From info at arin.net Mon Jun 2 11:27:24 2008 From: info at arin.net (Member Services) Date: Mon, 02 Jun 2008 11:27:24 -0400 Subject: [arin-ppml] Policy Proposal 2007-14 Discussed at ARIN Caribbean Sector Meeting Message-ID: <4844115C.3010308@arin.net> Policy Proposal 2007-14 Resource Review Process On 21 May, ARIN held a Caribbean Sector Meeting in Kingston, Jamaica, to discuss active policy proposals in the ARIN region and gain a Caribbean perspective on ARIN policies and procedures. Owen DeLong, as one of the proposal authors, presented the proposal and its rationale. Attendees asked questions about the review criteria, how ARIN will ensure equal treatment among organizations, ARIN's ties to the U.S. government, specific questions on ARIN's current IPv6 policies, and suggested clarification on the phrase "substantially out of compliance." Complete notes from the discussion about "Policy Proposal 2007-14: Resource Review Process" are available at http://www.arin.net/meetings/minutes/carib_spring_08/csm1_notes.html#anchor_5. The full report of that meeting, which includes presentations and summary notes, is available on the ARIN website at http://www.arin.net/meetings/minutes/carib_spring_08/. Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Mon Jun 2 11:27:30 2008 From: info at arin.net (Member Services) Date: Mon, 02 Jun 2008 11:27:30 -0400 Subject: [arin-ppml] Policy Proposal 2008-2 Discussed at ARIN Caribbean Sector Meeting Message-ID: <48441162.5020308@arin.net> Policy Proposal 2008-2 IPv4 Transfer Policy Proposal On 21 May, ARIN held a Caribbean Sector Meeting in Kingston, Jamaica, to discuss active policy proposals in the ARIN region and gain a Caribbean perspective on ARIN policies and procedures. Leo Bicknell, as Chair of the Advisory Council, presented on the topic of current policy, the history and rationale of this proposal, how the Advisory Council came to author it, and an overview of the text. Other members of the Board of Trustees and Advisory Council also provided other background information for the attendees. Meeting participants asked questions about ARIN's role in setting fees, the possibility of market speculation, and what repercussions would come from transfers made outside of ARIN. Another attendee commented that he did not understand the problem the policy attempts to solve, as IPv6 deployment would be the better solution. Complete notes from the discussion about "Policy Proposal 2008-2: IPv4 Transfer Policy Proposal" are available at http://www.arin.net/meetings/minutes/carib_spring_08/csm1_notes.html#anchor_6. The full report of that meeting, which includes presentations and summary notes, is available on the ARIN website at http://www.arin.net/meetings/minutes/carib_spring_08/. Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Mon Jun 2 11:27:36 2008 From: info at arin.net (Member Services) Date: Mon, 02 Jun 2008 11:27:36 -0400 Subject: [arin-ppml] Policy Proposal 2008-3 Discussed at ARIN Caribbean Sector Meeting Message-ID: <48441168.9070408@arin.net> Policy Proposal 2008-3 Community Networks IPv6 Allocation On 21 May, ARIN held a Caribbean Sector Meeting in Kingston, Jamaica, to discuss active policy proposals in the ARIN region and gain a Caribbean perspective on ARIN policies and procedures. Bill Darte, as a representative of the Advisory Council, presented the proposal and its rationale. Two attendees stated their support for such a proposal, with one commenting that it might help to foster the maturation and proliferation of new open source technologies such as WiMax. Complete notes from the discussion about "Policy Proposal 2008-3: Community Networks IPv6 Allocation" are available at http://www.arin.net/meetings/minutes/carib_spring_08/csm1_notes.html#anchor_12. The full report of that meeting, which includes presentations and summary notes, is available on the ARIN website at http://www.arin.net/meetings/minutes/carib_spring_08/. Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Mon Jun 2 11:27:42 2008 From: info at arin.net (Member Services) Date: Mon, 02 Jun 2008 11:27:42 -0400 Subject: [arin-ppml] Policy Proposal 2008-4 Discussed at ARIN Caribbean Sector Meeting Message-ID: <4844116E.1010206@arin.net> Policy Proposal 2008-4 Minimum Allocation in the Caribbean Region On 21 May, ARIN held a Caribbean Sector Meeting in Kingston, Jamaica, to discuss active policy proposals in the ARIN region and gain a Caribbean perspective on ARIN policies and procedures. Suzanne Woolf, as a representative of the Advisory Council, presented the proposal and outlined its specific requirements. Ray Plzak and Leo Bicknell provided additional information about the proposal's history and creation, including that this proposal's text is largely based on a previous policy in effect for the African portion of the ARIN region before AfriNIC became an RIR. Attendees asked for data on the number of organizations that would benefit from this policy. Leslie Nobile said that there have been 34 resource requests for allocations, assignments, and AS numbers between March 2007 and March 2008 and that of those received, about 50 percent were approved. Leo Bicknell asked if it would useful for this proposal to include assignments to end-users. Several attendees spoke in favor of such a revision, saying it would help foster competition and liberalize the industry in the Caribbean. Complete notes from the discussion about "Policy Proposal 2008-4: Minimum Allocation in the Caribbean Region" are available at http://www.arin.net/meetings/minutes/carib_spring_08/csm1_notes.html#anchor_13. The full report of that meeting, which includes presentations and summary notes, is available on the ARIN website at http://www.arin.net/meetings/minutes/carib_spring_08/. Regards, Member Services American Registry for Internet Numbers (ARIN) From carlos.usera at gsa.gov Mon Jun 2 17:02:20 2008 From: carlos.usera at gsa.gov (carlos.usera at gsa.gov) Date: Mon, 2 Jun 2008 16:02:20 -0500 Subject: [arin-ppml] Carlos A. Usera/6FB/R06/GSA/GOV is out of the office. Message-ID: I will be out of the office starting 06/02/2008 and will not return until 06/12/2008. Please contact Donna McCoy at 816-823-3620, if you have any immediate issues. From patara at lacnic.net Wed Jun 4 14:37:08 2008 From: patara at lacnic.net (Ricardo Patara) Date: Wed, 4 Jun 2008 15:37:08 -0300 Subject: [arin-ppml] Policy Proposal 2008-4 Discussed at ARIN Caribbean Sector Meeting In-Reply-To: <4844116E.1010206@arin.net> References: <4844116E.1010206@arin.net> Message-ID: <20080604153708.773568e6@lacnic.net> Hello, Regarding this policy proposal and also specially to the comment raised at ARIN Caribbean Sector Meeting, that similar policy would be needed inside LACNIC region. Such special policy for Caribbean sector is not needed in LACNIC, actually. Currently there is already a "similar" policy and it applies to any organization of the region. Basically, under this policy, any ISP in the LACNIC region can request a /21 IPv4 block. And to justify for such allocation, it has to show current efficient utilization of a /22 or an immediate need for it. No need to be multihomed. More details at: http://lacnic.net/en/politicas/2002-11-asignacionip.html 3.3.1. Initial Allocations to Internet Service Providers Regards -- Ricardo Patara Technical Area Manager | ricardo @ lacnic.net LACNIC - Latin American and | http://www.lacnic.net Caribbean IP Address Registry | +598 2 604 2222 >Policy Proposal 2008-4 >Minimum Allocation in the Caribbean Region > >On 21 May, ARIN held a Caribbean Sector Meeting in Kingston, Jamaica, to >discuss active policy proposals in the ARIN region and gain a Caribbean >perspective on ARIN policies and procedures. > >Suzanne Woolf, as a representative of the Advisory Council, presented >the proposal and outlined its specific requirements. Ray Plzak and Leo >Bicknell provided additional information about the proposal's history >and creation, including that this proposal's text is largely based on a >previous policy in effect for the African portion of the ARIN region >before AfriNIC became an RIR. > >Attendees asked for data on the number of organizations that would >benefit from this policy. Leslie Nobile said that there have been 34 >resource requests for allocations, assignments, and AS numbers between >March 2007 and March 2008 and that of those received, about 50 percent >were approved. Leo Bicknell asked if it would useful for this proposal >to include assignments to end-users. Several attendees spoke in favor of >such a revision, saying it would help foster competition and liberalize >the industry in the Caribbean. > >Complete notes from the discussion about "Policy Proposal 2008-4: >Minimum Allocation in the Caribbean Region" are available at >http://www.arin.net/meetings/minutes/carib_spring_08/csm1_notes.html#anchor_13. > >The full report of that meeting, which includes presentations and >summary notes, is available on the ARIN website at >http://www.arin.net/meetings/minutes/carib_spring_08/. > >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 the ARIN Member Services Help Desk at info at arin.net if you >experience any issues. From info at arin.net Thu Jun 5 10:32:15 2008 From: info at arin.net (Member Services) Date: Thu, 05 Jun 2008 10:32:15 -0400 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe Message-ID: <4847F8EF.5070709@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this 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. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Extend Experimental Renewal Timeframe Author: Azinger and Dave Meyer Proposal Version: 1 Submission Date: 4 June 2008 Proposal type: Modify Policy term: Permanent Policy statement: This proposal is to modify section 11.4 in the Policy Manual to extend the experimental timeframe from one year to two years before having to re-justify the use of an experimental block. Rationale: Currently anyone who has an experimental block is required to re-justify his or her use after just one year. Reality shows that any true experiment in technical nature that addresses the internet architecture and routing will take at least two years given the constraints of time and the simple fact of working out what could be a bug in the theory and not a show stopper. This proposal just wishes to extend the timeframe one year so that time isn?t wasted on re-justification. The revision of 11.4 would read as follows: The Numbering Resources are allocated on a lease/license basis for a period of two years. The allocation can be renewed on application to ARIN providing information as per Detail One. The identity and details of the applicant and the allocated Numbering Resources will be published under the conditions of ARIN?s normal publication policy. At the end of the experiment, resources allocated under this policy will be returned to the available pool. Timetable for implementation: Immediate From patara at lacnic.net Thu Jun 5 13:32:21 2008 From: patara at lacnic.net (Ricardo Patara) Date: Thu, 5 Jun 2008 14:32:21 -0300 Subject: [arin-ppml] Policy Proposal 2008-4 Discussed at ARIN Caribbean Sector Meeting In-Reply-To: <20080604153708.773568e6@lacnic.net> References: <4844116E.1010206@arin.net> <20080604153708.773568e6@lacnic.net> Message-ID: <20080605143221.553f0382@lacnic.net> Hello, Just to correct myself. Where I wrote that organization should demonstrate a utilization of /22, one should read demonstrate a utilization of /23. the correct statement would be: Basically, under this policy, any ISP in the LACNIC region can request a /21 IPv4 block. And to justify for such allocation, it has to show current efficient utilization of a /23 or an immediate need for it. No need to be multihomed. Regards Ricardo Patara > >Hello, > >Regarding this policy proposal and also specially to the comment raised at ARIN >Caribbean Sector Meeting, that similar policy would be needed inside LACNIC >region. > >Such special policy for Caribbean sector is not needed in LACNIC, actually. >Currently there is already a "similar" policy and it applies to any >organization of the region. > >Basically, under this policy, any ISP in the LACNIC region can request a /21 >IPv4 block. >And to justify for such allocation, it has to show current efficient >utilization of a /22 or an immediate need for it. No need to be multihomed. > >More details at: > >http://lacnic.net/en/politicas/2002-11-asignacionip.html >3.3.1. Initial Allocations to Internet Service Providers > >Regards >-- > Ricardo Patara > Technical Area Manager | ricardo @ lacnic.net > LACNIC - Latin American and | http://www.lacnic.net > Caribbean IP Address Registry | +598 2 604 2222 > >>Policy Proposal 2008-4 >>Minimum Allocation in the Caribbean Region >> >>On 21 May, ARIN held a Caribbean Sector Meeting in Kingston, Jamaica, to >>discuss active policy proposals in the ARIN region and gain a Caribbean >>perspective on ARIN policies and procedures. >> >>Suzanne Woolf, as a representative of the Advisory Council, presented >>the proposal and outlined its specific requirements. Ray Plzak and Leo >>Bicknell provided additional information about the proposal's history >>and creation, including that this proposal's text is largely based on a >>previous policy in effect for the African portion of the ARIN region >>before AfriNIC became an RIR. >> >>Attendees asked for data on the number of organizations that would >>benefit from this policy. Leslie Nobile said that there have been 34 >>resource requests for allocations, assignments, and AS numbers between >>March 2007 and March 2008 and that of those received, about 50 percent >>were approved. Leo Bicknell asked if it would useful for this proposal >>to include assignments to end-users. Several attendees spoke in favor of >>such a revision, saying it would help foster competition and liberalize >>the industry in the Caribbean. >> >>Complete notes from the discussion about "Policy Proposal 2008-4: >>Minimum Allocation in the Caribbean Region" are available at >>http://www.arin.net/meetings/minutes/carib_spring_08/csm1_notes.html#anchor_13. >> >>The full report of that meeting, which includes presentations and >>summary notes, is available on the ARIN website at >>http://www.arin.net/meetings/minutes/carib_spring_08/. >> >>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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you >experience any issues. From martin.hannigan at batelnet.bs Thu Jun 5 16:22:54 2008 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Thu, 05 Jun 2008 16:22:54 -0400 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out Message-ID: <48484b1e.3be.59b0.23719@batelnet.bs> ----- Original Message ----- From: "Michael K. Smith - Adhost" To: "Scott Leibrand" , Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out Date: Wed, 21 May 2008 16:26:19 -0700 > Hello Scott: > > I'm working on a basis assumption that Extra Large > organizations request more addresses more frequently than > any of the other groups. So, if allocations proceed > organically with the last IANA allocation, there is a high > likelihood that all of the last allocation will go to the > Extra Large organizations alone. Which will also filter down to other smaller guys, no? The larger networks are fulfilling their needs so that they can continue to grow their networks and their customers networks. Theoretically, all that would happen is that "smaller guys" with PI would have to resort to asking for "PA". All considered, that's better than getting nothing or stifling growth of others. Seems most fair to allow the system to operate on a needs basis right to the end, IMHO. Best, -M< From sleibrand at internap.com Thu Jun 5 23:53:34 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 05 Jun 2008 20:53:34 -0700 Subject: [arin-ppml] IPv6 in the Economist Message-ID: <4848B4BE.3060303@internap.com> The Economist, in their usual fashion, did a very good job with their metaphors in explaining the issues of IPv4 exhaustion and IPv6 transition for a general audience: http://www.economist.com/printedition/displaystory.cfm?story_id=11482493 -Scott From michel at arneill-py.sacramento.ca.us Fri Jun 6 00:43:06 2008 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 5 Jun 2008 21:43:06 -0700 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <4848B4BE.3060303@internap.com> References: <4848B4BE.3060303@internap.com> Message-ID: > Scott Leibrand wrote: > The Economist, in their usual fashion, did a very good job with > their metaphors in explaining the issues of IPv4 exhaustion and > IPv6 transition for a general audience: I think it would have been better if it was accurate: > http://www.economist.com/printedition/displaystory.cfm?story_id=11482493 > {..} Support for IPv6 is already baked into most popular operating > system software. It is incorporated into Windows XP and Vista {..} Last time I checked, IPv6 was not "incorporated" into XP. Given the huge popular success of Vista especially in corporate environments that changes the picture a bit, as XP still is by far the most popular operating system. I purchased some HP PCs recently; as many others, I bought the Windows Vista downgrade (meaning: the Vista license is purchased and the system comes with XP). And yes it is the actual wording. http://h20331.www2.hp.com/Hpsub/downloads/Vista_downgrade_FAQ.pdf Michel. From sleibrand at internap.com Fri Jun 6 00:49:00 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 05 Jun 2008 21:49:00 -0700 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: References: <4848B4BE.3060303@internap.com> Message-ID: <4848C1BC.9020009@internap.com> Michel Py wrote: >> Scott Leibrand wrote: >> The Economist, in their usual fashion, did a very good job with >> their metaphors in explaining the issues of IPv4 exhaustion and >> IPv6 transition for a general audience: > > I think it would have been better if it was accurate: > > http://www.economist.com/printedition/displaystory.cfm?story_id=11482493 >> {..} Support for IPv6 is already baked into most popular operating >> system software. It is incorporated into Windows XP and Vista {..} > > Last time I checked, IPv6 was not "incorporated" into XP. Given the > huge popular success of Vista especially in corporate > environments that changes the picture a bit, as XP still is > by far the most popular operating system. It requires activation from the command line, but Windows XP definitely has IPv6 support. I enabled and used it on my XP laptop at the last ARIN meeting. -Scott From michel at arneill-py.sacramento.ca.us Fri Jun 6 00:53:53 2008 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 5 Jun 2008 21:53:53 -0700 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <4848C1BC.9020009@internap.com> References: <4848B4BE.3060303@internap.com> <4848C1BC.9020009@internap.com> Message-ID: >> Michel Py wrote: >> Last time I checked, IPv6 was not "incorporated" into XP. > Scott Leibrand wrote: > It requires activation from the command line, but Windows XP > definitely has IPv6 support. I enabled and used it on my XP > laptop at the last ARIN meeting. I've been using it since it was in beta. Command line activation is exactly the kind of IPv6 support that will make IPv6 popular in a Windows world. Michel. From sleibrand at internap.com Fri Jun 6 00:57:00 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 05 Jun 2008 21:57:00 -0700 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: References: <4848B4BE.3060303@internap.com> <4848C1BC.9020009@internap.com> Message-ID: <4848C39C.5040209@internap.com> Michel Py wrote: >>> Michel Py wrote: >>> Last time I checked, IPv6 was not "incorporated" into XP. > >> Scott Leibrand wrote: >> It requires activation from the command line, but Windows XP >> definitely has IPv6 support. I enabled and used it on my XP >> laptop at the last ARIN meeting. > > I've been using it since it was in beta. Command line activation is > exactly the kind of IPv6 support that will make IPv6 popular in a > Windows world. Perhaps, but that seems like the least of out issues when so many devices don't support it at all. -Scott From randy at psg.com Fri Jun 6 04:32:34 2008 From: randy at psg.com (Randy Bush) Date: Fri, 06 Jun 2008 09:32:34 +0100 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <4848C1BC.9020009@internap.com> References: <4848B4BE.3060303@internap.com> <4848C1BC.9020009@internap.com> Message-ID: <4848F622.2090002@psg.com> Scott Leibrand wrote: > Windows XP definitely has IPv6 support. except it is broken. xp does not support the dns protocol over ipv6 transport. randy From owen at delong.com Fri Jun 6 04:51:42 2008 From: owen at delong.com (Owen DeLong) Date: Fri, 6 Jun 2008 01:51:42 -0700 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <4848C1BC.9020009@internap.com> References: <4848B4BE.3060303@internap.com> <4848C1BC.9020009@internap.com> Message-ID: <2E45CCB5-94CA-4AFE-BAA3-A32426696FCF@delong.com> On Jun 5, 2008, at 9:49 PM, Scott Leibrand wrote: > Michel Py wrote: >>> Scott Leibrand wrote: >>> The Economist, in their usual fashion, did a very good job with >>> their metaphors in explaining the issues of IPv4 exhaustion and >>> IPv6 transition for a general audience: >> >> I think it would have been better if it was accurate: >> >> http://www.economist.com/printedition/displaystory.cfm?story_id=11482493 >>> {..} Support for IPv6 is already baked into most popular operating >>> system software. It is incorporated into Windows XP and Vista {..} >> >> Last time I checked, IPv6 was not "incorporated" into XP. Given the >> huge popular success of Vista especially in corporate >> environments that changes the picture a bit, as XP still >> is >> by far the most popular operating system. > > It requires activation from the command line, but Windows XP > definitely > has IPv6 support. I enabled and used it on my XP laptop at the last > ARIN meeting. Except you can't do name resolution if you turn off IPv4. I would say that's not full IPv6 support. I'd say that's minimal sort-of support at best. Owen From farmer at umn.edu Fri Jun 6 08:21:30 2008 From: farmer at umn.edu (David Farmer) Date: Fri, 06 Jun 2008 07:21:30 -0500 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <2E45CCB5-94CA-4AFE-BAA3-A32426696FCF@delong.com> References: <4848B4BE.3060303@internap.com>, <4848C1BC.9020009@internap.com>, <2E45CCB5-94CA-4AFE-BAA3-A32426696FCF@delong.com> Message-ID: <4848E57A.6418.2D419CF@farmer.umn.edu> On 6 Jun 2008 Owen DeLong wrote: > > On Jun 5, 2008, at 9:49 PM, Scott Leibrand wrote: > > > Michel Py wrote: > >>> Scott Leibrand wrote: > >>> The Economist, in their usual fashion, did a very good job with > >>> their metaphors in explaining the issues of IPv4 exhaustion and > >>> IPv6 transition for a general audience: > >> > >> I think it would have been better if it was accurate: > >> > >> http://www.economist.com/printedition/displaystory.cfm?story_id=114 > >> 82493 > >>> {..} Support for IPv6 is already baked into most popular operating > >>> system software. It is incorporated into Windows XP and Vista {..} > >> > >> Last time I checked, IPv6 was not "incorporated" into XP. Given the > >> huge popular success of Vista especially in corporate > >> environments that changes the picture a bit, as XP still > >> is by far the most popular operating system. > > > > It requires activation from the command line, but Windows XP > > definitely > > has IPv6 support. I enabled and used it on my XP laptop at the last > > ARIN meeting. > > Except you can't do name resolution if you turn off IPv4. > > I would say that's not full IPv6 support. > > I'd say that's minimal sort-of support at best. > > Owen You are being typical techies, completely missing the point, and obscuring it with nit-picky details. I will join you :), but first. The most important part is the navy pin-striped suit world of the Economist is talking about IPv6, be glad and capitalize on it. For you services providers out there, get your CEOs to push this out to your customers executives. For end-user organizations, get your CIO to share this with the rest of the CXOs in your organization. So why should Microsoft support IPv6 any better than it supports IPv4. ================================================= David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ================================================= From info at arin.net Fri Jun 6 09:26:34 2008 From: info at arin.net (Member Services) Date: Fri, 06 Jun 2008 09:26:34 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment Message-ID: <48493B0A.2070305@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this 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. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Dedicated IPv4 block to facilitate IPv6 deployment Author: Alain Durand Proposal Version: 1.0 Submission Date: 6/6/2008 Proposal type: New Policy term: Permanent Policy statement: 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; 6) recipient organizations must be members in good standing of ARIN. Rationale: Rationale for reserving IPv4 space: This policy provides predictability on how the end game of IPv4 is going to be played after IANA completion. It will facilitate IPv6 deployment by ensuring that some small chunks of IPv4 space will remain available for a long time to ease the co-existence of IPv4 & IPv6. Rationale for reserving a contiguous /10 This is a balance between setting aside too much space and not having enough to facilitate IPv6 deployment for many years. Out of the last /8, that would leave the equivalent of 3 /10 to ARIN either for business as usual or for other policies in the spirit of this one. A /10 represents 4,194,304 IP addresses, If all of them were to be used in NAT-PT or NAT464 type devices with a consolidation factor of 100 users behind each IP address, that would represent about 400 million users. Most networks today filter IPv4 announcements more specific than /24. This policy creates allocations & assignment prefixes as long as /28. Allocating out of a contiguous block will mitigate the impact of this policy on filter lists. Rationale for minimum size allocation of /28 This minimum size allocation will put a cap at 250k additional entries in the global IPv4 routing table. Rationale for maximum size allocation of /24 and for the 6 month delay between allocations This maximum allocation size coupled with the requirement of a 6 months delay between allocations will prevent hoarding and make sure this pool will last several years. Rationale for forced renumbering for further allocation The minimum allocation size of /28 may create a huge increase in the IPv4 routing table size. Forcing renumbering for subsequent allocations under this policy will somehow limit the growth of the routing table size by enabling the announcement of aggregated space. It is expected that the savings in routing table entries will outweigh the pain of forced renumbering. However, renumbering is never an easy task, so it should only be considered as last resort. it is expected that sparse allocation techniques will prevent the need of force renumbering for a fairly long time. Note: This policy proposal hints that the /10 should come out of the last /8 received by ARIN from IANA. However, it does not say so explicitly, leaving the final decision up to the ARIN staff. Timetable for implementation: As soon as ARIN gets its last /8 allocation from IANA. From dean at av8.com Fri Jun 6 10:25:45 2008 From: dean at av8.com (Dean Anderson) Date: Fri, 6 Jun 2008 10:25:45 -0400 (EDT) Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <2E45CCB5-94CA-4AFE-BAA3-A32426696FCF@delong.com> Message-ID: On Fri, 6 Jun 2008, Owen DeLong wrote: > Except you can't do name resolution if you turn off IPv4. > > I would say that's not full IPv6 support. > > I'd say that's minimal sort-of support at best. DNS is very severely broken in IPv6. This non-technical reason is that certain root operators want to keep their monopolies on anycast sales, and so (for technically inexplicable reasons), they have advocated mixing IPv6 and IPv4, and silenced dissent in apparent violations of anti-trust law. So, there are no IPv6 root nameservers. Instead, one mixes IPv6 DNS records with IPv4 DNS records on the same nameserver. This totally unnecessary mixing creates stability problems for both IPv4 and IPv6. One has to remove IPv4 NS records to make room for IPv6 records, so any effort to deploy IPv6 comes at the expense of IPv4 stability. While bad enough, that isn't the worst part. What's worse is that the DNS resolver implementations are broken as well. One can't just create IPv6 root nameservers because the resolvers don't do the right thing--there is no IPv6-specific resolver which could use different root nameservers for IPv6. IPv4 and IPv6 have to be mixed at the roots on down. Until this is fixed, IPv6 won't really be very useful or else both won't be stable. Altering and updating resolvers on every computer is a very time-consuming job to say the least. So, I think IPv6 won't be taking over in 3 years, and IPv4 won't be going away in 3 years. Its probably 10+ years to fix the resolver problem, and so a long time before IPv6 could be ready for stable deployment outside a lab. In that time, I'd say we could go to OSI CLNS instead, and have much less risk. The good news is that one can work on both IPv6 and CLNS simultaneously as completely separate stacks. Keeping CLNS separate from IPv4 this time will improve the process of development, and improve deployment stability later. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From ptimmins at clearrate.com Fri Jun 6 10:27:43 2008 From: ptimmins at clearrate.com (Paul G. Timmins) Date: Fri, 6 Jun 2008 10:27:43 -0400 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: Message-ID: Dean, are you on drugs? I can't tolerate this garbage anymore. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Dean Anderson Sent: Friday, June 06, 2008 10:26 AM To: Owen DeLong Cc: PPML Subject: Re: [arin-ppml] IPv6 in the Economist On Fri, 6 Jun 2008, Owen DeLong wrote: > Except you can't do name resolution if you turn off IPv4. > > I would say that's not full IPv6 support. > > I'd say that's minimal sort-of support at best. DNS is very severely broken in IPv6. This non-technical reason is that certain root operators want to keep their monopolies on anycast sales, and so (for technically inexplicable reasons), they have advocated mixing IPv6 and IPv4, and silenced dissent in apparent violations of anti-trust law. So, there are no IPv6 root nameservers. Instead, one mixes IPv6 DNS records with IPv4 DNS records on the same nameserver. This totally unnecessary mixing creates stability problems for both IPv4 and IPv6. One has to remove IPv4 NS records to make room for IPv6 records, so any effort to deploy IPv6 comes at the expense of IPv4 stability. While bad enough, that isn't the worst part. What's worse is that the DNS resolver implementations are broken as well. One can't just create IPv6 root nameservers because the resolvers don't do the right thing--there is no IPv6-specific resolver which could use different root nameservers for IPv6. IPv4 and IPv6 have to be mixed at the roots on down. Until this is fixed, IPv6 won't really be very useful or else both won't be stable. Altering and updating resolvers on every computer is a very time-consuming job to say the least. So, I think IPv6 won't be taking over in 3 years, and IPv4 won't be going away in 3 years. Its probably 10+ years to fix the resolver problem, and so a long time before IPv6 could be ready for stable deployment outside a lab. In that time, I'd say we could go to OSI CLNS instead, and have much less risk. The good news is that one can work on both IPv6 and CLNS simultaneously as completely separate stacks. Keeping CLNS separate from IPv4 this time will improve the process of development, and improve deployment stability later. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From randy at psg.com Fri Jun 6 10:42:58 2008 From: randy at psg.com (Randy Bush) Date: Fri, 06 Jun 2008 15:42:58 +0100 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: References: Message-ID: <48494CF2.1050109@psg.com> Paul G. Timmins wrote: > Dean, are you on drugs? I can't tolerate this garbage anymore. > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Dean Anderson > > DNS is very severely broken in IPv6. This non-technical reason is that > certain root operators want to keep their monopolies on anycast sales, > and so (for technically inexplicable reasons), they have advocated > mixing IPv6 and IPv4, and silenced dissent in apparent violations of > anti-trust law. So, there are no IPv6 root nameservers. Instead, one > mixes IPv6 DNS records with IPv4 DNS records on the same nameserver. > This totally unnecessary mixing creates stability problems for both IPv4 > and IPv6. One has to remove IPv4 NS records to make room for IPv6 > records, so any effort to deploy IPv6 comes at the expense of IPv4 > stability. While bad enough, that isn't the worst part. this is truly amazing stuff! i am deeply impressed with the level of invention, delusion. and paranoia. it's better than some of the sci-fi i read on airplanes. i need to let some of this nut's stuff through when i need amusement. procmail needs a mood sensor. in my small experience, dns mostly works in v6. the issues are at the level of specific implementation oddities, xp not using v6 transport being the worst (i bought a mac). and some implementations which don't do dhcpv6 also do not use the wkas. randy From dean at av8.com Fri Jun 6 10:57:42 2008 From: dean at av8.com (Dean Anderson) Date: Fri, 6 Jun 2008 10:57:42 -0400 (EDT) Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: Message-ID: If you have something to dispute, dispute it. State your facts, if you have any to state. I've stated mine. Your mindless, factless promotion of certain view is wearing out. --Dean On Fri, 6 Jun 2008, Paul G. Timmins wrote: > Dean, are you on drugs? I can't tolerate this garbage anymore. > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Dean Anderson > Sent: Friday, June 06, 2008 10:26 AM > To: Owen DeLong > Cc: PPML > Subject: Re: [arin-ppml] IPv6 in the Economist > > On Fri, 6 Jun 2008, Owen DeLong wrote: > > > Except you can't do name resolution if you turn off IPv4. > > > > I would say that's not full IPv6 support. > > > > I'd say that's minimal sort-of support at best. > > DNS is very severely broken in IPv6. This non-technical reason is that > certain root operators want to keep their monopolies on anycast sales, > and so (for technically inexplicable reasons), they have advocated > mixing IPv6 and IPv4, and silenced dissent in apparent violations of > anti-trust law. So, there are no IPv6 root nameservers. Instead, one > mixes IPv6 DNS records with IPv4 DNS records on the same nameserver. > This totally unnecessary mixing creates stability problems for both IPv4 > and IPv6. One has to remove IPv4 NS records to make room for IPv6 > records, so any effort to deploy IPv6 comes at the expense of IPv4 > stability. While bad enough, that isn't the worst part. > > What's worse is that the DNS resolver implementations are broken as > well. One can't just create IPv6 root nameservers because the resolvers > don't do the right thing--there is no IPv6-specific resolver which could > use different root nameservers for IPv6. IPv4 and IPv6 have to be mixed > at the roots on down. Until this is fixed, IPv6 won't really be very > useful or else both won't be stable. Altering and updating resolvers on > every computer is a very time-consuming job to say the least. So, I > think IPv6 won't be taking over in 3 years, and IPv4 won't be going away > in 3 years. > > Its probably 10+ years to fix the resolver problem, and so a long time > before IPv6 could be ready for stable deployment outside a lab. In that > time, I'd say we could go to OSI CLNS instead, and have much less risk. > > The good news is that one can work on both IPv6 and CLNS simultaneously > as completely separate stacks. Keeping CLNS separate from IPv4 this > time will improve the process of development, and improve deployment > stability later. > > --Dean > > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From ptimmins at clearrate.com Fri Jun 6 11:05:48 2008 From: ptimmins at clearrate.com (Paul G. Timmins) Date: Fri, 6 Jun 2008 11:05:48 -0400 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: Message-ID: I was going to say the same about you. If you're angry, just sue someone already and get it over with. I tried to be neutral in this, but hearing months and months of conspiracy theories and now some sort of push for OSI CLNS over IPv6 because of some "certain root operators want to keep their monopolies on anycast sales" (obviously a reference to the usual suspects you decry on a daily basis). Maybe we let these people run the root servers because they do a good job at it and don't screw up? Are you offering to run a root DNS server? It's a job you get to do for free, and then net kooks can implicate you're part of a secret cabal. Sounds like a good deal. Tellya what. You set up your own ARIN running OSI CLNS, and your own root servers over OSI CLNS, and if it takes off and the majority people actually use it instead of IPv6, I'll buy transit from you. Deal? Until then, I think I speak for the silent majority when I say that your conspiracy theories and bandying about of legal terms freely, denigrating people who are generally respected as good actors on the internet (and if you don't like that, PROVE OTHERWISE! Making your case on PPML is great, but you know what they say about arguing on the internet. Pick your venue and go for it!) just weakens your case in the eyes of the public, and make PPML look like a collection of bickering adults in their mother's basements wearing tinfoil hats. As the glorious comic book I got last summer states: Who is ARIN? YOU ARE! And frankly, I don't want history to see us in this light. Well, maybe they can see you in this light, but not the rest of us. Maybe you could start a livejournal for your rants or something. -Paul -----Original Message----- From: Dean Anderson [mailto:dean at av8.com] Sent: Friday, June 06, 2008 10:58 AM To: Paul G. Timmins Cc: Owen DeLong; PPML Subject: Re: [arin-ppml] IPv6 in the Economist If you have something to dispute, dispute it. State your facts, if you have any to state. I've stated mine. Your mindless, factless promotion of certain view is wearing out. --Dean On Fri, 6 Jun 2008, Paul G. Timmins wrote: > Dean, are you on drugs? I can't tolerate this garbage anymore. > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Dean Anderson > Sent: Friday, June 06, 2008 10:26 AM > To: Owen DeLong > Cc: PPML > Subject: Re: [arin-ppml] IPv6 in the Economist > > On Fri, 6 Jun 2008, Owen DeLong wrote: > > > Except you can't do name resolution if you turn off IPv4. > > > > I would say that's not full IPv6 support. > > > > I'd say that's minimal sort-of support at best. > > DNS is very severely broken in IPv6. This non-technical reason is that > certain root operators want to keep their monopolies on anycast sales, > and so (for technically inexplicable reasons), they have advocated > mixing IPv6 and IPv4, and silenced dissent in apparent violations of > anti-trust law. So, there are no IPv6 root nameservers. Instead, one > mixes IPv6 DNS records with IPv4 DNS records on the same nameserver. > This totally unnecessary mixing creates stability problems for both IPv4 > and IPv6. One has to remove IPv4 NS records to make room for IPv6 > records, so any effort to deploy IPv6 comes at the expense of IPv4 > stability. While bad enough, that isn't the worst part. > > What's worse is that the DNS resolver implementations are broken as > well. One can't just create IPv6 root nameservers because the resolvers > don't do the right thing--there is no IPv6-specific resolver which could > use different root nameservers for IPv6. IPv4 and IPv6 have to be mixed > at the roots on down. Until this is fixed, IPv6 won't really be very > useful or else both won't be stable. Altering and updating resolvers on > every computer is a very time-consuming job to say the least. So, I > think IPv6 won't be taking over in 3 years, and IPv4 won't be going away > in 3 years. > > Its probably 10+ years to fix the resolver problem, and so a long time > before IPv6 could be ready for stable deployment outside a lab. In that > time, I'd say we could go to OSI CLNS instead, and have much less risk. > > The good news is that one can work on both IPv6 and CLNS simultaneously > as completely separate stacks. Keeping CLNS separate from IPv4 this > time will improve the process of development, and improve deployment > stability later. > > --Dean > > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean at av8.com Fri Jun 6 11:08:21 2008 From: dean at av8.com (Dean Anderson) Date: Fri, 6 Jun 2008 11:08:21 -0400 (EDT) Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <48494CF2.1050109@psg.com> Message-ID: On Fri, 6 Jun 2008, Randy Bush wrote: > this is truly amazing stuff! i am deeply impressed with the level of > invention, delusion. and paranoia. it's better than some of the sci-fi > i read on airplanes. i need to let some of this nut's stuff through > when i need amusement. procmail needs a mood sensor. Perhaps you mean Paul. If I've invented something, please, by all means, state it. BTW, asserting falsehoods about someone else's sanity is indeed per se defamation. Maybe you should check your facts. Or is fact-checking too much to ask? > in my small experience, dns mostly works in v6. the issues are at the > level of specific implementation oddities, xp not using v6 transport > being the worst (i bought a mac). and some implementations which don't > do dhcpv6 also do not use the wkas. 'dns mostly works in v6' doesn't seem very specific, not does it actually dispute any fact I asserted. 1. You could claim that there are actually IPv6 root servers. [that would be something objectively determined.] 2. You could claim that IPv4 and IPv6 DNS records aren't mixed. [that could also be objectively determined.] 3. You could claim that one must remove IPv4 NS records for IPv6 NS records. [that could also be objectively determined] Instead, you just resort to namecalling. Well, we already know that namecalling is no basis for a technical argument. In fact, we also know that namecalling is the last resort of the weakminded, who have no facts to support their views. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean at av8.com Fri Jun 6 11:43:19 2008 From: dean at av8.com (Dean Anderson) Date: Fri, 6 Jun 2008 11:43:19 -0400 (EDT) Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: Message-ID: On Fri, 6 Jun 2008, Paul G. Timmins wrote: > I was going to say the same about you. If you're angry, just sue someone > already and get it over with. Lawyers are involved. Members vote. Character matters. > I tried to be neutral in this, You don't sound very neutral. > but hearing months and months of conspiracy theories and A theory that explains the evidence and is supported by hard facts. > now some sort of push for OSI CLNS over IPv6 because of some "certain > root operators want to keep their monopolies on anycast sales" > (obviously a reference to the usual suspects you decry on a daily > basis). No, I'm pushing OSI CLNS over IPv6 because it will do the job better, and its already implemented on just about every router. OSI is a practical alternative. The remaining work is acheivable. By contrast, the root operator problems are additional problems of IPv6, and relate to other, similar problems. They are not the only reason to support OSI. > Maybe we let these people run the root servers because they do a good > job at it and don't screw up? Or maybe not. The evidence says 'not'. > Until then, "then"? Until I post facts about their not doing a good job, you mean? > I think I speak for the silent majority It turns out that the silent majority didn't vote for your view. They didn't vote at all. A tiny majority voted for Vixie (2%). So I don't think you or they speak for the silent majority. > when I say that your conspiracy theories and bandying about of legal > terms freely, denigrating people who are generally respected as good > actors on the internet (and if you don't like that, PROVE OTHERWISE! > Making your case on PPML is great, but you know what they say about > arguing on the internet. Pick your venue and go for it!) PPML is a place for public policy discussion, and in particular, IPv4 and IPv6 policy. And, indeed, I am proving that people aren't exactly the 'good actors' that you assert they are. You just don't like the unfavorable facts being brought to light. Facts I'm bringing to light do "PROVE OTHERWISE". > just weakens your case in the > eyes of the public, and make PPML look like a collection of bickering > adults in their mother's basements wearing tinfoil hats. As the glorious > comic book I got last summer states: Who is ARIN? YOU ARE! And frankly, > I don't want history to see us in this light. Well, maybe they can see > you in this light, but not the rest of us. Maybe you could start a > livejournal for your rants or something. You are the only one ranting---I posted facts. You haven't even bothered to dispute the facts I posted. That seems pretty 'rant-like'. I'm just responding to rants. Sigh. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From Lee at Dilkie.com Fri Jun 6 11:51:14 2008 From: Lee at Dilkie.com (Lee Dilkie) Date: Fri, 06 Jun 2008 11:51:14 -0400 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: References: Message-ID: <48495CF2.6040804@Dilkie.com> Dean, I'm unsure why you think IPv6 is broken simply because the DNS infrastructure isn't completely rolled out yet or is designed in a fashion not to your liking. Dean Anderson wrote: > 1. You could claim that there are actually IPv6 root servers. > [that would be something objectively determined.] > This will take some time, but is hardly holding up deployment. > 2. You could claim that IPv4 and IPv6 DNS records aren't mixed. [that > could also be objectively determined.] > I see no reason why there is a problem mixing IPv4 and IPv6 addresses in DNS. DNS is just a database, it contains a lot of other non ip address records like SPF and DKIM, TXT.. So putting both IPv4 and IPv6 addresses into the same nameserver is quite reasonable. How you access the nameserver, either via IPv4, IPv6 or X.25 even, isn't the question. > 3. You could claim that one must remove IPv4 NS records for IPv6 NS > records. [that could also be objectively determined] > huh? I don't understand your point. The fact is. IPv4 isn't going away for a very long time. The *only* reasonable rollout involves dual stack existing for a long time. Separating transport from content (be it web, dns records, anything) and making it accessible from both IPv4 and v6 is going to be the norm, for a long time. Owing to the nature of dual stack, I don't think anyone is in a hurry to roll out end-to-end IPv6-only deployments. Our first goal should be to get IPv6 networks and routing rolled out to our IPv4 customers so dual-stack will even have a chance of working. -lee > > From jradel at vantage.com Fri Jun 6 11:59:47 2008 From: jradel at vantage.com (Jon Radel) Date: Fri, 06 Jun 2008 11:59:47 -0400 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: References: Message-ID: <48495EF3.4000202@vantage.com> [Forgive me, for I know what I do and yet I do it anyway.] Dean Anderson wrote: > 'dns mostly works in v6' doesn't seem very specific, not does it > actually dispute any fact I asserted. > > 1. You could claim that there are actually IPv6 root servers. > [that would be something objectively determined.] > Could you please define what you mean by an "IPv6 root server." You see, I think most people would mean something along the lines of "a DNS server which responds to queries about TLD nameservers across the IPv6 Internet." So I just had a nice chat with m.root-servers.net on 2001:dc3::35 and among other fine servers for com. it told me about a.gtld-servers.net which was nice enough to talk to me on 2001:503:a83e::2:30 about the SLD I was curious about. So what vital part of the IPv6 puzzle is still missing in the land of root servers? > 2. You could claim that IPv4 and IPv6 DNS records aren't mixed. [that > could also be objectively determined.] > > You mean A and AAAA records all mushed together in one zone? Of course they are. I'm not sure I've ever seen an explanation from you as to why this is a concern. > 3. You could claim that one must remove IPv4 NS records for IPv6 NS > records. [that could also be objectively determined] > > > Ooops, you appear to be arguing against yourself here; you already made that claim yourself. > Instead, you just resort to namecalling. Well, we already know that > namecalling is no basis for a technical argument. In fact, we also know > that namecalling is the last resort of the weakminded, who have no facts > to support their views. > > --Dean > > The problem isn't that you don't have facts. You do have facts. Nice shiny facts. Some of them even sound a bit scary. But you never seem to show any reasoning behind the claim that those facts prove that things are terribly broken. Then you skip ahead, again never actually showing the connection, rather simply asserting it over and over, that since things are broken there is a conspiracy to make them so. --Jon Radel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3303 bytes Desc: S/MIME Cryptographic Signature URL: From randy at psg.com Fri Jun 6 12:01:04 2008 From: randy at psg.com (Randy Bush) Date: Fri, 06 Jun 2008 17:01:04 +0100 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <48495CF2.6040804@Dilkie.com> References: <48495CF2.6040804@Dilkie.com> Message-ID: <48495F40.30403@psg.com> > I don't think anyone is in a hurry to roll out end-to-end IPv6-only > deployments. see , a *very* big v6-only network. randy From bicknell at ufp.org Fri Jun 6 12:51:10 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 6 Jun 2008 12:51:10 -0400 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: References: <2E45CCB5-94CA-4AFE-BAA3-A32426696FCF@delong.com> Message-ID: <20080606165109.GB76533@ussenterprise.ufp.org> In a message written on Fri, Jun 06, 2008 at 10:25:45AM -0400, Dean Anderson wrote: > and IPv6. One has to remove IPv4 NS records to make room for IPv6 > records, so any effort to deploy IPv6 comes at the expense of IPv4 > stability. While bad enough, that isn't the worst part. I've seen one person confused by Dean's statement already, so I will attempt to clarify. Technically this is an extremely complex issue that has no place on the ARIN PPML list, so I will offer only the high level overview here. There are other more appropriate places for DNS information, and I would appreciate if you have questions that they be taken off list. DNS attempts to fit responses into a single UDP packet that will not need to be fragmented back to the sender. In IPv4 that requires the packet to fit in a 576 byte packet, the minimum end to end guaranteed MTU. Note that for IPv6 this limit has been raised to 1280 bytes. Doing the math you find that 13 NS records can be packed into a 512 byte response. This is why there are 13 root servers, and why some other domains have 13 name servers. That's not to say it's a hard limit, you could have more and do round robin or other tricks; but it often becomes a useful limit to know. Since there were 13 root servers, that is a full packet, a decision had to be made as to what to do when IPv6 addresses were added. Different name server software behaves slightly differently; basically you can prefer to fill the packet as much as possible, or you can prefer IPv4 over IPv6, or you can prefer IPv6 over IPv4. At the end of this message are some sample queries if you want to go and look for yourself. Note: only 6 root servers have IPv6 addresses today, eventually that will likely be all 13. The results: Before: 13 root servers After, Behavior #1: 10/13 IPv4 root addresses (at random) plus 4/6 IPv6 root addresses (at random) After, Behavior #2: 13/13 IPv4 root addresses, 2/6 IPv6 root addresses (at random) If you look at behavior #1, I believe that is the inspiration for Dean's statement, quoted above. [Only a guess.] One solution is a client could re-query using TCP. Some clients may do that. Fortunately DNS has also moved on. RFC 2671 specifies EDNS0, an extension to DNS to allow for larger packets. This was later required in RFC 3226 for all DNSSEC and A6 aware servers and resolvers. RFC 2874 may also be of interest. So, as a practical result IPv6 (transport) implementations have a 1280 byte packet guaranteed, and support EDNS0 to allow larger queries. This allows the entire set (in the case of the roots) to be returned in a single packet. See also the queries at the end of this message. So, as with all things the devil is in the details. The effect on DNS stability has been heavily discussed in the IETF and at the IANA level (in the case of the roots), and both of those venues are far more appropriate places than PPML for those discussions. Popular positions include (but are not limited to): * This hurts stability, IPv4 addresses are removed. * This helps stability, IPv4 and IPv6 transport now reach the roots. * It's a transition problem. * All clients should support EDNS0 which makes the problem moot. * Clients can fall back to TCP just fine. * Fall back to TCP doesn't work, usually because of anycast. YMMV. Some assembly required. Batteries not included. Many details omitted as this is not a technical DNS forum. Please take this discussion elsewhere. % dig -4 NS . @a.root-servers.net ; <<>> DiG 9.5.0-P1 <<>> -4 NS . @a.root-servers.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3008 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30 B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201 C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235 I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30 J.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:c27::2:30 ;; Query time: 78 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Fri Jun 6 16:17:58 2008 ;; MSG SIZE rcvd: 500 % dig -4 NS . @b.root-servers.net ; <<>> DiG 9.5.0-P1 <<>> -4 NS . @b.root-servers.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15468 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30 K.ROOT-SERVERS.NET. 3600000 IN A 193.0.14.129 L.ROOT-SERVERS.NET. 3600000 IN A 199.7.83.42 M.ROOT-SERVERS.NET. 3600000 IN A 202.12.27.33 A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201 F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235 ;; Query time: 12 msec ;; SERVER: 192.228.79.201#53(192.228.79.201) ;; WHEN: Fri Jun 6 16:22:05 2008 ;; MSG SIZE rcvd: 492 Using IPv6 w/EDNS0: dig -6 +bufsize=1024 NS . @a.root-servers.net ; <<>> DiG 9.5.0-P1 <<>> -6 +bufsize=1024 NS . @a.root-servers.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33651 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 20 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30 B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201 C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235 I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30 J.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:c27::2:30 K.ROOT-SERVERS.NET. 3600000 IN A 193.0.14.129 K.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:7fd::1 L.ROOT-SERVERS.NET. 3600000 IN A 199.7.83.42 M.ROOT-SERVERS.NET. 3600000 IN A 202.12.27.33 M.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:dc3::35 ;; Query time: 80 msec ;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30) ;; WHEN: Fri Jun 6 16:43:20 2008 ;; MSG SIZE rcvd: 615 -- 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: 187 bytes Desc: not available URL: From jay at impulse.net Fri Jun 6 13:20:50 2008 From: jay at impulse.net (Jay Hennigan) Date: Fri, 06 Jun 2008 10:20:50 -0700 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: References: Message-ID: <484971F2.7050807@impulse.net> Paul G. Timmins wrote: > Dean, are you on drugs? I can't tolerate this garbage anymore. In case you haven't noticed, ARIN, NANOG, IPv6, DNS, closed SMTP relays, etc. are all vast criminal conspiracies which his cartooneys will aggressively pursue Real Soon Now. Lather, rinse, repeat. +----------+ | PLEASE | | DO NOT | | FEED THE | | TROLL | +----------+ | | | | .\|.||/.. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From mloftis at wgops.com Fri Jun 6 13:20:14 2008 From: mloftis at wgops.com (Michael Loftis) Date: Fri, 06 Jun 2008 11:20:14 -0600 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: References: Message-ID: <7CA05D6FC904FC8EBFE18BF7@ZOP-MACTEL-3.local> --On June 6, 2008 10:25:45 AM -0400 Dean Anderson wrote: > On Fri, 6 Jun 2008, Owen DeLong wrote: > >> Except you can't do name resolution if you turn off IPv4. >> >> I would say that's not full IPv6 support. >> >> I'd say that's minimal sort-of support at best. > > DNS is very severely broken in IPv6. This non-technical reason is that > certain root operators want to keep their monopolies on anycast sales, > and so (for technically inexplicable reasons), they have advocated > mixing IPv6 and IPv4, and silenced dissent in apparent violations of If you can get the tens of thousands of ASs to switch to v6 on a given 0-hour then you must be closer to some God than any of us mortals. A solution without mixed v4/v6 is impossible right now because there are still many people who are in the v6 world on an island compared to certain other destinations, this is improving, but it will be quite a while before one can say v6 connectivity is as good as v4, and I'm pretty sure most op's agree on that. The only thing I can perceive that you want is for nameservers to answer with only v6 responses on v6 based queries, v4 on v4. And that's NOT the nameservers job. It might be a resolvers job, but certainly NOT a nameserver. A nameservers primary function is always to serve the requests of the client, be they for A, AAAA, NS, TXT, SPF, AFSDB, SOA, whatever RRtype the requestor desires. There again I'm using some leaps of logic to come to that conclusion, so if my leaps are wrong, please enlighten us as to what you mean by v4/v6 mixing, and why it's bad, and how anyone could even possibly be able to effect a 0-hour switch. anycast is a technical solution to providing more reliable, higher performance services, and has not a damn thing to do with address space depletion and IPv4 limitations. and therefore your statement about DNS being severely broken in IPv6 (I don't see this, I see a lack of deployment in ccTLDs especially and some TLDs, and a lack of support from registrars, but I've yet to experience any outright brokenness that can be blamed on DNS protocol, or implementations in common use) And on what planet are the root operators selling anything? They're not. In fact they're donating huge amounts of equipment and labor just so you can make what appears to be an uneducated rant. > anti-trust law. So, there are no IPv6 root nameservers. Instead, one Uh? $ dig +short aaaa f.root-servers.net 2001:500:2f::f $ dig +short aaaa a.root-servers.net 2001:503:ba3e::2:30 $ dig +short aaaa a.gtld-servers.net 2001:503:a83e::2:30 (OK that last one isn't a root nameserver at all, but more a proof) So on what internet are you on? > mixes IPv6 DNS records with IPv4 DNS records on the same nameserver. > This totally unnecessary mixing creates stability problems for both IPv4 > and IPv6. One has to remove IPv4 NS records to make room for IPv6 > records, so any effort to deploy IPv6 comes at the expense of IPv4 > stability. While bad enough, that isn't the worst part. One only has to remove IPv4 NS records if one wants to remove IPv4 support, plain and simple. They're not mutually exclusive. Not by a long shot. > > What's worse is that the DNS resolver implementations are broken as > well. One can't just create IPv6 root nameservers because the resolvers > don't do the right thing--there is no IPv6-specific resolver which could > use different root nameservers for IPv6. IPv4 and IPv6 have to be mixed > at the roots on down. Until this is fixed, IPv6 won't really be very > useful or else both won't be stable. Altering and updating resolvers on > every computer is a very time-consuming job to say the least. So, I > think IPv6 won't be taking over in 3 years, and IPv4 won't be going away > in 3 years. And you've spouted that OSI CLNS as a solution....Except last I checked the same problem would exist, worse, there's almost nothing outside of routers that actually supports OSI CLNS. And we all KNOW v6 won't suddenly take over in 3 years, and we all KNOW v4 *won't* be going away in 3 years. I don't think anyone but net.kook's have ever said anything even remotely like that. We're all going to be stuck with both for a long time. > > Its probably 10+ years to fix the resolver problem, and so a long time > before IPv6 could be ready for stable deployment outside a lab. In that > time, I'd say we could go to OSI CLNS instead, and have much less risk. > The good news is that one can work on both IPv6 and CLNS simultaneously > as completely separate stacks. Keeping CLNS separate from IPv4 this > time will improve the process of development, and improve deployment > stability later. The only modern platform I'm aware of with a broken v6 resolver is Windows XP specifically. And AFAIK it's only broken in the stance it can't use v6 transport, for places stuck with Windows boxes they can use a IPv4 RFC1918 DNS server that straddles the v4/v6 boundary until such time that Microsoft fixes it. And yes, we're all very aware it could take many years before everything is stable in v6. *HOW* does going with OSI CLNS help the matter at all? Other than divert resources. You'd still need all the other pieces. Having an agreed upon protocol and addressing scheme to go with it is only the smallest part. The hard part is all the software that *must* know about it, how to represent it, how to ask the OS to use it, how to find destinations on that address space/protocol. Are there any OSI CLNS client stacks? Seriously, the routers are a big problem, but far far far larger is the client and servers that will talk over a given protocol because there are many more implementations of those, and many more users of that software, and many more deployments of that software and hardware. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From dean at av8.com Fri Jun 6 14:38:05 2008 From: dean at av8.com (Dean Anderson) Date: Fri, 6 Jun 2008 14:38:05 -0400 (EDT) Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <7CA05D6FC904FC8EBFE18BF7@ZOP-MACTEL-3.local> Message-ID: On Fri, 6 Jun 2008, Lee Dilkie wrote: > Dean, > > I'm unsure why you think IPv6 is broken simply because the DNS > infrastructure isn't completely rolled out yet or is designed in a > fashion not to your liking. Read on, then. You may want to re-read my original message more closely. Leo Bicknell is right that the technical details are far too technical for this list. Probably far to technical for a few emails, even. We'll take a shot, though. One thing that Leo states that I think needs some clarification is this: > Fortunately DNS has also moved on. RFC 2671 specifies EDNS0, an > extension to DNS to allow for larger packets. This was later > required in RFC 3226 for all DNSSEC and A6 aware servers and > resolvers. RFC 2874 may also be of interest. Most resolvers aren't DNSSEC or EDNSO aware. There is a current proposal in the DNSEXT WG to change standards so that either TCP or EDNSO will be required. DNS standards may have moved on, or more specifically, may move on in the future. Implmentations take many years to catch up. Of course, if there are separate resolvers for IPv4 and IPv6, things get much easier to handle. Just like migrating IPv4 and Novell can mix on the same physical media without interference. Creating a separate IPv6 resolver would have allowed DNS standards to progress much faster, since you don't have upgrade IPv4 resolvers for IPv6 packet size increases, etc. Like Novell and IPv4, separate resolvers and infrastructure enable one to can access separate networks without conflicts. You shouldn't have to alter the old network to be able to use the new network. Turning off the old network shouldn't break the new network. On Fri, 6 Jun 2008, Michael Loftis wrote: > > > --On June 6, 2008 10:25:45 AM -0400 Dean Anderson wrote: > > > On Fri, 6 Jun 2008, Owen DeLong wrote: > > > >> Except you can't do name resolution if you turn off IPv4. > >> > >> I would say that's not full IPv6 support. > >> > >> I'd say that's minimal sort-of support at best. > > > > DNS is very severely broken in IPv6. This non-technical reason is that > > certain root operators want to keep their monopolies on anycast sales, > > and so (for technically inexplicable reasons), they have advocated > > mixing IPv6 and IPv4, and silenced dissent in apparent violations of > > If you can get the tens of thousands of ASs to switch to v6 on a given > 0-hour then you must be closer to some God than any of us mortals. A > solution without mixed v4/v6 is impossible right now because there are > still many people who are in the v6 world on an island compared to certain > other destinations This is mixing at a different level. Running Novell and IPv4 on the same ethernet is mixing, too. Howeverr, Novell doesn't depend on IPv4 to work. That's the problem: IPv6 depends on IPv4 to work. The IPv6 stack uses IPv4 resources. Remove, or significantly alter those resources, and breakage occurs. A clean IPv6 stack would have a separate resolver, separate servers, etc, and mix only like Novell and IP mix, now. On the physical media. A 0-hour switch is not a necessity to avoid the bad kind of mixing of stacks, any more than a migration from Novell to IPv4 must be 0-hour. > anycast is a technical solution to providing more reliable, higher > performance services, and has not a damn thing to do with address space > depletion and IPv4 limitations. In properly administered root DNS and IPv6, Anycast shouldn't (as in 'ought not to') have anything to with IPv6 DNS architecture. However, the (broken) IPv6 DNS approach does in fact keep exactly the same 13 DNS servers as before. Keeping these same servers is the only benefit of the current (broken) approach, and it only benefits the root DNS Operators who are selling Anycast DNS services. Creating a separate resolver would have allowed DNS standards to progress much faster, since you don't have upgrade IPv4 resolvers for IPv6 packet size increases, etc. Your assertion that Anycast is 'more reliable' or 'higher performance' is also not something that can be proven to be true in every DNS case, and has been proven to be false in some DNS cases. At best, the subject is controversial. The reason for the confusion is that most advocates of Anycast read RFC1546, and assert that DNS is a stateless UDP protocol. In small part, DNS is a stateless UDP protocol. However, DNS is not limited to stateless UDP service. Root servers in particular have to offer TCP services. Anycast is not reliable with TCP. This fact was plainly stated in RFC1546. In fact, Anycast is not reliable with ENDSO for similar reasons: As with TCP, ENDSO requires that state be maintained on the server end-to-end for Path MTU discovery. But RFC1546 is correct: Anycast is only suitable for stateless UDP protocols, and can benefit stateless UDP protocols. RFC3226 states: All RFC 2535 and RFC 2874 compliant entities MUST be able to handle fragmented IPv4 and IPv6 UDP packets. As Illjitsch van Beijnum pointed out a long time ago, a lost fragment due to PMTUD reply not reaching the original Anycast server is deadly to the packet. Usually people who advocate Anycast DNS or Anycast anything, particularly those who say "I'm doing anycast with no problem" are using only the stateless protocol configuration. There is more, but I'll refer you to http://www.av8.net/IETF-watch/DNSRootAnycast/History.html [This page needs to be updated with current events, and links were broken when the IETF moved some mailing list archives.] > > anti-trust law. So, there are no IPv6 root nameservers. Instead, one > > Uh? > $ dig +short aaaa f.root-servers.net > 2001:500:2f::f f.root-servers.net is an IPv4 nameservers returning an IPv6 addresses. As Leo points out, adding all the NS records for . requires a packet > 512 bytes. So what TLD operators have tried, and reported on DNSOP, is removing IPv4 A records until the packets are <=512 bytes. This affects stability of IPv4, since you are removing IPv4 nameservers for the zone. There are some problems to requiring TCP or EDNSO. Besides resolvers that don't expect >512 EDNSO responses, Anycast root servers aren't reliable for TCP or EDNSO. An IPv6 nameserver would only serve IPv6. If you change IPv6 to "Novell", you will find more sensible arguments, and you won't be so confused by IPv4 > And you've spouted that OSI CLNS as a solution....Except last I checked the > same problem would exist, worse, there's almost nothing outside of routers > that actually supports OSI CLNS. That's true. In some cases client stacks have to be written. But there is a stable OSI implementation to work out interoperability problems. IPv6 client stacks still have some interoperability problems, as Randy reported. Of course, one way around this problem, as is true of IPv6, is to proxy to interior IPv4 networks transparently, so the IPv4 client never knows its talking to OSI services. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From bicknell at ufp.org Fri Jun 6 15:18:43 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 6 Jun 2008 15:18:43 -0400 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: References: <7CA05D6FC904FC8EBFE18BF7@ZOP-MACTEL-3.local> Message-ID: <20080606191843.GA89000@ussenterprise.ufp.org> In a message written on Fri, Jun 06, 2008 at 02:38:05PM -0400, Dean Anderson wrote: > > Fortunately DNS has also moved on. RFC 2671 specifies EDNS0, an > > extension to DNS to allow for larger packets. This was later > > required in RFC 3226 for all DNSSEC and A6 aware servers and > > resolvers. RFC 2874 may also be of interest. > > Most resolvers aren't DNSSEC or EDNSO aware. While technically correct I believe this statement is misleading. Virtually none of the end-user resolver libraries (e.g. the stuff you get with your Windows, Linux, OSX or other distro) are DNSSEC or EDNS0 aware out of the box. However, those end user resolvers are often crippled in much more significant ways, such as the complete and total inability to walk up and down the DNS tree. In short, most are incapable of even knowing they need to ask the DNS root anything, much less being able to construct the query. Rather the architecture (as deployed, I don't have the time to research all the standards on the subject to know if they match reality) has created a situation where end user resolvers must point to some form of caching recursive server which has all of that logic in it. A very large percentage of those caching recursive name servers have DNSSEC and EDNS0 capability. In short, yes, 99% of end user resolvers can't make a EDNS0 query, however those same resolvers always ask a caching server to make the query for them, and 99% of the time the caching server is capable and performing those queries on behalf of the user. And I believe this is likely to be my last reply on the topic, as we are now quite far from anything that is ARIN related. For those who want to continue the discussion elsewhere, any or all of these may be appropriate: http://www.ietf.org/html.charters/dnsext-charter.html http://www.ietf.org/html.charters/dnsop-charter.html http://www.icann.org/committees/dns-root/ -- 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: 187 bytes Desc: not available URL: From dean at av8.com Fri Jun 6 16:41:40 2008 From: dean at av8.com (Dean Anderson) Date: Fri, 6 Jun 2008 16:41:40 -0400 (EDT) Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <20080606191843.GA89000@ussenterprise.ufp.org> Message-ID: On Fri, 6 Jun 2008, Leo Bicknell wrote: > In a message written on Fri, Jun 06, 2008 at 02:38:05PM -0400, Dean Anderson wrote: > > > Fortunately DNS has also moved on. RFC 2671 specifies EDNS0, an > > > extension to DNS to allow for larger packets. This was later > > > required in RFC 3226 for all DNSSEC and A6 aware servers and > > > resolvers. RFC 2874 may also be of interest. > > > > Most resolvers aren't DNSSEC or EDNSO aware. > > While technically correct I believe this statement is misleading. Well, let's see: > Virtually none of the end-user resolver libraries (e.g. the stuff > you get with your Windows, Linux, OSX or other distro) are DNSSEC > or EDNS0 aware out of the box. Yep. > However, those end user resolvers > are often crippled in much more significant ways, such as the > complete and total inability to walk up and down the DNS tree. In > short, most are incapable of even knowing they need to ask the DNS > root anything, much less being able to construct the query. Yes, all in all, things are indeed a little worse than I described, but this other breakage has been here for a while. In fact, the other breakage is just another reason that a separate IPv6 resolver would have been a good idea. There are a lot of uglies in DNS protocol that could have been wholesale dumped with a new resolver and slightly different protocol---minus the old uglies and plus the new stuff. These facts you cite enhance and improve my argument that wrong decisions were made on IPv6 DNS. These facts you cite hardly make my statements misleading. > in it. A very large percentage of those caching recursive name > servers have DNSSEC and EDNS0 capability. I'm not sure I agree. I think (also without checking the code), that djbDNS dnscache doesn't do DNSSEC or EDNSO. Indeed, perhaps the latest versions of several popular DNS caching servers do support DNSSEC. Of course, many people still run older versions of those servers that don't have support for DNSSEC. That affects the actual percentages. > In short, yes, 99% of end user resolvers can't make a EDNS0 query, > however those same resolvers always ask a caching server to make the > query for them, and 99% of the time the caching server is capable and > performing those queries on behalf of the user. Except the resolver still gets truncated data, and the supposed 1% of clients that fail is still too much to be considered reliable. I think the real unsupported percentage is probably much higher, but I won't make up numbers---there should be a way to measure this. The result is that, as I said originally: Dean Anderson wrote: > DNS is very severely broken in IPv6. This non-technical reason is that > certain root operators want to keep their monopolies on anycast sales, > and so (for technically inexplicable reasons), they have advocated > mixing IPv6 and IPv4, and silenced dissent in apparent violations of > anti-trust law. So, there are no IPv6 root nameservers. Instead, one > mixes IPv6 DNS records with IPv4 DNS records on the same nameserver. > This totally unnecessary mixing creates stability problems for both > IPv4 and IPv6. One has to remove IPv4 NS records to make room for > IPv6 records, so any effort to deploy IPv6 comes at the expense of > IPv4 stability. While bad enough, that isn't the worst part. > > What's worse is that the DNS resolver implementations are broken as > well. One can't just create IPv6 root nameservers because the > resolvers don't do the right thing--there is no IPv6-specific resolver > which could use different root nameservers for IPv6. IPv4 and IPv6 > have to be mixed at the roots on down. Until this is fixed, IPv6 > won't really be very useful or else both won't be stable. Altering > and updating resolvers on every computer is a very time-consuming job > to say the least. So, I think IPv6 won't be taking over in 3 years, > and IPv4 won't be going away in 3 years. Having drilled into the details quite a bit, my statement above still stands. None of my statements have been misleading or incorrect. Others can minimize facts to support their view, and maximize other facts, but they shouldn't be allowed to alter the facts to the point of creating a false impression that IPv6 is ready for deployment as is. The current DNS approach is fraught with avoidable problems that negatively affect the stability of IPv4. The current DNS root operators and DNS protocol definers, in fact, haven't been doing such a good job. > And I believe this is likely to be my last reply on the topic, as > we are now quite far from anything that is ARIN related. Altering the technical details are indeed beyond the scope of PPML---we can't fix any of these problems directly. But the _policy_ affected by the technical details and problems isn't beyond the scope of PPML. Policy makers ought to understand the technical details---that's necessary to make good policy. The policy makers just can't change the technical details; that's the job of others, as Leo points out. Those claiming that IPv6 is ready for widespread deployment now are simply not giving a reliable picture of the true status of IPv6; They do not cite the dissent to their view; they do not explain the problems yet to be overcome, nor do they even imply that there are significant obstacles to be overcome. We cannot adopt IPv6 policy on the basis of near-deceptions about the state of IPv6. People cannot be allowed to make unsubstantiated claims about IPv6 and its various impacts on IPv4 without being refuted. Policies cannot be adopted on the basis of such unsubstantiated assertions. My (high level) statement [quoted above] just illuminates problems that do indeed exist and usually aren't acknowledged by IPv6 promoters. [kind of like Bush Admin. didn't acknowledge dissents in intelligence data about Iraq---Indeed, NY Times today has a story that I can just about rewrite word for word, only changing a few key terms and names.] > For those who want to continue the discussion elsewhere, any or all > of these may be appropriate: Err, IPv6 public policy remains appropriate to PPML. So the high level discussion is appropriate. The lists you cite are appropriate for some kinds of discussion---perhaps actually fixing the problems I cite. But the lists you cite are not policy lists, and don't decide IPv6 policy at ARIN. IPv6 policy at ARIN is for PPML. > http://www.ietf.org/html.charters/dnsext-charter.html ^^^^ DNS Protocol definition. Our discussion isn't protocol definition. Ours is policy in light of protocol flaws. > http://www.ietf.org/html.charters/dnsop-charter.html ^^^^ Formerly included DNS root operations. There is a current effort to remove Root DNS operations from the charter. This charter change effort started in response to Anycast issues, to try to assert and then define than DNS Root Anycast problems are off-topic for DNSOP. > http://www.icann.org/committees/dns-root/ ^^^^ aka the RSSAC, closed except to root operators. Have a good weekend, --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From ipgoddess at gmail.com Fri Jun 6 19:49:17 2008 From: ipgoddess at gmail.com (Stacy Hughes) Date: Fri, 6 Jun 2008 16:49:17 -0700 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out In-Reply-To: <48484b1e.3be.59b0.23719@batelnet.bs> References: <48484b1e.3be.59b0.23719@batelnet.bs> Message-ID: <1c16a4870806061649k779c3f7ao806b699adb173f48@mail.gmail.com> I agree with Martin.While it seems to me that large ISPs are vilified for requiring more space than smaller organizations, I need to speak to the fact that they provide space to downstream customers who will _never_ qualify for PI space. We must not forget the true little guys - the /29 customers, the /28 customers - that large ISPs provide space for. This policy could effectively cheat the itty bitty guys out of legitimately needed business resources. I continue to support an organic depletion of the free pool without complication by policy specifically designed to control that process. Stacy On Thu, Jun 5, 2008 at 1:22 PM, Martin Hannigan wrote: > > ----- Original Message ----- > From: "Michael K. Smith - Adhost" > To: "Scott Leibrand" , > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > Distribution of IPv4 Resources before IPv4 Run out > Date: Wed, 21 May 2008 16:26:19 -0700 > > > Hello Scott: > > > > I'm working on a basis assumption that Extra Large > > organizations request more addresses more frequently than > > any of the other groups. So, if allocations proceed > > organically with the last IANA allocation, there is a high > > likelihood that all of the last allocation will go to the > > Extra Large organizations alone. > > Which will also filter down to other smaller guys, no? The > larger networks are fulfilling their needs so that they can > continue to grow their networks and their customers > networks. Theoretically, all that would happen is that > "smaller guys" with PI would have to resort to asking for > "PA". All considered, that's better than getting nothing or > stifling growth of others. Seems most fair to allow the > system to operate on a needs basis right to the end, IMHO. > > > 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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. > -- :):) /S -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.hannigan at batelnet.bs Fri Jun 6 22:06:16 2008 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Fri, 06 Jun 2008 22:06:16 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment Message-ID: <4849ed18.363.4008.19703@batelnet.bs> > > 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. Are there any fragements < /24 in the ARIN inventory of unallocated address space? -M< From martin.hannigan at batelnet.bs Fri Jun 6 22:06:28 2008 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Fri, 06 Jun 2008 22:06:28 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment Message-ID: <4849ed24.1ab.4009.27799@batelnet.bs> > > 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. Are there any fragements < /24 in the ARIN inventory of unallocated address space? -M< From packetgrrl at gmail.com Fri Jun 6 22:32:17 2008 From: packetgrrl at gmail.com (cja@daydream.com) Date: Fri, 6 Jun 2008 20:32:17 -0600 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: <4849ed18.363.4008.19703@batelnet.bs> References: <4849ed18.363.4008.19703@batelnet.bs> Message-ID: On Fri, Jun 6, 2008 at 8:06 PM, Martin Hannigan wrote: > > > > > > > > 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. > > > Are there any fragements < /24 in the ARIN inventory of > unallocated address space? > > Marin, yes there are. We had a discussion about it at the last ARIN meeting at the open policy hour. ----CJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.hannigan at batelnet.bs Fri Jun 6 22:30:44 2008 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Fri, 06 Jun 2008 22:30:44 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment Message-ID: <4849f2d4.1db.4182.26981@batelnet.bs> ----- Original Message ----- From: "cja at daydream.com" To: "Martin Hannigan" Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment Date: Fri, 6 Jun 2008 20:32:17 -0600 > On Fri, Jun 6, 2008 at 8:06 PM, Martin Hannigan > wrote: > > > > > > > > > > > > > > > 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. > > > > > Are there any fragements < /24 in the ARIN inventory of > > unallocated address space? > > > > > Marin, yes there are. We had a discussion about it at the > last ARIN meeting at the open policy hour. I would suggest that this policy could be improved by instead focusing it's resource requirement on utilizing those fragments. -M< From martin.hannigan at batelnet.bs Fri Jun 6 23:01:38 2008 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Fri, 06 Jun 2008 23:01:38 -0400 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe Message-ID: <4849fa12.55.432b.32511@batelnet.bs> > > Rationale: > > Currently anyone who has an experimental block is required > to re-justify his or her use after just one year. Sorry for 3 messages in 24 hours. :-) How much space is currently allocated under this policy? -M< From packetgrrl at gmail.com Fri Jun 6 23:11:26 2008 From: packetgrrl at gmail.com (cja@daydream.com) Date: Fri, 6 Jun 2008 21:11:26 -0600 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: <4849f2d4.1db.4182.26981@batelnet.bs> References: <4849f2d4.1db.4182.26981@batelnet.bs> Message-ID: > > > > > Are there any fragements < /24 in the ARIN inventory of > > > unallocated address space? > > > > > > > > Marin, yes there are. We had a discussion about it at the > > last ARIN meeting at the open policy hour. > > > I would suggest that this policy could be improved by > instead focusing it's resource requirement on utilizing > those fragments. > > > -M< Marty, I agree with you but the common argument against using those small non-contiguous blocks is that they won't be from a recognizable range that can be used in filters. ----CJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at vix.com Fri Jun 6 23:38:59 2008 From: paul at vix.com (Paul Vixie) Date: Sat, 07 Jun 2008 03:38:59 +0000 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: Your message of "Fri, 06 Jun 2008 21:11:26 CST." References: <4849f2d4.1db.4182.26981@batelnet.bs> Message-ID: <45479.1212809939@sa.vix.com> > > I would suggest that this policy could be improved by instead focusing > > it's resource requirement on utilizing those fragments. > > > > -M< > > Marty, I agree with you but the common argument against using those small > non-contiguous blocks is that they won't be from a recognizable range that > can be used in filters. > > ----CJ last time i asked routing people about it, prefix length filters were passe. but even if not, is routeability a reasonable consideration for arin policy? (if arin starts allocating these, it'd just end up killing whatever prefix length filters still exist, if any.) From owen at delong.com Sat Jun 7 18:35:59 2008 From: owen at delong.com (Owen DeLong) Date: Sat, 7 Jun 2008 15:35:59 -0700 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out In-Reply-To: <1c16a4870806061649k779c3f7ao806b699adb173f48@mail.gmail.com> References: <48484b1e.3be.59b0.23719@batelnet.bs> <1c16a4870806061649k779c3f7ao806b699adb173f48@mail.gmail.com> Message-ID: I oppose the "equitable distribution" policy because I don't believe it will create equitable distribution. However, I do support the idea of preserving a certain amount of space to be allocated as direct assignments/allocations strictly for transitional purposes. We now have a policy proposal for that which Matt and I are shepherding. I think that there needs to be a certain amount of space set aside to support transitional technologies or we may end up with a catch-22 in the end-game. Owen On Jun 6, 2008, at 4:49 PM, Stacy Hughes wrote: > I agree with Martin. > While it seems to me that large ISPs are vilified for requiring more > space than smaller organizations, I need to speak to the fact that > they provide space to downstream customers who will _never_ qualify > for PI space. We must not forget the true little guys - the /29 > customers, the /28 customers - that large ISPs provide space for. > This policy could effectively cheat the itty bitty guys out of > legitimately needed business resources. > I continue to support an organic depletion of the free pool without > complication by policy specifically designed to control that process. > Stacy > > On Thu, Jun 5, 2008 at 1:22 PM, Martin Hannigan > wrote: > > ----- Original Message ----- > From: "Michael K. Smith - Adhost" > To: "Scott Leibrand" , > > Subject: Re: [arin-ppml] Policy Proposal: Equitable > Distribution of IPv4 Resources before IPv4 Run out > Date: Wed, 21 May 2008 16:26:19 -0700 > > > Hello Scott: > > > > I'm working on a basis assumption that Extra Large > > organizations request more addresses more frequently than > > any of the other groups. So, if allocations proceed > > organically with the last IANA allocation, there is a high > > likelihood that all of the last allocation will go to the > > Extra Large organizations alone. > > Which will also filter down to other smaller guys, no? The > larger networks are fulfilling their needs so that they can > continue to grow their networks and their customers > networks. Theoretically, all that would happen is that > "smaller guys" with PI would have to resort to asking for > "PA". All considered, that's better than getting nothing or > stifling growth of others. Seems most fair to allow the > system to operate on a needs basis right to the end, IMHO. > > > 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 the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. > > > > -- > :):) > /S > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sat Jun 7 18:38:11 2008 From: owen at delong.com (Owen DeLong) Date: Sat, 7 Jun 2008 15:38:11 -0700 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: <4849f2d4.1db.4182.26981@batelnet.bs> References: <4849f2d4.1db.4182.26981@batelnet.bs> Message-ID: > I would suggest that this policy could be improved by > instead focusing it's resource requirement on utilizing > those fragments. > I would suggest that those fragments will probably get used anyway and that reserving a /10 for transitional technologies is far from unreasonable. Owen From packetgrrl at gmail.com Sat Jun 7 19:15:32 2008 From: packetgrrl at gmail.com (cja@daydream.com) Date: Sat, 7 Jun 2008 17:15:32 -0600 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: <45479.1212809939@sa.vix.com> References: <4849f2d4.1db.4182.26981@batelnet.bs> <45479.1212809939@sa.vix.com> Message-ID: Paul, I think the little non-contiguous blocks should be used for this. I brought it up at the meeting and I was shot down by folks who felt that it needed to be contiguous so that it can be filtered appropriately. It must not be passe for some folks :-) ----Cathy On Fri, Jun 6, 2008 at 9:38 PM, Paul Vixie wrote: > > > I would suggest that this policy could be improved by instead focusing > > > it's resource requirement on utilizing those fragments. > > > > > > -M< > > > > Marty, I agree with you but the common argument against using those small > > non-contiguous blocks is that they won't be from a recognizable range > that > > can be used in filters. > > > > ----CJ > > last time i asked routing people about it, prefix length filters were > passe. > > but even if not, is routeability a reasonable consideration for arin > policy? > (if arin starts allocating these, it'd just end up killing whatever prefix > length filters still exist, if any.) > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at vix.com Sat Jun 7 21:35:22 2008 From: paul at vix.com (Paul Vixie) Date: Sun, 08 Jun 2008 01:35:22 +0000 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: Your message of "Sat, 07 Jun 2008 17:15:32 CST." References: <4849f2d4.1db.4182.26981@batelnet.bs> <45479.1212809939@sa.vix.com> Message-ID: <84853.1212888922@sa.vix.com> cathy, you wrote: > I think the little non-contiguous blocks should be used for this. I brought > it up at the meeting and I was shot down by folks who felt that it needed to > be contiguous so that it can be filtered appropriately. It must not be > passe for some folks :-) it seems possible that a lot of people think that others are doing prefix length filtering, but that only a few people, or nobody, is actually doing it. the policy process should be informed somehow. any idea how we can objectively measure this, like a poll of operators in the region, or a poll of operators worldwide, or some kind of ping test using source addresses in various small prefixes, or some combination? if the AC can design and accept experiments that would inform this policy, i feel sure that we could get the experiments run by various nonpartisans with expertise in the area. paul From ljb at merit.edu Sat Jun 7 21:50:05 2008 From: ljb at merit.edu (Larry J. Blunk) Date: Sat, 07 Jun 2008 21:50:05 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: <84853.1212888922@sa.vix.com> References: <4849f2d4.1db.4182.26981@batelnet.bs> <45479.1212809939@sa.vix.com> <84853.1212888922@sa.vix.com> Message-ID: <484B3ACD.5060604@merit.edu> Paul Vixie wrote: > cathy, you wrote: > > >> I think the little non-contiguous blocks should be used for this. I brought >> it up at the meeting and I was shot down by folks who felt that it needed to >> be contiguous so that it can be filtered appropriately. It must not be >> passe for some folks :-) >> > > it seems possible that a lot of people think that others are doing prefix > length filtering, but that only a few people, or nobody, is actually doing > it. the policy process should be informed somehow. any idea how we can > objectively measure this, like a poll of operators in the region, or a poll > of operators worldwide, or some kind of ping test using source addresses in > various small prefixes, or some combination? if the AC can design and accept > experiments that would inform this policy, i feel sure that we could get the > experiments run by various nonpartisans with expertise in the area. > > paul > Renesys did a lightning talk on this topic at NANOG 41 -- http://www.nanog.org/mtg-0710/presentations/renesys-lighting.pdf They have a page with a few provider's policies. Both AT&T and Level3 have a /24 limit. -Larry From alain_durand at cable.comcast.com Sat Jun 7 22:11:11 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Sat, 07 Jun 2008 22:11:11 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitateIPv6 deployment In-Reply-To: <84853.1212888922@sa.vix.com> Message-ID: On 6/7/08 9:35 PM, "Paul Vixie" wrote: > it seems possible that a lot of people think that others are doing prefix > length filtering, but that only a few people, or nobody, is actually doing > it. the policy process should be informed somehow. any idea how we can > objectively measure this, like a poll of operators in the region, or a poll > of operators worldwide, or some kind of ping test using source addresses in > various small prefixes, or some combination? Paul, It seems that the recent incident with youtube showed that anouncements longer than /24 do not get through... So, apparently a large enough number of people today are using filters that acknowledging it in a policy proposal makes sense. - Alain. From paul at vix.com Sat Jun 7 22:13:21 2008 From: paul at vix.com (Paul Vixie) Date: Sun, 08 Jun 2008 02:13:21 +0000 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: Your message of "Sat, 07 Jun 2008 21:50:05 -0400." <484B3ACD.5060604@merit.edu> References: <4849f2d4.1db.4182.26981@batelnet.bs> <45479.1212809939@sa.vix.com> <84853.1212888922@sa.vix.com> <484B3ACD.5060604@merit.edu> Message-ID: <86051.1212891201@sa.vix.com> > > ... if the AC can design and accept experiments that would inform this > > policy, i feel sure that we could get the experiments run by various > > nonpartisans with expertise in the area. > > > > paul > > Renesys did a lightning talk on this topic at NANOG 41 -- > . They > have a page with a few provider's policies. Both AT&T and Level3 have a /24 > limit. > > -Larry do we expect these policies to remain in force, or loosen, or tighten, after iana runout occurs and there is pressure to further deaggregate the ipv4 space and fill in all these little holes? (and if so, why, or if not, why not?) i think that the industry's early reaction to iana runout and/or RIR runout will be to loosen filters since a lot of address blocks and therefore a lot of potential customers would be hidden by the filters described above (/24) and the initial desire will be to continue growing since a lot of the big guys have megaroute cores. competition of the form "i'll charge you less but i'll have to NAT you" won't always win vs. competition of the form "i'll charge you the same, or i'll charge you more, but i won't NAT you." smaller ISP's without megaroute cores won't have good leverage if they want to ignore these routes. hierarchical routing, as a principle, will take an arrow in the neck, and won't return until non-hierarchical growth proves measureably impossible. what do others think? From alain_durand at cable.comcast.com Sat Jun 7 22:17:25 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Sat, 07 Jun 2008 22:17:25 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitateIPv6 deployment In-Reply-To: Message-ID: On 6/7/08 7:15 PM, "cja at daydream.com" wrote: > Paul, > > I think the little non-contiguous blocks should be used for this. I brought it > up at the meeting and I was shot down by folks who felt that it needed to be > contiguous so that it can be filtered appropriately. It must not be passe for > some folks :-) > > ----Cathy Cathy, Your input at the meeting was very valuable and I took it into account when crafting this proposal. Initially, I was suggesting using the entire last /8. The current text talks about reserving only a /10. I thought it could be a good compromise, not reserving too much contiguous space while still accommodating people using prefix length filters. - Alain. From alain_durand at cable.comcast.com Sat Jun 7 22:28:27 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Sat, 07 Jun 2008 22:28:27 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitateIPv6 deployment In-Reply-To: <86051.1212891201@sa.vix.com> Message-ID: On 6/7/08 10:13 PM, "Paul Vixie" wrote: > i think that the industry's early reaction to iana runout and/or RIR runout > will be to loosen filters since a lot of address blocks and therefore a lot > of potential customers would be hidden by the filters described above (/24) > and the initial desire will be to continue growing since a lot of the big guys > have megaroute cores. competition of the form "i'll charge you less but i'll > have to NAT you" won't always win vs. competition of the form "i'll charge > you the same, or i'll charge you more, but i won't NAT you." smaller ISP's > without megaroute cores won't have good leverage if they want to ignore these > routes. hierarchical routing, as a principle, will take an arrow in the neck, > and won't return until non-hierarchical growth proves measureably impossible. > > what do others think? My personal opinion is that we have to make policies using the best *current* knowledge of how routing works. Filters on prefix length exists *today* and we must take them into account. If those filters go away in the future and the internet goes to flat route every single /28 or so, that is about 250 million routes... We all would be in a much different place. Knowing what we know about the current generation routers, it seems prudent to craft policies that not only do not have too negative an effect on routing table size, but also care about ACL size. - Alain. From paul at vix.com Sun Jun 8 00:56:11 2008 From: paul at vix.com (Paul Vixie) Date: Sun, 08 Jun 2008 04:56:11 +0000 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitateIPv6 deployment In-Reply-To: Your message of "Sat, 07 Jun 2008 22:28:27 -0400." References: Message-ID: <91130.1212900971@sa.vix.com> > > what do others think? > > My personal opinion is that we have to make policies using the best > *current* knowledge of how routing works. Filters on prefix length exists > *today* and we must take them into account. If those filters go away in the > future and the internet goes to flat route every single /28 or so, that is > about 250 million routes... We all would be in a much different place. under that reasoning, would there also be no IPv6 PI? would there be any PI, even for multihomers? would address blocks only be handed out to folks with intercontinental backbones whose intent was to use this address space for their customers? if not, why not? where are you choosing to draw the line and say, here we'll care about how routing works, but beyond this we won't? current policies and current proposed policies including relaxed transfers will yield a megaroute core years before that's cheap enough for current tier-1 and tier-2 let alone tier-3 and enterprise multihomers. and i don't actually feel all that sure that a megaroute core would work even if everybody could afford the CAM; that size DAG with no hold-down and no hold-up and current churn rates scares me and will scare me until some math weenie graph theorist explains why it would be ok. > Knowing what we know about the current generation routers, it seems prudent > to craft policies that not only do not have too negative an effect on > routing table size, but also care about ACL size. do you want folks to be able to say, "hey, you should accept our route, it's in an arin policy?" and do you think this will make some difference? and yet you think the industry should resist the siren call of revenue that comes from /28 multihomers hoping to avoid provider lock-in in a post-iana-pool world? From martin.hannigan at batelnet.bs Sun Jun 8 02:33:31 2008 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Sun, 08 Jun 2008 02:33:31 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment Message-ID: <484b7d3b.3c3.1d52.31350@batelnet.bs> ----- Original Message ----- From: Paul Vixie To: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment Date: Sat, 07 Jun 2008 03:38:59 +0000 > > > I would suggest that this policy could be improved by > > > instead focusing it's resource requirement on > > utilizing those fragments. > > > > -M< > > > > Marty, I agree with you but the common argument against > > using those small non-contiguous blocks is that they > > won't be from a recognizable range that can be used in > > filters. > > ----CJ > > last time i asked routing people about it, prefix length > filters were passe. > > but even if not, is routeability a reasonable > consideration for arin policy? (if arin starts allocating > these, it'd just end up killing whatever prefix length > filters still exist, if any.) The policy proposal itself inferred that < /24 was ok to allocate. Expecting a set aside of the last /8 is unreasonable. -M< From martin.hannigan at batelnet.bs Sun Jun 8 02:44:33 2008 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Sun, 08 Jun 2008 02:44:33 -0400 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out Message-ID: <484b7fd1.30e.1e12.19186@batelnet.bs> ----- Original Message ----- From: Owen DeLong To: Stacy Hughes Cc: "Martin Hannigan" , arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out Date: Sat, 7 Jun 2008 15:35:59 -0700 > I oppose the "equitable distribution" policy because I > don't believe it will create equitable distribution. Oh? How so? [ clip ] > I think that there needs to be a certain amount of space > set aside to support transitional technologies or we may > end up with a catch-22 in the end-game. Again, in the end-game, why wouldn't PA be sufficient? -M< From martin.hannigan at batelnet.bs Sun Jun 8 02:52:48 2008 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Sun, 08 Jun 2008 02:52:48 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment Message-ID: <484b81c0.24b.1e9a.9050@batelnet.bs> ----- Original Message ----- From: "Martin Hannigan" To: Paul Vixie , arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment Date: Sun, 08 Jun 2008 02:33:31 -0400 > ----- Original Message ----- > From: Paul Vixie > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Dedicated IPv4 > block to facilitate IPv6 deployment > Date: Sat, 07 Jun 2008 03:38:59 +0000 > > > > > I would suggest that this policy could be improved > > > > by instead focusing it's resource requirement on > > > utilizing those fragments. > > > > > -M< > > > > > > Marty, I agree with you but the common argument > > > against using those small non-contiguous blocks is > > > that they won't be from a recognizable range that can > > > be used in filters. > > > ----CJ > > > > last time i asked routing people about it, prefix length > > filters were passe. > > > > but even if not, is routeability a reasonable > > consideration for arin policy? (if arin starts > > allocating these, it'd just end up killing whatever > > prefix length filters still exist, if any.) > > The policy proposal itself inferred that < /24 was ok to > allocate. > > Expecting a set aside of the last /8 is unreasonable. > Please allow me to adjust this comment slightly. Expecting a set aside from within the last /8 is unreasonable. -M< From owen at delong.com Sun Jun 8 03:32:49 2008 From: owen at delong.com (Owen DeLong) Date: Sun, 8 Jun 2008 00:32:49 -0700 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: <86051.1212891201@sa.vix.com> References: <4849f2d4.1db.4182.26981@batelnet.bs> <45479.1212809939@sa.vix.com> <84853.1212888922@sa.vix.com> <484B3ACD.5060604@merit.edu> <86051.1212891201@sa.vix.com> Message-ID: On Jun 7, 2008, at 7:13 PM, Paul Vixie wrote: >>> ... if the AC can design and accept experiments that would inform >>> this >>> policy, i feel sure that we could get the experiments run by various >>> nonpartisans with expertise in the area. >>> >>> paul >> >> Renesys did a lightning talk on this topic at NANOG 41 -- >> > lighting.pdf>. They >> have a page with a few provider's policies. Both AT&T and Level3 >> have a /24 >> limit. >> >> -Larry > > do we expect these policies to remain in force, or loosen, or > tighten, after > iana runout occurs and there is pressure to further deaggregate the > ipv4 space > and fill in all these little holes? (and if so, why, or if not, why > not?) > I would expect that initially, they will loosen, but, then as it becomes harder to deal with the tide of increasing route table entries, they will again tighten. I think there will continue to be various forms of economic and technical pressures that create a sort of shove-of- war (hard to call it a tug in this case as all push and no pull). I think that situation will persist and potentially become worse until we reach the point where people start to remove their IPv4 deployments. I don't expect that to be any time soon. > i think that the industry's early reaction to iana runout and/or RIR > runout > will be to loosen filters since a lot of address blocks and > therefore a lot > of potential customers would be hidden by the filters described > above (/24) > and the initial desire will be to continue growing since a lot of > the big guys > have megaroute cores. competition of the form "i'll charge you less > but i'll > have to NAT you" won't always win vs. competition of the form "i'll > charge > you the same, or i'll charge you more, but i won't NAT you." > smaller ISP's > without megaroute cores won't have good leverage if they want to > ignore these > routes. hierarchical routing, as a principle, will take an arrow in > the neck, > and won't return until non-hierarchical growth proves measureably > impossible. > I'd say that's about the same as my prediction. The one potential difference being that I think the cycle to get to where restrictions are increasing will only be 6-12 months after the first big RIR exhaustion. Owen From owen at delong.com Sun Jun 8 03:42:41 2008 From: owen at delong.com (Owen DeLong) Date: Sun, 8 Jun 2008 00:42:41 -0700 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out In-Reply-To: <484b7fd1.30e.1e12.19186@batelnet.bs> References: <484b7fd1.30e.1e12.19186@batelnet.bs> Message-ID: <75E160FF-F14A-43B0-A2EE-954CA3FCCC30@delong.com> On Jun 7, 2008, at 11:44 PM, Martin Hannigan wrote: > > ----- Original Message ----- > From: Owen DeLong > To: Stacy Hughes > Cc: "Martin Hannigan" , > arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Equitable > Distribution of IPv4 Resources before IPv4 Run out > Date: Sat, 7 Jun 2008 15:35:59 -0700 > >> I oppose the "equitable distribution" policy because I >> don't believe it will create equitable distribution. > > > Oh? How so? > Because it will create an unfair disadvantage to the larger providers for no reason other than the fact that they are larger. Indeed, I think that need-based allocation down to the end with the exception of a reservation for transitional technologies is the best proposed end-game so far. > [ clip ] > >> I think that there needs to be a certain amount of space >> set aside to support transitional technologies or we may >> end up with a catch-22 in the end-game. > > > Again, in the end-game, why wouldn't PA be sufficient? > Because I believe that some of the people who will need this space may well be the providers that would assign it, and, some will be their customers in a day when they have nothing left to assign. I'd rather count on ARIN reserving a certain amount of space for this purpose (one organization I can trust and watch) vs. depending on EVERY provider to do so (may organizations which are opaque and hard to watch and several of which have proven repeatedly that they are not trustworthy). Owen From bmanning at vacation.karoshi.com Sun Jun 8 07:34:44 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 8 Jun 2008 11:34:44 +0000 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: <86051.1212891201@sa.vix.com> References: <4849f2d4.1db.4182.26981@batelnet.bs> <45479.1212809939@sa.vix.com> <84853.1212888922@sa.vix.com> <484B3ACD.5060604@merit.edu> <86051.1212891201@sa.vix.com> Message-ID: <20080608113444.GA676@vacation.karoshi.com.> > > what do others think? > _______________________________________________ this other thinks that a reserved chunk of v4 space to carve out /28's and /30's for NATPT functionality is a compromise. A step in the right direction. presuming (facts not in evidence) that address return/reuse will occur (your favorite "market" proposal goes here) - then we will see more and more interstitial gaps that are not covered by a /22 minimum allocation size. the -only- way to use them would be to then expand the "this is the reserved block for tiny spaces" to include those other parts of the v4 space -outside- the reserved block. and yes, heirarchical routing takes an arrow to the neck. --bill From reid at mejac.palo-alto.ca.us Sun Jun 8 08:55:38 2008 From: reid at mejac.palo-alto.ca.us (Brian Reid) Date: Sun, 08 Jun 2008 05:55:38 -0700 Subject: [arin-ppml] simple question about money Message-ID: <546210EA466CA8FBDBD412AC@Visible-Trout.local> Given how much IPv6 address space exists, why is it so damned expensive? I decided it was time to turn up IPv6 connectivity to my world, but when I went to look at prices for buying even a small block of portable address space I realized I couldn't afford it. Given that this is a fictitious resource, and that there is no intrinsic cost, ARIN should be charging about 1/100th of their listed prices for it. Is there a legitimate reason for the ultra-high prices? Is ARIN owned by Prada? Brian Reid From bicknell at ufp.org Sun Jun 8 10:04:26 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 8 Jun 2008 10:04:26 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: <84853.1212888922@sa.vix.com> References: <4849f2d4.1db.4182.26981@batelnet.bs> <45479.1212809939@sa.vix.com> <84853.1212888922@sa.vix.com> Message-ID: <20080608140425.GC17568@ussenterprise.ufp.org> In a message written on Sun, Jun 08, 2008 at 01:35:22AM +0000, Paul Vixie wrote: > it seems possible that a lot of people think that others are doing prefix > length filtering, but that only a few people, or nobody, is actually doing > it. the policy process should be informed somehow. any idea how we can First we need to think about the different cases: 1) How many networks prefix filter customers... strictly based on their allocation? allowing between their allocation and a /24? allowing anything inside their allocation? 2) How many networks accept longer routes from customers than they will pass along to their peers? 2) How many networks prefix filter peers... strictly based on their allocation? allowing between their allocation and a /24? allowing anything inside their allocation? allowing based on RIR published minimum allocation sizes? For instance, if you believed 99% of the networks filtered on RIR minimum published size, it's likely if the RIR's gave out /28's they would allow it. However, if you believe 99% of the networks filter at a /24 boundry, that would not be the case. The generic question "do you prefix list filter" does not provide enough information to make informed decisions. -- 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: 187 bytes Desc: not available URL: From BillD at cait.wustl.edu Sun Jun 8 10:20:05 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Sun, 8 Jun 2008 09:20:05 -0500 Subject: [arin-ppml] simple question about money References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> Message-ID: $1250 (x small allocation)per year with a 90% waiver through 2008.... = $125. Wow. Your right that IS expensive.... In 2012 you'd have to pony up the whole $100 per month. bd -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Brian Reid Sent: Sun 6/8/2008 7:55 AM To: ppml at arin.net Subject: [arin-ppml] simple question about money Given how much IPv6 address space exists, why is it so damned expensive? I decided it was time to turn up IPv6 connectivity to my world, but when I went to look at prices for buying even a small block of portable address space I realized I couldn't afford it. Given that this is a fictitious resource, and that there is no intrinsic cost, ARIN should be charging about 1/100th of their listed prices for it. Is there a legitimate reason for the ultra-high prices? Is ARIN owned by Prada? Brian Reid _______________________________________________ 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bmanning at vacation.karoshi.com Sun Jun 8 10:31:21 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 8 Jun 2008 14:31:21 +0000 Subject: [arin-ppml] simple question about money In-Reply-To: <546210EA466CA8FBDBD412AC@Visible-Trout.local> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> Message-ID: <20080608143121.GA1890@vacation.karoshi.com.> On Sun, Jun 08, 2008 at 05:55:38AM -0700, Brian Reid wrote: > Given how much IPv6 address space exists, why is it so damned expensive? I decided it was time to turn up IPv6 connectivity to my world, but when I went to look at prices for buying even a small block of portable address space I realized I couldn't afford it. > > Given that this is a fictitious resource, and that there is no intrinsic cost, ARIN should be charging about 1/100th of their listed prices for it. Is there a legitimate reason for the ultra-high prices? Is ARIN owned by Prada? > > Brian Reid actually Brian, its not for sale. what you pay for is registration services to ensure uniqueness. You might want to verify this with others. --bill > > > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From reid at mejac.palo-alto.ca.us Sun Jun 8 10:46:34 2008 From: reid at mejac.palo-alto.ca.us (Brian Reid) Date: Sun, 08 Jun 2008 07:46:34 -0700 Subject: [arin-ppml] simple question about money In-Reply-To: <20080608143121.GA1890@vacation.karoshi.com.> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <20080608143121.GA1890@vacation.karoshi.com.> Message-ID: <57E0EC0682885176731FABBA@Visible-Trout.local> Sale, rent, whatever. It's $1000/year that I'll have to pay to use IPv6. I know there are fee waivers in the beginning, but I don't care about the beginning. I care about the long term, and committing to $1000/year long term for the use of something that cannot possibly cost more than $10/year is, in my opinion, bordering on criminal. You will not convince me that it costs more than about $10/year to do all of the administrative processing needed to remember that I am the authorized user of that portion of the address space. If I were the only user, then, yes, the cost of maintaining an administrative staff would be more than $10/year. But in the fullness of time there ought to be millions of people using it, and tens of millions a year is the kind of thing that I expect ICANN to spend, not ARIN. When you finish making fun of me for asking the question, it would be good to have a factual answer. Pompous assertions that I must be ignorant else I would understand why they have to charge so much are neither factual nor answers. From reid at mejac.palo-alto.ca.us Sun Jun 8 10:48:33 2008 From: reid at mejac.palo-alto.ca.us (Brian Reid) Date: Sun, 08 Jun 2008 07:48:33 -0700 Subject: [arin-ppml] simple question about money In-Reply-To: <484BEBCA.40204@ttec.com> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <484BEBCA.40204@ttec.com> Message-ID: <5161610C82C568A6A4B56BD8@Visible-Trout.local> I can understand a fairly high one-time cost to help deal with these issues. But not a high annual fee. Charging an up-front fee of $5000 to register the block and then $10/year to cover the occasional operational expenses makes sense to me. $1000/year does not. > - scarcity barrier > > - frivolity barrier > > - hoarding barrier > > - operational expenses From randy at psg.com Sun Jun 8 10:50:43 2008 From: randy at psg.com (Randy Bush) Date: Sun, 08 Jun 2008 23:50:43 +0900 Subject: [arin-ppml] simple question about money In-Reply-To: <57E0EC0682885176731FABBA@Visible-Trout.local> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <20080608143121.GA1890@vacation.karoshi.com.> <57E0EC0682885176731FABBA@Visible-Trout.local> Message-ID: <484BF1C3.20007@psg.com> brian, you have an employment conflict of interest, vixie being a non-trivial and typically vixie religious player in the game of maintaining the RIRs' bloated position leasing integers. otherwise, we should talk. the bottom line is how much is an x.509 certificate and an in-addr.arpa entry worth? randy From james at towardex.com Sun Jun 8 10:53:44 2008 From: james at towardex.com (James Jun) Date: Sun, 8 Jun 2008 10:53:44 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <57E0EC0682885176731FABBA@Visible-Trout.local> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local><20080608143121.GA1890@vacation.karoshi.com.> <57E0EC0682885176731FABBA@Visible-Trout.local> Message-ID: <038301c8c977$735bdaf0$12fc5dd8@HCMC.local> Brian, If you are an existing IPv4 customer of ARIN, with a direct allocation, then you only pay the higher of the two protocols per year for maintenance. For example, if you currently pay $2250/yr for a /20 IPv4 block, the /32 IPv6 block at same fee is provided to you free of charge (assuming your org can qualify for a /32 via the usual justification process). I think it's a very reasonable policy, as long as you are an IPv4 subscriber of ARIN, you get to obtain equivalently priced/categorized IPv6 address space without incurring additional costs. If you are not an IPv4 customer of ARIN, think of the money that's being paid as part of General Membership fee as opposed to paying for just IPv6 addresses. Everyone holding non-legacy IPv4 address blocks is paying a fee for keep-up of ARIN operations every year, so it makes sense for new IPv6 holders to do the same, if they are not an existing IPv4 customer. Hope this helps clarify some of your concerns. james > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Brian Reid > Sent: Sunday, June 08, 2008 10:47 AM > To: ppml at arin.net > Subject: Re: [arin-ppml] simple question about money > > Sale, rent, whatever. It's $1000/year that I'll have to pay to use IPv6. I > know there are fee waivers in the beginning, but I don't care about the > beginning. I care about the long term, and committing to $1000/year long > term for the use of something that cannot possibly cost more than $10/year > is, in my opinion, bordering on criminal. > > You will not convince me that it costs more than about $10/year to do all > of the administrative processing needed to remember that I am the > authorized user of that portion of the address space. If I were the only > user, then, yes, the cost of maintaining an administrative staff would be > more than $10/year. But in the fullness of time there ought to be millions > of people using it, and tens of millions a year is the kind of thing that > I expect ICANN to spend, not ARIN. > > When you finish making fun of me for asking the question, it would be good > to have a factual answer. Pompous assertions that I must be ignorant else > I would understand why they have to charge so much are neither factual nor > answers. > > > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. From baptista at publicroot.org Sun Jun 8 11:09:00 2008 From: baptista at publicroot.org (Joe Baptista) Date: Sun, 8 Jun 2008 11:09:00 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <546210EA466CA8FBDBD412AC@Visible-Trout.local> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> Message-ID: <874c02a20806080809g5fda6a38md43295791a6c1991@mail.gmail.com> On Sun, Jun 8, 2008 at 8:55 AM, Brian Reid wrote: > Given how much IPv6 address space exists, why is it so damned expensive? I > decided it was time to turn up IPv6 connectivity to my world, but when I > went to look at prices for buying even a small block of portable address > space I realized I couldn't afford it. a lot of people feel just like you. they want to try out ipv6 - but when they realize the resource costs they quickly shy away for various reasons all associated with the extraordinary cost - which simply can't be justified. > Given that this is a fictitious resource, and that there is no intrinsic > cost, ARIN should be charging about 1/100th of their listed prices for it. > Is there a legitimate reason for the ultra-high prices? Is ARIN owned by > Prada? Of course there is no legitimate reasons for the ultra-high prices. It is simply a question of how much they can get away with before the community gives them the finger. Which I think it already has by rejecting ipv6 as a viable vehicle. If I were IANA Iwould be giving away allocations just to get people moving on the transition to ipv6. The goal to ensure every user has their own ipv6 allocations. regards joe baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium ---------------------------------------------------------------- The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. ---------------------------------------------------------------- Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 -------------- next part -------------- An HTML attachment was scrubbed... URL: From reid at mejac.palo-alto.ca.us Sun Jun 8 11:12:02 2008 From: reid at mejac.palo-alto.ca.us (Brian Reid) Date: Sun, 08 Jun 2008 08:12:02 -0700 Subject: [arin-ppml] simple question about money In-Reply-To: <038301c8c977$735bdaf0$12fc5dd8@HCMC.local> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local><20080608143121.GA1890@vacation.karoshi.com.> <57E0EC0682885176731FABBA@Visible-Trout.local> <038301c8c977$735bdaf0$12fc5dd8@HCMC.local> Message-ID: <8B8C02266896172CE602604F@Visible-Trout.local> > Hope this helps clarify some of your concerns. Nope. All it does is tell me that I should be happy to pay big chunks of money for a service that almost nobody wants. Which I'm not. From bmanning at vacation.karoshi.com Sun Jun 8 11:33:34 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 8 Jun 2008 15:33:34 +0000 Subject: [arin-ppml] simple question about money In-Reply-To: <57E0EC0682885176731FABBA@Visible-Trout.local> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <20080608143121.GA1890@vacation.karoshi.com.> <57E0EC0682885176731FABBA@Visible-Trout.local> Message-ID: <20080608153334.GB1890@vacation.karoshi.com.> On Sun, Jun 08, 2008 at 07:46:34AM -0700, Brian Reid wrote: > Sale, rent, whatever. It's $1000/year that I'll have to pay to use IPv6. I know there are fee waivers in the beginning, but I don't care about the beginning. I care about the long term, and committing to $1000/year long term for the use of something that cannot possibly cost more than $10/year is, in my opinion, bordering on criminal. > > You will not convince me that it costs more than about $10/year to do all of the administrative processing needed to remember that I am the authorized user of that portion of the address space. If I were the only user, then, yes, the cost of maintaining an administrative staff would be more than $10/year. But in the fullness of time there ought to be millions of people using it, and tens of millions a year is the kind of thing that I expect ICANN to spend, not ARIN. it may not take more than 10/yr to track that you are who you (still) say you are and are tied to the resources we think you are responsible for. Randy was on the right track w/ the x509, whois, and DNS services. that said, ARIN does a bit more than act as a title office. stuff our members ask us to do. that stuff costs and members -to date- are willing to pay for it. arin does not have millions of members, even though there are millions of folks using IP space. unclear that arin will -ever- have millions of users. Heirarchy is a good thing. > > When you finish making fun of me for asking the question, it would be good to have a factual answer. Pompous assertions that I must be ignorant else I would understand why they have to charge so much are neither factual nor answers. not making fun or being pompus, or infering that you are ignorant. simply correcting a factual error. Addresses are not for sale. If couched in terms of, "why is the fee scheduled the way it is?" and "how can an individual member adjust the fee schedule?" then those are reasonable questions. --bill > > > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From bicknell at ufp.org Sun Jun 8 11:44:27 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 8 Jun 2008 11:44:27 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <57E0EC0682885176731FABBA@Visible-Trout.local> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <20080608143121.GA1890@vacation.karoshi.com.> <57E0EC0682885176731FABBA@Visible-Trout.local> Message-ID: <20080608154427.GA26108@ussenterprise.ufp.org> In a message written on Sun, Jun 08, 2008 at 07:46:34AM -0700, Brian Reid wrote: > Sale, rent, whatever. It's $1000/year that I'll have to pay to > use IPv6. I know there are fee waivers in the beginning, but I don't > care about the beginning. I care about the long term, and committing > to $1000/year long term for the use of something that cannot possibly > cost more than $10/year is, in my opinion, bordering on criminal. Sent privately, but since Brian wants to air the complaint in public, I'll resend to the list. ARIN Provides many services to those who obtain addresses from ARIN: - Running the whois database. - Running reverse DNS servers. - Processing SWIP's. - Running twice yearly public policy meetings. - Running mailing lists like ppml, arin-discuss. - Maintianing a web site with all the information you need on it. - Staff to run all of the above. - Accountants to send you a bill and process it. - People to participate in the Internet Governance process to make sure you can get space from ARIN and it isn't given all to your local monopoly PTT or worse, a government agency. And many other things I'm sure I forgot. An end user like Brian might want to step up and say "But I don't ever change my whois or in-addr entries, and I don't do swips, and I choose not to come to the public policy meetings, and I don't participate on the mailing list except when the fees annoy me and I didn't ask anyone to go to a WSIS meeting on my behalf and......." However, those who do pay fees to ARIN have generally decided that all of those things are "in the public good" and contribute to a stable, scaleable, secure Internet which means that people like Brian have a place where they can use their prefixes. The community has also decided that an a-la cart model is not attractive. Just to put Brian's $10 in context. Per http://www.arin.net/meetings/minutes/ARIN_XXI/PDF/wednesday/MSD_Hamlin.pdf ARIN has 3055 total members as of 3/31/08. If each of them paid $10, that would be $30,055 dollars. I'd like Brian to tell us how ARIN could function on $30k per year. -- 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: 187 bytes Desc: not available URL: From jradel at vantage.com Sun Jun 8 12:17:36 2008 From: jradel at vantage.com (Jon Radel) Date: Sun, 08 Jun 2008 12:17:36 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <546210EA466CA8FBDBD412AC@Visible-Trout.local> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> Message-ID: <484C0620.7040201@vantage.com> Brian Reid wrote: > Given how much IPv6 address space exists, why is it so damned expensive? I decided it was time to turn up IPv6 connectivity to my world, but when I went to look at prices for buying even a small block of portable address space I realized I couldn't afford it. > > Or you could just view it as economic incentive to not use portable address space when turning up IPv6 connectivity to your little corner of the world. I've got two /48s that work fine and are free that I use for my personal little testbed and playground. Of course, they're not the least bit portable. --Jon Radel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3303 bytes Desc: S/MIME Cryptographic Signature URL: From ccaputo at alt.net Sun Jun 8 12:51:50 2008 From: ccaputo at alt.net (Chris Caputo) Date: Sun, 8 Jun 2008 16:51:50 +0000 (UTC) Subject: [arin-ppml] simple question about money In-Reply-To: <20080608154427.GA26108@ussenterprise.ufp.org> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <20080608143121.GA1890@vacation.karoshi.com.> <57E0EC0682885176731FABBA@Visible-Trout.local> <20080608154427.GA26108@ussenterprise.ufp.org> Message-ID: On Sun, 8 Jun 2008, Leo Bicknell wrote: > In a message written on Sun, Jun 08, 2008 at 07:46:34AM -0700, Brian Reid wrote: > > Sale, rent, whatever. It's $1000/year that I'll have to pay to > > use IPv6. I know there are fee waivers in the beginning, but I don't > > care about the beginning. I care about the long term, and committing > > to $1000/year long term for the use of something that cannot possibly > > cost more than $10/year is, in my opinion, bordering on criminal. > [...] > > An end user like Brian might want to step up and say "But I don't > ever change my whois or in-addr entries, and I don't do swips, and > I choose not to come to the public policy meetings, and I don't > participate on the mailing list except when the fees annoy me and > I didn't ask anyone to go to a WSIS meeting on my behalf and......." If Brian is an end-user, the minimum (/41 to /48) cost for IPv6 assignment is a one-time $1,250 plus max $100/year after the first year for this and any other ARIN end-user/assigned resources. No introductory price schedule for IPv6 for end-users/assignments, whereas there is one for ISPs/allocations. Chris From paul at vix.com Sun Jun 8 13:04:05 2008 From: paul at vix.com (Paul Vixie) Date: Sun, 08 Jun 2008 17:04:05 +0000 Subject: [arin-ppml] simple question about money In-Reply-To: Your message of "Sun, 08 Jun 2008 11:09:00 -0400." <874c02a20806080809g5fda6a38md43295791a6c1991@mail.gmail.com> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <874c02a20806080809g5fda6a38md43295791a6c1991@mail.gmail.com> Message-ID: <13324.1212944645@sa.vix.com> > If I were IANA Iwould be giving away allocations just to get people moving > on the transition to ipv6. The goal to ensure every user has their own ipv6 > allocations. because the internet routing system's physics require that most of those ipv6 be provider assigned, arin will never directly see those allocations. brian's need is for provider independent space, of which by necessity there cannot be all that many blocks. From sethm at rollernet.us Sun Jun 8 14:11:21 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 08 Jun 2008 11:11:21 -0700 Subject: [arin-ppml] simple question about money In-Reply-To: References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> Message-ID: <484C20C9.8030406@rollernet.us> Bill Darte wrote: > $1250 (x small allocation)per year with a 90% waiver through 2008.... = > $125. > Wow. Your right that IS expensive.... In 2012 you'd have to pony up the > whole $100 per month. > Last I checked, the waiver doesn't apply to assignments. So for those of us who aren't an ISP, trying to convince the people that control the money to spend *any* dollar amount on something that's perceived to be totally useless could be hard. Ultimately, if the goal is to encourage IPv6 adoption, the waiver should apply to assignments AND allocations. If you ask me, it's the little guys like me that are more likely to blaze ahead and deploy IPv6 just because we can, but we have to pay higher fees in the beginning. -- Seth Mattinen sethm at rollernet.us Roller Network LLC From owen at delong.com Sun Jun 8 16:01:26 2008 From: owen at delong.com (Owen DeLong) Date: Sun, 8 Jun 2008 13:01:26 -0700 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: <20080608140425.GC17568@ussenterprise.ufp.org> References: <4849f2d4.1db.4182.26981@batelnet.bs> <45479.1212809939@sa.vix.com> <84853.1212888922@sa.vix.com> <20080608140425.GC17568@ussenterprise.ufp.org> Message-ID: On Jun 8, 2008, at 7:04 AM, Leo Bicknell wrote: > In a message written on Sun, Jun 08, 2008 at 01:35:22AM +0000, Paul > Vixie wrote: >> it seems possible that a lot of people think that others are doing >> prefix >> length filtering, but that only a few people, or nobody, is >> actually doing >> it. the policy process should be informed somehow. any idea how >> we can > > First we need to think about the different cases: > > 1) How many networks prefix filter customers... > strictly based on their allocation? > allowing between their allocation and a /24? > allowing anything inside their allocation? > This is a constantly moving target and getting any accurate measure of any of those three numbers would be a challenge even for the fine folks at CAIDA, I suspect. Anybody feel like asking KC if she can tackle this? > 2) How many networks accept longer routes from customers than they > will > pass along to their peers? > My personal suspicion: Many. > 2) How many networks prefix filter peers... > strictly based on their allocation? > allowing between their allocation and a /24? > allowing anything inside their allocation? > allowing based on RIR published minimum allocation sizes? > Probably more than filter their customers. I also suspect that this number will drop in the short term after IANA freepool runout, then, start climbing dramatically on a somewhat parallel trajectory to the routing table growth that will result. > > For instance, if you believed 99% of the networks filtered on RIR > minimum published size, it's likely if the RIR's gave out /28's > they would allow it. However, if you believe 99% of the networks > filter at a /24 boundry, that would not be the case. The generic > question "do you prefix list filter" does not provide enough > information to make informed decisions. My rough guess is that currently less than 2% of networks filter on prefix size at all. However, I believe that at least one very large provider does so (or at least did so until very recent history). Further, I believe that the largest networks will be the ones with the most aggressive prefix filters in the shorter term as the tables start to grow. Owen From paul at vix.com Sun Jun 8 16:23:29 2008 From: paul at vix.com (Paul Vixie) Date: Sun, 08 Jun 2008 20:23:29 +0000 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: Your message of "Sun, 08 Jun 2008 13:01:26 MST." References: <4849f2d4.1db.4182.26981@batelnet.bs> <45479.1212809939@sa.vix.com> <84853.1212888922@sa.vix.com> <20080608140425.GC17568@ussenterprise.ufp.org> Message-ID: <19837.1212956609@sa.vix.com> > ... constantly moving target and getting any accurate measure > of any of those three numbers would be a challenge ... > > ... My personal suspicion: ... > > ... Probably more than ... > > ... I also suspect ... > > ... My rough guess is ... However, I believe that ... > > ... Further, I believe that ... so, back to the topic at hand, is there an experiment design in the offing? guesses, suspicions, level of challenge, probablies, and beliefs won't help us. it doesn't matter what we suspect, guess, or believe. what matters is what we can measure and what we can prove. is there an experiment design in the offing? we all know what one another's suspicions, predilictions, guesses, fears, hopes, and dreams are. what we need to know how is, what can we measure and how, what can we prove and how. straw man: grab a dozen unrouted /28 blocks from ARIN's inventory having wide range of first-octet, pick a dozen existing (routed; known to be old and stable) places; arrange the machinery and software to be able to do ping tests of some known reachable addresses within every prefix in today's global routing table; (ping means icmp-echo but could also include a TCP SYN to port 65535, and in all cases we need to remember the address of the gateway who sent us an icmp response); variations should include advertising each /28 and re-running the ping tests after 10 minutes, 100 minutes, 1000 minutes, and perhaps faking a route flap to see how that changes the results; compare the ping test quality of these /28's against the ping test quality from the existing/routed/old/stable prefixes run at the same time, to filter out the remote-end reachability problems and hopefully leave us with /28-nonpropagate events. ping tests of this kind are incomplete. we also need to institute ping and TCP/80 from within enduser networks, and it will have to be more than a dozen. but because of the difficulty of designing and executing that experiment, i'd say we should ask for the ping test results first, since if they are dismal, then marty's proposed amendment will fail and we won't need to know what the inbound reachability of these prefixes would have been. who can improve on this? From mhw at WittsEnd.com Sun Jun 8 16:55:51 2008 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sun, 08 Jun 2008 16:55:51 -0400 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <4848C1BC.9020009@internap.com> References: <4848B4BE.3060303@internap.com> <4848C1BC.9020009@internap.com> Message-ID: <1212958551.4681.18.camel@canyon.wittsend.com> On Thu, 2008-06-05 at 21:49 -0700, Scott Leibrand wrote: > Michel Py wrote: > >> Scott Leibrand wrote: > >> The Economist, in their usual fashion, did a very good job with > >> their metaphors in explaining the issues of IPv4 exhaustion and > >> IPv6 transition for a general audience: > > > > I think it would have been better if it was accurate: > > > > http://www.economist.com/printedition/displaystory.cfm?story_id=11482493 > >> {..} Support for IPv6 is already baked into most popular operating > >> system software. It is incorporated into Windows XP and Vista {..} > > > > Last time I checked, IPv6 was not "incorporated" into XP. Given the > > huge popular success of Vista especially in corporate > > environments that changes the picture a bit, as XP still is > > by far the most popular operating system. > It requires activation from the command line, but Windows XP definitely > has IPv6 support. I enabled and used it on my XP laptop at the last > ARIN meeting. IPv6 in Windows XP does not require command line activation since SP1. You can turn it on by right clicking on the network connection and adding the protocol. You don't even have to reboot. What is, err, disturbing is that a significant number of XP systems have ended up with IPv6 enabled and yet nobody knows how it happened. That a globally addressable and routable protocol "magically appears" on a box without the user having done it is very disturbing from a security standpoint. Some users have thought that it was due to a Microsoft update, but we know that to NOT be the case. This has happened even on some embedded systems, such as POS terminals. Yes, when enabled, it does have Teredo enabled and is perfectly capable of configuring itself to the MS Teredo servers and start chatting on IPv6. This has been occurring enough to be showing up on intrusion detection systems with Teredo and 6to4 signatures enabled. > -Scott Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part URL: From michael.dillon at bt.com Sun Jun 8 17:26:17 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 8 Jun 2008 22:26:17 +0100 Subject: [arin-ppml] simple question about money In-Reply-To: <57E0EC0682885176731FABBA@Visible-Trout.local> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local><20080608143121.GA1890@vacation.karoshi.com.> <57E0EC0682885176731FABBA@Visible-Trout.local> Message-ID: > Sale, rent, whatever. It's $1000/year that I'll have to pay > to use IPv6. I know there are fee waivers in the beginning, > but I don't care about the beginning. I care about the long > term, and committing to $1000/year long term for the use of > something that cannot possibly cost more than $10/year is, in > my opinion, bordering on criminal. No, it's business. You pay rent, you pay for electricity, and you pay wages, regardless of whether you are a non-profit or you are Exxon. If you really want free, then ask your upstream for a /48 and you won't have to pay ARIN a penny. > But in the fullness of time there ought to be > millions of people using it, and tens of millions a year is > the kind of thing that I expect ICANN to spend, not ARIN. The RIRs adjust their fee structures from time to time to ensure that they remain non-profit. I believe that the rough rule of thumb is that they ensure their cash reserves don't rise much beyond one year of outgoings. Fact is, that you have no say in ARIN fees unless you are an ARIN member, which is why there is no point in discussing fees here on the public policy mailing list. > When you finish making fun of me for asking the question, it > would be good to have a factual answer. The fact is that ARIN is not set in stone. It adjusts its policies according to public input on this list. It adjusts its fees according to the wishes of its members as expressed on their mailing list, or by the people that they elect to the Board of Trustees. --Michael Dillon From michael.dillon at bt.com Sun Jun 8 17:33:12 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 8 Jun 2008 22:33:12 +0100 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitateIPv6 deployment In-Reply-To: References: <4849f2d4.1db.4182.26981@batelnet.bs><45479.1212809939@sa.vix.com><84853.1212888922@sa.vix.com><20080608140425.GC17568@ussenterprise.ufp.org> Message-ID: > Anybody feel like asking KC if she can tackle this? Bad idea. KC is a researcher which means that she collects data and analyzes it. What we want here is a maintained database which records the filtering rules of every AS number holder. This is a job for the RIRs, not for the research community. To collect this information requires education and outreach, which tends to be among the formal purposes of each of the RIRs. --Michael Dillon From kevin at your.org Sun Jun 8 17:32:20 2008 From: kevin at your.org (Kevin Day) Date: Sun, 8 Jun 2008 16:32:20 -0500 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <1212958551.4681.18.camel@canyon.wittsend.com> References: <4848B4BE.3060303@internap.com> <4848C1BC.9020009@internap.com> <1212958551.4681.18.camel@canyon.wittsend.com> Message-ID: On Jun 8, 2008, at 3:55 PM, Michael H. Warfield wrote: > What is, err, disturbing is that a significant number of XP systems > have ended up with IPv6 enabled and yet nobody knows how it happened. > That a globally addressable and routable protocol "magically > appears" on > a box without the user having done it is very disturbing from a > security > standpoint. Some users have thought that it was due to a Microsoft > update, but we know that to NOT be the case. This has happened even > on > some embedded systems, such as POS terminals. > I've had some discussions on this problem with a few people at Microsoft. So that I'm not accidentally revealing anything that was told to me that wasn't meant for public consumption, I'll limit myself to what I told THEM to get the ball rolling, and leave some names out. A good number of users turned IPv6 on in one way or another after hearing about it, failing to get it working and not completely turning it back off. Or it did work at one point, then later broke. One "personal firewall system" had the foresight to realize that IPv6 might want to be firewalled as well. But just for it to install it's v6 firewall, it turned the v6 stack on. Even if you weren't using v6. The argument appeared to be "The user might turn v6 on later and our firewall wouldn't have protected them". There also were a few smaller software packages that tried to be helpful and make sure v6 was enabled on Windows so that their v6 support worked. This seemed to break things far worse than it helped. But, there are also people who are finding it's turned on and there just seems to be no reasonable explanation. Embedded systems are a great example. This is a significant problem for anyone deploying AAAA records. This is a few months out of date, but here's a comparison of the number of random users who have working v6 stacks to broken v6 connectivity on a highly-nontechnical popular website: http://www.your.org/v6clients.png Essentially, of the users visiting the site what percentage are able to load a 1x1 image via v6? (working clients) What percentage were unable to load an image that had both v4 and v6 addresses? (broken clients) The peak starting in early 2007 seems to roughly correlate to the uptick in Vista users, but not 1:1. This is part of what I want to really closely document with the stuff going on at http://www.ipv6experiment.com... which really really really honestly is coming soon now. :) -- Kevin From briand at ca.afilias.info Sun Jun 8 17:52:53 2008 From: briand at ca.afilias.info (Brian Dickson) Date: Sun, 08 Jun 2008 17:52:53 -0400 Subject: [arin-ppml] IPv4 Transfer policies - questions, definitions, thoughts, suggestions In-Reply-To: References: <546210EA466CA8FBDBD412AC@Visible-Trout.local><20080608143121.GA1890@vacation.karoshi.com.> <57E0EC0682885176731FABBA@Visible-Trout.local> Message-ID: <484C54B5.1070305@ca.afilias.info> I've been giving thought to the general area of IPv4 transfers-for-money. I thought I'd share some observations I've come up with, as well as questions, suggestions, and definitions which might help with coming to a consensus on major issues. If we can collectively work out the big things, quite possibly the small things will become moot and/or work themselves out. That said, here's what I have come up with so far... ----- I apologize for this being a bit long. I'll try to be brief where possible, and/or follow up on my own posting in separate threads. First, an observation: IPv4 Internet addresses (as in, used on the "public Internet") are finite. This means that any policies that don't address this or aren't compatible with a "zero sum game", may be fatally flawed because they are open to abuse. Second, a suggestion: any policy framework devised in any RIR region, or globally (IANA), should create an implicit bias towards those actually using IPv4 space, and against any participation by non-users (e.g. speculators). The reason for this is, what I think the obvious answer to the following question is: "Would the existence of speculators, who purchase IPv4 address space largely or solely for the purpose of profiting from the (re)sale of IPv4 address space, harm the 'IPv4 community' (those who actually use IPv4 addresses)?" I believe the answer to this question is "Yes.". I think the simplest corollary to the answer "yes" should be, that any policy regarding transfer of IPv4 space, should inherently discourage speculation. Rather than doing so by defining bad behavior, create a set of rules where there is no ability to benefit except indirectly, by acquiring IPv4 space that is needed and using it to operate one's own business. Here's a suggestion on how this could be framed: Apply the three laws of thermodynamics ("You can't win; You can't break even; You can't quit the game") to transfers: (1) You can't win: No resale of IPv4 space for net profit on a per-unit basis. (This would include buying block A and selling block B, perhaps with some special case exclusions where actual aggregation is the net side-effect of the purchase and sale.) (2) You can't break even: On an aggregate basis, any organizations transactions in IPv4 transfers must be a net increase in IPv4 space. The one exception would be the sale of previously assigned (but not purchased) space by an RSA or LRSA signatory. (3) You can't quit the game: If, for any reason, an entity to whom IPv4 space is registered, stops announcing that space on a permanent basis (e.g. because they have ceased operations, such as under a bankruptcy situation), then that address space may be reclaimed by (ARIN/IANA/RIR/whoever assigned it). This may be for consideration, but not for a net profit to the registrant, .e.g pro-rata or full refund at original price of purchase. I'm not suggesting that these suggestions are enough to form a complete policy, or even that they will be workable. However, I would encourage thinking about the issue of how to make it impossible for anyone, participant or non-participant, to abuse the transfer policy for profit, in as simple a way as possible. For example, the rules above, still leave open the issues of who operates, monitors, etc., the market itself, without placing any significant restrictions on how those can be resolved. On the other hand, if the rules prevent anyone from profiting on resale, speculators will not participate at all, I would suggest. Thoughts? Brian Dickson From randy at psg.com Sun Jun 8 18:03:23 2008 From: randy at psg.com (Randy Bush) Date: Mon, 09 Jun 2008 07:03:23 +0900 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: <19837.1212956609@sa.vix.com> References: <4849f2d4.1db.4182.26981@batelnet.bs> <45479.1212809939@sa.vix.com> <84853.1212888922@sa.vix.com> <20080608140425.GC17568@ussenterprise.ufp.org> <19837.1212956609@sa.vix.com> Message-ID: <484C572B.80205@psg.com> > straw man: grab a dozen unrouted /28 blocks from ARIN's inventory having wide > range of first-octet, pick a dozen existing (routed; known to be old and > stable) places; arrange the machinery and software to be able to do ping tests > of some known reachable addresses within every prefix in today's global > routing table; (ping means icmp-echo but could also include a TCP SYN to port > 65535, and in all cases we need to remember the address of the gateway who > sent us an icmp response); variations should include advertising each /28 > and re-running the ping tests after 10 minutes, 100 minutes, 1000 minutes, > and perhaps faking a route flap to see how that changes the results; compare > the ping test quality of these /28's against the ping test quality from the > existing/routed/old/stable prefixes run at the same time, to filter out the > remote-end reachability problems and hopefully leave us with /28-nonpropagate > events. > > ping tests of this kind are incomplete. we also need to institute ping and > TCP/80 from within enduser networks, and it will have to be more than a dozen. > but because of the difficulty of designing and executing that experiment, i'd > say we should ask for the ping test results first, since if they are dismal, > then marty's proposed amendment will fail and we won't need to know what the > inbound reachability of these prefixes would have been. > > who can improve on this? much of this has been been done. see nick's stuff, our paper last inm, the cool one at the app level from last janog and apricot, some renesys work in the area, ... but what is this gonna tell you? what is in place today. bit whoopie doo. just as with the 2050 /19 agreement in danvers, filtering policies will adjust to allocation realities if honestly negotiated and technically feasible. so do not base all future technology and policy on yesterday's ephemeral router configs. otoh, do make tools to prevent, diagnose, and fix errant configs. randy From paul at vix.com Sun Jun 8 19:08:53 2008 From: paul at vix.com (Paul Vixie) Date: Sun, 08 Jun 2008 23:08:53 +0000 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: Your message of "Mon, 09 Jun 2008 07:03:23 +0900." <484C572B.80205@psg.com> References: <4849f2d4.1db.4182.26981@batelnet.bs> <45479.1212809939@sa.vix.com> <84853.1212888922@sa.vix.com> <20080608140425.GC17568@ussenterprise.ufp.org> <19837.1212956609@sa.vix.com> <484C572B.80205@psg.com> Message-ID: <24849.1212966533@sa.vix.com> > ... > but what is this gonna tell you? what is in place today. bit whoopie doo. > > just as with the 2050 /19 agreement in danvers, filtering policies will > adjust to allocation realities if honestly negotiated and technically > feasible. > > so do not base all future technology and policy on yesterday's ephemeral > router configs. otoh, do make tools to prevent, diagnose, and fix errant > configs. overall, this is my position also. we already need some kind of routing security to prevent injection of prefixes by unauthorized parties, and it has to be based on public-key crypto rather than prefix lengths or prefix quotas. prefix length filtering "on RIR boundaries" is too coarse, and prefix limits per peer are too coarse. therefore without any new policy and without allocating any /28's from anywhere, we already have the need for technology which, once present, will mean that it doesn't matter where the /28 microallocations for v6/v4 gateways come from, even assuming that demand for these is from multihomers who cannot just use PA, which hasn't been successfully argued (to my satisfaction, anyway). my concern is, we're not there today. a policy that said folks could get /28's for use in v4/v6 gateways might not be attractive or even useful, if these prefixes wouldn't get good reachability. and while i agree that a well reasoned policy in this area would have the effect of changing the internet's route filtering culture, i think early adopters might feel some fear, and this fear might be well founded if it takes a while for prefix length filterers to adjust to the new policy. so, i'm suggesting that the reachability of these prefixes be measured and reported, and compared to the reachability of older, larger, more stable prefixes. this could be done not just once, but periodically, and so detect any trends. From keith.rhea at domaccess.com Sun Jun 8 22:10:37 2008 From: keith.rhea at domaccess.com (keith rhea) Date: Sun, 8 Jun 2008 22:10:37 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: <484C572B.80205@psg.com> References: <4849f2d4.1db.4182.26981@batelnet.bs> <45479.1212809939@sa.vix.com> <84853.1212888922@sa.vix.com> <20080608140425.GC17568@ussenterprise.ufp.org> <19837.1212956609@sa.vix.com> <484C572B.80205@psg.com> Message-ID: <007401c8c9d6$03b5f5a0$3202a8c0@91098204484F430> Stop sending these out to everyone please, this is not a chat room. From randy at psg.com Sun Jun 8 22:50:57 2008 From: randy at psg.com (Randy Bush) Date: Mon, 09 Jun 2008 11:50:57 +0900 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: <24849.1212966533@sa.vix.com> References: <4849f2d4.1db.4182.26981@batelnet.bs> <45479.1212809939@sa.vix.com> <84853.1212888922@sa.vix.com> <20080608140425.GC17568@ussenterprise.ufp.org> <19837.1212956609@sa.vix.com> <484C572B.80205@psg.com> <24849.1212966533@sa.vix.com> Message-ID: <484C9A91.2000508@psg.com> > my concern is, we're not there today. a policy that said folks could get > /28's for use in v4/v6 gateways might not be attractive or even useful, if > these prefixes wouldn't get good reachability. and while i agree that a > well reasoned policy in this area would have the effect of changing the > internet's route filtering culture, i think early adopters might feel some > fear, and this fear might be well founded if it takes a while for prefix > length filterers to adjust to the new policy. so, i'm suggesting that the > reachability of these prefixes be measured and reported, and compared to > the reachability of older, larger, more stable prefixes. this could be > done not just once, but periodically, and so detect any trends. we have written the code to do this and are verifying the quality of the methods used (and that is turning out deliciously well!). the first version of the code is already in arin's hands. (for the state a year or more ago, see apricot and inm papers) so far, it has been used to test the reachability, and causes of lack thereof, of space newly assigned to arin by the iana. i am not impressed by the state of filtering on the net. but detecting the filters sure makes the code look good :). randy From reid at mejac.palo-alto.ca.us Mon Jun 9 11:20:25 2008 From: reid at mejac.palo-alto.ca.us (Brian Reid) Date: Mon, 09 Jun 2008 08:20:25 -0700 Subject: [arin-ppml] simple question about money In-Reply-To: <484BF1C3.20007@psg.com> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <20080608143121.GA1890@vacation.karoshi.com.> <57E0EC0682885176731FABBA@Visible-Trout.local> <484BF1C3.20007@psg.com> Message-ID: <16EB6880180498D368047414@hindolveston.reid.org> > you have an employment conflict of interest, vixie being a non-trivial > and typically vixie religious player in the game of maintaining the > RIRs' bloated position leasing integers. Feh. I've known Paul Vixie more than half his life, and to me "typically vixie" means "honorable" and "lives by principle". That's why I'm proud to work for him and I probably should have checked with him first. Whatever this is, I can't imagine that he is guilty of "maintaining the bloated position" or of anything else that's even slightly unscrupulous. I shouldn't have been so harsh on ARIN in my question, and for that I owe him a public apology; I should have assumed that there was a good reason for the prices instead of assuming that there was not. Paul's typically laconic reply actually answered my question. Would that the documentation did so also. The summary of what I got from his reply was "there are solid technical reasons why there shouldn't be very many portable blocks, and so they are priced accordingly." What I learned is that I shouldn't want a direct allocation. To many of the rest of you: there's a difference between being a member of ARIN and a customer of ARIN. At least I think there is. Nowhere in the documentation do I see anything saying that you have to be a member of ARIN in order to get a direct allocation. Of course you can't fund the activities of ARIN with a membership fee that's 1/100th of what it is now, but that's not what I was asking about. If IPv6 is going to catch on with the technical public, the process of using it needs to be sufficiently transparent that somebody who spends 3 or 4 hours reading the website to figure out what to do needs to come away with a sense of how to get things done. I didn't. I know that many of you will just respond by telling me I'm stupid, but I really did read what was there and try hard to understand it. Nowhere did I see an explanation that the administration and management of IPv6 is (presumably by design) different from that of v4 and that the concepts don't just move over. In particular, the whole supply-and-demand thing is not properly explained or documented. There was a scarce resource (v4). It is priced high, like many scarce resources. Now there is an abundant resource (v6), with millions of times more availability. Conventional economics suggests that the more abundant resource ought to be a lot cheaper because of the principles of supply and demand. It isn't. The mistake I made was assuming that the bizarrely high price was motivated by greed or stupidity. I admit that my expectations there were set by having paid close attention to ICANN's early years. The bizarrely high price is in truth motivated by solid operational and technical concerns (and is therefore not bizarre), because there still is a scarce resource, namely routing table slots. I think it would help a lot for ARIN documentation to explain why the usual laws of supply and demand seemingly do not hold here. From Lee.Howard at stanleyassociates.com Mon Jun 9 12:08:20 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 9 Jun 2008 12:08:20 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <546210EA466CA8FBDBD412AC@Visible-Trout.local> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40A27BFA3@CL-S-EX-1.stanleyassociates.com> Your treasurer took the weekend off. I will try to be clear, even if I can't be concise. IPv6 fees are set by the Board, with recommendations from the Board's Finance Committee, and input from the membership. We have tweaked and waived IPv6 fees over the past few years, but the overriding interests are 1) covering ARIN's costs, and 2) providing predictable, understandable fee structures. ARIN now has two years of operating expenses in reserve, against a time in the IPv6 future when registration fees become unpredictable. Discussion more appropriately belongs on the member list, arin-discuss. End users pay a one-time fee, based on the size of the assignment, plus $100 annual maintenance fee. This one maintenance fee can be applied to all IPv4, IPv6, and ASN registrations with ARIN. Most end user organizations receive assignments from their ISPs, not from ARIN. End users do not receive membership benefits with their assignment. There is a membership option available to end users: an individual membership, see General Membership #2 at http://www.arin.net/membership/index.html ISPs pay a registration fee based on allocation size, plus a corresponding annual renewal. Most ISPs will probably get a /32, which is set at $2,250 per year. However, the Board does not want fees to be a disincentive to adoption of IPv6, and has set up a couple of waivers: Waiver #1: ISPs already paying an annual fee for for IPv4 won't pay an initial fee for IPv6. Waiver #2: Anyone paying an annual fee will pay only the higher fee of IPv4 or IPv6. In most cases, that means your current fees stay the same; $100/year for end users, or whatever your IPv4 renewal is for ISPs. Waiver #3: ISPs who get an IPv6 allocation (and whose fees aren't completely waived under Waiver #2) will see a reduced fee for the next few years. So an ISP getting an IPv6 /32 allocation this year will pay $225 now, $562.50 next year, $1125 in 2010, $1687.50 in 2011, and the full $2250 in 2012 and beyond. As I said, over the past few years there have been other waivers in place, and some of them have expired. The Board wants to encourage anyone who will continue needing new IP address blocks to plan for IPv6 now. (http://www.arin.net/announcements/2007/20070521.html) We generally avoid using fees as incentives, but we also try to avoid letting fees become disincentives to efficient utilization and stable networking. I worked with Financial Services and Member Services staff to try to make the language on the fee pages clear. We have apparently not completely succeeded, and we'll keep working on it. Disclaimers: All of the fee information is on http://www.arin.net/billing/fee_schedule.html but I've paraphrased it here. If my paraphrase disagrees with anything on the web site, the web site is authoritative. I am not a designated spokesperson for the Board, and I have not confirmed my understanding of the reasons for past Board actions with other Board members, or even checked past meeting minutes. My memory and understanding of Board actions and motives above is purely mine, and if I misremember, I'll backpaddle aggressively. Lee > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Brian Reid > Sent: Sunday, June 08, 2008 8:56 AM > To: ppml at arin.net > Subject: [arin-ppml] simple question about money > > Given how much IPv6 address space exists, why is it so damned > expensive? I decided it was time to turn up IPv6 connectivity > to my world, but when I went to look at prices for buying > even a small block of portable address space I realized I > couldn't afford it. > > Given that this is a fictitious resource, and that there is > no intrinsic cost, ARIN should be charging about 1/100th of > their listed prices for it. Is there a legitimate reason for > the ultra-high prices? Is ARIN owned by Prada? > > Brian Reid > > > _______________________________________________ > 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 the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From Lee at Dilkie.com Mon Jun 9 12:40:55 2008 From: Lee at Dilkie.com (Lee Dilkie) Date: Mon, 09 Jun 2008 12:40:55 -0400 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <48495F40.30403@psg.com> References: <48495CF2.6040804@Dilkie.com> <48495F40.30403@psg.com> Message-ID: <484D5D17.7010603@Dilkie.com> Sorry to be replying so late, I went camping for the weekend. I'm not sure how a Chinese IPv6 network in any way takes away from my argument. This network is more interested in it's own content, not the rest of the world's, so IPv6-only isn't going to hurt them (one could argue that IPv6 only nicely solves some social-political issues neatly for them in the short term). We're the "American"-rin, we need to be thinking what's best for our part of the world... Clearly we will be living with mixed v4-v6 networks for a while...So we need to think about getting *there* in the first place before worrying about deployment of v6-only networks. -lee Randy Bush wrote: >> I don't think anyone is in a hurry to roll out end-to-end IPv6-only >> deployments. >> > > see , a *very* big v6-only network. > > randy > From tedm at ipinc.net Mon Jun 9 12:56:24 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 9 Jun 2008 09:56:24 -0700 Subject: [arin-ppml] simple question about money In-Reply-To: <16EB6880180498D368047414@hindolveston.reid.org> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Brian Reid > Sent: Monday, June 09, 2008 8:20 AM > To: ppml at arin.net > Subject: Re: [arin-ppml] simple question about money > > > > If IPv6 is going to catch on with the technical public, the > process of using it needs to be sufficiently transparent that > somebody who spends 3 or 4 hours reading the website to > figure out what to do needs to come away with a sense of how > to get things done. Nobody who has never had any exposure to TCP/IP IPv4 can spend "3 or 4 hours reading" a website about it and come away with a sense of how to get things done. Why are you assuming that it would be any different with IPv6? I watched many administrators who came out of the Novell NetWare era who only had exposure to IPX take many months of struggling to understand TCP/IP. I remember asking the Teleco manager of Central Point Software, a really nice guy named Jeff (who is now a karate instructor, funny the paths people take in their life), back in 1992, if he had heard about TCP/IP and the Internet, and getting a blank stare. This was pretty common. > I didn't. I know that many of you will > just respond by telling me I'm stupid, but I really did read > what was there and try hard to understand it. Your not stupid and please do not get defensive. If IPv6 was simple then why did it take a team of expert network engineers to dream it up? > Nowhere did I > see an explanation that the administration and management of > IPv6 is (presumably > by design) different from that of v4 and that the concepts > don't just move over. In particular, the whole > supply-and-demand thing is not properly explained or > documented. There was a scarce resource (v4). It is priced > high, like many scarce resources. Now there is an abundant > resource (v6), with millions of times more availability. > Conventional economics suggests that the more abundant > resource ought to be a lot cheaper because of the principles > of supply and demand. It isn't. > I am sure it will be once everyone is using IPv6. > The mistake I made was assuming that the bizarrely high price > was motivated by greed or stupidity. I admit that my > expectations there were set by having paid close attention to > ICANN's early years. The bizarrely high price is in truth > motivated by solid operational and technical concerns (and is > therefore not bizarre), because there still is a scarce > resource, namely routing table slots. I think it would help a > lot for ARIN documentation to explain why the usual laws of > supply and demand > seemingly do not hold here. > But this is NOT ARIN's concern, as to how many routing slots things take. One of the "dirty little secrets" in the IPv4 world is that a lot of legacy assignments were handed out to some of the largest orgs, pre-ARIN. Those orgs pay nothing for those per the agreements that created the RIR's. Thus, the cost of administering numbers is, in fact, lopsided, and is bourne unequally by the orgs that came later on. When the automobile was first manufactured, the federal government required zero safety features. Thus the automakers did not have to spend any money on these features, and the buying public didn't have to pay for them. Later on the feds did start requiring many safety and today, emissions features on automobiles. These add thousands to the cost of the car. As a result, the latecomers buying new cars today bear the costs of all these extra safety and emissions features. Anyone who is still out there driving around a Model-T never had to pay those costs. Their cost of ownership per mile is a lot cheaper than the guy with the new vehicle. That is just how things work. Fortunately, as the shift to IPv6 will make useless those legacy assignments, ultimately those orgs that are paying nothing now, will have to start paying for the cost to adminster IP addressing, and therefore the costs will be more evenly spread, and should drop for everyone. Ted From tedm at ipinc.net Mon Jun 9 13:32:41 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 9 Jun 2008 10:32:41 -0700 Subject: [arin-ppml] simple question about money In-Reply-To: <13324.1212944645@sa.vix.com> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Paul Vixie > Sent: Sunday, June 08, 2008 10:04 AM > To: Joe Baptista > Cc: ppml at arin.net > Subject: Re: [arin-ppml] simple question about money > > brian's need is for provider > independent space, How do you know this? I have read the thread and nowhere does Brian mention he NEEDS portable IPv6. His exact words were: "...I decided it was time to turn up IPv6 connectivity to my world..." He then follows this with an ASSUMPTION that he should be out there obtaining portable IPv6 numbering. If Brian is an ISP and reselling service, then his customers pay the cost of IPv6, not him, and his complaints are unjustified. If he's just some dude in his garage with 2 DSL lines that he's running BGP over to different providers, then he can obtain an IPv6 block from one and advertise it to the other, no problem. If he IS some dude in his garage, even though technically it's non-portable, in reality since his cost to renumber such a trivially small assignment is virtually nothing, effectively his use of it is "portable" > of which by necessity there cannot be all > that many blocks. Nothing prevents people from obtaining provider-dependent chunks from upstream ISP's and filling up the BGP table with them. Nothing ARIN can do with fees will prevent this. Not to mention it's not in ARIN's charter to worry about the size of the table anyway. If Brian is ASSUMING he needs a portable block when in reality he doesen't, then he just needs to go back to the books and study some more, that will take care of the problem. If Brian just WANTS a portable block of IPv6 because he thinks it would be "cool to have" or that it would make him "special" then I'm sorry, but the Internet has been a commercial network for over a decade now, we really don't want a bunch of small fry experimenters on it anymore. He needs to do what everyone else does and work within the system and get his numbering from someone larger. Or if he must experiment, then he can go to work for some larger network, where his experimenting will be supervised by someone more knowledgeable. We do not let people do their own road paving anymore, either. If I live in an unincorporated area that has crummy roads, I am required by law to pay taxes so a professional can go out there and repave the road, I am not allowed to just go down and rent a paver and have at it myself, even though I could do the work myself, at a quarter of the cost. Ted From tedm at ipinc.net Mon Jun 9 14:25:39 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 9 Jun 2008 11:25:39 -0700 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Day > Sent: Sunday, June 08, 2008 2:32 PM > To: mhw at WittsEnd.com > Cc: PPML > Subject: Re: [arin-ppml] IPv6 in the Economist > > > > One "personal firewall system" Has to be Norton/Symantec. That's the biggest POS personal firewall out there and causes by far and away the largest number of support calls into us. Ted From tedm at ipinc.net Mon Jun 9 14:36:17 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 9 Jun 2008 11:36:17 -0700 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Paul G. Timmins > Sent: Friday, June 06, 2008 8:06 AM > To: Dean Anderson > Cc: PPML > Subject: Re: [arin-ppml] IPv6 in the Economist > > > Until then, I think I speak for the silent majority when I > say that your conspiracy theories and bandying about of legal > terms freely, denigrating people who are generally respected > as good actors on the internet (and if you don't like that, > PROVE OTHERWISE! Making your case on PPML is great, but you > know what they say about arguing on the internet. Pick your > venue and go for it!) just weakens your case in the eyes of > the public, and make PPML look like a collection of bickering > adults in their mother's basements Dean is our Jeremiah Wright Jr. I guess you must think history has labeled the current US presidential campaign "a collection of bickering adults in their mother's basements" But, the general public knows the difference with that campaign, and they do for Dean as well. > wearing tinfoil hats. As > the glorious comic book I got last summer states: Who is > ARIN? YOU ARE! And frankly, I don't want history to see us in > this light. Don't assume the future will be populated by morons. I'm insulted by long dead historical figures who decided that I am a moron and talked down to me. The worst are the ones who explained life using simplistic stories like this big old boat that had a lot of animals in it that survived a flood, or this guy and girl that ate an apple that a talking snake gave to them then decided that nudity was a bad thing, etc. etc. Ted From aaron at wholesaleinternet.com Mon Jun 9 16:01:47 2008 From: aaron at wholesaleinternet.com (Aaron Wendel) Date: Mon, 9 Jun 2008 15:01:47 -0500 Subject: [arin-ppml] simple question about money In-Reply-To: <5161610C82C568A6A4B56BD8@Visible-Trout.local> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <484BEBCA.40204@ttec.com> <5161610C82C568A6A4B56BD8@Visible-Trout.local> Message-ID: <183c01c8ca6b$a5ce6ee0$f16b4ca0$@com> If you're the only user then you can qualify under the end user clause which I believe makes it $1250 up front and $100 a year. Aaron -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Brian Reid Sent: Sunday, June 08, 2008 9:49 AM To: ppml at arin.net Subject: Re: [arin-ppml] simple question about money I can understand a fairly high one-time cost to help deal with these issues. But not a high annual fee. Charging an up-front fee of $5000 to register the block and then $10/year to cover the occasional operational expenses makes sense to me. $1000/year does not. > - scarcity barrier > > - frivolity barrier > > - hoarding barrier > > - operational expenses _______________________________________________ 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From rw at firstpr.com.au Mon Jun 9 16:33:43 2008 From: rw at firstpr.com.au (Robin Whittle) Date: Tue, 10 Jun 2008 06:33:43 +1000 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <484D5D17.7010603@Dilkie.com> References: <48495CF2.6040804@Dilkie.com> <48495F40.30403@psg.com> <484D5D17.7010603@Dilkie.com> Message-ID: <484D93A7.8040101@firstpr.com.au> I tried to correct what I saw as errors and omissions in the article: http://www.economist.com/printedition/displaystory.cfm?story_id=11482493 with the following comments. For more on my Ivip proposal to solve the routing scaling problem, see: http://www.firstpr.com.au/ip/ivip/ - Robin The most important error or omission in this article is that it fails to mention that a computer with only an IPv6 address cannot communicate directly with a computer with only IPv4 address. Email works fine, and some applications can work via proxy servers or application level gateways. Apart from that, the IPv6 Internet is quite separate from the IPv4 Internet we all use today. Many application programs only work with IPv4 and would require a significant rewrite to operate with IPv6 only, or with "dual-stack" IPv4 and IPv6. Almost every user needs full IPv4 connectivity, so they need an IPv4 address. There is currently no advantage to having an IPv6 address because essentially every website, server or computer of other end-users is is reachable via IPv4. "Nearly 85% of available addresses are already in use;". 1.7B IPv4 addresses are handled by the routing system, of the 3.7B which are available. Of these, probably only a few hundred million are actually used (1). By continued use of Network Address Translation (NAT) and finer slicing and dicing of IPv4 space, IPv4 space can be used much more efficiently than at present. For instance, the map-encap proposals - LISP, APT, Ivip and TRRP - currently being developed by the IRTF Routing Research Group (2) would all facilitate much finer and more efficient management of IPv4 space without further burdening the core BGP routing system. Windows XP can only perform DNS lookups (required for every IPv4 or IPv6 application) over an IPv4 service. Neither Comcast nor any other ISP has figured out how to meet the needs of ordinary end-users with an IPv6-only service. Most games, peer-to-peer and other applications (other than web-browsers and email clients) are IPv4-only. Since its inception in the mid-1990s, IPv6 has not met the needs of significant numbers of users or ISPs. The IPv4 address shortage won't change this, since for many years to come it will be easier and better to use IPv4 space more intensively than to try to sell end-users an IPv6 service which can't meet their needs and would involve intolerable levels of support calls and customer dissatisfaction even if it met 90% of their needs. Robin Whittle Analyst, Paul Budde Communications (1) http://www.isi.edu/~johnh/PAPERS/Heidemann08a.pdf, http://www.firstpr.com.au/ip/host-density-per-prefix/ (2) http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup From tedm at ipinc.net Mon Jun 9 17:39:15 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 9 Jun 2008 14:39:15 -0700 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <484D93A7.8040101@firstpr.com.au> Message-ID: Sorry, all for the top post, but I just don't see the point in a step-by-step refutation. Others are welcome. Robin, the problem here is summarized by the old Star Trek quote "The needs of the many outweigh the needs of the few" To put it simply, there are not enough IPv4 addresses available to use in the heiararchival fashion we have all decided to use on the Internet for organizing routing, to allow everyone who wants to be on the Internet to do everything they want to do. There is no question that for an INDIVIDUAL company, or person, that IPv6 is a cost. You have written an article here that discusses the issue from a technical case, that's all well and good. By the same token, it is CHEAPER for an individual who happens to own a car with a plugged catalyatic converter, to simply insert a long rod and punch out the honeycomb, rather than spend the money for a new converter. After all, his action only increases the amount of pollution an infinitestimal amount compared to all the air pollution we already have, and after all why should he have to pay for a catcon if some guy with similar circumstances out in the hill country where the state doesen't require emissions testing doesen't have to? You forget that you are on a network that has a lot of other people on it, and some of those people have severe problems due to the looming shortage of IPv4. NAT and the other fancy footwork your advocating isn't going to help them due to the nature of their problems. And, once IPv4 DOES runout, the number of people with problems is going to skyrocket. Of course, you don't give a God-dammed about those people, do you? As long as YOU have your IP numbers, screw the rest of the bastards. Because, that is basically what your saying. I've been using the Internet since you thought that TCP/IP was a line you hung clothes on to dry, and I didn't sign on to create an exclusive club. Neither did everyone else that helped set it up. It's a crying shame if your view prevails. Ted > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Robin Whittle > Sent: Monday, June 09, 2008 1:34 PM > To: PPML > Subject: Re: [arin-ppml] IPv6 in the Economist > > > I tried to correct what I saw as errors and omissions in the article: > > http://www.economist.com/printedition/displaystory.cfm?story_i > d=11482493 > > with the following comments. For more on my Ivip proposal to > solve the routing scaling problem, see: > > http://www.firstpr.com.au/ip/ivip/ > > - Robin > > > > The most important error or omission in this article is that > it fails to mention that a computer with only an IPv6 address > cannot communicate directly with a computer with only IPv4 > address. Email works fine, and some applications can work via > proxy servers or application level gateways. Apart from that, > the IPv6 Internet is quite separate from the IPv4 Internet we > all use today. > > Many application programs only work with IPv4 and would > require a significant rewrite to operate with IPv6 only, or > with "dual-stack" IPv4 and IPv6. > > Almost every user needs full IPv4 connectivity, so they need > an IPv4 address. There is currently no advantage to having an > IPv6 address because essentially every website, server or > computer of other end-users is is reachable via IPv4. > > "Nearly 85% of available addresses are already in use;". 1.7B > IPv4 addresses are handled by the routing system, of the 3.7B > which are available. Of these, probably only a few hundred > million are actually used (1). > > By continued use of Network Address Translation (NAT) and > finer slicing and dicing of IPv4 space, IPv4 space can be > used much more efficiently than at present. For instance, the > map-encap proposals - LISP, APT, Ivip and TRRP - currently > being developed by the IRTF Routing Research Group (2) would > all facilitate much finer and more efficient management of > IPv4 space without further burdening the core BGP routing system. > > Windows XP can only perform DNS lookups (required for every > IPv4 or IPv6 application) over an IPv4 service. > > Neither Comcast nor any other ISP has figured out how to meet > the needs of ordinary end-users with an IPv6-only service. > Most games, peer-to-peer and other applications (other than > web-browsers and email clients) are IPv4-only. > > Since its inception in the mid-1990s, IPv6 has not met the > needs of significant numbers of users or ISPs. The IPv4 > address shortage won't change this, since for many years to > come it will be easier and better to use IPv4 space more > intensively than to try to sell end-users an IPv6 service > which can't meet their needs and would involve intolerable > levels of support calls and customer dissatisfaction even if > it met 90% of their needs. > > Robin Whittle Analyst, Paul Budde Communications > > (1) http://www.isi.edu/~johnh/PAPERS/Heidemann08a.pdf, > http://www.firstpr.com.au/ip/host-density-per-prefix/ > > (2) > http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup > > _______________________________________________ > 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 the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From jmorrison at bogomips.com Mon Jun 9 18:44:35 2008 From: jmorrison at bogomips.com (John Paul Morrison) Date: Mon, 09 Jun 2008 15:44:35 -0700 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: References: Message-ID: <484DB253.9090508@bogomips.com> On 6/9/2008 2:39 PM, Ted Mittelstaedt wrote: > Robin, the problem here is summarized by the old Star Trek quote > "The needs of the many outweigh the needs of the few" and On 6/9/2008 10:32 AM, Ted Mittelstaedt wrote: > If Brian just WANTS a portable block of IPv6 because he thinks it > would be "cool to have" or that it would make him "special" then > I'm sorry, but the Internet has been > a commercial network for over a decade now, we really don't want > a bunch of small fry experimenters on it anymore. He needs to do > what everyone else does and work within the system and get his > numbering from someone larger. Or if he must experiment, then he > can go to work for some larger network, where his experimenting will > be supervised by someone more knowledgeable. > So make up your mind already! Is the Internet a commercial network, closed to garage do it-your-selfers and future innovators as you argue, or some kind of communal resource, shepherded by the wise old sages of the Internet for the benefit of the unwashed (but TCP/IP clothesline dried) masses?? I detect more than just a little sanctimonious BS here. You're telling one person wanting portable v6 addresses to shut up and go home, because the Internet is the big leagues now. But then you're whining about NAT and the needs of the many. Well if the Internet is a commerce and business driven enterprise, then this thing called The Market will decide how/when/if IPv6 resolves things - to all the little guys stuck with NAT or address space shortage - tough luck. The needs of the many only matter when they're spending money. On the other hand, if the community needs are to count for anything, IPv6 address portability ought to be factored in precisely to take care of the little guys, early adopters, and those who've learned from IPv4 experience. If there are any lessons from the early days of IPv4, it's that if you got portable IPv4 space early on, you didn't get held hostage by service providers, didn't have to jump through address justification bureaucracy because of someone else's design and policy decisions, and you were given the chance to implement your network redundancy/multi-homing properly with BGP (again without being beholden to any service provider). > You forget that you are on a network that has a lot of other people > on it, and some of those people have severe problems due to the > looming shortage of IPv4. NAT and the other fancy footwork your advocating > isn't going to help them due to the nature of their problems. And, > once IPv4 DOES runout, the number of people with problems is going > to skyrocket. > > Of course, you don't give a God-dammed about those people, do you? > As long as YOU have your IP numbers, screw the rest of the bastards. > > Because, that is basically what your saying. > > I've been using the Internet since you thought that TCP/IP was > a line you hung clothes on to dry, and I didn't sign on to create > an exclusive club. Neither did everyone else that helped set it up. > It's a crying shame if your view prevails. > > Ted > > From tedm at ipinc.net Mon Jun 9 19:21:37 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 9 Jun 2008 16:21:37 -0700 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <484DB253.9090508@bogomips.com> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Paul Morrison > Sent: Monday, June 09, 2008 3:45 PM > To: 'PPML' > Subject: Re: [arin-ppml] IPv6 in the Economist > > > On 6/9/2008 2:39 PM, Ted Mittelstaedt wrote: > > Robin, the problem here is summarized by the old Star Trek > quote "The > > needs of the many outweigh the needs of the few" > and > On 6/9/2008 10:32 AM, Ted Mittelstaedt wrote: > > If Brian just WANTS a portable block of IPv6 because he thinks it > > would be "cool to have" or that it would make him "special" > then I'm > > sorry, but the Internet has been a commercial network for over a > > decade now, we really don't want a bunch of small fry > experimenters on > > it anymore. He needs to do what everyone else does and work within > > the system and get his numbering from someone larger. Or > if he must > > experiment, then he can go to work for some larger network, > where his > > experimenting will be supervised by someone more knowledgeable. > > > So make up your mind already! Is the Internet a commercial network, > closed to garage do it-your-selfers and future innovators as > you argue, > or some kind of communal resource, shepherded by the wise old > sages of > the Internet for the benefit of the unwashed (but TCP/IP clothesline > dried) masses?? > It is both. It is a commercial network that is shepherded by the wise old sages of the Internet. What you (apparently) fail to realise is the enormous amount of money those wise old sages threw into getting the Internet rolling. Someone complaining about a thousand bucks today for getting an IPv6 block? HAH! I've spent more on voice-grade MODEMS for personal use over the years than the computer your posting from cost you. $1K? HAH! That's CHEAP! For an experimenter. > I detect more than just a little sanctimonious BS here. > You're telling > one person wanting portable v6 addresses to shut up and go > home, because > the Internet is the big leagues now. > But then you're whining about NAT and the needs of the many. Well if > the Internet is a commerce and business driven enterprise, then this > thing called The Market will decide how/when/if IPv6 resolves > things - > to all the little guys stuck with NAT or address space > shortage - tough > luck. The needs of the many only matter when they're spending money. > Once more a person confused on how private businesses use publically funded infrastructure to make a living. There is not a commercial market in the world that isn't HEAVILY dependant on government involvement. And as more and more of the world's information becomes available on the Internet, the Internet is becoming one of those rare things where the "higher ideals" of equal access to knowledge for all people, which the old guard always wanted, just happens to also be in tune with the commercial needs of faster and more complete communication to all people. Neither this ideal, nor the need of faster and more extensive communication, is served by limiting the growth of the Internet to all people, all places. Pushing IPv4 is pushing a system that once IPv4 runout happens, feudalizes the very structure of the Internet. You are now creating a network where those who were on stay on, those who weren't, cannot get on. You are also halting the ability of commercial entities to reach customers who are "fenced out" and cannot obtain IPv4 because there isn't any more of it. In short, it's short term gain that costs a lot more over the long term than you gain now. If your in favor of continuing IPv4 past runout, and not agressively moving to IPv6, your in favor of keeping the US social Security system as it stands now, where current workers incur ever larger future liabilities. It's exactly the same principle. > On the other hand, if the community needs are to count for anything, > IPv6 address portability ought to be factored in precisely to > take care > of the little guys, early adopters, and those who've learned > from IPv4 > experience. If there are any lessons from the early days of > IPv4, it's > that if you got portable IPv4 space early on, you didn't get held > hostage by service providers, The hands down biggest way that people were held hostage by service providers is because they used public IP numbering internally, and in an IPv4 address, the address itself carries both host-specific info (which is the same from subnet to subnet) and network-specific info (which changes from provider to provider) That changed with the advent of NAT. It also changes with the advent of IPv6 because the hosts don't need to be numbered with network-specific info. Search the list archives on renumbering if you don't recall that discussion. > didn't have to jump through address > justification bureaucracy because of someone else's design and policy > decisions, and you were given the chance to implement your network > redundancy/multi-homing properly with BGP (again without > being beholden > to any service provider). > BGP as a protocol cannot work if every host on the Internet had a separate routing slot. This is NOT an IPv6 issue. It is a BGP issue. However just because BGP cannot work that way does not mean that large networks cannot work that way. Consider the world's VISA/MasterCard credit card network. At any given instant in time, ANY visa number on ANY credit card could be swiped through ANY machine ANYWHERE in the world to pay for something. Yet, that network operates fine. Thus, it's possible to build a large network where there's no commonality in IP addressing. So, quit blaming IPv6 for this - if you think it's important, then figure out how VISA does it and adapt the concept to the Internet. Ted From info at arin.net Tue Jun 10 09:30:54 2008 From: info at arin.net (Member Services) Date: Tue, 10 Jun 2008 09:30:54 -0400 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run out In-Reply-To: <48343386.4060700@arin.net> References: <48343386.4060700@arin.net> Message-ID: <484E820E.1060605@arin.net> > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. The ARIN Advisory Council shepherds are Marla Azinger and Scott Leibrand. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts the proposal, > it will be posted as a formal policy proposal to PPML and it will be > presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision via the PPML. If a proposal is not > accepted, then the author may elect to use the petition process to > advance their proposal. If the author elects not to petition or the > petition fails, then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this 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. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Equitable Distribution of IPv4 Resources before > IPv4 Run out > > Author: Michael K. Smith > > Proposal Version: 1 > > Submission Date: 05/20/2008 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Upon receipt of the last allocation of IPv4 address space to ARIN from > IANA, ARIN will reserve address space within the allocated block for > Organizations within the defined ARIN Organizational Size determinations > (Extra Small, Small, Large, Extra Large) based upon the utilization > percentages for each group gathered from the statistics of the last two > IANA allocations to ARIN. In order to make the allocation percentages > mathematically feasible, the percentages will be rounded to the closest > whole number and, subsequently, the the closest bit boundary for > assignment the maximum allocation size for the Organization size as > defined by ARIN. > > Once the final IANA allocation is received, ARIN will publish the > allocation percentages that will be used for the final allocation to the > PPML and ARIN website with the necessary documentation supporting the > assignment of percentages. > > Rationale: > > Description: > > This policy is designed to allow Organizations of the various defined > sizes to continue to receive address allocations from the last available > space and is slanted towards ensuring that organizations within the > Large, Small and Extra Small groups (and more specifically, the Small > and Extra Small groups) are able to get additional IPv4 space at the end > of the ARIN's ability to allocate such space. Given the statistics > below, it is likely that Extra Large Organizations would get most or all > of the last remaining space because given the amount they have been > allocated to date. This policy would help ensure that other > Organizations had a statistically equal opportunity to receive space as > well. > > > Example: > > Please see http://www.arin.net/statistics/index.html (Note: the > statistics are generated from IP allocations from 2006 and 2007). This > policy would require statistics to be limited to the previous 2 IANA > allocations to ARIN.) > > The present distribution as of May 20th 2008 is: > > Extra Large: 83.11% > Large: 6.75% > Small: 9.00% > Extra Small: 1.14% > > With this example, ARIN would reserve address space in the final IANA > allocation according to those percentages, to the extent that it is > mathematically possible within the existing range. In order to make the > math work, rounding would give us: > > Extra Large: 83% > Large: 7% > Small: 9% > Extra Small: 1% > > Who is affected: > > All ARIN Members will be affected by this policy. I assume that smaller > providers will benefit from having some space available to them beyond > where they would be with an organic allocation model, and the Extra > Large Organizations would experience some pain because, using the model > above, they would be excluded from being allocated 17% of the remaining > space, even if they had all of the necessary justifications for > receiving allocations from within that space. > > Policy Enforcement: > > ARIN staff will have to enforce this policy and ensure that allocations > stay within the published percentages. > > Financial and Liability Implications: > > Financially, there may be additional resources required by ARIN Staff to > allocate resources using this model. These resources might include > application development, staff training and tracking of allocations > based upon the model. > > ARIN may have legal liability should Organizations that were denied > space according to the model decide to contest the legality of the > policy in court. > > Timetable for implementation: Upon receipt of finall IANA allocation > (roughly 2011). > > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > From info at arin.net Tue Jun 10 09:33:15 2008 From: info at arin.net (Member Services) Date: Tue, 10 Jun 2008 09:33:15 -0400 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In-Reply-To: <4847F8EF.5070709@arin.net> References: <4847F8EF.5070709@arin.net> Message-ID: <484E829B.4040509@arin.net> > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. The ARIN Advisory Council shepherds are Paul Andersen and Heather Schiller. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts the proposal, > it will be posted as a formal policy proposal to PPML and it will be > presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision via the PPML. If a proposal is not > accepted, then the author may elect to use the petition process to > advance their proposal. If the author elects not to petition or the > petition fails, then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this 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. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Extend Experimental Renewal Timeframe > > Author: Azinger and Dave Meyer > > Proposal Version: 1 > > Submission Date: 4 June 2008 > > Proposal type: Modify > > Policy term: Permanent > > Policy statement: > > This proposal is to modify section 11.4 in the Policy Manual to extend > the experimental timeframe from one year to two years before having to > re-justify the use of an experimental block. > > Rationale: > > Currently anyone who has an experimental block is required to re-justify > his or her use after just one year. Reality shows that any true > experiment in technical nature that addresses the internet architecture > and routing will take at least two years given the constraints of time > and the simple fact of working out what could be a bug in the theory and > not a show stopper. This proposal just wishes to extend the timeframe > one year so that time isn?t wasted on re-justification. > > The revision of 11.4 would read as follows: > > The Numbering Resources are allocated on a lease/license basis for a > period of two years. The allocation can be renewed on application to > ARIN providing information as per Detail One. The identity and details > of the applicant and the allocated Numbering Resources will be published > under the conditions of ARIN?s normal publication policy. At the end of > the experiment, resources allocated under this policy will be returned > to the available pool. > > Timetable for implementation: Immediate > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > From info at arin.net Tue Jun 10 09:34:42 2008 From: info at arin.net (Member Services) Date: Tue, 10 Jun 2008 09:34:42 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: <48493B0A.2070305@arin.net> References: <48493B0A.2070305@arin.net> Message-ID: <484E82F2.8000400@arin.net> > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. The ARIN Advisory Council shepherds are Owen DeLong and Matt Pounsett. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts the proposal, > it will be posted as a formal policy proposal to PPML and it will be > presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision via the PPML. If a proposal is not > accepted, then the author may elect to use the petition process to > advance their proposal. If the author elects not to petition or the > petition fails, then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this 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. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Dedicated IPv4 block to facilitate IPv6 deployment > > Author: Alain Durand > > Proposal Version: 1.0 > > Submission Date: 6/6/2008 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > 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; > > 6) recipient organizations must be members in good standing of ARIN. > > > Rationale: > > Rationale for reserving IPv4 space: > > This policy provides predictability on how the end game of IPv4 is going > to be played after IANA completion. It will facilitate IPv6 deployment > by ensuring that some small chunks of IPv4 space will remain available > for a long time to ease the co-existence of IPv4 & IPv6. > > Rationale for reserving a contiguous /10 > > This is a balance between setting aside too much space and not having > enough to facilitate IPv6 deployment for many years. Out of the last /8, > that would leave the equivalent of 3 /10 to ARIN either for business as > usual or for other policies in the spirit of this one. > > A /10 represents 4,194,304 IP addresses, If all of them were to be used > in NAT-PT or NAT464 type devices with a consolidation factor of 100 > users behind each IP address, that would represent about 400 million users. > > Most networks today filter IPv4 announcements more specific than /24. > This policy creates allocations & assignment prefixes as long as /28. > Allocating out of a contiguous block will mitigate the impact of this > policy on filter lists. > > Rationale for minimum size allocation of /28 > > This minimum size allocation will put a cap at 250k additional entries > in the global IPv4 routing table. > > Rationale for maximum size allocation of /24 and for the 6 month delay > between allocations > > This maximum allocation size coupled with the requirement of a 6 months > delay between allocations will prevent hoarding and make sure this pool > will last several years. > > Rationale for forced renumbering for further allocation > > The minimum allocation size of /28 may create a huge increase in the > IPv4 routing table size. Forcing renumbering for subsequent allocations > under this policy will somehow limit the growth of the routing table > size by enabling the announcement of aggregated space. It is expected > that the savings in routing table entries will outweigh the pain of > forced renumbering. > > However, renumbering is never an easy task, so it should only be > considered as last resort. it is expected that sparse allocation > techniques will prevent the need of force renumbering for a fairly long > time. > > Note: This policy proposal hints that the /10 should come out of the > last /8 received by ARIN from IANA. However, it does not say so > explicitly, leaving the final decision up to the ARIN staff. > > > Timetable for implementation: > > As soon as ARIN gets its last /8 allocation from IANA. > > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > From dean at av8.com Tue Jun 10 10:50:23 2008 From: dean at av8.com (Dean Anderson) Date: Tue, 10 Jun 2008 10:50:23 -0400 (EDT) Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: Message-ID: On Mon, 9 Jun 2008, Ted Mittelstaedt wrote: > Dean is our Jeremiah Wright Jr. I guess you must think history > has labeled the current US presidential campaign "a collection > of bickering adults in their mother's basements" I strongly object to being compared to a racist. I have never espoused racist views on anything. And, indeed, I've stood up against the people who do. A small group of people associated with Board Member Vixie have repeatedly spread the most vicious lies about me to misrepresent my current and past positions. Till now, I've thought the worst of these lies was their false claim that I've hijacked IP Address blocks (130.105/16 and 198.3.136/21). But asserting I am a racist or somehow like a racist is a _really_ vicious lie, indeed, more vicious than usual. If one were really concerned about how PPML might someday appear to historians, one might try avoiding the vicious lies and emotional attacks on well-reasoned and well-justified positions. It is an interesting juxtaposition of examples: that Senator Obama would disassociate himself from Rev. Wright, but Board Member Vixie continues to associate himself with SORBS and Matthew Sullivan, despite their lies about Anderson and AV8 Internet. It seems one is a role model demonstrating character to be emulated, and the other is demonstrating a discrediting degree of bad character. The followers led by bad character can't be good, either. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owen at delong.com Tue Jun 10 11:19:01 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 10 Jun 2008 08:19:01 -0700 Subject: [arin-ppml] simple question about money In-Reply-To: <16EB6880180498D368047414@hindolveston.reid.org> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <20080608143121.GA1890@vacation.karoshi.com.> <57E0EC0682885176731FABBA@Visible-Trout.local> <484BF1C3.20007@psg.com> <16EB6880180498D368047414@hindolveston.reid.org> Message-ID: > To many of the rest of you: there's a difference between being a > member of ARIN and a customer of ARIN. At least I think there is. > Nowhere in the documentation do I see anything saying that you have > to be a member of ARIN in order to get a direct allocation. Of > course you can't fund the activities of ARIN with a membership fee > that's 1/100th of what it is now, but that's not what I was asking > about. > Close, but, not quite. Where you hit the distinction is in the difference between an allocation and an assignment. An allocation is intended to be subdivided into blocks which are delegated (either as allocations or assignments) to downstream customers. An assignment cannot be subdivided and is issued to an end user. In order to receive a direct allocation, you must be a subscriber member. To receive a direct assignment, you do not need to be an ARIN member at all, and, the fee structure is quite different. > If IPv6 is going to catch on with the technical public, the process > of using it needs to be sufficiently transparent that somebody who > spends 3 or 4 hours reading the website to figure out what to do > needs to come away with a sense of how to get things done. I didn't. > I know that many of you will just respond by telling me I'm stupid, > but I really did read what was there and try hard to understand it. > Nowhere did I see an explanation that the administration and > management of IPv6 is (presumably > by design) different from that of v4 and that the concepts don't > just move over. In particular, the whole supply-and-demand thing is > not properly explained or documented. There was a scarce resource > (v4). It is priced high, like many scarce resources. Now there is an > abundant resource (v6), with millions of times more availability. > Conventional economics suggests that the more abundant resource > ought to be a lot cheaper because of the principles of supply and > demand. It isn't. > There is no difference in this respect between the ARIN IPv4 and the ARIN IPv6 policies, actually. There are some subtle differences in the qualification and metrics used, but, in terms of the differences in fee structure, there are allocation and assignment fee tables for both IPv4 and IPv6. The assignment renewal fees for end-users are all $100/year regardless of number of resources or resource type. The subscriber member fees for IPv6 and IPv4 are different, but, not substantially so, and, you only pay the greater of your IPv6 or IPv4 fees, not the sum. Finally, I do not believe that the price is set at all as a result of routing table slots, but, as a result of ARINs operating costs, reserves planning, etc. and the number of subscribers, end users, etc. I do believe that some of the policies on who qualifies for address space are motivated in part by routing table slots and that the result of those policies may affect the numbers that feed into determining fees, but, I do not believe that the fees are directly tied to that issue. Owen From Fred.Wettling at Bechtel.com Tue Jun 10 11:20:52 2008 From: Fred.Wettling at Bechtel.com (Wettling, Fred) Date: Tue, 10 Jun 2008 11:20:52 -0400 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: References: Message-ID: Gentlemen, Please join the majority of the PPML community by focusing your ppml email on discussing / debating policy proposals, not personalities. Thanks - Fred From tedm at ipinc.net Tue Jun 10 13:19:28 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 10 Jun 2008 10:19:28 -0700 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: Message-ID: > -----Original Message----- > From: Dean Anderson [mailto:dean at av8.com] > Sent: Tuesday, June 10, 2008 7:50 AM > To: Ted Mittelstaedt > Cc: 'Paul G. Timmins'; 'PPML' > Subject: Re: [arin-ppml] IPv6 in the Economist > > > On Mon, 9 Jun 2008, Ted Mittelstaedt wrote: > > > Dean is our Jeremiah Wright Jr. I guess you must think history has > > labeled the current US presidential campaign "a collection of > > bickering adults in their mother's basements" > > I strongly object to being compared to a racist. I have > never espoused racist views on anything. And, indeed, I've > stood up against the people who do. > Dean, that's a great rant, a wonderful rant, I congradulate you on it. Too bad it is completely beside the point - since Jeremiah Wright Jr. WAS NOT accused of being a racist. He was accused of being Anti-American and unpatriotic by Jeff Goldblatt in a FOX news article. As FOX news has as much credibility as the National Enquirer does, their accusations aren't worth the paper they are printed on. But, your real familiar with worthless accusations, aren't you Dean? It was only after Goldblatt's article was picked up by the conservative pro-McCain commentators who ran with it, that Obama played the race card to distance himself from Wright. Notably, Obama was the ONLY person to accuse Wright of being racist. And the fact of the matter is that by your own admission, you ARE anti-American, at least, anti-American Registry of Internet Numbers. Ted From james at towardex.com Tue Jun 10 13:28:40 2008 From: james at towardex.com (James Jun) Date: Tue, 10 Jun 2008 13:28:40 -0400 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: References: Message-ID: <007701c8cb1f$6cebb330$12fc5dd8@HCMC.local> Gentlemen, Can both of you please relocate your bickering to a dedicated Dean Anderson vs. Ted Mittelstaedt Forum, away from PPML? I'm happy to host it for you if you need. james > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Tuesday, June 10, 2008 1:19 PM > To: 'PPML' > Cc: 'Dean Anderson' > Subject: Re: [arin-ppml] IPv6 in the Economist > > > > > -----Original Message----- > > From: Dean Anderson [mailto:dean at av8.com] > > Sent: Tuesday, June 10, 2008 7:50 AM > > To: Ted Mittelstaedt > > Cc: 'Paul G. Timmins'; 'PPML' > > Subject: Re: [arin-ppml] IPv6 in the Economist > > > > > > On Mon, 9 Jun 2008, Ted Mittelstaedt wrote: > > > > > Dean is our Jeremiah Wright Jr. I guess you must think history has > > > labeled the current US presidential campaign "a collection of > > > bickering adults in their mother's basements" > > > > I strongly object to being compared to a racist. I have > > never espoused racist views on anything. And, indeed, I've > > stood up against the people who do. > > > > Dean, that's a great rant, a wonderful rant, I congradulate you > on it. Too bad it is completely beside the point - since Jeremiah Wright > Jr. > WAS NOT accused of being a racist. He was accused of being Anti-American > and > unpatriotic by Jeff Goldblatt in a FOX news article. As FOX news > has as much credibility as the National Enquirer does, their > accusations aren't worth the paper they are printed on. > > But, your real familiar with worthless accusations, aren't you Dean? > > > It was only after Goldblatt's article was picked up by the conservative > pro-McCain commentators who ran with it, that Obama played the race card > to distance himself from Wright. Notably, Obama was the ONLY person to > accuse > Wright of being racist. > > And the fact of the matter is that by your own admission, you > ARE anti-American, at least, anti-American Registry of Internet Numbers. > > 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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. From tedm at ipinc.net Tue Jun 10 13:34:02 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 10 Jun 2008 10:34:02 -0700 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <007701c8cb1f$6cebb330$12fc5dd8@HCMC.local> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of James Jun > Sent: Tuesday, June 10, 2008 10:29 AM > To: 'PPML' > Subject: Re: [arin-ppml] IPv6 in the Economist > > > Gentlemen, > > Can both of you please relocate your bickering to a dedicated > Dean Anderson vs. Ted Mittelstaedt Forum, away from PPML? > I'm happy to host it for you if you need. > Somebody is still reading this thread? Cool!!! Wow!!! Ted From Matteson_Mike at emc.com Tue Jun 10 14:11:06 2008 From: Matteson_Mike at emc.com (Matteson_Mike at emc.com) Date: Tue, 10 Jun 2008 14:11:06 -0400 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <007701c8cb1f$6cebb330$12fc5dd8@HCMC.local> References: <007701c8cb1f$6cebb330$12fc5dd8@HCMC.local> Message-ID: <2A22ECE278A6604A84476172F106BFCE02726D8C@CORPUSMX50A.corp.emc.com> I'll second that, as another small voice crying out in the wilderness... It would be very nice if this "debate" were taken off-line...or you could meet in a parking lot somewhere and duke it out. There has been little worth devoting the bandwidth this has taken up in recent days, and I wonder how many have taken advantage of the 'Unsubscribe' link at the bottom of the messages, as I am tempted to do. Regards, --MikeM-- -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of James Jun Sent: Tuesday, June 10, 2008 1:29 PM To: 'PPML' Subject: Re: [arin-ppml] IPv6 in the Economist Gentlemen, Can both of you please relocate your bickering to a dedicated Dean Anderson vs. Ted Mittelstaedt Forum, away from PPML? I'm happy to host it for you if you need. james > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Tuesday, June 10, 2008 1:19 PM > To: 'PPML' > Cc: 'Dean Anderson' > Subject: Re: [arin-ppml] IPv6 in the Economist > > > > > -----Original Message----- > > From: Dean Anderson [mailto:dean at av8.com] > > Sent: Tuesday, June 10, 2008 7:50 AM > > To: Ted Mittelstaedt > > Cc: 'Paul G. Timmins'; 'PPML' > > Subject: Re: [arin-ppml] IPv6 in the Economist > > > > > > On Mon, 9 Jun 2008, Ted Mittelstaedt wrote: > > > > > Dean is our Jeremiah Wright Jr. I guess you must think history has > > > labeled the current US presidential campaign "a collection of > > > bickering adults in their mother's basements" > > > > I strongly object to being compared to a racist. I have > > never espoused racist views on anything. And, indeed, I've > > stood up against the people who do. > > > > Dean, that's a great rant, a wonderful rant, I congradulate you > on it. Too bad it is completely beside the point - since Jeremiah Wright > Jr. > WAS NOT accused of being a racist. He was accused of being Anti-American > and > unpatriotic by Jeff Goldblatt in a FOX news article. As FOX news > has as much credibility as the National Enquirer does, their > accusations aren't worth the paper they are printed on. > > But, your real familiar with worthless accusations, aren't you Dean? > > > It was only after Goldblatt's article was picked up by the conservative > pro-McCain commentators who ran with it, that Obama played the race card > to distance himself from Wright. Notably, Obama was the ONLY person to > accuse > Wright of being racist. > > And the fact of the matter is that by your own admission, you > ARE anti-American, at least, anti-American Registry of Internet Numbers. > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From mueller at syr.edu Tue Jun 10 14:12:48 2008 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 10 Jun 2008 14:12:48 -0400 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <484D93A7.8040101@firstpr.com.au> References: <48495CF2.6040804@Dilkie.com><48495F40.30403@psg.com> <484D5D17.7010603@Dilkie.com> <484D93A7.8040101@firstpr.com.au> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9011DC930@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: arin-ppml-bounces at arin.net > "Nearly 85% of available addresses are already in use;". 1.7B IPv4 > addresses are handled by the routing system, of the 3.7B which are > available. Of these, probably only a few hundred million are > actually used (1). > > By continued use of Network Address Translation (NAT) and finer > slicing and dicing of IPv4 space, IPv4 space can be used much more > efficiently than at present. For instance, the map-encap proposals - > LISP, APT, Ivip and TRRP - currently being developed by the IRTF > Routing Research Group (2) would all facilitate much finer and more > efficient management of IPv4 space without further burdening the > core BGP routing system. > Robin: If as you say there are billions of allocated or assigned addresses that are not actually being used, wouldn't an intelligent address transfer policy (such as Policy Proposal 2008-2) do more to facilitate more efficient utilization of the IPv4 address space than NATs and "finer slicing and dicing?" Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org From dean at av8.com Tue Jun 10 16:59:30 2008 From: dean at av8.com (Dean Anderson) Date: Tue, 10 Jun 2008 16:59:30 -0400 (EDT) Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: <2A22ECE278A6604A84476172F106BFCE02726D8C@CORPUSMX50A.corp.emc.com> Message-ID: On Tue, 10 Jun 2008 Matteson_Mike at emc.com wrote: > There has been little worth devoting the bandwidth this has taken up > in recent days, Actually, there has been some significant discussion on the subject of IPv6 flaws. Compare the discussion between myself and Leo Bicknell. Of course, certain persons are opposed to any substantive discussion of IPv6 flaws and they disrupt any discussion of policy implications of those flaws. Indeed, their past success at such disruption is the reason for the flaws have persisted so long. So if honest people want to discuss IPv6 flaws and the policy implications of those flaws, please continue, and please ignore the dishonest personal attacks on me. So anyway, hopefully, we can learn as much as possible from these last few days. In the last couple days, there has been a number of irrational and angry attacks on me, as is all too typical. While this one raised my eyebrows, I don't take them very personally---I merely have to refute them to discredit the promoter and to make sure that people don't get the wrong impression from false claims. But I think the people making those attacks have been discredited sufficiently, even though they keep making additional false accusations. I think they can be ignored for a while. I think it is pretty obvious that I am not anti-American, that it is obvious that I am not anti-ARIN. And I think it is plain that discussing IPv6 flaws and policy implications is neither anti-American nor anti-ARIN. But this is the sort of shrill kind of exaggeration and fabrication that is typical of a particular group. In this case, asserting that I am racist or anti-American, or anti-ARIN is 'pretty far out in the weeds', as it were. Indeed, I am _FOR_ good and honest governance of ARIN and I am not alone in that goal. We are opposed to people who are dishonest and engage in transparently despicable lies. These last few days is just another example. Compare this: On Tue, 10 Jun 2008, Ted Mittelstaedt wrote: > since Jeremiah Wright Jr. WAS NOT accused of being a racist. With this: On Tue, 10 Jun 2008, Ted Mittelstaedt wrote: > Notably, Obama was the ONLY person to accuse Wright of being racist. So apparently, Mittelstaedt inconsistently concedes that Wright was indeed accused of being racist (which was the widely reported accuastion) even if he was also accused of something else. Such illogical and inconsistent claims are unfortunately all too typical of this particular group and pervades more than just their personal attacks. Similar inconsistency pervades their technical arguments and plans as well. But for me and others who have to argue the technical details, it is much harder to explain the technical issues to a non-technical group of decision makers. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From mueller at syr.edu Tue Jun 10 17:40:45 2008 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 10 Jun 2008 17:40:45 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <20080608143121.GA1890@vacation.karoshi.com.><57E0EC0682885176731FABBA@Visible-Trout.local><484BF1C3.20007@psg.com><16EB6880180498D368047414@hindolveston.reid.org> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9011DC936@SUEXCL-02.ad.syr.edu> > -----Original Message----- > > Finally, I do not believe that the price is set at > all as a result of routing table slots, but, as a > result of ARINs operating costs, reserves planning, > etc. and the number of subscribers, end users, etc. > > I do believe that some of the policies on who > qualifies for address space are motivated in part > by routing table slots and that the result > of those policies may affect the numbers that feed > into determining fees, but, I do not believe that > the fees are directly tied to that issue. > > Owen > Owen: This is an interesting comment. Brian Reid's comment stated that he had heard from Vixie that the pricing policy was designed to support route aggregation. And indeed, if the ability of routers to handle route announcements is a very scarce resource and needs to be conserved, and if a higher price for portable address assignments helps to conserve that resource, then few reasonable people would object. But if you think that is not the case, it raises a question: how would one find out what _does_ motivate the pricing policies? Are the economic assumptions underlying ARIN fees stated anywhere in ARIN documents? Are there archives of discussions regarding that topic? A post by M. Dillon indicated that fees were set by ARIN members/officers only, which is appropriate enough. However, he also expressed an opinion that the topic of address fees was off-limits for the public policy list. I would have to disagree with that. In the emerging environment of v4 depletion, etc., the fees people pay (directly or indirectly) for IP addresses will be one of _the_ major public policy issues for the next five years or so. It will have a major impact on address conservation, route aggregation, the v6 migration, etc. Of course, discussion of that issue here does not constitute some kind of a assertion that fee levels should be set here, but as the unclear responses to Brian's original question shows, everyone could benefit from a wider discussion of the relationship between address utilization and fee structures. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org From Lee.Howard at stanleyassociates.com Tue Jun 10 18:18:17 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 10 Jun 2008 18:18:17 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DC936@SUEXCL-02.ad.syr.edu> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40A2DD020@CL-S-EX-1.stanleyassociates.com> > how would one find out what _does_ motivate the pricing > policies? As Treasurer, I try to be as open and clear as possible. The original guidance provided when ARIN was formed was that fees should be set only high enough to cover ARIN's costs, including a sufficient reserve to provide stability. > Are the economic assumptions underlying ARIN fees > stated anywhere in ARIN documents? Other than the requirement that ARIN is a not-for-profit as defined by the IRS 501(c)6, there is no such statement in the Articles of Incorporation or Bylaws, and nothing in the Fee Schedule (which is already hard enough to read). There are also various public statements I've made, along the lines of "cover ARIN's costs." Others on the Board of Trustees have said much the same. > Are there archives of > discussions regarding that topic? You could search this PPML or the members mailing list (arin-discuss) here: http://www.arin.net/mailing_lists/index.html You can also search public policy and member meeting archives here: http://www.arin.net/meetings/minutes/index.html > > A post by M. Dillon indicated that fees were set by ARIN > members/officers only, which is appropriate enough. However, > he also expressed an opinion that the topic of address fees > was off-limits for the public policy list. I would have to > disagree with that. As a membership organization, ARIN operates as instructed by its membership. Part of ARIN's foundation is an open public policy process, but fees are generally not considered to be policy. > In the emerging environment of v4 > depletion, etc., the fees people pay (directly or indirectly) > for IP addresses will be one of _the_ major public policy > issues for the next five years or so. It will have a major > impact on address conservation, route aggregation, the v6 > migration, etc. Of course, discussion of that issue here does > not constitute some kind of a assertion that fee levels > should be set here, but as the unclear responses to Brian's > original question shows, everyone could benefit from a wider > discussion of the relationship between address utilization > and fee structures. Of course, people can debate anything they want, within the constraints of the AUP, http://www.arin.net/mailing_lists/aup.html Lee > > Milton Mueller > Professor, Syracuse University School of Information Studies > XS4All Professor, Delft University of Technology > ------------------------------ > Internet Governance Project: > http://internetgovernance.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 the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From dean at av8.com Tue Jun 10 18:25:53 2008 From: dean at av8.com (Dean Anderson) Date: Tue, 10 Jun 2008 18:25:53 -0400 (EDT) Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: Message-ID: Lets try to get the substantive discussion going again. Leo Bicknell asserted that 99% of resolvers are EDNSO capable. I disputed this and asserted that even if true, 1% failure is too much to consider as stable. In fact, http://www.ripe.net/docs/ripe-352.html reports some (2005) statistic on EDNSO. Particularly, table 2 shows statistics for k root, and shows that about 34.5% of the queries contain the EDNSO option. I think this probably represents the percentage of EDNSO-capable recursive nameservers. It is interesting that ns-pri.ripe.net reports 70% queries with EDNSO option. This server responds to the people going to RIPE's web pages, and is probably more heavily weighted to the comparative 'DNS cognoscenti' who frequent the pages and services of RIPE-NCC. Even the DNS elites don't support EDNSO very well. Hmm. This paper by ICANN (2007) reports ICANNs view: http://www.icann.org/committees/security/sac018.pdf I think this document glosses over some of the problems, oversimplifies some of the issues, and ignores some obvious alternatives. The document considers only two alternatives and ignores any other possible alternative, particularly the alternative of separating IPv6 name resolution from IPv4 name resolution. For some reason, that alternative wasn't even considered. --Dean On Fri, 6 Jun 2008, Dean Anderson wrote: > On Fri, 6 Jun 2008, Leo Bicknell wrote: > > > In a message written on Fri, Jun 06, 2008 at 02:38:05PM -0400, Dean Anderson wrote: > > > > Fortunately DNS has also moved on. RFC 2671 specifies EDNS0, an > > > > extension to DNS to allow for larger packets. This was later > > > > required in RFC 3226 for all DNSSEC and A6 aware servers and > > > > resolvers. RFC 2874 may also be of interest. > > > > > > Most resolvers aren't DNSSEC or EDNSO aware. > > > > While technically correct I believe this statement is misleading. > > Well, let's see: > > > Virtually none of the end-user resolver libraries (e.g. the stuff > > you get with your Windows, Linux, OSX or other distro) are DNSSEC > > or EDNS0 aware out of the box. > > Yep. > > > However, those end user resolvers > > are often crippled in much more significant ways, such as the > > complete and total inability to walk up and down the DNS tree. In > > short, most are incapable of even knowing they need to ask the DNS > > root anything, much less being able to construct the query. > > Yes, all in all, things are indeed a little worse than I described, but > this other breakage has been here for a while. In fact, the other > breakage is just another reason that a separate IPv6 resolver would have > been a good idea. There are a lot of uglies in DNS protocol that could > have been wholesale dumped with a new resolver and slightly different > protocol---minus the old uglies and plus the new stuff. These facts you > cite enhance and improve my argument that wrong decisions were made on > IPv6 DNS. These facts you cite hardly make my statements misleading. > > > in it. A very large percentage of those caching recursive name > > servers have DNSSEC and EDNS0 capability. > > I'm not sure I agree. I think (also without checking the code), that > djbDNS dnscache doesn't do DNSSEC or EDNSO. Indeed, perhaps the latest > versions of several popular DNS caching servers do support DNSSEC. Of > course, many people still run older versions of those servers that don't > have support for DNSSEC. That affects the actual percentages. > > > In short, yes, 99% of end user resolvers can't make a EDNS0 query, > > however those same resolvers always ask a caching server to make the > > query for them, and 99% of the time the caching server is capable and > > performing those queries on behalf of the user. > > Except the resolver still gets truncated data, and the supposed 1% of > clients that fail is still too much to be considered reliable. I think > the real unsupported percentage is probably much higher, but I won't > make up numbers---there should be a way to measure this. The result is > that, as I said originally: > > Dean Anderson wrote: > > DNS is very severely broken in IPv6. This non-technical reason is that > > certain root operators want to keep their monopolies on anycast sales, > > and so (for technically inexplicable reasons), they have advocated > > mixing IPv6 and IPv4, and silenced dissent in apparent violations of > > anti-trust law. So, there are no IPv6 root nameservers. Instead, one > > mixes IPv6 DNS records with IPv4 DNS records on the same nameserver. > > This totally unnecessary mixing creates stability problems for both > > IPv4 and IPv6. One has to remove IPv4 NS records to make room for > > IPv6 records, so any effort to deploy IPv6 comes at the expense of > > IPv4 stability. While bad enough, that isn't the worst part. > > > > What's worse is that the DNS resolver implementations are broken as > > well. One can't just create IPv6 root nameservers because the > > resolvers don't do the right thing--there is no IPv6-specific resolver > > which could use different root nameservers for IPv6. IPv4 and IPv6 > > have to be mixed at the roots on down. Until this is fixed, IPv6 > > won't really be very useful or else both won't be stable. Altering > > and updating resolvers on every computer is a very time-consuming job > > to say the least. So, I think IPv6 won't be taking over in 3 years, > > and IPv4 won't be going away in 3 years. > > Having drilled into the details quite a bit, my statement above still > stands. None of my statements have been misleading or incorrect. > > Others can minimize facts to support their view, and maximize other > facts, but they shouldn't be allowed to alter the facts to the point of > creating a false impression that IPv6 is ready for deployment as is. The > current DNS approach is fraught with avoidable problems that negatively > affect the stability of IPv4. The current DNS root operators and DNS > protocol definers, in fact, haven't been doing such a good job. > > > And I believe this is likely to be my last reply on the topic, as > > we are now quite far from anything that is ARIN related. > > Altering the technical details are indeed beyond the scope of PPML---we > can't fix any of these problems directly. But the _policy_ affected by > the technical details and problems isn't beyond the scope of PPML. > Policy makers ought to understand the technical details---that's > necessary to make good policy. The policy makers just can't change the > technical details; that's the job of others, as Leo points out. > > Those claiming that IPv6 is ready for widespread deployment now are > simply not giving a reliable picture of the true status of IPv6; They do > not cite the dissent to their view; they do not explain the problems yet > to be overcome, nor do they even imply that there are significant > obstacles to be overcome. We cannot adopt IPv6 policy on the basis of > near-deceptions about the state of IPv6. People cannot be allowed to > make unsubstantiated claims about IPv6 and its various impacts on IPv4 > without being refuted. Policies cannot be adopted on the basis of such > unsubstantiated assertions. > > My (high level) statement [quoted above] just illuminates problems that > do indeed exist and usually aren't acknowledged by IPv6 promoters. [kind > of like Bush Admin. didn't acknowledge dissents in intelligence data > about Iraq---Indeed, NY Times today has a story that I can just about > rewrite word for word, only changing a few key terms and names.] > > > > For those who want to continue the discussion elsewhere, any or all > > of these may be appropriate: > > Err, IPv6 public policy remains appropriate to PPML. So the high level > discussion is appropriate. The lists you cite are appropriate for some > kinds of discussion---perhaps actually fixing the problems I cite. But > the lists you cite are not policy lists, and don't decide IPv6 policy at > ARIN. IPv6 policy at ARIN is for PPML. > > > http://www.ietf.org/html.charters/dnsext-charter.html > ^^^^ DNS Protocol definition. Our discussion isn't protocol > definition. Ours is policy in light of protocol flaws. > > > http://www.ietf.org/html.charters/dnsop-charter.html > ^^^^ Formerly included DNS root operations. There is a current > effort to remove Root DNS operations from the charter. This charter > change effort started in response to Anycast issues, to try to assert > and then define than DNS Root Anycast problems are off-topic for DNSOP. > > > http://www.icann.org/committees/dns-root/ > ^^^^ aka the RSSAC, closed except to root operators. > > > Have a good weekend, > > --Dean > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean at av8.com Tue Jun 10 18:47:57 2008 From: dean at av8.com (Dean Anderson) Date: Tue, 10 Jun 2008 18:47:57 -0400 (EDT) Subject: [arin-ppml] simple question about money In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DC936@SUEXCL-02.ad.syr.edu> Message-ID: Good comment. Inline On Tue, 10 Jun 2008, Milton L Mueller wrote: > > > -----Original Message----- > > > > Finally, I do not believe that the price is set at > > all as a result of routing table slots, but, as a > > result of ARINs operating costs, reserves planning, > > etc. and the number of subscribers, end users, etc. > > > > I do believe that some of the policies on who > > qualifies for address space are motivated in part > > by routing table slots and that the result > > of those policies may affect the numbers that feed > > into determining fees, but, I do not believe that > > the fees are directly tied to that issue. > > > > Owen > > > > Owen: > This is an interesting comment. Brian Reid's comment stated that he had > heard from Vixie that the pricing policy was designed to support route > aggregation. And indeed, if the ability of routers to handle route > announcements is a very scarce resource and needs to be conserved, and > if a higher price for portable address assignments helps to conserve > that resource, then few reasonable people would object. I think that if router resources are indeed a very scarce resource, that it is ISPs that ought to set that price/resource policy, not ARIN. IPv6 was meant to have essentially infinite space: everyone can have a block of portable address space. Of course, it may cost to get it routed...But that isn't ARINs balliwick, and ARIN has no business influencing that through allocation policy. Here also I question what are the interests of ARIN vs the interests of the Board Members and a very small group of companies [Nanog] in control of all the Board seats. And I note that previously, many in Nanog opposed accepting longer prefixes from classful /16 (former class B's). Their objection then was impact on router memory limitations on the routers in their networks; they would have to spend money to upgrade their routers [particularly Verio]. > But if you think that is not the case, it raises a question: how would > one find out what _does_ motivate the pricing policies? Are the economic > assumptions underlying ARIN fees stated anywhere in ARIN documents? Are > there archives of discussions regarding that topic? You can find the ARIN board meeting minutes through the ARIN website. I don't know if you'll find much. > A post by M. Dillon indicated that fees were set by ARIN > members/officers only, which is appropriate enough. However, he also > expressed an opinion that the topic of address fees was off-limits for > the public policy list. I would have to disagree with that. I'd have to agree with Dr. Mueller. This topic is on-topic for PPML. I note the Mr. Dillon is one of the NANOG members whom I often point out. In anycase, Mr. Dillon does not select topics for the list, and does not offically represent ARIN in any capacity, but is just an ARIN member. > In the emerging environment of v4 depletion, etc., the fees people pay > (directly or indirectly) for IP addresses will be one of _the_ major > public policy issues for the next five years or so. It will have a > major impact on address conservation, route aggregation, the v6 > migration, etc. Of course, discussion of that issue here does not > constitute some kind of a assertion that fee levels should be set > here, but as the unclear responses to Brian's original question shows, > everyone could benefit from a wider discussion of the relationship > between address utilization and fee structures. I agree. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From bicknell at ufp.org Tue Jun 10 19:09:46 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 10 Jun 2008 19:09:46 -0400 Subject: [arin-ppml] IPv6 in the Economist In-Reply-To: References: Message-ID: <20080610230945.GA44116@ussenterprise.ufp.org> In a message written on Tue, Jun 10, 2008 at 06:25:53PM -0400, Dean Anderson wrote: > In fact, http://www.ripe.net/docs/ripe-352.html reports some (2005) > statistic on EDNSO. Particularly, table 2 shows statistics for k root, > and shows that about 34.5% of the queries contain the EDNSO option. I > think this probably represents the percentage of EDNSO-capable recursive > nameservers. I suspect there are several problems with this data point. Production quality EDNS0 capable servers were not widely available until around 2001 or so, and with no direct driver to "have to have EDNS0" most upgrades came as a result of natural software upgrades for other reasons (e.g. new platforms). As such, I would suspect 2005 was still in the uptake window. Also, it's well known that root servers query loads are "special", in that a large percentage (70-90%, depending on how measured) are "trash". Queries for non-existent TLD's due to typos and the like. Many of these are the result of particularly badly broken software, often repeating the same broken query thousands of times per hour. That said, the good folks at RIPE have provided more recent data. From earlier in the year when AAAA glue was added: http://www.ripe.net/news/k-root-service-IPv6-glue.html So in not quite 3 years we've gone from 34.5% to 60%, at the root, with the caveats listed above. Also interesting is they study TCP queries, to see if rather than doing EDNS0 the clients fell back to TCP. The answer is no, there was no change. Also, TCP queries come in at 0.5 qps, while queries peak at ~14,000qps. > It is interesting that ns-pri.ripe.net reports 70% queries with EDNSO > option. This server responds to the people going to RIPE's web pages, > and is probably more heavily weighted to the comparative 'DNS > cognoscenti' who frequent the pages and services of RIPE-NCC. Even the > DNS elites don't support EDNSO very well. Hmm. I would love to see updated statistics for ns-pri, as I believe it is a much more representative case than a root server. Given the change seen at K-Root I would hope ns-pri is above 90% by this time, hopefully well above. I also point out that while ns-pri is an order of magnitude less "unusual" than k.root in terms of the type of queries it receives it is still special in another way worth noting. I believe it almost exclusively hosts in-addr.arpa reverse domains. I'm not sure if I think that may cause it's numbers to be skewed in any particular direction; but it does say to me that we're missing the data point of a large, authortative, forward only nameserver for comparison. > This paper by ICANN (2007) reports ICANNs view: > http://www.icann.org/committees/security/sac018.pdf Appendix E of that paper is quite informative. There are 9 servers that don't support EDNS0 listed. Of those 9, at least two are so obsolete as to be funny (BIND 4.x servers), JDNSS is self documented as a "leaf" (their word not mine) server at http://sourceforge.net/projects/jdnss/ and per the README does not do iterative or recursive lookups, and QuickDNS seems to actually be DNS management software, and not a DNS server. So to me, those four aren't even important. So that leaves 5 servers, of which only two seem to me likely for most of the unsupported problem, BIND 8.2.2, and Microsoft Server 2000. Both of those should be ending their life cycles in most organizations. So I simply draw a different conclusion than you do from the same data. It appears to me we have pretty widespread deployment that has occurred mostly under conditions where the feature was not needed (natural upgrades for other reasons). It appears all major packages likely to be deployed at this time support EDNS0, which means both if people upgrade for any reason they will get the feature; but also that if the feature were "required" the small percentage of the people who didn't have it would have a wide array of choices for an upgrade path. While there is a lot of room for improving DNS, and I might even agree some of the solutions are far from the best that could be done I see nothing in the data that suggests there is a problem that should hinder the roll out of IPv6. To that end, I also see nothing here that should have a significant bearing on ARIN IPv6 policy regarding IPv6. That's just my opinion though. -- 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: 187 bytes Desc: not available URL: From reid at mejac.palo-alto.ca.us Tue Jun 10 21:26:29 2008 From: reid at mejac.palo-alto.ca.us (Brian Reid) Date: Tue, 10 Jun 2008 18:26:29 -0700 Subject: [arin-ppml] simple question about money In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DC936@SUEXCL-02.ad.syr.edu> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <20080608143121.GA1890@vacation.karoshi.com.><57E0EC0682885176731FABBA@Visible-Trout.local><484BF1C3.20007@psg.com><16EB6880180498D368047414@hindolveston.reid.org> <7663C7E01D8E094989CA62F0B0D21CD9011DC936@SUEXCL-02.ad.syr.edu> Message-ID: <7534030E5DA1B54ADFC531E8@hindolveston.reid.org> > Brian Reid's comment stated that he had > heard from Vixie that the pricing policy was designed to support route > aggregation. Well, not exactly. What I intended to say was that after I read Paul Vixie's response here on this list (which all of you would have been able to read) I concluded that the pricing policy was designed to discourage a large routing table. I knew that one way of discouraging a large routing table was to discourage lone-wolf routes, which are the kind that would be necessary if I had non-portable address space. From reid at mejac.palo-alto.ca.us Tue Jun 10 21:29:01 2008 From: reid at mejac.palo-alto.ca.us (Brian Reid) Date: Tue, 10 Jun 2008 18:29:01 -0700 Subject: [arin-ppml] simple question about money In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40A2DD020@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40A2DD020@CL-S-EX-1.stanleyassociates.com> Message-ID: <7B15F7BAFC92EDD4A023F19A@hindolveston.reid.org> > fees are generally not considered to be > policy. Curious, because as far as I am concerned, fees are the policy that matters the most. OK, so the policies are used to *set* the fees, rather than *be* the fees. It would seem to me that policies leading to the setting of fees are about as central to the charter of a public policy forum as can be. From randy at psg.com Tue Jun 10 22:15:25 2008 From: randy at psg.com (Randy Bush) Date: Wed, 11 Jun 2008 11:15:25 +0900 Subject: [arin-ppml] simple question about money In-Reply-To: <7534030E5DA1B54ADFC531E8@hindolveston.reid.org> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <20080608143121.GA1890@vacation.karoshi.com.><57E0EC0682885176731FABBA@Visible-Trout.local><484BF1C3.20007@psg.com><16EB6880180498D368047414@hindolveston.reid.org> <7663C7E01D8E094989CA62F0B0D21CD9011DC936@SUEXCL-02.ad.syr.edu> <7534030E5DA1B54ADFC531E8@hindolveston.reid.org> Message-ID: <484F353D.6070501@psg.com> end sites are being given /48s etc by their upstreams. those which multi-home will announce the /48s to both sides. and, when ipv6 becomes needed for real business, folk from the business side of the company will come walking over and telling us that customers are complaining that they can not get their mtv from those /48s. and the filters will fall, just as they did with ipv4. and the v4 table is over half /24s. this is just business, not an ideal world. and, in the meantime, we the incumbents use routing table aggregation as a excuse for creating a barrier to entry. randy From rw at firstpr.com.au Tue Jun 10 22:37:02 2008 From: rw at firstpr.com.au (Robin Whittle) Date: Wed, 11 Jun 2008 12:37:02 +1000 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering Message-ID: <484F3A4E.5010802@firstpr.com.au> Hi Ted, In "Re: [arin-ppml] IPv6 in the Economist" you wrote in part: > It also changes with the advent of IPv6 because the hosts don't > need to be numbered with network-specific info. Just because there is an automated approach for hosts to set their own IP addresses and even to do this for a new network prefix while running from the old does not mean that all substantial end-user networks could easily move from one ISP to another, by renumbering from one PA prefix to another. In many cases, there are too many places where raw IP addresses are written into config files and ACLs for the administrators to reliably find these and securely, reliably and automatically change them. DNS zone files are an obvious instance. Also, I read somewhere that IPv6 auto-numbering isn't acceptable to all networks due to security concerns. Automation can lead to increased robustness, security and simplification of management - but it can also lead to the opposite. The only way these problems can be handled is with portable address space - PI space as currently managed by BGP (driving the routing scaling problem) or some new kind of PI space such as provided by map-encap schemes which does not excessively burden the BGP system. Even if portability wasn't really required by most or all end-user networks, IPv6 still doesn't provide the multihoming they need for PA prefixes. SHIM6 relies on the correspondent host having SHIM6 and does not provide router-centric, network-centralised, multihoming management, since it works at the level of hosts. Every Internet-facing host in the network would need to do SHIM6 and be robustly and securely coordinated. There was some debate about this on the IRTF Routing Research Group recently: Consensus? End-user networks need their own portable address space http://psg.com/lists/rrg/2008/msg01310.html The RRG is attempting to find and recommend (by 2008-03) a new routing and addressing architecture for the Internet so that many (millions or potentially billions) of end-user networks can get multihomed address space, suitable for traffic engineering in a way which makes it relatively easy for them to change ISPs. This needs to be achieved in a scalable way - most likely by creating a new form of address space management and associated routing (actually tunneling) mechanisms so millions of end-user networks get the kind of space they need, without each such network advertising one or more prefixes in the global BGP system. RRG home page, wiki and archives: http://www.irtf.org/charter?gtype=rg&group=rrg http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup http://psg.com/lists/rrg/2008/maillist.html The five map-encap proposals all provide portable address space in a scalable fashion, for both IPv4 and IPv6: LISP-NERD, LISP-ALT, APT, Ivip and TRRP. (See the wiki for links to these.) Quite a few folks argued against portable address space. But I think their objections are primarily based on the way portability causes scaling problems in today's system. I think they are highly sceptical of map-encap solutions and keen to see everyone on IPv6 ASAP - where they think portable space isn't required. None of them convinced me that substantial end-user networks would be happy with IPv6 host renumbering as a means of easily changing the entire network's prefix when choosing another ISP. The fact that most RIRs now offer PI space to end-user networks strikes me as pretty good proof of my argument that end-user networks typically need portability. > Pushing IPv4 is pushing a system that once IPv4 runout happens, > feudalizes the very structure of the Internet. You are now > creating a network where those who were on stay on, those who > weren't, cannot get on. I am not saying IPv4 is ideal. I am just saying that I think the optimism some people have about IPv6 being widely adopted in the next 10 years is highly unrealistic. It is a separate network from the IPv4 Internet and most Internet users only want to be on a network where everyone else is. NAT-PT doesn't seem to be a viable transition mechanism by which IPv6-only hosts can retain connectivity to the IPv4 Internet, as I wrote here: http://psg.com/lists/rrg/2008/msg01467.html An alternative suggestion was: http://tools.ietf.org/html/draft-ietf-v6ops-nat64-pb-statement-req which I haven't read yet. So how are ISPs (other than those with captive customers, such as in China perhaps) going to sell an IPv6-only service which won't do everything ordinary end-users want? All it takes is 10% of the end-users to find that some relatively obscure application won't work, and the service would be really hard to sell and be costly to support. > You are also halting the ability of commercial entities to reach > customers who are "fenced out" and cannot obtain IPv4 because > there isn't any more of it. I am not trying to push IPv4 or halt IPv6. I am trying to be realistic about the difficulties of sufficient end-users getting IPv6 connectivity so that most end-users won't need IPv4 connectivity. > In short, it's short term gain that costs a lot more over the > long term than you gain now. I agree - but why are end-users going to pay for an Internet service which only connects to a subset of other end-users? This is especially the case at the start, when only a tiny fraction of end-users have IPv6. End-users don't care whether the packets are carried by IPv4, IPv6 or a global network of relativistic carrier pigeons. I think most end-users require something like this: 1 - Their applications work as expected. For some end-users this includes obscure applications which don't do IPv6 and never will - either because the application is no longer updated, because the author doesn't update it to IPv6 or because they do not in fact update their applications. 2 - They can reach any website, send email anywhere, get any service, do peer-to-peer anything with whoever they want. 3 - The service must be installable without any fussing around with configurations, including probably the requirement that they don't have to upgrade their OS from XP, which many folks are keen to hold onto to avoid getting sucked into Vista and being unable to drive some of their old peripherals. Unfortunately, there is no upgrade path from IPv4 which meets these requirements. IPv6 proponents tend to have a much more flexible notion of what ordinary end-users want, such as them upgrading all their applications rapidly and only using a few protocols. These proponents tend to downplay the importance of P2P applications, but I understand this is a big part of the attraction of the Net for a large enough proportion of home users to constitute a significant barrier to selling IPv6-only services when the vast majority of end-users have no IPv6 connectivity. I am suggesting that IPv4 has a lot more life left in it than IPv6-advocates imagine. Maybe that will give us time to devise an upgrade path to something better - IPv6 or something else. But maybe that won't be possible and we will be locked into IPv4 with NAT forever. Attempting to tell the truth (and to learn and change my mind) about the barriers to the world transitioning to IPv6 does not affect what those barriers are. There could be many other barriers to IPv6 adoption. I don't know enough about DNS to properly follow what Leo Bicknell and Dean Anderson wrote in the "IPv6 in the Economist" thread. Perhaps there needs to be a wiki on barriers to IPv6 adoption. - Robin http://www.firstpr.com.au/ip/ivip/ From jmaimon at chl.com Tue Jun 10 23:29:33 2008 From: jmaimon at chl.com (Joe Maimon) Date: Tue, 10 Jun 2008 23:29:33 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <484F353D.6070501@psg.com> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <20080608143121.GA1890@vacation.karoshi.com.><57E0EC0682885176731FABBA@Visible-Trout.local><484BF1C3.20007@psg.com><16EB6880180498D368047414@hindolveston.reid.org> <7663C7E01D8E094989CA62F0B0D21CD9011DC936@SUEXCL-02.ad.syr.edu> <7534030E5DA1B54ADFC531E8@hindolveston.reid.org> <484F353D.6070501@psg.com> Message-ID: <484F469D.9010303@chl.com> Randy Bush wrote: > end sites are being given /48s etc by their upstreams. those which > multi-home will announce the /48s to both sides. Of which there are only 65k in a /32, which means all but the smallest of ISPs will need more over their effective lifetime, but thats another flame war. > and, when ipv6 becomes > needed for real business, folk from the business side of the company > will come walking over and telling us that customers are complaining > that they can not get their mtv from those /48s. and the filters will > fall, just as they did with ipv4. and the v4 table is over half /24s. > > this is just business, not an ideal world. In ideal world, the resources would be appropriately charged for at the point of consumption. The resources are global routing slots and registry operational expenses. That routing people rely on the registry fee to protect access to the routing slots resource is a hack. However, having the local ISP charge per advertised prefix equates to local actors selling global slots that weren't theirs to local customers. Basically the only intelligent course of action for any local actor would be to sell as many slots as possible, since if they wont, someone else will - and they will consume the same number of slots on everyone keeping a DFZ table either way. Perhaps a centralized enough (PKI or otherwise) routing registry could actually be viewed as the leasing of a routing slot, assuming sufficient take-up of filtering based on this registry. > > and, in the meantime, we the incumbents use routing table aggregation as > a excuse for creating a barrier to entry. > > randy Not sure I understood you correctly. Did you mean that incumbents perform routing table aggregation to create an entry barrier for small sized prefixes or did you mean that incumbents have created a PI entry barrier in response to routing table de-aggregation (or both)? Joe From tony.li at tony.li Wed Jun 11 00:26:35 2008 From: tony.li at tony.li (Tony Li) Date: Tue, 10 Jun 2008 21:26:35 -0700 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: <484F3A4E.5010802@firstpr.com.au> References: <484F3A4E.5010802@firstpr.com.au> Message-ID: Hi Robin |The only way these problems can be handled is with portable address |space - PI space as currently managed by BGP (driving the routing |scaling problem) or some new kind of PI space such as provided by |map-encap schemes which does not excessively burden the BGP system. Or, by some other scheme that we come up with. For example, in a GSE approach a host wouldn't need to know about it's routing goop, yet the site wouldn't need PI space. |Even if portability wasn't really required by most or all end-user |networks, IPv6 still doesn't provide the multihoming they need for |PA prefixes. Today. Our goal is to fix that. | SHIM6 relies on the correspondent host having SHIM6 |and does not provide router-centric, network-centralised, |multihoming management, since it works at the level of hosts. Every |Internet-facing host in the network would need to do SHIM6 and be |robustly and securely coordinated. In fact, that's not true. SHIM6 can cleanly operate with 'legacy' v6 hosts. |There was some debate about this on the IRTF Routing Research Group |recently: | | Consensus? End-user networks need their own portable address space | http://psg.com/lists/rrg/2008/msg01310.html And there was no consensus. |The RRG is attempting to find and recommend (by 2008-03) a new |routing and addressing architecture for the Internet so that many |(millions or potentially billions) of end-user networks can get |multihomed address space, suitable for traffic engineering in a way |which makes it relatively easy for them to change ISPs. This needs |to be achieved in a scalable way - most likely by creating a new |form of address space management and associated routing (actually |tunneling) mechanisms so millions of end-user networks get the kind |of space they need, without each such network advertising one or |more prefixes in the global BGP system. It's actually very unlikely that we will resort to a tunneling/encapsulation mechanism. They are too cumbersome, architecturally unclean, and fraught with MTU issues. My hope is that we do something better. |Quite a few folks argued against portable address space. But I |think their objections are primarily based on the way portability |causes scaling problems in today's system. I think they are highly |sceptical of map-encap solutions and keen to see everyone on IPv6 |ASAP - where they think portable space isn't required. Well, think what you like. Other people have a slightly different perspective than you as to the urgency of dealing with the issues and the level of architectural cleanliness that we would like to deliver. I, for one, do not want RRG's legacy to be a giant kludge. Most people object not to the portability of a prefix but to its lack of aggregatability. That leads exactly to the scaling issues that we're trying to solve. Ideally, we will end up with a routing architecture where there are no non-aggregatable addresses for end sites and preferably even higher up the hierarchy. |None of them convinced me that substantial end-user networks would |be happy with IPv6 host renumbering as a means of easily changing |the entire network's prefix when choosing another ISP. Is this a comment about the technology? Or about you? ;-) |The fact |that most RIRs now offer PI space to end-user networks strikes me as |pretty good proof of my argument that end-user networks typically |need portability. In fact, it was intentionally done that way precisely because there is no decent routing and addressing architecture for the RIRs to follow. Post hoc, ergo propter hoc. |NAT-PT doesn't seem to be a viable transition mechanism by which |IPv6-only hosts can retain connectivity to the IPv4 Internet, as I |wrote here: | | http://psg.com/lists/rrg/2008/msg01467.html Which basically seems to claim that NAT can't work. I believe that we've shown the converse. Tony From rw at firstpr.com.au Wed Jun 11 02:05:20 2008 From: rw at firstpr.com.au (Robin Whittle) Date: Wed, 11 Jun 2008 16:05:20 +1000 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: References: <484F3A4E.5010802@firstpr.com.au> Message-ID: <484F6B20.7020903@firstpr.com.au> Hi Tony, You wrote: > |The only way these problems can be handled is with portable address > |space - PI space as currently managed by BGP (driving the routing > |scaling problem) or some new kind of PI space such as provided by > |map-encap schemes which does not excessively burden the BGP system. > > Or, by some other scheme that we come up with. For example, in a GSE > approach a host wouldn't need to know about it's routing goop, yet the site > wouldn't need PI space. That might be OK if you are working with a development and deployment timetable which involves doing nothing to directly help with the IPv4 routing scaling problem. Maybe I don't understand enough about GSE, but what about routers which filter addresses? That needs to be an IP address as far as I know. How can networks be built so that every instance of an IP address in a config file of some daemon or router can be found and securely and correctly changed when moving from one or more PA prefixes given by one or ISPs to the PA prefixes of other ISPs? Likewise securely and reliably updating the correct entries in DNS zonefiles? > |Even if portability wasn't really required by most or all end-user > |networks, IPv6 still doesn't provide the multihoming they need for > |PA prefixes. > > Today. Our goal is to fix that. If the RRG decides that it doesn't need to solve the IPv4 routing scaling problem, then there is plenty of time to come up with an IPv6 solution with a wider variety of potential techniques and fewer backward compatibility reasons than would be the case for an IPv4 solution. > | SHIM6 relies on the correspondent host having SHIM6 > |and does not provide router-centric, network-centralised, > |multihoming management, since it works at the level of hosts. Every > |Internet-facing host in the network would need to do SHIM6 and be > |robustly and securely coordinated. > > In fact, that's not true. SHIM6 can cleanly operate with 'legacy' v6 hosts. I recall that if host A the "correspondent host" and host B is multihomed with two or more PI prefixes, that both A and B need to be running additional SHIM6 code in their TCP/IP stack in order that A can send packets to another prefix when the one it was using doesn't work for some reason. If A didn't have the SHIM6 additions, it could operate with B, but only as long the prefix in which it accesses B still works. So to support multihoming, I recall that SHIM6 requires upgrades to both hosts. Still, I can't see how a network's multihoming can be reliably and securely controlled by the administrators if it requires hooks into all their hosts. Map-encap portability, multihoming etc. solves that problem without any host changes or the hosts having to be involved in multihoming at all. > |There was some debate about this on the IRTF Routing Research Group > |recently: > | > | Consensus? End-user networks need their own portable address space > | http://psg.com/lists/rrg/2008/msg01310.html > > And there was no consensus. Yes. There has been virtually no consensus on the RRG. That is no-one's fault. These are difficult issues and it is a self-selected group. > |The RRG is attempting to find and recommend (by 2008-03) a new > |routing and addressing architecture for the Internet so that many > |(millions or potentially billions) of end-user networks can get > |multihomed address space, suitable for traffic engineering in a way > |which makes it relatively easy for them to change ISPs. This needs > |to be achieved in a scalable way - most likely by creating a new > |form of address space management and associated routing (actually > |tunneling) mechanisms so millions of end-user networks get the kind > |of space they need, without each such network advertising one or > |more prefixes in the global BGP system. > > It's actually very unlikely that we will resort to a tunneling/encapsulation > mechanism. They are too cumbersome, architecturally unclean, and fraught > with MTU issues. My hope is that we do something better. The developers of the map-encap systems - LISP, APT, Ivip and TRRP - have a different view. There may be enough active members of the RRG to form a rough consensus with your view, which is contrary to the intention of the map-encap developers (as far as I know) to work on IPv4 first. In that case, the RRG will proceed to work towards a more ambitious goal of an architecturally cleaner IPv6-only solution, over a longish time-span. But that would involve leaving the IPv4 routing scaling problem to grow increasingly worse until by some combination of events, enough end-users decide to adopt IPv6-only addresses sufficient to halt or reverse the IPv4 problem. This is why the question of IPv6 adoption is so crucial to the RRG deciding whether or not to develop a solution for IPv4 ASAP. My approach to the MTU problems of map-encap schemes is here: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ > |Quite a few folks argued against portable address space. But I > |think their objections are primarily based on the way portability > |causes scaling problems in today's system. I think they are highly > |sceptical of map-encap solutions and keen to see everyone on IPv6 > |ASAP - where they think portable space isn't required. > > Well, think what you like. Other people have a slightly different > perspective than you as to the urgency of dealing with the issues and the > level of architectural cleanliness that we would like to deliver. I, for > one, do not want RRG's legacy to be a giant kludge. Sure, there are major differences in opinion about this. I think what I like and try to learn from others to think better. Map-encap is giant and it is a kludge to the extent that it adds stuff to an originally simple Internet. But that simple Internet can't scale properly, or support mobility properly. I think a well designed map-encap system with real-time control (Ivip) is the best solution for IPv4 and IPv6, not least because it removes a lot of complexity from the ITRs by having the end-user directly control the mapping, rather than building in multihoming restoration decisions into the ITRs and therefore the map-encap system. Also, this is the only way I can imagine of supporting scalable, generally path-optimal, mobility: http://www.firstpr.com.au/ip/ivip/#mobile This looks good for both IPv4 and IPv6. Still, I can't see how the world is going to break the IPv4 habit and move to IPv6, since the transition mechanisms are so problematic. My guess is that IPv4 will persist for at least a decade and probably more, with or without a routing scalability fix. Even if the RRG doesn't recommend one, someone else might be motivated to create one. For instance, the Ivip model of providing finely sliced PI space may well be a promising commercial proposition. The TTR mobility extensions should be much more commercially attractive. All this could be done for IPv4 without IETF involvement. I am not suggesting this should happen, but if the IETF remains so focused on IPv6 it does not develop an IPv4 fix then the rest of the world, using IPv4, may finds commercial Ivip-like systems attractive for portability, multihoming and global mobility. > Most people object not to the portability of a prefix but to its lack of > aggregatability. That leads exactly to the scaling issues that we're trying > to solve. Ideally, we will end up with a routing architecture where there > are no non-aggregatable addresses for end sites and preferably even higher > up the hierarchy. Yes, but map-encap removes the aggregatability problem by bundling potentially thousands of EID-prefixes (micronets) into one BGP-managed prefix. It provides portable address space, and with the TTR extensions to Ivip, global mobility. The trick is to make the map-encap system much more scalable than BGP's global system of each DFZ router conversing with its peers. I believe this is not hard to do, including with real-time control of ITRs as in Ivip. > |None of them convinced me that substantial end-user networks would > |be happy with IPv6 host renumbering as a means of easily changing > |the entire network's prefix when choosing another ISP. > > Is this a comment about the technology? Or about you? ;-) I was unconvinced by the counterarguments. > |The fact > |that most RIRs now offer PI space to end-user networks strikes me as > |pretty good proof of my argument that end-user networks typically > |need portability. > > In fact, it was intentionally done that way precisely because there is no > decent routing and addressing architecture for the RIRs to follow. Post > hoc, ergo propter hoc. I don't clearly understand this. IPv6 was always meant to involve purely PA space for end-user networks. End-user network administrators were supposed to be happy to multihome with SHIM6 and happy to change PA prefixes by the wonders of host auto-renumbering. I see no evidence that end-user networks are happy with either solution. My understanding is that in order to get end-user network IPv6 adoption going at all, the RIRs caved in to end-user requirements and therefore abandoned the purity of the official IPv6 doctrine, by offering PI prefixes for end-user networks. I understand that in doing this, they knew that if and when IPv6 is widely adopted this would replicate the routing swamp of IPv4. So I guess the RIRs are relying on the IETF -> IRTF -> RRG to come up with an architectural fix in time to prevent this getting too bad. > |NAT-PT doesn't seem to be a viable transition mechanism by which > |IPv6-only hosts can retain connectivity to the IPv4 Internet, as I > |wrote here: > | > | http://psg.com/lists/rrg/2008/msg01467.html > > Which basically seems to claim that NAT can't work. I believe that we've > shown the converse. NAT-PT was buried last year: http://tools.ietf.org/html/rfc4966 I understand that the fear was that these kludges are unacceptable - especially since they would tend to become part of the network and so become barriers to the ideal of unencumbered IPv6 end-to-end connectivity. (At least with map-encap, there are no host-level kludges, and the BGP system carries on as usual. It is a relatively clean system considering the enormity of what it provides.) The only replacement I know of is NAT64. The initial ID, one version only, in 2002: http://tools.ietf.org/html/draft-durand-ngtrans-nat64-nat46-00 In Feb 2008, updated in May, a requirements document: http://tools.ietf.org/html/draft-ietf-v6ops-nat64-pb-statement-req and yesterday a start at the NAT64 and DNS64 protocols: http://tools.ietf.org/html/draft-bagnulo-behave-nat64 So is the RRG going to say to today's Internet users something like this?: Don't worry about the IPv4 routing scaling problem. It will get worse, but before it gets too bad we will have IPv6 all sorted out, with a transition mechanism which most of you will all be happy with, and with a much better solution to the routing scaling problem than we feel like suggesting for IPv4. Yet 10 or so years of effort at a transition arrangement for IPv6 was junked last year and it is early days for the new plans. A quick read of the requirements document made me think the task is not going to be easy - and can probably be achieved only in ways which support a subset of the applications and protocols in wide use today. - Robin From tony.li at tony.li Wed Jun 11 02:56:22 2008 From: tony.li at tony.li (Tony Li) Date: Tue, 10 Jun 2008 23:56:22 -0700 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: <484F6B20.7020903@firstpr.com.au> References: <484F3A4E.5010802@firstpr.com.au> <484F6B20.7020903@firstpr.com.au> Message-ID: <62CA6272C0D04F419931B4620104675D@ad.redback.com> Hi Robin, |Maybe I don't understand enough about GSE, but what about routers |which filter addresses? Filters would be on the identifier. Please, please, please go read GSE. You may not like it, you may not agree with it, but until you grok it, you haven't seen a big chunk of the solution space. http://www.watersprings.org/pub/id/draft-ietf-ipngwg-gseaddr-00.txt |That needs to be an IP address as far as I |know. How can networks be built so that every instance of an IP |address in a config file of some daemon or router can be found and |securely and correctly changed when moving from one or more PA |prefixes given by one or ISPs to the PA prefixes of other ISPs? |Likewise securely and reliably updating the correct entries in DNS |zonefiles? Again, there would be no 'address'. Only 'routing goop' and 'identifiers'. Since identifiers are fixed and assigned to hosts, there would no issue with filtering, config files, DNS, etc. |> |Even if portability wasn't really required by most or all end-user |> |networks, IPv6 still doesn't provide the multihoming they need for |> |PA prefixes. |> |> Today. Our goal is to fix that. | |If the RRG decides that it doesn't need to solve the IPv4 routing |scaling problem, then there is plenty of time to come up with an |IPv6 solution with a wider variety of potential techniques and fewer |backward compatibility reasons than would be the case for an IPv4 |solution. Or... If we don't panic, spend the time to come up with a clean solution that we can all get behind, then we might find that we can apply it to v4 as well as v6. Or that once we have it, the thought of transitioning to v6 is suddenly less distasteful. Again, having a mechanism whereby end sites could be multi-homed, not have to fight and/or pay ARIN, and get reliable routing might well be seen as a benefit. |> In fact, that's not true. SHIM6 can cleanly operate with |'legacy' v6 hosts. | |I recall that if host A the "correspondent host" and host B is |multihomed with two or more PI prefixes, that both A and B need to |be running additional SHIM6 code in their TCP/IP stack in order that |A can send packets to another prefix when the one it was using |doesn't work for some reason. | |If A didn't have the SHIM6 additions, it could operate with B, but |only as long the prefix in which it accesses B still works. So to |support multihoming, I recall that SHIM6 requires upgrades to both |hosts. This is a circular argument. Yes, to get the benefits of SHIM6, you need to upgrade the host. To get maximal benefits, you need to upgrade the hosts at all multi-homed sites. Of course, those are also the most technologically adept sites, best prepared to upgrade, and the costs of upgrading are aligned with the beneficiaries, so that somehow all is aligned. Of course, you DO have to run Windows Update/OSX Software Update. My recollection is that you believe that won't happen. |Still, I can't see how a network's multihoming can be reliably and |securely controlled by the administrators if it requires hooks into |all their hosts. Control is at the CPE systems/firewalls, just as it is now. |Map-encap portability, multihoming etc. solves that problem without |any host changes or the hosts having to be involved in multihoming |at all. Except, of course, MTU issues, still unknown mapping issues, and legacy interaction issues. How did that help? |> It's actually very unlikely that we will resort to a |tunneling/encapsulation |> mechanism. They are too cumbersome, architecturally |unclean, and fraught |> with MTU issues. My hope is that we do something better. | |The developers of the map-encap systems - LISP, APT, Ivip and TRRP - |have a different view. There may be enough active members of the |RRG to form a rough consensus with your view, which is contrary to |the intention of the map-encap developers (as far as I know) to work |on IPv4 first. In that case, the RRG will proceed to work towards a |more ambitious goal of an architecturally cleaner IPv6-only |solution, over a longish time-span. Not yet. ;-( As you note, the active members of the RRG are a diverse bunch. | But that simple Internet |can't scale properly, or support mobility properly. Fine, but that doesn't exclude the remainder of the solution space. |Still, I can't see how the world is going to break the IPv4 habit |and move to IPv6, since the transition mechanisms are so problematic. Yeah, and we'll never get off of NCP either. You'd be amazed at what you can do with a little consensus and leadership. |My guess is that IPv4 will persist for at least a decade and |probably more, with or without a routing scalability fix. Agreed. We *want* this. What better way to de-risk transition than to make it possible to not transition? What if we simply transitioned because we *wanted* to? Because there was compelling value and benefit there? Much smoother, yes? |All this could be done for IPv4 without IETF involvement. I am not |suggesting this should happen, but if the IETF remains so focused on |IPv6 it does not develop an IPv4 fix then the rest of the world, |using IPv4, may finds commercial Ivip-like systems attractive for |portability, multihoming and global mobility. Or, we can just keep NATing. Carrier-class NAT anyone? ;-) |Yes, but map-encap removes the aggregatability problem by bundling |potentially thousands of EID-prefixes (micronets) into one |BGP-managed prefix. It provides portable address space, and with |the TTR extensions to Ivip, global mobility. Not at all clear. If every end site still gets a prefix, don't you end up with the same problem? To ensure that you have aggregation, you need to have a clear plan for aggregated identifier assignment. I still haven't found one that I find compelling. |> |The fact |> |that most RIRs now offer PI space to end-user networks strikes me as |> |pretty good proof of my argument that end-user networks typically |> |need portability. |> |> In fact, it was intentionally done that way precisely |because there is no |> decent routing and addressing architecture for the RIRs to |follow. Post |> hoc, ergo propter hoc. | |I don't clearly understand this. | |IPv6 was always meant to involve purely PA space for end-user |networks. End-user network administrators were supposed to be happy |to multihome with SHIM6 and happy to change PA prefixes by the |wonders of host auto-renumbering. | |I see no evidence that end-user networks are happy with either |solution. My understanding is that in order to get end-user network |IPv6 adoption going at all, the RIRs caved in to end-user |requirements and therefore abandoned the purity of the official IPv6 |doctrine, by offering PI prefixes for end-user networks. I |understand that in doing this, they knew that if and when IPv6 is |widely adopted this would replicate the routing swamp of IPv4. So I |guess the RIRs are relying on the IETF -> IRTF -> RRG to come up |with an architectural fix in time to prevent this getting too bad. Correct, they caved and they knew it. You can't use this to claim that they felt it was the right solution. If there was a solution that meant that end users didn't have to renumber and yet they weren't given portable addresses, this would not have been necessary. |> |NAT-PT doesn't seem to be a viable transition mechanism by which |> |IPv6-only hosts can retain connectivity to the IPv4 Internet, as I |> |wrote here: |> | |> | http://psg.com/lists/rrg/2008/msg01467.html |> |> Which basically seems to claim that NAT can't work. I |believe that we've |> shown the converse. | |NAT-PT was buried last year: | | http://tools.ietf.org/html/rfc4966 As an act of defiance by the NAT-haters. That doesn't mean that it's actually dead. Like Mary Queen of Scots, it will probably live again. The market wants it. The question is who will build it. |I understand that the fear was that these kludges are unacceptable - |especially since they would tend to become part of the network and |so become barriers to the ideal of unencumbered IPv6 end-to-end |connectivity. Yet, if they become a valuable transition tool, they will necessarily happen. Anyone remember PIX? |So is the RRG going to say to today's Internet users something like |this?: | | Don't worry about the IPv4 routing scaling problem. It will get | worse, but before it gets too bad we will have IPv6 all sorted | out, with a transition mechanism which most of you will all be | happy with, and with a much better solution to the routing | scaling problem than we feel like suggesting for IPv4. | |Yet 10 or so years of effort at a transition arrangement for IPv6 |was junked last year and it is early days for the new plans. A |quick read of the requirements document made me think the task is |not going to be easy - and can probably be achieved only in ways |which support a subset of the applications and protocols in wide use |today. Hopefully, the RRG will have something cleaner to say. In any case, I don't think that the RRG need address the users of the Internet. Most of them won't even care. As long as the bits flow, it won't matter to them. In actuality, the only folks we have to convince are ourselves. After that, it steamrolls. Tony From randy at psg.com Wed Jun 11 03:03:23 2008 From: randy at psg.com (Randy Bush) Date: Wed, 11 Jun 2008 16:03:23 +0900 Subject: [arin-ppml] simple question about money In-Reply-To: <484F469D.9010303@chl.com> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <20080608143121.GA1890@vacation.karoshi.com.><57E0EC0682885176731FABBA@Visible-Trout.local><484BF1C3.20007@psg.com><16EB6880180498D368047414@hindolveston.reid.org> <7663C7E01D8E094989CA62F0B0D21CD9011DC936@SUEXCL-02.ad.syr.edu> <7534030E5DA1B54ADFC531E8@hindolveston.reid.org> <484F353D.6070501@psg.com> <484F469D.9010303@chl.com> Message-ID: <484F78BB.3050303@psg.com> > Not sure I understood you correctly. Did you mean that incumbents > perform routing table aggregation to create an entry barrier for small > sized prefixes or did you mean that incumbents have created a PI entry > barrier in response to routing table de-aggregation (or both)? incumbents have created a barrier to entry in the belief in a demonstrated fantasy that we can reduce routing table size. randy From rw at firstpr.com.au Wed Jun 11 04:10:48 2008 From: rw at firstpr.com.au (Robin Whittle) Date: Wed, 11 Jun 2008 18:10:48 +1000 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: <62CA6272C0D04F419931B4620104675D@ad.redback.com> References: <484F3A4E.5010802@firstpr.com.au> <484F6B20.7020903@firstpr.com.au> <62CA6272C0D04F419931B4620104675D@ad.redback.com> Message-ID: <484F8888.4060909@firstpr.com.au> Hi Tony, You wrote: > |Maybe I don't understand enough about GSE, but what about routers > |which filter addresses? > > Filters would be on the identifier. > > Please, please, please go read GSE. You may not like it, you may > not agree with it, but until you grok it, you haven't seen a big > chunk of the solution space. I understand you are suggesting the RRG consider recommending a longer-term project of a radical revision of IPv6 along the lines of GSE: http://tools.ietf.org/html/draft-ietf-ipngwg-gseaddr-00 I haven't read this and I don't see anything to do with GSE in the RRG wiki: http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup If it is so significant then I would have thought that someone would have written it up as a proposal and done an 8 page summary and analysis document for it, as was provided for each of the map-encap and some other proposals. > |That needs to be an IP address as far as I > |know. How can networks be built so that every instance of an IP > |address in a config file of some daemon or router can be found and > |securely and correctly changed when moving from one or more PA > |prefixes given by one or ISPs to the PA prefixes of other ISPs? > |Likewise securely and reliably updating the correct entries in DNS > |zonefiles? > > Again, there would be no 'address'. Only 'routing goop' and 'identifiers'. > Since identifiers are fixed and assigned to hosts, there would no issue with > filtering, config files, DNS, etc. Without reading further, my impression is that you are proposing to forget about the routing scaling problem in the IPv4 Internet, and to forget about existing IPv6 usage, but to change IPv6 to use GSE - a proposal which seems to have flourished briefly around 1997 and not been heard of much since then. This is pretty radical and does not look promising to me. A quick scan of gseaddr-00 makes me think this requires major changes in every IPv6 router and host - both stack and applications. Is this the case? If so, maybe it might be best to fix the IPv4 problem so we have more time to re-jig IPv6 into something fundamentally better. I would not want to be on such a high-pressure mission as I think you are contemplating: let Rome burn while we convert another city into something very different from what it was meant to be, and by then the folks from Rome will happily want to come to live in the new city instead. Since the folks in Rome gave us the task of saving them from flames, I think their patience could be rather strained as the place goes up in smoke while we try to rebuild the other city. > |> |Even if portability wasn't really required by most or all end-user > |> |networks, IPv6 still doesn't provide the multihoming they need for > |> |PA prefixes. > |> > |> Today. Our goal is to fix that. > | > |If the RRG decides that it doesn't need to solve the IPv4 routing > |scaling problem, then there is plenty of time to come up with an > |IPv6 solution with a wider variety of potential techniques and fewer > |backward compatibility reasons than would be the case for an IPv4 > |solution. > > Or... If we don't panic, spend the time to come up with a clean solution > that we can all get behind, then we might find that we can apply it to v4 as > well as v6. Or that once we have it, the thought of transitioning to v6 is > suddenly less distasteful. GSE obviously can't be made to work with IPv4, unless you change IPv4 hosts and routers completely - in which case it is not IPv4 and is not backwards compatible with IPv4. I am increasingly perplexed by my understanding of your suggestions, which I admit may be faulty. > Again, having a mechanism whereby end sites could be multi-homed, not have > to fight and/or pay ARIN, and get reliable routing might well be seen as a > benefit. Sure, but to radically alter IPv6 . . . when there are already major problems getting anyone to use it . . . What would transition mechanisms look like for IPv4 and GSE-IPv6, or with current IPv6 and GSE-IPv6? > |> In fact, that's not true. SHIM6 can cleanly operate with > |'legacy' v6 hosts. > | > |I recall that if host A the "correspondent host" and host B is > |multihomed with two or more PI prefixes, that both A and B need to > |be running additional SHIM6 code in their TCP/IP stack in order that > |A can send packets to another prefix when the one it was using > |doesn't work for some reason. > | > |If A didn't have the SHIM6 additions, it could operate with B, but > |only as long the prefix in which it accesses B still works. So to > |support multihoming, I recall that SHIM6 requires upgrades to both > |hosts. > > This is a circular argument. Yes, to get the benefits of SHIM6, you need to > upgrade the host. To get maximal benefits, you need to upgrade the hosts at > all multi-homed sites. Of course, those are also the most technologically > adept sites, best prepared to upgrade, and the costs of upgrading are > aligned with the beneficiaries, so that somehow all is aligned. > > Of course, you DO have to run Windows Update/OSX Software Update. My > recollection is that you believe that won't happen. There are many more devices than PCs and servers. It is hard enough to update them, but harder still to update embedded devices. Map-encap doesn't require any host changes at all. > |Still, I can't see how a network's multihoming can be reliably and > |securely controlled by the administrators if it requires hooks into > |all their hosts. > > Control is at the CPE systems/firewalls, just as it is now. Hmm - maybe I need to revise my understanding of SHIM6. > |Map-encap portability, multihoming etc. solves that problem without > |any host changes or the hosts having to be involved in multihoming > |at all. > > Except, of course, MTU issues, still unknown mapping issues, and legacy > interaction issues. How did that help? I proposed a way around the MTU problems. I haven't received any critiques: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ "Legacy interaction" is handled with Ivip's Open ITRs in the DFZ (OITRDs). LISP does the same thing with their "Proxy Tunnel Routers" (PTRs). Ivip's fast push mapping system is described in some detail here: http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00 There's more work to do, but plenty of detail criticise if you think it can't be robust and be much more scalable than the current BGP approach. It is fast push to wherever the operators decide to place their full database query servers. Then, past that, to wherever the ITRs are, it is local fast pull, with fast, robust, notification of a mapping update from the full database query server to the ITR. > |> It's actually very unlikely that we will resort to a > |tunneling/encapsulation > |> mechanism. They are too cumbersome, architecturally > |unclean, and fraught > |> with MTU issues. My hope is that we do something better. > | > |The developers of the map-encap systems - LISP, APT, Ivip and TRRP - > |have a different view. There may be enough active members of the > |RRG to form a rough consensus with your view, which is contrary to > |the intention of the map-encap developers (as far as I know) to work > |on IPv4 first. In that case, the RRG will proceed to work towards a > |more ambitious goal of an architecturally cleaner IPv6-only > |solution, over a longish time-span. > > Not yet. ;-( > > As you note, the active members of the RRG are a diverse bunch. Indeed . . . > | But that simple Internet > |can't scale properly, or support mobility properly. > > Fine, but that doesn't exclude the remainder of the solution space. The solution space is wide open if you ignore IPv4. You have a longer time to do all sorts of things to IPv6, which hardly anyone outside the IETF really cares about compared to how they care about and rely upon the IPv4 Internet. We map-encap folk are preparin' to put out the fire where we live and make sure our potential future abode can't catch fire. I think you are ignoring the fire and concentrating on constructing a crystalline future, which I understand the attraction of. > |Still, I can't see how the world is going to break the IPv4 habit > |and move to IPv6, since the transition mechanisms are so problematic. > > Yeah, and we'll never get off of NCP either. > > You'd be amazed at what you can do with a little consensus and leadership. Consensus in the RRG to ignore the IPv4 Internet and direct the IETF to focus only on IPv6 could cause the IETF to further rely on IPv6 - something the rest of the world has not found it needs so far. If so, I predict the IPv4 Internet will be kept alive by hook or by crook, because most people simply don't want to move to an alternative Internet which doesn't work for them as well as the one they are using now. > |My guess is that IPv4 will persist for at least a decade and > |probably more, with or without a routing scalability fix. > > Agreed. We *want* this. What better way to de-risk transition than to make > it possible to not transition? What if we simply transitioned because we > *wanted* to? Because there was compelling value and benefit there? Much > smoother, yes? Almost no-one wants to transition to some other Internet which doesn't work like the current one. The long-term vision you have about the benefits is not shared by the great majority of end-users, who rely on unencumbered communications with all other end-users - something the IPv4 Internet does fine and which IPv6 won't for a long time. > |All this could be done for IPv4 without IETF involvement. I am not > |suggesting this should happen, but if the IETF remains so focused on > |IPv6 it does not develop an IPv4 fix then the rest of the world, > |using IPv4, may finds commercial Ivip-like systems attractive for > |portability, multihoming and global mobility. > > Or, we can just keep NATing. Carrier-class NAT anyone? ;-) Sure - better than resolving not to speak English any more and only communicating directly with folks who speak Esperanto. > |Yes, but map-encap removes the aggregatability problem by bundling > |potentially thousands of EID-prefixes (micronets) into one > |BGP-managed prefix. It provides portable address space, and with > |the TTR extensions to Ivip, global mobility. > > Not at all clear. If every end site still gets a prefix, don't you end up > with the same problem? No. I have been explaining this for a year now. The Ivip-arch ID has been available since July 2007. In Ivip, a Mapped Address Block is advertised in BGP as a prefix. OITRDs all advertise this and receive the packets. They split the address space up into micronets, according to the mapping information, and tunnel packets to ETRs. You could have a single /14 with 2^18 IP addresses. That could be as many as 2^18 micronets of one IP address each. Let's say the average micronet size was 8 IP addresses, that is still 2^15 micronets, for this many or somewhat fewer separate end-user networks, all with just a single addition to the DFZ routing table. > To ensure that you have aggregation, you need to > have a clear plan for aggregated identifier assignment. I still haven't > found one that I find compelling. My Ivip material which explains all this is plenty detailed enough for you or others to criticise. > |> |The fact > |> |that most RIRs now offer PI space to end-user networks strikes me as > |> |pretty good proof of my argument that end-user networks typically > |> |need portability. > |> > |> In fact, it was intentionally done that way precisely > |because there is no > |> decent routing and addressing architecture for the RIRs to > |follow. Post > |> hoc, ergo propter hoc. > | > |I don't clearly understand this. > | > |IPv6 was always meant to involve purely PA space for end-user > |networks. End-user network administrators were supposed to be happy > |to multihome with SHIM6 and happy to change PA prefixes by the > |wonders of host auto-renumbering. > | > |I see no evidence that end-user networks are happy with either > |solution. My understanding is that in order to get end-user network > |IPv6 adoption going at all, the RIRs caved in to end-user > |requirements and therefore abandoned the purity of the official IPv6 > |doctrine, by offering PI prefixes for end-user networks. I > |understand that in doing this, they knew that if and when IPv6 is > |widely adopted this would replicate the routing swamp of IPv4. So I > |guess the RIRs are relying on the IETF -> IRTF -> RRG to come up > |with an architectural fix in time to prevent this getting too bad. > > Correct, they caved and they knew it. You can't use this to claim that they > felt it was the right solution. If there was a solution that meant that end > users didn't have to renumber and yet they weren't given portable addresses, > this would not have been necessary. As I wrote, I figure they knew this would brew trouble - and that they are surely relying on the IETF to find a solution. > |> |NAT-PT doesn't seem to be a viable transition mechanism by which > |> |IPv6-only hosts can retain connectivity to the IPv4 Internet, as I > |> |wrote here: > |> | > |> | http://psg.com/lists/rrg/2008/msg01467.html > |> > |> Which basically seems to claim that NAT can't work. I > |believe that we've > |> shown the converse. > | > |NAT-PT was buried last year: > | > | http://tools.ietf.org/html/rfc4966 > > As an act of defiance by the NAT-haters. That doesn't mean that it's > actually dead. The IETF assigned it to Historic status. > Like Mary Queen of Scots, it will probably live again. The > market wants it. The question is who will build it. Do you need NAT-PT or something similar to ease transition to a new GSE-IPv6? Do you think the world will adopt it without a seamless transition mechanism? > |I understand that the fear was that these kludges are unacceptable - > |especially since they would tend to become part of the network and > |so become barriers to the ideal of unencumbered IPv6 end-to-end > |connectivity. > > Yet, if they become a valuable transition tool, they will necessarily > happen. Anyone remember PIX? Not me. > |So is the RRG going to say to today's Internet users something like > |this?: > | > | Don't worry about the IPv4 routing scaling problem. It will get > | worse, but before it gets too bad we will have IPv6 all sorted > | out, with a transition mechanism which most of you will all be > | happy with, and with a much better solution to the routing > | scaling problem than we feel like suggesting for IPv4. > | > |Yet 10 or so years of effort at a transition arrangement for IPv6 > |was junked last year and it is early days for the new plans. A > |quick read of the requirements document made me think the task is > |not going to be easy - and can probably be achieved only in ways > |which support a subset of the applications and protocols in wide use > |today. > > Hopefully, the RRG will have something cleaner to say. In any case, I don't > think that the RRG need address the users of the Internet. Most of them > won't even care. As long as the bits flow, it won't matter to them. But the bits won't flow the way end-users expect them except on the unadulterated IPv4 Internet. Most of them will not pay for a service which offers less, so there will be a massive financial pressure on ISPs to get as much IPv4 space as they can and to use it very efficiently. I reckon there is a lot of scope to do that in the next 10 to 20 years, for better or for worse. > In actuality, the only folks we have to convince are ourselves. > After that, it steamrolls. I disagree. If we want most of the world to use a system with scalable routing, we need to present it in a way they feel immediate and lasting benefits from, since we can't foist them into a new system and we can't rely on the growing pain of the IPv4 routing scaling problem causing enough of them to jump ship into a separate, incompatible and poorly backwards compatible IPv6 Internet. - Robin From tvest at pch.net Wed Jun 11 04:53:17 2008 From: tvest at pch.net (Tom Vest) Date: Wed, 11 Jun 2008 04:53:17 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <484F78BB.3050303@psg.com> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <20080608143121.GA1890@vacation.karoshi.com.><57E0EC0682885176731FABBA@Visible-Trout.local><484BF1C3.20007@psg.com><16EB6880180498D368047414@hindolveston.reid.org> <7663C7E01D8E094989CA62F0B0D21CD9011DC936@SUEXCL-02.ad.syr.edu> <7534030E5DA1B54ADFC531E8@hindolveston.reid.org> <484F353D.6070501@psg.com> <484F469D.9010303@chl.com> <484F78BB.3050303@psg.com> Message-ID: <8A02BF21-4D5E-415D-B684-FE3660E4512F@pch.net> On Jun 11, 2008, at 3:03 AM, Randy Bush wrote: >> Not sure I understood you correctly. Did you mean that incumbents >> perform routing table aggregation to create an entry barrier for >> small >> sized prefixes or did you mean that incumbents have created a PI >> entry >> barrier in response to routing table de-aggregation (or both)? > > incumbents have created a barrier to entry in the belief in a > demonstrated fantasy that we can reduce routing table size. > > randy Randy since the RIRs were established, tens of thousands of new operationally independent ISPS have been established. Granted, lots have since been acquired and merged into yet larger ISPs -- some of which were/are pre-Internet incumbents, some of which are incumbents of our very own -- but that's not something that's affected by address policy one way or another (except maybe to delay what would have happened anyway as a result of market power, increasing returns to scale, etc.). So, if you believe that address policy itself has been a barrier to entry, how many address resource recipients *should* there be? How many are missing? How much *more* decentralized should our industry be today relative to all of the others? The level of address resource concentration across players in our particular industry is pretty substantial, until you start to compare it to other large industries (auto manufacturing, banking, etc.), relative to which we are fabulously decentralized. Again, granted, concentration levels are rising somewhat today, but unless you want address policy to become an explicit benchmark and powerful tool of (otherwise generally toothless) national antitrust policies, it's not clear what more any address policy body could do to offset this trend. Finally, if "incumbents" are the guilty party in your interpretation of recent history, how is privatizing address resources and giving incumbents the power to directly/unilaterally set (minimum/ unavoidable) prices for future operator entry and growth going to make matters better? They are also going to be the same institutions whose commercial strategies will determine when (if ever) v6-to-v4 gateway services will no longer be mandatory, so simply pointing to IPv6 as an alternative does not answer the question. If we really are missing lots of lots of independent operators that would otherwise be in (independent) operation today purely because of address policy "capture" by incumbents, and we're facing an indefinite future of 6/4 translation -- and routing table size is really immune to address allocation policies as you seem to suggest (or perhaps recommend) -- then maybe all of the remaining /32s should be distributed to individuals, like driver's licenses -- or rather like the privatization vouchers that were the basis for redistribution of common pool assets on Poland, Russia, etc...? Doesn't seem like that always leads to radical, enduring decentralization either :-\ TV From bmanning at vacation.karoshi.com Wed Jun 11 08:46:58 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 11 Jun 2008 12:46:58 +0000 Subject: [arin-ppml] simple question about money In-Reply-To: <8A02BF21-4D5E-415D-B684-FE3660E4512F@pch.net> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <7663C7E01D8E094989CA62F0B0D21CD9011DC936@SUEXCL-02.ad.syr.edu> <7534030E5DA1B54ADFC531E8@hindolveston.reid.org> <484F353D.6070501@psg.com> <484F469D.9010303@chl.com> <484F78BB.3050303@psg.com> <8A02BF21-4D5E-415D-B684-FE3660E4512F@pch.net> Message-ID: <20080611124658.GA14177@vacation.karoshi.com.> > Randy since the RIRs were established, tens of thousands of new > operationally independent ISPS have been established. > Granted, lots have since been acquired and merged into yet larger ISPs > -- some of which were/are pre-Internet incumbents, some of which are > incumbents of our very own -- but that's not something that's affected > by address policy one way or another (except maybe to delay what would > have happened anyway as a result of market power, increasing returns > to scale, etc.). > > So, if you believe that address policy itself has been a barrier to > entry, how many address resource recipients *should* there be? How > many are missing? How much *more* decentralized should our industry be > today relative to all of the others? Tom, put on your academic hat and play the decentralization game... go grab the skitter graph:: http://www.caida.org/research/topology/as_core_network/2007/ and -remove- paths through the top 5 ASNs. Will your Internet experience be affected? If so, how and why? Can you replicate the mesh w/ massive peering on a local scale? One thing that I beleive you (and others) are conflating is access to address space and entries in some mythical "global routing table". Just because some small player in Los Angeles gets a /28 for their needs (and have agreements w/ their peers to carry routes for that /28), is no reason Telia to be forced to carry that discreate /28. Your use of IP space does -NOT- automatically equate to a slot in my routing table, either as a discreate entry or an aggregate. > TV --bill From tvest at pch.net Wed Jun 11 09:10:46 2008 From: tvest at pch.net (Tom Vest) Date: Wed, 11 Jun 2008 09:10:46 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <20080611124658.GA14177@vacation.karoshi.com.> References: <546210EA466CA8FBDBD412AC@Visible-Trout.local> <7663C7E01D8E094989CA62F0B0D21CD9011DC936@SUEXCL-02.ad.syr.edu> <7534030E5DA1B54ADFC531E8@hindolveston.reid.org> <484F353D.6070501@psg.com> <484F469D.9010303@chl.com> <484F78BB.3050303@psg.com> <8A02BF21-4D5E-415D-B684-FE3660E4512F@pch.net> <20080611124658.GA14177@vacation.karoshi.com.> Message-ID: On Jun 11, 2008, at 8:46 AM, bmanning at vacation.karoshi.com wrote: >> Randy since the RIRs were established, tens of thousands of new >> operationally independent ISPS have been established. >> Granted, lots have since been acquired and merged into yet larger >> ISPs >> -- some of which were/are pre-Internet incumbents, some of which >> are >> incumbents of our very own -- but that's not something that's >> affected >> by address policy one way or another (except maybe to delay what >> would >> have happened anyway as a result of market power, increasing returns >> to scale, etc.). >> >> So, if you believe that address policy itself has been a barrier to >> entry, how many address resource recipients *should* there be? How >> many are missing? How much *more* decentralized should our industry >> be >> today relative to all of the others? > > Tom, > > put on your academic hat and play the decentralization game... > go grab the skitter graph:: > http://www.caida.org/research/topology/as_core_network/2007/ > and -remove- paths through the top 5 ASNs. > Will your Internet experience be affected? If so, how and why? > Can you replicate the mesh w/ massive peering on a local scale? > > One thing that I beleive you (and others) are conflating is > access to address space and entries in some mythical "global > routing table". Just because some small player in Los Angeles > gets a /28 for their needs (and have agreements w/ their peers > to carry routes for that /28), is no reason Telia to be forced > to carry that discreate /28. > > Your use of IP space does -NOT- automatically equate to a > slot in my routing table, either as a discreate entry or an > aggregate. > >> TV > > --bill Hi Bill, You're point is well taken, esp. since it's roughly the same point I was trying to make about allocation policies being able to do *nothing more* than establish a norm of open access -- or open access to a critical resource which is necessary but not by itself sufficient to engage in independent Internet production. To repeat for the sake of clarity: "Necessary, but not sufficient" -- but "necessary" is still in there. I don't know anyone who's making the mistake you're describing. TV From mueller at syr.edu Wed Jun 11 10:03:32 2008 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 11 Jun 2008 10:03:32 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <7B15F7BAFC92EDD4A023F19A@hindolveston.reid.org> References: <369EB04A0951824ABE7D8BAC67AF9BB40A2DD020@CL-S-EX-1.stanleyassociates.com> <7B15F7BAFC92EDD4A023F19A@hindolveston.reid.org> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901BB78D3@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Brian Reid > > fees are generally not considered to be > > policy. > > Curious, because as far as I am concerned, fees are the policy that > matters the most. OK, so the policies are used to *set* the fees, rather > than *be* the fees. It would seem to me that policies leading to the > setting of fees are about as central to the charter of a public policy > forum as can be. > Yes, any attempt to separate "resource policy" and "pricing policy" just can't work. This is like saying that the price of oil is unrelated to energy resources policy. I am sure we are all familiar with basic laws of supply and demand. How things are priced affects how much is consumed, incentives to conserve, what are viable substitutes, etc. There are many pricing structures that would cover the costs of the registry. But how those costs are distributed across different classes of address users can vary greatly, and each pricing structure would create different kinds of incentives with respect to address consumption, different kinds of barriers to entry, etc. It seems to me that the two biggest policy issues facing RIRs today are address transfers (in effect, the creation of a much-needed private secondary market to move scarce v4 addresses from underutilized allocations/assignments to those who need them more) and the costs or fees associated with granting assignments or allocations. From paul at vix.com Wed Jun 11 10:23:28 2008 From: paul at vix.com (Paul Vixie) Date: Wed, 11 Jun 2008 14:23:28 +0000 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: Your message of "Wed, 11 Jun 2008 16:05:20 +1000." <484F6B20.7020903@firstpr.com.au> References: <484F3A4E.5010802@firstpr.com.au> <484F6B20.7020903@firstpr.com.au> Message-ID: <52077.1213194208@sa.vix.com> robin, thanks for this and for yesterday's message on this thread (Message-ID: <484F3A4E.5010802 at firstpr.com.au>). your explainations of the outstanding issues are clear and concise and i hope you will blog them somewhere so that this mailing list won't be the only permanent record of what you said. most important thing i've learned is that RRG hasn't got consensus on whether or not to try to save IPv4. you wrote: If the RRG decides that it doesn't need to solve the IPv4 routing scaling problem, then there is plenty of time to come up with an IPv6 solution with a wider variety of potential techniques and fewer backward compatibility reasons than would be the case for an IPv4 solution. while i am not a member of RRG, if the question is drawn as clearly as that, my position would be, forget about IPv4. the internet will have many more than 2^32 devices connected to it simultaneously within our lifetimes, and i think we should preserve the option of not using NAT in future generations. therefore IPv4's growth has a glass ceiling formed by its address size, and any effort that's put into growing its routing table has a fixed return. paul From Lee.Howard at stanleyassociates.com Wed Jun 11 10:26:26 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 11 Jun 2008 10:26:26 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <484F353D.6070501@psg.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40A33A43D@CL-S-EX-1.stanleyassociates.com> Randy said: > when ipv6 becomes needed for real business, folk from the > business side of the company will come walking over and > telling us that customers are complaining that they can not > get their mtv from those /48s. Fortunately, it's the same business folk who decide whether to spend money on bigger routers with CPUs that can handle the churn. If such devices (will) exist. > and, in the meantime, we the incumbents use routing table > aggregation as a excuse for creating a barrier to entry. I still don't see PA space as a barrier to "entry." It can be construed as a barrier to "exit" maybe, but only for the very smallest providers. Current PI policy (4.2.2) says /20 for a single-homed or /22 for a multihomed ISP in IPv4, which is not very many customers. In IPv6, it's "a plan for making 200 end-site assignments...within 5 years." There may be a few ISPs without enough customers to justify a PI assignment, and who also have an engineer capable of speaking BGP on staff, but I don't think the incumbents care to prevent them from entering the market. Lee From Lee.Howard at stanleyassociates.com Wed Jun 11 11:17:48 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 11 Jun 2008 11:17:48 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40A33A43D@CL-S-EX-1.stanleyassociates.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40A33A51B@CL-S-EX-1.stanleyassociates.com> I said, in response to Randy: > > and, in the meantime, we the incumbents use routing table > aggregation > > as a excuse for creating a barrier to entry. > > I still don't see PA space as a barrier to "entry." It can > be construed as a barrier to "exit" maybe, but only for the > very smallest providers. Current PI policy (4.2.2) says /20 > for a single-homed or /22 for a multihomed ISP in IPv4, which > is not very many customers. In IPv6, it's "a plan for making > 200 end-site assignments...within 5 years." Owen suggested I should also point out that in IPv6, you could also "be an existing, known ISP in the ARIN region" which plans to assign some IPv6 address space, even if less than 200. The barrier is low. I find it interesting that there are two arguments currently under the subject line "simple question about money": * fees are too high and prevent end users from getting space * fees are too low and do not encourage conservation These two arguments should find each other. I look forward to consensus. Lee From tedm at ipinc.net Wed Jun 11 16:00:54 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 11 Jun 2008 13:00:54 -0700 Subject: [arin-ppml] simple question about money In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40A33A51B@CL-S-EX-1.stanleyassociates.com> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Howard, W. Lee > Sent: Wednesday, June 11, 2008 8:18 AM > To: Howard, W. Lee; Randy Bush > Cc: PPML > Subject: Re: [arin-ppml] simple question about money > > > > I said, in response to Randy: > > > and, in the meantime, we the incumbents use routing table > > aggregation > > > as a excuse for creating a barrier to entry. > > > > I still don't see PA space as a barrier to "entry." It can > > be construed as a barrier to "exit" maybe, but only for the > > very smallest providers. Current PI policy (4.2.2) says /20 > > for a single-homed or /22 for a multihomed ISP in IPv4, which > > is not very many customers. In IPv6, it's "a plan for making > > 200 end-site assignments...within 5 years." > > Owen suggested I should also point out that in IPv6, you could > also "be an existing, known ISP in the ARIN region" which plans > to assign some IPv6 address space, even if less than 200. > > The barrier is low. > > I find it interesting that there are two arguments currently > under the subject line "simple question about money": > * fees are too high and prevent end users from getting space > * fees are too low and do not encourage conservation > These two arguments should find each other. I look forward > to consensus. > You won't have it. The same thing is happening to the ISP market that has happened to a great many markets. I'll point to the beer market for example. When you go to buy beer what do you find on the shelf? You find some cheap pee-water from the great, gigantic breweries that are part of multinational food conglomerates. And you find drinkable-but-expensive "real" beer from the small fry regional craft brewers. What you DON'T find is drinkable real beer that is cheap. Why? Because that would only come from a mid-sized beer company that was a standalone business that just made beer, made a lot of it, distributed it over the country, yet was still small enough that they actually gave a shit about product quality. If your a small fry craft brewer your going to think the cost of getting all the government health certifications to sell your product is too high and is a barrier to market. If you're a large conglomerate, these costs are peanuts, and naturally your main concern is seeing that these fees stay fairly high for the small fry, so that they cannot compete head-to-head with you on price. (and thus, their growth is forever limited) This is why in the ISP market you don't find mid-sized ISP's who are cheap yet still care. You find small ISPs that care, and you find large ISP's that are more interested in selling television and advertising and a whole host of other crap besides Internet connectivity. The ironic thing is that while the small ISP's bitch about the costs to entry, what most of them don't realize is that those high costs of entry help them just as much as they help the large conglomerate ISPs. I work for a small ISP. We can compete on the basis of product quality and support with the large, elephant AOL's and Comcasts of the world. We can also compete with all the other small fry ISPs like us out there. What we -can't- compete with are the mid-sized ISPs who because of their larger size than us can cut deals and buy bandwidth a hell of a lot cheaper than we do so they can sell connectivity at the same cost as the elephants can, yet because they are not large enough to be distracted from their core product, can still offer the same quality and technical support that we do. Fortunately, the elephant ISPs of the world cannot compete with those midsized ISP's either. So, whenever one of those midsized ISPs appears in the market, one of the elephant sized ISP's buys them out, and runs them into the ground until their service is just as horrible as the elephant sized ISPs. Ted From tedm at ipinc.net Wed Jun 11 19:03:26 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 11 Jun 2008 16:03:26 -0700 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: <52077.1213194208@sa.vix.com> Message-ID: <71B6AA7F8A46468FA74B0832E46CD863@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Paul Vixie > Sent: Wednesday, June 11, 2008 7:23 AM > To: Robin Whittle > Cc: 'PPML' > Subject: Re: [arin-ppml] Portable address space vs. IPv6 > auto-numbering > > > while i am not a member of RRG, if the question is drawn as > clearly as that, my position would be, forget about IPv4. > the internet will have many more than 2^32 devices connected > to it simultaneously within our lifetimes, and i think we > should preserve the option of not using NAT in future > generations. therefore IPv4's growth has a glass ceiling > formed by its address size, and any effort that's put into > growing its routing table has a fixed return. Standard road lane width on a modern US highway is determined by the width of the butts of 2 horses. This dates back oh, a couple thousand years. Is standard auto and road width optimal? I don't know. I do know, though, that a hell of a lot of people have died in SUV rollover crashes that would have not happened if the width of their vehicle was, say, the width of 3 butts of horses. Backwards compatability is not always smart, and can even kill people. Think unintended consequences. Ted From Lee.Howard at stanleyassociates.com Wed Jun 11 19:33:21 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 11 Jun 2008 19:33:21 -0400 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: <71B6AA7F8A46468FA74B0832E46CD863@tedsdesk> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40A33ABE4@CL-S-EX-1.stanleyassociates.com> I usually let these irrelevant analogies go by, but this one's too much. > > > > while i am not a member of RRG, if the question is drawn as > > clearly as that, my position would be, forget about IPv4. > > the internet will have many more than 2^32 devices connected > > to it simultaneously within our lifetimes, and i think we > > should preserve the option of not using NAT in future > > generations. therefore IPv4's growth has a glass ceiling > > formed by its address size, and any effort that's put into > > growing its routing table has a fixed return. > > Standard road lane width on a modern US highway is determined > by the width of the butts of 2 horses. This dates back oh, > a couple thousand years. Roman roads were narrower (8') than modern highway lanes (12'). http://en.wikipedia.org/wiki/Roman_road http://en.wikipedia.org/wiki/Interstate_Highway_standards Even if they were essentially the same, the width was set to meet the requirement to allow passage of a vehicle that allows two passengers to sit side by side. > Is standard auto and road width optimal? I don't know. I do > know, though, that a hell of a lot of people have died in > SUV rollover crashes that would have not happened if the width > of their vehicle was, say, the width of 3 butts of horses. Only if they were not proportionately higher. > Backwards compatability is not always smart, and can even > kill people. Think unintended consequences. If Tony and Robin are taking a poll on the best way to make routing scale, I'll agree with Paul that I don't think IPv4 can be made to scale, and so we shouldn't waste time trying. I can't argue on which of various solutions might work for IPv6; it's not part of my day job or volunteer work. Lee > > 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 the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From Lee.Howard at stanleyassociates.com Wed Jun 11 19:59:12 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 11 Jun 2008 19:59:12 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901BB78D3@SUEXCL-02.ad.syr.edu> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40A33ABFA@CL-S-EX-1.stanleyassociates.com> > Yes, any attempt to separate "resource policy" and "pricing > policy" just can't work. This is like saying that the price > of oil is unrelated to energy resources policy. Integers aren't oil. Even if they were analogous, I'm not convinced energy policy is related to the price of oil, or that it should be in any significant way. > I am sure we > are all familiar with basic laws of supply and demand. How > things are priced affects how much is consumed, incentives to > conserve, what are viable substitutes, etc. We do not have a market. ARIN is a not-for-profit trying to recover its costs. We can change that, but it requires the membership to tell us they want a different system, which is why that discussion should happen on arin-discuss. Lest you feel disenfranchised, you may become an ARIN member without having to justify an address allocation: http://www.arin.net/membership/index.html Also, there is a policy proposal under discussion that may be relevant: http://www.arin.net/policy/proposals/2008_2.html > There are many pricing structures that would cover the costs > of the registry. But how those costs are distributed across > different classes of address users can vary greatly, and each Yes, it's an imperfect model. If we want to assess our fixed costs and our transaction costs, we could spend a few hundred thousand dollars in consulting and develop a more finely-tuned system. > It seems to me that the two biggest policy issues facing RIRs > today are address transfers (in effect, the creation of a > much-needed private secondary market to move scarce v4 > addresses from underutilized allocations/assignments to those > who need them more) and the costs or fees associated with > granting assignments or allocations. I encourage you to get more involved! You can voice support for or opposition to a current proposal, on this very list (PPML at arin.net). For instance: http://www.arin.net/policy/proposals/2008_2.html You can propose something else: + Send email to PPML at arin.net with your idea to get informal feedback. + Send email to one of the Advisory Council members to get assistance submitting a formal proposal. http://www.arin.net/about_us/ac.html + Formally propose an alternative, by sending a completed Policy Proposal Template (http://www.arin.net/policy/irpep_template.html) to policy at arin.net, as described in the Internet Resource Policy Evaluation Process (http://www.arin.net/policy/irpep.html) You can attend a free public policy meeting and voice your support for or opposition to a proposal: http://www.arin.net/meetings/index.html You can attend the Open Policy Hour just before a policy meeting and get informal feedback on your idea (watch for announcements as we approach the next meeting). Of course, all of these options are open to everyone. It's a very open policy process. Lee From tedm at ipinc.net Wed Jun 11 20:39:18 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 11 Jun 2008 17:39:18 -0700 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40A33ABE4@CL-S-EX-1.stanleyassociates.com> Message-ID: <09F559B28D234E6591B2F7B238AA7FC8@tedsdesk> > -----Original Message----- > From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] > Sent: Wednesday, June 11, 2008 4:33 PM > To: Ted Mittelstaedt > Cc: PPML > Subject: RE: [arin-ppml] Portable address space vs. IPv6 > auto-numbering > > > I usually let these irrelevant analogies go by, but this > one's too much. > Hey if you can't have any fun at all what's the point of posting? > > > > > > while i am not a member of RRG, if the question is drawn as > > > clearly as that, my position would be, forget about IPv4. > > > the internet will have many more than 2^32 devices connected > > > to it simultaneously within our lifetimes, and i think we > > > should preserve the option of not using NAT in future > > > generations. therefore IPv4's growth has a glass ceiling > > > formed by its address size, and any effort that's put into > > > growing its routing table has a fixed return. > > > > Standard road lane width on a modern US highway is > determined by the > > width of the butts of 2 horses. This dates back oh, a > couple thousand > > years. > > Roman roads were narrower (8') than modern highway lanes > (12'). http://en.wikipedia.org/wiki/Roman_road > http://en.wikipedia.org/wiki/Interstate_Highway_standards > > Even if they were essentially the same, the width was set to > meet the requirement to allow passage of a vehicle that allows > two passengers to sit side by side. > Jokes about airplane manufacturers, the comparative width of horse and people butts, and increase in obesity in the US are very hard to let pass by, here, Lee.... > > Is standard auto and road width optimal? I don't know. I do know, > > though, that a hell of a lot of people have died in SUV rollover > > crashes that would have not happened if the width of their vehicle > > was, say, the width of 3 butts of horses. > > Only if they were not proportionately higher. > Height is determined largely by the hight of a person from midsection to head, there's no reason to believe that your average SUV would be any higher if the road width was made wider. The military dictated a wider width for the HumVee when it comissioned them because even the bull-necks in the military can see that blindly following a standard set by measuring people's or horse's asses was not an optimal standard. IPv4 is the Internet's horse's ass standard, here... Ted From rw at firstpr.com.au Wed Jun 11 21:37:33 2008 From: rw at firstpr.com.au (Robin Whittle) Date: Thu, 12 Jun 2008 11:37:33 +1000 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: <71B6AA7F8A46468FA74B0832E46CD863@tedsdesk> References: <71B6AA7F8A46468FA74B0832E46CD863@tedsdesk> Message-ID: <48507DDD.30402@firstpr.com.au> I am replying to Paul Vixie and Ted Mittelstaedt. Paul Vixie wrote: > robin, thanks for this and for yesterday's message on this thread http://lists.arin.net/pipermail/arin-ppml/2008-June/010984.html > your explainations of the outstanding issues are clear and concise > and i hope you will blog them somewhere so that this mailing list > won't be the only permanent record of what you said. Thanks very much! Nonetheless we disagree about whether to fix the IPv4 routing scaling problem. I linked to this thread from the "Recent Developments" section of the homepage for my Ivip (Internet Vastly Improved Plumbing) map-encap proposal: http://www.firstpr.com.au/ip/ivip/ > most important thing i've learned is that RRG hasn't got consensus > on whether or not to try to save IPv4. you wrote: > >> If the RRG decides that it doesn't need to solve the IPv4 routing >> scaling problem, then there is plenty of time to come up with an >> IPv6 solution with a wider variety of potential techniques and >> fewer backward compatibility reasons than would be the case for >> an IPv4 solution. > > while i am not a member of RRG, if the question is drawn as > clearly as that, my position would be, forget about IPv4. the > internet will have many more than 2^32 devices connected to it > simultaneously within our lifetimes, and i think we should > preserve the option of not using NAT in future generations. > > therefore IPv4's growth has a glass ceiling formed by its address > size, and any effort that's put into growing its routing table has > a fixed return. OK - quite a few people on the RRG agree with you on this. Here is a more nuanced version: If the RRG decides it doesn't need to fix the IPv4 routing scaling problem, then it can concentrate its energies - and the IETF's, if the IETF accepts the RRG's recommendation - on the much less urgent IPv6 scaling problem. IPv6 has many more technical possibilities for solving the problem, primarily due to its longer address length and much lower installed base. If the RRG/IETF doesn't care about the IPv4 routing scaling problem, then it probably has many years to solve the IPv6 problem, because I can't see how mass migration to IPv6 is going to happen in the next decade. However, this seems like a high-pressure, high-risk venture. While one planet burns, the expeditionary force is supposed to be preparing another, significantly incompatible, but ultimately better planet. I would rather a more relaxed mission timetable: I would rather fix the IPv4 problem ASAP and have more time to prepare a lasting alternative, especially something with greater ease of migration from IPv4, which means a much better means of communicating with the IPv4 Internet than is currently possible with IPv6. NAT-PT has been buried and the replacements - NAT64 and DNS64 - are at a very early stage of development: http://tools.ietf.org/html/draft-ietf-v6ops-nat64-pb-statement-req-00 http://tools.ietf.org/html/draft-bagnulo-behave-nat64-00 Many IETF folks have had unrealistic optimism about end-users wanting or needing IPv6 for over a decade. While I know that IPv4 with NAT etc. falls a long way short of the ideal, I still think many IETF folks are unrealistically optimistic about IPv6 adoption in the next 10 years. I think there are plenty of coping mechanisms for keeping IPv4 tolerable for most users in that time frame and probably beyond - and these will be cheaper and better for ISPs than trying to sell an IPv6-only service. The transition mechanisms are not there. The IPv6 Internet doesn't connect properly to the IPv4 Internet. People like the IPv4 Internet because everyone is reachable via it. I think a scalable IPv6 could be prepared, which sounds like heaven to many IETF people (though I still think 128 bits is 64 too long) - but the main population of end-users wouldn't care, since it is a different planet with almost none of their friends on it yet. Ted Mittelstaedt wrote: >> while i am not a member of RRG, if the question is drawn as >> clearly as that, my position would be, forget about IPv4. >> the internet will have many more than 2^32 devices connected >> to it simultaneously within our lifetimes, and i think we >> should preserve the option of not using NAT in future >> generations. therefore IPv4's growth has a glass ceiling >> formed by its address size, and any effort that's put into >> growing its routing table has a fixed return. > > Standard road lane width on a modern US highway is determined > by the width of the butts of 2 horses. This dates back oh, > a couple thousand years. For the sake of the argument, I won't dispute this. > Is standard auto and road width optimal? I don't know. I do > know, though, that a hell of a lot of people have died in > SUV rollover crashes that would have not happened if the width > of their vehicle was, say, the width of 3 butts of horses. Time to re-introduce the 1959 Chevrolet. Nice and low and with narrow window-door "A pillars" so there is no obstruction of vision. > Backwards compatability is not always smart, and can even > kill people. Think unintended consequences. Yes. Folks in the USA drive on the wrong side of the road - in part, after copying the French practice of driving on the right to be like the proletariat who swapped from walking on the left to walking on the right to be safe from the landed gentry who were driving their carriages on the left. Walking on the left is the natural approach - most right-handed people can have their dagger hand ready to tackle an oncoming attacker: http://users.pandora.be/worldstandards/driving%20on%20the%20left.htm This causes crashes when North Americans make understandable mistakes driving in countries where we still drive on the correct side. Sure, but IPv6 has not been needed or wanted by the vast majority of ISPs and end-users in the 12 or so years since its inception. Do you think it would be best to soup it up for scalable routing while IPv4 festers, or to fix IPv4 and take a longer, more relaxed, time to do a better job of improving IPv6 and making mass migration more practical? You might be interested in the possibility of applying GSE: http://tools.ietf.org/html/draft-ietf-ipngwg-gseaddr-00 to IPv6 (while not fixing IPv4), as is being discussed on the RRG: http://psg.com/lists/rrg/2008/maillist.html http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup - Robin From heldal at eml.cc Thu Jun 12 04:53:25 2008 From: heldal at eml.cc (Per Heldal) Date: Thu, 12 Jun 2008 10:53:25 +0200 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: <48507DDD.30402@firstpr.com.au> References: <71B6AA7F8A46468FA74B0832E46CD863@tedsdesk> <48507DDD.30402@firstpr.com.au> Message-ID: <1213260805.28021.36.camel@obelix.sandbu> On Thu, 2008-06-12 at 11:37 +1000, Robin Whittle wrote: > I would rather fix the IPv4 problem ASAP and have more time > to prepare a lasting alternative, especially something with > greater ease of migration from IPv4, which means a much better > means of communicating with the IPv4 Internet than is currently > possible with IPv6. > > NAT-PT has been buried and the replacements - NAT64 and DNS64 - > are at a very early stage of development: > > http://tools.ietf.org/html/draft-ietf-v6ops-nat64-pb-statement-req-00 > http://tools.ietf.org/html/draft-bagnulo-behave-nat64-00 > > Many IETF folks have had unrealistic optimism about end-users > wanting or needing IPv6 for over a decade. Most of that unrealistic optimism originate from the same crowd that built the OSI-bubble (GOSIP&friends) in the 80s and 90s. I.e. mostly staff within the public-sector and the closely related consultant industry. Although they're vocal and often linked to standardisation efforts, few have actually been active in the IETF. While NAT-PT has been rejected by purists opposing NAT in general, there is no universal agreement against this approach as a transitional tool, as described by the ongoing initiatives you link to as well as ongoing efforts to implement such solutions. Further technical discussions in this thread belong on the RRG-list, but there's one thing relevant to RIR policy that I find a bit odd. If continued growth of the net through re-allocation of unused resources is the no-brainer you claim it is, why haven't the RIR yet performed and published results from surveys to document it? How much of the previously allocated space can be expected to be available for re-use given various conditions (prices and/or political pressure), from either registered LIRs or legacy-holders. Is it possible to meet the market's demand for sustained growth for any significant time past depletion of the free pool? //per From rw at firstpr.com.au Thu Jun 12 05:24:30 2008 From: rw at firstpr.com.au (Robin Whittle) Date: Thu, 12 Jun 2008 19:24:30 +1000 Subject: [arin-ppml] Map-encap for better utilization of IPv4 space? Message-ID: <4850EB4E.80905@firstpr.com.au> Hi Per, In "Re: [arin-ppml] Portable address space vs. IPv6 auto-numbering", you wrote, in part: > If continued growth of the net through re-allocation of unused > resources is the no-brainer you claim it is, why haven't the RIR > yet performed and published results from surveys to document it? I know very little about RIRs and address allocation policy - and I never wrote it was easy. It is difficult to do now, without generating far more BGP advertised prefixes, generally longer prefixes, as space is divided more carefully in smaller chunks. That drives the routing scaling problem, so it is strongly resisted. The pressure to use IPv4 space more efficiently will grow and grow, since I can't see how IPv6-only services could suit most end-users. > How much of the previously allocated space can be expected to be > available for re-use given various conditions (prices and/or > political pressure), from either registered LIRs or > legacy-holders. Is it possible to meet the market's demand for > sustained growth for any significant time past depletion of the > free pool? My understanding is that only a relatively small fraction of the IP addresses currently advertised are actually in use: http://www.isi.edu/~johnh/PAPERS/Heidemann08a.pdf http://www.firstpr.com.au/ip/host-density-per-prefix/ perhaps 200 to 300 million. I know ping surveys have their problems, but the figure I and the USC/ISI team got was around 110 million. A map-encap system - LISP, APT, Ivip or TRRP: http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup would enable a lot of the space to be finely and arbitrarily divided amongst end-users without adding to the routing scaling problem. I figure this could make much better use of IPv4 space in general. Each such end-user network could get portable, multihomable space without the costs of current PI space, and without having to grab more than they need, since the map-encap systems can easily slice to 1, 2, 4 etc. IP address prefixes. It is a big question which I can't answer in detail, but if the world is getting by now with a few hundred million IPv4 addresses in use, out of 1.7B advertised, and there are 3.7B which could be advertised, then I reckon that a map-encap system gives a great deal of scope for much higher rates of utilisation and therefore many more years of life for IPv4 without any end-user networks really being unable to obtain IPv4 space (perhaps in smaller than ideal chunks) for a reasonable price. I am not sure this directly helps ISPs who don't want map-encap space, but want swaths of space to connect DSL customers, each with an IPv4 address. It is more that the map-encap scheme and the pressures on end-user networks to get their own, multihomable, public, portable PI space will drive the use of map-encap and so fit far more end-user networks into a given amount of space than is possible now. - Robin http://www.firstpr.com.au/ip/ivip/ From mueller at syr.edu Thu Jun 12 09:31:41 2008 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 12 Jun 2008 09:31:41 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40A33ABFA@CL-S-EX-1.stanleyassociates.com> References: <7663C7E01D8E094989CA62F0B0D21CD901BB78D3@SUEXCL-02.ad.syr.edu> <369EB04A0951824ABE7D8BAC67AF9BB40A33ABFA@CL-S-EX-1.stanleyassociates.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9011DC94D@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] > Integers aren't oil. Even if they were analogous, I'm not > convinced energy policy is related to the price of oil, or > that it should be in any significant way. Astonishing. I'm just going to assume that you didn't really mean that last assertion, because it is indefensible and I don't see any point in pursing it. IP addresses are more than "integers." They are unique and exclusive assignments of "integers" which perform a function in a data network. In the context of a market for Internet connectivity, they have economic value. The laws of supply and demand apply here, as they do to all human products. We don't need to get into a debate about that, any more than we do about whether the earth is flat or gravity exists. There are many possible ways to manages a resource, and ARIN's existing fee structures and policies may be good, bad or somewhere in between -- but let's not frame a discussion of them by jumping off a social science cliff and denying that everything we know about the relationship between prices and resources doesn't apply. > Also, there is a policy proposal under discussion that may > be relevant: http://www.arin.net/policy/proposals/2008_2.html Yes. I have already mentioned that proposal in connection with this thread. I think authorizing address transfers is an essential move to make now, but we do need to understand its implications and how to do it properly. > If we want to assess our fixed costs and our transaction costs, > we could spend a few hundred thousand dollars in consulting and > develop a more finely-tuned system. Or, you could listen to people in the policy and economics community who are working on the problem who charge you nothing. Some of our ideas may be wrong, some may be helpful, > > It seems to me that the two biggest policy issues facing RIRs > > today are address transfers (in effect, the creation of a > > much-needed private secondary market to move scarce v4 > > addresses from underutilized allocations/assignments to those > > who need them more) and the costs or fees associated with > > granting assignments or allocations. > > I encourage you to get more involved! Thanks! that's what I'm doing. From Lee.Howard at stanleyassociates.com Thu Jun 12 09:58:49 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 12 Jun 2008 09:58:49 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DC94D@SUEXCL-02.ad.syr.edu> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40A33AE50@CL-S-EX-1.stanleyassociates.com> > > If we want to assess our fixed costs and our transaction costs, we > > could spend a few hundred thousand dollars in consulting > and develop a > > more finely-tuned system. > > Or, you could listen to people in the policy and economics > community who are working on the problem who charge you > nothing. Some of our ideas may be wrong, some may be helpful, I listen very closely to the policy community, which is this list. Who else is "working on the problem," and exactly which problem do you mean in this case (I'm afradi thread-trimming may have lost the context)? Outside resources will not be able to assess our cost-recovery fees, but may have useful things to say about economics. Please send pointers to useful information. Lee From paul at vix.com Thu Jun 12 10:16:50 2008 From: paul at vix.com (Paul Vixie) Date: Thu, 12 Jun 2008 14:16:50 +0000 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: Your message of "Thu, 12 Jun 2008 11:37:33 +1000." <48507DDD.30402@firstpr.com.au> References: <71B6AA7F8A46468FA74B0832E46CD863@tedsdesk> <48507DDD.30402@firstpr.com.au> Message-ID: <98747.1213280210@sa.vix.com> > > while i am not a member of RRG, if the question is drawn as clearly as > > that, my position would be, forget about IPv4. the internet will have > > many more than 2^32 devices connected to it simultaneously within our > > lifetimes, and i think we should preserve the option of not using NAT in > > future generations. > > > > therefore IPv4's growth has a glass ceiling formed by its address size, > > and any effort that's put into growing its routing table has a fixed > > return. > > OK - quite a few people on the RRG agree with you on this. > > Here is a more nuanced version: ... i think that what quite a few people on RRG might be in agreement with is the first qualified statement i made, "...forget about IPv4." however, the qualification is important: "if the question is drawn as clearly as that," which it sounds like it isn't. furthermore, what i mean by "fixed return" is that it's economically damned: the more effort we put into it the more expensive that effort will turn out to have been. i don't know if the RRG folks are looking at this as an economics proposition but if not, there isn't really any necessary relationship between what i said and what they might, under different and/or synthetic circumstances, agree with. i'm not just picking nits -- your "more nuanced version" does not represent my view correctly, it is not a restatement of any position i've had nor of one i can agree to. > ... > Many IETF folks have had unrealistic optimism about end-users wanting or > needing IPv6 for over a decade. While I know that IPv4 with NAT etc. falls > a long way short of the ideal, I still think many IETF folks are > unrealistically optimistic about IPv6 adoption in the next 10 years. I > think there are plenty of coping mechanisms for keeping IPv4 tolerable for > most users in that time frame and probably beyond - and these will be > cheaper and better for ISPs than trying to sell an IPv6-only service. while on the one hand i completely disagree, the bigger issue is, you're just saying what you think, here, whereas in your two previous articles you shared facts. > The transition mechanisms are not there. The IPv6 Internet doesn't connect > properly to the IPv4 Internet. People like the IPv4 Internet because > everyone is reachable via it. these are plain facts and i agree. (i wanted to agree to something here.) as to optimism, jean camp showed some S curves in denver describing adoption of technology, and while a lot of folks didn't understand them, they were well argued and well reasoned, and they give *no* cause for optimism wrt IPv6. so, if provable pessimism about IPv6 were an argument in favour of prolonging the lifetime of IPv4, you'd need look no further than elmore/camp/stephens: http://weis2008.econinfosec.org/papers/Elmore.pdf alain durand's current plan is to native V6 to their customer edge and backbone, and use native V6 to carry NAT'd V4, and thus get provide stack to the comcast customer base. apple and microsoft, as well as every IP-capable device designed or manufactured in japan, as well as most f/l/oss software, will all use native V6 if it's present. there's a very real deployment scenario involving islands of this kind of dual-stack, followed by address space shortages and/or explosive routing table deaggregation, followed by heightened, agitated capital investment in more dual-stack because it's a way to avoid the worst pain of the shortages/explosions. > I think a scalable IPv6 could be prepared, which sounds like heaven to many > IETF people (though I still think 128 bits is 64 too long) - but the main > population of end-users wouldn't care, since it is a different planet with > almost none of their friends on it yet. i think we're going to see IPv6 routing table bloat earlier than RRG's work could possibly complete, and that that's the real race here, and that any time spent prolonging IPv4's doddering old age with double- and triple-NAT is a dangerous distraction. the internet is not just the web, and we can't go on building new kinds of applications if everything has to be some kind of NAT or map-encap or ALG or proxy. IPv4 is headed for end-of-life. let's move on. From info at arin.net Thu Jun 12 12:12:38 2008 From: info at arin.net (Member Services) Date: Thu, 12 Jun 2008 12:12:38 -0400 Subject: [arin-ppml] ARIN Mailing Lists Message-ID: <48514AF6.6080903@arin.net> Mr. Dean Anderson's privilege to post and participate in ARIN's various mail lists has been permanently suspended effective 12 June 2008, 12:00 PM ET. This decision follows the recommendation of the ARIN Mailing List Acceptable Use Policy (AUP) Committee in accordance with the procedures in ARIN's Mailing List AUP dated 27 March 2008. Mr. Anderson was previously warned in writing and temporarily suspended for violating ARIN's Mailing List AUP. Additional information and related documents can be found at: http://www.arin.net/mailing_lists/aup_comm.html Raymond A. Plzak President & CEO American Registry for Internet Numbers (ARIN) From dlr at rhinointernet.com Thu Jun 12 17:56:22 2008 From: dlr at rhinointernet.com (dlr at rhinointernet.com) Date: Thu, 12 Jun 2008 14:56:22 -0700 Subject: [arin-ppml] AUTO: David Richardson is out of the office. (returning 06/16/2008) Message-ID: I am out of the office until 06/16/2008. If you have a problem that can not wait, please call Support at 480-784-1676 or support (@) rhinointernet.com Note: This is an automated response to your message ARIN-PPML Digest, Vol 36, Issue 26 sent on 6/12/2008 9:00:00 AM. This is the only notification you will receive while this person is away. From rw at firstpr.com.au Thu Jun 12 23:00:58 2008 From: rw at firstpr.com.au (Robin Whittle) Date: Fri, 13 Jun 2008 13:00:58 +1000 Subject: [arin-ppml] IPv6 adoption, map-encap for IPv4? Message-ID: <4851E2EA.3060407@firstpr.com.au> Hi Paul, In "Re: [arin-ppml] Portable address space vs. IPv6 auto-numbering" you wrote: >>> while i am not a member of RRG, if the question is drawn as >>> clearly as that, my position would be, forget about IPv4. >>> the internet will have many more than 2^32 devices connected >>> to it simultaneously within our lifetimes, and i think we >>> should preserve the option of not using NAT in future >>> generations. >>> >>> therefore IPv4's growth has a glass ceiling formed by its >>> address size, and any effort that's put into growing its >>> routing table has a fixed return. >> >> OK - quite a few people on the RRG agree with you on this. >> >> Here is a more nuanced version: ... > > i think that what quite a few people on RRG might be in agreement > with is the first qualified statement i made, "...forget about > IPv4." however, the qualification is important: "if the question > is drawn as clearly as that," which it sounds like it isn't. The text being debated in the RRG is from co-chair Tony Li and is quite short: http://psg.com/lists/rrg/2008/msg01417.html My understanding of this is that it would make it acceptable for the RRG to work on the IPv6 problem alone, and not the IPv4 problem. On PP ML recently, I think Tony expressed a desire to solve the IPv6 routing scaling problem by change IPv6 (protocol, stack and I assume applications) to support GSE, and not work on IPv4 at all. I suggested a longer and more detailed alternative - solving the IPv4 problem soon and then taking more time with IPv6, which has more technical alternatives and less backwards compatibility constraints: http://psg.com/lists/rrg/2008/msg01444.html Tony's text has received more support than mine, though my text was supported entirely by Bill Herrin (TRRP map-encap developer) and the APT (map-encap) team supported fixing both IPv4 and IPv6 with the same approach. The remaining map-encap developers - the LISP team - haven't commented on my text, but my understanding of their earlier comments is that they want to fix both the IPv4 and IPv6 problems. So I understand that the map-encap developers in general want the RRG to recommend a fix for IPv4. > furthermore, what i mean by "fixed return" is that it's > economically damned: the more effort we put into it the more > expensive that effort will turn out to have been. i don't know > if the RRG folks are looking at this as an economics proposition > but if not, there isn't really any necessary relationship between > what i said and what they might, under different and/or synthetic > circumstances, agree with. The best place to debate Tony's proposal is the RRG list. Naturally, the more effort the more cost. My best guess is that a great deal of effort will be put into keeping IPv4 going, because IPv4 space will remain the only way to provide Internet services which people find acceptable. IPv6-only services simply don't do what most end-users want and need. David Conrad listed some major reasons why most end-users and ISPs don't want IPv6: http://psg.com/lists/rrg/2008/msg01519.html not least because "c) Very few of the applications end users want to run support IPv6". While I accept what I am told about major browsers and email programs working with IPv6 - and some games and perhaps P2P file sharing programs - I would put it another way: A high a proportion of ordinary business and home end-users would find some application would not work as expected in an IPv6-only service, and/or would find that some site, some service etc. was not available to them. This would cause many or most of them (probably the great majority) of them to be too dissatisfied to continue the service when they could get an IPv4 service from a competitor. Also, for those who remained, the ISP would face excessive support costs. > i'm not just picking nits -- your "more nuanced version" does not > represent my view correctly, it is not a restatement of any > position i've had nor of one i can agree to. My "more nuanced version" was an attempt to better state my position, which I know is very different from yours. I wasn't expecting you to agree, but was trying to draw out the differences in our perspectives. >> ... Many IETF folks have had unrealistic optimism about >> end-users wanting or needing IPv6 for over a decade. While I know >> that IPv4 with NAT etc. falls a long way short of the ideal, I >> still think many IETF folks are unrealistically optimistic about >> IPv6 adoption in the next 10 years. I think there are plenty of >> coping mechanisms for keeping IPv4 tolerable for most users in >> that time frame and probably beyond - and these will be cheaper >> and better for ISPs than trying to sell an IPv6-only service. > > while on the one hand i completely disagree, the bigger issue is, > you're just saying what you think, here, whereas in your two > previous articles you shared facts. Apart from quoted text, everything I write is based on what I think. I think you are most likely to identify my thoughts as facts when you agree with them. What I wrote above is about the future. We have no facts about the future. However, I can reliably inform you that it is a fact that I believe this about the future! >> The transition mechanisms are not there. The IPv6 Internet >> doesn't connect properly to the IPv4 Internet. People like the >> IPv4 Internet because everyone is reachable via it. > > these are plain facts and i agree. (i wanted to agree to > something here.) Yes, I prefer to agree if it is all possible. > as to optimism, jean camp showed some S curves in denver > describing adoption of technology, and while a lot of folks didn't > understand them, they were well argued and well reasoned, and they > give *no* cause for optimism wrt IPv6. so, if provable pessimism > about IPv6 were an argument in favour of prolonging the lifetime > of IPv4, you'd need look no further than elmore/camp/stephens: > > http://weis2008.econinfosec.org/papers/Elmore.pdf Thanks for pointing me to this. I have only dipped into the text. Figure 5 shows two S curves of adoption of IPv6 as a proportion of ASes. The "optimistic prediction" seems to reach 98% in 2011. The "best prediction" S-curve shows only a few percent in 2011, and seems to reach 50% around 2040. Figure 1 looks bleaker still, but does not take account of IPv4 address depletion. The faster and slower rising curves are the result of increasing or decreasing the "follower coefficient" by one standard deviation. Figure 5 is based on the IPv6 adoption rate after the drop caused by the end of 6bone. > alain durand's current plan is to native V6 to their customer > edge and backbone, and use native V6 to carry NAT'd V4, and thus > get provide stack to the comcast customer base. apple and > microsoft, as well as every IP-capable device designed or > manufactured in japan, as well as most f/l/oss software, > will all use native V6 if it's present. OK, but I think this falls a long way short of what end-users want and need in the next few years. Do the major PC firewalls and anti-virus programs work fine over IPv6-only? What about the various IM programs, AIM, Yahoo Chat etc. Searching adobe.com for IPv6 turns up some pages which suggest that at least some of their apps use IPv6. There's a bunch of shareware and freeware that people like to use. I wonder how much of that is ready for IPv6 only services. There are really strong reasons for keeping XP and avoiding whatever else Microsoft wants us to use - so it is a non-starter to expect customers to switch from XP. That would need a fix because I understand its DNS relies on IPv4. I figure most printers etc. only support IPv4, so the customers are going to be running IPv4 on their LANs and IPv6 to the outside world. I haven't tried this, but I imagine the average user is a long way from being able to use IPv6-only, without noticing any deficiencies. What about VoIP boxes and programs. How many of these are ready for IPv6 at all and how many can actually do calls and conferencing via some gateway to IPv4 without any user intervention of inconvenience? > there's a very real deployment scenario involving islands of this > kind of dual-stack, followed by address space shortages and/or > explosive routing table deaggregation, followed by heightened, > agitated capital investment in more dual-stack because > it's a way to avoid the worst pain of the shortages/explosions. I think this optimism about early migration to IPv6-only is based on an unrealistically bleak notion of how difficult it will be to make much better use of IPv4 space in the next decade or two and on an unrealistically rosy view of how many end-users won't be troubled by apps and various Internet services, not least most web-sites, not working via an IPv6-only service. I don't see how you hold this optimistic view when you agree with these statements as facts: >> The transition mechanisms are not there. The IPv6 Internet >> doesn't connect properly to the IPv4 Internet. People like the >> IPv4 Internet because everyone is reachable via it. >> I think a scalable IPv6 could be prepared, which sounds like >> heaven to many IETF people (though I still think 128 bits is 64 >> too long) - but the main population of end-users wouldn't care, >> since it is a different planet with almost none of their friends >> on it yet. > > i think we're going to see IPv6 routing table bloat earlier than > RRG's work could possibly complete, But this is not yet a fact :) > and that that's the real race here, and that any time spent > prolonging IPv4's doddering old age with double- and triple-NAT is > a dangerous distraction. the internet is not just the web, and we > can't go on building new kinds of applications if everything has > to be some kind of NAT or map-encap or ALG or proxy. IPv4 is > headed for end-of-life. let's move on. I think our discussion nicely illustrates two widely different views about IPv6 adoption in the next five years. If someone got a bunch of ordinary home users this year, and put them on an IPv6-only service with state of the art NAT-PT or whatever, and then found that 90% of them or more didn't notice much difference, and didn't make more than one or two support calls, then I would modify my views. Comcast and maybe other providers have a lot riding on this IPv6-only service model. If it is so feasible, I would have thought they would have done some actual trials with real users by now. Alternatively, they might have done a careful study of exactly what a hundred or so home and SOHO customers do with their PCs and Internet services over a period of 3 months, and then recreated a representative subset of this in the lab - to see how it flies with their IPv6-only service. There is a discussion on the RRG list about how ordinary end-users might, and to some small extent are, adopting IPv6 such as via a tunnel broker service, to give their home services a stable place on the Net, albeit the IPv6 Internet. However, many DSL modems support uPnP, and this already provides an automated and robust method by which applications on PCs can punch holes in the modem's NAT and so have a reasonably stable publicly accessible UDP or TCP port. This means they can accept incoming communications, run a web server, game server, fully functional P2P client/server etc. Various dynamic DNS services makes these servers etc. easily accessible and apparently stable to other end-users. So it is not as if this IPv6 approach is the only way of getting a stable public IP address for most users who are on single IP address DSL services with NAT in the modem. - Robin http://www.firstpr.com.au/ip/ivip/ - Robin From paul at vix.com Fri Jun 13 00:06:54 2008 From: paul at vix.com (Paul Vixie) Date: Fri, 13 Jun 2008 04:06:54 +0000 Subject: [arin-ppml] IPv6 adoption, map-encap for IPv4? In-Reply-To: Your message of "Fri, 13 Jun 2008 13:00:58 +1000." <4851E2EA.3060407@firstpr.com.au> References: <4851E2EA.3060407@firstpr.com.au> Message-ID: <27413.1213330014@sa.vix.com> > > furthermore, what i mean by "fixed return" is that it's > > economically damned: the more effort we put into it the more > > expensive that effort will turn out to have been. ... > > Naturally, the more effort the more cost. ... no, and that's pivotal. if ipv4 had legs, had a long life ahead of it, then effort spent on ipv4 would have a variable return, in which case one could conceptually speaking amortize the effort over an unknown period, which economists love (it's the miracle of capital without depreciation.) when i say "has a fixed return" you need to hear darth vader's breath and see him standing over there with a light sabre all ready to go. fixed return on a variable investment means "don't go there" and "don't do that." > The best place to debate Tony's proposal is the RRG list. i'm not qualified to debate any of tony's proposals, which is undoubtedly why i am here on PPML talking about economics and policy, rather than over on RRG talking about ones and zeroes. > > alain durand's current plan is to native V6 to their customer edge and > > backbone, and use native V6 to carry NAT'd V4, and thus get provide stack > > to the comcast customer base. apple and microsoft, as well as every > > IP-capable device designed or manufactured in japan, as well as most > > f/l/oss software, will all use native V6 if it's present. > > > > there's a very real deployment scenario involving islands of this kind of > > dual-stack, followed by address space shortages and/or explosive routing > > table deaggregation, followed by heightened, agitated capital investment > > in more dual-stack because it's a way to avoid the worst pain of the > > shortages/explosions. > OK, but I think this falls a long way short of what end-users want and need > in the next few years. there is no direct path between what end-users want or need, and what we make available. it's an indirect path, and all i intend to show with the above is that there will be a way for the earliest people who have nothing to sell and therefore feel pain, to avoid that pain. ljcamp's s-curve shows that the period during which people feel pain will be long. my example shows that they will have choices less painful than going out of business or bootlegging IPv4 address space or paying speculators for IPv4 address space or living with explosive IPv4 routing table deaggregation. human history shows that with those choices available, we will see pressure on the IPv6 routing table soon enough that working on anything else than locator-id split for IPv6 is an irresponsible and dangerous waste of time. > I think this optimism about early migration to IPv6-only is based on an > unrealistically bleak notion of how difficult it will be to make much better > use of IPv4 space in the next decade or two and on an unrealistically rosy > view of how many end-users won't be troubled by apps and various Internet > services, not least most web-sites, not working via an IPv6-only service. i don't call it optimism. there will be a lot of pain for a lot of people, since human history shows that everybody does their homework at 1AM the night before it's due, and the network effect says that everybody is everybody else's hostage when it comes to IPv6 adoption. however, people will have choices. and if you think my notions of the IPv4 endgame are bleak, you should come to los angeles in october and put a couple of beers into john curran and ask him why explosive deaggregation is absolutely inevitable. then you'll start calling me "mr. sunshine". > If someone got a bunch of ordinary home users this year, and put them on an > IPv6-only service with state of the art NAT-PT or whatever, and then found > that 90% of them or more didn't notice much difference, and didn't make more > than one or two support calls, then I would modify my views. "oh i hope and pray that they will..." (schoolhouse rock) > However, many DSL modems support uPnP, and this already provides an > automated and robust method by which applications on PCs can punch holes in > the modem's NAT and so have a reasonably stable publicly accessible UDP or > TCP port. This means they can accept incoming communications, run a web > server, game server, fully functional P2P client/server etc. Various > dynamic DNS services makes these servers etc. easily accessible and > apparently stable to other end-users. So it is not as if this IPv6 approach > is the only way of getting a stable public IP address for most users who are > on single IP address DSL services with NAT in the modem. when i wrote the software described by http://sa.vix.com/~vixie/proxynet.pdf in ~1995, i knew that i was making all kinds of cool things possible and thus opening alternatives. but i also knew it wouldn't scale, wouldn't last, was not the desireable way forward as would be measured through the lens of history. that's how uPnP's above-described feature set looks to me right now. if you're having a conflict of vision having to do with ALG/NAT vs end-to-end then i don't want to be involved. ALG/NAT feels too much like minitel, compuserve, old-AOL, old-MSN, none of which have inspired internet growth, and all of which were swept aside by internet growth. From tedm at ipinc.net Thu Jun 12 15:41:48 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 12 Jun 2008 12:41:48 -0700 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: <98747.1213280210@sa.vix.com> Message-ID: <0FA3035B5C7C4C599373F790320E900B@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Paul Vixie > Sent: Thursday, June 12, 2008 7:17 AM > To: Robin Whittle > Cc: PPML > Subject: Re: [arin-ppml] Portable address space vs. IPv6 > auto-numbering > > > > The transition mechanisms are not there. The IPv6 Internet doesn't > > connect properly to the IPv4 Internet. People like the > IPv4 Internet > > because everyone is reachable via it. > > these are plain facts and i agree. (i wanted to agree to > something here.) > I have to disagree. "People" don't gave a damn about the transport, they care about the data. If what they want is on IPv4, they will use IPv4, if what they want is on IPv6, they will use IPv6. If they are only given IPv6 as long as what they want is available from it, they simply won't give a damn. A more correct restatement of what Robin said is: "People like the Internet because everyone is reachable via it." If "the Internet" was entirely IPv6 they wouldn't like it any less. > as to optimism, jean camp showed some S curves in denver > describing adoption of technology, and while a lot of folks > didn't understand them, they were well argued and well > reasoned, and they give *no* cause for optimism wrt IPv6. > so, if provable pessimism about IPv6 were an argument in > favour of prolonging the lifetime of IPv4, you'd need look no > further than elmore/camp/stephens: > > http://weis2008.econinfosec.org/papers/Elmore.pdf > All of this is beside the point, because the argument that adoption curves of technology have any relation to whether a technology is ultimately adopted isn't valid. There are many technologies that had slow adoption curves that were ultimately adopted, just as there are many technologies that had rapid adoption curves that were ultimately discarded. And advance predictions have a way of being wrong. As for the argument that a relatively small fraction of the IP addresses currently advertised are actually in use, well whether "the market" coughs up those "3.7B which could be advertised" IPv4 addresses, or whether it doesen't, POST IPv4 runout, is at this point really just speculation. We won't know until after IPv4 runout. As for other schemes to extend IPv4, such as "selling" them, I find it very amazing that some of the biggest proponents of an IPv4 "sales market" as a way of extending the life of IPv4, have so little faith in the operation of the market to find all these dusy old unused IPv4 subnets that we aren't advertising, post-IPv4 runout. Once IPv4 is runout, people who want portable assignments of IPv4 won't be able to get them, so they will have to settle for non-portable IPv4 assignments from this great, possibly-mythical, pool of 3.7B unadvertised IP addresses. So for a number of years "the market" will have a growing number of ISP's and others who really -want- portable IPv4, but are stuck with paying a provider for non-portable IPv4. It seems perfectly logical to me that once that mass of ISP's and people who are stuck gets large enough, that will tip the balance to IPv6 regardless of it's deficiencies. Ted From awahid at cwgo.com Fri Jun 13 01:51:36 2008 From: awahid at cwgo.com (Aamir Wahid) Date: Fri, 13 Jun 2008 01:51:36 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 36, Issue 27 Message-ID: <952962674@mail.cwgo.com> From michael.dillon at bt.com Fri Jun 13 08:13:36 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 13 Jun 2008 13:13:36 +0100 Subject: [arin-ppml] simple question about money In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901BB78D3@SUEXCL-02.ad.syr.edu> Message-ID: > It seems to me that the two biggest policy issues facing RIRs > today are address transfers (in effect, the creation of a > much-needed private secondary market to move scarce v4 > addresses from underutilized allocations/assignments to those > who need them more) and the costs or fees associated with > granting assignments or allocations. That's like saying that we should create a much-needed secondary market for used cars so that cars which have been stolen can be more easily sold to those who badly need a car for transport. It's too hard at present because you have to file off vehicle registration numbers or ship them to Africa or the former Soviet countries where nobody will notice that the registration numbers belong to stolen vehicles. Currently ARIN policy only allows for organizations to receive IP address allocations or assignments if they can show a technical need for the addresses. If the technical need has ceased to exist, then these organizations are no longer LEGITIMATELY holding those resources. Of course, we don't get anal about this, especially in the case of ISPs since shrinkage in one part of their network may only be temporary followed by growth in another part of the network. Look at ARIN's long term IP allocation charts to see this when the telecom collapse caused a drop in new allocations. Then once the networks began to grow again, they used up their surpluses and began to apply for new addresses again. It is strange to see an economist who does not recognize the fact than when a fixed resource nears exhaustion, there just isn't anything available for people to sell because everyone is in the same boat. --Michael Dillon From alain_durand at cable.comcast.com Fri Jun 13 09:15:04 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Fri, 13 Jun 2008 09:15:04 -0400 Subject: [arin-ppml] 464: was (Re: IPv6 adoption, map-encap for IPv4?) In-Reply-To: <4851E2EA.3060407@firstpr.com.au> Message-ID: On 6/12/08 11:00 PM, "Robin Whittle" wrote: > Comcast and maybe other providers have a lot riding on this > IPv6-only service model. If it is so feasible, I would have thought > they would have done some actual trials with real users by now. > Alternatively, they might have done a careful study of exactly what > a hundred or so home and SOHO customers do with their PCs and > Internet services over a period of 3 months, and then recreated a > representative subset of this in the lab - to see how it flies with > their IPv6-only service. I would suggest you read any of my presentations about 464. I clearly say that an IPv6-only service to broadband customers is a non starter today. 464 is all about providing IPv4 service for legacy PC/apps while provisioning the home gateway with IPv6-only, no IPv4 on the WAN interface. Think of IPv6 a a wonderful end to end L2 taking our packets to the nearest IPv4-IPv4 NAT box ;-) IMHO, 464 is a technology that makes IPv6 backward compatible with IPv4. As about trials, we are doing some this year. We used a preview of the technology at IETF71 in Philadelphia last March during the planned IPv4 outage. We are expecting to demo the full technology at the next NANOG/ARIN meeting in LA. - Alain. From mueller at syr.edu Fri Jun 13 10:16:48 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 13 Jun 2008 10:16:48 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901BB78D3@SUEXCL-02.ad.syr.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9011DC960@SUEXCL-02.ad.syr.edu> > -----Original Message----- > [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com > > > Currently ARIN policy only allows for organizations to receive IP > address allocations or assignments if they can show a > technical need for the addresses. But as you yourself implicitly recognize, once the addresses have been assigned, they don't come back. And as you also recognized in your reference to the telecom collapse, in many cases it is perfectly rational for organizations that have been assigned addresses to hold on to them even if they have more than they presently need, because they may grow in the future, and the process of "demonstrating need" to a central planning authority is costly, time consuming and unpleasant. So your comparison of these organizations to car thieves is just inflammatory rhetoric that doesn't solve any problem. Good policy pays attention to how people actually behave and what their rational incentives are. If your policy is founded on the assumption that commercial ISPs and corporations will voluntarily give up resources that don't cost them anything to hold in order to help other ISPs or organizations, it probably won't work, because that assumption doesn't square with how people actually behave. > If the technical need has ceased to exist, > then these organizations are no longer LEGITIMATELY holding those resources. So, what do you think is a better way to get them back? Get people on the ARIN PPML to call them bad names? Or provide them tangible economic benefits to transfer them to someone who does need them? If ISP A needs addresses and ISP B is willing to give up addresses that it doesn't need as long as it receives some compensation, why should anyone object? > It is strange to see an economist who does not recognize the fact than > when a fixed resource nears exhaustion, there just isn't anything > available for people to sell because everyone is in the same boat. I think you misunderstand the issue here. The fundamental insight behind the address transfer policy is that there is a huge difference between "exhaustion" of _assignments_, which is purely nominal, and the exhaustion of the _actually used_ address space, which we may not have reached. There may be large amounts of address space that are assigned, but unused. The assignees nevertheless hold on to that space because they get no benefits from giving it up, but incur real costs and risks if they do. We've been through a very similar situation with respect to radio spectrum. There has been a 50-year war between broadcasters and mobile telecom interests over the UHF spectrum resources. There is little doubt about the fact that the UHF spectrum allocated to broadcasters is vastly underutilized. Nevertheless, broadcaster industry organizations (NAB, etc.) have invested IMMENSE political and financial resources into hanging on to that spectrum and preventing a reallocation to mobile telecom. Broadcasters hoard spectrum because they know that they have control of an extremely valuable asset and once they give it up other firms will benefit and they won't. Legally, spectrum is the property of "the public." But railing about the public airwaves doesn't do anyone a bit of good in this policy dispute. From mueller at syr.edu Fri Jun 13 10:43:21 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 13 Jun 2008 10:43:21 -0400 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: <0FA3035B5C7C4C599373F790320E900B@tedsdesk> References: <98747.1213280210@sa.vix.com> <0FA3035B5C7C4C599373F790320E900B@tedsdesk> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9011DC961@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: arin-ppml-bounces at arin.net > > As for the argument that a relatively small fraction of the IP > addresses currently advertised are actually in use, well > whether "the market" coughs up those "3.7B which could be advertised" > IPv4 addresses, or whether it doesen't, POST IPv4 runout, is > at this point really just speculation. The degree to which that happens is highly uncertain, but it's a bit more than speculation. We know that gray market IP address transfers have already been going on, and we have experience with secondary markets in other resources, such as bandwidth and spectrum. > We won't know until after > IPv4 runout. Two points. First, I don't understand why you need to wait for what you call "IPv4 runout" (see point 2) to permit transfers. You could do it tomorrow. Second, and pardon me if this sounds pedantic, but people who understand price systems know that resources don't literally "run out" unless there is something drastically wrong with the social systems used to ration them. They become increasingly scarce and expensive. We will never, for example, actually "run out" of oil. It may eventually become so scarce that you only see it in tiny vials displayed as jewelry around the necks of beautiful models, but it won't "run out." More importantly, I am wondering how you view the impact of v4 transfer markets on the v6 transition. This seems an important issue. Let's suppose it is fantastically successful at prolonging the life of v4 Internet by releasing many unused address resources. Does it then discourage v6 migration? Or does it over the longer term improve the value proposition for v6 by making the fees/costs associated with v6 addresses look more favorable? From michael.dillon at bt.com Fri Jun 13 11:05:51 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 13 Jun 2008 16:05:51 +0100 Subject: [arin-ppml] simple question about money In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DC960@SUEXCL-02.ad.syr.edu> Message-ID: > But as you yourself implicitly recognize, once the addresses > have been assigned, they don't come back. Don't put words in my mouth. It is rude and you can't get away with it on this list. The fact is that addresses do come back. ISPs regularly recover customer assigned addresses. ARIN also gets back address blocks for various reasons. Even IANA has received addresses back such as the 14/8 block. > And as you also > recognized in your reference to the telecom collapse, in many > cases it is perfectly rational for organizations that have > been assigned addresses to hold on to them even if they have > more than they presently need, because they may grow in the > future, and the process of "demonstrating need" to a central > planning authority is costly, time consuming and unpleasant. Part of the process of "technical justification" does allow for intent to use the addresses. You don't need to buy equipment, configure it, and give ARIN a tour of the boxes. > So your comparison of these organizations to car thieves is > just inflammatory rhetoric that doesn't solve any problem. Car thieves do not have a justification for owning the car that they are selling. In the same way, an ISP who has an ARIN allocation which is more than they need, and which they DO NOT INTENT TO USE, is breaking ARIN laws/policies. The car thief analogy is perfectly valid and I expect that most people realize that I am not suggesting that ARIN policy has the same weight as US law. I am simply pointing out that an ISP with a surplus of addresses that they do not intend to use, has the same relation to ARIN policy as someone who finds a wallet on the sidewalk. If you return the wallet, then you are good upright citizen. If you keep the wallet, then you are just like a car thief selling auto parts. > Good policy pays attention to how people actually behave and > what their rational incentives are. If your policy is founded > on the assumption that commercial ISPs and corporations will > voluntarily give up resources that don't cost them anything > to hold in order to help other ISPs or organizations, it > probably won't work, because that assumption doesn't square > with how people actually behave. Let's see. I have surplus IPv4 addresses which can only mean that I am either on the verge of bankruptcy or I have a healthy IPv6 deployment with good customer takeup. Do I give my surplus back to ARIN in order to help my poor IPv4 brethren or do I hoard it. If I'm on the verge of bankruptcy, hoarding won't make a difference because the IPv4 market is shrinking and those who most need IPv4 addresses are living off their internal supply from customer churn. If I'm deploying IPv6 then I don't give a damn what the IPv4 ISPs do because they can't hurt me. I may as well make a big public fuss about handing back my unneeded IPv4 adresses to ARIN, after having hired some extra sales people to handle the rush of new business. > So, what do you think is a better way to get them back? Get > people on the ARIN PPML to call them bad names? Or provide > them tangible economic benefits to transfer them to someone > who does need them? If ISP A needs addresses and ISP B is > willing to give up addresses that it doesn't need as long as > it receives some compensation, why should anyone object? Because it is selling. It either happens in private or it happens in an open public market. To create an open and public market is not easy, and is even risky because of the maze of laws and regulations. The ARIN BoT could end up in jail if they don't do it right, and doing it right costs a lot of money. It is easier to not do it at all and continue with the current policy which discourages selling entirely. A few wierdos hand over money anyway, but since there are no guarantees that BOUGHT addresses will work, this has never picked up any momentum. It has been happening since the mid 1990's if not earlier, but it is a drop in the bucket, not a market. > I think you misunderstand the issue here. The fundamental > insight behind the address transfer policy is that there is a > huge difference between "exhaustion" of _assignments_, which > is purely nominal, and the exhaustion of the _actually used_ > address space, which we may not have reached. There is a hierarchy of assignments and they all run out in the same way. First IANA runs out but the RIRs have some. Then, one by one, the RIRs run out but in an unpredictable order. Then, the large ISPs begin to run out PoP by PoP, also in an unpredictable order. Nobody can know how many addresses are "free" in the ISPs since "free" is hard to pin down. If I shut down a dialup pool and put those addresses in limbo for 4 months while I try to cleanse the DUL lists, are they really "free"? If I notify all small business customers that when contract renewal time comes up, I will not renew contracts unless they agree to go to NAT, hand back their address allocations, and live behind a single statically assigned address per circuit, then are those handed-back addresses "free". > There may be > large amounts of address space that are assigned, but unused. > The assignees nevertheless hold on to that space because they > get no benefits from giving it up, but incur real costs and > risks if they do. Yes. One benefit is that they encourage more IPv6 deployment which can lead to more business for forward thinking IPv6 ISPs. The risk from giving it up is that less people buy IPv6 services. > Nevertheless, broadcaster industry organizations (NAB, > etc.) have invested IMMENSE political and financial resources > into hanging on to that spectrum and preventing a > reallocation to mobile telecom. Yes, but in this industry the opposite had happened. We have created a new kind of spectrum which is so vast that it will be hard for anyone (except the RIRs) to hang onto enough spectrum that it will block other users. That new spectrum is IPv6. And that is the reason why we don't need FCC or other regulatory oversight, or any kind of IP address markets. --Michael Dillon From rw at firstpr.com.au Fri Jun 13 11:49:19 2008 From: rw at firstpr.com.au (Robin Whittle) Date: Sat, 14 Jun 2008 01:49:19 +1000 Subject: [arin-ppml] 464: was (Re: IPv6 adoption, map-encap for IPv4?) In-Reply-To: References: Message-ID: <485296FF.8090908@firstpr.com.au> Hi Alain, I read your Internet Draft a couple of weeks ago: http://tools.ietf.org/html/draft-durand-v6ops-natv4v6v4-01 but couldn't easily find your presentations. Please let me know where they are. I assume 464 involves multiple customers sharing a remote NAT box with a single public IPv4 address. I understand the primary motivation here is to eliminate the current requirement that each customer's DSL or DOCSIS service have its own public IPv4 address. Does each user PC get a link to the remote NAT box, meaning each PC experiences a single layer of NAT to the IPv4 Internet? Or does the home modem operate as a NAT box in some way for IPv4, and that NAT box gets a link through 464 to another remote NAT box which actually has a public IPv4 address? I understand uPnP Internet Gateway Device (IGD) is implemented in many DSL modems and used by applications now to get a hole through their DSL (DOCSIS too?) modem's NAT - so the application has direct access to a UDP/TCP port in that modem's single public IPv4 address. That means ordinary users, with little or no effort or awareness, can run servers, receive incoming communications etc. when an application needs to. Dynamic DNS enables these servers etc. to be reachable via stable FQDNs. If 464 presents the PC with a single layer of NAT, maybe it could do uPnP IGD too. But if 464 is double NAT, I guess this wouldn't work. Either way, by trying to squeeze multiple customers onto a single IPv4 address (or into fewer IPv4 addresses than customers), even if uPnP works, there will be clashes when two customers on the same NAT box want the same port. That is OK when the NAT box is at home, used by the one customer. A family or office can fight it out amongst themselves who gets each port. But it does not seem to me like a workable solution for customers who expect (even without knowing what it is) for uPnP to work as it does on today's ordinary IPv4 services. As far as I know, with 464, each customer would have to take their chances with what other customers are doing with uPnP IGD capacity of the one NAT box they share. I guess the NAT box could have more than one IPv4 address - but then this is getting messy, trying to guess how many of the customers of that box want the same port. Does the customer run their own private IPv4 network? I assume their network isn't shared with other customers. Thanks for this: > I clearly say that an IPv6-only service to broadband customers is > a non starter today. Some folks are citing Comcast leading the way as evidence that IPv6-only services will soon by practical . . . widespread . . . and perhaps ubiquitous much sooner than people like me expect. > Think of IPv6 as a wonderful end to end L2 taking our packets to > the nearest IPv4-IPv4 NAT box ;-) OK. > IMHO, 464 is a technology that makes IPv6 backward compatible with > IPv4. I disagree entirely. As far as most end-user traffic is concerned, all I think you are doing with 464 is using IPv6 as a "wonderful end to end L2 taking packets to the nearest IPv4-IPv4 NAT box"! I can't imagine ubiquitous IPv6-only services - without relying primarily on IPv4 as you are with 464 - being viable until: 1 - Most websites, IM servers, game servers etc. are available via IPv6. 2 - Most Operating systems, applications work fine with IPv6 only, or dual stack. where "Most" means something like 95%, 99% or 99.9%. This is a stupendous global chicken and egg problem. Even dual stack IPv6 adoption is minute and glacial, but these two interdependent conditions require applications and operating systems which can survive fine without IPv4 at all. There's no real reason for 1 to occur until 2 occurs - no reason for 2 unless 1 eventuates. Until then all applications and services will have to support IPv4, which means having IPv6 doesn't really provide any substantial added value for end-users. An IPv6 service can provide each end-user with a stable patch of public IPv6 address space they could use for servers etc. However, I understand that end-users can already use uPnP IGD for that. IPv6 proponents have great hopes that the IPv4 address depletion problem will cause many ISPs and end-users to have no option but to jump ship. However, as you implicitly acknowledge, we are a long way from there being a situation where the great majority of end-users can be happy, without excessive support calls, with an IPv6-only service: not nearly enough applications nor services run with IPv6 yet. I believe there is great scope for using IPv4 space more efficiently than at present, especially by using a map-encap scheme - but that view is not shared by many people today. I doubt that ISPs using IPv6 access networks as a link between customers' PCs and an IPv4 NAT box would advance genuine IPv6 adoption much, or the development of IPv6 capable applications and servers. - Robin http://www.firstpr.com.au/ip/ivip/ From Daniel_Alexander at Cable.Comcast.com Fri Jun 13 12:09:43 2008 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Fri, 13 Jun 2008 12:09:43 -0400 Subject: [arin-ppml] IPv6 adoption, map-encap for IPv4? In-Reply-To: <4851E2EA.3060407@firstpr.com.au> References: <4851E2EA.3060407@firstpr.com.au> Message-ID: <997BC128AE961E4A8B880CD7442D948005664301@NJCHLEXCMB01.cable.comcast.com> Robin, I hope you make it to the ARIN meeting in LA this fall, and have a chance to talk directly to many of the people on this list. These are discussions that should continue. As I've been reading this thread, however I can't get past two concepts. These are that you are of the opinion the IPv4 Internet is underutilized because experiments can only ping ~100 million IP. The other is that IPv6 deployment is a failure because its not already deployed. People continue to think that someone will be able to "see" the whole (I)nternet. That it is a static, while growing, thing that can be mapped. Since everyone likes to use Comcast as a reference, here are some facts. Comcast has more than 38 million active interfaces using RIR allocated IP addresses. If you factor in re-use of private networks, another 35 million IP are being used of RFC1918 space. Your thoughts on utilization would imply that Comcast makes up around 37% of the Internet. I can't speak with authority, but I'm quite confident that is not the case. Also keep in mind what you consider "utilized". If you have a VLAN with a /26, and 50 interfaces connected, are the 50 IP utilized, or are all 64 now unusable anywhere else on the network. The 38 million number I quote does not include subnet loss, aggregation, capacity maintenance, or deployment plans. Also consider, we have had arrangements with other providers, where we routed RFC1918 space outside our AS boundries. My point to this paragraph is simply the Internet is much more utilized that anyone can, or will ever see. Paul made a good point that applies to IPv6 deployment. It didn't matter that you had a week to study for the final exam. Other items were prioritized and the studying happens the night before. It is a fair assumption that there is at least one or two years of IPv4 space left in the IANA pool. Would it be remotely responsible for any company to drop everything to ensure IPv6 is already deployed, when Ipv4 space is still readily available? Now I'm not saying they wait until the last minute. I'm simply saying many companies will prioritize accordingly. Where your assumption is off, is that you think no one is, or wants to work on it. Any company that wants to wait until the night before, will suffer the appropriate fate in the marketplace. But like the utilization of the IP address space, no one will never see what most companies are working on, or how they have prioritized IPv6 deployment, until after the fact. In the end, the IPv4 space will become fully allocated, and IPv6 deployments will spread like a brushfire. Of course this should all be considered just another opinion. Thanks, Dan Alexander Comcast Cable ARIN AC -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Robin Whittle Sent: Thursday, June 12, 2008 11:01 PM To: PPML Cc: Paul Vixie Subject: [arin-ppml] IPv6 adoption, map-encap for IPv4? Hi Paul, In "Re: [arin-ppml] Portable address space vs. IPv6 auto-numbering" you wrote: >>> while i am not a member of RRG, if the question is drawn as clearly >>> as that, my position would be, forget about IPv4. >>> the internet will have many more than 2^32 devices connected to it >>> simultaneously within our lifetimes, and i think we should preserve >>> the option of not using NAT in future generations. >>> >>> therefore IPv4's growth has a glass ceiling formed by its address >>> size, and any effort that's put into growing its routing table has a >>> fixed return. >> >> OK - quite a few people on the RRG agree with you on this. >> >> Here is a more nuanced version: ... > > i think that what quite a few people on RRG might be in agreement with > is the first qualified statement i made, "...forget about IPv4." > however, the qualification is important: "if the question is drawn as > clearly as that," which it sounds like it isn't. The text being debated in the RRG is from co-chair Tony Li and is quite short: http://psg.com/lists/rrg/2008/msg01417.html My understanding of this is that it would make it acceptable for the RRG to work on the IPv6 problem alone, and not the IPv4 problem. On PP ML recently, I think Tony expressed a desire to solve the IPv6 routing scaling problem by change IPv6 (protocol, stack and I assume applications) to support GSE, and not work on IPv4 at all. I suggested a longer and more detailed alternative - solving the IPv4 problem soon and then taking more time with IPv6, which has more technical alternatives and less backwards compatibility constraints: http://psg.com/lists/rrg/2008/msg01444.html Tony's text has received more support than mine, though my text was supported entirely by Bill Herrin (TRRP map-encap developer) and the APT (map-encap) team supported fixing both IPv4 and IPv6 with the same approach. The remaining map-encap developers - the LISP team - haven't commented on my text, but my understanding of their earlier comments is that they want to fix both the IPv4 and IPv6 problems. So I understand that the map-encap developers in general want the RRG to recommend a fix for IPv4. > furthermore, what i mean by "fixed return" is that it's economically > damned: the more effort we put into it the more expensive that effort > will turn out to have been. i don't know if the RRG folks are looking > at this as an economics proposition but if not, there isn't really any > necessary relationship between what i said and what they might, under > different and/or synthetic circumstances, agree with. The best place to debate Tony's proposal is the RRG list. Naturally, the more effort the more cost. My best guess is that a great deal of effort will be put into keeping IPv4 going, because IPv4 space will remain the only way to provide Internet services which people find acceptable. IPv6-only services simply don't do what most end-users want and need. David Conrad listed some major reasons why most end-users and ISPs don't want IPv6: http://psg.com/lists/rrg/2008/msg01519.html not least because "c) Very few of the applications end users want to run support IPv6". While I accept what I am told about major browsers and email programs working with IPv6 - and some games and perhaps P2P file sharing programs - I would put it another way: A high a proportion of ordinary business and home end-users would find some application would not work as expected in an IPv6-only service, and/or would find that some site, some service etc. was not available to them. This would cause many or most of them (probably the great majority) of them to be too dissatisfied to continue the service when they could get an IPv4 service from a competitor. Also, for those who remained, the ISP would face excessive support costs. > i'm not just picking nits -- your "more nuanced version" does not > represent my view correctly, it is not a restatement of any position > i've had nor of one i can agree to. My "more nuanced version" was an attempt to better state my position, which I know is very different from yours. I wasn't expecting you to agree, but was trying to draw out the differences in our perspectives. >> ... Many IETF folks have had unrealistic optimism about end-users >> wanting or needing IPv6 for over a decade. While I know that IPv4 >> with NAT etc. falls a long way short of the ideal, I still think many >> IETF folks are unrealistically optimistic about >> IPv6 adoption in the next 10 years. I think there are plenty of >> coping mechanisms for keeping IPv4 tolerable for most users in that >> time frame and probably beyond - and these will be cheaper and better >> for ISPs than trying to sell an IPv6-only service. > > while on the one hand i completely disagree, the bigger issue is, > you're just saying what you think, here, whereas in your two previous > articles you shared facts. Apart from quoted text, everything I write is based on what I think. I think you are most likely to identify my thoughts as facts when you agree with them. What I wrote above is about the future. We have no facts about the future. However, I can reliably inform you that it is a fact that I believe this about the future! >> The transition mechanisms are not there. The IPv6 Internet doesn't >> connect properly to the IPv4 Internet. People like the >> IPv4 Internet because everyone is reachable via it. > > these are plain facts and i agree. (i wanted to agree to something > here.) Yes, I prefer to agree if it is all possible. > as to optimism, jean camp showed some S curves in denver describing > adoption of technology, and while a lot of folks didn't understand > them, they were well argued and well reasoned, and they give *no* > cause for optimism wrt IPv6. so, if provable pessimism about IPv6 were > an argument in favour of prolonging the lifetime of IPv4, you'd need > look no further than elmore/camp/stephens: > > http://weis2008.econinfosec.org/papers/Elmore.pdf Thanks for pointing me to this. I have only dipped into the text. Figure 5 shows two S curves of adoption of IPv6 as a proportion of ASes. The "optimistic prediction" seems to reach 98% in 2011. The "best prediction" S-curve shows only a few percent in 2011, and seems to reach 50% around 2040. Figure 1 looks bleaker still, but does not take account of IPv4 address depletion. The faster and slower rising curves are the result of increasing or decreasing the "follower coefficient" by one standard deviation. Figure 5 is based on the IPv6 adoption rate after the drop caused by the end of 6bone. > alain durand's current plan is to native V6 to their customer edge and > backbone, and use native V6 to carry NAT'd V4, and thus get provide > stack to the comcast customer base. apple and microsoft, as well as > every IP-capable device designed or manufactured in japan, as well as > most f/l/oss software, will all use native V6 if it's present. OK, but I think this falls a long way short of what end-users want and need in the next few years. Do the major PC firewalls and anti-virus programs work fine over IPv6-only? What about the various IM programs, AIM, Yahoo Chat etc. Searching adobe.com for IPv6 turns up some pages which suggest that at least some of their apps use IPv6. There's a bunch of shareware and freeware that people like to use. I wonder how much of that is ready for IPv6 only services. There are really strong reasons for keeping XP and avoiding whatever else Microsoft wants us to use - so it is a non-starter to expect customers to switch from XP. That would need a fix because I understand its DNS relies on IPv4. I figure most printers etc. only support IPv4, so the customers are going to be running IPv4 on their LANs and IPv6 to the outside world. I haven't tried this, but I imagine the average user is a long way from being able to use IPv6-only, without noticing any deficiencies. What about VoIP boxes and programs. How many of these are ready for IPv6 at all and how many can actually do calls and conferencing via some gateway to IPv4 without any user intervention of inconvenience? > there's a very real deployment scenario involving islands of this kind > of dual-stack, followed by address space shortages and/or explosive > routing table deaggregation, followed by heightened, agitated capital > investment in more dual-stack because it's a way to avoid the worst > pain of the shortages/explosions. I think this optimism about early migration to IPv6-only is based on an unrealistically bleak notion of how difficult it will be to make much better use of IPv4 space in the next decade or two and on an unrealistically rosy view of how many end-users won't be troubled by apps and various Internet services, not least most web-sites, not working via an IPv6-only service. I don't see how you hold this optimistic view when you agree with these statements as facts: >> The transition mechanisms are not there. The IPv6 Internet doesn't >> connect properly to the IPv4 Internet. People like the >> IPv4 Internet because everyone is reachable via it. >> I think a scalable IPv6 could be prepared, which sounds like heaven >> to many IETF people (though I still think 128 bits is 64 too long) - >> but the main population of end-users wouldn't care, since it is a >> different planet with almost none of their friends on it yet. > > i think we're going to see IPv6 routing table bloat earlier than RRG's > work could possibly complete, But this is not yet a fact :) > and that that's the real race here, and that any time spent prolonging > IPv4's doddering old age with double- and triple-NAT is a dangerous > distraction. the internet is not just the web, and we can't go on > building new kinds of applications if everything has to be some kind > of NAT or map-encap or ALG or proxy. IPv4 is headed for end-of-life. > let's move on. I think our discussion nicely illustrates two widely different views about IPv6 adoption in the next five years. If someone got a bunch of ordinary home users this year, and put them on an IPv6-only service with state of the art NAT-PT or whatever, and then found that 90% of them or more didn't notice much difference, and didn't make more than one or two support calls, then I would modify my views. Comcast and maybe other providers have a lot riding on this IPv6-only service model. If it is so feasible, I would have thought they would have done some actual trials with real users by now. Alternatively, they might have done a careful study of exactly what a hundred or so home and SOHO customers do with their PCs and Internet services over a period of 3 months, and then recreated a representative subset of this in the lab - to see how it flies with their IPv6-only service. There is a discussion on the RRG list about how ordinary end-users might, and to some small extent are, adopting IPv6 such as via a tunnel broker service, to give their home services a stable place on the Net, albeit the IPv6 Internet. However, many DSL modems support uPnP, and this already provides an automated and robust method by which applications on PCs can punch holes in the modem's NAT and so have a reasonably stable publicly accessible UDP or TCP port. This means they can accept incoming communications, run a web server, game server, fully functional P2P client/server etc. Various dynamic DNS services makes these servers etc. easily accessible and apparently stable to other end-users. So it is not as if this IPv6 approach is the only way of getting a stable public IP address for most users who are on single IP address DSL services with NAT in the modem. - Robin http://www.firstpr.com.au/ip/ivip/ - Robin _______________________________________________ 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From alain_durand at cable.comcast.com Fri Jun 13 12:30:59 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Fri, 13 Jun 2008 12:30:59 -0400 Subject: [arin-ppml] 464: was (Re: IPv6 adoption, map-encap for IPv4?) In-Reply-To: <485296FF.8090908@firstpr.com.au> Message-ID: On 6/13/08 11:49 AM, "Robin Whittle" wrote: > Hi Alain, > > I read your Internet Draft a couple of weeks ago: > > http://tools.ietf.org/html/draft-durand-v6ops-natv4v6v4-01 > > but couldn't easily find your presentations. Please let me know > where they are. I'll send you a private copy of the latest slide deck. > I assume 464 involves multiple customers sharing a remote NAT box > with a single public IPv4 address. I understand the primary > motivation here is to eliminate the current requirement that each > customer's DSL or DOCSIS service have its own public IPv4 address. Correct. > Does each user PC get a link to the remote NAT box, meaning each PC > experiences a single layer of NAT to the IPv4 Internet? > > Or does the home modem operate as a NAT box in some way for IPv4, > and that NAT box gets a link through 464 to another remote NAT box > which actually has a public IPv4 address? The idea is that the home gateway will be provisioned on the WAN with only IPv6 and will run DHCPv4 with 192.168.0.0 on the LAN side. Now, instead of translating outgoing IPv4 packets, it will forward them unchanged inside of an IPv6 tunnel which endpoint is somewhere within the service provider network. That endpoint will decapsulate the packet and translate the original IPv4 packet to use a global IPv4 source address. Of course, that carrier grade NAT will have to use the IPv6 tunnel src address as part of its mapping table instead of the IPv4 address of the original packet. That way, there is effectively only one level of NAT. Manual port forwarding cannot be supported, of course. We are now studying what is the impact on p2p protocols and uPNP. Note: It is actually possible to run a 464 client on a stand alone device (ie not behind a home gateway) that is connected only with IPv6. That device pick up any random or well know IPv4 src address (even 127.0.0.1 could work), figure out the IPv4 destination (resolve A records over IPv6 DNS), and ship the packet over the 464 tunnel. That way, you can run v4 apps, browse the v4 Internet, all that on a v6-only configured device... - Alain. From mueller at syr.edu Fri Jun 13 12:40:57 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 13 Jun 2008 12:40:57 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD9011DC960@SUEXCL-02.ad.syr.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9011DC96C@SUEXCL-02.ad.syr.edu> > -----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: Friday, June 13, 2008 11:06 AM > To: ppml at arin.net > Subject: Re: [arin-ppml] simple question about money > > > But as you yourself implicitly recognize, once the addresses > > have been assigned, they don't come back. > > Don't put words in my mouth. It is rude and you can't get > away with it on this list. Hmmm. I think reasonable people can see for themselves which comment was more or less uncivil. From my point of view this is a fairly technical policy discussion and I see nothing to get hot about. > The fact is that addresses do come back. ISPs regularly recover > customer assigned addresses. ARIN also gets back address blocks > for various reasons. Even IANA has received addresses back such > as the 14/8 block. Sure, there are a few actors who will respond to moral suasion, such as the University that returned the /8 it obviously didn't need. But you can't count on that. And of course ISPs recover addresses from their customers, they have an economic incentive to do so. But tell me how often ISPs surrender addresses back to RIRs? Facts would be helpful here, no reason to rely on opinions. Are stastistics from ARIN and other RIRs available on this? I see no obvious place to look for address block returns on the ARIN site, but would love to be more informed. > Part of the process of "technical justification" does allow for > intent to use the addresses. Sure, but "intent" is obviously rather subjective, and provides a huge areas of latitude for holding on to things. > > So, what do you think is a better way to get them back? Get > > people on the ARIN PPML to call them bad names? Or provide > > them tangible economic benefits to transfer them to someone > > who does need them? If ISP A needs addresses and ISP B is > > willing to give up addresses that it doesn't need as long as > > it receives some compensation, why should anyone object? > > Because it is selling. So? I must confess I have little sympathy for this idea that "selling" is intrinsically evil. I spent a lot of time studying China's reform of its telecom sector in the 1990s, and in these RIR debates I sometimes feel as if I am dealing with die hard CCP members. If selling or trading addresses makes utilization more efficient or increases access to v4 addresses by opening up new resources that otherwise would be hoarded, then by all means, let's embrace "selling." Or, as Deng Xiaoping said, I don't care whether the cat is black or white as long as it catches mice. > The ARIN BoT could end up in jail if they don't do it right, and > doing it right costs a lot of money. It is easier to not do it > at all and continue with the current policy which discourages > selling entirely. A few wierdos hand over money anyway, but since > there are no guarantees that BOUGHT addresses will work, this has > never picked up any momentum. It has been happening since the mid > 1990's if not earlier, but it is a drop in the bucket, not a market. The problem with your argument here is that it fails to take into account the increasing scarcity, and the pressures that will inevitably place upon ARIN and other RIRs. I was going to answer your argument in full but discovered that ARIN's legal staff has already done so. Here is the analysis from ARIN's counsel: "No matter what policy ARIN implements, it seems likely that there will be more disputes, and hence more legal risk, once ARIN can no longer satisfy requests for v4 resources. But if ARIN attempted to continue its existing policy to prohibit most transfers, counsel anticipates that widespread transfers would nonetheless occur -- imposing significant future legal costs including the costs of investigation, arbitration, and litigation." > Nobody can know how many addresses are "free" in the ISPs since > "free" is hard to pin down. If I shut down a dialup pool and put those > addresses in limbo for 4 months while I try to cleanse the DUL lists, > are they really "free"? If I notify all small business customers that > when contract renewal time comes up, I will not renew contracts unless > they agree to go to NAT, hand back their address allocations, and live > behind a single statically assigned address per circuit, then > are those handed-back addresses "free". Thank you, these are interesting empirical issues regarding the degree to which addresses are fungible resources that could be released and transferred. I would like to hear more from ISPs about this. Or any other resrouces you know of that clarify the issue. > Yes, but in this industry the opposite had happened. We have created > a new kind of spectrum which is so vast that it will be hard for > anyone (except the RIRs) to hang onto enough spectrum that it will > block other users. That new spectrum is IPv6. Don't want to get too stuck in analogy-land, but there are more parallels here than you might think. There is all kinds of new spectrum that could be used by mobile services. The problem is that the contested UHF space was the "prime real estate" because it was contiguous to other mobile blocks and because of its lower-cost propagation properties. so in that respect it is like the IP address situation. It is cheaper and easier to expand existing allocations than to abandon completely the old space when massive legacy investments are built around it. From bicknell at ufp.org Fri Jun 13 13:23:10 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 13 Jun 2008 13:23:10 -0400 Subject: [arin-ppml] 464: was (Re: IPv6 adoption, map-encap for IPv4?) In-Reply-To: References: <4851E2EA.3060407@firstpr.com.au> Message-ID: <20080613172309.GA93877@ussenterprise.ufp.org> In a message written on Fri, Jun 13, 2008 at 09:15:04AM -0400, Alain Durand wrote: > IMHO, 464 is a technology that makes IPv6 backward compatible with IPv4. Can you provide any references? Googling for the subject turns up rather unhelpful results. -- 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: 187 bytes Desc: not available URL: From tvest at pch.net Fri Jun 13 14:25:34 2008 From: tvest at pch.net (Tom Vest) Date: Fri, 13 Jun 2008 14:25:34 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DC96C@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD9011DC960@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD9011DC96C@SUEXCL-02.ad.syr.edu> Message-ID: Hi Milton -- welcome to the conversation ;-) On Jun 13, 2008, at 12:40 PM, Milton L Mueller wrote: >> -----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: Friday, June 13, 2008 11:06 AM >> To: ppml at arin.net >> Subject: Re: [arin-ppml] simple question about money >> >>> But as you yourself implicitly recognize, once the addresses >>> have been assigned, they don't come back. >> >> Don't put words in my mouth. It is rude and you can't get >> away with it on this list. > > Hmmm. I think reasonable people can see for themselves which comment > was > more or less uncivil. From my point of view this is a fairly technical > policy discussion and I see nothing to get hot about. > >> The fact is that addresses do come back. ISPs regularly recover >> customer assigned addresses. ARIN also gets back address blocks >> for various reasons. Even IANA has received addresses back such >> as the 14/8 block. > > Sure, there are a few actors who will respond to moral suasion, such > as > the University that returned the /8 it obviously didn't need. But you > can't count on that. And of course ISPs recover addresses from their > customers, they have an economic incentive to do so. But tell me how > often ISPs surrender addresses back to RIRs? Facts would be helpful > here, no reason to rely on opinions. Are stastistics from ARIN and > other > RIRs available on this? I see no obvious place to look for address > block > returns on the ARIN site, but would love to be more informed. > >> Part of the process of "technical justification" does allow for >> intent to use the addresses. > > Sure, but "intent" is obviously rather subjective, and provides a huge > areas of latitude for holding on to things. > >>> So, what do you think is a better way to get them back? Get >>> people on the ARIN PPML to call them bad names? Or provide >>> them tangible economic benefits to transfer them to someone >>> who does need them? If ISP A needs addresses and ISP B is >>> willing to give up addresses that it doesn't need as long as >>> it receives some compensation, why should anyone object? >> >> Because it is selling. > > So? I must confess I have little sympathy for this idea that "selling" > is intrinsically evil. I spent a lot of time studying China's reform > of > its telecom sector in the 1990s, and in these RIR debates I sometimes > feel as if I am dealing with die hard CCP members. If selling or > trading > addresses makes utilization more efficient or increases access to v4 > addresses by opening up new resources that otherwise would be hoarded, > then by all means, let's embrace "selling." Or, as Deng Xiaoping > said, I > don't care whether the cat is black or white as long as it catches > mice. Thanks for using this particular analogy! I'd love to hear more about what you concluded from your Chinese research, esp. about the competitive environment that resulted. The Chinese privatization was short-lived, and when the authorities decided they didn't like the results they re-nationalized the "flagship" private/competitive carrier and turned it into the telco for the northern provinces. Today there may be superficial segments where competition exists, but certainly not at the "fundamental" (as in non-substitutable input) infrastructure level, which happens to be where IP address resources are relevant. At that level, China is even more valuable as an example, since it is not even possible to make use of IP address space from legitimate external sources within the territory -- perhaps as a matter of commercial practice rather than affirmative law, but what difference does it make in the absence of competitive alternatives? If things turn out to be other that the transfer enthusiasts wish, there will no return path for address resources -- or at least none involving "self-governance" as it currently exists. To be honest, I'm a little that surprised community members don't sound even more conservative than they do. >> The ARIN BoT could end up in jail if they don't do it right, and >> doing it right costs a lot of money. It is easier to not do it >> at all and continue with the current policy which discourages >> selling entirely. A few wierdos hand over money anyway, but since >> there are no guarantees that BOUGHT addresses will work, this has >> never picked up any momentum. It has been happening since the mid >> 1990's if not earlier, but it is a drop in the bucket, not a market. > > The problem with your argument here is that it fails to take into > account the increasing scarcity, and the pressures that will > inevitably > place upon ARIN and other RIRs. I was going to answer your argument in > full but discovered that ARIN's legal staff has already done so. > Here is > the analysis from ARIN's counsel: > > "No matter what policy ARIN implements, it seems likely that there > will > be more disputes, and hence more legal risk, once ARIN can no longer > satisfy requests for v4 resources. But if ARIN attempted to continue > its existing policy to prohibit most transfers, counsel anticipates > that > widespread transfers would nonetheless occur -- imposing significant > future legal costs including the costs of investigation, arbitration, > and litigation." > >> Nobody can know how many addresses are "free" in the ISPs since >> "free" is hard to pin down. If I shut down a dialup pool and put >> those >> addresses in limbo for 4 months while I try to cleanse the DUL lists, >> are they really "free"? If I notify all small business customers that >> when contract renewal time comes up, I will not renew contracts >> unless >> they agree to go to NAT, hand back their address allocations, and >> live >> behind a single statically assigned address per circuit, then >> are those handed-back addresses "free". > > Thank you, these are interesting empirical issues regarding the degree > to which addresses are fungible resources that could be released and > transferred. I would like to hear more from ISPs about this. Or any > other resrouces you know of that clarify the issue. > >> Yes, but in this industry the opposite had happened. We have created >> a new kind of spectrum which is so vast that it will be hard for >> anyone (except the RIRs) to hang onto enough spectrum that it will >> block other users. That new spectrum is IPv6. > > Don't want to get too stuck in analogy-land, but there are more > parallels here than you might think. There are indeed. "Diehard communists" are not the only kind of people that raise concerns about embarking on far-reaching privatization plans without adequate forethought. Do you remember the debates for and against "shock therapy" in Poland and Russia? Would you say that the critics -- all of them -- were too conservative in those cases too? I do look forward to hearing more about relevant parallels. Regards, Tom > There is all kinds of new spectrum > that could be used by mobile services. The problem is that the > contested > UHF space was the "prime real estate" because it was contiguous to > other > mobile blocks and because of its lower-cost propagation properties. so > in that respect it is like the IP address situation. It is cheaper and > easier to expand existing allocations than to abandon completely the > old > space when massive legacy investments are built around it. From schiller at uu.net Fri Jun 13 14:38:03 2008 From: schiller at uu.net (Jason Schiller) Date: Fri, 13 Jun 2008 14:38:03 -0400 (EDT) Subject: [arin-ppml] do you prefix list filter In-Reply-To: <20080608140425.GC17568@ussenterprise.ufp.org> Message-ID: On Sun, 8 Jun 2008, Leo Bicknell wrote: > First we need to think about the different cases: > > 1) How many networks prefix filter customers... > strictly based on their allocation? > allowing between their allocation and a /24? > allowing anything inside their allocation? > > 2) How many networks accept longer routes from customers than they will > pass along to their peers? > > 3) How many networks prefix filter peers... > strictly based on their allocation? > allowing between their allocation and a /24? > allowing anything inside their allocation? > allowing based on RIR published minimum allocation sizes? > 4) What is you ASN 1) Prefix filter on customers to allow anything inside their allocation 2) Accept more specific routes from customers, only pass along less specific than /24 3) Accept only less specific than /24 from Peers 4) 701 From mueller at syr.edu Fri Jun 13 14:54:03 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 13 Jun 2008 14:54:03 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD9011DC960@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD9011DC96C@SUEXCL-02.ad.syr.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9011DC971@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: Tom Vest [mailto:tvest at pch.net] > The Chinese privatization was short-lived, and when the authorities > decided they didn't like the results they re-nationalized > the "flagship" private/competitive carrier and turned it into the > telco for the northern provinces. There was never any "privatization" in China, nor any re-nationalization. China has always maintained state ownership of all telecom sector entities. There was some corporatization of telecom operations of government agencies (the railroads, ministry of electronics, PLA, etc.) and some managed competition among them. At a very local and small-scale level, there was "bootleg" privatization of radio resources by entrepreneurial military units to run paging services, but that was reined in. Still, the Peoples Liberation Army is still probably a big player in telecom. The main reason privatization doesn't take place, as you know, is so that the state can maintain top-down control of communications as much as is possible. > If things turn out to be other that the transfer enthusiasts wish, > there will no return path for address resources -- or at least none > involving "self-governance" as it currently exists. Huh? First, a transfer policy can simply be stopped. The policy is repealed, as of X date. Then there are no more (authorized) transfers; i.e. no more than there would be if there were no policy at all and the RIRs continue to bury their heads in the sand. Second, if indeed there is v6 take up and the whole scheme is transitional as intended, then the commies have their paradise in the v6 space and can continue to serve as God-like central planners judging others' needs there. > "Diehard communists" are not the only kind of people that raise > concerns about embarking on far-reaching privatization plans without > adequate forethought. The frame of "privatization" is the wrong one to draw around the IP address transfer proposals. Privatization means conferring a legal right of ownership to the address block assignee. A right to transfer the address from one user to another using ARIN as an intermediary does not imply legal ownership. > Do you remember the debates for and against "shock therapy" > in Poland and Russia? Do you seriously consider these moderate transfer policies as "shock therapy?" I guffaw, sir! The strategy is very Chinese. ;-) --MM From tedm at ipinc.net Fri Jun 13 14:56:53 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 13 Jun 2008 11:56:53 -0700 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DC961@SUEXCL-02.ad.syr.edu> Message-ID: <0EF8C4DEE66C44649352987057E885BF@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller > Sent: Friday, June 13, 2008 7:43 AM > To: ppml at arin.net > Subject: Re: [arin-ppml] Portable address space vs. IPv6 > auto-numbering > > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > > > As for the argument that a relatively small fraction of the IP > > addresses currently advertised are actually in use, well > whether "the > > market" coughs up those "3.7B which could be advertised" IPv4 > > addresses, or whether it doesen't, POST IPv4 runout, is at > this point > > really just speculation. > > The degree to which that happens is highly uncertain, but > it's a bit more than speculation. We know that gray market IP > address transfers have already been going on, and we have > experience with secondary markets in other resources, such as > bandwidth and spectrum. > > > We won't know until after > > IPv4 runout. > > Two points. First, I don't understand why you need to wait > for what you call "IPv4 runout" (see point 2) to permit > transfers. You could do it tomorrow. The ONLY legitimate need for IPv4 transfers at the current time is to subvert the IP utilization policies. Sicne the RIR's have free IPv4, there is no economic benefit to an org to pay a transfer fee to a 3rd party then start paying ARIN fees when they can merely go to ARIN and get the IPv4 for free - UNLESS for some reason ARIN would deny their application. Such as their failure to meet utilization requirements. Note that a transfer doesen't happen when org1 buys org2's network, that is an acquisition. > Second, and pardon me if > this sounds pedantic, but people who understand price systems > know that resources don't literally "run out" unless there is > something drastically wrong with the social systems used to > ration them. They become increasingly scarce and expensive. > We will never, for example, actually "run out" of oil. It may > eventually become so scarce that you only see it in tiny > vials displayed as jewelry around the necks of beautiful > models, but it won't "run out." > Tell that to the elephant tusk ivory resource. Tell that to the passenger pigeon meat resource, I understand they were pretty tasty. Sure we won't ever "run out" of IPv4. In the future, post IPv4-runout, there will still be orgs who go bankrupt and stop paying their bill, and the RIR can then assume their subnets. That is a marginal case. The term "IPv4-runout" is as good as any for a term to label the day in the future that the last virgin IPv4 block is handed out from ARIN. > More importantly, I am wondering how you view the impact of > v4 transfer markets on the v6 transition. This seems an > important issue. Let's suppose it is fantastically successful > at prolonging the life of v4 Internet by releasing many > unused address resources. Does it then discourage v6 > migration? It delays it. > Or does it over the longer term improve the value > proposition for v6 by making the fees/costs associated with > v6 addresses look more favorable? > It actually makes things a lot worse. Unless you can rework IPv4 to make IPv4 "effectively unlimited" the way IPv6 is, every year you delay IPv6 adoption you put more IPv4 into service and the cost to shift the Internet over goes up. Until Windows Vista the argument that we aren't ready for IPv6 had a lot of merit. Today, yes there's still a lot of XP. But every year less and less and more and more Vista. Eventually the only people who can't deploy IPv6 will be people like my employer who have older routers that don't have enough ram to update to current code. And IP numbering policy should not be paying attention to this sort of problem. Ted From tedm at ipinc.net Fri Jun 13 15:17:12 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 13 Jun 2008 12:17:12 -0700 Subject: [arin-ppml] simple question about money In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DC971@SUEXCL-02.ad.syr.edu> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller > Sent: Friday, June 13, 2008 11:54 AM > To: Tom Vest > Cc: ppml at arin.net > Subject: Re: [arin-ppml] simple question about money > > > > > > -----Original Message----- > > From: Tom Vest [mailto:tvest at pch.net] > > The Chinese privatization was short-lived, and when the > authorities > > decided they didn't like the results they re-nationalized > > the "flagship" private/competitive carrier and turned it into the > > telco for the northern provinces. > > There was never any "privatization" in China, nor any > re-nationalization. China has always maintained state > ownership of all telecom sector entities. There was some > corporatization of telecom operations of government agencies > (the railroads, ministry of electronics, PLA, etc.) and some > managed competition among them. At a very local and > small-scale level, there was "bootleg" privatization of radio > resources by entrepreneurial military units to run paging > services, but that was reined in. Still, the Peoples > Liberation Army is still probably a big player in telecom. > The main reason privatization doesn't take place, as you > know, is so that the state can maintain top-down control of > communications as much as is possible. > > > If things turn out to be other that the transfer enthusiasts wish, > > there will no return path for address resources -- or at > least none > > involving "self-governance" as it currently exists. > > Huh? First, a transfer policy can simply be stopped. The > policy is repealed, as of X date. Then there are no more > (authorized) transfers; i.e. no more than there would be if > there were no policy at all and the RIRs continue to bury > their heads in the sand. Second, if indeed there is v6 take > up and the whole scheme is transitional as intended, then the > commies have their paradise in the v6 space and can continue > to serve as God-like central planners judging others' needs there. > > > "Diehard communists" are not the only kind of people that raise > > concerns about embarking on far-reaching privatization > plans without > > adequate forethought. > > The frame of "privatization" is the wrong one to draw around > the IP address transfer proposals. Privatization means > conferring a legal right of ownership to the address block > assignee. A right to transfer the address from one user to > another using ARIN as an intermediary does not imply legal ownership. > If done right it may not - BUT what it does do is throw the entire issue of control over address assignment to the national legal system of the country that the parties are in. Party A and Party B are in the US. The US has no law on ownership of IP addresses. Party A and party B sign a legal contract to transfer registration of IP addresses between each other. ARIN comes along and says "party A has not met utilization requirements and thus the transfer isn't allowed" It would seem that party A and B both would immediately file a lawsuit against ARIN alleging interference in a contract. ARIN has no law backing it's control over the IP addresses so the whole thing goes to a US court to sort out. This type of thing has -already- happened. What was done is the issue was punted on jurisdictional issues since one party was not in the US, so ARIN argued US laws didn't apply and the court threw out the case, and both parties ended up being forced to deal with ARIN anyway. Also, since the case was an acquisition not a transfer, and ARIN already has rules that cover that, the court observed that one party had been subject to their contract with ARIN which dictated that they had to work with ARIN. If we allow transfers then we merely open the door for one of these cases to be tried in a US court which will then begin the process of creating case law and legal precedent that will ultimately end up ceeding control of address assignment to the US, within the US. Then it's only a matter of time before other countries get into the act and now we have a legal morass of different laws regarding IP addressing assignments in different countries. IP addressing is a global issue and the legal framework for anything like IPv4 transferring belongs in the World Court so it is the same for all countries, all RIRs. But if you look at the rest of the world, they have more interest in IPv6 than in IPv4. The US really is the one that has the most interest in IPv4 because it's been on the Internet longer. The US really needs to get with the program and not try imposing this dependence on IPv4 on the rest of the world. Ted From michael.dillon at bt.com Fri Jun 13 15:58:37 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 13 Jun 2008 20:58:37 +0100 Subject: [arin-ppml] simple question about money In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DC96C@SUEXCL-02.ad.syr.edu> Message-ID: > > Because it is selling. > > So? I must confess I have little sympathy for this idea that "selling" > is intrinsically evil. Who said it is evil? The fact is that selling IP addresses is not allowed by ARIN policy or by the contract that every ISP signs with ARIN. > I spent a lot of time studying China's > reform of its telecom sector in the 1990s, and in these RIR > debates I sometimes feel as if I am dealing with die hard CCP > members. If selling or trading addresses makes utilization > more efficient Not really possible due to the way IPv4 addressing works. This is a technical barrier that money cannot change. > or increases access to v4 addresses by opening > up new resources that otherwise would be hoarded, then by all > means, let's embrace "selling." We have opened up new resources with IPv6. Selling IPv4 only makes it harder for people to access these new IPv6 resources. > Or, as Deng Xiaoping said, I > don't care whether the cat is black or white as long as it > catches mice. Typical CEO statement. IP addressing is not a problem that will be solved with CEO culture. > The problem with your argument here is that it fails to take > into account the increasing scarcity, and the pressures that > will inevitably place upon ARIN and other RIRs. No, it is your argument that fails to take these pressures into account. IPv6 exists today as a technology. Increasing scarcity of IPv4 increases the pressure on companies to deploy IPv6. When hardnosed business people look at the possibility of buying IPv4 addresses to meet continuing needs they quickly see that it is a losing proposition because the increasing scarcity means that sellers will be few and prices will be astronomical. Meanwhile, IPv6 technology exists today and 80 percent of the v4-v6 interworking problems have already been solved. > I was going > to answer your argument in full but discovered that ARIN's > legal staff has already done so. Here is the analysis from > ARIN's counsel: > > "No matter what policy ARIN implements, it seems likely that > there will be more disputes, and hence more legal risk, once > ARIN can no longer satisfy requests for v4 resources. But if > ARIN attempted to continue its existing policy to prohibit > most transfers, counsel anticipates that widespread transfers > would nonetheless occur -- imposing significant future legal > costs including the costs of investigation, arbitration, and > litigation." The key bit of this statement is "counsel anticipates". Basically I don't believe that ARIN counsel is competent to forecast what will happen since this is primarily a technical issue. Any company that considers launching legal action over IPv4 addresses has to weigh the negative impacts on the business of publicly admitting that their business is not ready to cope with the new world of IPv6, and that their growth prospects are therefore limited. I recommend forward thinking ISPs to keep their eye on the court filings in Fairfax County, VA so that they know which company's customers to target with their IPv6 sales force. > Thank you, these are interesting empirical issues regarding > the degree to which addresses are fungible resources that > could be released and transferred. I would like to hear more > from ISPs about this. Or any other resrouces you know of that > clarify the issue. May I suggest that you specifically look into the issues of routability and the route filtering that most ISPs perform to protect the stability and longevity of their core routers. > so in that > respect it is like the IP address situation. It is cheaper > and easier to expand existing allocations than to abandon > completely the old space when massive legacy investments are > built around it. Interworking between IPv4 and IPv6 is possible. There are many flavors of interworking, but it has been tested and it works except for some corner cases. There are two years or so left to work out the remaining technical issues so I think this is being underrated as a solution. After all we are not talking about replacing IPv4 with IPv6. The reality is that we will have a blended network for a generation, but IPv6 is where all the growth and network expansion will occur. And that is because it is easier and cheaper to build IPv6 networks than it is to deploy double and triple NAT to make IPv4 feasible for growth. --Michael Dillon From tedm at ipinc.net Fri Jun 13 16:04:20 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 13 Jun 2008 13:04:20 -0700 Subject: [arin-ppml] simple question about money In-Reply-To: Message-ID: > -----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: Friday, June 13, 2008 12:59 PM > To: ppml at arin.net > Subject: Re: [arin-ppml] simple question about money > > > The key bit of this statement is "counsel anticipates". > Basically I don't believe that ARIN counsel is competent to > forecast what will happen since this is primarily a technical > issue. "Go not to the lawyers for counsel, for they will say both yes and no" Ted From schiller at uu.net Fri Jun 13 16:04:49 2008 From: schiller at uu.net (Jason Schiller) Date: Fri, 13 Jun 2008 16:04:49 -0400 (EDT) Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: <98747.1213280210@sa.vix.com> Message-ID: If Tony and Robin are taking a poll on the best way to make routing scale, I'll agree with Paul and Lee. If I have to choose between implementing locator and ID separation in either IPv4 or IPv6, I think IPv6 makes the most sense. However I don't see any solutions for IPv4 that cannot also be implemented in IPv6. If there is a way to make IPv4 and IPv6 more scalable through redirection such as locator/ID separation then we should be working on providing that functionality for both protocols. However, if the extra bits in IPv6, or the extra next-headers somehow give us more flexibility and allow us to as Tony Li puts it "do something better", that is less "architecturally unclean", then we should focus on an architectural solution for IPv6, especially when we consider IPv4 depletion. This is not to say as Robin suggests that by focusing on IPv6 we somehow get the luxury of more time. No matter whether we focus on solving the routing issue in IPv4, IPv6, or both protocols, we have maybe two years until IPv4 depletion. Once that occurs demand for new address will only be fulfilled through IPv6. It would be nice if we had a solution for mult-homing, TE, and mobility at that time so we do not recreate the problems that IPv4 is currently suffering from in IPv6, namely massive de-aggregation to solve the problems of multi-home, TE, mobility, and provider independence. The short time line may drive us to something which requires little or no stack modifications and instead is more "architecturally unclean". __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Wed, 11 Jun 2008, Paul Vixie wrote: > while i am not a member of RRG, if the question is drawn as clearly as > that, my position would be, forget about IPv4. the internet will have > many more than 2^32 devices connected to it simultaneously within our > lifetimes, and i think we should preserve the option of not using NAT in > future generations. therefore IPv4's growth has a glass ceiling formed > by its address size, and > any effort that's put into growing its routing table has a fixed return. On Wed, 11 Jun 2008, Howard, W. Lee wrote: > If Tony and Robin are taking a poll on the best way to make > routing scale, I'll agree with Paul that I don't think IPv4 > can be made to scale, and so we shouldn't waste time trying. > I can't argue on which of various solutions might work for > IPv6; it's not part of my day job or volunteer work. On Thu, 12 Jun 2008, Robin Whittle wrote: > If the RRG decides it doesn't need to fix the IPv4 routing > scaling problem, then it can concentrate its energies - and > the IETF's, if the IETF accepts the RRG's recommendation - on > the much less urgent IPv6 scaling problem. > > IPv6 has many more technical possibilities for solving the > problem, primarily due to its longer address length and much > lower installed base. > > If the RRG/IETF doesn't care about the IPv4 routing scaling > problem, then it probably has many years to solve the IPv6 > problem, because I can't see how mass migration to IPv6 is > going to happen in the next decade. > > However, this seems like a high-pressure, high-risk venture. > > While one planet burns, the expeditionary force is supposed > to be preparing another, significantly incompatible, but > ultimately better planet. I would rather a more relaxed > mission timetable: > > I would rather fix the IPv4 problem ASAP and have more time > to prepare a lasting alternative, especially something with > greater ease of migration from IPv4, which means a much better > means of communicating with the IPv4 Internet than is currently > possible with IPv6. On Thu, 12 Jun 2008, Paul Vixie wrote: > i think we're going to see IPv6 routing table bloat earlier than RRG's > work could possibly complete, and that that's the real race here, and > that any time spent prolonging IPv4's doddering old age with double- and > triple-NAT is a dangerous distraction. the internet is not just the > web, and we can't go on building new kinds of applications if everything > has to be some kind of NAT or map-encap or ALG or proxy. IPv4 is headed > for end-of-life. let's move on. On Tue, 10 Jun 2008, Tony Li wrote: > It's actually very unlikely that we will resort to a > tunneling/encapsulation mechanism. They are too cumbersome, > architecturally unclean, and fraught with MTU issues. My hope is that > we do something better. From jmorrison at bogomips.com Fri Jun 13 16:29:13 2008 From: jmorrison at bogomips.com (John Paul Morrison) Date: Fri, 13 Jun 2008 13:29:13 -0700 Subject: [arin-ppml] 464: was (Re: IPv6 adoption, map-encap for IPv4?) In-Reply-To: References: Message-ID: <4852D899.7090006@bogomips.com> Wow - I recall speculating that broadband providers would eventually move to NAT IPv4, but I didn't think they were already doing it (or that it was imminent). I saw that as a negative - that the providers would recoup routable IPv4 space and charge a premium for it as IPv4 becomes more scarce. And I suppose there's nothing stopping that. I was also more pessimistic in assuming they would simply put up carrier grade NATs to extend IPv4 address resources, without really providing a path for IPv6. Probably nothing stopping other providers from doing that either, if they're betting IPv6 deployment isn't worth the effort. Does Comcast provides native, routable IPv6 addresses to those who want them? If so, that would seem to provide some incentive to take advantage of IPv6 as it becomes more widespread. I wasn't clued into this when Paul talked about the gamers and peer-to-peerers getting better performance out of IPv6. This strategy does seem to be the most plausible I've yet seen for IPv6 rollout. It would seem that if IPv4 addresses become valuable in the IPv4 end-game, Comcast wins or at least breaks even by freeing up and redeploying IPv4 addresses. If IPv6 wins out, Comcast is obviously in a good position. A broadband carrier who bets against IPv6 could win if IPv4 addresses go up in value and IPv6 doesn't take off; but they face the looming risk that if it does, they'll be at a disadvantage. On 6/13/2008 9:30 AM, Alain Durand wrote: > The idea is that the home gateway will be provisioned on the WAN with only > IPv6 and will run DHCPv4 with 192.168.0.0 on the LAN side. > Now, instead of translating outgoing IPv4 packets, it will forward them > unchanged inside of an IPv6 tunnel which endpoint is somewhere within the > service provider network. That endpoint will decapsulate the packet and > translate the original IPv4 packet to use a global IPv4 source address. Of > course, that carrier grade NAT will have to use the IPv6 tunnel src address > as part of its mapping table instead of the IPv4 address of the original > packet. > > That way, there is effectively only one level of NAT. Manual port forwarding > cannot be supported, of course. We are now studying what is the impact on > p2p protocols and uPNP. > > Note: It is actually possible to run a 464 client on a stand alone device > (ie not behind a home gateway) that is connected only with IPv6. That device > pick up any random or well know IPv4 src address (even 127.0.0.1 could > work), figure out the IPv4 destination (resolve A records over IPv6 DNS), > and ship the packet over the 464 tunnel. That way, you can run v4 apps, > browse the v4 Internet, all that on a v6-only configured device... > > - Alain. > > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > From tvest at pch.net Fri Jun 13 16:48:55 2008 From: tvest at pch.net (Tom Vest) Date: Fri, 13 Jun 2008 16:48:55 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DC971@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD9011DC960@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD9011DC96C@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD9011DC971@SUEXCL-02.ad.syr.edu> Message-ID: <0E506302-719C-4C2C-9FBD-2286DB463E78@pch.net> On Jun 13, 2008, at 2:54 PM, Milton L Mueller wrote: >> -----Original Message----- >> From: Tom Vest [mailto:tvest at pch.net] >> The Chinese privatization was short-lived, and when the authorities >> decided they didn't like the results they re-nationalized >> the "flagship" private/competitive carrier and turned it into the >> telco for the northern provinces. > > There was never any "privatization" in China, nor any > re-nationalization. I suppose these were only "transfers" too, that were later reversed and suspended? Then the argument is the same, for reasons described below. >> If things turn out to be other that the transfer enthusiasts wish, >> there will no return path for address resources -- or at least none >> involving "self-governance" as it currently exists. > > Huh? First, a transfer policy can simply be stopped. The policy is > repealed, as of X date. Then there are no more (authorized) transfers; > i.e. no more than there would be if there were no policy at all and > the > RIRs continue to bury their heads in the sand. Second, if indeed there > is v6 take up and the whole scheme is transitional as intended, then > the > commies have their paradise in the v6 space and can continue to > serve as > God-like central planners judging others' needs there. The reason I believe that that you're wrong about this is because you are also mistaken about your next point... >> "Diehard communists" are not the only kind of people that raise >> concerns about embarking on far-reaching privatization plans without >> adequate forethought. > > The frame of "privatization" is the wrong one to draw around the IP > address transfer proposals. Privatization means conferring a legal > right > of ownership to the address block assignee. A right to transfer the > address from one user to another using ARIN as an intermediary does > not > imply legal ownership. There is a large and diverse set of (mostly new) laws and precedents used in many countries that goes under the rubric of "economic substance doctrine". Very roughly it's the legal equivalent of an "if it walks like a duck and talks like a duck..." argument that lawyers, accountants, and/or regulators sometimes apply when confronted with a description of some value-bearing asset or transaction that has been undervalued, or characterized as valueless by the interested parties (e.g., in cases of cross-border transfer pricing, obfuscation to avoid taxes, regulation, bankruptcy proceedings, etc.). The punchline is, as you might expect, that a duck is sometimes a duck no matter what one may wish to call it. Repeating something I wrote first to this list back in April, a "transfer" of resources that were previously defined and/or treated as common pool resources, which makes those resources alienable, and grants the initial recipients the right to choose the identity, timing, and terms of transfer to subsequent recipients is privatization, plain and simple. We may all wish to passionately assert otherwise. Perhaps that passion will have weight in legal proceedings. I'll guess we'll have to wait and see. I readily admit that I'm not a lawyer; perhaps there are lawyers with expertise in this new/emerging field on the list? >> Do you remember the debates for and against "shock therapy" >> in Poland and Russia? > > Do you seriously consider these moderate transfer policies as "shock > therapy?" I guffaw, sir! The strategy is very Chinese. ;-) Oh I don't know, what's the actual definition of "shock therapy" -- or if you prefer, "big bang" style economic reforms? Simultaneous total transformation of several core economic systems, on the theory that the alternative ("sequencing") is less likely to succeed. What kind of core functions? 1. Distribution architecture - e.g., from centralized to decentralized. 2. Eligibility criteria - e.g., from categorical ("all citizens" or "need-based") to competitive (i.e., markets). 3. Medium of exchange -- e.g., from one currency to another, or in this case from "credible promises of new Internet production" to whatever considerations are acceptable to incumbent IPv4 holders. What are/were the theoretical justifications for shock therapy? 1. The current system has reached end-of-life, and nothing less than total transformation will make it better. 2. The incentives are misaligned, let's introduce the profit motive to get things moving in another direction. 3. The medium of exchange has failed -- usually that means hyperinflation, not severe deflation as in this case -- so let's dump it. 4. The locals are too insular, too protected -- let's introduce some foreign capital/competition/expertise -- (this space left as an exercise for the reader). What are/were some of the more common effects of shock therapy? 1. Deflation -- but the therapeutic kind rather than the Great Depression kind, because the previous excess was hyperinflation. 2. Initial, severe disruption -- lots of industry restructuring, with lots of pain for those working in the affected industries. 3. "Insider privatization" -- a necessary and accepted evil in sectors where expertise was scarce, but which can lead to excesses (with names like "crony capitalism", "kleptocracy", etc.), esp. in situations where public transparency or property rights/rule of law is weak. 4. Speculation / Consolidation -- i.e., the opposite of competition, but good for getting prices up, which spurs investment! And sometimes, much later: 5. Recovery, normalization, usually with PTSD -- those who lived through it wondering if there might have been an easier way... Guffaw if you wish; this is no joke. I (literally) hope to be proven wrong, if anyone wishes to do me the kindness of trying... TV From michael.dillon at bt.com Fri Jun 13 17:00:57 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 13 Jun 2008 22:00:57 +0100 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: <0EF8C4DEE66C44649352987057E885BF@tedsdesk> Message-ID: > It actually makes things a lot worse. Unless you can rework > IPv4 to make IPv4 "effectively unlimited" the way IPv6 is, > every year you delay IPv6 adoption you put more IPv4 into > service and the cost to shift the Internet over goes up. The cost to shift to IPv6 does not go up and may in fact go down slightly. However, the total capital investment required to both eke out the last value from IPv4 and then deploy IPv6 will be higher for all but some small specialist businesses. This is where the real economic issue is. It's rather like that story about the frog in a pot of cold water that slowly comes to a boil. Because it is not clear what the costs are to eke out the last value from IPv4, some companies will blindly go down that road and then end up in bankruptcy (or fire sale) when they have to deploy IPv6 but have already spent their capital on IPv4 kludges that cannot deliver a return on their investment. --Michael Dillon From mueller at syr.edu Fri Jun 13 17:18:09 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 13 Jun 2008 17:18:09 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: References: Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9011DC97A@SUEXCL-02.ad.syr.edu> > -----Original Message----- > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > > > > The key bit of this statement is "counsel anticipates". > > Basically I don't believe that ARIN counsel is competent to > > forecast what will happen since this is primarily a technical > > issue. > > "Go not to the lawyers for counsel, for they will say both yes and no" > The Counsel's statement is very clear, it does not hedge, and it addresses an issue of legal risk not a "technical issue." I would listen to and trust your lawyer on an assessment of the legal risks. From mueller at syr.edu Fri Jun 13 17:41:49 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 13 Jun 2008 17:41:49 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <0E506302-719C-4C2C-9FBD-2286DB463E78@pch.net> References: <7663C7E01D8E094989CA62F0B0D21CD9011DC960@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD9011DC96C@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD9011DC971@SUEXCL-02.ad.syr.edu> <0E506302-719C-4C2C-9FBD-2286DB463E78@pch.net> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9011DC97B@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: Tom Vest [mailto:tvest at pch.net] > a "transfer" of resources that were previously defined and/or > treated as common pool resources, which makes those resources > alienable, and grants the initial recipients the right to choose > the identity, timing, and terms of transfer to subsequent recipients is > privatization, plain and simple. The resources are already alienable, for any economic definition of alienable. The right to choose the identity, timing and terms of transfer is new, but it's a feature not a bug (an issue you keep ignoring). That's the whole point. Those transfers will not take place otherwise. So let's talk about whether the transfers are useful and needed. > We may all wish to passionately assert otherwise. Perhaps > that passion > will have weight in legal proceedings. I'll guess we'll have to wait > and see. I readily admit that I'm not a lawyer; perhaps there are > lawyers with expertise in this new/emerging field on the list? the issue is not all that new. E.g., the atmosphere is the ultimate common pool resource; and yet you can trade carbon emission rights with respect to it. Yet, the air is not "privatized." You have spectrum auctions, but the government maintains all kinds of rights over spectrum use, terms and conditions. (Read the fine print) And no one wants to go back to comparative hearings, the equivalent of RIR's "need-based allocations." ICANN's beauty contests for TLDs are a disaster as well. > > Do you seriously consider these moderate transfer policies as "shock > > therapy?" I guffaw, sir! I've read your arguments about shock therapy, and think they are not so relevant. Like your use of the "P" word (privatization) I see only mental blocks and possibly scare tactics here. And perhaps I share the blame for that, having initiated the Deng Xiao Ping thing. Fact is, the Internet and the RIRs are already deeply, deeply embedded in a market economy. Consumers buy Internet service in a market; they buy PCs and networking equipment in a market, they buy content in a market, businesses buy and sell advertising in a market; they get the real estate out of which they operate in a market, and they buy labor in a market. So we are talking about the insertion of a piddling amount of economic incentives into a tiny part of the internet market. For you to compare that to the wholesale transformation of an entire (Russian/Chinese/Polish) that had spent 7 decades completely outside of a market price system (and centuries in feudalism prior to that) is just sheer panic-mongering. Unlike formerly communist countries, RIR reforms take place in a rule of law, fairly clear lines of authority within ARIN, an independent judiciary outside of it. No commissars in the U.S. DoD will be making off with half the address space....er, ooops, I guess they have already done that, haven't they? But they did that years ago without any need for address transfers, didn't they? Indeed, a transfer scheme might give us some change of recovering that.... From mueller at syr.edu Fri Jun 13 17:47:10 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 13 Jun 2008 17:47:10 -0400 Subject: [arin-ppml] 464: was (Re: IPv6 adoption, map-encap for IPv4?) In-Reply-To: <4852D899.7090006@bogomips.com> References: <4852D899.7090006@bogomips.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9011DC97C@SUEXCL-02.ad.syr.edu> > -----Original Message----- > [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Paul Morrison > This strategy does seem to be the most plausible I've yet > seen for IPv6 rollout. It would seem that if IPv4 addresses > become valuable in the IPv4 end-game, Comcast wins or at least > breaks even by freeing up and redeploying IPv4 addresses. If > IPv6 wins out, Comcast is obviously in a good position. A > broadband carrier who bets against IPv6 could win if > IPv4 addresses go up in value and IPv6 doesn't take off; but > they face the looming risk that if it does, they'll be at a disadvantage. Yes, this is why it's important for v4 addresses to go up in price. And allowing transfers to set the price is a far more flexible, realistic and responsive way to do that than blind, top-down impositions of fees by ARIN remaining within the centralized allocation model. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org From tedm at ipinc.net Fri Jun 13 18:29:55 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 13 Jun 2008 15:29:55 -0700 Subject: [arin-ppml] simple question about money In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DC97A@SUEXCL-02.ad.syr.edu> Message-ID: > -----Original Message----- > From: Milton L Mueller [mailto:mueller at syr.edu] > Sent: Friday, June 13, 2008 2:18 PM > To: Ted Mittelstaedt; michael.dillon at bt.com; ppml at arin.net > Subject: RE: [arin-ppml] simple question about money > > > > > -----Original Message----- [mailto:arin-ppml-bounces at arin.net] On > > Behalf Of Ted Mittelstaedt > > > > > > The key bit of this statement is "counsel anticipates". > > > Basically I don't believe that ARIN counsel is competent to > > > forecast what will happen since this is primarily a technical > > > issue. > > > > "Go not to the lawyers for counsel, for they will say both > yes and no" > > > > The Counsel's statement is very clear, it does not hedge, and > it addresses an issue of legal risk not a "technical issue." > I would listen to and trust your lawyer on an assessment of > the legal risks. > > Oh brother. When 2 lawyers meet and battle in a court, one always is WRONG and LOSES. Lawyers are no better than anyone else when it comes to predicting what will happen in a dispute where there is no precedent. Their primary value is interpreting the law as it's written, their secondary value is in trying to convince others that YOUR interpretation is the correct one. Let's examine the statement, shall we: > "No matter what policy ARIN implements, meaning does, or doesn't... > it seems likely that > there will be more disputes, and hence more legal risk, once > ARIN can no longer satisfy requests for v4 resources. So, if ARIN DOESN'T continue it's existing policy to prohibit most transfers, it seems likely that there will be more disputes, and hence more legal risk.... So, let's look at what the lawyer says if ARIN DOES continue it's existing policy to prohibit most transfers: > But if > ARIN attempted to continue its existing policy to prohibit > most transfers, counsel anticipates that widespread transfers > would nonetheless occur -- imposing significant future legal > costs including the costs of investigation, arbitration, and > litigation." Do I hear an echo? In other words, ARIN is going to be screwed either way. The lawyer is merely saying here do you want it doggie style or missionary position? Ted From tedm at ipinc.net Fri Jun 13 18:36:41 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 13 Jun 2008 15:36:41 -0700 Subject: [arin-ppml] Portable address space vs. IPv6 auto-numbering In-Reply-To: Message-ID: <0AE9124166CD47B086A358BC089AE9ED@tedsdesk> > -----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: Friday, June 13, 2008 2:01 PM > To: ppml at arin.net > Subject: Re: [arin-ppml] Portable address space vs. IPv6 > auto-numbering > > > This is where the real economic issue is. It's rather like that story > about the frog in a pot of cold water that slowly comes to > a boil. heh... http://www.uga.edu/srel/ecoviews/ecoview021118.htm Ted From tvest at pch.net Fri Jun 13 19:23:53 2008 From: tvest at pch.net (Tom Vest) Date: Fri, 13 Jun 2008 19:23:53 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DC97B@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD9011DC960@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD9011DC96C@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD9011DC971@SUEXCL-02.ad.syr.edu> <0E506302-719C-4C2C-9FBD-2286DB463E78@pch.net> <7663C7E01D8E094989CA62F0B0D21CD9011DC97B@SUEXCL-02.ad.syr.edu> Message-ID: On Jun 13, 2008, at 5:41 PM, Milton L Mueller wrote: >> -----Original Message----- >> From: Tom Vest [mailto:tvest at pch.net] > >> a "transfer" of resources that were previously defined and/or >> treated as common pool resources, which makes those resources >> alienable, and grants the initial recipients the right to choose >> the identity, timing, and terms of transfer to subsequent recipients >> is privatization, plain and simple. > > The resources are already alienable, for any economic definition of > alienable. I'd be very interested to read something resembling argument rather than assertion here; references to real observations or data too. > The right to choose the identity, timing and terms of transfer is new, ... and it basically completes the functional definition of "privatization." > but it's a feature not a bug (an issue you keep ignoring). I'll be happy to discuss the hypothetical benefits if you'll confirm that you are, in fact, advocating the full privatization of IPv4. > That's the whole point. Those transfers will not take place > otherwise. So let's > talk about whether the transfers are useful and needed. That's also not necessarily true. I believe that there are other potentially viable mechanisms for facilitating the "recirculation" of IPv4 as necessary, as part of a transition to IPv6 -- mechanisms that will not have the same risks (i.e., non-reversibility) or perverse incentives as a transfer market is likely to have. >> We may all wish to passionately assert otherwise. Perhaps >> that passion >> will have weight in legal proceedings. I'll guess we'll have to wait >> and see. I readily admit that I'm not a lawyer; perhaps there are >> lawyers with expertise in this new/emerging field on the list? > > the issue is not all that new. E.g., the atmosphere is the > ultimate common pool resource; and yet you can trade carbon emission > rights with respect to it. Milton, what makes a market useful? What makes a market "liquid"? Can you point to a market for any other industrial input anywhere/ anytime that has the following characteristics: 1. Both scarce and absolutely finite, with no more production/ extraction possible. 2. Completely owned by incumbents in that industry (if not today then in 1-2 years per common assumption), who actually use the resource, and might have to purchase more themselves in the open market if they outgrow their own reserves. 3. Completely non-substitutable within the relevant industry, forever, unless/until the incumbents choose to make it substitutable. 4. Value is potentially very substantial, but 100% contingent on strategic preferences of the incumbents; when they choose to make it substitutable, value will diminish rapidly to zero. And: 5. Supply is liquid, prices are relatively stable -- not constantly appreciating -- and "reasonable". "Reasonable" is a pretty fuzzy term I'll grant you, so use this for context: 6. Relevant industry is critical to national, as well as other interests. 7. Public pricing information does not exist -- details of all transactions remain confidential. 8. Potential buyers have access to legal, regulatory recourse. Note that the above is is not intended to impugn commercial operators in any way, other than to assume that they are subject to (at least) the same competitive pressures that exist in every other market. This is a coordination problem, but if it's thrown over the fence commercial operators will be punished -- by speculators, or investors, or their competitors --- if they fail to respond as "rationality" dictates. > Yet, the air is not "privatized." You have > spectrum auctions, but the government maintains all kinds of rights > over > spectrum use, terms and conditions. Yes, governments retain all sorts of rights don't they? Ahh, the privileges of sovereignty. If you also wish to declare that you advocate ceding the RIR function to national authorities, I'll grant that this is a relevant comparison. > (Read the fine print) And no one > wants to go back to comparative hearings, the equivalent of RIR's > "need-based allocations." ICANN's beauty contests for TLDs are a > disaster as well. > >>> Do you seriously consider these moderate transfer policies as "shock >>> therapy?" I guffaw, sir! > > I've read your arguments about shock therapy, and think they are not > so > relevant. Like your use of the "P" word (privatization) I see only > mental blocks and possibly scare tactics here. And perhaps I share the > blame for that, having initiated the Deng Xiao Ping thing. I have tried to lay out my reasoning. You may not find it persuasive, others may not either. I've asked for corrections of fact or logic, and still look forward to them. But I would likely be a lot more receptive to conversion if responses took the form of an empirically-grounded counterargument, rather than just "scary", "not new", "not relevant", etc. Oh, and if the argument really is old, I'd love some citations too. > Fact is, the Internet and the RIRs are already deeply, deeply embedded > in a market economy. Consumers buy Internet service in a market; they > buy PCs and networking equipment in a market, they buy content in a > market, businesses buy and sell advertising in a market; they get the > real estate out of which they operate in a market, and they buy > labor in > a market. > > So we are talking about the insertion of a piddling amount of economic > incentives into a tiny part of the internet market. I like economic incentives too. I think it's going to be hard if not impossible to get through the transition that looms, whichever one we think that happens to be, without them. But I think that anyone who wishes to engage in market design had better understand the full context / incentive structure first. > For you to compare that to the wholesale transformation of an entire > (Russian/Chinese/Polish) that had spent 7 decades completely outside > of > a market price system (and centuries in feudalism prior to that) is > just > sheer panic-mongering. If it's not new and not relevant then I doubt it can inspire much panic. Once fully understood, it should inspire confidence (or at least some reassurance) rather than panic. In the mean time, if you're suggesting that the Internet is somehow trivial as an economic phenomenon relative to the individual countries that have been mentioned, then we'll just have to agree to disagree. If you're suggesting that IPv4 is, at present, something less that the Internet's only global medium of exchange -- and I do mean that quite literally -- then I will also categorically disagree.* And finally, If you think that the introduction of the first-ever market price system for the Internet's foundational medium of exchange will be any less traumatic than it has been in other spheres, I can only hope that you're right -- or better yet that we don't have to risk finding out the hard way. > Unlike formerly communist countries, RIR reforms take place in a > rule of > law, fairly clear lines of authority within ARIN, an independent > judiciary outside of it. No commissars in the U.S. DoD will be making > off with half the address space....er, ooops, I guess they have > already > done that, haven't they? But they did that years ago without any need > for address transfers, didn't they? Indeed, a transfer scheme might > give > us some change of recovering that.... Of course everything you say is true, but also irrelevant and immaterial. There are many things that I would like to see survive (at least) this transition -- most importantly the capacity of the Internet to support new entrants, new applications and services, on terms that are (at least) no worse than those enjoyed by past and current stakeholders. I think that the system of self-governance (the alternative to which is sometimes called "arbitrary partition" by an illustrious industry colleague) is useful to that end, and I even think that the RIRs have been a useful element of that system of self- governance. I want to see these things survive not merely in form, but also in substance -- i.e., survive because they're still delivering on (at least) their intended purpose, and our current aspirations for the Internet, if not more. Survive because if they didn't we'd want to reinvent them, but might not be able to. And as the violins swell, I bid you all a good weekend ;-) TV *Paper with more details forthcoming. From alain_durand at cable.comcast.com Fri Jun 13 19:37:51 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Fri, 13 Jun 2008 19:37:51 -0400 Subject: [arin-ppml] 464: was (Re: IPv6 adoption, map-encap for IPv4?) In-Reply-To: <4852D899.7090006@bogomips.com> Message-ID: On 6/13/08 4:29 PM, "John Paul Morrison" wrote: > Wow - I recall speculating that broadband providers would eventually > move to NAT IPv4, but I didn't think they were already doing it (or that > it was imminent). I think I need to clarify. We are *NOT* deploying 464 today to our customers. Our service remains and will remain as long as possible classic IPv4. 464 is a very promising technology that we are looking at seriously. - Alain. From dudepron at gmail.com Fri Jun 13 21:04:05 2008 From: dudepron at gmail.com (Aaron) Date: Fri, 13 Jun 2008 21:04:05 -0400 Subject: [arin-ppml] do you prefix list filter In-Reply-To: References: <20080608140425.GC17568@ussenterprise.ufp.org> Message-ID: <480dad640806131804q6839eb1emadf17e2ff6fa0f6c@mail.gmail.com> If I remember correctly, ARIN does NOT take in account ISP filtering for any polices and does not guarantee routability of any allocations. On Fri, Jun 13, 2008 at 2:38 PM, Jason Schiller wrote: > On Sun, 8 Jun 2008, Leo Bicknell wrote: > > > First we need to think about the different cases: > > > > 1) How many networks prefix filter customers... > > strictly based on their allocation? > > allowing between their allocation and a /24? > > allowing anything inside their allocation? > > > > 2) How many networks accept longer routes from customers than they will > > pass along to their peers? > > > > 3) How many networks prefix filter peers... > > strictly based on their allocation? > > allowing between their allocation and a /24? > > allowing anything inside their allocation? > > allowing based on RIR published minimum allocation sizes? > > > 4) What is you ASN > > 1) Prefix filter on customers to allow anything inside their allocation > > 2) Accept more specific routes from customers, only pass along less > specific than /24 > > 3) Accept only less specific than /24 from Peers > > 4) 701 > > > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleibrand at internap.com Sat Jun 14 00:48:46 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 13 Jun 2008 21:48:46 -0700 Subject: [arin-ppml] do you prefix list filter In-Reply-To: <480dad640806131804q6839eb1emadf17e2ff6fa0f6c@mail.gmail.com> References: <20080608140425.GC17568@ussenterprise.ufp.org> <480dad640806131804q6839eb1emadf17e2ff6fa0f6c@mail.gmail.com> Message-ID: <48534DAE.6010404@internap.com> Aaron wrote: > If I remember correctly, ARIN does NOT take in account ISP filtering for > any polices and does not guarantee routability of any allocations. ARIN (as in ARIN staff) may not, but those of us that participate in the public policy process generally do take into account ISP filters when setting policy. -Scott (speaking for myself) > On Fri, Jun 13, 2008 at 2:38 PM, Jason Schiller > wrote: > > On Sun, 8 Jun 2008, Leo Bicknell wrote: > > > First we need to think about the different cases: > > > > 1) How many networks prefix filter customers... > > strictly based on their allocation? > > allowing between their allocation and a /24? > > allowing anything inside their allocation? > > > > 2) How many networks accept longer routes from customers than > they will > > pass along to their peers? > > > > 3) How many networks prefix filter peers... > > strictly based on their allocation? > > allowing between their allocation and a /24? > > allowing anything inside their allocation? > > allowing based on RIR published minimum allocation sizes? > > > 4) What is you ASN > > 1) Prefix filter on customers to allow anything inside their allocation > > 2) Accept more specific routes from customers, only pass along less > specific than /24 > > 3) Accept only less specific than /24 from Peers > > 4) 701 > > > _______________________________________________ > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From rw at firstpr.com.au Sat Jun 14 04:12:19 2008 From: rw at firstpr.com.au (Robin Whittle) Date: Sat, 14 Jun 2008 18:12:19 +1000 Subject: [arin-ppml] IPv6 adoption, map-encap for IPv4? In-Reply-To: <997BC128AE961E4A8B880CD7442D948005664301@NJCHLEXCMB01.cable.comcast.com> References: <4851E2EA.3060407@firstpr.com.au> <997BC128AE961E4A8B880CD7442D948005664301@NJCHLEXCMB01.cable.comcast.com> Message-ID: <48537D63.6000005@firstpr.com.au> Hi Dan, Thanks very much for your message, in which you wrote: > I hope you make it to the ARIN meeting in LA this fall, and have > a chance to talk directly to many of the people on this list. > These are discussions that should continue. That would be great, but I don't work for a big company and am based in Melbourne, Australia. > As I've been reading this thread, however I can't get past two > concepts. These are that you are of the opinion the IPv4 Internet > is underutilized because experiments can only ping ~100 million > IP. The other is that IPv6 deployment is a failure because its not > already deployed. IPv6 may well be widely adopted at some time. I just think the transition arrangements are a shambles and that it is a very long way from being widely adopted. I think the chicken and egg problem is far to big and that there is great scope for keeping most customers on IPv4, albeit in an increasingly ugly way if it involves less capable or multi-layer NAT. > People continue to think that someone will be able to "see" the > whole (I)nternet. That it is a static, while growing, thing that > can be mapped. Since everyone likes to use Comcast as a > reference, here are some facts. Comcast has more than 38 million > active interfaces using RIR allocated IP addresses. If you factor > in re-use of private networks, another 35 million IP are being > used of RFC1918 space. Your thoughts on utilization would imply > that Comcast makes up around 37% of the Internet. The question is to what extent the ping figures underestimate the real figure of utilization, full or part time, of IPv4 addresses. I wasn't suggesting the real figure is close to the ping figure. I wrote I guess it was 1.5 to 2 times this figure, but have pointed to this discussion and changed my guesstimate to 3 to 5: http://www.firstpr.com.au/ip/host-density-per-prefix/#comcast > I can't speak > with authority, but I'm quite confident that is not the case. > Also keep in mind what you consider "utilized". If you have a > VLAN with a /26, and 50 interfaces connected, are the 50 IP > utilized, or are all 64 now unusable anywhere else on the > network. The 38 million number I quote does not include subnet > loss, aggregation, capacity maintenance, or deployment plans. > Also consider, we have had arrangements with other providers, > where we routed RFC1918 space outside our AS boundries. My point > to this paragraph is simply the Internet is much more utilized > that anyone can, or will ever see. OK, thanks for this. > Paul made a good point that applies to IPv6 deployment. It didn't > matter that you had a week to study for the final exam. Other > items were prioritized and the studying happens the night before. > It is a fair assumption that there is at least one or two years > of IPv4 space left in the IANA pool. Would it be remotely > responsible for any company to drop everything to ensure IPv6 is > already deployed, when Ipv4 space is still readily available? Now > I'm not saying they wait until the last minute. I'm simply saying > many companies will prioritize accordingly. Where your assumption > is off, is that you think no one is, or wants to work on it. I wasn't suggesting no-one was working on it, just that I didn't see any evidence that an IPv6-only service would be useful to many customers for a very long time. Recent messages from Alain Durand indicate that the future Comcast 464 service is simply a centralised NAT system to put multiple customer homes and offices on single-layer NAT behind a single IPv4 address. The service will provide native IPv6 connectivity too, but I think it will be many years before IPv6 itself is important to a significant number of customers. > Any company that wants to wait until the night before, will suffer > the appropriate fate in the marketplace. But like the utilization > of the IP address space, no one will never see what most > companies are working on, or how they have prioritized IPv6 > deployment, until after the fact. In the end, the IPv4 space will > become fully allocated, and IPv6 deployments will spread like a > brushfire. Yes, but I think there is much more scope for squeezing the IPv4 toothpaste tube than most other people think. This is especially the case if a map-encap system such as LISP, APT or Ivip was implemented for IPv4. I may be wrong, but it is an interesting discussion. > Of course this should all be considered just another opinion. It contains some useful *facts* too! - Robin From Lee at dilkie.com Sat Jun 14 09:02:41 2008 From: Lee at dilkie.com (Lee Dilkie) Date: Sat, 14 Jun 2008 09:02:41 -0400 Subject: [arin-ppml] 464: was (Re: IPv6 adoption, map-encap for IPv4?) In-Reply-To: References: Message-ID: <4853C171.4090407@dilkie.com> Alain Durand wrote: > > > I think I need to clarify. We are *NOT* deploying 464 today to our > customers. Our service remains and will remain as long as possible classic > IPv4. 464 is a very promising technology that we are looking at seriously. > > - Alain. > > > I understand that you are looking at this as a means to reduce IPv4 address space usage by sharing one address amongst multiple customers, and that's a novel approach. What I am more interested in is whether you plan on offering IPv6 to your customers as well? This could be the absolutely best-case scenario if you did, as an obvious solution to the share-ed NAT problem (uPnP, no port forwarding...) your customers would experience. It both creates a demand for IPv6 and offers a solution at the same time. regards, -lee From bmanning at vacation.karoshi.com Sat Jun 14 10:08:48 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 14 Jun 2008 14:08:48 +0000 Subject: [arin-ppml] 464: was (Re: IPv6 adoption, map-encap for IPv4?) In-Reply-To: References: <4852D899.7090006@bogomips.com> Message-ID: <20080614140848.GA11394@vacation.karoshi.com.> On Fri, Jun 13, 2008 at 07:37:51PM -0400, Alain Durand wrote: > > On 6/13/08 4:29 PM, "John Paul Morrison" wrote: > > > Wow - I recall speculating that broadband providers would eventually > > move to NAT IPv4, but I didn't think they were already doing it (or that > > it was imminent). > > > I think I need to clarify. We are *NOT* deploying 464 today to our > customers. Our service remains and will remain as long as possible classic > IPv4. 464 is a very promising technology that we are looking at seriously. > > - Alain. > there is similar technology from China called IVI. They have been using this in production for several years now in their native IPv6 only networks and have recently decided to open this up for others. Its been presented a couple of times, SIGCOM2007 and most recently AFRINIC. If all goes well, we may be able to do a head/head evaluation this fall. --bill From Daniel_Alexander at Cable.Comcast.com Sat Jun 14 10:08:12 2008 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Sat, 14 Jun 2008 10:08:12 -0400 Subject: [arin-ppml] 464: was (Re: IPv6 adoption, map-encap for IPv4?) In-Reply-To: <4853C171.4090407@dilkie.com> References: <4853C171.4090407@dilkie.com> Message-ID: <997BC128AE961E4A8B880CD7442D948005664789@NJCHLEXCMB01.cable.comcast.com> Lee, In a short answer yes. Comcast has every intention of providing a customer an IPv6 address. All the trials are looking at options as to how to provide a scalable solution, to a scenario where all services do not exist on either Internet, and IPv4 resources are not readily available. -Dan -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lee Dilkie Sent: Saturday, June 14, 2008 9:03 AM To: Durand, Alain Cc: PPML; Paul_Vixie at isc.org Subject: Re: [arin-ppml] 464: was (Re: IPv6 adoption, map-encap for IPv4?) Alain Durand wrote: > > > I think I need to clarify. We are *NOT* deploying 464 today to our > customers. Our service remains and will remain as long as possible > classic IPv4. 464 is a very promising technology that we are looking at seriously. > > - Alain. > > > I understand that you are looking at this as a means to reduce IPv4 address space usage by sharing one address amongst multiple customers, and that's a novel approach. What I am more interested in is whether you plan on offering IPv6 to your customers as well? This could be the absolutely best-case scenario if you did, as an obvious solution to the share-ed NAT problem (uPnP, no port forwarding...) your customers would experience. It both creates a demand for IPv6 and offers a solution at the same time. regards, -lee _______________________________________________ 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From paul at vix.com Sat Jun 14 11:26:57 2008 From: paul at vix.com (Paul Vixie) Date: Sat, 14 Jun 2008 15:26:57 +0000 Subject: [arin-ppml] IPv6 adoption, map-encap for IPv4? In-Reply-To: Your message of "Sat, 14 Jun 2008 18:12:19 +1000." <48537D63.6000005@firstpr.com.au> References: <4851E2EA.3060407@firstpr.com.au> <997BC128AE961E4A8B880CD7442D948005664301@NJCHLEXCMB01.cable.comcast.com> <48537D63.6000005@firstpr.com.au> Message-ID: <95424.1213457217@sa.vix.com> robin, you wrote, in response to dan: > IPv6 may well be widely adopted at some time. I just think the > transition arrangements are a shambles and that it is a very long > way from being widely adopted. ... nobody anywhere will disagree with that summary. without intending to pile on, or to blame bob hinden personally, i have several times now referenced which summarized the reasons ipNG (ipv6 as we know it today) won the beauty contest even though a lot of people were saying things like "too little, too soon" (tony li). i call your attention to this little gem in section 11 (transition mechanisms): The key transition objective is to allow IPv6 and IPv4 hosts to interoperate. A second objective is to allow IPv6 hosts and routers to be deployed in the Internet in a highly diffuse and incremental fashion, with few interdependencies. A third objective is that the transition should be as easy as possible for end- users, system administrators, and network operators to understand and carry out. ... The IPng transition mechanisms ensures that IPv6 hosts can interoperate with IPv4 hosts anywhere in the Internet up until the time when IPv4 addresses run out, and allows IPv6 and IPv4 hosts within a limited scope to interoperate indefinitely after that. This feature protects the huge investment users have made in IPv4 and ensures that IPv6 does not render IPv4 obsolete. Hosts that need only a limited connectivity range (e.g., printers) need never be upgraded to IPv6. The incremental upgrade features of the IPng transition mechanisms allow the host and router vendors to integrate IPv6 into their product lines at their own pace, and allows the end users and network operators to deploy IPng on their own schedules. had these statements been accurate, there would be no debate today about the inevitability of ipv6, it wouldn't even be controversial. but since there is effectively no transition mechanism whose attributes are anything like those described above, and since ipv6 likewise failed to address the real shortage of global routing table slots, what we have is "ip with more address bits" that makes the problems we already had in 1995 even worse, and only solving a problem which in 1995 we did not have, and providing no soft or rolling transition mechanism such that the cutover is massive, expensive, and painful. however, general agreement on this point doesn't extend to your conclusion: > ... I think the chicken and egg problem > is far to big and that there is great scope for keeping most > customers on IPv4, albeit in an increasingly ugly way if it involves > less capable or multi-layer NAT. with all respect to tony ("too little, too soon") li, it's no longer too soon even though in 1995 it clearly was. and while it may still be "too little", it's what we've got, and we finally have the only problem ipv6 solves, and we have several lurching, squeaking, bumpy ways to do dual-stack with IPv4-NAT and IPv6-native, and since so many of us (even those who disliked the approach taken in ipv6) qwest for a return to native end-to-end IP... we're moving onward. simply put, i do not expect you to get any kind of traction on a plan that involves more ALG or NAT or IPv4. that ship has already sunk. paul From mueller at syr.edu Sat Jun 14 14:03:59 2008 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 14 Jun 2008 14:03:59 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD9011DC960@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD9011DC96C@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD9011DC971@SUEXCL-02.ad.syr.edu> <0E506302-719C-4C2C-9FBD-2286DB463E78@pch.net> <7663C7E01D8E094989CA62F0B0D21CD9011DC97B@SUEXCL-02.ad.syr.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901BB79E5@SUEXCL-02.ad.syr.edu> Tom This dialogue has reached if not passed the point of diminishing returns. Let's agree to talk f2f some time it's too labor-intensive this way. > -----Original Message----- > From: Tom Vest [mailto:tvest at pch.net] > > The resources are already alienable, for any economic definition of > > alienable. > > I'd be very interested to read something resembling argument rather > than assertion here; references to real observations or data too. You made a one-line assertion about alienability. Now you ask me for a full-fledged argument, observations and data. Tell you what: Apply the same standards to your own argumentation as you do to mine. Alienability in economics simply means you can give up a resource. You can do that with or without address transfers, since you can always return them to the RIR. > ... and it basically completes the functional definition of > "privatization." > I'll be happy to discuss the hypothetical benefits if you'll confirm > that you are, in fact, advocating the full privatization of IPv4. More rhetorical games. Not interested. I said that an ARIN-authorized transfer policy was _not_ full privatization, and made an argument to that effect, which you ignored. The issue is whether v4 address management is aided by decentralized transfers. All you've done is reassert that you want to call it privatization. > I believe that there are other > potentially viable mechanisms for facilitating the "recirculation" of > IPv4 as necessary, as part of a transition to IPv6 -- mechanisms that > will not have the same risks (i.e., non-reversibility) or perverse > incentives as a transfer market is likely to have. Tell me what they are. That would be useful. > Can you point to a market for any other industrial input anywhere/ > anytime that has the following characteristics: Yes, I could if I wanted to spend the next 2 hours writing about it and going down your list. Right now I don't. I will say that markets are applied to fairly limited pools all the time, e.g., auctions for desirable phone numbers or license plates, auctions for specific domain names (no other perfect substitute exists), etc. Real estate markets also come to mind. > In the mean time, if you're suggesting that the Internet is somehow > trivial as an economic phenomenon relative to the individual countries > that have been mentioned, Apparently you didn't understand my point. My point was that Internet is already deeply embedded in a commercial market economy and so a transition to a few more market incentives in a very narrow context was not comparable to disruiptive capability of the total transformation of the entire political economy of some of the world's biggest countries. > If you're suggesting that IPv4 is, at present, something less that the > Internet's only global medium of exchange -- and I do mean that quite > literally -- then I will also categorically disagree.* You have a tendency to slide into weirdo economics. It's particularly strange here. You want to call IPv4 a "medium of exchange" but you are making panicky arguments against allowing people to exchange ipv4 addresses. Interesting. I'll wait for the paper, but remember that media of exchange are more commonly called "money." And its value hinges precisely on its transferability. And IP addresses are technical resources and not a "medium of exchange." Try to find a vocabulary for your ideas that works. > immaterial. There are many things that I would like to see survive (at > least) this transition -- most importantly the capacity of the > Internet to support new entrants, Me too. I think your policies kill it. > new applications and services, on > terms that are (at least) no worse than those enjoyed by past and > current stakeholders. It is impossible to equalize opportunities across time. > I think that the system of self-governance (the > alternative to which is sometimes called "arbitrary partition" by an > illustrious industry colleague) is useful to that end, and I even > think that the RIRs have been a useful element of that system of self- > governance. So do I. I want to see non-national-state governance survive. Institutions that ignore the economic forces driving their governance problems will certainly not survive, and we all know that governments will be willing and able to step in. From tvest at pch.net Sat Jun 14 15:32:26 2008 From: tvest at pch.net (Tom Vest) Date: Sat, 14 Jun 2008 15:32:26 -0400 Subject: [arin-ppml] simple question about money In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901BB79E5@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD9011DC960@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD9011DC96C@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD9011DC971@SUEXCL-02.ad.syr.edu> <0E506302-719C-4C2C-9FBD-2286DB463E78@pch.net> <7663C7E01D8E094989CA62F0B0D21CD9011DC97B@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB79E5@SUEXCL-02.ad.syr.edu> Message-ID: <82EDD960-A366-4153-A0EE-CAB01038574C@pch.net> On Jun 14, 2008, at 2:03 PM, Milton L Mueller wrote: > Tom > This dialogue has reached if not passed the point of diminishing > returns. Let's agree to talk f2f some time it's too labor-intensive > this > way. Hi Milton, Will look forward to having that f2f when circumstances permit. Do you use Dopplr? >> -----Original Message----- >> From: Tom Vest [mailto:tvest at pch.net] >>> The resources are already alienable, for any economic definition of >>> alienable. >> >> I'd be very interested to read something resembling argument rather >> than assertion here; references to real observations or data too. > > You made a one-line assertion about alienability. Now you ask me for a > full-fledged argument, observations and data. Tell you what: Apply the > same standards to your own argumentation as you do to mine. > > Alienability in economics simply means you can give up a resource. You > can do that with or without address transfers, since you can always > return them to the RIR. So, in effect, you're suggesting that the fact that LIRs can always return address space to an RIR means that there's nothing new and different about the "alienability" that an address transfer market would create? Hmmm... >> ... and it basically completes the functional definition of >> "privatization." >> I'll be happy to discuss the hypothetical benefits if you'll confirm >> that you are, in fact, advocating the full privatization of IPv4. > > More rhetorical games. Not interested. I said that an ARIN-authorized > transfer policy was _not_ full privatization, and made an argument to > that effect, which you ignored. I honestly don't see that. I see your assertion that things would be different (apparently contra the claim above) and that the difference would be good, but I don't see any rebuttal to my claim that a transfer market would be equivalent (functionally, then formally once the suits are done) to the privatization of IPv4. If you will kindly refer me back to the right argument, I promise not to ignore it ;-) > The issue is whether v4 address management is aided by decentralized > transfers. All you've done is reassert that you want to call it > privatization. > >> I believe that there are other >> potentially viable mechanisms for facilitating the "recirculation" of >> IPv4 as necessary, as part of a transition to IPv6 -- mechanisms that >> will not have the same risks (i.e., non-reversibility) or perverse >> incentives as a transfer market is likely to have. > > Tell me what they are. That would be useful. > >> Can you point to a market for any other industrial input anywhere/ >> anytime that has the following characteristics: > > Yes, I could if I wanted to spend the next 2 hours writing about it > and > going down your list. Right now I don't. > > I will say that markets are applied to fairly limited pools all the > time, e.g., auctions for desirable phone numbers or license plates, > auctions for specific domain names (no other perfect substitute > exists), > etc. Real estate markets also come to mind. These things may come to mind, but they're not relevant. The "fairly limited" nature of the good is not at issue -- it's the non- substitutability for the purposes of entry into a very broad set of critical industries, coupled with the exclusive possession of the good by incumbents in said industry. For your examples to have any bearing, one would have to grant that the industry composed of firms called "bakery.com" or the industry composed of law firms that can only exist if they are located in the 400 block of Main Street are equivalent to the global industry of firms that can independently provide Internet access for their own requirements or third parties. The different between having to negotiate with incumbents for access to critical market entry inputs and having *any* other kind of (for lack of a netter term) "open" or "non-adversarial" access to said inputs is not a difference of degree, or a matter of imperfect substitutability. >> In the mean time, if you're suggesting that the Internet is somehow >> trivial as an economic phenomenon relative to the individual >> countries >> that have been mentioned, > > Apparently you didn't understand my point. My point was that > Internet is > already deeply embedded in a commercial market economy and so a > transition to a few more market incentives in a very narrow context > was > not comparable to disruiptive capability of the total transformation > of > the entire political economy of some of the world's biggest countries. I understood it the first time; I just summarily rejected it. Longitudinal comparisons across jurisdictions where IP address resources are/are not available on (for lack of a netter term) non- adversarial terms reveal profound differences in growth rates, industry structures, concentration levels, etc. That fact was one of the primary factors that drove the emergence of *regional* Internet registries. So just saying that some things are sold, so selling some other things -- things that happen to be both foundational and non- substitutable -- makes no difference is simply false. However, if you disagree I'll be happy to have my boys over to collect your liver later this weekend ;-) Remind me again how much you said you wanted for it? >> If you're suggesting that IPv4 is, at present, something less that >> the >> Internet's only global medium of exchange -- and I do mean that quite >> literally -- then I will also categorically disagree.* > > You have a tendency to slide into weirdo economics. Apologies -- it's a bad habit that comes from observing real economic processes in the wild, in this particular sector even. I confess it can leave one with a very unorthodox perspective -) > It's particularly > strange here. You want to call IPv4 a "medium of exchange" but you are > making panicky arguments against allowing people to exchange ipv4 > addresses. Interesting. > I'll wait for the paper, but remember that media of exchange are more > commonly called "money." And its value hinges precisely on its > transferability. And IP addresses are technical resources and not a > "medium of exchange." Try to find a vocabulary for your ideas that > works. Okay, so what's the actual components of the definition of "money" according to the weirdo source Wikipedia? 1. Unit of account 2. Store of value 3. Medium of exchange So perhaps one cannot be reduced to the other, and you should try to find a rhetorical strategy for your rebuttals that is somewhat less diversionary and abrasive. http://en.wikipedia.org/wiki/Money For the rest, I agree; you can wait for the paper. >> immaterial. There are many things that I would like to see survive >> (at >> least) this transition -- most importantly the capacity of the >> Internet to support new entrants, > > Me too. I think your policies kill it. > >> new applications and services, on >> terms that are (at least) no worse than those enjoyed by past and >> current stakeholders. > > It is impossible to equalize opportunities across time. I suppose that's true in some trivial technical sense. Usually in contexts like this, however, facts like the differences in size between the IPv4 vs. IPv6 pools, or the effects of Moore's Law on processing and network capacity are cited in defense of rising rather than diminishing expectations for the future of the Internet. Are you resigned to a future of unequal -- and reduced -- opportunities, or was this really just a trivial technical point? >> I think that the system of self-governance (the >> alternative to which is sometimes called "arbitrary partition" by an >> illustrious industry colleague) is useful to that end, and I even >> think that the RIRs have been a useful element of that system of >> self- >> governance. > > So do I. I want to see non-national-state governance survive. > Institutions that ignore the economic forces driving their governance > problems will certainly not survive, and we all know that governments > will be willing and able to step in. We are in full agreement here. However, the consequences of "ignoring economic forces" will be no different from those of misdiagnosing the problem, or of prescribing the wrong remedy; self-governance (at least) will be just as dead in each case. But we're not dead yet! TV From tony.li at tony.li Sat Jun 14 23:13:19 2008 From: tony.li at tony.li (Tony Li) Date: Sat, 14 Jun 2008 20:13:19 -0700 Subject: [arin-ppml] IPv6 adoption, map-encap for IPv4? In-Reply-To: <95424.1213457217@sa.vix.com> References: <4851E2EA.3060407@firstpr.com.au><997BC128AE961E4A8B880CD7442D948005664301@NJCHLEXCMB01.cable.comcast.com><48537D63.6000005@firstpr.com.au> <95424.1213457217@sa.vix.com> Message-ID: |with all respect to tony ("too little, too soon") li, it's no |longer too soon |even though in 1995 it clearly was. and while it may still be |"too little", |it's what we've got Agreed. And the real Greek tragedy of it all is that we now know enough to make things better. If we were to redo the decision again today, it would have a completely different outcome, and we would no longer have to deal with "too little". Tony From mueller at syr.edu Sun Jun 15 10:46:48 2008 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 15 Jun 2008 10:46:48 -0400 Subject: [arin-ppml] Creating a market for IPv4 address space in absence of routing table entry market In-Reply-To: References: <4852D899.7090006@bogomips.com> <7663C7E01D8E094989CA62F0B0D21CD9011DC97C@SUEXCL-02.ad.syr.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> I see no reason why the transacting parties would not be able to internalize the routing externality. Who is going to put down good money for addresses that can't be routed, or that even have a substantial risk of non-routability? > -----Original Message----- > > The arrangement of the address space (in terms of numbers of > blocks, shape of said blocks, and fit to existing holders blocks) are > all factors which affect the value of some space to a given holder. > i.e. 16 random /28's may not have the same usefulness as a /24) > Most of this consequential to the externality of having to route > the address space before being able to use it for most applications. > As there is no market for global table routing slots, and yet a very > real limit on their availability, this externality is extremely difficulty > to assess and creates a continuously iterated prisoner's dilemma > situation with unknown equilibrium points. Market failure in > this case can result in a truly dysfunctional Internet. From bmanning at vacation.karoshi.com Sun Jun 15 21:01:36 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 16 Jun 2008 01:01:36 +0000 Subject: [arin-ppml] Creating a market for IPv4 address space in absence of routing table entry market In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> References: <4852D899.7090006@bogomips.com> <7663C7E01D8E094989CA62F0B0D21CD9011DC97C@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> Message-ID: <20080616010136.GA30513@vacation.karoshi.com.> your statement, "who is going to put down [] money for addresses ... that have a substantial risk of non-routability." is key. Since no one can assure routability -outside- their own infrastructure, why would anyone buy addresses? --bill On Sun, Jun 15, 2008 at 10:46:48AM -0400, Milton L Mueller wrote: > I see no reason why the transacting parties would not be able to > internalize the routing externality. Who is going to put down good money > for addresses that can't be routed, or that even have a substantial risk > of non-routability? > > > -----Original Message----- > > > > The arrangement of the address space (in terms of numbers of > > blocks, shape of said blocks, and fit to existing holders blocks) are > > all factors which affect the value of some space to a given holder. > > i.e. 16 random /28's may not have the same usefulness as a /24) > > Most of this consequential to the externality of having to route > > the address space before being able to use it for most applications. > > As there is no market for global table routing slots, and yet a very > > real limit on their availability, this externality is extremely > difficulty > > to assess and creates a continuously iterated prisoner's dilemma > > situation with unknown equilibrium points. Market failure in > > this case can result in a truly dysfunctional Internet. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From jradel at vantage.com Sun Jun 15 22:11:49 2008 From: jradel at vantage.com (Jon Radel) Date: Sun, 15 Jun 2008 22:11:49 -0400 Subject: [arin-ppml] Creating a market for IPv4 address space in absence of routing table entry market In-Reply-To: <20080616010136.GA30513@vacation.karoshi.com.> References: <4852D899.7090006@bogomips.com> <7663C7E01D8E094989CA62F0B0D21CD9011DC97C@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> <20080616010136.GA30513@vacation.karoshi.com.> Message-ID: <4855CBE5.5070701@vantage.com> bmanning at vacation.karoshi.com wrote: > your statement, "who is going to put down [] money for addresses ... that have > a substantial risk of non-routability." is key. Since no one can assure > routability -outside- their own infrastructure, why would anyone buy addresses? > > Because they know how to calculate risk, make business decisions, and hire lawyers who know how to write commercial contracts? As for the original question, if anything even vaguely approaching an open market develops, I would expect the price of addresses to reflect their quality. Start selling me /28s at 10 cents each and I'll buy a couple thousand just to see if some of them eventually work out. I rather suspect that I'd be outbid. --Jon Radel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3303 bytes Desc: S/MIME Cryptographic Signature URL: From mueller at syr.edu Mon Jun 16 11:55:33 2008 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 16 Jun 2008 11:55:33 -0400 Subject: [arin-ppml] FW: Creating a market for IPv4 address space in absence of routing table entry market Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901BB7A20@SUEXCL-02.ad.syr.edu> This issue (consolidation of the ISP market) is something I have been thinking about and preparing a paper on. Assume for a moment, Tom, that address transfers are NOT allowed, ever, by any RIR. When v4 free pool is depeleted is not the only alternative then for a hungry ISP to acquire a smaller ISP if it wants to expand address space? Small ISPs might be able to buy address space from larger ISPs, especially ones that are migrating to v6. But small ISPs are much less likely to be able to acquire larger ISPs. Usually big fish eat smaller ones not the other way 'round. > -----Original Message----- > From: Tom Vest [mailto:tvest at pch.net] > Sent: Sunday, June 15, 2008 3:43 PM > To: John Curran > Cc: Milton L Mueller > Subject: Re: [arin-ppml] Creating a market for IPv4 address space in > absence of routing table entry market > > I agree with Milton's observation, but that's because I believe that > transit providers will only/always be on the buy side of any IPv4 > transfer market. In other words, I predict that a transfer market will > produce a world wherein all of the loose address space constantly > gravitates to (ever larger and larger) transit providers, henceforth > to be (increasingly non-aggregatable) PA space forevermore -- i.e., a > world characterized by all of worst feature of PA, with none of the > upside. > > I'm sure a few sources will remain for those who are willing to pay > industrial-size (8-9 significant digit) prices for small PI prefixes > -- but the institutions capable of doing this (banks, etc.), will also > have no problem finding someone to accept their money to route them. > > TV > > On Jun 15, 2008, at 10:46 AM, Milton L Mueller wrote: > > > I see no reason why the transacting parties would not be able to > > internalize the routing externality. Who is going to put down good > > money > > for addresses that can't be routed, or that even have a substantial > > risk > > of non-routability? > > > >> -----Original Message----- > >> > >> The arrangement of the address space (in terms of numbers of > >> blocks, shape of said blocks, and fit to existing holders blocks) are > >> all factors which affect the value of some space to a given holder. > >> i.e. 16 random /28's may not have the same usefulness as a /24) > >> Most of this consequential to the externality of having to route > >> the address space before being able to use it for most applications. > >> As there is no market for global table routing slots, and yet a very > >> real limit on their availability, this externality is extremely > > difficulty > >> to assess and creates a continuously iterated prisoner's dilemma > >> situation with unknown equilibrium points. Market failure in > >> this case can result in a truly dysfunctional Internet. > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the > > ARIN Public Policy > > Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact the ARIN Member Services Help Desk at info at arin.net > > if you experience any issues. From mueller at syr.edu Mon Jun 16 12:13:39 2008 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 16 Jun 2008 12:13:39 -0400 Subject: [arin-ppml] Creating a market for IPv4 address space in absence of routing table entry market In-Reply-To: <20080616010136.GA30513@vacation.karoshi.com.> References: <4852D899.7090006@bogomips.com> <7663C7E01D8E094989CA62F0B0D21CD9011DC97C@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> <20080616010136.GA30513@vacation.karoshi.com.> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901BB7A24@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Sunday, June 15, 2008 9:02 PM > To: Milton L Mueller > Cc: John Curran; PPML ppml > Subject: Re: [arin-ppml] Creating a market for IPv4 address space in > absence of routing table entry market > > your statement, "who is going to put down [] money for addresses ... that > have a substantial risk of non-routability." is key. Since no one can > assure routability -outside- their own infrastructure, why would anyone > buy addresses? that's a question you need to let the market actors answer. I do recognize that there is a real possibility that if transfers are authorized no one (or few) will use them. This happened with the broadcast spectrum in New Zealand; though spectrum transfers were legal the transactions costs of re-configuring limited geographical spectrum rights were too high to fool with, due to high levels of interdependence with the rights of many other rights-holders.* Another possible reason that the market will turn out to be a dud is that no one will want to give up address space that they have; all the big holders will just keep holding on. There may be only prospective buyers and no sellers. But this kind "failure" of an address transfer market doesn't do any harm; it just leaves things pretty much where they are now. If it turns out that there is a huge pent up demand for address transfers, on the other hand, and ARIN fails to act, the risks are far worse. We have very strong reasons to assume that people do want to buy addresses. We know less about whether people will sell addresses. I agree, it's an uncertain situation. A more glib answer to your initial question is that since no one can assure routability outside their own infrastructure, why would they ever get addresses from ARIN? I.e. the routability problem is a problem with or without transfer markets. * Anyone interested in a detailed study of NZ spectrum markets can write me off line and I'll send it when I get back to the US in a few weeks. From bmanning at vacation.karoshi.com Mon Jun 16 13:01:37 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 16 Jun 2008 17:01:37 +0000 Subject: [arin-ppml] Creating a market for IPv4 address space in absence of routing table entry market In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901BB7A24@SUEXCL-02.ad.syr.edu> References: <4852D899.7090006@bogomips.com> <7663C7E01D8E094989CA62F0B0D21CD9011DC97C@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> <20080616010136.GA30513@vacation.karoshi.com.> <7663C7E01D8E094989CA62F0B0D21CD901BB7A24@SUEXCL-02.ad.syr.edu> Message-ID: <20080616170137.GB21192@vacation.karoshi.com.> On Mon, Jun 16, 2008 at 12:13:39PM -0400, Milton L Mueller wrote: > > We have very strong reasons to assume that people do want to buy > addresses. We know less about whether people will sell addresses. I > agree, it's an uncertain situation. "we" is whom in this context? "strong reasons" - which are? please elaborate the reasons and why they are particularly strong? > A more glib answer to your initial question is that since no one can > assure routability outside their own infrastructure, why would they ever > get addresses from ARIN? I.e. the routability problem is a problem with > or without transfer markets. People get address space from ARIN for several strong reasons; the primary one (the reason I get space from ARIN) is assured uniqueness. Because they are unique, I can then approach my ISP's and request routability, knowing the uniquness can beassured (bogons can be identified and eliminated). I still have no assurance that my ISP will be willing or able to route packets - but that issue is not something ARIN (or any RIR) can do anything about. --bill From dogwallah at gmail.com Mon Jun 16 13:11:26 2008 From: dogwallah at gmail.com (McTim) Date: Mon, 16 Jun 2008 20:11:26 +0300 Subject: [arin-ppml] FW: Creating a market for IPv4 address space in absence of routing table entry market In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901BB7A20@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901BB7A20@SUEXCL-02.ad.syr.edu> Message-ID: Hullo Milton, (and welcome to the conversation) On Mon, Jun 16, 2008 at 6:55 PM, Milton L Mueller wrote: > > > This issue (consolidation of the ISP market) is something I have been > thinking about and preparing a paper on. > > Assume for a moment, Tom, that address transfers are NOT allowed, ever, > by any RIR. > Well, some of the RIRs have a sub-allocation policy in place already, which could be used to transfer space from one LIR to another. > When v4 free pool is depeleted is not the only alternative then for a > hungry ISP to acquire a smaller ISP if it wants to expand address space? or use RFC1918/NAT/IPv6/or even multicast/somebody else's block (not unheard of). -- Cheers, McTim $ whois -h whois.afrinic.net mctim From michael.dillon at bt.com Mon Jun 16 14:06:46 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 16 Jun 2008 19:06:46 +0100 Subject: [arin-ppml] FW: Creating a market for IPv4 address space in absenceof routing table entry market In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901BB7A20@SUEXCL-02.ad.syr.edu> Message-ID: > When v4 free pool is depeleted is not the only alternative > then for a hungry ISP to acquire a smaller ISP if it wants to > expand address space? No. There are several options. 1. Multilayered NAT to put more users behind each IPv4 address. 2. Just pirate some addresses from another region. For instance APNIC allocated all of 126.0.0.0/8 to Softbank, a Japanese cable provider. If an American ISP decided to "borrow" these addresses, then few of their customers would notice that they cannot contact consumer cable customers in Japan. 130.0.0.0/8 is another interesting block as are the various military allocations. 3. IPv6 is always an option. 4. Shop for an upstream provider that will provide the needed addresses. Since IPv6 deployment is likely to come first from larger ISPs, who are more likely to act as upstreams, this should supply everyone's needs once they start selling IPv6 services in earnest. > Small ISPs might be able to buy address space from larger > ISPs, especially ones that are migrating to v6. I don't know about the USA, but in Europe, the largest ISPs come from a telco background and these companies are members of an association called ETNO which does various things like fixing broken standards, and issuing joint position papers. ETNO recently released a position paper saying that IP addresses should not be sold, which I would interpret to mean that these companies will *NOT* sell surplus IP addresses. Giving them to a customer who needs them is just business as usual so I expect that the only way to access this surplus will be to buy service from such companies. Clever readers will have noticed that under today's rules were private transfers are not allowed, a company needing IP addresses could pay an ISP for service and get some addresses for free. Under the market scenario that some are promoting, a company needing IP addresses could pay an ISP for addresses and get no service at all. One of the reasons for promoting this is that they fear some companies today are paying an ISP for service and getting IP addresses, but passing on the services that they paid for. It seems strange... --Michael Dillon From jcurran at istaff.org Mon Jun 16 13:29:53 2008 From: jcurran at istaff.org (John Curran) Date: Mon, 16 Jun 2008 13:29:53 -0400 Subject: [arin-ppml] Creating a market for IPv4 address space in absence of routing table entry market In-Reply-To: <20080616170137.GB21192@vacation.karoshi.com.> References: <4852D899.7090006@bogomips.com> <7663C7E01D8E094989CA62F0B0D21CD9011DC97C@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> <20080616010136.GA30513@vacation.karoshi.com.> <7663C7E01D8E094989CA62F0B0D21CD901BB7A24@SUEXCL-02.ad.syr.edu> <20080616170137.GB21192@vacation.karoshi.com.> Message-ID: At 5:01 PM +0000 6/16/08, bmanning at vacation.karoshi.com wrote: > > People get address space from ARIN for several strong reasons; > the primary one (the reason I get space from ARIN) is assured > uniqueness. Because they are unique, I can then approach my > ISP's and request routability, knowing the uniquness can beassured > (bogons can be identified and eliminated). I still have no assurance > that my ISP will be willing or able to route packets - but that > issue is not something ARIN (or any RIR) can do anything about. Historically, the address blocks received from ARIN also meet between 3 and 12 months of need (i.e. used to connect customers) all in one contiguous block. This means that many, many customers can be connected with only a small number of routes injected in the global routing tables. This hierarchy seems to be important for Internet scaling, and address blocks transferred between parties doesn't necessarily exhibit the same properties (unless they are just as large and transferred predominantly to ISP's...) /John From mueller at syr.edu Mon Jun 16 18:09:21 2008 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 16 Jun 2008 18:09:21 -0400 Subject: [arin-ppml] FW: Creating a market for IPv4 address space inabsenceof routing table entry market In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901BB7A20@SUEXCL-02.ad.syr.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901BB7A7C@SUEXCL-02.ad.syr.edu> > -----Original Message----- > No. There are several options. [to acquiring other ISPs to obtain their addresses --MM] > > 1. Multilayered NAT to put more users behind each IPv4 address. > > 2. Just pirate some addresses from another region. For instance APNIC > allocated all of 126.0.0.0/8 to Softbank, a Japanese cable provider. If > an American ISP decided to "borrow" these addresses, then few of their > customers would notice that they cannot contact consumer cable customers > in Japan. 130.0.0.0/8 is another interesting block as are the various > military allocations. Is it just me, or do these first two alternatives not look so great? ;-) More NAT-ing and a fragmented internet? > 3. IPv6 is always an option. Yes. But remember, a parameter of this discussion is that we are talking about what ISPs _who want more v4 addresses_ will do. If they have already decided to migrate to v6 and are not interested in more v4 addys, then they are outside the bounds of this discussion. > 4. Shop for an upstream provider that will provide the needed addresses. This is reinforcing my point. The upstream will sense the demand for more v4 addresses and might consider acquisitions of smaller ISPs to get them. > I don't know about the USA, but in Europe, the largest ISPs come from a > telco background and these companies are members of an association > called ETNO which does various things like fixing broken standards, and > issuing joint position papers. ETNO recently released a position paper > saying that IP addresses should not be sold, which I would interpret to Ah yes, good old ETNO. No time to go into details but I think that those of you who are worried that address transfers might increase incumbents' market power might do well to contemplate why ETNO is do dead set against address transfer markets. Is their opposition consistent with your theory? > mean that these companies will *NOT* sell surplus IP addresses. Giving > them to a customer who needs them is just business as usual so I expect > that the only way to access this surplus will be to buy service from > such companies. And that might have something to do with their opposition to transfer markets, eh? > Clever readers will have noticed that under today's rules where private > transfers are not allowed, a company needing IP addresses could pay an > ISP for service and get some addresses for free. Nothing is free. If their possession of addresses is the main reason you are going to them for service then you are going to pay for the addresses, believe me. > Under the market > scenario that some are promoting, a company needing IP addresses could > pay an ISP for addresses and get no service at all. One of the reasons > for promoting this is that they fear some companies today are paying an > ISP for service and getting IP addresses, but passing on the services > that they paid for. It seems strange... That's called "unbundling." There's a whole economic literature on how unbundling components of a service with different competitive conditions can improve consumer welfare, and how bundling them together can increase the market power of the bundler. From mueller at syr.edu Mon Jun 16 18:16:04 2008 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 16 Jun 2008 18:16:04 -0400 Subject: [arin-ppml] Creating a market for IPv4 address space in absence of routing table entry market In-Reply-To: <20080616170137.GB21192@vacation.karoshi.com.> References: <4852D899.7090006@bogomips.com> <7663C7E01D8E094989CA62F0B0D21CD9011DC97C@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> <20080616010136.GA30513@vacation.karoshi.com.> <7663C7E01D8E094989CA62F0B0D21CD901BB7A24@SUEXCL-02.ad.syr.edu> <20080616170137.GB21192@vacation.karoshi.com.> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901BB7A7D@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > > We have very strong reasons to assume that people do want to buy > > addresses. We know less about whether people will sell addresses. I > > agree, it's an uncertain situation. > > "we" is whom in this context? Everyone I know of involved in this discussion, with the possible exception of you. ;-) > "strong reasons" - which are? please elaborate the reasons > and why they are particularly strong? Is this a trick question? The strong reasons are the continued fast growth in the ipv4 Internet, the depletion of the v4 free pool and the huge uncertainty regarding the leap to ipv6. > I still have no assurance > that my ISP will be willing or able to route packets - but that > issue is not something ARIN (or any RIR) can do anything about. That was precisely my point. If ARIN or any other RIR authorizes address transfers, that act in and of itself neither undermines nor improves routability. From owen at delong.com Mon Jun 16 18:22:33 2008 From: owen at delong.com (Owen DeLong) Date: Mon, 16 Jun 2008 15:22:33 -0700 Subject: [arin-ppml] Creating a market for IPv4 address space in absence of routing table entry market In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901BB7A7D@SUEXCL-02.ad.syr.edu> References: <4852D899.7090006@bogomips.com> <7663C7E01D8E094989CA62F0B0D21CD9011DC97C@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> <20080616010136.GA30513@vacation.karoshi.com.> <7663C7E01D8E094989CA62F0B0D21CD901BB7A24@SUEXCL-02.ad.syr.edu> <20080616170137.GB21192@vacation.karoshi.com.> <7663C7E01D8E094989CA62F0B0D21CD901BB7A7D@SUEXCL-02.ad.syr.edu> Message-ID: <4C727C69-0B7D-45D5-A2FE-0249353E6B05@delong.com> On Jun 16, 2008, at 3:16 PM, Milton L Mueller wrote: > > >> -----Original Message----- >> From: bmanning at vacation.karoshi.com > [mailto:bmanning at vacation.karoshi.com] >>> We have very strong reasons to assume that people do want to buy >>> addresses. We know less about whether people will sell addresses. I >>> agree, it's an uncertain situation. >> >> "we" is whom in this context? > > Everyone I know of involved in this discussion, with the possible > exception of you. ;-) > I am also involved in the discussion and have no strong reason to assume that people want to buy addresses. In fact, I'm trying very hard not to assume anything in this discussion as I think that assumptions are not what is needed in this situation. I think there has been far too much of that and it has lead to very bad conclusions in at least two registries. >> "strong reasons" - which are? please elaborate the reasons >> and why they are particularly strong? > > Is this a trick question? The strong reasons are the continued fast > growth in the ipv4 Internet, the depletion of the v4 free pool and the > huge uncertainty regarding the leap to ipv6. > Seems like a valid question to me. Those are all reasons to believe that something different probably needs to occur soon. I do not see any strong tie between that and the assumption that people will want to buy addresses. I suspect that if purchasing them becomes the path of least resistance to obtaining addresses, sure, there's good reason to believe people will resort to that. However, I believe the substantive part of this discussion is more along the lines of should we make that the path of least resistance, so, I don't see how that helps the discussion. >> I still have no assurance >> that my ISP will be willing or able to route packets - but that >> issue is not something ARIN (or any RIR) can do anything about. > > That was precisely my point. If ARIN or any other RIR authorizes > address > transfers, that act in and of itself neither undermines nor improves > routability. This is not necessarily true. Up to this point, because ARIN has taken some care to avoid doing things leading directly to massive dis- aggregation, there is some level of credibility given to ARIN-issued address space by ISPs in general. While ARIN cannot and does not guarantee routability and ISPs are free to do what they want independent of ARIN, it would be a radical change for ARIN to completely disregard the history and context here. I'm not sure whether it would be a good or a bad radical change, but, it would be a radical change. Owen From keith.rhea at domaccess.com Mon Jun 16 19:02:10 2008 From: keith.rhea at domaccess.com (keith rhea) Date: Mon, 16 Jun 2008 19:02:10 -0400 Subject: [arin-ppml] FW: Creating a market for IPv4 address spaceinabsenceof routing table entry market In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901BB7A7C@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901BB7A20@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB7A7C@SUEXCL-02.ad.syr.edu> Message-ID: <040401c8d005$04f3ce80$7504a8c0@91098204484F430> How do I get off this chat room list??? K -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller Sent: Monday, June 16, 2008 6:09 PM To: michael.dillon at bt.com; ppml at arin.net Subject: Re: [arin-ppml] FW: Creating a market for IPv4 address spaceinabsenceof routing table entry market > -----Original Message----- > No. There are several options. [to acquiring other ISPs to obtain their addresses --MM] > > 1. Multilayered NAT to put more users behind each IPv4 address. > > 2. Just pirate some addresses from another region. For instance APNIC > allocated all of 126.0.0.0/8 to Softbank, a Japanese cable provider. If > an American ISP decided to "borrow" these addresses, then few of their > customers would notice that they cannot contact consumer cable customers > in Japan. 130.0.0.0/8 is another interesting block as are the various > military allocations. Is it just me, or do these first two alternatives not look so great? ;-) More NAT-ing and a fragmented internet? > 3. IPv6 is always an option. Yes. But remember, a parameter of this discussion is that we are talking about what ISPs _who want more v4 addresses_ will do. If they have already decided to migrate to v6 and are not interested in more v4 addys, then they are outside the bounds of this discussion. > 4. Shop for an upstream provider that will provide the needed addresses. This is reinforcing my point. The upstream will sense the demand for more v4 addresses and might consider acquisitions of smaller ISPs to get them. > I don't know about the USA, but in Europe, the largest ISPs come from a > telco background and these companies are members of an association > called ETNO which does various things like fixing broken standards, and > issuing joint position papers. ETNO recently released a position paper > saying that IP addresses should not be sold, which I would interpret to Ah yes, good old ETNO. No time to go into details but I think that those of you who are worried that address transfers might increase incumbents' market power might do well to contemplate why ETNO is do dead set against address transfer markets. Is their opposition consistent with your theory? > mean that these companies will *NOT* sell surplus IP addresses. Giving > them to a customer who needs them is just business as usual so I expect > that the only way to access this surplus will be to buy service from > such companies. And that might have something to do with their opposition to transfer markets, eh? > Clever readers will have noticed that under today's rules where private > transfers are not allowed, a company needing IP addresses could pay an > ISP for service and get some addresses for free. Nothing is free. If their possession of addresses is the main reason you are going to them for service then you are going to pay for the addresses, believe me. > Under the market > scenario that some are promoting, a company needing IP addresses could > pay an ISP for addresses and get no service at all. One of the reasons > for promoting this is that they fear some companies today are paying an > ISP for service and getting IP addresses, but passing on the services > that they paid for. It seems strange... That's called "unbundling." There's a whole economic literature on how unbundling components of a service with different competitive conditions can improve consumer welfare, and how bundling them together can increase the market power of the bundler. _______________________________________________ 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From randy at psg.com Mon Jun 16 19:33:10 2008 From: randy at psg.com (Randy Bush) Date: Tue, 17 Jun 2008 08:33:10 +0900 Subject: [arin-ppml] FW: Creating a market for IPv4 address spaceinabsenceof routing table entry market In-Reply-To: <040401c8d005$04f3ce80$7504a8c0@91098204484F430> References: <7663C7E01D8E094989CA62F0B0D21CD901BB7A20@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB7A7C@SUEXCL-02.ad.syr.edu> <040401c8d005$04f3ce80$7504a8c0@91098204484F430> Message-ID: <4856F836.1070005@psg.com> keith rhea wrote: > How do I get off this chat room list??? read to the bottom of the email From steve at ibctech.ca Mon Jun 16 19:35:15 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 16 Jun 2008 19:35:15 -0400 Subject: [arin-ppml] FW: Creating a market for IPv4 address spaceinabsenceof routing table entry market In-Reply-To: <040401c8d005$04f3ce80$7504a8c0@91098204484F430> References: <7663C7E01D8E094989CA62F0B0D21CD901BB7A20@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB7A7C@SUEXCL-02.ad.syr.edu> <040401c8d005$04f3ce80$7504a8c0@91098204484F430> Message-ID: <4856F8B3.4040204@ibctech.ca> keith rhea wrote: > How do I get off this chat room list??? Review the footer that is present in *every* *single* *message* that is sent to you via this list.... > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From geneb at deltasoft.com Mon Jun 16 20:22:02 2008 From: geneb at deltasoft.com (Gene Buckle) Date: Mon, 16 Jun 2008 17:22:02 -0700 (PDT) Subject: [arin-ppml] FW: Creating a market for IPv4 address spaceinabsenceof routing table entry market In-Reply-To: <4856F836.1070005@psg.com> References: <7663C7E01D8E094989CA62F0B0D21CD901BB7A20@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB7A7C@SUEXCL-02.ad.syr.edu> <040401c8d005$04f3ce80$7504a8c0@91098204484F430> <4856F836.1070005@psg.com> Message-ID: On Tue, 17 Jun 2008, Randy Bush wrote: > keith rhea wrote: >> How do I get off this chat room list??? > > read to the bottom of the email > ...and understand this isn't a "chat room list". *sigh* g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. From michael.dillon at bt.com Tue Jun 17 06:23:19 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 17 Jun 2008 11:23:19 +0100 Subject: [arin-ppml] FW: Creating a market for IPv4 address space inabsenceof routing table entry market In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901BB7A7C@SUEXCL-02.ad.syr.edu> Message-ID: > > 1. Multilayered NAT to put more users behind each IPv4 address. > > > > 2. Just pirate some addresses from another region. For > instance APNIC > > allocated all of 126.0.0.0/8 to Softbank, a Japanese cable provider. > If > > an American ISP decided to "borrow" these addresses, then > few of their > > customers would notice that they cannot contact consumer cable > customers > > in Japan. 130.0.0.0/8 is another interesting block as are > the various > > military allocations. > > Is it just me, or do these first two alternatives not look so > great? ;-) More NAT-ing and a fragmented internet? Being an ISP is a business. If it makes business sense to apply more NAT or pirate IPv4 addresses from Japan, then that's what businesses will do. Most people do not care about a fragmented Internet, unless the fragmentation is close to home. The fact is that the Return on Investment for the above two scenarios is limited, especially the NATing scenario, because you have to spend the money but you really don't control how long you can use the investment. If the market shifts strongly to IPv6, then you are boxed in and have to invest a second time. This risk will tend to drive businesses to make invest in IPv6 rather than stretching the lifetime of IPv4. Since the IPv6 investment money will go towards v6-v4 interworking such as NAT-PT, a really careful investor can put their money in equipment that supports both the multi-layer NAT scenario as well as IPv6. > > 4. Shop for an upstream provider that will provide the needed > addresses. > > This is reinforcing my point. The upstream will sense the > demand for more v4 addresses and might consider acquisitions > of smaller ISPs to get them. It's much easier to shift your broadband products to IPv6, and then use the recovered IPv4 addresses for leased-line customers. Nowadays, many providers are doing this with their dialin infrastructure. This strategy is what I would call cannibalisation, where an ISP reviews their products and forcibly migrates certain lower margin products to IPv6 in order to use the IPv4 addresses for more lucrative customers. > Giving > > them to a customer who needs them is just business as usual so I > expect > > that the only way to access this surplus will be to buy > service from > > such companies. > > And that might have something to do with their opposition to > transfer markets, eh? Why is that? In a transfer market, the ISP who will bundle free IPv4 addresses with Internet access service should always win a deal against someone who just wants to sell some addresses. This makes it hard for a market pricing mechnism to work. If very few address blocks are offered for sale, it may seem as though the price should be $500,000 for a /24, but if ISPs with spare addresses are still giving them away, then the real value is close to zero. > That's called "unbundling." There's a whole economic > literature on how unbundling components of a service with > different competitive conditions can improve consumer > welfare, and how bundling them together can increase the > market power of the bundler. This discussion does not involve consumers at all. They will never buy IPv4 addresses. In any case, the abundance of IPv6 addresses will tend to improve the position of the consumer because they can justify a /48 block if they want it. --Michael Dillon From bmanning at vacation.karoshi.com Tue Jun 17 09:35:46 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 17 Jun 2008 13:35:46 +0000 Subject: [arin-ppml] Creating a market for IPv4 address space in absence of routing table entry market In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901BB7A7D@SUEXCL-02.ad.syr.edu> References: <4852D899.7090006@bogomips.com> <7663C7E01D8E094989CA62F0B0D21CD9011DC97C@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> <20080616010136.GA30513@vacation.karoshi.com.> <7663C7E01D8E094989CA62F0B0D21CD901BB7A24@SUEXCL-02.ad.syr.edu> <20080616170137.GB21192@vacation.karoshi.com.> <7663C7E01D8E094989CA62F0B0D21CD901BB7A7D@SUEXCL-02.ad.syr.edu> Message-ID: <20080617133546.GA11590@vacation.karoshi.com.> On Mon, Jun 16, 2008 at 06:16:04PM -0400, Milton L Mueller wrote: > > > > -----Original Message----- > > From: bmanning at vacation.karoshi.com > [mailto:bmanning at vacation.karoshi.com] > > > We have very strong reasons to assume that people do want to buy > > > addresses. We know less about whether people will sell addresses. I > > > agree, it's an uncertain situation. > > > > "we" is whom in this context? > > Everyone I know of involved in this discussion, with the possible > exception of you. ;-) that is a leap of faith - to presume that all participants on the arin public policy mailing list want to buy addresses. and since you have not aske me my opinion, your presumption that i am the sole exception is ... unrealistic. > > "strong reasons" - which are? please elaborate the reasons > > and why they are particularly strong? > > Is this a trick question? The strong reasons are the continued fast > growth in the ipv4 Internet, the depletion of the v4 free pool and the > huge uncertainty regarding the leap to ipv6. for reasons stated elsewhere in this thread, the "continued fast growth in the ipv4 Internet" is doomed. there are only 4 billion marbles to play with and soon all of them will be in play. We can't make more. We have two choices; NAT all the way down or IPv6. I think your presuming that -IF- one could buy/sell integers -AND- Milton happend to "buy" 128.0.0.0/3 - that anyone would automatically route it for you. Regardless of your status with regard to any prefix in question, "owner" or (imho) steward, there is ZERO assurance of routablity by a third party. > > I still have no assurance > > that my ISP will be willing or able to route packets - but that > > issue is not something ARIN (or any RIR) can do anything about. > > That was precisely my point. If ARIN or any other RIR authorizes address > transfers, that act in and of itself neither undermines nor improves > routability. Ah... perhaps my presumption stated above is not what you think after all. authorizing transfers does not equate to buying/selling address space. --bill From schiller at uu.net Tue Jun 17 12:36:15 2008 From: schiller at uu.net (Jason Schiller) Date: Tue, 17 Jun 2008 12:36:15 -0400 (EDT) Subject: [arin-ppml] Creating a market for IPv4 address space in absence of routing table entry market In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> Message-ID: On Sun, 15 Jun 2008, Milton L Mueller wrote: > I see no reason why the transacting parties would not be able to > internalize the routing externality. Who is going to put down good money > for addresses that can't be routed, or that even have a substantial risk > of non-routability? Milton, I think it is rather difficult to internalize the routing externality. As Geoff Huston says there is no routing economy. The problem is that there is a real cost of consuming a routing table slot (RIB), a forwarding table slot (FIB), and CPU to deal with routing instability with a reasonable amount of convergence time. Scaling the RIB memory, the FIB memory, and the routing processor CPU have costs, not just in dollars, but also in size, weight, power, cooling requirements, etc. Assuming we can reasonably predict the growth of the routing table, assuming the growth rate doesn't change too suddenly, and assuming we can reasonably estimate the costs of scaling a router, we will still have a problem of distributing the cost. The distribution problem is as follows: 1. Identify all of the ASes that receive full routes 1A. Alternatively, identify all of the ASes that cannot function without receiving full routes 2. Identify the number of routers in each of these networks that receive full routes 3. Identify the life span of these routers as a function of the number of Internet routes, the number of internal routes, the number of places these routes are learned, the BGP architecture (flat iBGP vs hierarchy with some number us clusters / sub-ASes being aggregated at a given level of the hierarchy), and the amount of routing churn 4. Recover enough cost by charging per prefix in the projected life span for all networks that carry full routes to upgrade all of their routers that carry full routes 5. Distribute this money equitably to all the networks that carry full routes To say it another way, should an ISP charge an end user to place a route in the routing table, and then share a portion of those proceeds to every other network that carries that route? Should that portion be determined by the cost of what upgrades cost? Should ISPs with more routers (and thus a higher upgrade cost) receive a greater share of the proceeds? Also it seems there is not a strong correlation between routing churn and Internet table size, but rather only a few networks are responsible for a majority of the churn, so this seems less predictable. Should ISPs also charge for routing churn and share a portion of those proceeds to every other network that see the churn? What about multi-homed end-sites that receive a full routing table? Is this only a benefit to them to use shorter paths, and therefore they should carry the burden, or should they receive a share of the portion of the proceeds from charging for routing slots? __Jason > > > -----Original Message----- > > > > The arrangement of the address space (in terms of numbers of > > blocks, shape of said blocks, and fit to existing holders blocks) are > > all factors which affect the value of some space to a given holder. > > i.e. 16 random /28's may not have the same usefulness as a /24) > > Most of this consequential to the externality of having to route > > the address space before being able to use it for most applications. > > As there is no market for global table routing slots, and yet a very > > real limit on their availability, this externality is extremely > difficulty > > to assess and creates a continuously iterated prisoner's dilemma > > situation with unknown equilibrium points. Market failure in > > this case can result in a truly dysfunctional Internet. From JOHN at egh.com Tue Jun 17 16:37:18 2008 From: JOHN at egh.com (John Santos) Date: Tue, 17 Jun 2008 16:37:18 -0400 Subject: [arin-ppml] Creating a market for IPv4 address space in absence of routing table entry market In-Reply-To: <20080617133546.GA11590@vacation.karoshi.com.> Message-ID: <1080617162313.449B-100000@Ives.egh.com> On Tue, 17 Jun 2008 bmanning at vacation.karoshi.com wrote: > On Mon, Jun 16, 2008 at 06:16:04PM -0400, Milton L Mueller wrote: > > > > > > > -----Original Message----- > > > From: bmanning at vacation.karoshi.com > > [mailto:bmanning at vacation.karoshi.com] > > > > We have very strong reasons to assume that people do want to buy > > > > addresses. We know less about whether people will sell addresses. I > > > > agree, it's an uncertain situation. > > > > > > "we" is whom in this context? > > > > Everyone I know of involved in this discussion, with the possible > > exception of you. ;-) > > that is a leap of faith - to presume that all participants > on the arin public policy mailing list want to buy addresses. > and since you have not aske me my opinion, your presumption > that i am the sole exception is ... unrealistic. > Sheesh!! It *would* be a leap of faith if Milton had presumed that, but he said no such thing. He said "we" (presumably the consensus amongst PPML subscribers) think people want to buy addresses. He did *not* say we, ourselves, want to buy addresses. Please *read* the post before replying. It's not like Milton was vague. > > > "strong reasons" - which are? please elaborate the reasons > > > and why they are particularly strong? > > > > Is this a trick question? The strong reasons are the continued fast > > growth in the ipv4 Internet, the depletion of the v4 free pool and the > > huge uncertainty regarding the leap to ipv6. > > for reasons stated elsewhere in this thread, the "continued > fast growth in the ipv4 Internet" is doomed. there are only > 4 billion marbles to play with and soon all of them will be > in play. We can't make more. We have two choices; NAT all > the way down or IPv6. > Or the third choice, redistribute the marbles, which is what's being discussed here. > I think your presuming that -IF- one could buy/sell integers > -AND- Milton happend to "buy" 128.0.0.0/3 - that anyone would > automatically route it for you. Regardless of your status > with regard to any prefix in question, "owner" or (imho) steward, > there is ZERO assurance of routablity by a third party. > Finally, an actual on-topic response: You think redistribution wouldn't work because it would be unlikely that they would get routed. > > > I still have no assurance > > > that my ISP will be willing or able to route packets - but that > > > issue is not something ARIN (or any RIR) can do anything about. > > > > That was precisely my point. If ARIN or any other RIR authorizes address > > transfers, that act in and of itself neither undermines nor improves > > routability. > > Ah... perhaps my presumption stated above is not what > you think after all. > authorizing transfers does not equate to buying/selling > address space. > I don't think anyone who advocates a market in address space thinks that implies ownership of address space. It implies ownership of the right to use address space (i.e. a license to use that unique set of integers, in the limited context of the IPv4 Internet.) > --bill > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > > Sorry to be so snarky, but there is enough material posted to this list to try to wade through every day without the additional burden of careless misrepresentations of what other people said. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From mueller at syr.edu Tue Jun 17 18:14:27 2008 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 17 Jun 2008 18:14:27 -0400 Subject: [arin-ppml] Creating a transfer market for IPv4 addresses In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901BB7AF6@SUEXCL-02.ad.syr.edu> > > I think it is rather difficult to internalize the routing externality. As > Geoff Huston says there is no routing economy. The problem is that there > is a real cost of consuming a routing table slot (RIB), a forwarding table > slot (FIB), and CPU to deal with routing instability with a reasonable > amount of convergence time. Jason, I think the issue of a routing slot fee or market is a very interesting and complex one. I've had some very preliminary discussions of it with Geoff Huston. At the time he seemed to believe that because someone in 1996 (Yakov Richter, I think) tried to write one paper about it and didn't get very far that it can't be done. But then, that was three years ago and in 2007 Huston became the author of APNIC's proposed address transfer policy, didn't he? Right now we are talking about address transfers, not a routing market. I don't see the two as linked. I think Jon Radel hit the nail on the head. "I would expect the price of addresses to reflect their quality." If the routability of a tradeable address block is in question, the willingness of people to buy them will decrease proportionately. I don't think anything else needs to be said about that. If no market develops because of those uncertainties then no harm done. Lots of expensive assets have lots of uncertainties associated with their value and functionality. Think of buying a home, or even renting a apartment. Who knows what unpleasant little surprises await you. And yet, people buy them. And we're all better off because they can be traded. Getting back to Bill Manning's question whether anyone out there really wants to buy address blocks. That discussion is getting a bit silly. We need to explore and discuss the merits of authorizing private address transfers; I am not going to spend another minute humoring the pretense that no one is interested in transferring addresses. I am justified in doing that because, if anyone really believes that there are no substantial players out there willing to trade address space for money, then that person shouldn't worry about instituting the transfer policies. If no one trades, the transfers can't possibly do any harm, can they? You can't have it both ways. EITHER address transfer policy proposals are "shock therapy," the end of the RIR world as we know it, a form of stealth privatization that will lead to rampant speculation, the collapse of routing tables, the fragmentation of the Internet and the heartbreak of psoriasis -- OR they are pointless exercises that no one is interested in. Take one, or the other. Then we can have a discussion. > -----Original Message----- > > Scaling the RIB memory, the FIB memory, and the routing processor CPU have > costs, not just in dollars, but also in size, weight, power, cooling > requirements, etc. Assuming we can reasonably predict the growth of the > routing table, assuming the growth rate doesn't change too suddenly, and > assuming we can reasonably estimate the costs of scaling a router, we will > still have a problem of distributing the cost. > > The distribution problem is as follows: > > 1. Identify all of the ASes that receive full routes > 1A. Alternatively, identify all of the ASes that cannot function > without receiving full routes > > 2. Identify the number of routers in each of these networks that receive > full routes > > 3. Identify the life span of these routers as a function of the number of > Internet routes, the number of internal routes, the number of places > these routes are learned, the BGP architecture (flat iBGP vs hierarchy > with some number us clusters / sub-ASes being aggregated at a given > level of the hierarchy), and the amount of routing churn > > 4. Recover enough cost by charging per prefix in the projected life span > for all networks that carry full routes to upgrade all of their routers > that carry full routes > > 5. Distribute this money equitably to all the networks that carry full > routes > > To say it another way, should an ISP charge an end user to place a route > in the routing table, and then share a portion of those proceeds to every > other network that carries that route? Should that portion be determined > by the cost of what upgrades cost? Should ISPs with more routers (and > thus a higher upgrade cost) receive a greater share of the proceeds? > > Also it seems there is not a strong correlation between routing churn and > Internet table size, but rather only a few networks are responsible for a > majority of the churn, so this seems less predictable. Should ISPs also > charge for routing churn and share a portion of those proceeds to every > other network that see the churn? > > What about multi-homed end-sites that receive a full routing table? Is > this only a benefit to them to use shorter paths, and therefore they > should carry the burden, or should they receive a share of the portion of > the proceeds from charging for routing slots? > > __Jason > > > > > > -----Original Message----- > > > > > > The arrangement of the address space (in terms of numbers of > > > blocks, shape of said blocks, and fit to existing holders blocks) are > > > all factors which affect the value of some space to a given holder. > > > i.e. 16 random /28's may not have the same usefulness as a /24) > > > Most of this consequential to the externality of having to route > > > the address space before being able to use it for most applications. > > > As there is no market for global table routing slots, and yet a very > > > real limit on their availability, this externality is extremely > > difficulty > > > to assess and creates a continuously iterated prisoner's dilemma > > > situation with unknown equilibrium points. Market failure in > > > this case can result in a truly dysfunctional Internet. From randy at psg.com Tue Jun 17 19:01:23 2008 From: randy at psg.com (Randy Bush) Date: Wed, 18 Jun 2008 08:01:23 +0900 Subject: [arin-ppml] Creating a transfer market for IPv4 addresses In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901BB7AF6@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB7AF6@SUEXCL-02.ad.syr.edu> Message-ID: <48584243.8010504@psg.com> > Right now we are talking about address transfers, not a routing market. > I don't see the two as linked. many people here do. there is apocrypha that an ip space market will cause more fragmentation, and that this puts more pressure on the routing table, and that a market in routing slots would address that issue. personally, i believe that the first assumption, market produces fragmentation, is very weak. it just changes where you get space, not what you do with it. of course there will be some effect, but nothing like the crap-think that makes the current routing table over half /24 rubbish. secondly, i am highly suspicious of any amateur regulatory causal chains this long. we are sooo good at asserting physics that is not yet demonstrated. hence my inclination to minimal regulatory structure until we learn more about reality and depend less on amateur guesses. randy From bmanning at vacation.karoshi.com Tue Jun 17 21:06:39 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 18 Jun 2008 01:06:39 +0000 Subject: [arin-ppml] Creating a transfer market for IPv4 addresses In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901BB7AF6@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB7AF6@SUEXCL-02.ad.syr.edu> Message-ID: <20080618010639.GA16898@vacation.karoshi.com.> On Tue, Jun 17, 2008 at 06:14:27PM -0400, Milton L Mueller wrote: > > > > Right now we are talking about address transfers, not a routing market. > I don't see the two as linked. this is an interesting construct. if they are not linked, we can only beleive that address hording is the object. Last I checked, address hording is generally frowned on by the community. And Jason almost certainly knows more about routing than you and I combined. If he claims they are linked, then its a really good opportunity to learn from experts than dismiss routing as a real concern. > Getting back to Bill Manning's question whether anyone out there really > wants to buy address blocks. That discussion is getting a bit silly. We > need to explore and discuss the merits of authorizing private address > transfers; I am not going to spend another minute humoring the pretense > that no one is interested in transferring addresses. again the "we"... why do "we" NEED to explore private transfers? why is that the presumed desired outcome over any other possible future? > I am justified in doing that because, if anyone really believes that > there are no substantial players out there willing to trade address > space for money, then that person shouldn't worry about instituting the > transfer policies. If no one trades, the transfers can't possibly do any > harm, can they? other than the waste of time and resource in creating worthless policy, no harm no foul. that said, review and update of transfer policies are clearly within the perview of the ARIN membership. I'm not persuaded about your forgone conclusions about: ) the disconnect between address stewardship and routability ) equating stewardship with ownership ) the inevitability of private transfer --bill From bmanning at vacation.karoshi.com Tue Jun 17 21:13:01 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 18 Jun 2008 01:13:01 +0000 Subject: [arin-ppml] Creating a market for IPv4 address space in absence of routing table entry market In-Reply-To: <1080617162313.449B-100000@Ives.egh.com> References: <20080617133546.GA11590@vacation.karoshi.com.> <1080617162313.449B-100000@Ives.egh.com> Message-ID: <20080618011301.GB16898@vacation.karoshi.com.> On Tue, Jun 17, 2008 at 04:37:18PM -0400, John Santos wrote: > > I think your presuming that -IF- one could buy/sell integers > > -AND- Milton happend to "buy" 128.0.0.0/3 - that anyone would > > automatically route it for you. Regardless of your status > > with regard to any prefix in question, "owner" or (imho) steward, > > there is ZERO assurance of routablity by a third party. > > > > Finally, an actual on-topic response: You think redistribution wouldn't > work because it would be unlikely that they would get routed. I am persuaded that simply being the registered steward of a prefix will not be sufficent to get the prefix routed. Redistribution works today. And routing is not assured. -- bill From randy at psg.com Tue Jun 17 21:23:33 2008 From: randy at psg.com (Randy Bush) Date: Wed, 18 Jun 2008 10:23:33 +0900 Subject: [arin-ppml] Creating a market for IPv4 address space in absence of routing table entry market In-Reply-To: <20080618011301.GB16898@vacation.karoshi.com.> References: <20080617133546.GA11590@vacation.karoshi.com.> <1080617162313.449B-100000@Ives.egh.com> <20080618011301.GB16898@vacation.karoshi.com.> Message-ID: <48586395.4020001@psg.com> > I am persuaded that simply being the registered steward of > a prefix will not be sufficient to get the prefix routed. no quibble, but not overly interesting. but, to hoist myself on my own petard, are you/folk at all concerned that, as the rpki becomes used in secure routing, iana and the rirs will have affect your prefixes routability far more than they do today? while we are trying to make it so an accidental ops slip at an rpki node will not damage you if it is corrected in reasonable time, if you piss off someone up the validation chain (or worse, if someone up the chain two links pisses someone >2 links up), they can break the validation chain for your certs/roas. randy From tvest at pch.net Tue Jun 17 22:00:48 2008 From: tvest at pch.net (Tom Vest) Date: Tue, 17 Jun 2008 22:00:48 -0400 Subject: [arin-ppml] Creating a transfer market for IPv4 addresses In-Reply-To: <48584243.8010504@psg.com> References: <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB7AF6@SUEXCL-02.ad.syr.edu> <48584243.8010504@psg.com> Message-ID: <4341AA03-1620-444A-85CF-B5535F7DA7C0@pch.net> On Jun 17, 2008, at 7:01 PM, Randy Bush wrote: > secondly, i am highly suspicious of any amateur regulatory causal > chains > this long. we are sooo good at asserting physics that is not yet > demonstrated. hence my inclination to minimal regulatory structure > until we learn more about reality and depend less on amateur guesses. Randy, I'm curious; what is your litmus test for distinguishing between amateur and expert in a given field? And what field is it exactly that one would need expertise in, for this particular situation, in order to merit something other than summary dismissal from you? Whose guesses -- and whose blunt assertions and summary dismissals -- get to count more (or maybe at all) in this case, and why? TV From mueller at syr.edu Wed Jun 18 03:41:35 2008 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 18 Jun 2008 03:41:35 -0400 Subject: [arin-ppml] Creating a market for IPv4 address space in absence of routing table entry market References: <20080617133546.GA11590@vacation.karoshi.com.> <1080617162313.449B-100000@Ives.egh.com> <20080618011301.GB16898@vacation.karoshi.com.> <48586395.4020001@psg.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901884113@SUEXCL-02.ad.syr.edu> Very interested and concerned about the interaction between secure routing and centralization of authority over what has before now been a relatively loose system of routing self-governance by ISPs. I guess I am less worried about IANA and RIRs abusing their authority over a validation chain than I am about governments or lawsuits that force them to do so. Think of DNS and the UDRP. ________________________________ From: arin-ppml-bounces at arin.net on behalf of Randy Bush but, to hoist myself on my own petard, are you/folk at all concerned that, as the rpki becomes used in secure routing, iana and the rirs will have affect your prefixes routability far more than they do today? while we are trying to make it so an accidental ops slip at an rpki node will not damage you if it is corrected in reasonable time, if you piss off someone up the validation chain (or worse, if someone up the chain two links pisses someone >2 links up), they can break the validation chain for your certs/roas. randy _______________________________________________ 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Wed Jun 18 06:07:14 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 18 Jun 2008 11:07:14 +0100 Subject: [arin-ppml] Creating a market for IPv4 address space in absenceof routing table entry market In-Reply-To: <1080617162313.449B-100000@Ives.egh.com> Message-ID: > I don't think anyone who advocates a market in address space > thinks that implies ownership of address space. It implies > ownership of the right to use address space (i.e. a license > to use that unique set of integers, in the limited context of > the IPv4 Internet.) If so, then that would be a MAJOR change to the set of rights wich currently come with an ARIN allocation. Currently you have a right to use those integers in devices which support the Internet Protocol version 4. This holds whether or not you connect the set of devices to the Internet or not. If you have a need for uniqueness, you can apply to ARIN and get addresses. Many companies have done so, often to use in VPNs or private internetworks (also called extranets) in which companies connect to their trading partners. --Michael Dillon From michael.dillon at bt.com Wed Jun 18 07:07:21 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 18 Jun 2008 12:07:21 +0100 Subject: [arin-ppml] ARIN apathy Message-ID: In this article about hijacking IPv4 address blocks , the author states that ARIN is in a state of apathy about the whole thing. Is this true? If true, is it right? Should we lobby the ARIN BoT to simply wipe out these "transfers" on the basis of the evidence in that article, in the hopes that it will attract a legal challenge so we can get some stronger case-law support? Or should we lobby the ARIN BoT to charge in and sue this Mulligan fellow first? Or should we just leave it alone and be happy that there is now clear precedent for hijacking addresses? This will go some way to alleviate the IP address shortage that is looming although this doesn't help those who want to hijack 126.0.0.0/8 or 130.0.0.0/8. --Michael Dillon From tvest at pch.net Wed Jun 18 07:17:33 2008 From: tvest at pch.net (Tom Vest) Date: Wed, 18 Jun 2008 07:17:33 -0400 Subject: [arin-ppml] Creating a market for IPv4 address space in absence of routing table entry market In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901884113@SUEXCL-02.ad.syr.edu> References: <20080617133546.GA11590@vacation.karoshi.com.> <1080617162313.449B-100000@Ives.egh.com> <20080618011301.GB16898@vacation.karoshi.com.> <48586395.4020001@psg.com> <7663C7E01D8E094989CA62F0B0D21CD901884113@SUEXCL-02.ad.syr.edu> Message-ID: <971CB52E-E73B-4058-AC92-C1AAC0C511FD@pch.net> Isn't that a bit like worrying about whether or not "Congress is going to screw us"? What can the RIRs do -- what have they ever been -- other than an open forum for collective decision making about the treatment of a common (as in "everybody needs it") critical resource, the treatment of which by a minority or even a single party might affect the value and functioning of the resource and the system it supports for every other user? If you really think that creation of the mechanism itself, and its dependence on a (any) hierarchy with real/potential power is a fatal flaw, then you might also want to consider a proposal to dissolve the RIRs entirely; after all, pro-authority agents might sneak into one of the open policy meetings and pull off a bloodless coup, or over time established community members themselves might develop false consciousness... And finally, do you really imagine that if sovereign authorities elect to start imposing their will on number resources or policy, that they would simply throw up their hands if community-managed certification (or the RIRs themselves) did not exist? I would think that a more plausible explanation for the continued autonomy of this particular sphere is that the other authorities perceive that the current arrangement is working "good enough" (their own internal benchmark I'm told), and doesn't appear to be in imminent danger of melting down, so autonomy looks like a good, stable bet for everyone. It seems to me that if the "good enough" benchmark is shifting, either because the system is more "critical" or the bad guys more capable today, then it would probably be prudent for the community to step up and address that fact, so that no one else is tempted or obliged to. TV On Jun 18, 2008, at 3:41 AM, Milton L Mueller wrote: > Very interested and concerned about the interaction between secure > routing and centralization of authority over what has before now > been a relatively loose system of routing self-governance by ISPs. I > guess I am less worried about IANA and RIRs abusing their authority > over a validation chain than I am about governments or lawsuits that > force them to do so. Think of DNS and the UDRP. > > From: arin-ppml-bounces at arin.net on behalf of Randy Bush > but, to hoist myself on my own petard, are you/folk at all concerned > that, as the rpki becomes used in secure routing, iana and the rirs > will > have affect your prefixes routability far more than they do today? > > while we are trying to make it so an accidental ops slip at an rpki > node > will not damage you if it is corrected in reasonable time, if you piss > off someone up the validation chain (or worse, if someone up the chain > two links pisses someone >2 links up), they can break the validation > chain for your certs/roas. > > randy > _______________________________________________ > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From jcurran at istaff.org Wed Jun 18 07:32:48 2008 From: jcurran at istaff.org (John Curran) Date: Wed, 18 Jun 2008 07:32:48 -0400 Subject: [arin-ppml] Creating a transfer market for IPv4 addresses In-Reply-To: <48584243.8010504@psg.com> References: <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB7AF6@SUEXCL-02.ad.syr.edu> <48584243.8010504@psg.com> Message-ID: At 8:01 AM +0900 6/18/08, Randy Bush wrote: >personally, i believe that the first assumption, market produces >fragmentation, is very weak. it just changes where you get space, not >what you do with it. of course there will be some effect, but nothing >like the crap-think that makes the current routing table over half /24 >rubbish. > >secondly, i am highly suspicious of any amateur regulatory causal chains >this long. we are sooo good at asserting physics that is not yet >demonstrated. hence my inclination to minimal regulatory structure >until we learn more about reality and depend less on amateur guesses. What transfer policy would you propose based on the above beliefs? /John From randy at psg.com Wed Jun 18 07:48:41 2008 From: randy at psg.com (Randy Bush) Date: Wed, 18 Jun 2008 20:48:41 +0900 Subject: [arin-ppml] Creating a transfer market for IPv4 addresses In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901BB79ED@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901BB7AF6@SUEXCL-02.ad.syr.edu> <48584243.8010504@psg.com> Message-ID: <4858F619.7010201@psg.com> >> personally, i believe that the first assumption, market produces >> fragmentation, is very weak. it just changes where you get space, not >> what you do with it. of course there will be some effect, but nothing >> like the crap-think that makes the current routing table over half /24 >> rubbish. >> >> secondly, i am highly suspicious of any amateur regulatory causal chains >> this long. we are sooo good at asserting physics that is not yet >> demonstrated. hence my inclination to minimal regulatory structure >> until we learn more about reality and depend less on amateur guesses. > > What transfer policy would you propose based on the above beliefs? geoff claims to be reworking his proposal to meet the ideas that came in from discussion. and it was fairly simple. probably could have been a bit simpler, but let's see what he does. randy From owen at delong.com Wed Jun 18 09:26:49 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Jun 2008 06:26:49 -0700 Subject: [arin-ppml] Creating a market for IPv4 address space in absenceof routing table entry market In-Reply-To: References: Message-ID: <26E65C57-C5B9-46F0-8476-0BA57BD48755@delong.com> On Jun 18, 2008, at 3:07 AM, wrote: > >> I don't think anyone who advocates a market in address space >> thinks that implies ownership of address space. It implies >> ownership of the right to use address space (i.e. a license >> to use that unique set of integers, in the limited context of >> the IPv4 Internet.) > > If so, then that would be a MAJOR change to the set of rights wich > currently come with an ARIN allocation. Currently you have a right > to use those integers in devices which support the Internet Protocol > version 4. This holds whether or not you connect the set of devices > to the Internet or not. If you have a need for uniqueness, you can > apply to ARIN and get addresses. Many companies have done so, often > to use in VPNs or private internetworks (also called extranets) in > which companies connect to their trading partners. As I understand it, there are no rights conveyed. What you receive is assurance that ARIN, the other cooperating RIRs, and IANA will not register the same set of integers to someone else. This turns out to also have the side-effect that since most ISPs (perhaps even all) cooperate i this same system, those ISPs tend to recognize that you are the legitimate user of those addresses on the IPv4 internet if you choose to use them there. Owen From owen at delong.com Wed Jun 18 10:39:25 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Jun 2008 07:39:25 -0700 Subject: [arin-ppml] Whois Archival Policy? Message-ID: From: http://www.47-usc-230c2.org (Seven weeks ago, during my phone conversation with ARIN officials relating to the SF Bay Packet Radio IP address block, I requested from ARIN a copy of their archived WHOIS record for the 134.17.0.0/16 IP address block, as it existed on any date prior to the formation of Mr. Mulligan's SF Bay Packet Radio, LLC. ARIN declined my request on the basis of their lack of a "policy" under which such archival and formerly publicly available WHOIS data could be provided by ARIN to members of the media or other interested parties.) I'd like to find out from members of the community how they feel about the idea of having such a policy. Should we develop a policy allowing ARIN to release historical WHOIS records? Should there be any restrictions on the circumstances under which ARIN would do so? If so, what should those restrictions be? My initial inclination is that since this is entirely data which was, at one time, publicly available, publishing it again is entirely appropriate. I can even see some valid use cases for a "whois wayback machine", such as wanting to know the history of an address block. In fairness, I have not yet asked ARIN staff about the difficulty of making such data available, so, I don't know whether this is feasible or not. I would, first, like to get a sense from the community of how they feel about development of such a policy. Thanks, Owen DeLong (Note: This is not a communication from the AC, it is my own individual question) -------------- next part -------------- An HTML attachment was scrubbed... URL: From heather.skanks at gmail.com Wed Jun 18 12:15:20 2008 From: heather.skanks at gmail.com (heather skanks) Date: Wed, 18 Jun 2008 12:15:20 -0400 Subject: [arin-ppml] Whois Archival Policy? In-Reply-To: References: Message-ID: <616812070806180915x5c32bf1ck656302a4cd2f2829@mail.gmail.com> On Wed, Jun 18, 2008 at 10:39 AM, Owen DeLong wrote: > From: http://www.47-usc-230c2.org > (Seven weeks ago, during my phone conversation with ARIN officials relating > to the *SF Bay Packet Radio* IP address block, I requested from ARIN a > copy of their archived WHOIS record for the 134.17.0.0/16 IP address > block, as it existed on any date prior to the formation of Mr. Mulligan's > *SF Bay Packet Radio, LLC*. ARIN declined my request on the basis of their > lack of a "policy" under which such archival and formerly publicly available > WHOIS data could be provided by ARIN to members of the media or other > interested parties.) > > > I'd like to find out from members of the community how they feel about the > idea of having such a policy. > Such a policy already exists. NRPM 3.1 http://www.arin.net/policy/nrpm.html#three1 3.1. Bulk Copies of ARIN's WHOIS ARIN will provide a bulk copy of WHOIS output, including point of contact information, on the ARIN site for download by any organization that wishes to obtain the data providing they agree to ARIN's acceptable use policy. This point of contact information will not include data marked as private. [The Request Form for ARIN Bulk WHOIS Data, which contains the Acceptable Use Policy (AUP) for Bulk Copies of ARIN WHOIS Data, can be found at: http://www.arin.net/registration/agreements/bulkwhois.pdf] > > Should we develop a policy allowing ARIN to release historical WHOIS > records? > > Should there be any restrictions on the circumstances under which ARIN > would do so? > > If so, what should those restrictions be? > > My initial inclination is that since this is entirely data which was, at > one time, publicly available, publishing it again is entirely appropriate. I > can even see some valid use cases for a "whois wayback machine", such as > wanting to know the history of an address block. > > In fairness, I have not yet asked ARIN staff about the difficulty of making > such data available, so, I don't know whether this is feasible or not. I > would, first, like to get a sense from the community of how they feel about > development of such a policy. > > Thanks, > > Owen DeLong > > (Note: This is not a communication from the AC, it is my own individual > question) > > > > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleibrand at internap.com Wed Jun 18 11:59:40 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 18 Jun 2008 08:59:40 -0700 Subject: [arin-ppml] Whois Archival Policy? In-Reply-To: References: Message-ID: <485930EC.1040708@internap.com> (As another individual) I would favor making historical whois query answers generally available to the public, just as current whois query answers are. I don't see any need for a special manual process with restrictions, but am of course willing to change my mind if presented with solid arguments that an open query mechanism would be more open to abuse than the current system. -Scott Owen DeLong wrote: > From: http://www.47-usc-230c2.org > > (Seven weeks ago, during my phone conversation with ARIN officials > relating to the /SF Bay Packet Radio/ IP address block, I requested from > ARIN a copy of their archived WHOIS record for the 134.17.0.0/16 IP > address block, as it existed on any date prior to the formation of Mr. > Mulligan's /SF Bay Packet Radio, LLC/. ARIN declined my request on the > basis of their lack of a "policy" under which such archival and formerly > publicly available WHOIS data could be provided by ARIN to members of > the media or other interested parties.) > > > I'd like to find out from members of the community how they feel about > the idea of having such a policy. > > Should we develop a policy allowing ARIN to release historical WHOIS > records? > > Should there be any restrictions on the circumstances under which ARIN > would do so? > > If so, what should those restrictions be? > > My initial inclination is that since this is entirely data which was, at > one time, publicly available, publishing it again is entirely > appropriate. I can even see some valid use cases for a "whois wayback > machine", such as wanting to know the history of an address block. > > In fairness, I have not yet asked ARIN staff about the difficulty of > making such data available, so, I don't know whether this is feasible or > not. I would, first, like to get a sense from the community of how they > feel about development of such a policy. > > Thanks, > > Owen DeLong > > (Note: This is not a communication from the AC, it is my own individual > question) > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From sleibrand at internap.com Wed Jun 18 12:18:19 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 18 Jun 2008 09:18:19 -0700 Subject: [arin-ppml] Whois Archival Policy? In-Reply-To: <616812070806180915x5c32bf1ck656302a4cd2f2829@mail.gmail.com> References: <616812070806180915x5c32bf1ck656302a4cd2f2829@mail.gmail.com> Message-ID: <4859354B.4010405@internap.com> I don't see anything in there about historical data: AFAICT that's just talking about a bulk copy of all current whois data... -Scott heather skanks wrote: > > > On Wed, Jun 18, 2008 at 10:39 AM, Owen DeLong > wrote: > > From: http://www.47-usc-230c2.org > > (Seven weeks ago, during my phone conversation with ARIN officials > relating to the /SF Bay Packet Radio/ IP address block, I requested > from ARIN a copy of their archived WHOIS record for the > 134.17.0.0/16 IP address block, as it existed > on any date prior to the formation of Mr. Mulligan's /SF Bay Packet > Radio, LLC/. ARIN declined my request on the basis of their lack of > a "policy" under which such archival and formerly publicly available > WHOIS data could be provided by ARIN to members of the media or > other interested parties.) > > > I'd like to find out from members of the community how they feel > about the idea of having such a policy. > > > Such a policy already exists. NRPM 3.1 > > http://www.arin.net/policy/nrpm.html#three1 > > > 3.1. Bulk Copies of ARIN's WHOIS > > ARIN will provide a bulk copy of WHOIS output, including point of > contact information, on the ARIN site for download by any organization > that wishes to obtain the data providing they agree to ARIN's acceptable > use policy. This point of contact information will not include data > marked as private. > > [The Request Form for ARIN Bulk WHOIS Data, which contains the > Acceptable Use Policy (AUP) for Bulk Copies of ARIN WHOIS Data, can be > found at: > > http://www.arin.net/registration/agreements/bulkwhois.pdf] > > > > > > Should we develop a policy allowing ARIN to release historical WHOIS > records? > > > Should there be any restrictions on the circumstances under which > ARIN would do so? > > If so, what should those restrictions be? > > My initial inclination is that since this is entirely data which > was, at one time, publicly available, publishing it again is > entirely appropriate. I can even see some valid use cases for a > "whois wayback machine", such as wanting to know the history of an > address block. > > In fairness, I have not yet asked ARIN staff about the difficulty of > making such data available, so, I don't know whether this is > feasible or not. I would, first, like to get a sense from the > community of how they feel about development of such a policy. > > Thanks, > > Owen DeLong > > (Note: This is not a communication from the AC, it is my own > individual question) > > > > _______________________________________________ > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From dlw+arin at tellme.com Wed Jun 18 12:24:45 2008 From: dlw+arin at tellme.com (David Williamson) Date: Wed, 18 Jun 2008 09:24:45 -0700 Subject: [arin-ppml] Whois Archival Policy? In-Reply-To: <616812070806180915x5c32bf1ck656302a4cd2f2829@mail.gmail.com> References: <616812070806180915x5c32bf1ck656302a4cd2f2829@mail.gmail.com> Message-ID: <20080618162445.GJ21527@shell01.cell.sv2.tellme.com> On Wed, Jun 18, 2008 at 12:15:20PM -0400, heather skanks wrote: > On Wed, Jun 18, 2008 at 10:39 AM, Owen DeLong wrote: > > > From: http://www.47-usc-230c2.org > > (Seven weeks ago, during my phone conversation with ARIN officials relating > > to the *SF Bay Packet Radio* IP address block, I requested from ARIN a > > copy of their archived WHOIS record for the 134.17.0.0/16 IP address > > block, as it existed on any date prior to the formation of Mr. Mulligan's > > *SF Bay Packet Radio, LLC*. ARIN declined my request on the basis of their > > lack of a "policy" under which such archival and formerly publicly available > > WHOIS data could be provided by ARIN to members of the media or other > > interested parties.) > > > > > > I'd like to find out from members of the community how they feel about the > > idea of having such a policy. > > > > Such a policy already exists. NRPM 3.1 It's ambiguous. There is a bulk whois policy, but, lacking any specific verbiage, it would seem to permit bulk whois queries for *current* data only. I think Owen wants to know the state of a whois record from, for example, 1999. In this case, it's not the number of queries that is interesting (which is what 3.1 tries to address, I think), but the date. I'd be in favor of access to a wayback machine, although I have no idea of how technically difficult it would be to provide such a service. Actually, upon some reflection, it sounds fairly hard. The same rules should apply: normal query rates (one or two at a time) would be permitted, bulk transfers would fall under 3.1. Ideally, whois would provide this as part of the protocol, but the majority of clients probably lack any way to specify a date string. :) -David From JOHN at egh.com Wed Jun 18 12:43:09 2008 From: JOHN at egh.com (John Santos) Date: Wed, 18 Jun 2008 12:43:09 -0400 Subject: [arin-ppml] Creating a market for IPv4 address space in absenceof routing table entry market In-Reply-To: Message-ID: <1080618122759.449A-100000@Ives.egh.com> On Wed, 18 Jun 2008 michael.dillon at bt.com wrote: > > > I don't think anyone who advocates a market in address space > > thinks that implies ownership of address space. It implies > > ownership of the right to use address space (i.e. a license > > to use that unique set of integers, in the limited context of > > the IPv4 Internet.) > > If so, then that would be a MAJOR change to the set of rights wich > currently come with an ARIN allocation. Currently you have a right > to use those integers in devices which support the Internet Protocol > version 4. This holds whether or not you connect the set of devices > to the Internet or not. If you have a need for uniqueness, you can > apply to ARIN and get addresses. Many companies have done so, often > to use in VPNs or private internetworks (also called extranets) in > which companies connect to their trading partners. No, this is no change at all to the rights that come with an ARIN allocation. If I am building my own IPv4 network that is not connected to the Internet, I can use any set of addresses I want. I do *not* need ARIN's (or anyone else's) permission to do this. I do not have any guarantee of uniqueness, but if I'm not connected to the Internet, I don't care. Also, if I want to use 32-bit numbers for any purpose not related to IP or specifically IPv4, ARIN's supplied 32-bit numbers are of absolutely no relevence. If you have been supplied the *same* 32-bit IPv4 addesses by ARIN that I've used in my own completely non-connected network, you have have no right to prevent me from doing so. The rights granted by ARIN in conjunction with an IPv4 address apply only to the use of that address on the Internet, and not to that number in any other context. This has always been true. It is *not* a change. > > --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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From steve at blighty.com Wed Jun 18 12:38:12 2008 From: steve at blighty.com (Steve Atkins) Date: Wed, 18 Jun 2008 09:38:12 -0700 Subject: [arin-ppml] Whois Archival Policy? In-Reply-To: <20080618162445.GJ21527@shell01.cell.sv2.tellme.com> References: <616812070806180915x5c32bf1ck656302a4cd2f2829@mail.gmail.com> <20080618162445.GJ21527@shell01.cell.sv2.tellme.com> Message-ID: On Jun 18, 2008, at 9:24 AM, David Williamson wrote: > > > I'd be in favor of access to a wayback machine, although I have no > idea > of how technically difficult it would be to provide such a service. > Actually, upon some reflection, it sounds fairly hard. The same rules > should apply: normal query rates (one or two at a time) would be > permitted, bulk transfers would fall under 3.1. Ideally, whois would > provide this as part of the protocol, but the majority of clients > probably lack any way to specify a date string. :) Implementing it as a webapp wouldn't be too difficult, given access to archived bulk data or transaction logs, and using ongoing access to current bulk data to keep it updated (and I'd certainly find the information useful). I'm not sure it's something ARIN staff should necessarily expend much effort on, though, unless it's something they actively want to support. Cheers, Steve From reid at mejac.palo-alto.ca.us Wed Jun 18 12:40:11 2008 From: reid at mejac.palo-alto.ca.us (Brian Reid) Date: Wed, 18 Jun 2008 09:40:11 -0700 Subject: [arin-ppml] Whois Archival Policy? In-Reply-To: References: Message-ID: <537FCAA4F26052AC9737A5C6@hindolveston.reid.org> Geoff Mulligan used to work for me 10 years ago. I'll say that the allegations about his activities do not surprise me in the least. Surely some private enterprise keeps historical IP registration data the way DomainTools does for names? From farmer at umn.edu Wed Jun 18 13:02:54 2008 From: farmer at umn.edu (David Farmer) Date: Wed, 18 Jun 2008 12:02:54 -0500 Subject: [arin-ppml] Whois Archival Policy? In-Reply-To: <485930EC.1040708@internap.com> References: , <485930EC.1040708@internap.com> Message-ID: <4858F96E.20471.3AC30F7@farmer.umn.edu> Given that we are talking about historical data, it is entirely possible that the information is not readily available and my require some research and searching of historical records in order to compile the requested information, especially in the case of legacy registrations that pre-date ARIN. I would therefore, suggest that a policy regarding historical data, include a clause requiring the requester to pay for any necessary staff time needed for research or data collection activities required to compile the requested information. This type of clause is usually include in most open records laws. Basically, your entitled to the information, but you are not entitled to the staff time necessary to compile the information, if it is not readily available. While I agree NRPM 3.1 is ambiguous about historical data, I agree with Scott, and don't think that was its intended purpose. However, I believe with some minor rewording the AUP could be used for Historical Data too. Additionally, any information not considered public when it was current should not be public once it is historical information. Generally, I support the idea of open records including historical ones, it is good policy for organizations like ARIN with a public trust. On 18 Jun 2008 Scott Leibrand wrote: > (As another individual) I would favor making historical whois query > answers generally available to the public, just as current whois > query > answers are. I don't see any need for a special manual process with > restrictions, but am of course willing to change my mind if > presented > with solid arguments that an open query mechanism would be more open > to > abuse than the current system. > > -Scott > > Owen DeLong wrote: > > From: http://www.47-usc-230c2.org > > > > (Seven weeks ago, during my phone conversation with ARIN officials > > relating to the /SF Bay Packet Radio/ IP address block, I > requested from > > ARIN a copy of their archived WHOIS record for the 134.17.0.0/16 > IP > > address block, as it existed on any date prior to the formation of > Mr. > > Mulligan's /SF Bay Packet Radio, LLC/. ARIN declined my request on > the > > basis of their lack of a "policy" under which such archival and > formerly > > publicly available WHOIS data could be provided by ARIN to members > of > > the media or other interested parties.) > > > > > > I'd like to find out from members of the community how they feel > about > > the idea of having such a policy. > > > > Should we develop a policy allowing ARIN to release historical > WHOIS > > records? > > > > Should there be any restrictions on the circumstances under which > ARIN > > would do so? > > > > If so, what should those restrictions be? > > > > My initial inclination is that since this is entirely data which > was, at > > one time, publicly available, publishing it again is entirely > > appropriate. I can even see some valid use cases for a "whois > wayback > > machine", such as wanting to know the history of an address > block. > > > > In fairness, I have not yet asked ARIN staff about the difficulty > of > > making such data available, so, I don't know whether this is > feasible or > > not. I would, first, like to get a sense from the community of how > they > > feel about development of such a policy. > > > > Thanks, > > > > Owen DeLong > > > > (Note: This is not a communication from the AC, it is my own > individual > > question) > > > > > > > > > -------------------------------------------------------------------- > ---- > > > > _______________________________________________ > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. ================================================= David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ================================================= From owen at delong.com Wed Jun 18 13:53:34 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Jun 2008 10:53:34 -0700 Subject: [arin-ppml] Whois Archival Policy? In-Reply-To: <4859354B.4010405@internap.com> References: <616812070806180915x5c32bf1ck656302a4cd2f2829@mail.gmail.com> <4859354B.4010405@internap.com> Message-ID: <4BA5355D-E1AB-4C99-A726-D4C5413F18EC@delong.com> That is correct. Owen On Jun 18, 2008, at 9:18 AM, Scott Leibrand wrote: > I don't see anything in there about historical data: AFAICT that's > just talking about a bulk copy of all current whois data... > > -Scott > > heather skanks wrote: >> On Wed, Jun 18, 2008 at 10:39 AM, Owen DeLong > >> wrote: >> From: http://www.47-usc-230c2.org >> (Seven weeks ago, during my phone conversation with ARIN officials >> relating to the /SF Bay Packet Radio/ IP address block, I >> requested >> from ARIN a copy of their archived WHOIS record for the >> 134.17.0.0/16 IP address block, as it >> existed >> on any date prior to the formation of Mr. Mulligan's /SF Bay >> Packet >> Radio, LLC/. ARIN declined my request on the basis of their lack >> of >> a "policy" under which such archival and formerly publicly >> available >> WHOIS data could be provided by ARIN to members of the media or >> other interested parties.) I'd like to find out from members >> of the community how they feel >> about the idea of having such a policy. >> Such a policy already exists. NRPM 3.1 >> http://www.arin.net/policy/nrpm.html#three1 >> 3.1. Bulk Copies of ARIN's WHOIS >> ARIN will provide a bulk copy of WHOIS output, including point of >> contact information, on the ARIN site for download by any >> organization that wishes to obtain the data providing they agree to >> ARIN's acceptable use policy. This point of contact information >> will not include data marked as private. >> [The Request Form for ARIN Bulk WHOIS Data, which contains the >> Acceptable Use Policy (AUP) for Bulk Copies of ARIN WHOIS Data, can >> be found at: >> http://www.arin.net/registration/agreements/bulkwhois.pdf] >> Should we develop a policy allowing ARIN to release historical >> WHOIS >> records? Should there be any restrictions on the >> circumstances under which >> ARIN would do so? >> If so, what should those restrictions be? >> My initial inclination is that since this is entirely data which >> was, at one time, publicly available, publishing it again is >> entirely appropriate. I can even see some valid use cases for a >> "whois wayback machine", such as wanting to know the history of an >> address block. >> In fairness, I have not yet asked ARIN staff about the >> difficulty of >> making such data available, so, I don't know whether this is >> feasible or not. I would, first, like to get a sense from the >> community of how they feel about development of such a policy. >> Thanks, >> Owen DeLong >> (Note: This is not a communication from the AC, it is my own >> individual question) >> _______________________________________________ >> 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net >> if you experience any issues. From farmer at umn.edu Wed Jun 18 13:02:57 2008 From: farmer at umn.edu (David Farmer) Date: Wed, 18 Jun 2008 12:02:57 -0500 Subject: [arin-ppml] Whois Archival Policy? Message-ID: Given that we are talking about historical data, it is entirely possible that the information is not readily available and my require some research and searching of historical records in order to compile the requested information, especially in the case of legacy registrations that pre-date ARIN. I would therefore, suggest that a policy regarding historical data, include a clause requiring the requester to pay for any necessary staff time needed for research or data collection activities required to compile the requested information. This type of clause is usually include in most open records laws. Basically, your entitled to the information, but you are not entitled to the staff time necessary to compile the information, if it is not readily available. While I agree NRPM 3.1 is ambiguous about historical data, I agree with Scott, and don't think that was its intended purpose. However, I believe with some minor rewording the AUP could be used for Historical Data too. Additionally, any information not considered public when it was current should not be public once it is historical information. Generally, I support the idea of open records including historical ones, it is good policy for organizations like ARIN with a public trust. On 18 Jun 2008 Scott Leibrand wrote: > (As another individual) I would favor making historical whois query > answers generally available to the public, just as current whois > query > answers are. I don't see any need for a special manual process with > restrictions, but am of course willing to change my mind if > presented > with solid arguments that an open query mechanism would be more open > to > abuse than the current system. > > -Scott > > Owen DeLong wrote: > > From: http://www.47-usc-230c2.org > > > > (Seven weeks ago, during my phone conversation with ARIN officials > > relating to the /SF Bay Packet Radio/ IP address block, I > requested from > > ARIN a copy of their archived WHOIS record for the 134.17.0.0/16 > IP > > address block, as it existed on any date prior to the formation of > Mr. > > Mulligan's /SF Bay Packet Radio, LLC/. ARIN declined my request on > the > > basis of their lack of a "policy" under which such archival and > formerly > > publicly available WHOIS data could be provided by ARIN to members > of > > the media or other interested parties.) > > > > > > I'd like to find out from members of the community how they feel > about > > the idea of having such a policy. > > > > Should we develop a policy allowing ARIN to release historical > WHOIS > > records? > > > > Should there be any restrictions on the circumstances under which > ARIN > > would do so? > > > > If so, what should those restrictions be? > > > > My initial inclination is that since this is entirely data which > was, at > > one time, publicly available, publishing it again is entirely > > appropriate. I can even see some valid use cases for a "whois > wayback > > machine", such as wanting to know the history of an address > block. > > > > In fairness, I have not yet asked ARIN staff about the difficulty > of > > making such data available, so, I don't know whether this is > feasible or > > not. I would, first, like to get a sense from the community of how > they > > feel about development of such a policy. > > > > Thanks, > > > > Owen DeLong > > > > (Note: This is not a communication from the AC, it is my own > individual > > question) > > > > > > > > > -------------------------------------------------------------------- > ---- > > > > _______________________________________________ > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From davids at webmaster.com Wed Jun 18 14:26:20 2008 From: davids at webmaster.com (David Schwartz) Date: Wed, 18 Jun 2008 11:26:20 -0700 Subject: [arin-ppml] Creating a market for IPv4 address space inabsenceof routing table entry market In-Reply-To: Message-ID: > > I don't think anyone who advocates a market in address space > > thinks that implies ownership of address space. It implies > > ownership of the right to use address space (i.e. a license > > to use that unique set of integers, in the limited context of > > the IPv4 Internet.) > If so, then that would be a MAJOR change to the set of rights wich > currently come with an ARIN allocation. Currently you have a right > to use those integers in devices which support the Internet Protocol > version 4. This holds whether or not you connect the set of devices > to the Internet or not. If you have a need for uniqueness, you can > apply to ARIN and get addresses. Many companies have done so, often > to use in VPNs or private internetworks (also called extranets) in > which companies connect to their trading partners. > > --Michael Dillon Your response is a non sequiter. He said that A implies B. You replied that would be a major change because we have always felt that C was also true. However, there is no inconsistency between B and C. In fact, C is independent of B. Perhaps you took his "A implies only B" to mean that he was claiming your particular superset of B was false. But he did no such thing. He simply said it wasn't implied by A. However, that takes no position on its truth or falsity. In this case: A = A market for address space B = Ownership of a right to use address space only on the Internet C = Assignment includes right to use address space in non-Internet contexts In case it's not clear, he argued that a market in address space implies that you can own the right to use address space in the limited context of the IPv4 Internet (A implies or requires just B). He said nothing about use of address space in any other context. He didn't say you couldn't get it or didn't have it, he just said that only ownership of a right to use in the limited context of the Internet is required for a market in address space. And, in fact, when someone wants to "buy IP addresses", what they want is the exclusive right to use those IP addresses on the public Internet. If this right can be had and transferred, then there can be a market in address space. DS From michael at rancid.berkeley.edu Wed Jun 18 14:22:27 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Wed, 18 Jun 2008 11:22:27 -0700 Subject: [arin-ppml] Whois Archival Policy? In-Reply-To: References: Message-ID: <48595263.9060702@rancid.berkeley.edu> Owen DeLong wrote: > From: http://www.47-usc-230c2.org > > (Seven weeks ago, during my phone conversation with ARIN officials > relating to the /SF Bay Packet Radio/ IP address block, I requested from > ARIN a copy of their archived WHOIS record for the 134.17.0.0/16 IP > address block, as it existed on any date prior to the formation of Mr. > Mulligan's /SF Bay Packet Radio, LLC/. ARIN declined my request on the > basis of their lack of a "policy" under which such archival and formerly > publicly available WHOIS data could be provided by ARIN to members of > the media or other interested parties.) > > > I'd like to find out from members of the community how they feel about > the idea of having such a policy. > > Should we develop a policy allowing ARIN to release historical WHOIS > records? Yes. > Should there be any restrictions on the circumstances under which ARIN > would do so? > > If so, what should those restrictions be? One thing would be feasible access to the information, and, as Dave Farmer pointed out (and you mention below), staff time. However, those details can be worked out as the policy process progresses. Technical means for preserving the information for everyone can be worked out by ARIN staff. > My initial inclination is that since this is entirely data which was, at > one time, publicly available, publishing it again is entirely > appropriate. I can even see some valid use cases for a "whois wayback > machine", such as wanting to know the history of an address block. Even more so, because the data was once public, anyone could archive it by making repeated copies of bulk whois under current ARIN policy. They could also modify the archival data to suit their own agenda. Having an official ARIN archive helps to ensure the integrity of the archival data. > In fairness, I have not yet asked ARIN staff about the difficulty of > making such data available, so, I don't know whether this is feasible or > not. I would, first, like to get a sense from the community of how they > feel about development of such a policy. I think, given recent events, it's worth moving forward so that we can at least see how messy it gets. michael From JOHN at egh.com Wed Jun 18 14:54:24 2008 From: JOHN at egh.com (John Santos) Date: Wed, 18 Jun 2008 14:54:24 -0400 Subject: [arin-ppml] Creating a market for IPv4 address space inabsenceof routing table entry market In-Reply-To: Message-ID: <1080618143934.449C-100000@Ives.egh.com> On Wed, 18 Jun 2008, David Schwartz wrote: > > > > I don't think anyone who advocates a market in address space > > > thinks that implies ownership of address space. It implies > > > ownership of the right to use address space (i.e. a license > > > to use that unique set of integers, in the limited context of > > > the IPv4 Internet.) > > > If so, then that would be a MAJOR change to the set of rights wich > > currently come with an ARIN allocation. Currently you have a right > > to use those integers in devices which support the Internet Protocol > > version 4. This holds whether or not you connect the set of devices > > to the Internet or not. If you have a need for uniqueness, you can > > apply to ARIN and get addresses. Many companies have done so, often > > to use in VPNs or private internetworks (also called extranets) in > > which companies connect to their trading partners. > > > > --Michael Dillon > > Your response is a non sequiter. He said that A implies B. You replied that > would be a major change because we have always felt that C was also true. > However, there is no inconsistency between B and C. In fact, C is > independent of B. > > Perhaps you took his "A implies only B" to mean that he was claiming your > particular superset of B was false. But he did no such thing. He simply said > it wasn't implied by A. However, that takes no position on its truth or > falsity. > > In this case: > > A = A market for address space > B = Ownership of a right to use address space only on the Internet > C = Assignment includes right to use address space in non-Internet contexts > > In case it's not clear, he argued that a market in address space implies > that you can own the right to use address space in the limited context of > the IPv4 Internet (A implies or requires just B). He said nothing about use > of address space in any other context. He didn't say you couldn't get it or > didn't have it, he just said that only ownership of a right to use in the > limited context of the Internet is required for a market in address space. > > And, in fact, when someone wants to "buy IP addresses", what they want is > the exclusive right to use those IP addresses on the public Internet. If > this right can be had and transferred, then there can be a market in address > space. > > DS That's what I meant in my followup, if it was a little incoherent. Someone else has mail me privately (not sure if it is okay to quote him directly) that the dispute with my original statement is not that the rights go beyond what I said, but that there are any rights at all at stake. He said there are not, but there is an explicit guarantee of uniqueness. I claim that if this guarantee has any meaning, then it implies a right. Otherwise it is no guarantee at all. Maybe the dispute is over the meaning of the word "right" or license. Or maybe Micheal is claiming that there is a broader right than I posited, and my other correspondent is claiming narrower rights. As for extranets, ARIN doesn't grant you the right to use the allocated (or assigned) addresses in a non-Internet context, you already have the right to use *any* addresses you and your trading partners agree to. All that ARIN provides in this context is a convenient allocation scheme. However, a typical Internet user does not have any explicit contract or agreement with the vast majority of other Internet users, so the RIR guarantee of uniqueness and exclusivity matters. > > > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From owen at delong.com Wed Jun 18 15:23:53 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Jun 2008 12:23:53 -0700 Subject: [arin-ppml] Creating a market for IPv4 address space inabsenceof routing table entry market In-Reply-To: <1080618143934.449C-100000@Ives.egh.com> References: <1080618143934.449C-100000@Ives.egh.com> Message-ID: <61D3A97F-AA68-4D50-B52B-FD38A286F31F@delong.com> > That's what I meant in my followup, if it was a little incoherent. > > Someone else has mail me privately (not sure if it is okay to quote > him directly) that the dispute with my original statement is not that > the rights go beyond what I said, but that there are any rights at > all at stake. He said there are not, but there is an explicit > guarantee of uniqueness. I claim that if this guarantee has any > meaning, then it implies a right. Otherwise it is no guarantee > at all. Maybe the dispute is over the meaning of the word "right" > or license. Or maybe Micheal is claiming that there is a broader > right than I posited, and my other correspondent is claiming > narrower rights. > Yes, if you still feel it necessary, you may quote me in public. However, my intent was to point out that ARIN is not conveying any rights. I made no statement about what rights may or may not exist. I merely stated that ARIN does exactly this: ARIN guarantees you that ARIN will not issue the same addresses to another party while you maintain your account in good standing with ARIN and your resources have not been reclaimed for other reasons. You are also reasonably assured that the other RIRs and the IANA will not issue the same addresses to someone else. This does not convey any rights with respect to the internet or any organization outside of ARIN. It's just a contract between you and ARIN. Nothing more. The fact that most (if not all) ISPs agree and cooperate with ARIN and the other RIRs as authoritative registries for uniqueness is what makes the internet possible and keeps it working. However, if ISPs choose to believe someone else besides ARIN and let them route addresses ARIN assigned to you, there's not really any right on the part of ARIN to do anything about that. Nor will any government likely listen to you about ARIN having conveyed such a right to you. Owen From davids at webmaster.com Wed Jun 18 16:40:28 2008 From: davids at webmaster.com (David Schwartz) Date: Wed, 18 Jun 2008 13:40:28 -0700 Subject: [arin-ppml] Creating a market for IPv4 address space inabsenceof routing table entry market In-Reply-To: <61D3A97F-AA68-4D50-B52B-FD38A286F31F@delong.com> Message-ID: > Yes, if you still feel it necessary, you may quote me in public. > > However, my intent was to point out that ARIN is not conveying > any rights. I made no statement about what rights may or may > not exist. I merely stated that ARIN does exactly this: > > ARIN guarantees you that ARIN will not issue the same addresses > to another party while you maintain your account in good standing > with ARIN and your resources have not been reclaimed for other > reasons. > > You are also reasonably assured that the other RIRs and the IANA > will not issue the same addresses to someone else. > > This does not convey any rights with respect to the internet or any > organization outside of ARIN. It's just a contract between you > and ARIN. Nothing more. > > The fact that most (if not all) ISPs agree and cooperate with ARIN > and the other RIRs as authoritative registries for uniqueness > is what makes the internet possible and keeps it working. However, > if ISPs choose to believe someone else besides ARIN and let them > route addresses ARIN assigned to you, there's not really any > right on the part of ARIN to do anything about that. Nor will > any government likely listen to you about ARIN having conveyed > such a right to you. This may be a convenient legal fiction, but to actually believe this, you would have to believe that ARIN is not responsible for the predictable consequences of its actions based on other people's rational actions. ARIN knows that its unique delegations are the gateways to Internet routability, and that this is so for good and rational reasons. It makes its decisions with this knowledge and cannot say it is not responsible for the results because it does not directly control those gateways. This would be like a credit-reporting agency saying that it has no responsibility for denials of credit rationally made on the basis of its ratings because it wasn't the entity that denied the credit. That's absurd. DS From mysidia at gmail.com Wed Jun 18 19:55:56 2008 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 18 Jun 2008 18:55:56 -0500 Subject: [arin-ppml] Whois Archival Policy? In-Reply-To: <4859354B.4010405@internap.com> References: <616812070806180915x5c32bf1ck656302a4cd2f2829@mail.gmail.com> <4859354B.4010405@internap.com> Message-ID: <4859A08C.3090005@gmail.com> The policy doesn't currently say "bulk copies of all current whois data" It says "Bulk copies of WHOIS output" If ARIN _does_ maintain an archive of historical WHOIS data; I would expect all the non-private data from that archive to be available under this policy, even the entire archive (detailing every single WHOIS record to ever exist, and change-by-change, every revision ever made to every record, and the date every change was made on) But nothing about this policy says that ARIN will preserve past versions of WHOIS records or historical information in the first place. I think ARIN should perhaps have a policy that every record will be versioned and every version of every record to ever exist be retained in a historical archive. It may very well be the case that ARIN doesn't have the historical information. ARIN may not have the resources to commit to archiving old WHOIS information, without a policy saying it should be done. Or possibly the historical data is known, but not in a WHOIS-friendly format. Also, sorting through historical data for records pertaining to a specific org or specific range is not something you can get with "Bulk request" as the policy is right now, "Bulk request" means all records; if you want to filter out records that meet certain criteria, you do that yourself, after downloading the _entire_ file from ARIN's website. I believe that answering any request for bulk data may have a substantial cost -- use of ARIN server resources and bandwidth to provide the bulk data to the requestor, or DVD-Rs to record the data on, in addition to the staff time involved. There is also the portion of the cost of preserving the bulk data, divided by the total number of requests (the requestor's share of the long-term infrastructure costs involved in ARIN being able to actually service their request). Preserving the information may be a useful service to the public. I believe it should be done. But when an organization makes a request for bulk data, that organization should be required to pay in advance, the cost of handling the specific request, AND a share of the storage costs for the historical data they retrieve. Possibly with an appropriate discount if the requestor of bulk data is an ARIN member in good standing. Not a high price -- but something sufficient to avoid frivolous requests for terabytes of WHOIS data. -- -J Scott Leibrand wrote: > I don't see anything in there about historical data: AFAICT that's just > talking about a bulk copy of all current whois data... > > -Scott > > heather skanks wrote: >> Such a policy already exists. NRPM 3.1 >> >> http://www.arin.net/policy/nrpm.html#three1 >> >> >> 3.1. Bulk Copies of ARIN's WHOIS >> >> ARIN will provide a bulk copy of WHOIS output, including point of >> contact information, on the ARIN site for download by any organization >> that wishes to obtain the data providing they agree to ARIN's acceptable >> use policy. This point of contact information will not include data >> marked as private. >> >> [The Request Form for ARIN Bulk WHOIS Data, which contains the >> Acceptable Use Policy (AUP) for Bulk Copies of ARIN WHOIS Data, can be >> found at: >> >> http://www.arin.net/registration/agreements/bulkwhois.pdf] >> From jabley at ca.afilias.info Wed Jun 18 22:01:52 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Wed, 18 Jun 2008 22:01:52 -0400 Subject: [arin-ppml] Whois Archival Policy? In-Reply-To: References: <616812070806180915x5c32bf1ck656302a4cd2f2829@mail.gmail.com> <20080618162445.GJ21527@shell01.cell.sv2.tellme.com> Message-ID: On 18 Jun 2008, at 12:38, Steve Atkins wrote: > Implementing it as a webapp wouldn't be too difficult, given access to > archived bulk data or transaction logs, and using ongoing access to > current bulk data to keep it updated (and I'd certainly find the > information useful). Since in my personal experience it's far harder to come up with a name for something than to implement it, I offer the following short-cut. When we were working on OpenReg at ISC to support the ISC/IMS bid for the ORG registry, we discussed an ambition to provide a "whowas" service which would provide historical information about registry records. I am not aware of any real prospect of a whois-like interface for historical registry data ever being made available in any domain registry today. However, if the word "whowas" could feature in an analogous service at some other type of registry, it would make me curiously happy. For what that's worth. :-) Joe From bill at herrin.us Wed Jun 18 23:52:44 2008 From: bill at herrin.us (William Herrin) Date: Wed, 18 Jun 2008 23:52:44 -0400 Subject: [arin-ppml] Whois Archival Policy? In-Reply-To: References: Message-ID: <3c3e3fca0806182052x2c350586g49aea7631d3360c9@mail.gmail.com> On Wed, Jun 18, 2008 at 10:39 AM, Owen DeLong wrote: > I'd like to find out from members of the community how they feel about the > idea of having such a policy. > Should we develop a policy allowing ARIN to release historical WHOIS > records? Owen, I see one potential difficulty: Many (most?) of the legacy registrations were pretty haphazard. Having the ability to identify components of prior registration details may be the only way an original registrant can establish his bona fides in a dispute. If the data is intentionally published, the data goes from being marginally usable for authentication to being unusable for authentication. Here's a question: If you're the original legacy registrant but your email address, phone number and postal address have changed, how exactly do you establish your bona-fides to ARIN in order to make a change now? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From heather.skanks at gmail.com Thu Jun 19 00:24:34 2008 From: heather.skanks at gmail.com (heather skanks) Date: Thu, 19 Jun 2008 00:24:34 -0400 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In-Reply-To: <4849fa12.55.432b.32511@batelnet.bs> References: <4849fa12.55.432b.32511@batelnet.bs> Message-ID: <616812070806182124w101e5ac6yc86ef348c6e1455f@mail.gmail.com> On Fri, Jun 6, 2008 at 11:01 PM, Martin Hannigan < martin.hannigan at batelnet.bs> wrote: > > > > > > Rationale: > > > > Currently anyone who has an experimental block is required > > to re-justify his or her use after just one year. > > Sorry for 3 messages in 24 hours. :-) > > How much space is currently allocated under this policy? > > -M< > NRPM 11.7 Resource Allocation Size ... The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, their experimental documentation should have clearly described and justified why this is required. --h > > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heather.skanks at gmail.com Thu Jun 19 00:34:32 2008 From: heather.skanks at gmail.com (heather skanks) Date: Thu, 19 Jun 2008 00:34:32 -0400 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In-Reply-To: <4847F8EF.5070709@arin.net> References: <4847F8EF.5070709@arin.net> Message-ID: <616812070806182134s3fab1fe6ub6f1c9dcf96089bc@mail.gmail.com> Is the argument that renewing an experimental allocation every year is a hardship? Would anyone care to post about their experiences with an experimental allocation and the renewal process? The rationale statement says, "Reality shows that any true experiment in technical nature that addresses the internet architecture and routing will take at least two years given the constraints of time and the simple fact of working out what could be a bug in the theory and not a show stopper. " Can the authors or someone on list, give a current example of a "true experiment in technical nature that addresses the internet architecture and routing" that is adversely affected by the 1 year renewal requirement? On Thu, Jun 5, 2008 at 10:32 AM, Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts the proposal, > it will be posted as a formal policy proposal to PPML and it will be > presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision via the PPML. If a proposal is not > accepted, then the author may elect to use the petition process to > advance their proposal. If the author elects not to petition or the > petition fails, then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this 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. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Extend Experimental Renewal Timeframe > > Author: Azinger and Dave Meyer > > Proposal Version: 1 > > Submission Date: 4 June 2008 > > Proposal type: Modify > > Policy term: Permanent > > Policy statement: > > This proposal is to modify section 11.4 in the Policy Manual to extend > the experimental timeframe from one year to two years before having to > re-justify the use of an experimental block. > > Rationale: > > Currently anyone who has an experimental block is required to re-justify > his or her use after just one year. Reality shows that any true > experiment in technical nature that addresses the internet architecture > and routing will take at least two years given the constraints of time > and the simple fact of working out what could be a bug in the theory and > not a show stopper. This proposal just wishes to extend the timeframe > one year so that time isn't wasted on re-justification. > > The revision of 11.4 would read as follows: > > The Numbering Resources are allocated on a lease/license basis for a > period of two years. The allocation can be renewed on application to > ARIN providing information as per Detail One. The identity and details > of the applicant and the allocated Numbering Resources will be published > under the conditions of ARIN's normal publication policy. At the end of > the experiment, resources allocated under this policy will be returned > to the available pool. > > Timetable for implementation: Immediate > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at boku.net Thu Jun 19 00:28:35 2008 From: peter at boku.net (Peter Eisch) Date: Wed, 18 Jun 2008 23:28:35 -0500 Subject: [arin-ppml] Whois Archival Policy? In-Reply-To: <3c3e3fca0806182052x2c350586g49aea7631d3360c9@mail.gmail.com> References: <3c3e3fca0806182052x2c350586g49aea7631d3360c9@mail.gmail.com> Message-ID: <020d01c8d1c4$f106d090$d31471b0$@net> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of William Herrin > Sent: Wednesday, June 18, 2008 10:53 PM > To: Owen DeLong > Cc: PPML ppml > Subject: Re: [arin-ppml] Whois Archival Policy? > > On Wed, Jun 18, 2008 at 10:39 AM, Owen DeLong wrote: > > I'd like to find out from members of the community how they feel > about the > > idea of having such a policy. > > Should we develop a policy allowing ARIN to release historical WHOIS > > records? > ... > Here's a question: > > If you're the original legacy registrant but your email address, phone > number and postal address have changed, how exactly do you establish > your bona-fides to ARIN in order to make a change now? > If you're advertising a route for your assignment, this should be trivial to establish/verify identity. peter From randy at psg.com Thu Jun 19 01:15:47 2008 From: randy at psg.com (Randy Bush) Date: Thu, 19 Jun 2008 14:15:47 +0900 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In-Reply-To: <616812070806182134s3fab1fe6ub6f1c9dcf96089bc@mail.gmail.com> References: <4847F8EF.5070709@arin.net> <616812070806182134s3fab1fe6ub6f1c9dcf96089bc@mail.gmail.com> Message-ID: <4859EB83.1050609@psg.com> heather skanks wrote: > Is the argument that renewing an experimental allocation every year is a > hardship? Would anyone care to post about their experiences with an > experimental allocation and the renewal process? it's fairly easy, just administrivia and money > Can the authors or someone on list, give a current example of a "true > experiment in technical nature that addresses the internet architecture and > routing" that is adversely affected by the 1 year renewal requirement? it's just administrivia and money randy From owen at delong.com Thu Jun 19 02:34:32 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Jun 2008 23:34:32 -0700 Subject: [arin-ppml] Creating a market for IPv4 address space inabsenceof routing table entry market In-Reply-To: References: Message-ID: <6847587E-39DC-482E-A3AB-73B443E338FA@delong.com> On Jun 18, 2008, at 1:40 PM, David Schwartz wrote: > >> Yes, if you still feel it necessary, you may quote me in public. >> >> However, my intent was to point out that ARIN is not conveying >> any rights. I made no statement about what rights may or may >> not exist. I merely stated that ARIN does exactly this: >> >> ARIN guarantees you that ARIN will not issue the same addresses >> to another party while you maintain your account in good standing >> with ARIN and your resources have not been reclaimed for other >> reasons. >> >> You are also reasonably assured that the other RIRs and the IANA >> will not issue the same addresses to someone else. >> >> This does not convey any rights with respect to the internet or any >> organization outside of ARIN. It's just a contract between you >> and ARIN. Nothing more. >> >> The fact that most (if not all) ISPs agree and cooperate with ARIN >> and the other RIRs as authoritative registries for uniqueness >> is what makes the internet possible and keeps it working. However, >> if ISPs choose to believe someone else besides ARIN and let them >> route addresses ARIN assigned to you, there's not really any >> right on the part of ARIN to do anything about that. Nor will >> any government likely listen to you about ARIN having conveyed >> such a right to you. > > This may be a convenient legal fiction, but to actually believe > this, you > would have to believe that ARIN is not responsible for the predictable > consequences of its actions based on other people's rational > actions. ARIN > knows that its unique delegations are the gateways to Internet > routability, > and that this is so for good and rational reasons. It makes its > decisions > with this knowledge and cannot say it is not responsible for the > results > because it does not directly control those gateways. > What you are saying does not disagree with my point. I am not talking about ARIN's responsibilities. I am talking about what, if any, rights are conveyed with an IP address assignment from ARIN. ARIN doesn't have any rights to control people who run routers, and, IP addresses delegated by ARIN don't come with any such rights, either. I'm not saying ARIN isn't responsible for making sure that what they issue is proper. I'm saying ARIN has no ability to enforce what some other ISP does with the data. ARIN can't control if Verizon chooses to route some random address to one of their customers instead of to the organization that ARIN issued the addresses to. There's simply no way ARIN can do anything about this. > This would be like a credit-reporting agency saying that it has no > responsibility for denials of credit rationally made on the basis of > its > ratings because it wasn't the entity that denied the credit. > No... What I'm talking about would be more like saying that a credit- reporting agency isn't responsible if MC issues a card number to someone and VISA issues the same card number to someone else. (Yes, I know that V starts with 4 and MC starts with 5 exactly to avoid this, but, it's the closest I could come using the analogy presented.) The reality is that if VISA and MC do create such a numbering conflict, the credit reporting agency really can't do much about it. I don't know what level of authority is granted to the numbering authority for PCI stuff, so, let's just accept that the analogy doesn't fit if you over-analyze it and move on. Owen From mueller at syr.edu Thu Jun 19 04:19:58 2008 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 19 Jun 2008 04:19:58 -0400 Subject: [arin-ppml] ARIN address transfer policy Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> I am conducting a systematic analysis of the IPv4 Transfer Policy Proposal (2008-02). I would like to know who drafted the policy in order to ask questions (off list) about the rationale for certain features. Also would like to know more about the process by which amendments are proposed and implemented. Thanks, MM -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Jun 19 04:35:19 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Jun 2008 01:35:19 -0700 Subject: [arin-ppml] ARIN address transfer policy In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> Message-ID: It was a joint effort of the entire ARIN AC. Amendments can be proposed by stating what you want on the list, and, will be implemented, if accepted, by the AC incorporating them into the next revision of the policy. Owen On Jun 19, 2008, at 1:19 AM, Milton L Mueller wrote: > I am conducting a systematic analysis of the IPv4 Transfer Policy > Proposal (2008-02). I would like to know who drafted the policy in > order to ask questions (off list) about the rationale for certain > features. Also would like to know more about the process by which > amendments are proposed and implemented. Thanks, > MM > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Thu Jun 19 07:25:21 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 19 Jun 2008 12:25:21 +0100 Subject: [arin-ppml] Creating a market for IPv4 address space in absenceof routing table entry market In-Reply-To: <1080618122759.449A-100000@Ives.egh.com> Message-ID: - > > > I don't think anyone who advocates a market in address > space thinks > > > that implies ownership of address space. It implies ownership of > > > the right to use address space (i.e. a license to use that unique > > > set of integers, in the limited context of the IPv4 Internet.) > > > > If so, then that would be a MAJOR change to the set of rights wich > > currently come with an ARIN allocation. Currently you have > a right to > > use those integers in devices which support the Internet Protocol > > version 4. This holds whether or not you connect the set of > devices to > > the Internet or not. If you have a need for uniqueness, you > can apply > > to ARIN and get addresses. Many companies have done so, > often to use > > in VPNs or private internetworks (also called extranets) in which > > companies connect to their trading partners. > > No, this is no change at all to the rights that come with an > ARIN allocation. Yes it is. Many companies, including the one I work for, have applied for and received ARIN allocations for use on IP networks that are not on the Internet. RFC 2050 which is the basis for the RIR system allows for this. There has never been a restriction or requirement about using registered IP addresses on the Internet. > If I am building my own IPv4 network that > is not connected to the Internet, I can use any set of > addresses I want. > I do *not* need ARIN's (or anyone else's) permission to do > this. I do not have any guarantee of uniqueness, but if I'm > not connected to the Internet, I don't care. Not true. If I am building boxes with hardcoded IP addresses, that will be plugged in at some random network location, then I do care about IP address conflicts. If I am running a private internetwork which multiple companies will connect to then I do care. Please don't just make up facts. I am discussing the situation as it exists today. > lso, if I want > to use 32-bit numbers for any purpose not related to IP or > specifically IPv4, ARIN's supplied 32-bit numbers are of > absolutely no relevence. What is your point? As I stated before, IPv4ddresses are for use on network devices that use Internet Protocol version 4. This says nothing about the Internet. The Internet is a public IP internetwork and is a subset which contains a subset of the devices using IPv4, even if you count all the devices behind NATs. > The rights granted by ARIN in conjunction with an IPv4 > address apply only to the use of that address on the > Internet, and not to that number in any other context. This > has always been true. > It is *not* a change. You sir, are wrong and you clearly have not been reading RFC 2050, ARIN's policy, the ARIN RSA, and the ARIN charter. We do not operate based on network mythology, except in the case of the whois directory. --Michael Dillon From michael.dillon at bt.com Thu Jun 19 07:34:28 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 19 Jun 2008 12:34:28 +0100 Subject: [arin-ppml] Creating a market for IPv4 address spaceinabsenceof routing table entry market In-Reply-To: Message-ID: > > > It implies ownership of > > > the right to use address space (i.e. a license to use that unique > > > set of integers, in the limited context of the IPv4 Internet.) > > If so, then that would be a MAJOR change to the set of rights wich > > currently come with an ARIN allocation. Currently you have > a right to > > use those integers in devices which support the Internet Protocol > > version 4. This holds whether or not you connect the set of > devices to > > the Internet or not. > Your response is a non sequiter. He said that A implies B. > You replied that would be a major change because we have > always felt that C was also true. > However, there is no inconsistency between B and C. In fact, > C is independent of B. You are splitting hairs. I'm not talking about logic, I'm talking about policy. If you accept ambiguous language, even in a discussion, then it could come to pass that new policies contain language saying that they apply in the limited context of the IPv4 Internet. That is not the case with current policy. Plain English is more than adequate to discuss ARIN policy so please do not try and force us to argue about whether or not you have correctly translated the discussion into the language of logic. --Michael Dillon From michael.dillon at bt.com Thu Jun 19 07:42:22 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 19 Jun 2008 12:42:22 +0100 Subject: [arin-ppml] Whois Archival Policy? In-Reply-To: Message-ID: > Should we develop a policy allowing ARIN to release > historical WHOIS records? Yes. I'd especially like to see the contents of the ftp server at rs.internic.net. > Should there be any restrictions on the circumstances under > which ARIN would do so? Not really. maybe just a date before which they are "historical" and wide open, and after which the bulk whois policy applies. --Michael Dillon From jcurran at istaff.org Thu Jun 19 07:35:58 2008 From: jcurran at istaff.org (John Curran) Date: Thu, 19 Jun 2008 07:35:58 -0400 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In-Reply-To: <4859EB83.1050609@psg.com> References: <4847F8EF.5070709@arin.net> <616812070806182134s3fab1fe6ub6f1c9dcf96089bc@mail.gmail.com> <4859EB83.1050609@psg.com> Message-ID: At 2:15 PM +0900 6/19/08, Randy Bush wrote: >heather skanks wrote: >> Is the argument that renewing an experimental allocation every year is a >> hardship? Would anyone care to post about their experiences with an >> experimental allocation and the renewal process? > >it's fairly easy, just administrivia and money > >> Can the authors or someone on list, give a current example of a "true >> experiment in technical nature that addresses the internet architecture and >> routing" that is adversely affected by the 1 year renewal requirement? > >it's just administrivia and money Can you elaborate on either of these for sake of those who might not have direct experience, and do you have an opinion either way regarding the policy proposal to change the renewal timeframe? /John From bicknell at ufp.org Thu Jun 19 09:35:45 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 19 Jun 2008 09:35:45 -0400 Subject: [arin-ppml] ARIN address transfer policy In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> Message-ID: <20080619133545.GB71329@ussenterprise.ufp.org> In a message written on Thu, Jun 19, 2008 at 04:19:58AM -0400, Milton L Mueller wrote: > I am conducting a systematic analysis of the IPv4 Transfer Policy > Proposal (2008-02). I would like to know who drafted the policy in > order to ask questions (off list) about the rationale for certain > features. Also would like to know more about the process by which > amendments are proposed and implemented. Thanks, You can go to the policy proposal archive (http://www.arin.net/policy/proposals/proposal_archive.html) and find information for any proposal. For 2008-2 (http://www.arin.net/policy/proposals/2008_2.html) the author is the ARIN Advisory Council, which makes asking the author a bit more difficult. However, every proposal has Shepherds, in this case Scott and Stacy. The AC members are listed at http://www.arin.net/about_us/ac.html along with e-mail addresses. Feel free to e-mail Shepherds with questions, that's why we have them! -- 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: 187 bytes Desc: not available URL: From randy at psg.com Thu Jun 19 11:02:50 2008 From: randy at psg.com (Randy Bush) Date: Fri, 20 Jun 2008 00:02:50 +0900 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In-Reply-To: References: <4847F8EF.5070709@arin.net> <616812070806182134s3fab1fe6ub6f1c9dcf96089bc@mail.gmail.com> <4859EB83.1050609@psg.com> Message-ID: <485A751A.1030303@psg.com> John Curran wrote: > At 2:15 PM +0900 6/19/08, Randy Bush wrote: >> heather skanks wrote: >>> Is the argument that renewing an experimental allocation every >>> year is a hardship? Would anyone care to post about their >>> experiences with an experimental allocation and the renewal >>> process? >> it's fairly easy, just administrivia and money >> >>> Can the authors or someone on list, give a current example of a >>> "true experiment in technical nature that addresses the internet >>> architecture and routing" that is adversely affected by the 1 >>> year renewal requirement? >> it's just administrivia and money > > Can you elaborate on either of these for sake of those who might not > have direct experience uh, the administrivia is on the web site. i will not mock you by sending a url. same for the pricing. i guess i must not understand your question. it's just business. do the paperwork, send the cash; arin even takes credit cards; i have not tried green stamps. as to the administrative hassle, anyone who asks clearly has never dealt with ripe's eurocrazy. you just don't realize how easy it is to work with arin hostfolk. > and do you have an opinion either way regarding the policy proposal > to change the renewal timeframe? i did not read it beyond scanning; it seemed uninteresting, more policy noise. i am only on this thread because heather asked two questions for which i was foolish enough to believe that i had the direct experience to answer. randy From mueller at syr.edu Thu Jun 19 16:46:54 2008 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 19 Jun 2008 16:46:54 -0400 Subject: [arin-ppml] Legacy RSA Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0D98E@SUEXCL-02.ad.syr.edu> Hello, all: How many organizations have signed the Legacy Registration Services Agreement since it was promulgated this year? Just the facts, ma'am --MM -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Thu Jun 19 17:01:04 2008 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 19 Jun 2008 17:01:04 -0400 Subject: [arin-ppml] ARIN apathy In-Reply-To: References: Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0D98F@SUEXCL-02.ad.syr.edu> Michael: Asynchronous email is often a poor conveyor of subtle meanings. When you say something like this: > -----Original Message----- > > Or should we just leave it alone and be happy that there is now clear > precedent for hijacking addresses? This will go some way to alleviate > the IP address shortage that is looming although this doesn't help those > who want to hijack 126.0.0.0/8 or 130.0.0.0/8. ...I confess I cannot tell whether you are being ironic or serious. If you are being ironic, then presumably you are spoofing some people who you believe want to hijack addresses. But I don't know of anyone who supports that. And this is the second or third message you've sent defending hijacking, and, I hope you are not offended, the humor doesn't wear well with the repetition. If you are serious, then my head spins. I have trouble understanding why someone would strenuously oppose voluntary market transfers to move addresses from unused places to needed places, and prefer random hijacking instead?! You _really_ have to hate market forces a _lot_ to take a position like that, i.e. as much as your typical 64 year old British literary studies professor, and one typically doesn't think of people working for BT as being in that category. Help me out here, please. From dogwallah at gmail.com Thu Jun 19 17:01:17 2008 From: dogwallah at gmail.com (McTim) Date: Fri, 20 Jun 2008 00:01:17 +0300 Subject: [arin-ppml] Legacy RSA In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D98E@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D98E@SUEXCL-02.ad.syr.edu> Message-ID: On Thu, Jun 19, 2008 at 11:46 PM, Milton L Mueller wrote: > Hello, all: > > How many organizations have signed the Legacy Registration Services > Agreement since it was promulgated this year? IGP blog fodder publicly available in meeting minutes, you just have to look! http://www.arin.net/meetings/minutes/ARIN_XXI/mem_transcript.html#anchor_5_discussion -- Cheers, McTim $ whois -h whois.afrinic.net mctim From Lee.Howard at stanleyassociates.com Thu Jun 19 17:13:24 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 19 Jun 2008 17:13:24 -0400 Subject: [arin-ppml] Legacy RSA In-Reply-To: Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40A4B3CD2@CL-S-EX-1.stanleyassociates.com> If you're not so good with words, see slide 9 of http://www.arin.net/meetings/minutes/ARIN_XXI/PDF/wednesday/RSD_Nobile.p df Lee > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of McTim > Sent: Thursday, June 19, 2008 5:01 PM > To: PPML ppml > Subject: Re: [arin-ppml] Legacy RSA > > On Thu, Jun 19, 2008 at 11:46 PM, Milton L Mueller > wrote: > > Hello, all: > > > > How many organizations have signed the Legacy Registration Services > > Agreement since it was promulgated this year? > > IGP blog fodder publicly available in meeting minutes, you > just have to look! > > http://www.arin.net/meetings/minutes/ARIN_XXI/mem_transcript.h > tml#anchor_5_discussion > > -- > Cheers, > > McTim > $ whois -h whois.afrinic.net mctim > _______________________________________________ > 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 the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From info at arin.net Thu Jun 19 17:36:25 2008 From: info at arin.net (Member Services) Date: Thu, 19 Jun 2008 17:36:25 -0400 Subject: [arin-ppml] Legacy RSAs Message-ID: <485AD159.1030701@arin.net> Hello, To date, there have been 92 organizations that have signed ARIN?s Legacy RSA since it was introduced on October 31, 2007. Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN) From mueller at syr.edu Thu Jun 19 17:37:39 2008 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 19 Jun 2008 17:37:39 -0400 Subject: [arin-ppml] Legacy RSA In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901E0D98E@SUEXCL-02.ad.syr.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0D993@SUEXCL-02.ad.syr.edu> Mctim: On the ARIN site there is block that says "search ARIN.net" If you type "Legacy Registration Services Agreement" into that here is what you get: "Your search - Legacy Registration Services Agreement - did not match any documents on the ARIN site. No pages were found containing "Legacy Registration Services Agreement" So I've modified your message: > -----Original Message----- > > IGP blog fodder publicly available in meeting minutes, you just have to > [KNOW WHERE TO] look! From mueller at syr.edu Thu Jun 19 18:04:50 2008 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 19 Jun 2008 18:04:50 -0400 Subject: [arin-ppml] ARIN address transfer policy In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> Thanks to Owen, Leo and Scott for responding. Based on what you all said, it seems as if it would be best for the questions I have to be openly stated and discussed on this list. Most of the AC members, if not all, are probably present here and the rest of the list would benefit from seeing the questions answered, as many of them may have the same questions in mind. I'll start soon. --MM ________________________________ From: Owen DeLong [mailto:owen at delong.com] Sent: Thursday, June 19, 2008 4:35 AM To: Milton L Mueller Cc: PPML ppml Subject: Re: [arin-ppml] ARIN address transfer policy It was a joint effort of the entire ARIN AC. Amendments can be proposed by stating what you want on the list, and, will be implemented, if accepted, by the AC incorporating them into the next revision of the policy. Owen On Jun 19, 2008, at 1:19 AM, Milton L Mueller wrote: I am conducting a systematic analysis of the IPv4 Transfer Policy Proposal (2008-02). I would like to know who drafted the policy in order to ask questions (off list) about the rationale for certain features. Also would like to know more about the process by which amendments are proposed and implemented. Thanks, MM _______________________________________________ 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Thu Jun 19 19:00:01 2008 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 19 Jun 2008 19:00:01 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <485AD985.70300@internap.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> Let's start with a fairly simple question. The ARIN proposal says that the transfers it authorizes only start "when IANA allocates its last unallocated unicast IPv4 address block." What is the economic rationale for this? If I have too much address space now, and someone else wants it, what is the social benefit of requiring me to wait for IANA's "last unallocated unicast ipv4 address block" to be dropped? > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand at internap.com] > Sent: Thursday, June 19, 2008 6:11 PM > To: Milton L Mueller > Cc: Owen DeLong; Leo Bicknell > Subject: Re: [arin-ppml] ARIN address transfer policy > > That works for me. I'm particularly interested to start getting new > points discussed on PPML, and hopefully avoid too much rehashing of the > same debates we've already had repeatedly. It sounds like your effort > will move us in the right direction there, so thanks in advance. > > -Scott > > Milton L Mueller wrote: > > Thanks to Owen, Leo and Scott for responding. > > > > Based on what you all said, it seems as if it would be best for the > > questions I have to be openly stated and discussed on this list. Most of > > the AC members, if not all, are probably present here and the rest of > > the list would benefit from seeing the questions answered, as many of > > them may have the same questions in mind. I'll start soon. > > > > --MM > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > *From:* Owen DeLong [mailto:owen at delong.com] > > *Sent:* Thursday, June 19, 2008 4:35 AM > > *To:* Milton L Mueller > > *Cc:* PPML ppml > > *Subject:* Re: [arin-ppml] ARIN address transfer policy > > > > > > > > It was a joint effort of the entire ARIN AC. > > > > > > > > Amendments can be proposed by stating what you want on the list, and, > will > > > > be implemented, if accepted, by the AC incorporating them into the next > > > > revision of the policy. > > > > > > > > Owen > > > > > > > > On Jun 19, 2008, at 1:19 AM, Milton L Mueller wrote: > > > > > > > > I am conducting a systematic analysis of the IPv4 Transfer Policy > > Proposal (2008-02). I would like to know who drafted the policy in order > > to ask questions (off list) about the rationale for certain features. > > Also would like to know more about the process by which amendments are > > proposed and implemented. Thanks, > > > > MM > > > > _______________________________________________ > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if > you experience any issues. From sleibrand at internap.com Thu Jun 19 19:49:05 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 19 Jun 2008 16:49:05 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> Message-ID: <485AF071.1020802@internap.com> I've seen & heard a couple of arguments for waiting to start allowing transfers. I'm not sure whether I find the arguments compelling or not, but here they are: - If addresses are still available "for free" from ARIN, then an argument has been made that the only people that would want to acquire addresses via transfer in advance of exhaustion would be organizations that don't qualify for space under current policy. - If, as in 2008-2, we allow the transfer of legacy class C's (/24s), then allowing people to start using the policy early would constitute an end run around the /22 limitation in the current PI policy. In other words, organizations that wouldn't qualify to get PI space would be able to acquire it on the transfer market instead. The main counterarguments to waiting too long to start allowing transfers is that we'd like to work out the kinks in the system before exhaustion hits, and that getting started early allows the market to gradually settle on a price as volume gradually increases. -Scott Milton L Mueller wrote: > Let's start with a fairly simple question. The ARIN proposal says that > the transfers it authorizes only start "when IANA allocates its last > unallocated unicast IPv4 address block." What is the economic rationale > for this? > > If I have too much address space now, and someone else wants it, what is > the social benefit of requiring me to wait for IANA's "last unallocated > unicast ipv4 address block" to be dropped? > >> -----Original Message----- >> From: Scott Leibrand [mailto:sleibrand at internap.com] >> Sent: Thursday, June 19, 2008 6:11 PM >> To: Milton L Mueller >> Cc: Owen DeLong; Leo Bicknell >> Subject: Re: [arin-ppml] ARIN address transfer policy >> >> That works for me. I'm particularly interested to start getting new >> points discussed on PPML, and hopefully avoid too much rehashing of > the >> same debates we've already had repeatedly. It sounds like your effort >> will move us in the right direction there, so thanks in advance. >> >> -Scott >> >> Milton L Mueller wrote: >>> Thanks to Owen, Leo and Scott for responding. >>> >>> Based on what you all said, it seems as if it would be best for the >>> questions I have to be openly stated and discussed on this list. > Most of >>> the AC members, if not all, are probably present here and the rest > of >>> the list would benefit from seeing the questions answered, as many > of >>> them may have the same questions in mind. I'll start soon. >>> >>> --MM >>> >>> >>> >>> >>> >>> > ------------------------------------------------------------------------ >>> *From:* Owen DeLong [mailto:owen at delong.com] >>> *Sent:* Thursday, June 19, 2008 4:35 AM >>> *To:* Milton L Mueller >>> *Cc:* PPML ppml >>> *Subject:* Re: [arin-ppml] ARIN address transfer policy >>> >>> >>> >>> It was a joint effort of the entire ARIN AC. >>> >>> >>> >>> Amendments can be proposed by stating what you want on the list, > and, >> will >>> be implemented, if accepted, by the AC incorporating them into the > next >>> revision of the policy. >>> >>> >>> >>> Owen >>> >>> >>> >>> On Jun 19, 2008, at 1:19 AM, Milton L Mueller wrote: >>> >>> >>> >>> I am conducting a systematic analysis of the IPv4 Transfer Policy >>> Proposal (2008-02). I would like to know who drafted the policy in > order >>> to ask questions (off list) about the rationale for certain > features. >>> Also would like to know more about the process by which amendments > are >>> proposed and implemented. Thanks, >>> >>> MM >>> >>> _______________________________________________ >>> 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From tvest at pch.net Thu Jun 19 19:49:38 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 19 Jun 2008 19:49:38 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> Message-ID: Hi Milton, Are you asking for a hypothetical answer that assumes that the resource proposal is adopted, or a hypothetical answer that assumes that the proposal is not adopted and the status quo remains unchanged, or something else entirely? There are many possibilities either way, but I think it would be good to clarify what you're looking for before everyone starts chiming in and creating needless confusion (c.f., the last thread on "creating a transfer market"). TV On Jun 19, 2008, at 7:00 PM, Milton L Mueller wrote: > Let's start with a fairly simple question. The ARIN proposal says that > the transfers it authorizes only start "when IANA allocates its last > unallocated unicast IPv4 address block." What is the economic > rationale > for this? > > If I have too much address space now, and someone else wants it, > what is > the social benefit of requiring me to wait for IANA's "last > unallocated > unicast ipv4 address block" to be dropped? > >> -----Original Message----- >> From: Scott Leibrand [mailto:sleibrand at internap.com] >> Sent: Thursday, June 19, 2008 6:11 PM >> To: Milton L Mueller >> Cc: Owen DeLong; Leo Bicknell >> Subject: Re: [arin-ppml] ARIN address transfer policy >> >> That works for me. I'm particularly interested to start getting new >> points discussed on PPML, and hopefully avoid too much rehashing of > the >> same debates we've already had repeatedly. It sounds like your >> effort >> will move us in the right direction there, so thanks in advance. >> >> -Scott >> >> Milton L Mueller wrote: >>> Thanks to Owen, Leo and Scott for responding. >>> >>> Based on what you all said, it seems as if it would be best for the >>> questions I have to be openly stated and discussed on this list. > Most of >>> the AC members, if not all, are probably present here and the rest > of >>> the list would benefit from seeing the questions answered, as many > of >>> them may have the same questions in mind. I'll start soon. >>> >>> --MM >>> >>> >>> >>> >>> >>> > ------------------------------------------------------------------------ >>> >>> *From:* Owen DeLong [mailto:owen at delong.com] >>> *Sent:* Thursday, June 19, 2008 4:35 AM >>> *To:* Milton L Mueller >>> *Cc:* PPML ppml >>> *Subject:* Re: [arin-ppml] ARIN address transfer policy >>> >>> >>> >>> It was a joint effort of the entire ARIN AC. >>> >>> >>> >>> Amendments can be proposed by stating what you want on the list, > and, >> will >>> >>> be implemented, if accepted, by the AC incorporating them into the > next >>> >>> revision of the policy. >>> >>> >>> >>> Owen >>> >>> >>> >>> On Jun 19, 2008, at 1:19 AM, Milton L Mueller wrote: >>> >>> >>> >>> I am conducting a systematic analysis of the IPv4 Transfer Policy >>> Proposal (2008-02). I would like to know who drafted the policy in > order >>> to ask questions (off list) about the rationale for certain > features. >>> Also would like to know more about the process by which amendments > are >>> proposed and implemented. Thanks, >>> >>> MM >>> >>> _______________________________________________ >>> 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From tedm at ipinc.net Thu Jun 19 20:42:30 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 19 Jun 2008 17:42:30 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller > Sent: Thursday, June 19, 2008 4:00 PM > To: PPML ppml > Subject: [arin-ppml] Q1 - ARIN address transfer policy: why > the trigger date? > > > Let's start with a fairly simple question. The ARIN proposal > says that the transfers it authorizes only start "when IANA > allocates its last unallocated unicast IPv4 address block." > What is the economic rationale for this? > ARIN policy isn't supposed to be based on an economic rationale. It's supposed to be based on the concept of the greatest good for the greatest number. Addressing policy is designed for 3 reasons: 1) The internet doesen't work unless all "visible" hosts on it have different IP addresses, so we have to insure against duplications. 2) To know who has what so if there's a problem we know who to go to to fix it. 3) Conservation of a scarce resource IPv6 effectively erases #3 which is why it's a better system than IPv4. > If I have too much address space now, By definition, if you have "too much" address space then you are required under the RSA you signed to return it. Why - because you gave invalid estimates of your use when you obtained the addressing. You could have believed at one time that your future estimates required you to obtain a /10. You provided those estimates to ARIN in good faith and got your /10. But, 3 years later you realized that those estimates were wrong. Thus, you found that the rationale used at that time to qualify for the /10 was also false, and thus you obtained address space under false pretences - lying about utilization is IMHO a violation of your RSA agreement - "too much" in your words - You are thus now required to return some of it. The situation is no different if your shopping in a grocery store and unknown to you your 3 year old drops a candy bar into your purse. When you walked out of the grocery store without paying for it at that instant you were NOT a thief. When you discover the candy bar later at that instant you still are not a thief. However when you make a conscious decision after discovering it to NOT return it to the store, and NOT pay for it, at that instant, you become a thief. Therefore your hypothetical situation -cannot- exist pre-IPv4 runout. ANYONE who "sells extra IPv4" that they obtained under an RSA pre-runout is in my opinion a liar and a thief and a contract breaker. The modification of the ARIN requirements to permit "selling" effectively modifies the existing RSAs that people have signed, because it basically says that "After IPv4-runout we don't give a crap how you got your IPv4, whether honestly or not, from this point on we all have a clean slate" This is why such a policy is a horrible idea pre-IPv4 runout. Post-IPv4 runout I don't care for it much either, but I do understand the argument that the social good is better served by letting the speculators who obtained IPv4 under a pack of lies profit from their misdeeds. I don't agree with it, but I do understand it. Ted From randy at psg.com Thu Jun 19 22:14:36 2008 From: randy at psg.com (Randy Bush) Date: Fri, 20 Jun 2008 11:14:36 +0900 Subject: [arin-ppml] yep, no one trades address space Message-ID: <485B128C.7060000@psg.com> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&Item=270247528043&Category=11175&_trksid=p3907.m29 From tvest at pch.net Thu Jun 19 22:28:37 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 19 Jun 2008 22:28:37 -0400 Subject: [arin-ppml] yep, no one trades address space In-Reply-To: <485B128C.7060000@psg.com> References: <485B128C.7060000@psg.com> Message-ID: <3E9B6EAD-7C25-4F64-B6E9-A8CDE2ADF038@pch.net> That's amazing timing... purely coincidental no doubt. Have other transactions like this been observed on Ebay in the past? TV On Jun 19, 2008, at 10:14 PM, Randy Bush wrote: > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&Item=270247528043&Category=11175&_trksid=p3907.m29 > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From randy at psg.com Thu Jun 19 22:51:23 2008 From: randy at psg.com (Randy Bush) Date: Fri, 20 Jun 2008 11:51:23 +0900 Subject: [arin-ppml] yep, no one trades address space In-Reply-To: <400FC682CB93E36021101437@as-paul-l.apnic.net.> References: <485B128C.7060000@psg.com> <3E9B6EAD-7C25-4F64-B6E9-A8CDE2ADF038@pch.net> <400FC682CB93E36021101437@as-paul-l.apnic.net.> Message-ID: <485B1B2B.6090005@psg.com> Paul Wilson wrote: > I believe that such listings have been posted in the past, and that in > some cases eBay has acted to have them removed i wonder on what basis randy From sleibrand at internap.com Thu Jun 19 23:04:07 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 19 Jun 2008 20:04:07 -0700 Subject: [arin-ppml] yep, no one trades address space In-Reply-To: <485B1B2B.6090005@psg.com> References: <485B128C.7060000@psg.com> <3E9B6EAD-7C25-4F64-B6E9-A8CDE2ADF038@pch.net> <400FC682CB93E36021101437@as-paul-l.apnic.net.> <485B1B2B.6090005@psg.com> Message-ID: <485B1E27.6080901@internap.com> In this case at least the seller is being honest that he won't likely be able to get the address space transferred, and is offering to "license" the buyer the space indefinitely in that case (a de facto sale without a transfer). Since current policy doesn't prohibit the indefinite-lease-and-SWIP model, I suspect we'll see a lot more of that if we keep our transfer policy unchanged... -Scott Randy Bush wrote: > Paul Wilson wrote: >> I believe that such listings have been posted in the past, and that in >> some cases eBay has acted to have them removed > > i wonder on what basis > > randy > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From pwilson at apnic.net Thu Jun 19 22:43:43 2008 From: pwilson at apnic.net (Paul Wilson) Date: Fri, 20 Jun 2008 12:43:43 +1000 Subject: [arin-ppml] yep, no one trades address space In-Reply-To: <3E9B6EAD-7C25-4F64-B6E9-A8CDE2ADF038@pch.net> References: <485B128C.7060000@psg.com> <3E9B6EAD-7C25-4F64-B6E9-A8CDE2ADF038@pch.net> Message-ID: <400FC682CB93E36021101437@as-paul-l.apnic.net.> I believe that such listings have been posted in the past, and that in some cases eBay has acted to have them removed (which I expect someone from ARIN can confirm). In case this one disappears, here is a record. Paul. --On 19 June 2008 10:28:37 PM -0400 Tom Vest wrote: > That's amazing timing... purely coincidental no doubt. > > Have other transactions like this been observed on Ebay in the past? > > TV > > On Jun 19, 2008, at 10:14 PM, Randy Bush wrote: > >> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&Item=270247528043&Category >> =11175&_trksid=p3907.m29 _______________________________________________ >> 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. ________________________________________________________________________ Paul Wilson, Director-General, APNIC http://www.apnic.net ph/fx +61 7 3858 3100/99 -------------- next part -------------- A non-text attachment was scrubbed... Name: IPforSale-20080620.png Type: image/png Size: 172224 bytes Desc: not available URL: From davids at webmaster.com Thu Jun 19 23:12:58 2008 From: davids at webmaster.com (David Schwartz) Date: Thu, 19 Jun 2008 20:12:58 -0700 Subject: [arin-ppml] yep, no one trades address space In-Reply-To: <485B1B2B.6090005@psg.com> Message-ID: > Paul Wilson wrote: > > I believe that such listings have been posted in the past, and that in > > some cases eBay has acted to have them removed > > i wonder on what basis > > randy If memory serves me, they said something like 'Seller does not have the right or ability to deliver the product or service offered'. The way this one is worded, I think they'd be right. But you might be able to get around this by carefully wording precisely what you will and won't do for the winning bidder. DS From tvest at pch.net Thu Jun 19 23:24:48 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 19 Jun 2008 23:24:48 -0400 Subject: [arin-ppml] Creating a market for IPv4 address space inabsenceof routing table entry market In-Reply-To: <1080618143934.449C-100000@Ives.egh.com> References: <1080618143934.449C-100000@Ives.egh.com> Message-ID: Some confusion is edifying... On Jun 18, 2008, at 2:54 PM, John Santos wrote: > On Wed, 18 Jun 2008, David Schwartz wrote: > >> >>>> I don't think anyone who advocates a market in address space >>>> thinks that implies ownership of address space. It implies >>>> ownership of the right to use address space (i.e. a license >>>> to use that unique set of integers, in the limited context of >>>> the IPv4 Internet.) >> >>> If so, then that would be a MAJOR change to the set of rights wich >>> currently come with an ARIN allocation. Currently you have a right >>> to use those integers in devices which support the Internet Protocol >>> version 4. This holds whether or not you connect the set of devices >>> to the Internet or not. If you have a need for uniqueness, you can >>> apply to ARIN and get addresses. Many companies have done so, often >>> to use in VPNs or private internetworks (also called extranets) in >>> which companies connect to their trading partners. >>> >>> --Michael Dillon >> >> Your response is a non sequiter. He said that A implies B. You >> replied that >> would be a major change because we have always felt that C was also >> true. >> However, there is no inconsistency between B and C. In fact, C is >> independent of B. >> >> Perhaps you took his "A implies only B" to mean that he was >> claiming your >> particular superset of B was false. But he did no such thing. He >> simply said >> it wasn't implied by A. However, that takes no position on its >> truth or >> falsity. >> >> In this case: >> >> A = A market for address space >> B = Ownership of a right to use address space only on the Internet >> C = Assignment includes right to use address space in non-Internet >> contexts >> >> In case it's not clear, he argued that a market in address space >> implies >> that you can own the right to use address space in the limited >> context of >> the IPv4 Internet (A implies or requires just B). He said nothing >> about use >> of address space in any other context. He didn't say you couldn't >> get it or >> didn't have it, he just said that only ownership of a right to use >> in the >> limited context of the Internet is required for a market in address >> space. >> >> And, in fact, when someone wants to "buy IP addresses", what they >> want is >> the exclusive right to use those IP addresses on the public >> Internet. If >> this right can be had and transferred, then there can be a market >> in address >> space. >> >> DS > > That's what I meant in my followup, if it was a little incoherent. > > Someone else has mail me privately (not sure if it is okay to quote > him directly) that the dispute with my original statement is not that > the rights go beyond what I said, but that there are any rights at > all at stake. He said there are not, but there is an explicit > guarantee of uniqueness. I claim that if this guarantee has any > meaning, then it implies a right. Otherwise it is no guarantee > at all. Maybe the dispute is over the meaning of the word "right" > or license. Or maybe Micheal is claiming that there is a broader > right than I posited, and my other correspondent is claiming > narrower rights. > > As for extranets, ARIN doesn't grant you the right to use the > allocated (or assigned) addresses in a non-Internet context, > you already have the right to use *any* addresses you and > your trading partners agree to. > All that ARIN provides in this > context is a convenient allocation scheme. However, a typical > Internet user does not have any explicit contract or agreement > with the vast majority of other Internet users, so the RIR > guarantee of uniqueness and exclusivity matters. Here it sounded like you were asserting something like: Whatever two parties agree to do bilaterally with respect to announcing and accepting any IPv4 address/prefix -- even one that might be used elsewhere in a full "public" capacity (i.e., with whatever expectation of uniqueness that an official RIR allocation implies) is entirely up to the two parties involved; no RIR policies or other external requirements or restrictions apply, at least in the context of that specific bilateral usage. However, subsequent elaborations made the claim sound much broader -- if not quite a declaration of absolute (bilateral) contractual precedence over all other restrictions or requirements applicable to possession or use of Pv4 addresses. And that's exactly the problem. When you buy your PI IPv4 address space from Address Vendor X, are you required to participate fully in whois, to keep your whois records complete and up-to-date? If the presumed answer is "yes", where does the requirement come from? What are the mechanism(s) for ongoing verification/accuracy maintenance, and the default response in the event of noncompliance? In the event of a loss/failure of accuracy, what basis and mechanisms will exist to restore accuracy, or to pursue other remedies if that is not possible? This is a real question, for me anyway, as I am having troubling imagining answers other than: 1. No mechanisms other than self-interest; that will be enough to guarantee that whois continues to be (or becomes) "good enough" -- a faith which is not well supported by the quality of whois in the pre-RIR days, back when individual incentives really were the only mechanism to preserve accuracy (and the net was small, and largely noncommercial, and everyone was chummy). 2. Bilateral address transfer contracts will incorporate whois requirements -- Just begs the same questions in a different form (where does the contractual language requirement come from?), along with many others -- e.g., who gets stuck with monitoring/verification, who is harmed and may seek redress in the event of a failure, etc. 3. Hierarchical resource certification will solve all of these problems -- A plausible answer, but resource certification is a completely separate issue, which is not assumed much less required by the resource transfer proposals -- and one that is not exactly embraced with great enthusiasm by all IPv4 market advocates. So, we had an interesting if somewhat ambiguous object lesson about identifiability tonight: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&Item=270247528043&Category=11175&_trksid=p3907.m29 The prankster may have intended to illustrate that a transfer market is inevitable or unstoppable -- or maybe that a transfer market is certain to bring an end to any illusions about the viability of self- provisioning/self-governance of address resource identifiability, in which case someone will no doubt come along and help us out with that... Is there another alternative? TV -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Fri Jun 20 06:19:26 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 20 Jun 2008 11:19:26 +0100 Subject: [arin-ppml] ARIN apathy In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D98F@SUEXCL-02.ad.syr.edu> Message-ID: > > Or should we just leave it alone and be happy that there is > now clear > > precedent for hijacking addresses? This will go some way to > alleviate > > the IP address shortage that is looming although this doesn't help > those > > who want to hijack 126.0.0.0/8 or 130.0.0.0/8. > > ...I confess I cannot tell whether you are being ironic or serious. I am leaving it to the reader to decide whether this is an ironic suggestion, or a serious one. I expect that it will be interpreted in both ways and that is fine by me. > If you are being ironic, then presumably you are spoofing > some people who you believe want to hijack addresses. But I > don't know of anyone who supports that. I don't know what you mean by this. Certainly, it is common practice for people to use registered addresses that are not registered to them. Many of these instances are companies who connected to the Internet ten to fifteen years ago, got an address assignment from their ISP, numbered their internal network, and then, when they changed ISPs, decided that NAT was easier than renumbering. These cases sometimes get noticed by abuse desks because the company is running an SMTP server behind the NAT and that server puts the original not-properly-registered address in the mail headers. There are other cases, for instance many companies use 1.0.0.0/8, 2.0.0.0/8, 3.0.0.0/8, 4.0.0.0/8, 5.0.0.0/8, 6.0.0.0/8, 7.0.0.0/8 type addressing internally. In one case that I learned about, a company had three separate internal networks, which did not intercommunicate, and which all used 1.0.0.0/8 addresses. I mention 126.0.0.0/8 and 130.0.0.0/8 because I know that these addresses are also used in IP internetworks by companies which have not registered them. The first of these blocks is clearly registered to Softbank Japan and I believe it was the first time that an RIR allocated an entire /8 to one company. The second block is of indeterminate status according to IANA and ARIN records. Check for yourself. > And this is the > second or third message you've sent defending hijacking, and, > I hope you are not offended, the humor doesn't wear well with > the repetition. It's not humour. It happens to be a fact that many IP networks can function perfectly well without 100% universal connectivity. This is not only true of private networks and private internetworks, but also of the public Internet itself. A small to mid-size ISP has to ask themselves the serious business question, how many of my users would cancel their contracts if they could not get to or versus how many would cancel if it became known that we have run out of IPv4 addresses. > If you are serious, then my head spins. I have trouble > understanding why someone would strenuously oppose voluntary > market transfers to move addresses from unused places to > needed places, and prefer random hijacking instead?! It's not random hijacking when a small to mid-sized business in the ARIN region, carefully checks the records of IP address allocations in RIPE or APNIC et al. to choose some address range which their customers are very unlikely to want to communicate with. The ISP also has access to their own traffic data which can be used to confirm whether or not they have made a reasonable choice. When the current supply of IPv4 addresses runs out, if it is not feasible for your business to deploy IPv6, then you must acquire more IPv4 addresses, period. At this point, if you are a prudent business manager you will carefully consider your options starting with a build or buy decision. I believe that most such businesses will *NOT* make a buy decision but will instead opt for the build decision which I have documented in this message. It is cheaper and carries minimal risk to the business if they are careful in their choice of address range. > You > _really_ have to hate market forces a _lot_ to take a > position like that, i.e. as much as your typical 64 year old > British literary studies professor, and one typically doesn't > think of people working for BT as being in that category. First, I don't hate market forces. The fact is that there are no market forces in the IP addressing regime because there is no market. The fact that Geoffrey Mulligan and a few others have managed to sell a few addresses in a black market is not sufficient to create market forces. Given that there is only a couple of years left before we run out of the current free supply, there just is not enough time for a robuts and liquid market to develop, therefore any market forces that would arise will be skewed. As for people working at BT, well we are a rather large global company doing IT consulting, network security, and a whole range of data and voice networking services. As one might expect, there is broad diversity of opinion within the company. As I mentioned before in one earlier message, there is an official BT opinion that is basically opposed to market forces in IP addressing, and that opinion is available here on the ETNO site under May 2008. You will note that this is the joint opinion of BT and several other European network operators including France Telecom and Deutsche Telekom. In general, I get the impression that you are a fish out of water here, because this is fundamentally about making technical policy, and there are technical details involved which are not obvious to a literary studies professor of any age. I hope that you do hang around, learn a bit more, and do some writing on the topic, but please understand that some of us have as much in depth experience with the Internet and IP addressing as you have with some of of your work. I got my first IP address allocation back in early 1994, built several ISPs, was a founding member of the ARIN Advisory Council and so on. I've also done consulting work with several ISPs, helped numerous companies get ARIN or RIPE number resources, and I've seen a lot of variety in the IP networking world. It is not as nice and neat and simple as you have been led to believe. --Michael Dillon P.S. generally it is considered bad form to refer to someone else's employer since this list is really a public venue in which people speak for themselves, not for their company. From jcurran at istaff.org Fri Jun 20 07:06:47 2008 From: jcurran at istaff.org (John Curran) Date: Fri, 20 Jun 2008 07:06:47 -0400 Subject: [arin-ppml] Reporting of Fraudulent Transfers Message-ID: Folks - ARIN has always and will continue to investigate any credible information regarding fraudulent transfers, or other violations of its policies. In light of recent public discussions, the ARIN Board will publish mechanisms and procedures to encourage the submission to ARIN of creditable and supported information about such fraudulent transfers. We will also consider how to notify the ARIN community, and particularly those who bring ARIN such information privately, regarding the ultimate outcome of such investigations, keeping in mind that privacy or law enforcement needs may impose limits on public transparency. Publishing these procedures will take a short while to accomplish, and we will keep the community informed as we make progress. Thanks! /John John Curran Chairman ARIN Board of Trustees From bmanning at vacation.karoshi.com Fri Jun 20 09:16:47 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 20 Jun 2008 13:16:47 +0000 Subject: [arin-ppml] yep, no one trades address space In-Reply-To: <485B1E27.6080901@internap.com> References: <485B128C.7060000@psg.com> <3E9B6EAD-7C25-4F64-B6E9-A8CDE2ADF038@pch.net> <400FC682CB93E36021101437@as-paul-l.apnic.net.> <485B1B2B.6090005@psg.com> <485B1E27.6080901@internap.com> Message-ID: <20080620131647.GA9938@vacation.karoshi.com.> sounds a little bit like the whole ISP business... "you become my customer and I'll let you use some of the address space I'm responsible for..." Kind of glad the current policies don't prohibit that. On Thu, Jun 19, 2008 at 08:04:07PM -0700, Scott Leibrand wrote: > In this case at least the seller is being honest that he won't likely be > able to get the address space transferred, and is offering to "license" > the buyer the space indefinitely in that case (a de facto sale without a > transfer). > > Since current policy doesn't prohibit the indefinite-lease-and-SWIP > model, I suspect we'll see a lot more of that if we keep our transfer > policy unchanged... > > -Scott > > Randy Bush wrote: > > Paul Wilson wrote: > >> I believe that such listings have been posted in the past, and that in > >> some cases eBay has acted to have them removed > > > > i wonder on what basis > > > > randy > > _______________________________________________ > > 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From mueller at syr.edu Fri Jun 20 09:33:51 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 20 Jun 2008 09:33:51 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD90188411A@SUEXCL-02.ad.syr.edu> Tom: Sorry, I thought I was very clear about this. We are discussing Policy Proposal 2008-2, and the specific rationales that went into its features and design, so that we can assess what would happen if it _is_ implemented. ________________________________ From: Tom Vest [mailto:tvest at pch.net] Sent: Thu 6/19/2008 7:49 PM To: Milton L Mueller Cc: PPML ppml Subject: Re: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? Hi Milton, Are you asking for a hypothetical answer that assumes that the resource proposal is adopted, or a hypothetical answer that assumes that the proposal is not adopted and the status quo remains unchanged, or something else entirely? There are many possibilities either way, but I think it would be good to clarify what you're looking for before everyone starts chiming in and creating needless confusion (c.f., the last thread on "creating a transfer market"). TV On Jun 19, 2008, at 7:00 PM, Milton L Mueller wrote: > Let's start with a fairly simple question. The ARIN proposal says that > the transfers it authorizes only start "when IANA allocates its last > unallocated unicast IPv4 address block." What is the economic > rationale > for this? > > If I have too much address space now, and someone else wants it, > what is > the social benefit of requiring me to wait for IANA's "last > unallocated > unicast ipv4 address block" to be dropped? > >> -----Original Message----- >> From: Scott Leibrand [mailto:sleibrand at internap.com] >> Sent: Thursday, June 19, 2008 6:11 PM >> To: Milton L Mueller >> Cc: Owen DeLong; Leo Bicknell >> Subject: Re: [arin-ppml] ARIN address transfer policy >> >> That works for me. I'm particularly interested to start getting new >> points discussed on PPML, and hopefully avoid too much rehashing of > the >> same debates we've already had repeatedly. It sounds like your >> effort >> will move us in the right direction there, so thanks in advance. >> >> -Scott >> >> Milton L Mueller wrote: >>> Thanks to Owen, Leo and Scott for responding. >>> >>> Based on what you all said, it seems as if it would be best for the >>> questions I have to be openly stated and discussed on this list. > Most of >>> the AC members, if not all, are probably present here and the rest > of >>> the list would benefit from seeing the questions answered, as many > of >>> them may have the same questions in mind. I'll start soon. >>> >>> --MM >>> >>> >>> >>> >>> >>> > ------------------------------------------------------------------------ >>> >>> *From:* Owen DeLong [mailto:owen at delong.com] >>> *Sent:* Thursday, June 19, 2008 4:35 AM >>> *To:* Milton L Mueller >>> *Cc:* PPML ppml >>> *Subject:* Re: [arin-ppml] ARIN address transfer policy >>> >>> >>> >>> It was a joint effort of the entire ARIN AC. >>> >>> >>> >>> Amendments can be proposed by stating what you want on the list, > and, >> will >>> >>> be implemented, if accepted, by the AC incorporating them into the > next >>> >>> revision of the policy. >>> >>> >>> >>> Owen >>> >>> >>> >>> On Jun 19, 2008, at 1:19 AM, Milton L Mueller wrote: >>> >>> >>> >>> I am conducting a systematic analysis of the IPv4 Transfer Policy >>> Proposal (2008-02). I would like to know who drafted the policy in > order >>> to ask questions (off list) about the rationale for certain > features. >>> Also would like to know more about the process by which amendments > are >>> proposed and implemented. Thanks, >>> >>> MM >>> >>> _______________________________________________ >>> 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tvest at pch.net Fri Jun 20 09:54:19 2008 From: tvest at pch.net (Tom Vest) Date: Fri, 20 Jun 2008 09:54:19 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD90188411A@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD90188411A@SUEXCL-02.ad.syr.edu> Message-ID: Thanks for (re)affirming that Milton. TV On Jun 20, 2008, at 9:33 AM, Milton L Mueller wrote: > Tom: > Sorry, I thought I was very clear about this. We are discussing > Policy Proposal 2008-2, and the specific rationales that went into > its features and design, so that we can assess what would happen if > it _is_ implemented. > > > From: Tom Vest [mailto:tvest at pch.net] > Sent: Thu 6/19/2008 7:49 PM > To: Milton L Mueller > Cc: PPML ppml > Subject: Re: [arin-ppml] Q1 - ARIN address transfer policy: why the > trigger date? > > Hi Milton, > > Are you asking for a hypothetical answer that assumes that the > resource proposal is adopted, or a hypothetical answer that assumes > that the proposal is not adopted and the status quo remains unchanged, > or something else entirely? > > There are many possibilities either way, but I think it would be good > to clarify what you're looking for before everyone starts chiming in > and creating needless confusion (c.f., the last thread on "creating a > transfer market"). > > TV > > > > On Jun 19, 2008, at 7:00 PM, Milton L Mueller wrote: > > > Let's start with a fairly simple question. The ARIN proposal says > that > > the transfers it authorizes only start "when IANA allocates its last > > unallocated unicast IPv4 address block." What is the economic > > rationale > > for this? > > > > If I have too much address space now, and someone else wants it, > > what is > > the social benefit of requiring me to wait for IANA's "last > > unallocated > > unicast ipv4 address block" to be dropped? > > > >> -----Original Message----- > >> From: Scott Leibrand [mailto:sleibrand at internap.com] > >> Sent: Thursday, June 19, 2008 6:11 PM > >> To: Milton L Mueller > >> Cc: Owen DeLong; Leo Bicknell > >> Subject: Re: [arin-ppml] ARIN address transfer policy > >> > >> That works for me. I'm particularly interested to start getting > new > >> points discussed on PPML, and hopefully avoid too much rehashing of > > the > >> same debates we've already had repeatedly. It sounds like your > >> effort > >> will move us in the right direction there, so thanks in advance. > >> > >> -Scott > >> > >> Milton L Mueller wrote: > >>> Thanks to Owen, Leo and Scott for responding. > >>> > >>> Based on what you all said, it seems as if it would be best for > the > >>> questions I have to be openly stated and discussed on this list. > > Most of > >>> the AC members, if not all, are probably present here and the rest > > of > >>> the list would benefit from seeing the questions answered, as many > > of > >>> them may have the same questions in mind. I'll start soon. > >>> > >>> --MM > >>> > >>> > >>> > >>> > >>> > >>> > > > ------------------------------------------------------------------------ > >>> > >>> *From:* Owen DeLong [mailto:owen at delong.com] > >>> *Sent:* Thursday, June 19, 2008 4:35 AM > >>> *To:* Milton L Mueller > >>> *Cc:* PPML ppml > >>> *Subject:* Re: [arin-ppml] ARIN address transfer policy > >>> > >>> > >>> > >>> It was a joint effort of the entire ARIN AC. > >>> > >>> > >>> > >>> Amendments can be proposed by stating what you want on the list, > > and, > >> will > >>> > >>> be implemented, if accepted, by the AC incorporating them into the > > next > >>> > >>> revision of the policy. > >>> > >>> > >>> > >>> Owen > >>> > >>> > >>> > >>> On Jun 19, 2008, at 1:19 AM, Milton L Mueller wrote: > >>> > >>> > >>> > >>> I am conducting a systematic analysis of the IPv4 Transfer Policy > >>> Proposal (2008-02). I would like to know who drafted the policy in > > order > >>> to ask questions (off list) about the rationale for certain > > features. > >>> Also would like to know more about the process by which amendments > > are > >>> proposed and implemented. Thanks, > >>> > >>> MM > >>> > >>> _______________________________________________ > >>> 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net > > if you experience any issues. > > From mueller at syr.edu Fri Jun 20 10:09:20 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 20 Jun 2008 10:09:20 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485AF071.1020802@internap.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD90188411C@SUEXCL-02.ad.syr.edu> Thanks, Scott, these are useful discussion points. see below ________________________________ From: Scott Leibrand [mailto:sleibrand at internap.com] > - If addresses are still available "for free" from ARIN, then an >argument has been made that the only people that would want to acquire >addresses via transfer in advance of exhaustion would be organizations >that don't qualify for space under current policy. But the ARIN policy doesn't allow you to receive addresses via transfer if they think you don't qualify under current policy anyway. You have to "prequalify." See Section 8.3.2. (This I think will prove to be a fatal flaw in the policy but that goes to another question.) > - If, as in 2008-2, we allow the transfer of legacy class C's (/24s), >then allowing people to start using the policy early would constitute an >end run around the /22 limitation in the current PI policy. In other >words, organizations that wouldn't qualify to get PI space would be able >to acquire it on the transfer market instead. At first blush this doesn't strike me as an inherently bad thing. Can you tell me what harm it does? >The main counterarguments to waiting too long to start allowing >transfers is that we'd like to work out the kinks in the system before >exhaustion hits, and that getting started early allows the market to >gradually settle on a price as volume gradually increases. Another argument is that address blocks are pretty fungible, so if I get an address block from source A instead of ARIN, then ARIN has more to give out the traditional way. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Fri Jun 20 10:11:04 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 20 Jun 2008 10:11:04 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? References: Message-ID: <7663C7E01D8E094989CA62F0B0D21CD90188411B@SUEXCL-02.ad.syr.edu> ________________________________ From: Ted Mittelstaedt [mailto:tedm at ipinc.net] This is the kind of response I had hoped I wouldn't get. I know there are ideologically motivated people who think it is evil to trade addresses, or "immoral" to hold on to more than you actally "need" (as if "address need" were some stable, fixed and objectively verifiable attribute of any network). But if that is your position, then there should be no transfer policy at all, right? So while it is evident that that attitude has shaped the nature of ARIN's policy, it is not really relevant to defining a transfer policy once you decide to have one. >ARIN policy isn't supposed to be based on an economic rationale. Um. Policies pertaining to scarce resources used by global industries that aren't grounded in sound economic concepts about actual behavior under conditions of scarcity cannot succeed. The greatest good for the greatest number cannot be achieved without taking actors' economic incentives into account. See below. >By definition, if you have "too much" address space then you >are required under the RSA you signed to return it. Why - because [snip] >Therefore your hypothetical situation -cannot- exist pre-IPv4 runout. Your statement describes an idealized interpretation of what you consider to be a moral obligation. It does not describe how people actually behave. Thus, your statement that the situatuion "cannot" exist is factually incorrect. The situation does exist, and everyone knows it does. Further, the situation exists both before and after IANA's free pool exhaustion. >The modification of the ARIN requirements to permit "selling" >effectively modifies the existing RSAs that people have signed, >because it basically says that "After IPv4-runout we don't give a crap >how you got your IPv4, whether honestly or not, from this point on we all >have a clean slate" This is why such a policy is a horrible idea pre-IPv4 runout. OK, I am glad that you finally got around to attempting to answer my question. And your anwer is, presumably, that the "clean slate" facilitates the transfer of resources from people who value them less to people who value them more. And my simple observation is that if it makes sense to do that after IANA pool depletion, it makes sense to do it beforehand. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwhite at olp.net Fri Jun 20 10:30:50 2008 From: dwhite at olp.net (Dan White) Date: Fri, 20 Jun 2008 09:30:50 -0500 Subject: [arin-ppml] rwhoisd alternatives Message-ID: <485BBF1A.1020504@olp.net> Is anyone aware of any alternatives to rwhoisd (http://www.rwhois.net)? Preferably open source. We investigating ways of pulling/caching customer information, for whois queries, from our billing system. Thanks, - Dan White BTC Broadband From tvest at pch.net Fri Jun 20 10:35:24 2008 From: tvest at pch.net (Tom Vest) Date: Fri, 20 Jun 2008 10:35:24 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD90188411B@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD90188411B@SUEXCL-02.ad.syr.edu> Message-ID: <89DE3E4A-4A54-4961-BDB3-D9A7BC2AC128@pch.net> On Jun 20, 2008, at 10:11 AM, Milton L Mueller wrote: > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > This is the kind of response I had hoped I wouldn't get. I know > there are ideologically motivated people who think it is evil to > trade addresses, or "immoral" to hold on to more than you actally > "need" (as if "address need" were some stable, fixed and objectively > verifiable attribute of any network). But if that is your position, > then there should be no transfer policy at all, right? So while it > is evident that that attitude has shaped the nature of ARIN's > policy, it is not really relevant to defining a transfer policy once > you decide to have one. > >ARIN policy isn't supposed to be based on an economic rationale. > > Um. Policies pertaining to scarce resources used by global > industries that aren't grounded in sound economic concepts about > actual behavior under conditions of scarcity cannot succeed. The > greatest good for the greatest number cannot be achieved without > taking actors' economic incentives into account. See below. > > >By definition, if you have "too much" address space then you > >are required under the RSA you signed to return it. Why - because > [snip] > >Therefore your hypothetical situation -cannot- exist pre-IPv4 runout. > > Your statement describes an idealized interpretation of what you > consider to be a moral obligation. It does not describe how people > actually behave. Thus, your statement that the situatuion "cannot" > exist is factually incorrect. The situation does exist, and everyone > knows it does. Further, the situation exists both before and after > IANA's free pool exhaustion. > > >The modification of the ARIN requirements to permit "selling" > >effectively modifies the existing RSAs that people have signed, > >because it basically says that "After IPv4-runout we don't give a > crap > >how you got your IPv4, whether honestly or not, from this point on > we all > >have a clean slate" This is why such a policy is a horrible idea > pre-IPv4 runout. > > OK, I am glad that you finally got around to attempting to answer my > question. And your anwer is, presumably, that the "clean slate" > facilitates the transfer of resources from people who value them > less to people who value them more. And my simple observation is > that if it makes sense to do that after IANA pool depletion, it > makes sense to do it beforehand. > Hi Milton, Following this logic, would you also say that the distribution of address resources should have always been determined through direct competition between those who value them more (i.e., are willing willing/able to pay more for them) and everyone else (ala RFC 1744, contra the "Address Ownership Considered Fatal" argument that prevailed back in the mid-1990s)? If the answer is "no", is the differentiating factor the existence of a "free pool" from which addresses can be allocated on some other, noncompetitive basis? If this answer to the second question is "yes", then which would you value more highly, or advocate more strongly: making due without whatever benefits recommended the old order, or taking steps to preserve those benefits, e.g., by maintaining something like a "free pool"? Thanks, TV From sleibrand at internap.com Fri Jun 20 10:35:47 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 20 Jun 2008 07:35:47 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD90188411B@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD90188411B@SUEXCL-02.ad.syr.edu> Message-ID: <485BC043.50304@internap.com> Milton L Mueller wrote: > And my simple observation is that if it > makes sense to do that after IANA pool depletion, it makes sense to do > it beforehand. For what it's worth, the Denver meeting seemed to agree with you. The meeting transcript reads: "On the assumption that ARIN continues work on the policy proposal and maintains a need-based qualification of recipients, all those in favor of an effective date sooner than the IANA IPv4 free pool depletion, raise your hand. ... On the matter of an earlier effective date than the IPv4 depletion date, in favor, 35; opposed, 13. This information will be provided to the AC for their consideration." So, perhaps the question should be: what would be a better "earlier effective date"? -Scott From mueller at syr.edu Fri Jun 20 10:25:31 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 20 Jun 2008 10:25:31 -0400 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freeze period? Message-ID: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu> In the ARIN proposal, the releasing party cannot have received any IPv4 addresses, either from ARIN or from transfers, in the past 24 months, and cannot request any for the next 24 months. So anyone who participates on the release side of a transfer must remove themselves from the ARIN v4 allocation/assignment process for a total of four years. Ostensibly, the rationale here is to prevent hoarding and speculation. But it seems like overkill. Is this intended to be punitive? Is the rationale really a Ted-style "you immoral bastards held on to address space you didn't need and so now we're going to screw you back" kind of an attitude? The problem here is the huge disincentive it creates to release any address space. Unless the address block involved and the money exchanged is pretty darn large and the entity has zero chance of asking for any more ipv4, who's going to put up with a 4-year time out from mama ARIN? What's your goal here -- do you want to rub people's noses in the need-based ideology or do you want to get them to give up addresses? Wouldn't it be simpler to block speculation the way RIPE proposes, and simply restrict -- on the recipient side -- transfer of the received addresses for two years? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgrundemann at gmail.com Fri Jun 20 10:38:50 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 20 Jun 2008 08:38:50 -0600 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD90188411B@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD90188411B@SUEXCL-02.ad.syr.edu> Message-ID: <443de7ad0806200738h596dcd72tf4b49da2e3a48cbe@mail.gmail.com> On Fri, Jun 20, 2008 at 8:11 AM, Milton L Mueller wrote: >>________________________________ >> From: Ted Mittelstaedt [mailto:tedm at ipinc.net] >>By definition, if you have "too much" address space then you >>are required under the RSA you signed to return it. Why - because [snip] > >>Therefore your hypothetical situation -cannot- exist pre-IPv4 runout. > > Your statement describes an idealized interpretation of what you consider to > be a moral obligation. It does not describe how people actually behave. > Thus, your statement that the situatuion "cannot" exist is factually > incorrect. The situation does exist, and everyone knows it does. Further, > the situation exists both before and after IANA's free pool exhaustion. > Leaving morality out of it for the moment, there are contractual obligations here (RSA). Are you suggesting that the contracts signed with ARIN do not matter or that they should not matter? If everyone followed the terms of the RSA they signed and returned unused and unneeded space, we would be facing a smaller problem. If legacy space holders also decided to do the right thing for the community and return their unused space we might face no problem at all (if these two statements are false then a transfer policy won't help anyway). In reality, the only need for a transfer policy seems to be to motivate people to do what they should already be doing... I guess we are back to morality after all. > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. > > -- Chris Grundemann www.linkedin.com/in/cgrundemann From dogwallah at gmail.com Fri Jun 20 10:50:15 2008 From: dogwallah at gmail.com (McTim) Date: Fri, 20 Jun 2008 17:50:15 +0300 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freeze period? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu> Message-ID: On Fri, Jun 20, 2008 at 5:25 PM, Milton L Mueller wrote: > > In the ARIN proposal, the releasing party cannot have received any IPv4 > addresses, either from ARIN or from transfers, in the past 24 months, and > cannot request any for the next 24 months. So anyone who participates on the > release side of a transfer must remove themselves from the ARIN v4 > allocation/assignment process for a total of four years. > > Ostensibly, the rationale here is to prevent hoarding and speculation. But > it seems like overkill. Is this intended to be punitive? probably not Milton. Prohibitive perhaps, but not punitive. Is the rationale > really a Ted-style "you immoral bastards held on to address space you didn't > need and so now we're going to screw you back" kind of an attitude? I don't see that, what I see is "if you have free blocks to flog off, then you won't need any more for a while, will you" rationale. > > The problem here is the huge disincentive it creates to release any address > space. Unless the address block involved and the money exchanged is pretty > darn large and the entity has zero chance of asking for any more ipv4, who's > going to put up with a 4-year time out from mama ARIN? Those who are moving to IPv6?!? What's your goal here > -- do you want to rub people's noses in the need-based ideology or do you > want to get them to give up addresses? Encourage v6 uptake is certainly a goal. > Wouldn't it be simpler to block speculation the way RIPE proposes, and > simply restrict -- on the recipient side -- transfer of the received > addresses for two years? Well, if it's simplicity your after in re: deterring speculation, simply keep the status quo. -- Cheers, McTim $ whois -h whois.afrinic.net mctim From mueller at syr.edu Fri Jun 20 11:10:53 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 20 Jun 2008 11:10:53 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? References: <7663C7E01D8E094989CA62F0B0D21CD90188411B@SUEXCL-02.ad.syr.edu> <443de7ad0806200738h596dcd72tf4b49da2e3a48cbe@mail.gmail.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901884122@SUEXCL-02.ad.syr.edu> ________________________________ From: Chris Grundemann [mailto:cgrundemann at gmail.com] >Leaving morality out of it for the moment, there are contractual >obligations here (RSA). Are you suggesting that the contracts signed >with ARIN do not matter or that they should not matter? Should not matter. First, a lot of legacy space is outside any RSA. Second, a contract that asks people to do things not in their interest and then provides no enforceable mechanism for ensuring compliance, and isn't enforced for 5-10 years, is not something to get hung up on. Third, returning address space takes time and effort; inertia doesn't take any, so you're asking them to incur expenses for an action that yields them no benefit. Four, "need" is not an objective quantity; they may think they need the addresses until the prospect of economic gains from trade makes them give the sitaution another look. >In reality, the only need for a transfer policy seems to be to >motivate people to do what they should already be doing... That's a common, well-known feature of the price system. You can talk until blue in the face about global warming and the need to reduce energy consumption, but isn't it interesting how people didn't really stop buying gas guzzlers until the price of gas doubled. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Fri Jun 20 11:19:31 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 20 Jun 2008 11:19:31 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? References: <7663C7E01D8E094989CA62F0B0D21CD90188411B@SUEXCL-02.ad.syr.edu> <485BC043.50304@internap.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901884124@SUEXCL-02.ad.syr.edu> As soon as the policy passes. No time to game the system ________________________________ From: Scott Leibrand [mailto:sleibrand at internap.com] Sent: Fri 6/20/2008 10:35 AM To: Milton L Mueller Cc: PPML ppml Subject: Re: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? Milton L Mueller wrote: > And my simple observation is that if it > makes sense to do that after IANA pool depletion, it makes sense to do > it beforehand. For what it's worth, the Denver meeting seemed to agree with you. The meeting transcript reads: "On the assumption that ARIN continues work on the policy proposal and maintains a need-based qualification of recipients, all those in favor of an effective date sooner than the IANA IPv4 free pool depletion, raise your hand. ... On the matter of an earlier effective date than the IPv4 depletion date, in favor, 35; opposed, 13. This information will be provided to the AC for their consideration." So, perhaps the question should be: what would be a better "earlier effective date"? -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From marla.azinger at frontiercorp.com Fri Jun 20 11:18:56 2008 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Fri, 20 Jun 2008 11:18:56 -0400 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In-Reply-To: <4859EB83.1050609@psg.com> References: <4847F8EF.5070709@arin.net> <616812070806182134s3fab1fe6ub6f1c9dcf96089bc@mail.gmail.com> <4859EB83.1050609@psg.com> Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1047F8628D56@ROCH-EXCH1.corp.pvt> Randy's answer should suffice. But since its asked despite it being in the rational of the proposal I will re-word it. If a more point blank explanation is needed maybe this one will work: Its a waste of time and money for both parties (ARIN Staff and Experimenter). One year is a short timeframe for any experiment to have to take time out for administrivia. And while 1 year is a waste of time for both parties it wont do any harm to push it out to 2 years which is a more realistic time frame for an experimenter to really figure out if they have something worth pursuing or not. And it does NO harm to change it. And yes there is an experiment with this space in progress which is why this bit of ridiculous adminsitrivia with a short time frame came up. Cheers Marla -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Randy Bush Sent: Wednesday, June 18, 2008 10:16 PM To: heather skanks Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe heather skanks wrote: > Is the argument that renewing an experimental allocation every year is a > hardship? Would anyone care to post about their experiences with an > experimental allocation and the renewal process? it's fairly easy, just administrivia and money > Can the authors or someone on list, give a current example of a "true > experiment in technical nature that addresses the internet > architecture and routing" that is adversely affected by the 1 year renewal requirement? it's just administrivia and money randy _______________________________________________ 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From stephen at sprunk.org Fri Jun 20 11:39:34 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 20 Jun 2008 10:39:34 -0500 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> Message-ID: <485BCF36.90101@sprunk.org> Milton L Mueller wrote: > Let's start with a fairly simple question. The ARIN proposal says that > the transfers it authorizes only start "when IANA allocates its last > unallocated unicast IPv4 address block." What is the economic rationale > for this? > > If I have too much address space now, and someone else wants it, what is > the social benefit of requiring me to wait for IANA's "last unallocated > unicast ipv4 address block" to be dropped? > I see no social benefit to that, and see some benefit to not having that requirement. The thinking goes, AIUI, that people are supposed to be returning unused space today for free, but it doesn't matter so much if they don't. After exhaustion, it will matter much more, so we will allow financial incentives to get them to do so. However, with the possibility of that financial incentive tomorrow, who in their right mind would voluntarily return space today for free? If we start allowing folks to put their blocks on the market now, even if there is no demand yet, then we prime the pump for when ARIN no longer has any "free" space to hand out and the demand suddenly materializes. We may also get a preview of what the market price is, which may provide interesting input to the policy process to fine-tune things before crunch time hits. S From owen at delong.com Fri Jun 20 12:09:17 2008 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Jun 2008 09:09:17 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <485BCF36.90101@sprunk.org> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> Message-ID: <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> > However, with the possibility of that financial incentive tomorrow, > who > in their right mind would voluntarily return space today for free? If > we start allowing folks to put their blocks on the market now, even if > there is no demand yet, then we prime the pump for when ARIN no longer > has any "free" space to hand out and the demand suddenly materializes. > We may also get a preview of what the market price is, which may > provide > interesting input to the policy process to fine-tune things before > crunch time hits. > The policy proposal talks about IANA freepool exhaustion, not ARIN freepool exhaustion. The thinking was that would prime the pump prior to ARIN runout, but, not too early so as to create other problems. When we started the process of developing this policy, I regarded the ability to do these kinds of transfers as a potential necessary but undesirable thing that would have to be tolerated during the post-runout and pre-ipv6 time gap. Having observed all of the discussion and attempts to tweak the policy to avoid speculators, gaming the system, etc., and also believing that this policy has the strong potential to create a class system that I consider highly undesirable on the internet, I have become more and more convinced that there is no way to implement such a policy without doing more harm than good. As such, I, personally am of the opinion that we should simply live with the existing mechanism until there are no addresses to allocate/assign and then move to IPv6 for all future allocations or assignments from ARIN. I do not take this lightly, nor do I necessarily expect this to be a popular opinion widely shared by my colleagues (although I hope they will eventually come to similar conclusions). However, I see a trading market in address space as having a great potential to change the characteristic of the internet in very harmful ways. I do not believe that allowing address space to flow only to those with the greatest financial resources is in the best interests of the internet. That is one predictable outcome of an address trading market. I do not believe that speculation will improve the distribution of IP addresses, but, I do not believe a market without speculation/speculators is possible without burdensome regulations which make the market somewhat impractical. I question ARINs ability to enforce such regulations, and, I expect that there would be a constant struggle against these regulations in the policy process until the controls were eroded and a speculative market evolved. I think that the subprime mortgage and oil futures markets are examples of how professionally regulated markets fail to do the right thing, and I cannot imagine that we will somehow miraculously do better than the regulators in those markets. Finally, I do not believe that this proposal has very much potential to do actual good. I do not believe that the amount of address space which would be made available by enacting this policy proposal will make a significant difference in the date at which IPv4 scarcity becomes a serious problem, and, I don't see the market as making much in the way of resources available to the community until people start to turn down their IPv4 networks after having migrated to IPv6. By then, the lack of IPv4 addresses will be virtually irrelevant anyway. Owen From bicknell at ufp.org Fri Jun 20 12:22:55 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 20 Jun 2008 12:22:55 -0400 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1047F8628D56@ROCH-EXCH1.corp.pvt> References: <4847F8EF.5070709@arin.net> <616812070806182134s3fab1fe6ub6f1c9dcf96089bc@mail.gmail.com> <4859EB83.1050609@psg.com> <2E2FECEBAE57CC4BAACDE67638305F1047F8628D56@ROCH-EXCH1.corp.pvt> Message-ID: <20080620162255.GA74707@ussenterprise.ufp.org> In a message written on Fri, Jun 20, 2008 at 11:18:56AM -0400, Azinger, Marla wrote: > Its a waste of time and money for both parties (ARIN Staff and > Experimenter). One year is a short timeframe for any experiment > to have to take time out for administrivia. And while 1 year is a > waste of time for both parties it wont do any harm to push it out > to 2 years which is a more realistic time frame for an experimenter > to really figure out if they have something worth pursuing or not. > And it does NO harm to change it. For me, the critical item is not that there is administrivia after a year, it is the burden on staff and the experimenter. Based on ARIN's staff response I'm invisioing it goes something like this (having never had an experimental block myself): ARIN, Via E-Mail: Hi! It's been a year since you applied for your experimental block. We would like you to please confirm that you are still conducting the experiment and provide us with some documentation of your progress. Experimenter, Via E-Mail: Hi! The experiment is ongoing. Our web page is at http:://mybigexperiment.com/ with information on what we're doing. I did a presentation at IETF about it, archived at www.ietf.org/meeting123/presoABC.pdf, and I'm on the schedule at the next nanog as well. ARIN: Checks URLS. ARIN, Via E-Mail: Thanks! Talk to you next year. If my vision is accurate, then I don't believe the burden is large enough to waste a policy proposal on at this time. If my vision is inaccurate, then I would encourage someone to post a summary of how much time and effort the one year review took so we have some concrete data. Saying it took 5 hours of time and 30 e-mails to make staff happy would tell me we need to look into this in more detail. -- 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: 187 bytes Desc: not available URL: From bicknell at ufp.org Fri Jun 20 12:34:43 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 20 Jun 2008 12:34:43 -0400 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freeze period? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu> Message-ID: <20080620163443.GB74707@ussenterprise.ufp.org> In a message written on Fri, Jun 20, 2008 at 10:25:31AM -0400, Milton L Mueller wrote: > The problem here is the huge disincentive it creates to release any > address space. Unless the address block involved and the money > exchanged is pretty darn large and the entity has zero chance of > asking for any more ipv4, who's going to put up with a 4-year time out > from mama ARIN? What's your goal here -- do you want to rub people's > noses in the need-based ideology or do you want to get them to give up > addresses? Correction, a 2 year time out on IPv4 resources only. I think the interesting thought exercise here is consider if this restriction were that in place, that is: - ARIN has no more address space to give out. - You have excess resources at this moment. Unless the address holder has fully transitioned to IPv6 they will need more IPv4 resources in the future. They can't be obtained from ARIN, so selling resources now means future needs will have to be bought on the open market. Is the price going to go up or down before you need them? It's an interesting bet. My own feeling is anyone who believes they have a need the next two years would choose to hold on to their address space, rather than selling it and buying back more later at a unknown price. Thus I come up with the premise that no address holder who needs space in the next two years will sell it now and then come back trying to buy more later; it doesn't pass any reasonable risk/reward analysis. However, there is a class of people who might like to hold address space for shorter periods of time, speculators. I'm not as concerned about people who are in the market for the long haul (investors, if you will), but rather with those who play off volility in the market (day traders, if you will), as they tend to destabilize the market. Personally I might support a timeframe as short as 1 year, but no shorter. For the reasons above, I don't think 2 years is likely to be a burden to anyone actually using the space. I'd be interested in hearing an argument as to why someone might want to sell excess space and then buy on the open market in a year timeframe. -- 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: 187 bytes Desc: not available URL: From paul at vix.com Fri Jun 20 12:49:34 2008 From: paul at vix.com (Paul Vixie) Date: Fri, 20 Jun 2008 16:49:34 +0000 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: Your message of "Fri, 20 Jun 2008 09:09:17 MST." <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> Message-ID: <86372.1213980574@sa.vix.com> without commenting on the merits of your "no transfers allowed" policy recommendation, i do have questions about one thing you've said here: > I do not believe that allowing address space to flow only to those with the > greatest financial resources is in the best interests of the internet. That > is one predictable outcome of an address trading market. isn't this inevitable in times of shortage, regardless of the shade (regulated or unregulated) of the market that inevitably occurs when humans face shortages? if it is, then our choice is not whether a market appears, but rather, whether that inevitable market is regulated or unregulated. > I think that the subprime mortgage and oil futures markets are examples of > how professionally regulated markets fail to do the right thing, and I > cannot imagine that we will somehow miraculously do better than the > regulators in those markets. do you think that the oil and gas situation right now would be worse or better if that market were less regulated than it is? if you think it would be worse then could it not also be the case that the professionals who regulate that market could be part of a vast corrupt kleptocracy, or institutionally incompetent, or just less well rewarded/motivated/resourced than those they regulate? in short can you explain why you consider this a parallel case? From tvest at pch.net Fri Jun 20 12:55:40 2008 From: tvest at pch.net (Tom Vest) Date: Fri, 20 Jun 2008 12:55:40 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901884122@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD90188411B@SUEXCL-02.ad.syr.edu> <443de7ad0806200738h596dcd72tf4b49da2e3a48cbe@mail.gmail.com> <7663C7E01D8E094989CA62F0B0D21CD901884122@SUEXCL-02.ad.syr.edu> Message-ID: <77BF5D7B-1731-4234-8FE7-1FCA2AC715AE@pch.net> On Jun 20, 2008, at 11:10 AM, Milton L Mueller wrote: > From: Chris Grundemann [mailto:cgrundemann at gmail.com] > >Leaving morality out of it for the moment, there are contractual > >obligations here (RSA). Are you suggesting that the contracts signed > >with ARIN do not matter or that they should not matter? > > Should not matter. First, a lot of legacy space is outside any RSA. > The contract was predated by, and generally (just) codifies the norms of the address resource-using community. > Second, a contract that asks people to do things not in their > interest and then provides no enforceable mechanism for ensuring > compliance, and isn't enforced for 5-10 years, is not something to > get hung up on. > Since by any plausible measure the (vast, I'd venture) majority of address resource users have complied to date, even with other terms of the agreement that are not in their immediate interest -- despite the alleged unenforceability and historical non-enforcement of the RSA -- I can only conclude that those norms must be pretty powerful. Norms may not have the same power as "laws of physics," so there will always be deviations, as well as mis-specifications -- just as there are with black letter law. Could you please elaborate on your basis for summarily dismissing those norms? Which norms do you think would be superior -- or do you really advocate some kind of market power absolutism? > Third, returning address space takes time and effort; inertia > doesn't take any, so you're asking them to incur expenses for an > action that yields them no benefit. > Yes, norms have no efficacy, so I suppose it would follow that good will and favorable PR have no utility. > Four, "need" is not an objective quantity; they may think they need > the addresses until the prospect of economic gains from trade makes > them give the sitaution another look. > How about the economic gains from excluding others from trade -- e.g., strategic rationing, price predation, etc.? Those can be equally if not more compelling, especially if a critical, non-substitutable, bottleneck input is at stake. Today, the norms of the community, as baked into address resource policies, practices, and institutions prevent that from occurring -- must be, since the contracts are unenforceable and unenforced, right? Too bad other industries don't seem to have similar norms -- but I guess we can find out what that's like for ourselves once the last vestiges of the old norms are eroded away. So long as "need" is not determined solely by individual address seekers, but rather by the aspiring address recipient and the address resource community that defines a common policy, it *is* objective -- or at the very least, inter-subjective -- and in a domain-specific context. Why should that allocation scheme be considered inferior to one in which anyone with (the most) wealth, obtained by any means, can preempt and rewrite the rules to suit themselves? I think you should be more careful -- or at least more explicit -- about what you wish for. One person's "hypocrisy" (imperfect adherence to a belief that itself remains unchallenged) may be another person's pursuit of social change or affective education... What norms you espouse in academia, or in "Internet governance"? TV . From owen at delong.com Fri Jun 20 13:08:05 2008 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Jun 2008 10:08:05 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <86372.1213980574@sa.vix.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> Message-ID: On Jun 20, 2008, at 9:49 AM, Paul Vixie wrote: > without commenting on the merits of your "no transfers allowed" policy > recommendation, i do have questions about one thing you've said here: > >> I do not believe that allowing address space to flow only to those >> with the >> greatest financial resources is in the best interests of the >> internet. That >> is one predictable outcome of an address trading market. > > isn't this inevitable in times of shortage, regardless of the shade > (regulated > or unregulated) of the market that inevitably occurs when humans face > shortages? if it is, then our choice is not whether a market > appears, but > rather, whether that inevitable market is regulated or unregulated. > I don't accept your premise that a market is inevitable. I do believe that some black market trades will occur, but, that if they become significant, it will become exponentially difficult to get those traded addresses routed and thus the black market will rapidly collapse if it ever becomes significant. I think that if a very small black market continues, there's little we can do about that, but, at least this will keep it relatively small. >> I think that the subprime mortgage and oil futures markets are >> examples of >> how professionally regulated markets fail to do the right thing, >> and I >> cannot imagine that we will somehow miraculously do better than the >> regulators in those markets. > > do you think that the oil and gas situation right now would be worse > or better > if that market were less regulated than it is? if you think it > would be worse > then could it not also be the case that the professionals who > regulate that > market could be part of a vast corrupt kleptocracy, or institutionally > incompetent, or just less well rewarded/motivated/resourced than > those they > regulate? in short can you explain why you consider this a parallel > case? I think it would be far worse. I think that with no regulation, the speculators who first crippled the mortgage markets would have us paying close to $10/gallon for gasoline by now. Yes, it is possible that the regulators are corrupt, incompetent, etc. However, while I believe ARIN to be likely to be less corrupt, I do not believe us likely to be more competent at market regulation. I am quite certain that ARIN would also be less well rewarded/resourced than those they regulate if this were to become a target for speculators. I consider this a parallel case because it is a market that is likely to attract speculators if it is not regulated in such a way as to prevent them. Further, I believe that the backlash against the various anti- speculation provisions of the proposed policy is reasonable evidence that such regulation would be burdensome and undesirable to the community. A market without such regulation would, in my opinion be quite harmful. As such, no market and no such regulation seems the safest course. Owen From paul at vix.com Fri Jun 20 13:10:52 2008 From: paul at vix.com (Paul Vixie) Date: Fri, 20 Jun 2008 17:10:52 +0000 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: Your message of "Fri, 20 Jun 2008 10:08:05 MST." References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> Message-ID: <87333.1213981852@sa.vix.com> > > isn't this inevitable in times of shortage, ... > I don't accept your premise that a market is inevitable. what else have you ever seen humans do in times of shortage? you have all of recorded human history to draw from. show us some alternatives. From marla.azinger at frontiercorp.com Fri Jun 20 13:18:38 2008 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Fri, 20 Jun 2008 13:18:38 -0400 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In-Reply-To: <20080620162255.GA74707@ussenterprise.ufp.org> References: <4847F8EF.5070709@arin.net> <616812070806182134s3fab1fe6ub6f1c9dcf96089bc@mail.gmail.com> <4859EB83.1050609@psg.com> <2E2FECEBAE57CC4BAACDE67638305F1047F8628D56@ROCH-EXCH1.corp.pvt> <20080620162255.GA74707@ussenterprise.ufp.org> Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1047F8628F29@ROCH-EXCH1.corp.pvt> Leo- While your idea of how is should go down would be simple and easy, the interpretation is that it requires more than that. And it doesn't say ARIN will contact them via a simple email to ask "hey are you using it?". It says the experimenter must apply for renewal with details. And honestly I wish a proposal wasn't needed to change 1 year to 2 years. Its a simple change that would cut out an early hit of administrivia and should just be able to be changed in a much simpler way. It doesn't effect the intent of the policy it just adjusts a timeframe that is more realistic. As far as historical, we are talking about IPv6. And whether its experimental space or someone is just using their direct allocation for experimenting in the lab before publicly routing it, I'm seeing more than one year become a norm for testing and experimenting with IPv6. The point is, experimenting usually takes more than a year. In short. This is time effecting trivia and I really didn't expect it to be such a debate. Debating how much time we waste for the renewal even makes me laugh. To debate what level of a pain in the ass threshold needs to exist before we change something is really very humorous. I really didn't see this proposal as such a "thinker". In a nut shell it looks like this part of our policy was written without much thought or maybe a lack of experience with experimenting was the culprit, I don't know and I really don't want to start that debate. So when someone in our community approached me about this I decided to submit a simple realistic change. It's really very simple. 1 year is a short timeframe when it comes to experimenting and I don't think we should waste peoples time on applying for renewal after just 1 year. Cheers Marla -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Friday, June 20, 2008 9:23 AM To: Azinger, Marla Cc: Randy Bush; heather skanks; arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In a message written on Fri, Jun 20, 2008 at 11:18:56AM -0400, Azinger, Marla wrote: > Its a waste of time and money for both parties (ARIN Staff and > Experimenter). One year is a short timeframe for any experiment to > have to take time out for administrivia. And while 1 year is a waste > of time for both parties it wont do any harm to push it out to 2 years > which is a more realistic time frame for an experimenter to really > figure out if they have something worth pursuing or not. > And it does NO harm to change it. For me, the critical item is not that there is administrivia after a year, it is the burden on staff and the experimenter. Based on ARIN's staff response I'm invisioing it goes something like this (having never had an experimental block myself): ARIN, Via E-Mail: Hi! It's been a year since you applied for your experimental block. We would like you to please confirm that you are still conducting the experiment and provide us with some documentation of your progress. Experimenter, Via E-Mail: Hi! The experiment is ongoing. Our web page is at http:://mybigexperiment.com/ with information on what we're doing. I did a presentation at IETF about it, archived at www.ietf.org/meeting123/presoABC.pdf, and I'm on the schedule at the next nanog as well. ARIN: Checks URLS. ARIN, Via E-Mail: Thanks! Talk to you next year. If my vision is accurate, then I don't believe the burden is large enough to waste a policy proposal on at this time. If my vision is inaccurate, then I would encourage someone to post a summary of how much time and effort the one year review took so we have some concrete data. Saying it took 5 hours of time and 30 e-mails to make staff happy would tell me we need to look into this in more detail. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From owen at delong.com Fri Jun 20 13:27:22 2008 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Jun 2008 10:27:22 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <87333.1213981852@sa.vix.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <87333.1213981852@sa.vix.com> Message-ID: On Jun 20, 2008, at 10:10 AM, Paul Vixie wrote: >>> isn't this inevitable in times of shortage, ... > >> I don't accept your premise that a market is inevitable. > > what else have you ever seen humans do in times of shortage? you > have all of > recorded human history to draw from. show us some alternatives. I have seen the following in history: Cooperative rationing The Donner Party Markets Black Markets Gray Markets Enforced rationing War Famine Obviously, some of these approaches have yielded better results in some circumstances than other. The Donner Party being an example of a particularly poor outcome. However, most of human history that you are referring to applies to shortages that were temporary in nature. The current legitimate market in Ivory in the US would be a good parallel example worth considering for something which will not be replenished at some future point. There are actually very few shortages in human history which are parallel in this nature, but, the ones that do exist which I am aware of show how markets drove the price up until we finally hunted the animal to extinction and then the market collapsed. In this case, we have the option of just watching the extinction occur without creating a market and all of the economic damage that follows as a result of such a markets bubble and eventual collapse. OTOH, the perceived shortage of tulips provides another interesting and potentially entertaining study in why natural human market behavior may not exactly be a good thing. Owen From tvest at pch.net Fri Jun 20 13:30:29 2008 From: tvest at pch.net (Tom Vest) Date: Fri, 20 Jun 2008 13:30:29 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <87333.1213981852@sa.vix.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <87333.1213981852@sa.vix.com> Message-ID: <22534561-3D17-4BDD-986B-20E5621B5895@pch.net> On Jun 20, 2008, at 1:10 PM, Paul Vixie wrote: >>> isn't this inevitable in times of shortage, ... > >> I don't accept your premise that a market is inevitable. > > what else have you ever seen humans do in times of shortage? you > have all of > recorded human history to draw from. show us some alternatives. Sometimes they perceive a better possibility on the far side of that "shortage", and being uncertain that a random walk (competitive marathon?) of diverse individuals with unequal capacities, diverse motives, and imperfect information will ever get them there -- and rather than risk the possibility of never making it across, they decide to embark on a collaborative, cooperative effort. Examples: The Marshall Plan European Monetary Union The last addressing & routing crisis TV From bicknell at ufp.org Fri Jun 20 13:38:53 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 20 Jun 2008 13:38:53 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <86372.1213980574@sa.vix.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> Message-ID: <20080620173853.GA78555@ussenterprise.ufp.org> In a message written on Fri, Jun 20, 2008 at 04:49:34PM +0000, Paul Vixie wrote: > isn't this inevitable in times of shortage, regardless of the shade (regulated > or unregulated) of the market that inevitably occurs when humans face > shortages? if it is, then our choice is not whether a market appears, but > rather, whether that inevitable market is regulated or unregulated. Without getting into the details of implementation (and by extension, how various countries have implemented them over time)... The two extremes are capitalism, which generally leads to the rich getting what they need and the poor getting nothing, and socialism, which generally leads to everyone getting a proportional amount (possibly less than they need). However, I think "shortage" doesn't encompass the entire situation in this case. The really interesting question is one of fungibility. If your worry is that the poor eat then a freeze in Florida zapping the orange juice crop is not a big concern. Yes, the price of orange juice will rise, and only the rich will have orange juice; but it's not the case that the poor have nothing. They can have apple juice, or grape juice, or soda, or water, or lemonaid. To those on a budget beverage choice is highly fungible. This also has a great tempering effect on the orange juice market. When the price rises a small amount demand naturally eases, keeping the price from spiking to absurd levels. Compare with say, oil. For most consumers there's nothing they can put in their car tank besides gasoline, and swapping out the vehicle for a non-petroleum based vehicle is very difficult. A relatively modest supply issue causes huge spikes in the price as a result. So the debate hinges on how much you believe IPv4 and IPv6 are fungible. Are they like orange juice? If so it would take only a minor increase in IPv4 costs to drive people to IPv6, which would automatically prevent an IPv4 market from ever becoming a large, widespread thing. If you believe IPv4 is more like oil, and IPv6 is like hydrogen technology, promising but not yet ready then the lack of IPv4 will create a huge, volatile market as people panic since there is no real way they can move to IPv6. I personally happen to think they are relatively fungible. The mere fact that IPv4 is unavailable will drive people to IPv6, and any small market that develops (black, white, or grey) will only accelerate that trend. To that end any market is self-defeating; and I think very quickly so. If you believe, as I do, that the mere fact that there is no more IPv4 available from ARIN will drive people to IPv6 then I think it may well be the case that a "market" does not appear. (*) Others have different opinions. * Which is not to say I believe there will be zero transactions. Someone will hijack space, someone will sell, someone will buy. For there to be a real market, there must be multiple buyers, and sellers and some reasonably well defined way for them to meet. A few isolated individual transactions does not count, at least to me. -- 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: 187 bytes Desc: not available URL: From paul at vix.com Fri Jun 20 13:47:35 2008 From: paul at vix.com (Paul Vixie) Date: Fri, 20 Jun 2008 17:47:35 +0000 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: Your message of "Fri, 20 Jun 2008 13:38:53 -0400." <20080620173853.GA78555@ussenterprise.ufp.org> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> Message-ID: <88479.1213984055@sa.vix.com> > * Which is not to say I believe there will be zero transactions. > Someone will hijack space, someone will sell, someone will buy. > For there to be a real market, there must be multiple buyers, and > sellers and some reasonably well defined way for them to meet. > A few isolated individual transactions does not count, at least > to me. so, would it be better in your opinion that there not be such a market, which presumably would not occur without an ARIN transfer policy, since sellers would be in violation of their RSA's? or is the fact that most space in the world is legacy mean that such a market will come into existence (perhaps, created and operated by speculators?) no matter what ARIN does with 2008-2? From bicknell at ufp.org Fri Jun 20 13:57:00 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 20 Jun 2008 13:57:00 -0400 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1047F8628F29@ROCH-EXCH1.corp.pvt> References: <4847F8EF.5070709@arin.net> <616812070806182134s3fab1fe6ub6f1c9dcf96089bc@mail.gmail.com> <4859EB83.1050609@psg.com> <2E2FECEBAE57CC4BAACDE67638305F1047F8628D56@ROCH-EXCH1.corp.pvt> <20080620162255.GA74707@ussenterprise.ufp.org> <2E2FECEBAE57CC4BAACDE67638305F1047F8628F29@ROCH-EXCH1.corp.pvt> Message-ID: <20080620175700.GB78555@ussenterprise.ufp.org> In a message written on Fri, Jun 20, 2008 at 01:18:38PM -0400, Azinger, Marla wrote: > While your idea of how is should go down would be simple and easy, > the interpretation is that it requires more than that. And it > doesn't say ARIN will contact them via a simple email to ask "hey > are you using it?". It says the experimenter must apply for renewal > with details. I will go back to my original query. I would very much like someone who has used the experimental policy and completed one of these one year renewals to post about the actual pain level they encountered. I'm not interested in anyone's interpretation, I'm interested in actual implementation. Have you or Dave, as the authors, been through a 1 year renewal on an experimental allocation? Can you tell us, specifically, how much time and effort it took? What things ARIN staff required you to provide? -- 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: 187 bytes Desc: not available URL: From bicknell at ufp.org Fri Jun 20 14:07:56 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 20 Jun 2008 14:07:56 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <88479.1213984055@sa.vix.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <88479.1213984055@sa.vix.com> Message-ID: <20080620180756.GC78555@ussenterprise.ufp.org> In a message written on Fri, Jun 20, 2008 at 05:47:35PM +0000, Paul Vixie wrote: > so, would it be better in your opinion that there not be such a market, > which presumably would not occur without an ARIN transfer policy, since > sellers would be in violation of their RSA's? or is the fact that most > space in the world is legacy mean that such a market will come into > existence (perhaps, created and operated by speculators?) no matter what > ARIN does with 2008-2? Leaving aside the legacy space issue; I believe we would be better without a liberalize transfer policy. The reason is that technology transitions happen best when they are shared pain. For for example to Y2K. One, very specific date. Same (basic problem) for everyone who runs a computer. Because of these properties the troops were rallied, work was done, and it was almost entirely a non-issue. If there were a way to have all ISP's "run out" on the same date, and be able to predict that date with reasonable accuracy I'd be all for it. That to me would insure a fairly smooth transition to IPv6. A market is one mechanism to lengthen the amount of time over which the transition occurs. This will create increased costs for first movers (as development costs typically get spread to first movers), create competitive advantages and disadvantages in the market place, increase costs as customers with slow to move ISP's may need to move to fast to move ISP's if they themselves have a need and generally make the entire transition much worse. On the legacy space issue, that's a gigantic mistake that will go down in the history books. Better records should have been kept. Clear contracts should have been in place from day one; ARIN, IANA, ICANN, and the US government should have worked to solve this when ARIN was founded. We have close to three decades of head in the sand thinking when it comes to legacy space leading to all sorts of bit-rot and other problems. My only hope is that we move to IPv6 before it becomes a major issue; because the other path is to end up in court, and as any laywer will tell you there's always a chance that a judge or jury will make some totally random decision for no good reason, leaving you in an even bigger 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: 187 bytes Desc: not available URL: From randy at psg.com Fri Jun 20 14:26:30 2008 From: randy at psg.com (Randy Bush) Date: Sat, 21 Jun 2008 03:26:30 +0900 Subject: [arin-ppml] rwhoisd alternatives In-Reply-To: <485BBF1A.1020504@olp.net> References: <485BBF1A.1020504@olp.net> Message-ID: <485BF656.607@psg.com> Dan White wrote: > Is anyone aware of any alternatives to rwhoisd > (http://www.rwhois.net)? Preferably open source. /usr/ports/net/irrd randy From jay at handynetworks.com Fri Jun 20 14:21:10 2008 From: jay at handynetworks.com (Jay Sudowski - Handy Networks LLC) Date: Fri, 20 Jun 2008 12:21:10 -0600 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com><7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu><485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> Message-ID: <7EC421F755E45242A47938C3B6F634B1DA3A81@hnetavail1.exchange.handynetworks.com> For those of you who don't think a rational transfer policy is necessary, please consider the following: 1. In the real world, many people do not view ARIN postively. Business people (CEO types) who run companies that require portable IP space view ARIN as overly punative, prohibitive gatekeepers to a important resource that they need access to. Technicians in that have to deal with ARIN infrequently for initial IP allocations, additional allocations, etc hold ARIN in the same light. Due to this, if it often easier, far less stressful, and far less expensive in time/opportunity cost to "purchase" IP space or hire someone to interact with ARIN for you. Put simply and bluntly, ARIN is a pain in the ass to deal with. 2. I have been aware of people have been buying, selling and using subterfuge to obtain IP allocations for as long as I have been been in the industry (the past 8 years). Some examples: 2a. Three companies merge into one. For many months after they merged, they continued to interact with ARIN as separate entities, obtaining far more IP allocations than they would have been able to as a single entity. Even today, this single entity (which has now recently merged again), interacts with ARIN using two separate, but related entity names and two separate ORG IDs. 2b. Every month I run into people who are willing to sell me their /18, /19, /20 for a fee. It is my understanding that such transactions are usually structured so that other [usually worthless] assets or an entire shell entity are included in the sale to pass ARIN scrutiny. 2c. For a time, I did work for an entity that had previous bad blood with ARIN (see point 1) and managed to obtain 3 /18s on the after market. From what I gather, this is not all that unusual. 2d. There are consultants out there who, for a fee, guarantee you will get an IP allocation from ARIN. They are able to accomplish because they control a large amount of IP space for entities that they work for, and they SWIP out space from those entities to the entity paying them for the direct allocation. Bogus data is submitted to ARIN, the SWIP'd space supports the bogus allocation, and the allocation is granted. 2e. ARIN members continue to report IP usage by customers that have long since left their network, inflating their actual need and utilization percentages, allowing them to obtain unneccesary allocations from ARIN. For those of you who want to maintain the status quo, think about the above and then think about how the bad actors will multiply once IPv4 becomes truly scarce. It's one thing to be idealistic, it's another to be ignorant about what's happening _today_ and what will happen _in the future_. The academics on this list can continue to disucss the parallels between IPv4 depletion and Ivory, if there will even be a market for IP space, etc. Meanwhile, people operating in the real world, will do what they have to do to put food on their table and gas in their cars. As such, they will continue to do what they are doing today [see 2a-e] and will do so with increasing frequncy and neccessity as IP depletion becomes reality. The choice should be to either create a framework that attemps to define, regulate and bring some transparency an IP allocation trading/transfer market or simply come to the realization that the existing IP address marketplace, which exists in the hidden corners of the Internet, will continue to function and evolve as depletion comes closer and closer to reality. -Jay Sudowski -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, June 20, 2008 10:09 AM To: Stephen Sprunk Cc: ARIN PPML Subject: Re: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? > However, with the possibility of that financial incentive tomorrow, > who > in their right mind would voluntarily return space today for free? If > we start allowing folks to put their blocks on the market now, even if > there is no demand yet, then we prime the pump for when ARIN no longer > has any "free" space to hand out and the demand suddenly materializes. > We may also get a preview of what the market price is, which may > provide > interesting input to the policy process to fine-tune things before > crunch time hits. > The policy proposal talks about IANA freepool exhaustion, not ARIN freepool exhaustion. The thinking was that would prime the pump prior to ARIN runout, but, not too early so as to create other problems. When we started the process of developing this policy, I regarded the ability to do these kinds of transfers as a potential necessary but undesirable thing that would have to be tolerated during the post-runout and pre-ipv6 time gap. Having observed all of the discussion and attempts to tweak the policy to avoid speculators, gaming the system, etc., and also believing that this policy has the strong potential to create a class system that I consider highly undesirable on the internet, I have become more and more convinced that there is no way to implement such a policy without doing more harm than good. As such, I, personally am of the opinion that we should simply live with the existing mechanism until there are no addresses to allocate/assign and then move to IPv6 for all future allocations or assignments from ARIN. I do not take this lightly, nor do I necessarily expect this to be a popular opinion widely shared by my colleagues (although I hope they will eventually come to similar conclusions). However, I see a trading market in address space as having a great potential to change the characteristic of the internet in very harmful ways. I do not believe that allowing address space to flow only to those with the greatest financial resources is in the best interests of the internet. That is one predictable outcome of an address trading market. I do not believe that speculation will improve the distribution of IP addresses, but, I do not believe a market without speculation/speculators is possible without burdensome regulations which make the market somewhat impractical. I question ARINs ability to enforce such regulations, and, I expect that there would be a constant struggle against these regulations in the policy process until the controls were eroded and a speculative market evolved. I think that the subprime mortgage and oil futures markets are examples of how professionally regulated markets fail to do the right thing, and I cannot imagine that we will somehow miraculously do better than the regulators in those markets. Finally, I do not believe that this proposal has very much potential to do actual good. I do not believe that the amount of address space which would be made available by enacting this policy proposal will make a significant difference in the date at which IPv4 scarcity becomes a serious problem, and, I don't see the market as making much in the way of resources available to the community until people start to turn down their IPv4 networks after having migrated to IPv6. By then, the lack of IPv4 addresses will be virtually irrelevant anyway. Owen _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From randy at psg.com Fri Jun 20 14:37:15 2008 From: randy at psg.com (Randy Bush) Date: Sat, 21 Jun 2008 03:37:15 +0900 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1047F8628F29@ROCH-EXCH1.corp.pvt> References: <4847F8EF.5070709@arin.net> <616812070806182134s3fab1fe6ub6f1c9dcf96089bc@mail.gmail.com> <4859EB83.1050609@psg.com> <2E2FECEBAE57CC4BAACDE67638305F1047F8628D56@ROCH-EXCH1.corp.pvt> <20080620162255.GA74707@ussenterprise.ufp.org> <2E2FECEBAE57CC4BAACDE67638305F1047F8628F29@ROCH-EXCH1.corp.pvt> Message-ID: <485BF8DB.6010801@psg.com> > While your idea of how is should go down would be simple and easy, the interpretation is that it requires more than that. And it doesn't say ARIN will contact them via a simple email to ask "hey are you using it?". in fact, that is what arin does. just got one. please wrap lines reading this thread would lead one to think policy creators needed work randy From randy at psg.com Fri Jun 20 14:42:45 2008 From: randy at psg.com (Randy Bush) Date: Sat, 21 Jun 2008 03:42:45 +0900 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In-Reply-To: <20080620175700.GB78555@ussenterprise.ufp.org> References: <4847F8EF.5070709@arin.net> <616812070806182134s3fab1fe6ub6f1c9dcf96089bc@mail.gmail.com> <4859EB83.1050609@psg.com> <2E2FECEBAE57CC4BAACDE67638305F1047F8628D56@ROCH-EXCH1.corp.pvt> <20080620162255.GA74707@ussenterprise.ufp.org> <2E2FECEBAE57CC4BAACDE67638305F1047F8628F29@ROCH-EXCH1.corp.pvt> <20080620175700.GB78555@ussenterprise.ufp.org> Message-ID: <485BFA25.6000909@psg.com> > I would very much like someone who has used the experimental policy > and completed one of these one year renewals to post about the > actual pain level they encountered. how many times do you need me to do so? dealing with arin hostfolk is infinitely easier than reading the on this list. randy From bicknell at ufp.org Fri Jun 20 14:50:16 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 20 Jun 2008 14:50:16 -0400 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In-Reply-To: <4847F8EF.5070709@arin.net> References: <4847F8EF.5070709@arin.net> Message-ID: <20080620185016.GA85333@ussenterprise.ufp.org> As a bit of history: http://www.arin.net/policy/proposals/2002_2.html ARIN X: http://www.arin.net/meetings/minutes/ARIN_X/PDF/2002-2.pdf http://www.arin.net/meetings/minutes/ARIN_X/ppm_minutes.html#2002_2 ARIN XI: http://www.arin.net/meetings/minutes/ARIN_XI/PDF/Tuesday/1B_20022_Woolf.pdf http://www.arin.net/meetings/minutes/ARIN_XI/ppm_minutes_day2.html#2 ARIN XII: http://www.arin.net/meetings/minutes/ARIN_XII/PDF/Thursday/2002-2.pdf http://www.arin.net/meetings/minutes/ARIN_XII/ppm_minutes_day2.html#13 -- 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: 187 bytes Desc: not available URL: From cgrundemann at gmail.com Fri Jun 20 15:19:30 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 20 Jun 2008 13:19:30 -0600 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: <7EC421F755E45242A47938C3B6F634B1DA3A81@hnetavail1.exchange.handynetworks.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <7EC421F755E45242A47938C3B6F634B1DA3A81@hnetavail1.exchange.handynetworks.com> Message-ID: <443de7ad0806201219t40fa82d2o171a120ab1b3a56f@mail.gmail.com> On Fri, Jun 20, 2008 at 12:21 PM, Jay Sudowski - Handy Networks LLC wrote: > For those of you who don't think a rational transfer policy is > necessary, please consider the following: > > 1. In the real world, many people do not view ARIN postively. Business > people (CEO types) who run companies that require portable IP space view > ARIN as overly punative, prohibitive gatekeepers to a important resource > that they need access to. Technicians in that have to deal with ARIN > infrequently for initial IP allocations, additional allocations, etc > hold ARIN in the same light. Due to this, if it often easier, far less > stressful, and far less expensive in time/opportunity cost to "purchase" > IP space or hire someone to interact with ARIN for you. Put simply and > bluntly, ARIN is a pain in the ass to deal with. > > 2. I have been aware of people have been buying, selling and using > subterfuge to obtain IP allocations for as long as I have been been in > the industry (the past 8 years). Some examples: > > 2a. Three companies merge into one. For many months after they merged, > they continued to interact with ARIN as separate entities, obtaining far > more IP allocations than they would have been able to as a single > entity. Even today, this single entity (which has now recently merged > again), interacts with ARIN using two separate, but related entity names > and two separate ORG IDs. > > 2b. Every month I run into people who are willing to sell me their /18, > /19, /20 for a fee. It is my understanding that such transactions are > usually structured so that other [usually worthless] assets or an entire > shell entity are included in the sale to pass ARIN scrutiny. > > 2c. For a time, I did work for an entity that had previous bad blood > with ARIN (see point 1) and managed to obtain 3 /18s on the after > market. From what I gather, this is not all that unusual. > > 2d. There are consultants out there who, for a fee, guarantee you will > get an IP allocation from ARIN. They are able to accomplish because > they control a large amount of IP space for entities that they work for, > and they SWIP out space from those entities to the entity paying them > for the direct allocation. Bogus data is submitted to ARIN, the SWIP'd > space supports the bogus allocation, and the allocation is granted. > > 2e. ARIN members continue to report IP usage by customers that have long > since left their network, inflating their actual need and utilization > percentages, allowing them to obtain unneccesary allocations from ARIN. > > For those of you who want to maintain the status quo, think about the > above and then think about how the bad actors will multiply once IPv4 > becomes truly scarce. It's one thing to be idealistic, it's another to > be ignorant about what's happening _today_ and what will happen _in the > future_. > > The academics on this list can continue to disucss the parallels between > IPv4 depletion and Ivory, if there will even be a market for IP space, > etc. Meanwhile, people operating in the real world, will do what they > have to do to put food on their table and gas in their cars. As such, > they will continue to do what they are doing today [see 2a-e] and will > do so with increasing frequncy and neccessity as IP depletion becomes > reality. > > The choice should be to either create a framework that attemps to > define, regulate and bring some transparency an IP allocation > trading/transfer market or simply come to the realization that the > existing IP address marketplace, which exists in the hidden corners of > the Internet, will continue to function and evolve as depletion comes > closer and closer to reality. You are saying that these things happen today when IPv4 space is freely available. I will not (because I can not - I have seen some of these things as well) contest that fact. So that means that people / organizations are willing to break (bend) the rules today simply to avoid the "pain in the ass" that is the ARIN allocation process. Which leads me to ponder; why does a transfer policy change this in any way? People who are willing to break the rules do not care what rules you put in place. IMHO, a transfer policy actually has a greater chance of making this black market larger and stronger than it does of curbing it. This is because the public trade will help establish value and cause confusion. If IP number transfers are strictly prohibited, it is harder to mask a transfer and harder to set a value. Furthermore, any black market that does exist will mostly solve itself as IPv6 adoption occurs; the more of the Internet that becomes IPv6, the less v4 space will be worth. Therefor, the most effective way to stop the black market is to speed IPv6 proliferation, not allow transfers. ~Chris > > -Jay Sudowski > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Friday, June 20, 2008 10:09 AM > To: Stephen Sprunk > Cc: ARIN PPML > Subject: Re: [arin-ppml] Q1 - ARIN address transfer policy: why the > triggerdate? > >> However, with the possibility of that financial incentive tomorrow, >> who >> in their right mind would voluntarily return space today for free? If >> we start allowing folks to put their blocks on the market now, even if >> there is no demand yet, then we prime the pump for when ARIN no longer >> has any "free" space to hand out and the demand suddenly materializes. >> We may also get a preview of what the market price is, which may >> provide >> interesting input to the policy process to fine-tune things before >> crunch time hits. >> > The policy proposal talks about IANA freepool exhaustion, not ARIN > freepool exhaustion. The thinking was that would prime the pump > prior to ARIN runout, but, not too early so as to create other problems. > > When we started the process of developing this policy, I regarded > the ability to do these kinds of transfers as a potential necessary > but undesirable thing that would have to be tolerated during > the post-runout and pre-ipv6 time gap. > > Having observed all of the discussion and attempts to tweak the > policy to avoid speculators, gaming the system, etc., and also > believing that this policy has the strong potential to create > a class system that I consider highly undesirable on the > internet, I have become more and more convinced that there > is no way to implement such a policy without doing more > harm than good. > > As such, I, personally am of the opinion that we should simply > live with the existing mechanism until there are no addresses > to allocate/assign and then move to IPv6 for all future allocations > or assignments from ARIN. > > I do not take this lightly, nor do I necessarily expect this to be > a popular opinion widely shared by my colleagues (although > I hope they will eventually come to similar conclusions). > However, I see a trading market in address space as having > a great potential to change the characteristic of the internet > in very harmful ways. > > I do not believe that allowing address space to flow only to > those with the greatest financial resources is in the best > interests of the internet. That is one predictable outcome > of an address trading market. > > I do not believe that speculation will improve the distribution > of IP addresses, but, I do not believe a market without > speculation/speculators is possible without burdensome > regulations which make the market somewhat impractical. > > I question ARINs ability to enforce such regulations, and, I > expect that there would be a constant struggle against these > regulations in the policy process until the controls were eroded > and a speculative market evolved. > > I think that the subprime mortgage and oil futures markets are > examples of how professionally regulated markets fail > to do the right thing, and I cannot imagine that we will > somehow miraculously do better than the regulators in > those markets. > > Finally, I do not believe that this proposal has very much > potential to do actual good. I do not believe that the amount > of address space which would be made available by > enacting this policy proposal will make a significant > difference in the date at which IPv4 scarcity becomes a > serious problem, and, I don't see the market as making > much in the way of resources available to the community > until people start to turn down their IPv4 networks after > having migrated to IPv6. By then, the lack of IPv4 > addresses will be virtually irrelevant anyway. > > Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > -- Chris Grundemann www.linkedin.com/in/cgrundemann From randy at psg.com Fri Jun 20 15:26:05 2008 From: randy at psg.com (Randy Bush) Date: Sat, 21 Jun 2008 04:26:05 +0900 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: <443de7ad0806201219t40fa82d2o171a120ab1b3a56f@mail.gmail.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <7EC421F755E45242A47938C3B6F634B1DA3A81@hnetavail1.exchange.handynetworks.com> <443de7ad0806201219t40fa82d2o171a120ab1b3a56f@mail.gmail.com> Message-ID: <485C044D.9090907@psg.com> > People who are willing to break the rules do not care what rules you > put in place. this is the "they are bad people" theory, a subset of the black helicopter theme. repeat the following mantra a few times and the fear will go away. it's just business. they are just trying to get their work done. of course there are bad folk on the net; c.f. recent hijack allegations. but the current address traders seem to be consenting parties on both sides. they are just trying to get their work done despite amateur over-regulation. randy From paul at vix.com Fri Jun 20 15:32:30 2008 From: paul at vix.com (Paul Vixie) Date: Fri, 20 Jun 2008 19:32:30 +0000 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: Your message of "Sat, 21 Jun 2008 04:26:05 +0900." <485C044D.9090907@psg.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <7EC421F755E45242A47938C3B6F634B1DA3A81@hnetavail1.exchange.handynetworks.com> <443de7ad0806201219t40fa82d2o171a120ab1b3a56f@mail.gmail.com> <485C044D.9090907@psg.com> Message-ID: <91914.1213990350@sa.vix.com> > of course there are bad folk on the net; c.f. recent hijack allegations. > but the current address traders seem to be consenting parties on both > sides. they are just trying to get their work done despite amateur > over-regulation. > > randy there are more than two parties to these transactions. the community has a stake in every address allocation especially if it affects the global routing table but even if it does not. that there are two consenting adults may be true, but it's irrelevant since there are others who are being affected who are not being informed nor asked to consent. the mechanism for that informed consent is the RIR policy process. and while you may find it amateurish, i think it compares quite favourably to what happens in meatspace or telecoms, and i'd stack our community's brainpower, objectivity, goodwill, perspective, and experience up against any other regulation system anywhere in the world at any time in history. From cgrundemann at gmail.com Fri Jun 20 15:42:32 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 20 Jun 2008 13:42:32 -0600 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: <485C044D.9090907@psg.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <7EC421F755E45242A47938C3B6F634B1DA3A81@hnetavail1.exchange.handynetworks.com> <443de7ad0806201219t40fa82d2o171a120ab1b3a56f@mail.gmail.com> <485C044D.9090907@psg.com> Message-ID: <443de7ad0806201242k1004b7f6o4051e7110a857a2f@mail.gmail.com> On Fri, Jun 20, 2008 at 1:26 PM, Randy Bush wrote: >> People who are willing to break the rules do not care what rules you >> put in place. > > this is the "they are bad people" theory, a subset of the black > helicopter theme. > > repeat the following mantra a few times and the fear will go away. > > it's just business. > they are just trying to get their work done. > > of course there are bad folk on the net; c.f. recent hijack allegations. > but the current address traders seem to be consenting parties on both > sides. they are just trying to get their work done despite amateur > over-regulation. I was not trying to imply that anyone involved was necessarily "bad" (or "good" for that matter) and I definitely have no opinion on their mode of transportation ;). My point is that if a market (of sorts - term applied liberally) exists today when IP numbers are free and available, why would these market players go through the trouble of a sanctioned transfer in the future? Why (and/or how) will this policy (or any transfer policy) change existing behavior? I simply suggest that some will "just try to get their work done despite [perceived] amateur over-regulation" regardless of what that specific regulation is. ~Chris From tvest at pch.net Fri Jun 20 16:21:47 2008 From: tvest at pch.net (Tom Vest) Date: Fri, 20 Jun 2008 16:21:47 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <20080620173853.GA78555@ussenterprise.ufp.org> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> Message-ID: <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> Comments inline below. On Jun 20, 2008, at 1:38 PM, Leo Bicknell wrote: > In a message written on Fri, Jun 20, 2008 at 04:49:34PM +0000, Paul > Vixie wrote: >> isn't this inevitable in times of shortage, regardless of the shade >> (regulated >> or unregulated) of the market that inevitably occurs when humans face >> shortages? if it is, then our choice is not whether a market >> appears, but >> rather, whether that inevitable market is regulated or unregulated. > > Without getting into the details of implementation (and by extension, > how various countries have implemented them over time)... > > The two extremes are capitalism, which generally leads to the rich > getting what they need and the poor getting nothing, and socialism, > which generally leads to everyone getting a proportional amount > (possibly less than they need). > > However, I think "shortage" doesn't encompass the entire situation > in this case. The really interesting question is one of fungibility. > If your worry is that the poor eat then a freeze in Florida zapping > the orange juice crop is not a big concern. Yes, the price of > orange juice will rise, and only the rich will have orange juice; > but it's not the case that the poor have nothing. They can have > apple juice, or grape juice, or soda, or water, or lemonaid. To > those on a budget beverage choice is highly fungible. This also > has a great tempering effect on the orange juice market. When the > price rises a small amount demand naturally eases, keeping the price > from spiking to absurd levels. > > Compare with say, oil. For most consumers there's nothing they can > put in their car tank besides gasoline, and swapping out the vehicle > for a non-petroleum based vehicle is very difficult. A relatively > modest supply issue causes huge spikes in the price as a result. > > So the debate hinges on how much you believe IPv4 and IPv6 are > . Are they like orange juice? If so it > would take only a > minor increase in IPv4 costs to drive people to IPv6, which would > automatically prevent an IPv4 market from ever becoming a large, > widespread thing. If you believe IPv4 is more like oil, and IPv6 > is like hydrogen technology, promising but not yet ready then the > lack of IPv4 will create a huge, volatile market as people panic > since there is no real way they can move to IPv6. Hi Leo, I think that, purely from a protocol/software standpoint, an individual IPv6 address might be pretty close to substitutable for an individual IPv4 address, if not today then pretty soon. However, that narrow equivalence is dwarfed by other huge contrasts between IPv4 and IPv6 -- gaps that might easily be exacerbated or locked into place forever if IPv4 is privatized, or a decentralized "transfer market" is legitimized, if you prefer that terminology. Consider: Even if individual IPv6 and IPv4 addresses are technically equivalent to each other tomorrow, IPv4 could continue to be non- substitutable, and to have substantial "exchange value" (i.e., command a high price) for as long as most or all of the universe of "real Internet resources" (i.e., users, content, media, services, etc.) are attached to the Internet via IPv4. Randy has taught us all well: "IPv6 is not compatible on the wire". So, for long as that remains true, every operator that wishes to have even the potential to exchange traffic with that universe of legacy resources will need at least a few IPv4 addresses -- either PA from an incumbent ISP, or PI from an incumbent ISP (or maybe just an independent IPv4 "dealership"). Under most conceivable/internally consistent scenarios, incumbent ISPs (and/or non-operator speculators) eventually will be the only source for IPv4 for all practical purposes. Incumbents that actually use IPv4 may or may not be willing to part with any; in fact some will almost certainly continue buying IPv4 until the price becomes "really prohibitive". However, some incumbent IPv4 owners may be incentivized to sell some IPv4 to make money. If you are commercial operator (esp. one that is publicly traded), then your first job is to make as much money as possible -- maybe by adding customers, maybe by servicing growing customers, maybe just by commanding a higher margin across all customers, regardless of their growth rates. If you are adding customers, or your customers are growing, then (to repeat) maybe you're also an IPv4 buyer yourself -- and thus acutely conscious of the fact that anything you sell today you might need to buy back, perhaps at a much inflated price, in the future. However, if you think you can command a higher one-time price for selling off PI IPV4 today, compared to the recurring revenue from reserving/using that for current and future direct customers in the months/years to come, then maybe you consider selling some now. Since your bottom line is revenue/profit, how will you maximize this particular, possibly transient opportunity? First of all, you won't dump all of your unassigned addresses all at once, at any price, any more than you'd sell 100% of your salable upstream bandwidth all at once if that obliged you to flood the market and undercut our own prices. You'll definitely have a "reservation price" below which you'll just use internally or save for a more eager buyer. By the same logic, you won't be cannibalizing the IPv4 addresses that your customers are using directly -- not so much because they would get upset, but rather because as long as your edge resources (and those all of the other incumbent IPv4-based operators) remain attached via IPv4, then the IPv4 requirement will persist, and the IPv4 market will remain profitable. If IPv6 remains (at best) (just) an acceptable substitute for IPv4 -- i.e., offers no new features that are unavailable via IPv4 -- then those edge resources will be the absolute last IPv4 addresses to go... and even after they're gone too, maybe you'll continue running a reverse gateway (aka "IPv4 bottleneck server") to keep that IPv4 market alive just a little bit longer... How many really large operators would have to "choose altruism" and forego this strategy in order to preclude this outcome? Perhaps that would be a good research question for a better economist than me... Barring such altruistic defections, how long will the IPv4 era last -- i.e., how long will it take for (/30 x total number of direct peerings between all ASNs) to consume 32 bits, assuming that growth and new entrant rates are sensitive to the rising cost of access? That would be an easier one to extrapolate -- even a poor economist like me can intuit that the number would be very, very large. Bottom line: A "resource transfer" market will magically transform IPv4 into the new and dramatically improved "last mile bottleneck" -- "dramatically" improved because the bottleneck will be between everybody and everybody else. Apologies for taxing the patience of anyone who got this far; I'll do my best to spare the list another telling of this particular story, at least, hereafter. TV > I personally happen to think they are relatively fungible. The > mere fact that IPv4 is unavailable will drive people to IPv6, and > any small market that develops (black, white, or grey) will only > accelerate that trend. To that end any market is self-defeating; > and I think very quickly so. If you believe, as I do, that the mere > fact that there is no more IPv4 available from ARIN will drive > people to > IPv6 then I think it may well be the case that a "market" does not > appear. (*) > > Others have different opinions. > > * Which is not to say I believe there will be zero transactions. > Someone will hijack space, someone will sell, someone will buy. > For there to be a real market, there must be multiple buyers, and > sellers and some reasonably well defined way for them to meet. > A few isolated individual transactions does not count, at least > to me. > > -- > 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 the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From dmm at 1-4-5.net Fri Jun 20 16:11:24 2008 From: dmm at 1-4-5.net (David Meyer) Date: Fri, 20 Jun 2008 13:11:24 -0700 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In-Reply-To: <20080620175700.GB78555@ussenterprise.ufp.org> References: <4847F8EF.5070709@arin.net> <616812070806182134s3fab1fe6ub6f1c9dcf96089bc@mail.gmail.com> <4859EB83.1050609@psg.com> <2E2FECEBAE57CC4BAACDE67638305F1047F8628D56@ROCH-EXCH1.corp.pvt> <20080620162255.GA74707@ussenterprise.ufp.org> <2E2FECEBAE57CC4BAACDE67638305F1047F8628F29@ROCH-EXCH1.corp.pvt> <20080620175700.GB78555@ussenterprise.ufp.org> Message-ID: <20080620201124.GA26404@1-4-5.net> On Fri, Jun 20, 2008 at 01:57:00PM -0400, Leo Bicknell wrote: > In a message written on Fri, Jun 20, 2008 at 01:18:38PM -0400, Azinger, Marla wrote: > > While your idea of how is should go down would be simple and easy, > > the interpretation is that it requires more than that. And it > > doesn't say ARIN will contact them via a simple email to ask "hey > > are you using it?". It says the experimenter must apply for renewal > > with details. > > I will go back to my original query. > > I would very much like someone who has used the experimental policy > and completed one of these one year renewals to post about the > actual pain level they encountered. > > I'm not interested in anyone's interpretation, I'm interested in > actual implementation. > > Have you or Dave, as the authors, been through a 1 year renewal on > an experimental allocation? Can you tell us, specifically, how > much time and effort it took? What things ARIN staff required you > to provide? I haven't, but I still don't understand the point of the one year renewal. That's really not much time to get something built, deployed, and to get experience with whatever it is you're trying to build/deploy. But the main point I made to Mark in Brooklyn was simply that it seemed odd to put these barriers in place that cause people who want to do something with IPv6 must overcome. Maybe it isn't that big of a deal, but it did strike me as odd, given, well, IPv6. Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From bicknell at ufp.org Fri Jun 20 16:32:10 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 20 Jun 2008 16:32:10 -0400 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In-Reply-To: <20080620201124.GA26404@1-4-5.net> References: <4847F8EF.5070709@arin.net> <616812070806182134s3fab1fe6ub6f1c9dcf96089bc@mail.gmail.com> <4859EB83.1050609@psg.com> <2E2FECEBAE57CC4BAACDE67638305F1047F8628D56@ROCH-EXCH1.corp.pvt> <20080620162255.GA74707@ussenterprise.ufp.org> <2E2FECEBAE57CC4BAACDE67638305F1047F8628F29@ROCH-EXCH1.corp.pvt> <20080620175700.GB78555@ussenterprise.ufp.org> <20080620201124.GA26404@1-4-5.net> Message-ID: <20080620203210.GA91322@ussenterprise.ufp.org> In a message written on Fri, Jun 20, 2008 at 01:11:24PM -0700, David Meyer wrote: > I haven't, but I still don't understand the point of the > one year renewal. That's really not much time to get > something built, deployed, and to get experience with > whatever it is you're trying to build/deploy. The ARIN community has been extremely supportive of ARIN contacting resource holders once per year in an effort to make sure contact is not lost. This helps keep whois up to date, among other things. For a "regular" customer, this is done by sending them a yearly bill which they pay and return. For Experimental allocations the $500 fee (as I understand it) is one-time, when the block is allocated. There is no yearly contact as a result of billing activity. I think one of the things the community was looking for in crafting this policy in the first place was to insure there was outreach at least once a year to make sure someone was still using the block and the contact information was still good. This also puts experimental address holders on par with all other address holders who are contacted once a year. I'm fairly positive no one expects the experiments to be complete in a year. If the current language is a concern ("rejustifing the block") perhaps it would be better to remove that and just charge the $500 fee annually, as ARIN does with all other blocks? -- 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: 187 bytes Desc: not available URL: From dwhite at olp.net Fri Jun 20 16:34:20 2008 From: dwhite at olp.net (Dan White) Date: Fri, 20 Jun 2008 15:34:20 -0500 Subject: [arin-ppml] rwhoisd alternatives In-Reply-To: <20080620183129.GA10547@arin.net> References: <485BBF1A.1020504@olp.net> <20080620183129.GA10547@arin.net> Message-ID: <485C144C.2020207@olp.net> Mark Kosters wrote: > On Fri, Jun 20, 2008 at 10:30:50AM -0400, Dan White wrote: >> Is anyone aware of any alternatives to rwhoisd >> (http://www.rwhois.net)? Preferably open source. > > Another is a python implementation that just came out: > > http://blacka.com/software/python-rwhoisd Thank You, Looks like something I can run with. - Dan From dmm at 1-4-5.net Fri Jun 20 16:40:13 2008 From: dmm at 1-4-5.net (David Meyer) Date: Fri, 20 Jun 2008 13:40:13 -0700 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe In-Reply-To: <20080620203210.GA91322@ussenterprise.ufp.org> References: <4847F8EF.5070709@arin.net> <616812070806182134s3fab1fe6ub6f1c9dcf96089bc@mail.gmail.com> <4859EB83.1050609@psg.com> <2E2FECEBAE57CC4BAACDE67638305F1047F8628D56@ROCH-EXCH1.corp.pvt> <20080620162255.GA74707@ussenterprise.ufp.org> <2E2FECEBAE57CC4BAACDE67638305F1047F8628F29@ROCH-EXCH1.corp.pvt> <20080620175700.GB78555@ussenterprise.ufp.org> <20080620201124.GA26404@1-4-5.net> <20080620203210.GA91322@ussenterprise.ufp.org> Message-ID: <20080620204013.GA27105@1-4-5.net> On Fri, Jun 20, 2008 at 04:32:10PM -0400, Leo Bicknell wrote: > In a message written on Fri, Jun 20, 2008 at 01:11:24PM -0700, David Meyer wrote: > > I haven't, but I still don't understand the point of the > > one year renewal. That's really not much time to get > > something built, deployed, and to get experience with > > whatever it is you're trying to build/deploy. > > The ARIN community has been extremely supportive of ARIN contacting > resource holders once per year in an effort to make sure contact > is not lost. This helps keep whois up to date, among other things. > For a "regular" customer, this is done by sending them a yearly > bill which they pay and return. > > For Experimental allocations the $500 fee (as I understand it) is > one-time, when the block is allocated. There is no yearly contact > as a result of billing activity. That is not my understanding, but I could easily be mistaken. > I think one of the things the community was looking for in crafting > this policy in the first place was to insure there was outreach at > least once a year to make sure someone was still using the block > and the contact information was still good. This also puts > experimental address holders on par with all other address holders > who are contacted once a year. Sure, that makes sense. > I'm fairly positive no one expects the experiments to be complete > in a year. > > If the current language is a concern ("rejustifing the block") > perhaps it would be better to remove that and just charge the $500 > fee annually, as ARIN does with all other blocks? Not really sure. Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ptimmins at clearrate.com Fri Jun 20 16:50:29 2008 From: ptimmins at clearrate.com (Paul G. Timmins) Date: Fri, 20 Jun 2008 16:50:29 -0400 Subject: [arin-ppml] rwhoisd alternatives In-Reply-To: <485C144C.2020207@olp.net> Message-ID: We built a script that pulls all the allocation data from our custom inhouse IP tracking database, and rebuilds the rwhois data every 15 minutes out of cron, and we run the stock rwhoisd against those datafiles. We just extended the schema so we didn't have to deal with the whole whack of contact handles, and all that other cruft, the output ends up just looking similar to the RIPE whois when we're done (for example, whois 208.83.66.130) Not as cool or sophisticated as some of the more whizbang solutions that do it in real time, but it works well and made getting our second /21 absolutely painless. -Paul -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Dan White Sent: Friday, June 20, 2008 4:34 PM To: Mark Kosters Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] rwhoisd alternatives Mark Kosters wrote: > On Fri, Jun 20, 2008 at 10:30:50AM -0400, Dan White wrote: >> Is anyone aware of any alternatives to rwhoisd >> (http://www.rwhois.net)? Preferably open source. > > Another is a python implementation that just came out: > > http://blacka.com/software/python-rwhoisd Thank You, Looks like something I can run with. - Dan _______________________________________________ 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From dwhite at olp.net Fri Jun 20 17:16:23 2008 From: dwhite at olp.net (Dan White) Date: Fri, 20 Jun 2008 16:16:23 -0500 Subject: [arin-ppml] Fwd: [afnog] Beta Release: cwhoisd Version 0.9.3 In-Reply-To: References: <20050820190837.B99288@pop.eahd.or.ug> Message-ID: <485C1E27.2090504@olp.net> Thanks McTim. I'm forwarding on to the list. - Dan McTim wrote: > this might also be smt you might use instead of rwhoisd: > > > ---------- Forwarded message ---------- > From: Begumisa Gerald M > Date: Sat, Aug 20, 2005 at 7:12 PM > Subject: [afnog] Beta Release: cwhoisd Version 0.9.3 > To: afnog at afnog.org > > > Hi All, > > Just thought this bit of open source software we developed for the .UG > ccTLD may be useful to other ccTLD's and [hopefully] RIR / LIRs may > express enough interest in it for it to be developed further to suite as > many people's needs as possible. > > In short it's a whois server that suite's the needs of the .UG ccTLD the > way it is but I wouldn't mind putting in more effort to make it more > flexible :-) > > Following are brief notes / instructions on how to get it. > > > -- > Selected Excerpts from the README and CREDITS files: > > [README] > What is cwhoisd? > > cwhoisd is a highly scalable, fast, lightweight C/C++ daemon which > aims to implement most of the RFC1834 whois server specification. > It has built-in support for the MySQL database engine and is not > tied to any specific table structure making it a highly viable and > extremely easy-to-setup option in situations where there is an > already existing database. Nonetheless, cwhoisd comes with a > proposed table structure for a Whois database. > > cwhoisd features a powerful set of Access Control List rules which > administrators may use tightly control access to the server when > accessible by the general Internet, on a per-ip basis. These may > be on a per-client or global basis. Nonetheless, by building > cwhoisd with the "default allow" mode, cwhoisd may operate like > any completely open whois server. > > A typical setup might be: > > o Limit the query rate of a whose IP is XX.YY.ZZ.AA to 100 > requests per second. > > o Delay this client to enforce the rate if they exceed this > specified rate and print a warning for this client before > servicing > > In addition to the default action of reading the Access Control > List rules at startup from the configuration file, cwhoisd > features [experimental] support for dynamic addition or > modification of ACL rules in the running server. This is achieved > by specifying a second Internet port which will be used for this > purpose > > Download the software to learn more! > [/README] > > > [CREDITS] > Begumisa Gerald > cwhoisd Server Software Architecture Design and Implementation. > > Catherine Aloikin > Design of MySQL Database, modelled specifically for the .UG ccTLD > Registry. > > Computer Frontiers International www.cfi.co.ug > Funded and continues to fund the development of cwhoisd for the > .UG Country Code Top Level Domain (ccTLD) Registry. CFI also > provides the hosting and bandwidth facilities that make cwhoisd > available for free download. > [/CREDITS] > > > > How to get a copy of the software: > > There are basically 2 ways of getting this software. > > a) Download > > Grab either of the following two files: > > http://storm.cfi.co.ug/cwhoisd/cwhoisd-0.9.3.tar.bz2 > OR > http://storm.cfi.co.ug/cwhoisd/cwhoisd-0.9.3.tar.gz > > b) Concurrent Versions System (CVS) Server (abit slower) > > Log in to any Unix server (Linux / FreeBSD) and type out the > following commands: > > $ cvs -d :pserver:anoncvs at pop.eahd.or.ug:/usr/local/cvsroot login > > NOTE: At this point you will be required to enter a password, > use the password "anoncvs" without the double quotes. > > $ cvs -d :pserver:anoncvs at pop.eahd.or.ug:/usr/local/cvsroot checkout > -r v0_9_3 cwhoisd > > Then change to the cwhoisd folder and read the file called > "README" > > This will get you version 0.9.3 of the cwhoisd software. > -- > > Enjoy! > > > Regards, > Gerald. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Begumisa Gerald M. > Programmer / Systems Administrator > Computer Frontiers International > Plot 32 Lumumba Avenue, Kampala > Office Tel.: +256 41 340417 > Mobile Tel.: +256 71 991983 > Fax: +256 41 340456 > Web: www.cfi.co.ug > > _______________________________________________ > afnog mailing list > > > From mueller at syr.edu Fri Jun 20 18:31:57 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 20 Jun 2008 18:31:57 -0400 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freeze period? In-Reply-To: <20080620163443.GB74707@ussenterprise.ufp.org> References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu> <20080620163443.GB74707@ussenterprise.ufp.org> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0D9E0@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: Leo Bicknell [mailto:bicknell at ufp.org] > > Correction, a 2 year time out on IPv4 resources only. Nope. 4 years. You can't have gotten any ARIN or transfer resources 2 years _prior_ to the transfer, and you can't get any 2 years after. 2+2=4. Exact quotes: Nope. 4 years. You can't have gotten any ARIN or transfer resources 2 years _prior_ to the transfer, and you can't get any 2 years after. 2+2=4. Your position is relatively reasonable. As I said in my prior message, I think RIPE handled this correctly. You restrict what the RECIPIENT of the market-transfer does with the transferred addresses for two years, not the releaser. That stops speculation cold. From mueller at syr.edu Fri Jun 20 18:48:31 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 20 Jun 2008 18:48:31 -0400 Subject: [arin-ppml] I guess the price of oil does have something to do with policy... In-Reply-To: <86372.1213980574@sa.vix.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu><7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu><485AD985.70300@internap.com><7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu><485BCF36.90101@sprunk.org><63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0D9E1@SUEXCL-02.ad.syr.edu> Owen, Clearly you don't trust/like markets. But how much do you trust/like the absence of markets? I hope you are old enough to remember what happened when the price of oil was subject to strict price controls in 1973 and 1979. We had severe shortages and rationing and lines at the gas pumps. Those shortages were far more serious and damaging than the price increases we are faced with now. Bad as current price rises are for some, they have produced massive conservation efforts and shifts to new energy technologies. I do not think there is anything wrong with the oil futures markets other than (justified) uncertainty. As for subprime, I don't get it. IP addresses are not credit lines. They are essential but fairly small intermediate inputs into an industry. Wall St. will not be basing derivative instruments on them. It is not a consumer market, the buyers are likely to be informed. And it's a temporary thing (we hope). > -----Original Message----- > > I think that the subprime mortgage and oil futures markets are examples > > how professionally regulated markets fail to do the right thing, and I > > cannot imagine that we will somehow miraculously do better than the > > regulators in those markets. > From mueller at syr.edu Fri Jun 20 18:51:26 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 20 Jun 2008 18:51:26 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu><7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu><485AD985.70300@internap.com><7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu><485BCF36.90101@sprunk.org><63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com><86372.1213980574@sa.vix.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0D9E2@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > > I consider this a parallel case because it is a market that is likely to > attract speculators if it is not regulated in such a way as to prevent > them. Further, I believe that the backlash against the various anti- > speculation provisions of the proposed policy is reasonable evidence > that such regulation would be burdensome and undesirable to the > community. What backlash? Did I miss something? As I said earlier, a 2-year limit on transfer of the received addresses is fine. Not burdensome, doesn't undermine the incentive to release addresses, but shakes out speculation. > A market without such regulation would, in my opinion > be quite harmful. As such, no market and no such regulation > seems the safest course. From mueller at syr.edu Fri Jun 20 18:53:04 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 20 Jun 2008 18:53:04 -0400 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freezeperiod? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D9E0@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu><20080620163443.GB74707@ussenterprise.ufp.org> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E0@SUEXCL-02.ad.syr.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0D9E3@SUEXCL-02.ad.syr.edu> Oops, I pasted the wrong text in. Here is the selection from 8.3.1. apologies to all: * The transferor has not received any IPv4 allocations or assignments from ARIN (through ordinary allocations or assignments, or through this Simple Transfer policy) within the preceding 24 months. * The transferor may not request any IPv4 allocations or assignments from ARIN (through ordinary allocations or assignments, or through this Simple Transfer policy) within the subsequent 24 months. > -----Original Message----- > > > -----Original Message----- > > From: Leo Bicknell [mailto:bicknell at ufp.org] > > > > Correction, a 2 year time out on IPv4 resources only. > > Nope. 4 years. You can't have gotten any ARIN or transfer resources 2 > years _prior_ to the transfer, and you can't get any 2 years after. > 2+2=4. > > Exact quotes: > Nope. 4 years. You can't have gotten any ARIN or transfer resources 2 > years _prior_ to the transfer, and you can't get any 2 years after. > 2+2=4. > > Your position is relatively reasonable. As I said in my prior message, I > think RIPE handled this correctly. You restrict what the RECIPIENT of > the market-transfer does with the transferred addresses for two years, > not the releaser. That stops speculation cold. > > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. From steve at ibctech.ca Fri Jun 20 18:59:21 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 20 Jun 2008 18:59:21 -0400 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freeze period? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu> Message-ID: <485C3649.1090601@ibctech.ca> Milton L Mueller wrote: > > In the ARIN proposal, the releasing party cannot have received any IPv4 > addresses, either from ARIN or from transfers, in the past 24 months, > and cannot request any for the next 24 months. So anyone who > participates on the release side of a transfer must remove themselves > from the ARIN v4 allocation/assignment process for a total of four years. > > Ostensibly, the rationale here is to prevent hoarding and speculation. > But it seems like overkill. Is this intended to be punitive? Is the > rationale really a Ted-style "you immoral bastards held on to address > space you didn't need and so now we're going to screw you back" kind of > an attitude? > Wouldn't it be simpler to block speculation the way RIPE proposes, and > simply restrict -- on the recipient side -- transfer of the received > addresses for two years? I have not been following these threads thoroughly, so forgive me up front. What if ARIN blocked the transfer of addresses by looking at it from the side of the purchaser, not the merchant, and enforced them to follow already written policy that states they must provide justification for the size of block in the transfer? ...or am I way off in my statement, and the one that I quoted, in thinking perhaps that how in Gods name is ARIN going to be able to functionally stop any market of sorts, and how will it be enforced if the transfer happens between regions? I snickered at the eBay message this morning. Whoever posted that has their ducks in a row. To be honest, after thinking about it, if it were me, I would not have stated that they can lease it for as long as they want for the purchase price. I would have tried to word in an ongoing 'maintenance' fee for it. I'd like to see some sort of credit system in place, where if I give back a piece of my /NN (due to migrating at least my internal infrastructure to IPv6), I receive NN credits. When the time comes that IPv4 space is so valuable, let the market dictate the price. Have an eBay style auction in which my credits earn me the right to collect NN percent of the inflated fee the allocatee paid for the registration. This will be my incentive (beyond my already existent incentives) for migrating to IPv6, and/or evaluating and rectifying areas of my network that is blatantly not conservative of v4 address assignment. Off the wall, I know. Steve From sleibrand at internap.com Fri Jun 20 19:10:09 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 20 Jun 2008 16:10:09 -0700 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freeze period? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D9E3@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu><20080620163443.GB74707@ussenterprise.ufp.org> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E0@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E3@SUEXCL-02.ad.syr.edu> Message-ID: <485C38D1.4080408@internap.com> Milton L Mueller wrote: > Here is the selection from 8.3.1. apologies to all: > > * The transferor has not received any IPv4 allocations or assignments > from ARIN (through ordinary allocations or assignments, or through this > Simple Transfer policy) within the preceding 24 months. > * The transferor may not request any IPv4 allocations or assignments > from ARIN (through ordinary allocations or assignments, or through this > Simple Transfer policy) within the subsequent 24 months. So it looks to me like the best way to accomplish what you want is to strike "or through this Simple Transfer policy" from the second clause, leaving something like this: * The transferor may not request any ordinary allocations or assignments IPv4 allocations or assignments from ARIN within the subsequent 24 months. (Striking the entire second clause would allow someone to transfer away their current address holdings, and then get more addresses through an ordinary assignment, which I don't think we want to allow.) That would have the effect of allowing someone to transfer away their space, and then turn around receive more space by transfer, perhaps at a lower price. Essentially, that allows someone to "short" IPv4 addresses, while requiring "long" positions to be at least 24 months long. It would also allow someone to transfer away their addresses, with the assurance that, if they end up needing addresses after all, they can get new addresses. Those, in turn, would add supply to the market, driving prices down somewhat. I would not be opposed to such a change. Can anyone else think of any negative implications that would outweigh the positives already outlined? Thanks, Scott >> Your position is relatively reasonable. As I said in my prior message, >> I think RIPE handled this correctly. You restrict what the RECIPIENT of >> the market-transfer does with the transferred addresses for two years, >> not the releaser. That stops speculation cold. From mueller at syr.edu Fri Jun 20 19:27:31 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 20 Jun 2008 19:27:31 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why thetriggerdate? In-Reply-To: <443de7ad0806201242k1004b7f6o4051e7110a857a2f@mail.gmail.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu><7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu><485AD985.70300@internap.com><7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu><485BCF36.90101@sprunk.org><63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com><7EC421F755E45242A47938C3B6F634B1DA3A81@hnetavail1.exchange.handynetworks.com><443de7ad0806201219t40fa82d2o171a120ab1b3a56f@mail.gmail.com><485C044D.9090907@psg.com> <443de7ad0806201242k1004b7f6o4051e7110a857a2f@mail.gmail.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0D9E7@SUEXCL-02.ad.syr.edu> Chris: My point about the ARIN policy is that it is so restrictive (compare it to the RIPE and APNIC proposals) that people WILL disregard the rules, and the transfers of addresses that do occur will go underground. The post by Jay Sudowksi was particularly illuminating in this regard. It is bad policy design, not bad human nature, that causes this problem. Here is what the ARIN policy does in a nutshell. It says: "hey, you people who want to buy addresses? don't think for a moment that you can transact directly with a seller, you have to go through us and WE will tell you whether you need the resources or not. Come to us and we will do a needs assessment _not only_ on the addresses you are asking for but on the ones you already have, too. Heck we might even take some away." And then it says, "hey sellers, if you want to participate in this market say goodbye to any ARIN resources for 4 years, and you can't get any transfers for years either. And oh, the buyer can't really pay you until we decide what you can give him, which you will not be able to predict. And oh by the way, you get to pay a special transfer fee for this 'service.'" Those conditions are ridiculous. Or rather, as Owen and Leo have basically confessed in public, they were designed by people who don't want there to be transfer markets at all. Since IPv4 resources are so heavily concentrated in the ARIN region, it is incumbent upon ARIN to handle the problem in the best possible way. Policy 2008-2 isn't even close to being good, much less "best." You do have to decide. Either liberalize 2008-2 along the lines of the RIPE proposal, (which as far as I can tell would do a good job of facilitating market transfers while eliminating harmful speculation or hoarding) or make it clear to the world that you're not going to allow address markets as a way to force them into v6. If the latter, then you are playing chicken with the v4-v6 transition and risk driving a hell of a lot of the v4 economy underground. Hope you're right. --MM > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Chris Grundemann > Sent: Friday, June 20, 2008 3:43 PM > To: Randy Bush > Cc: ARIN PPML > Subject: Re: [arin-ppml] Q1 - ARIN address transfer policy: why > thetriggerdate? > > On Fri, Jun 20, 2008 at 1:26 PM, Randy Bush wrote: > >> People who are willing to break the rules do not care what rules you > >> put in place. > > > > this is the "they are bad people" theory, a subset of the black > > helicopter theme. > > > > repeat the following mantra a few times and the fear will go away. > > > > it's just business. > > they are just trying to get their work done. > > > > of course there are bad folk on the net; c.f. recent hijack allegations. > > but the current address traders seem to be consenting parties on both > > sides. they are just trying to get their work done despite amateur > > over-regulation. > > I was not trying to imply that anyone involved was necessarily "bad" > (or "good" for that matter) and I definitely have no opinion on their > mode of transportation ;). My point is that if a market (of sorts - > term applied liberally) exists today when IP numbers are free and > available, why would these market players go through the trouble of a > sanctioned transfer in the future? Why (and/or how) will this policy > (or any transfer policy) change existing behavior? > > I simply suggest that some will "just try to get their work done > despite [perceived] amateur over-regulation" regardless of what that > specific regulation is. > > ~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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. From mueller at syr.edu Fri Jun 20 19:54:46 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 20 Jun 2008 19:54:46 -0400 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freeze period? In-Reply-To: <485C38D1.4080408@internap.com> References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu><20080620163443.GB74707@ussenterprise.ufp.org> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E0@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E3@SUEXCL-02.ad.syr.edu> <485C38D1.4080408@internap.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0D9E9@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand at internap.com] > > * The transferor has not received any IPv4 allocations or assignments > > from ARIN (through ordinary allocations or assignments, or through this > > Simple Transfer policy) within the preceding 24 months. > > * The transferor may not request any IPv4 allocations or assignments > > from ARIN (through ordinary allocations or assignments, or through this > > Simple Transfer policy) within the subsequent 24 months. > > So it looks to me like the best way to accomplish what you want is to > strike "or through this Simple Transfer policy" from the second clause, > leaving something like this: > > * The transferor may not request any ordinary allocations or assignments > IPv4 allocations or assignments from ARIN within the subsequent 24 months. That's good, but I am also interested in reducing the "time out" to 2 years total. I tend to think you only need one of those clauses, the second one, or if you retain both, make the time period one year. > (Striking the entire second clause would allow someone to transfer away > their current address holdings, and then get more addresses through an > ordinary assignment, which I don't think we want to allow.) > > That would have the effect of allowing someone to transfer away their > space, and then turn around receive more space by transfer, perhaps at a > lower price. Essentially, that allows someone to "short" IPv4 > addresses, while requiring "long" positions to be at least 24 months > long. It would also allow someone to transfer away their addresses, > with the assurance that, if they end up needing addresses after all, > they can get new addresses. Yes, that's good. It also might allow someone to aggregate larger blocks > Those, in turn, would add supply to the market, driving prices down > somewhat. > > I would not be opposed to such a change. Can anyone else think of any > negative implications that would outweigh the positives already outlined? > > Thanks, > Scott > > From tedm at ipinc.net Fri Jun 20 19:55:59 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 20 Jun 2008 16:55:59 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: <87333.1213981852@sa.vix.com> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Paul Vixie > Sent: Friday, June 20, 2008 10:11 AM > To: Owen DeLong > Cc: ARIN PPML > Subject: Re: [arin-ppml] Q1 - ARIN address transfer policy: > why the triggerdate? > > > > > isn't this inevitable in times of shortage, ... > > > I don't accept your premise that a market is inevitable. > > what else have you ever seen humans do in times of shortage? There is no shortage, however. A true shortage of IP numbers would mean that there are not enough numbers to use for everyone who wanted to get on to the Internet. However, there are many many many IPv6 numbers available for anyone who wants to get on the Internet. All they have to do is get their IPv6 numbers and their ISP setup a gateway to gateway from IPv4 to IPv6, then then as many people as you want can use the IPv6 numbers to get on to both the IPv4 and IPv6 numbering on the Internet. This is a "prima donna" shortage. It is like the people who walk into a restaurant and demand lobster, then when the restaurant says "sorry we ran out" they then stomp out claiming "there isn't anything I can eat at that restaurant" Ted From tedm at ipinc.net Fri Jun 20 19:59:24 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 20 Jun 2008 16:59:24 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901884122@SUEXCL-02.ad.syr.edu> Message-ID: -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller Sent: Friday, June 20, 2008 8:11 AM To: Chris Grundemann Cc: PPML ppml Subject: Re: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? From: Chris Grundemann [mailto:cgrundemann at gmail.com] >>Leaving morality out of it for the moment, there are contractual >>obligations here (RSA). Are you suggesting that the contracts signed >>with ARIN do not matter or that they should not matter? >Should not matter. Anyone who says that signed contracts should not matter is frankly full of fecal matter. Ted From sleibrand at internap.com Fri Jun 20 20:06:41 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 20 Jun 2008 17:06:41 -0700 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freeze period? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D9E9@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu><20080620163443.GB74707@ussenterprise.ufp.org> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E0@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E3@SUEXCL-02.ad.syr.edu> <485C38D1.4080408@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E9@SUEXCL-02.ad.syr.edu> Message-ID: <485C4611.2030102@internap.com> Milton L Mueller wrote: > > That's good, but I am also interested in reducing the "time out" to 2 > years total. I tend to think you only need one of those clauses, the > second one, or if you retain both, make the time period one year. I think we need both. Here's why: "The transferor has not received any IPv4 allocations or assignments from ARIN (through ordinary allocations or assignments, or through this Simple Transfer policy) within the preceding 24 months." This clause would prevent someone from getting space from ARIN, then immediately turning around and transferring it for a profit. It also deters hoarding by setting a minimum length on any "long" position. "The transferor may not request any ordinary IPv4 allocations or assignments from ARIN within the subsequent 24 months." This clause would prevent someone from transferring their current address holdings for a profit, then immediately turning around and getting replacement space from ARIN. I would, however, be amenable to changing all instances of "24 months" in 8.3.1 and 8.3.2 to "12 months" (or something else), if people think that'd be better. Perhaps we could get some input from other folks on the best duration for these "time out" clauses? -Scott From sleibrand at internap.com Fri Jun 20 20:12:05 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 20 Jun 2008 17:12:05 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: References: Message-ID: <485C4755.2010905@internap.com> Ted Mittelstaedt wrote: >>> Leaving morality out of it for the moment, there are contractual >>> obligations here (RSA). Are you suggesting that the contracts signed >>> with ARIN do not matter or that they should not matter? > >> Should not matter. > > Anyone who says that signed contracts should not matter is frankly > full of fecal matter. Are you arguing that we the community, through ARIN, should not have the right to waive certain contractual rights if we think it's in our collective best interest? -Scott From bicknell at ufp.org Fri Jun 20 20:17:26 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 20 Jun 2008 20:17:26 -0400 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freeze period? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D9E0@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu> <20080620163443.GB74707@ussenterprise.ufp.org> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E0@SUEXCL-02.ad.syr.edu> Message-ID: <20080621001726.GA3189@ussenterprise.ufp.org> In a message written on Fri, Jun 20, 2008 at 06:31:57PM -0400, Milton L Mueller wrote: > Nope. 4 years. You can't have gotten any ARIN or transfer resources 2 > years _prior_ to the transfer, and you can't get any 2 years after. > 2+2=4. Ah ok, I misunderstood earlier. While I'm not married to the 2+2, I do believe it should be 1+something, at a minimum. Today when someone makes a request of ARIN they do so to get a 1 year supply (a recent change). If addresses were transferred away under a market plan prior to that one year timeframe, it seems to me there is an extremely high chance something bad happened, like the requestor lying about how much space they had free, or about their needs for the future. While we could waste a lot of resources by having ARIN staff do extra checks on resources transferred away prior to 1 year, it seems more reasonable to me to have the first timeframe be at least one year so that situation does not occur. Basically, let's not encourage people to cheat the system. Beyond that I don't have a strong opinion on what the actual timeframes should 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: 187 bytes Desc: not available URL: From steve at ibctech.ca Fri Jun 20 20:22:56 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 20 Jun 2008 20:22:56 -0400 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freeze period? In-Reply-To: <485C4611.2030102@internap.com> References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu><20080620163443.GB74707@ussenterprise.ufp.org> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E0@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E3@SUEXCL-02.ad.syr.edu> <485C38D1.4080408@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E9@SUEXCL-02.ad.syr.edu> <485C4611.2030102@internap.com> Message-ID: <485C49E0.2090502@ibctech.ca> Scott Leibrand wrote: > Milton L Mueller wrote: >> That's good, but I am also interested in reducing the "time out" to 2 >> years total. I tend to think you only need one of those clauses, the >> second one, or if you retain both, make the time period one year. > > I think we need both. Here's why: > I would, however, be amenable to changing all instances of "24 months" > in 8.3.1 and 8.3.2 to "12 months" (or something else), if people think > that'd be better. > > Perhaps we could get some input from other folks on the best duration > for these "time out" clauses? Instead of a dedicated time frame, a derivative of some sort based on their past history, prior to the inclusion of this new portion of the policy. - received allocation 0403 - received allocation 0610 - received allocation 0702 - received allocation 0806 ...a mathematical algorithm based on the size of allocation, and the time frame between allocations? Would a well-defined algorithm be non-biased against large and small orgs in this case, but not hold anyone to a time frame of 'waiting' that there is no precedence to go by to set? Steve From bicknell at ufp.org Fri Jun 20 20:21:58 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 20 Jun 2008 20:21:58 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why thetriggerdate? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D9E7@SUEXCL-02.ad.syr.edu> References: <443de7ad0806201242k1004b7f6o4051e7110a857a2f@mail.gmail.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E7@SUEXCL-02.ad.syr.edu> Message-ID: <20080621002158.GB3189@ussenterprise.ufp.org> In a message written on Fri, Jun 20, 2008 at 07:27:31PM -0400, Milton L Mueller wrote: > Those conditions are ridiculous. Or rather, as Owen and Leo have > basically confessed in public, they were designed by people who don't > want there to be transfer markets at all. I believe this incorrectly states the history. The AC developed this proposal together. Of the 15 members several are quite pro-market, several are quite anti-market, many are somewhere in the middle.. If anything it could be called a "bipartisen bill". My own history is that I was mildly pro-market prior to the AC taking on the task of developing the policy proposal. As I considered the options seriously and in-depth I moved to a anti-market position. Some on the AC did just the opposite. -- 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: 187 bytes Desc: not available URL: From tedm at ipinc.net Fri Jun 20 20:27:03 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 20 Jun 2008 17:27:03 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD90188411B@SUEXCL-02.ad.syr.edu> Message-ID: >-----Original Message----- >From: Milton L Mueller [mailto:mueller at syr.edu] >Sent: Friday, June 20, 2008 7:11 AM >To: Ted Mittelstaedt; PPML ppml >Subject: RE: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? >This is the kind of response I had hoped I wouldn't get. For starters, please use ASCII text, and do a better job of formatting. >I know there are ideologically motivated people who think it >is evil to trade addresses, or "immoral" to hold on to more than >you actally "need" (as if "address need" were some stable, fixed >and objectively verifiable attribute of any network). But if that >is your position, NO, Milton, it's YOUR position. YOU were the one who said that you had "more addresses than I needed" YOU are the "ideologically motivated" person, here. -I- never said that -I- had more addresses than -I- needed, nor did anyone else. YOU were the one who brought that up. NOT ME. >then there should be no transfer policy at all, right? There already is a transfer policy. It's called, returning the addresses you don't need to those who assigned them, so they can be handed out to those who do need them. You should try it out before just assuming that it won't work. >So while it is evident that that attitude has shaped the nature of >ARIN's policy, it is not really relevant to defining a transfer policy >once you decide to have one. However we haven't yet decided to have one. Thus, your out of order. >>ARIN policy isn't supposed to be based on an economic rationale. >Um. Policies pertaining to scarce resources used by global industries >that aren't grounded in sound economic concepts about actual behavior >under conditions of scarcity cannot succeed. Spoken like a dyed in the wool trickle-down economist. Where is the scarce resource? Numbers? We have lots of addresses. Just because they aren't the color you want, doesen't mean they won't work. >The greatest good for the greatest number cannot be achieved without >taking actors' economic incentives into account. It's done all of the time. >>See below. >>By definition, if you have "too much" address space then you >>are required under the RSA you signed to return it. Why - because [snip] >>Therefore your hypothetical situation -cannot- exist pre-IPv4 runout. >Your statement describes an idealized interpretation of what you consider >to be a moral obligation. It does not describe how people actually behave. Explain then why so many organizations have returned addressing, then. They apparently weren't reading the same textbooks that you were. > Thus, your statement that the situatuion "cannot" exist is factually > incorrect. The situation does exist, and "everyone knows it does" Lame argumentum ad populum won't save you now, >Further, the situation exists both before and after IANA's free pool exhaustion. >The modification of the ARIN requirements to permit "selling" >effectively modifies the existing RSAs that people have signed, >because it basically says that "After IPv4-runout we don't give a crap >how you got your IPv4, whether honestly or not, from this point on we all >have a clean slate" This is why such a policy is a horrible idea pre-IPv4 runout. >OK, I am glad that you finally got around to attempting to answer my >question. And your anwer is, presumably, that the "clean slate" >facilitates the transfer of resources from people who value them less to >people who value them more. And my simple observation is that if it makes >sense to do that after IANA pool depletion, it makes sense to do it beforehand. And if it makes sense to clean the stuff out of the cat litter box after we buy the cat, it makes sense to do it before we buy the cat... Come off it Milton. We aren't that dumb to fall for one of these leading arguments. Ted From tedm at ipinc.net Fri Jun 20 20:44:23 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 20 Jun 2008 17:44:23 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why thetriggerdate? In-Reply-To: <7EC421F755E45242A47938C3B6F634B1DA3A81@hnetavail1.exchange.handynetworks.com> Message-ID: <60A854C04B0E48288CA37B0E98CA830F@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jay Sudowski > - Handy Networks LLC > Sent: Friday, June 20, 2008 11:21 AM > To: Owen DeLong; Stephen Sprunk > Cc: ARIN PPML > Subject: Re: [arin-ppml] Q1 - ARIN address transfer policy: > why thetriggerdate? > > > For those of you who don't think a rational transfer policy > is necessary, please consider the following: > > 1. In the real world, many people do not view ARIN postively. > Business people (CEO types) who run companies that require > portable IP space view ARIN as overly punative, prohibitive > gatekeepers to a important resource that they need access to. > Technicians in that have to deal with ARIN infrequently for > initial IP allocations, additional allocations, etc hold ARIN > in the same light. Due to this, if it often easier, far less > stressful, and far less expensive in time/opportunity cost to > "purchase" IP space or hire someone to interact with ARIN for > you. Put simply and bluntly, ARIN is a pain in the ass to deal with. > So what? People don't view the US IRS in a positive light either and lots would sign on to a movement to get rid of it. It's a given that a lot of people are stupid, so what? > 2. I have been aware of people have been buying, selling and > using subterfuge to obtain IP allocations for as long as I > have been been in the industry (the past 8 years). Some examples: > > 2a. Three companies merge into one. For many months after > they merged, they continued to interact with ARIN as separate > entities, obtaining far more IP allocations than they would > have been able to as a single entity. Even today, this > single entity (which has now recently merged again), > interacts with ARIN using two separate, but related entity > names and two separate ORG IDs. > > 2b. Every month I run into people who are willing to sell me > their /18, /19, /20 for a fee. It is my understanding that > such transactions are usually structured so that other > [usually worthless] assets or an entire shell entity are > included in the sale to pass ARIN scrutiny. > > 2c. For a time, I did work for an entity that had previous > bad blood with ARIN (see point 1) and managed to obtain 3 > /18s on the after market. From what I gather, this is not > all that unusual. > > 2d. There are consultants out there who, for a fee, guarantee > you will get an IP allocation from ARIN. They are able to > accomplish because they control a large amount of IP space > for entities that they work for, and they SWIP out space from > those entities to the entity paying them for the direct > allocation. Bogus data is submitted to ARIN, the SWIP'd > space supports the bogus allocation, and the allocation is granted. > > 2e. ARIN members continue to report IP usage by customers > that have long since left their network, inflating their > actual need and utilization percentages, allowing them to > obtain unneccesary allocations from ARIN. > > For those of you who want to maintain the status quo, think > about the above and then think about how the bad actors will > multiply once IPv4 becomes truly scarce. Once more, so what? The brokers out there who are selling IP space won't last long. When an org that needs IPv4 buys it, they will use it. It will then no longer be available for resale. Imagine it this way. There's a lot of bad citizens out there who get flood damaged cars, spruce them up, then sell them to victims as new. One day, all the automakers announce that they are running out of cars, and there won't be any after 2011. So by 2020 or so, all the cars will be in service or used up or in wrecking yards. There won't be any left and these nasty people will have to find some other scam. > even be a market for IP space, etc. Meanwhile, people > operating in the real world, will do what they have to do to > put food on their table and gas in their cars. As such, they > will continue to do what they are doing today [see 2a-e] and > will do so with increasing frequncy and neccessity as IP > depletion becomes reality. > And when all the IPv4 is tied up, then what will these people do? > The choice should be to either create a framework that > attemps to define, regulate and bring some transparency an IP > allocation trading/transfer market or simply come to the > realization that the existing IP address marketplace, which > exists in the hidden corners of the Internet, will continue > to function and evolve as depletion comes closer and closer > to reality. > I've already come to the realization that the existing IP address marketplace, which exists in the hidden corners of the Internet, will continue to function. But I've also come to the realization that it won't function very long after the RIR's run out of IPv4. So why should we help it out any? Once again, how does it help me to assist in stretching out IPv4? Everything you have said simply tells me that the more effort I put into helping prolong IPv4 post-runout, the more power and authority I give into the hands of these bad people who you seem to think are going to run IPv4 allocations in the hidden corners of the Internet. Ted From tedm at ipinc.net Fri Jun 20 20:45:52 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 20 Jun 2008 17:45:52 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <485C4755.2010905@internap.com> Message-ID: <55701A282BF9477A9CD7DD868A0277D3@tedsdesk> > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand at internap.com] > Sent: Friday, June 20, 2008 5:12 PM > To: Ted Mittelstaedt > Cc: 'PPML ppml' > Subject: Re: [arin-ppml] Q1 - ARIN address transfer policy: > why the trigger date? > > > Ted Mittelstaedt wrote: > >>> Leaving morality out of it for the moment, there are contractual > >>> obligations here (RSA). Are you suggesting that the contracts > >>> signed with ARIN do not matter or that they should not matter? > > > >> Should not matter. > > > > Anyone who says that signed contracts should not matter is frankly > > full of fecal matter. > > Are you arguing that we the community, through ARIN, should > not have the > right to waive certain contractual rights if we think it's in our > collective best interest? > AnyONE. Not -all- of us. I think you missed taking your paranoid pill, Scott. ;-) Ted From sleibrand at internap.com Fri Jun 20 20:58:23 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 20 Jun 2008 17:58:23 -0700 Subject: [arin-ppml] Under what circumstances should ARIN permit transfers? (was: Q1 ...) In-Reply-To: <55701A282BF9477A9CD7DD868A0277D3@tedsdesk> References: <55701A282BF9477A9CD7DD868A0277D3@tedsdesk> Message-ID: <485C522F.5010905@internap.com> Ted Mittelstaedt wrote: >>>>> Leaving morality out of it for the moment, there are contractual >>>>> obligations here (RSA). Are you suggesting that the contracts >>>>> signed with ARIN do not matter or that they should not matter? >>>> Should not matter. >>> Anyone who says that signed contracts should not matter is frankly >>> full of fecal matter. >> Are you arguing that we the community, through ARIN, >> should not have the right to >> waive certain contractual rights if we think it's in our >> collective best interest? > > AnyONE. Not -all- of us. Ok, then in that case we're in agreement, at least, but I think the thread above shows some over-reaction. Everyone who I've heard argue that parts of "the contracts signed with ARIN should not matter" made that statement within the context of a discussion about a relaxed transfer policy proposal like 2008-2. Either it passes, and we collectively agree that those parts of the RSA shouldn't matter, or it doesn't pass, and they still do matter. I haven't heard anyone arguing that the RSA should be nullified more generally. In any event, I'd like to hear your input on some of the more specific issues, as well. If the community ends up favoring a relaxed transfer policy, which rights do you think ARIN should reserve (such as the requirement for justification of need, holding periods, etc.), and why? Thanks, Scott From bmanning at vacation.karoshi.com Sat Jun 21 00:27:44 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 21 Jun 2008 04:27:44 +0000 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> Message-ID: <20080621042744.GA16756@vacation.karoshi.com.> On Fri, Jun 20, 2008 at 04:21:47PM -0400, Tom Vest wrote: > Hi Leo, > > I think that, purely from a protocol/software standpoint, an > individual IPv6 address might be pretty close to substitutable for an > individual IPv4 address, if not today then pretty soon. > > Since your bottom line is revenue/profit, how will you maximize this Tom, While I'll agree to the lema that the Internet of today is not the same as the Internet of last century, I refuse to beleive that all users/potential users of Internet Addressing are driven by revenue/profit. Non-profits, research, government, military, public service sectors all can and do benefit from equal access to communications capabilities... And their use of IP addresses is not driven by revenue/profit. Does an open market best serve the needs of these communities? Or is the existing needs-based system do a better job of resource allocation? --bill From sleibrand at internap.com Sat Jun 21 00:34:44 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 20 Jun 2008 21:34:44 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <20080621042744.GA16756@vacation.karoshi.com.> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> Message-ID: <485C84E4.7040606@internap.com> bmanning at vacation.karoshi.com wrote: > Non-profits, research, government, military, public service > sectors all can and do benefit from equal access to communications > capabilities... And their use of IP addresses is not driven > by revenue/profit. Does an open market best serve the needs of > these communities? Or is the existing needs-based system do a > better job of resource allocation? Today's needs-based system does a better job of serving the needs of almost everyone in the community who needs more IP addresses (for-profit and not-for-profit) than a market would, because today the addresses can be given out essentially for free, whereas in a market system they'll have an acquisition cost. However, that's not the debate around 2008-2. The question at hand is which would better serve the needs of the community after the free pool is exhausted: a market-based transfer system, or a simple discontinuation of all IPv4 allocations from RIRs? -Scott From tvest at pch.net Sat Jun 21 02:07:20 2008 From: tvest at pch.net (Tom Vest) Date: Sat, 21 Jun 2008 02:07:20 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <20080621042744.GA16756@vacation.karoshi.com.> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> Message-ID: On Jun 21, 2008, at 12:27 AM, bmanning at vacation.karoshi.com wrote: > On Fri, Jun 20, 2008 at 04:21:47PM -0400, Tom Vest wrote: >> Hi Leo, >> >> I think that, purely from a protocol/software standpoint, an >> individual IPv6 address might be pretty close to substitutable for an >> individual IPv4 address, if not today then pretty soon. >> >> Since your bottom line is revenue/profit, how will you maximize this > > > Tom, > > While I'll agree to the lema that the Internet of today is > not the same as the Internet of last century, I refuse to > beleive that all users/potential users of Internet Addressing > are driven by revenue/profit. > > Non-profits, research, government, military, public service > sectors all can and do benefit from equal access to communications > capabilities... And their use of IP addresses is not driven > by revenue/profit. Does an open market best serve the needs of > these communities? Or is the existing needs-based system do a > better job of resource allocation? > > --bill Hi Bill, I never said, and I don't for a minute believe, that all current and potential address resource users are motivated as you suggest; if I did it certainly wouldn't have made much sense to make a plea for a "collaborative, cooperative" response, as I did in one message earlier today. Neither did I say (and I do not believe) that who those that are "driven" or otherwise subject to market forces/profitability requirements are somehow "bad" by virtue of that fact. By itself, the fact of one's participation in some market doesn't make you bad, or good; it doesn't damn you, or absolve you either. What I did suggest was that the fact that market forces are irrelevant for some Internet resource users won't matter at all, and absolutely won't prevent what I described from coming to pass. The only way that such users could possibly make any difference is if they happen to BOTH (a) directly control a very large share of very popular/critical Internet content and services, which they elect to voluntarily, promptly, and unilaterally make native IPv6 accessible, AND (b) that they can also provide at least gateway-sized PI IPv4 assignments, on "reasonable terms", for most/all aspiring new Internet entrants for long enough (several years at least, I reckon) to deter others from pursuing the completely rational, a-moral, profit-maximizing strategy that I outlined. That's why I used the "choose altruism" terminology in my long message. The point about markets is that occasionally they "fail"; for some markets it's not even occasional, but now a predictable/cyclical phenomenon. The vulnerability of markets to failure generally doesn't say anything about the ethical character of market participants, most of whom are stuck with whatever circumstances that they confront. No doubt "bad" actors sometimes have some contingent role in determining the timing, trigger, etc. of a market failure -- but the point is that a "good market" is one that cannot be easily (hence frequently) perturbed by any participant regardless of their intentions or actions. While the intentions of most market actors don't really matter all that much, the same is not true for those who enjoy the rare luxury of being able to define and launch a new market of their own. They -- we -- are obliged to consider the consequences of what we set in motion, because we do have choices -- many of which will not be available, or reversible, or modifiable without great cost by those who have to live with(in) that market once it's set in motion. I'm not even close to being the smartest or most experienced person on this list -- am probably much closer to the other end of the spectrum -- but I've seen plenty of "strategic behavior" like this both in commercial institutions that I've worked for and in others that I've worked/interacted with. I know many readers of this list who have seen much, much more. If I can figure this out, then it's a good bet that many others already have, and that many more will, with 100% certainty, as soon as the incentives that a transfer market would create actually come into play. So, to paraphrase Yakov's 1995 Montreal presentation once again, we may choose to deny or simply ignore the possible/predictable consequences of the forces that we set in motion, but that won't stop them from working, or absolve us for the consequences. Ditto failing to take any action at all. I received a couple of offlist responses asking, in effect, when "the other shoe is gong to drop." I'll drop one of my own later this weekend (fair warning: many of you have already been subjected to it, willingly or unwillingly, in Denver or Taipei or Berlin), but I'll be even more interested to hear from others how to mitigate if not eliminate these risks -- and/or how and why my prediction is flawed. I would like (almost) nothing better.... Thanks, TV From owen at delong.com Sat Jun 21 03:37:19 2008 From: owen at delong.com (Owen DeLong) Date: Sat, 21 Jun 2008 00:37:19 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why thetriggerdate? In-Reply-To: <20080621002158.GB3189@ussenterprise.ufp.org> References: <443de7ad0806201242k1004b7f6o4051e7110a857a2f@mail.gmail.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E7@SUEXCL-02.ad.syr.edu> <20080621002158.GB3189@ussenterprise.ufp.org> Message-ID: On Jun 20, 2008, at 5:21 PM, Leo Bicknell wrote: > In a message written on Fri, Jun 20, 2008 at 07:27:31PM -0400, > Milton L Mueller wrote: >> Those conditions are ridiculous. Or rather, as Owen and Leo have >> basically confessed in public, they were designed by people who don't >> want there to be transfer markets at all. > > I believe this incorrectly states the history. > > The AC developed this proposal together. Of the 15 members several > are quite pro-market, several are quite anti-market, many are > somewhere in the middle.. If anything it could be called a > "bipartisen > bill". > > My own history is that I was mildly pro-market prior to the AC > taking on the task of developing the policy proposal. As I considered > the options seriously and in-depth I moved to a anti-market position. > > Some on the AC did just the opposite. > I also started out mildly pro-market although I absolutely opposed an unregulated market. Indeed, it is watching the discussion and the process of attempting to develop appropriate regulations for such a market which caused me to move to an anit-market position. Owen From owen at delong.com Sat Jun 21 04:01:29 2008 From: owen at delong.com (Owen DeLong) Date: Sat, 21 Jun 2008 01:01:29 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <485C84E4.7040606@internap.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> Message-ID: > However, that's not the debate around 2008-2. The question at hand is > which would better serve the needs of the community after the free > pool > is exhausted: a market-based transfer system, or a simple > discontinuation of all IPv4 allocations from RIRs? To me, this assumes facts not in evidence. Namely: 1. It assumes people who realize that there is no valid market for their address space will still refuse to return it for recycling. 2. It assumes that Markets will significantly increase the amount of address space that is returned. 3. It assumes that the RIRs will not be able to issue any returned space after free pool exhaustion. I am not convinced any of those three things are true. Therefore, I am not convinced that the choices are the only ones available to us. Owen From mueller at syr.edu Sat Jun 21 05:27:57 2008 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 21 Jun 2008 05:27:57 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD90188411B@SUEXCL-02.ad.syr.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0D9F2@SUEXCL-02.ad.syr.edu> I don't think this kind of ranting is useful. > -----Original Message----- > > > NO, Milton, it's YOUR position. YOU were the one who said that > you had "more addresses than I needed" YOU are the > "ideologically motivated" person, here. > > -I- never said that -I- had more addresses than -I- needed, nor > did anyone else. > > YOU were the one who brought that up. NOT ME. > > >then there should be no transfer policy at all, right? > > There already is a transfer policy. It's called, returning the > addresses you don't need to those who assigned them, so they can > be handed out to those who do need them. > > You should try it out before just assuming that it won't work. > > >So while it is evident that that attitude has shaped the nature of > >ARIN's policy, it is not really relevant to defining a transfer policy > >once you decide to have one. > > However we haven't yet decided to have one. Thus, your out of order. > > >>ARIN policy isn't supposed to be based on an economic rationale. > > >Um. Policies pertaining to scarce resources used by global industries > >that aren't grounded in sound economic concepts about actual behavior > >under conditions of scarcity cannot succeed. > > Spoken like a dyed in the wool trickle-down economist. Where is the > scarce resource? Numbers? We have lots of addresses. Just because > they aren't the color you want, doesen't mean they won't work. > > >The greatest good for the greatest number cannot be achieved without > >taking actors' economic incentives into account. > > It's done all of the time. > > >>See below. > >>By definition, if you have "too much" address space then you > >>are required under the RSA you signed to return it. Why - because > [snip] > >>Therefore your hypothetical situation -cannot- exist pre-IPv4 runout. > >Your statement describes an idealized interpretation of what you consider > >to be a moral obligation. It does not describe how people actually > behave. > > Explain then why so many organizations have returned addressing, then. > They apparently weren't reading the same textbooks that you were. > > > Thus, your statement that the situatuion "cannot" exist is factually > > incorrect. The situation does exist, and "everyone knows it does" > > Lame argumentum ad populum won't save you now, > > >Further, the situation exists both before and after IANA's free pool > exhaustion. > >The modification of the ARIN requirements to permit "selling" > >effectively modifies the existing RSAs that people have signed, > >because it basically says that "After IPv4-runout we don't give a crap > >how you got your IPv4, whether honestly or not, from this point on we all > >have a clean slate" This is why such a policy is a horrible idea pre-IPv4 > runout. > > >OK, I am glad that you finally got around to attempting to answer my > >question. And your anwer is, presumably, that the "clean slate" > >facilitates the transfer of resources from people who value them less to > >people who value them more. And my simple observation is that if it makes > >sense to do that after IANA pool depletion, it makes sense to do it > beforehand. > > And if it makes sense to clean the stuff out of the cat litter box > after we buy the cat, it makes sense to do it before we buy the cat... > > Come off it Milton. We aren't that dumb to fall for one of these > leading arguments. > > Ted From mueller at syr.edu Sat Jun 21 05:39:12 2008 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 21 Jun 2008 05:39:12 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net><20080621042744.GA16756@vacation.karoshi.com.><485C84E4.7040606@internap.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0D9F3@SUEXCL-02.ad.syr.edu> > -----Original Message----- > To me, this assumes facts not in evidence. > > 1. It assumes people who realize that there is no valid market > for their address space will still refuse to return it for > recycling. A pretty reasonable assumption, given what we've seen so far. Just insert the word "most" between "assumes" and "people." > 2. It assumes that Markets will significantly increase the amount > of address space that is returned. Again, hard to argue with this one, and an assumption that seems to be tacitly supported by your own concerns about rampant speculation. > 3. It assumes that the RIRs will not be able to issue any > returned space after free pool exhaustion. > If assumptions 1 and 2 turn out to be true, this one just flows logically. Although the words "not be able to issue _any_ returned space" is too extreme. I am sure there will be SOME returns; I am also sure that most of the potential returns will NOT happen without economic incentives. From ppml at rs.seastrom.com Sat Jun 21 08:03:33 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Sat, 21 Jun 2008 08:03:33 -0400 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freezeperiod? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D9E3@SUEXCL-02.ad.syr.edu> (Milton L. Mueller's message of "Fri, 20 Jun 2008 18:53:04 -0400") References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu> <20080620163443.GB74707@ussenterprise.ufp.org> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E0@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E3@SUEXCL-02.ad.syr.edu> Message-ID: <86hcbnc7vu.fsf@seastrom.com> Note that these are both restrictions on the transferor, not the transferee. The goal here is to create a situation where organizations *who are not using their address space* are incented to give up some or all of it. While there may indeed be corner cases where organizations suddenly don't need any of their addresses, in the vast majority of situations demand has been following some sort of curve over time and either increasing (in which case in all probability the organization will be a transferee in the future) or decreasing (in which case the organization will not have been back to ARIN in a while) or remained constant (in which case, the organization might not even be an ARIN member, having pre-RIR space). There is no goal of creating a market where people can speculate, and the two year pre-transfer clause helps mitigate concerns about ARIN having to deal with fabricated requests creating a run on the market. I am categorically against having any shorter period of time than two years or getting rid of the before/after dual restriction. I would be an enthusiastic proponent of expanding the timeouts on both sides of the event to three years or whatever the time between "right now" and the best guesstimate of IPv4 ARIN-exhaustion-of-final-block is, whichever is less. ---Rob "Milton L Mueller" writes: > Oops, I pasted the wrong text in. > Here is the selection from 8.3.1. apologies to all: > > * The transferor has not received any IPv4 allocations or assignments > from ARIN (through ordinary allocations or assignments, or through this > Simple Transfer policy) within the preceding 24 months. > * The transferor may not request any IPv4 allocations or assignments > from ARIN (through ordinary allocations or assignments, or through this > Simple Transfer policy) within the subsequent 24 months. > >> -----Original Message----- >> >> > -----Original Message----- >> > From: Leo Bicknell [mailto:bicknell at ufp.org] >> > >> > Correction, a 2 year time out on IPv4 resources only. >> >> Nope. 4 years. You can't have gotten any ARIN or transfer resources 2 >> years _prior_ to the transfer, and you can't get any 2 years after. >> 2+2=4. >> >> Exact quotes: >> Nope. 4 years. You can't have gotten any ARIN or transfer resources 2 >> years _prior_ to the transfer, and you can't get any 2 years after. >> 2+2=4. >> >> Your position is relatively reasonable. As I said in my prior message, > I >> think RIPE handled this correctly. You restrict what the RECIPIENT of >> the market-transfer does with the transferred addresses for two years, >> not the releaser. That stops speculation cold. >> >> _______________________________________________ >> 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From ppml at rs.seastrom.com Sat Jun 21 08:24:47 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Sat, 21 Jun 2008 08:24:47 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why thetriggerdate? In-Reply-To: (Owen DeLong's message of "Sat, 21 Jun 2008 00:37:19 -0700") References: <443de7ad0806201242k1004b7f6o4051e7110a857a2f@mail.gmail.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E7@SUEXCL-02.ad.syr.edu> <20080621002158.GB3189@ussenterprise.ufp.org> Message-ID: <86lk0zasc0.fsf@seastrom.com> Owen DeLong writes: > On Jun 20, 2008, at 5:21 PM, Leo Bicknell wrote: > >> In a message written on Fri, Jun 20, 2008 at 07:27:31PM -0400, >> Milton L Mueller wrote: >>> Those conditions are ridiculous. Or rather, as Owen and Leo have >>> basically confessed in public, they were designed by people who don't >>> want there to be transfer markets at all. >> >> I believe this incorrectly states the history. >> >> The AC developed this proposal together. Of the 15 members several >> are quite pro-market, several are quite anti-market, many are >> somewhere in the middle.. If anything it could be called a >> "bipartisen >> bill". >> >> My own history is that I was mildly pro-market prior to the AC >> taking on the task of developing the policy proposal. As I considered >> the options seriously and in-depth I moved to a anti-market position. >> >> Some on the AC did just the opposite. >> > I also started out mildly pro-market although I absolutely opposed an > unregulated market. Indeed, it is watching the discussion and the > process of attempting to develop appropriate regulations for such > a market which caused me to move to an anit-market position. And for a counterexample, I started as quite anti-market, hoping that runout with absolutely no contingency plan for transfer of addresses would speed v6 adoption. I'm still concerned that creating a market will dull perceptions about the finality of run-out; we emphatically do not want to promulgate the belief that it will be business mostly as usual except with higher prices. On the other hand, the market exists right now, it's just unregulated and shadowy because it is prohibited by policy. Acknowledging the existence of the market and putting a modicum of regulation on it is certainly in the interest of the buyers, and likely in the interest of the sellers as well, since fair pricing can be established on more than an anecdotal basis. So I'm somewhat pro-market at this time. Disclaimer here is that I'm one of a minority of people on the AC who has personal or employer-assigned legacy space. I'm not planning on getting rid of any of my /23 as it is needed for my own activities, and I think we're all in the same boat on that point. -r From mueller at syr.edu Sat Jun 21 09:26:00 2008 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 21 Jun 2008 09:26:00 -0400 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freezeperiod? In-Reply-To: <86hcbnc7vu.fsf@seastrom.com> References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu><20080620163443.GB74707@ussenterprise.ufp.org><7663C7E01D8E094989CA62F0B0D21CD901E0D9E0@SUEXCL-02.ad.syr.edu><7663C7E01D8E094989CA62F0B0D21CD901E0D9E3@SUEXCL-02.ad.syr.edu> <86hcbnc7vu.fsf@seastrom.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0D9F6@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: Robert E. Seastrom [mailto:rs at seastrom.com] On Behalf Of Robert E. > > Note that these are both restrictions on the transferor, not the > transferee. Yes, I understand that. And if your target is truly speculation, the restrictions seem to be targeting the wrong side of the transaction. Note that true speculators are likely to be, indeed must be, first recipient and then sources of addresses. You can't speculate without first buying and then selling, and the pure speculator wants to be able to control the time at which they sell to capture the highest price. So a long-term restriction on what the recipient does with transferred addresses is much more on target than a restriction on the source. > The goal here is to create a situation where organizations *who are > not using their address space* are incented to give up some or all of > it. Indeed. So restrictions on the transferor (source) are more likely to interfere with the incentive to release address resources in a way that undermines the goal of the policy. As Scott noted, the only thing you want to do with the source is make sure that they don't sell their assignment and then come back to ARIN for more for free. The only other reason you have cited to impose a prior 2-year restraint on sources is to prevent "fabricated requests" and "creating a run on the market." This argument shows a rather interesting lack of faith in the vaunted "needs-based assessment." Are you suggesting that you don't think ARIN staff can distinguish between real and fabricated requests? If it can, this is no problem, because unnecessary requests will not be rewarded. If it can't, then the run on the bank will occur even if there is no transfer policy of any kind. > I would be > an enthusiastic proponent of expanding the timeouts on both sides of > the event to three years or whatever the time between "right now" and > the best guesstimate of IPv4 ARIN-exhaustion-of-final-block is, > whichever is less. This attitude reveals a lack of awareness of the cost-benefit tradeoffs that will define how the policy actually works in practice. If the timeouts on sources are too long you undermine the incentives to release. So if you recognize the need for a transfer policy, as you seem to do, reluctantly, you can't just expand the timeouts indefinitely. From bicknell at ufp.org Sat Jun 21 10:08:10 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 21 Jun 2008 10:08:10 -0400 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freezeperiod? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D9F6@SUEXCL-02.ad.syr.edu> References: <86hcbnc7vu.fsf@seastrom.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D9F6@SUEXCL-02.ad.syr.edu> Message-ID: <20080621140810.GA42915@ussenterprise.ufp.org> In a message written on Sat, Jun 21, 2008 at 09:26:00AM -0400, Milton L Mueller wrote: > Note that true speculators are likely to be, indeed must be, first > recipient and then sources of addresses. > > You can't speculate without first buying and then selling, and the pure > speculator wants to be able to control the time at which they sell to > capture the highest price. So a long-term restriction on what the > recipient does with transferred addresses is much more on target than a > restriction on the source. You've actually raised an interesting point here because it changes over time. Were the policy to be implemented prior to ARIN run-out (and since it is triggered at IANA run out as written that is the case right now) then a speculator need not buy first on the market. Rather they can requet space from ARIN like anyone else. While ARIN would not accept "I want them so I can sell them in a year" as justification (I hope!); through some combination of bending the truth and/or various activities (like shell companies who may actually "build something") I'm sure various people will try it. We've seen how creative people can be to try and sell address space. Post-run out your statement becomes correct, the only way for a speculator to have addresses to sell is to purchase them on the market first and then hold them for some period of time. -- 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: 187 bytes Desc: not available URL: From ppml at rs.seastrom.com Sat Jun 21 11:36:15 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Sat, 21 Jun 2008 11:36:15 -0400 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freezeperiod? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D9F6@SUEXCL-02.ad.syr.edu> (Milton L. Mueller's message of "Sat, 21 Jun 2008 09:26:00 -0400") References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu> <20080620163443.GB74707@ussenterprise.ufp.org> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E0@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E3@SUEXCL-02.ad.syr.edu> <86hcbnc7vu.fsf@seastrom.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D9F6@SUEXCL-02.ad.syr.edu> Message-ID: <86r6aqiyvk.fsf@seastrom.com> "Milton L Mueller" writes: > Note that true speculators are likely to be, indeed must be, first > recipient and then sources of addresses. > > You can't speculate without first buying and then selling, and the pure > speculator wants to be able to control the time at which they sell to > capture the highest price. So a long-term restriction on what the > recipient does with transferred addresses is much more on target than a > restriction on the source. These two paragraphs are at odds with each other. I believe the right place to first raise the restrictions is as close to the source of the address space as possible, that is, the speculator himself. > Indeed. So restrictions on the transferor (source) are more likely to > interfere with the incentive to release address resources in a way that > undermines the goal of the policy. Complete disagreement here. Restrictions on the transferor and transferee are different sides of the same coin, but restrictions on the transferor are closer to the source and more likely to catch people's attention. > As Scott noted, the only thing you want to do with the source is make > sure that they don't sell their assignment and then come back to ARIN > for more for free. Or go back into the market, driving up the prices needlessly. > The only other reason you have cited to impose a prior 2-year restraint > on sources is to prevent "fabricated requests" and "creating a run on > the market." > > This argument shows a rather interesting lack of faith in the vaunted > "needs-based assessment." Are you suggesting that you don't think ARIN > staff can distinguish between real and fabricated requests? If it can, > this is no problem, because unnecessary requests will not be rewarded. > If it can't, then the run on the bank will occur even if there is no > transfer policy of any kind. I have a huge amount of faith in ARIN's analysts and believe that they do an exceptionally good job today of making sure that requests that are blatantly fabricated don't slip through. I do not make the error (as you seem to have) of assuming that everything is black and white, or that every ARIN analyst is as good as his officemate. If we create a situation where there is a big uptick in the number of requests that hit ARIN, we are going to be faced with a situation where an analyst with a few weeks of experience is going to be called upon to do the job of someone with a few years of experience. Creating a climate in which the incentive to fib on one's applications is increased rather than decreased, is a step away from goodness. I'm not for it. >> I would be >> an enthusiastic proponent of expanding the timeouts on both sides of >> the event to three years or whatever the time between "right now" and >> the best guesstimate of IPv4 ARIN-exhaustion-of-final-block is, >> whichever is less. > > This attitude reveals a lack of awareness of the cost-benefit tradeoffs > that will define how the policy actually works in practice. If the > timeouts on sources are too long you undermine the incentives to > release. So if you recognize the need for a transfer policy, as you seem > to do, reluctantly, you can't just expand the timeouts indefinitely. I didn't suggest expanding the timeouts indefinitely, and I've put plenty of thought into the cost-benefit tradeoffs involved in how the policy will actually work in practice. You're free to believe otherwise of course, but I don't think any of my colleagues on the AC will join you in accusing me of being unaware of what's going on here as you have. ---rob (on the ac, would never dream of speaking for it) From tvest at pch.net Sat Jun 21 11:39:54 2008 From: tvest at pch.net (Tom Vest) Date: Sat, 21 Jun 2008 11:39:54 -0400 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freezeperiod? In-Reply-To: <86hcbnc7vu.fsf@seastrom.com> References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu> <20080620163443.GB74707@ussenterprise.ufp.org> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E0@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E3@SUEXCL-02.ad.syr.edu> <86hcbnc7vu.fsf@seastrom.com> Message-ID: I'm just curious: assuming that decentralized resource transfers are approved with *any* policy-based requirements or limitations, what mechanisms will survive to enable the community to do the following: 1. Establish the primacy of the surviving policies in (at least some) cases where they conflict with more general property-based laws, requirements, and limitations, and/or possession/ownership-related rights & privileges. 2. Exert influence of any kind (carrots, sticks, et al.) to encourage adherence to the surviving community policies. 3. Know when the policies are being being followed, and when they are not being followed. 4. Assuming noncompliance is detectable, exert influence of any kind (carrots, sticks, et al.) to encourage remedial action. 5. Promote ongoing community interest, or get consistent input/ feedback by any other means, on any number resources or policies within the scope of the transfer proposal. For anyone generous enough to respond, I'd be especially grateful for specifics (e.g., point-by-point, or at least individual point-level answers, matched with specific policies or RIR/community coordination- like jobs). Thanks, TV On Jun 21, 2008, at 8:03 AM, Robert E. Seastrom wrote: > > Note that these are both restrictions on the transferor, not the > transferee. > > The goal here is to create a situation where organizations *who are > not using their address space* are incented to give up some or all of > it. While there may indeed be corner cases where organizations > suddenly don't need any of their addresses, in the vast majority of > situations demand has been following some sort of curve over time and > either increasing (in which case in all probability the organization > will be a transferee in the future) or decreasing (in which case the > organization will not have been back to ARIN in a while) or remained > constant (in which case, the organization might not even be an ARIN > member, having pre-RIR space). > > There is no goal of creating a market where people can speculate, and > the two year pre-transfer clause helps mitigate concerns about ARIN > having to deal with fabricated requests creating a run on the market. > > I am categorically against having any shorter period of time than two > years or getting rid of the before/after dual restriction. I would be > an enthusiastic proponent of expanding the timeouts on both sides of > the event to three years or whatever the time between "right now" and > the best guesstimate of IPv4 ARIN-exhaustion-of-final-block is, > whichever is less. > > ---Rob > > "Milton L Mueller" writes: > >> Oops, I pasted the wrong text in. >> Here is the selection from 8.3.1. apologies to all: >> >> * The transferor has not received any IPv4 allocations or assignments >> from ARIN (through ordinary allocations or assignments, or through >> this >> Simple Transfer policy) within the preceding 24 months. >> * The transferor may not request any IPv4 allocations or assignments >> from ARIN (through ordinary allocations or assignments, or through >> this >> Simple Transfer policy) within the subsequent 24 months. >> >>> -----Original Message----- >>> >>>> -----Original Message----- >>>> From: Leo Bicknell [mailto:bicknell at ufp.org] >>>> >>>> Correction, a 2 year time out on IPv4 resources only. >>> >>> Nope. 4 years. You can't have gotten any ARIN or transfer >>> resources 2 >>> years _prior_ to the transfer, and you can't get any 2 years after. >>> 2+2=4. >>> >>> Exact quotes: >>> Nope. 4 years. You can't have gotten any ARIN or transfer >>> resources 2 >>> years _prior_ to the transfer, and you can't get any 2 years after. >>> 2+2=4. >>> >>> Your position is relatively reasonable. As I said in my prior >>> message, >> I >>> think RIPE handled this correctly. You restrict what the RECIPIENT >>> of >>> the market-transfer does with the transferred addresses for two >>> years, >>> not the releaser. That stops speculation cold. >>> >>> _______________________________________________ >>> 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From owen at delong.com Sat Jun 21 12:14:14 2008 From: owen at delong.com (Owen DeLong) Date: Sat, 21 Jun 2008 09:14:14 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D9F3@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net><20080621042744.GA16756@vacation.karoshi.com.><485C84E4.7040606@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D9F3@SUEXCL-02.ad.syr.edu> Message-ID: <08F26523-9930-4312-AA2C-327B9A58C65B@delong.com> On Jun 21, 2008, at 2:39 AM, Milton L Mueller wrote: > > >> -----Original Message----- >> To me, this assumes facts not in evidence. >> >> 1. It assumes people who realize that there is no valid > market >> for their address space will still refuse to return it > for >> recycling. > > A pretty reasonable assumption, given what we've seen so far. Just > insert the word "most" between "assumes" and "people." > Perhaps. OTOH, I think it is just as reasonable to assume that some fraction of those holding address space they do not need are doing so because they believe there will be a future value to it. >> 2. It assumes that Markets will significantly increase the > amount >> of address space that is returned. > > Again, hard to argue with this one, and an assumption that seems to be > tacitly supported by your own concerns about rampant speculation. > I'm not convinced that there is a significant amount of free address space out there. Further, I am not convinced that a market will actually cause people to parcel it out. Finally, I am not convinced that doing so will actually help in any meaningful way. As such, I don't think that this is actually supported. My concern about preventing speculation does not mean that I expect a significant amount of address space to be made available, but, rather that speculation could eliminate any benefit to the community that could be achieved by a market. >> 3. It assumes that the RIRs will not be able to issue any >> returned space after free pool exhaustion. >> > > If assumptions 1 and 2 turn out to be true, this one just flows > logically. Although the words "not be able to issue _any_ returned > space" is too extreme. I am sure there will be SOME returns; I am also > sure that most of the potential returns will NOT happen without > economic > incentives. I'm not so sure that if we were to make it clear a market will not be legitimized that those few who are holding on to resources in the hope to realize future value will continue to retain them. I'm sure some will. I'm sure some will not. I think that any statement about what fraction will fit into each category is purely speculation at this time. I'm not sure that many returns will occur with incentives. Since I am not convinced that the assumptions in 1 and 2 are as assured as you are, then, it also follows that 3 is equally invalid. Owen From paul at vix.com Sat Jun 21 12:52:49 2008 From: paul at vix.com (Paul Vixie) Date: Sat, 21 Jun 2008 16:52:49 +0000 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: Your message of "Sat, 21 Jun 2008 01:01:29 MST." References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> Message-ID: <30546.1214067169@sa.vix.com> > From: Owen DeLong > ... > To me, this assumes facts not in evidence. > ... > I am not convinced any of those three things are true. Therefore, I am not > convinced that the choices are the only ones available to us. most of ipv4 is legacy, and much of that isn't globally routed right now, and i think that the pro-market position in light of those facts is, a lot of that space is going to come into use, and the community needs to provide a paper trail for same. that paper trail would include LRSA and qualifying transfers, since voluntary recycling appears to be less likely than black marketeering, and black marketeering would significantly pollute and devalue the records we see by "whois" and probably lead to more deaggregation than a transfer system. the anti-market position in light of those facts appears to be, ipv4 consumption is driven by large allocations, which are speeding up over time, and cannot be indefinitely met by ipv4 no matter how much of the legacy space is recycled or remarketed, since we'll either face explosive deaggregation or still have to do double- and triple-NAT and application growth will slow down. most of us are, in the above terms, both pro-market and anti-market. there's no way forward without some kind of miracle, such as 464 or LISP or similar. and while it may be irresponsible to incorporate a "necessary but unknown miracle" into one's plans, that's where the reduction leads in this case. and this is what bolsters the case for "stop prolonging the life of ipv4, we might all hate the costs and complexities of ipv6, but the sooner we all bite that bullet the better off we will all be." or even "dead or alive, you're coming with me" (oops, "market or no market, we're all going to be using ipv6 soon.") From sleibrand at internap.com Sat Jun 21 13:14:20 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 21 Jun 2008 10:14:20 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <08F26523-9930-4312-AA2C-327B9A58C65B@delong.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net><20080621042744.GA16756@vacation.karoshi.com.><485C84E4.7040606@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D9F3@SUEXCL-02.ad.syr.edu> <08F26523-9930-4312-AA2C-327B9A58C65B@delong.com> Message-ID: <485D36EC.5040507@internap.com> Owen DeLong wrote: > > I think it is just as reasonable to assume that some > fraction of those holding address space they do not need are doing > so because they believe there will be a future value to it. This is almost a tautology: everyone who holds address space does so either because they believe it will have value to them at some point, or because of inertia. Value is not something created by a market. A wife's love is one of the most valuable things on the planet: just because it can't be traded doesn't make it any less so. In the case of IPv4 addresses, they have value because you can use them on the Internet, or reassign them to customers to do so. > I'm not so sure that if we were to make it clear a market will not be > legitimized that those few who are holding on to resources in > the hope to realize future value will continue to retain them. > I'm sure some will. I'm sure some will not. I think that any > statement about what fraction will fit into each category is > purely speculation at this time. I disagree. If you understand that "hoping to realize future value" does *not* equate to "hoping to be able to directly sell them for money", then no matter what we do, IPv4 addresses will have future value up until the point that IPv6 adoption is far enough along that people no longer need IPv4 addresses to have good Internet connectivity. Given that most organizations will see some future value in their IPv4 addresses, I see it as quite unlikely that we'll see enough voluntary, non-incentivized returns of address space to meet more than about 10% of the demand for IPv4 addresses post-exhaustion. Therefore, I see two alternatives: either do nothing, and force long enough (gas)^W IPv4 lines to get people to (buy electric cars)^W^W^W migrate to IPv6, or provide incentives to IPv4 address holders to give up their space. The latter still provides a strong economic incentive to move to IPv6, but it does so without the disruption of shortages. -Scott From bicknell at ufp.org Sat Jun 21 14:03:51 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 21 Jun 2008 14:03:51 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <30546.1214067169@sa.vix.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> Message-ID: <20080621180351.GA56882@ussenterprise.ufp.org> In a message written on Sat, Jun 21, 2008 at 04:52:49PM +0000, Paul Vixie wrote: > most of ipv4 is legacy, and much of that isn't globally routed right now, and I'm not sure either of these assertations is supported by the facts. I believe the threshold has flipped, that RIR assigned space is larger than legacy space. Also, I think for the purposes of the rest of your e-mail "legacy" isn't the right delimiter, but rather is the space under an RSA. Legacy holders have migrated legacy space under both standard and legacy RSA's. APNIC passed a policy that required all legacy space to fall under their RSA, for instance. I would love to have a hard number, but my feeling is perhaps 1/3 of all allocated (by anyone) space is not under any RSA at this time. As for much of that isn't globally routed, again, I think the number is wrong on its face; but it's also the wrong thing to consider. It has been documented that at least a few legacy blocks, while not routed on the global internet, are used by extensive internal networks. If your premise is non-globally routed space might come onto a market then I think you need to exclude these networks, or at least pro-rate them in some reasonable way. I think there are also interesting non-technical cases to consider. For instance, several people like to talk about various large universities with what appears to be more space than they need. Many of these same universities are being hauled before congress right now having to explain why they have such large endowments, and why they should keep their tax except status. Several are giving away free tuition just to appear to not be abusing the system. I would submit the last thing they would want to do right now is take a resource provided to them by the government for free and sell it at huge profit; that would not help their case at all. Personally I think we might see on the order of 10-15 /8's worth of space come onto the market in total. I belive that could extend overall IPv4 by 1-2 years. -- 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: 187 bytes Desc: not available URL: From paul at vix.com Sat Jun 21 14:09:04 2008 From: paul at vix.com (Paul Vixie) Date: Sat, 21 Jun 2008 18:09:04 +0000 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freezeperiod? In-Reply-To: Your message of "Sat, 21 Jun 2008 10:08:10 -0400." <20080621140810.GA42915@ussenterprise.ufp.org> References: <86hcbnc7vu.fsf@seastrom.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D9F6@SUEXCL-02.ad.syr.edu> <20080621140810.GA42915@ussenterprise.ufp.org> Message-ID: <32559.1214071744@sa.vix.com> > From: Leo Bicknell > ... > Post-run out your statement becomes correct, the only way for a > speculator to have addresses to sell is to purchase them on the > market first and then hold them for some period of time. if i were a speculator, i'd set some kind of floor price and bid aggressively on everything that comes available. since there's only 2^32, a couple billion $USD is all it would take to corner the market. since the costs of moving to ipv6 are perceived as very high, i'd offer to lease the use of these resources on a recurring cost basis. if i were doing this in the person of china or google or cogent, i'd keep the lease periods short to ensure market instability and also ensure that i could end certain leases when i needed to consume some of the space (or to put some kind of pressure on a competitor at just the wrong moment.) if i were doing this as a VC-funded "numbers play" i'd make the lease periods moderately longer to ensure market stability while still clearing a minimum of 10X my initial investment during the time it would take the world to switch to ipv6, and, i'd keep prices low enough to keep the ipv6 transition cost higher than the recurring lease costs, so that the serfs would remain somnambulant. there's no hope that one or both of these won't happen, since ipv4 is at this moment something large companies with money "must have". i foresee a robust market with high prices as the speculators, who are no doubt already organizing themselves, divide the pie. note that some speculators won't go in as buyers but rather as property managers, telling HP or MIT that they can help monetize these "assets" for a share of the recurring lease revenue. sitting out, or recycling through the RIRs, or selling early, are all stupid things to do if you have a lot of (money or address space) and ambition. the only the way the world could prevent an oil-like speculators market in ipv4 and thus avoid being a cash cow for the harvard business school grads was to adopt ipv6 before they had to, and folks generally felt like that would also be stupid. From kc at caida.org Sat Jun 21 15:28:20 2008 From: kc at caida.org (k claffy) Date: Sat, 21 Jun 2008 12:28:20 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <30546.1214067169@sa.vix.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> Message-ID: <20080621192820.GA68347@rommie.caida.org> On Sat, Jun 21, 2008 at 04:52:49PM +0000, paul v wrote: most of us are, in the above terms, both pro-market and anti-market. there's no way forward without some kind of miracle, such as 464 or LISP or similar. that's inconsistent with your favorable stacking of this community against every other regulation system anywhere in the world any time in history. if we're so great at stewardship, how did we get so stuck so fast? and why are we now helping OECD call in meatspace regulatory systems to help deploy ipv6 http://www.oecd.org/dataoecd/7/1/40605942.pdf since our well-stacked system is failing to get it deployed? and while it may be irresponsible to incorporate a "necessary but unknown miracle" into one's plans, that's where the reduction leads in this case. and this is what bolsters the case for "stop prolonging the life of ipv4, we might all hate the costs and complexities of ipv6, but the sooner we all bite that bullet the better off we will all be." or even "dead or alive, you're coming with me" (oops, "market or no market, we're all going to be using ipv6 soon.") what about the miracle that has to happen for the current routing and economic architectures to accommodate a couple decades years of ipv6+ipv4 growth+splintering? or did someone get some numbers and some data to support realistic simulation of routing and market dynamics and this option looks quantitatively better now? or are you just recommending the option we have even less data about than the current system, because 'how could it possibly be as bad as what we have now?' counts as stewardship? 'our community' may have all the noble virtues you list, but they aren't the metrics by which history will judge stewardship. as we speed toward the edge of this cliff, no regulation system anywhere in the world at any time in history would give our system an A (or a B) for stewardship. let's be serious, we still don't even have a web page of related work or recommended reading, much less research of our own. we don't have scenario planning activities. we don't have empirically grounded analysis of any aspect of the macroeconomic dynamics. we don't know how to measure, much less model, the phenomena we're trying to understand. we're trying to optimize a few parameters with no regard for how those parameters interact with other parameters more vital to political economy. we have made no attempt to assess how much capital is (or should be) allocated to pursuing various solutions, or metrics for evaluating the progress of those solutions. there is no concerted funded effort to develop a long-term sustainable routing and addressing architecture while we argue about how to prolong the architecture(s) we all insist are inherently crippled. we're mostly trying to keep up with this conversation in addition to our day jobs, and we're proud to have as few regulatory experts in our 'regulatory system' as possible. many of the smartest people i know are in this community, but bragging doesn't seem in order. k From paul at vix.com Sat Jun 21 16:43:18 2008 From: paul at vix.com (Paul Vixie) Date: Sat, 21 Jun 2008 20:43:18 +0000 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: Your message of "Sat, 21 Jun 2008 12:28:20 MST." <20080621192820.GA68347@rommie.caida.org> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> Message-ID: <37052.1214080998@sa.vix.com> > most of us are, in the above terms, both pro-market and anti-market. > there's no way forward without some kind of miracle, such as 464 or LISP > or similar. > > that's inconsistent with your favorable stacking of this community against > every other regulation system anywhere in the world any time in history. i can see why it appears inconsistent. i'll try to straighten things out: > if we're so great at stewardship, how did we get so stuck so fast? and why > are we now helping OECD call in meatspace regulatory systems to help deploy > ipv6 http://www.oecd.org/dataoecd/7/1/40605942.pdf since our well-stacked > system is failing to get it deployed? we got stuck because there are no carrots or sticks. on the internet, if someone doesn't like what you're saying, they can just ignore you. we're asking meatspace for help getting ipv6 deployed because meatspace is harder to ignore. but these differences are in the nature of the problem spaces, not in the nature of the regulators. > and while it may be irresponsible to incorporate a "necessary but unknown > miracle" into one's plans, that's where the reduction leads in this case. > > what about the miracle that has to happen for the current routing and > economic architectures to accommodate a couple decades years of ipv6+ipv4 > growth+splintering? we've been riding moore's law. according to tli back in ARIN ABQ, that ride is over, and we'll need a different way to grow the internet soon/already. > 'our community' may have all the noble virtues you list, but they aren't the > metrics by which history will judge stewardship. that we built it at all and grew it this far this fast and that we generally knew at this juncture which of our problems weren't solvable is good enough for me. that is, make sure the historians photograph me on my best side. > many of the smartest people i know are in this community, but bragging > doesn't seem in order. i didn't mean to brag, honestly. i just don't like hearing this community called amateurs in the field of comms regulation, either because we're not, or because at the bar set by the internet, everybody everywhere everywhen is. From jcurran at istaff.org Sat Jun 21 17:29:41 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 21 Jun 2008 17:29:41 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <20080621192820.GA68347@rommie.caida.org> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> Message-ID: At 12:28 PM -0700 6/21/08, k claffy wrote: >if we're so great at stewardship, how did we get so stuck so fast? RFC 1669: The community opted to not to differentiate IPng (now IPv6) in terms of desirable end-user functionality, and that means that its deployment needs to be pushed by ISP's to solve their IPv4 depletion problem instead of deployed through end-user demand. >and why are we now helping >OECD call in meatspace regulatory systems to help deploy ipv6 >http://www.oecd.org/dataoecd/7/1/40605942.pdf since our >well-stacked system is failing to get it deployed? See above. There's going to be quite a few parties interested in how the global ISP community makes this happen over the next few years, particularly given the economic impact of getting it wrong. >what about the miracle that has to happen for the current >routing and economic architectures to accommodate a couple >decades years of ipv6+ipv4 growth+splintering? IPv6 routes are bigger, but there are several orders of magnitude fewer of them today. We certainly have the ability through policy to keep the number of IPv6 routes manageable if the community desires such. The IPv4 fragmentation impact is still open to debate, and likely quite variable depending on the introduction of "open" transfers and the exact policies adopted (if any). I'll maintain that today's policies for IPv4 and IPv6 allocation provide an option for growth without routing collapse, presuming you believe the equipment community, and we have a coordinated effort to move public Internet servers to IPv6, and the community maintains its conservative (in terms of routing impact) stance on IPv4 and IPv6 allocation policies. While I don't have rigorous analysis for the above personal statement, VAF's analysis from the IAB RAWS workshop suggest that staying the course for immediate (5 year) future is uncomfortable but manageable. The medium-term outlook may even require reducing IPv4 routing post-transition into to keep everything running. Long-term, we all know we'll need the EID/LOC split being explored by the IRTF RRG work. In light our vulnerable situation, it definitely would be nice if there were "some data to support realistic simulation of routing and market dynamics" that result from significant departures to our present IP resource allocation policy. To date there simply hasn't been any. This doesn't mean that we shouldn't necessarily make such changes, only that it requires an amount of faith given the stakes involved. >there is no concerted funded effort to develop a long-term sustainable >routing and addressing architecture while we argue about how to >prolong the architecture(s) we all insist are inherently crippled. Yes, that would be quite valuable. No, it's not the role of the ARIN, or the RIR's, or ISP's in general to make this happen. The IRTF RRG folks are out there working on this, and this community is waiting patiently for results. /John From randy at psg.com Sat Jun 21 18:39:36 2008 From: randy at psg.com (Randy Bush) Date: Sun, 22 Jun 2008 07:39:36 +0900 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> Message-ID: <485D8328.6050806@psg.com> > I'll maintain that today's policies for IPv4 and IPv6 allocation provide > an option for growth without routing collapse, presuming you believe > the equipment community, and we have a coordinated effort to move > public Internet servers to IPv6, and the community maintains its > conservative (in terms of routing impact) stance on IPv4 and IPv6 > allocation policies. after all, they have done so well keeping the /24s out of today's routing table. we have to be careful not to inhale too much of our own smoke. randy From jcurran at istaff.org Sat Jun 21 19:02:18 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 21 Jun 2008 19:02:18 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <485D8328.6050806@psg.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> <485D8328.6050806@psg.com> Message-ID: At 7:39 AM +0900 6/22/08, Randy Bush wrote: > > I'll maintain that today's policies for IPv4 and IPv6 allocation provide >> an option for growth without routing collapse, presuming you believe >> the equipment community, and we have a coordinated effort to move >> public Internet servers to IPv6, and the community maintains its >> conservative (in terms of routing impact) stance on IPv4 and IPv6 >> allocation policies. > >after all, they have done so well keeping the /24s out of today's >routing table. If ISP's care to route them, then there's obviously room to carry. >we have to be careful not to inhale too much of our own smoke. Full agreement there... kc calls for more modeling of outcomes and I agreed. We've got some modeling of status quo in the RAWS and IRTF RRG work, so at least there's some reality basis for extrapolation under current policies. Now, if we want to talk about smoke, where's all of the modeling from the open market folks regarding consequences to the routing table? /John From sleibrand at internap.com Sat Jun 21 19:49:10 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 21 Jun 2008 16:49:10 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> <485D8328.6050806@psg.com> Message-ID: <485D9376.5030409@internap.com> John Curran wrote: > Now, if we want to talk > about smoke, where's all of the modeling from the open market > folks regarding consequences to the routing table? Whom are you referring to as "open market folks"? In the case of 2008-2, the goal is to keep deaggregation pressures the same as they would be under a continuation of the current system (if we had more addresses to give out). In other words, I believe that the extrapolation of current routing table size trend lines that Schiller et. al. have presented represents the eventual situation under 2008-2 about as well as possible given the inherent uncertainties. On the other hand, I'm pretty sure that the proposed APNIC policy would result in an acceleration of routing table growth, which to my knowledge has not been modeled. -Scott From sleibrand at internap.com Sat Jun 21 19:57:29 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 21 Jun 2008 16:57:29 -0700 Subject: [arin-ppml] Q2: on Address Transfers - Enforcement mechanisms In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu> <20080620163443.GB74707@ussenterprise.ufp.org> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E0@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E3@SUEXCL-02.ad.syr.edu> <86hcbnc7vu.fsf@seastrom.com> Message-ID: <485D9569.4020701@internap.com> Tom Vest wrote: > I'm just curious: assuming that decentralized resource transfers are > approved with *any* policy-based requirements or limitations, what > mechanisms will survive to enable the community to do the following: > > 1. Establish the primacy of the surviving policies in (at least some) > cases where they conflict with more general property-based laws, > requirements, and limitations, and/or possession/ownership-related > rights & privileges. As I understand it the RSA controls for address blocks covered by one. For legacy blocks without an RSA, the situation is much murkier. > 2. Exert influence of any kind (carrots, sticks, et al.) to encourage > adherence to the surviving community policies. The primary carrot is inclusion in the ARIN listing service. The primary stick is that some ISPs require space be listed in whois before routing it. (/me waves at Heather.) > 3. Know when the policies are being being followed, and when they are > not being followed. ARIN staff are getting fairly good at fraud-sniffing. > 4. Assuming noncompliance is detectable, exert influence of any kind > (carrots, sticks, et al.) to encourage remedial action. ARIN can and does revoke space transferred fraudulently, or in a manner that violates a signed RSA. > 5. Promote ongoing community interest, or get consistent input/ > feedback by any other means, on any number resources or policies > within the scope of the transfer proposal. Not sure what you mean by this, unless you're just referring to the public policy process in general. -Scott > For anyone generous enough to respond, I'd be especially grateful for > specifics (e.g., point-by-point, or at least individual point-level > answers, matched with specific policies or RIR/community coordination- > like jobs). > > Thanks, > > TV > > On Jun 21, 2008, at 8:03 AM, Robert E. Seastrom wrote: > >> Note that these are both restrictions on the transferor, not the >> transferee. >> >> The goal here is to create a situation where organizations *who are >> not using their address space* are incented to give up some or all of >> it. While there may indeed be corner cases where organizations >> suddenly don't need any of their addresses, in the vast majority of >> situations demand has been following some sort of curve over time and >> either increasing (in which case in all probability the organization >> will be a transferee in the future) or decreasing (in which case the >> organization will not have been back to ARIN in a while) or remained >> constant (in which case, the organization might not even be an ARIN >> member, having pre-RIR space). >> >> There is no goal of creating a market where people can speculate, and >> the two year pre-transfer clause helps mitigate concerns about ARIN >> having to deal with fabricated requests creating a run on the market. >> >> I am categorically against having any shorter period of time than two >> years or getting rid of the before/after dual restriction. I would be >> an enthusiastic proponent of expanding the timeouts on both sides of >> the event to three years or whatever the time between "right now" and >> the best guesstimate of IPv4 ARIN-exhaustion-of-final-block is, >> whichever is less. >> >> ---Rob >> >> "Milton L Mueller" writes: >> >>> Oops, I pasted the wrong text in. >>> Here is the selection from 8.3.1. apologies to all: >>> >>> * The transferor has not received any IPv4 allocations or assignments >>> from ARIN (through ordinary allocations or assignments, or through >>> this >>> Simple Transfer policy) within the preceding 24 months. >>> * The transferor may not request any IPv4 allocations or assignments >>> from ARIN (through ordinary allocations or assignments, or through >>> this >>> Simple Transfer policy) within the subsequent 24 months. >>> >>>> -----Original Message----- >>>> >>>>> -----Original Message----- >>>>> From: Leo Bicknell [mailto:bicknell at ufp.org] >>>>> >>>>> Correction, a 2 year time out on IPv4 resources only. >>>> Nope. 4 years. You can't have gotten any ARIN or transfer >>>> resources 2 >>>> years _prior_ to the transfer, and you can't get any 2 years after. >>>> 2+2=4. >>>> >>>> Exact quotes: >>>> Nope. 4 years. You can't have gotten any ARIN or transfer >>>> resources 2 >>>> years _prior_ to the transfer, and you can't get any 2 years after. >>>> 2+2=4. >>>> >>>> Your position is relatively reasonable. As I said in my prior >>>> message, >>> I >>>> think RIPE handled this correctly. You restrict what the RECIPIENT >>>> of >>>> the market-transfer does with the transferred addresses for two >>>> years, >>>> not the releaser. That stops speculation cold. >>>> >>>> _______________________________________________ >>>> 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From randy at psg.com Sat Jun 21 20:33:29 2008 From: randy at psg.com (Randy Bush) Date: Sun, 22 Jun 2008 09:33:29 +0900 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> <485D8328.6050806@psg.com> Message-ID: <485D9DD9.9040907@psg.com> John Curran wrote: > where's all of the modeling from the open market folks regarding > consequences to the routing table? i believe lucy's theory. the vast majority of blocks will trade pretty much straight across in a year or so, flushing out the unused space; the goal of the exercise. follow the cash. what this discussion is really about is who gets the money, the rir bureaucracies or the holders of the resources. as usual, the internet can and will cut out the middleman. it's just business. get over it. the impact on the table will be that of bringing the current unannounced space back into use, multiplied by the idiocy factor that defrags current blocks no matter how acquired. and recycling them through the rir bureaucracies will have little effect except to monetize the process in favor of supporting the bureaucracies. and then, no matter how allocated by whom, slow continual defrag as more and more ipv4 space is used to front nats. again, irrespective of how acquired. that the arin region really has any control over the routing table any more is a fantasy overridden by greed and self-interest [0]. we are too good at overgrazing the commons and pissing in the drinking water. just look at the actual routing table, over half /24s. randy --- [0] - japan is a bit different; much more cooperative and conservative dealing with common resources and planning. but it is one small island chain. From jcurran at istaff.org Sun Jun 22 01:02:16 2008 From: jcurran at istaff.org (John Curran) Date: Sun, 22 Jun 2008 01:02:16 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <485D9DD9.9040907@psg.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> <485D8328.6050806@psg.com> <485D9DD9.9040907@psg.com> Message-ID: At 9:33 AM +0900 6/22/08, Randy Bush wrote: >John Curran wrote: >> where's all of the modeling from the open market folks regarding >> consequences to the routing table? > >i believe lucy's theory. the vast majority of blocks will trade pretty >much straight across in a year or so, flushing out the unused space; the >goal of the exercise. Agreed on the goal (flushing our the unused space), but see no reason why it will not deaggregate in the process of being flushed out if that has the highest return and is allowed by policy. >follow the cash. what this discussion is really about is who gets the >money, the rir bureaucracies or the holders of the resources. I don't know about other regions, but it's certainly not about that in the ARIN region. The ISP community has historically been pretty vocal about preventing completely uncontrolled block fragmentation (even though the routing table has plenty of examples of ISP's carrying more specifics for their own business reasons), and that's the real question on the table. Personally, I think RIR's need to plan for a long-term future where their mission with respect to registration services is rather staid, as IPv6 availability and allocation sizes will tend to preclude follow-on allocation requests, but that's a different topic for discussion... >the impact on the table will be that of bringing the current unannounced >space back into use, multiplied by the idiocy factor that defrags >current blocks no matter how acquired. Bringing currently unannounced space back into use definitely creates more entries, but currently blocks don't fragment from speculators trying to maximize value by breaking up blocks, nor to do they deaggregate due to constraints from the current transfer policy. The transfer policies in consideration in the various RIR's introduce new factors for fragmentation and as kc said, some realistic simulation of routing and market dynamics here would be useful. /John From randy at psg.com Sun Jun 22 01:30:04 2008 From: randy at psg.com (Randy Bush) Date: Sun, 22 Jun 2008 14:30:04 +0900 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> <485D8328.6050806@psg.com> <485D9DD9.9040907@psg.com> Message-ID: <485DE35C.4060302@psg.com> > Bringing currently unannounced space back into use definitely creates > more entries, but currently blocks don't fragment from speculators trying > to maximize value by breaking up blocks, nor to do they deaggregate due > to constraints from the current transfer policy. no, they degenerate *irrespective* of them. get over the fantasy; arin no longer plays any significant role in keeping fragmentation down. look at the routing table, not this list. you don't need a weatherman to know which way the wind blows. randy From randy at psg.com Sun Jun 22 02:05:36 2008 From: randy at psg.com (Randy Bush) Date: Sun, 22 Jun 2008 15:05:36 +0900 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> <485D8328.6050806@psg.com> <485D9DD9.9040907@psg.com> Message-ID: <485DEBB0.5060708@psg.com> >> Bringing currently unannounced space back into use definitely creates >> more entries, but currently blocks don't fragment from speculators trying >> to maximize value by breaking up blocks, nor to do they deaggregate due >> to constraints from the current transfer policy. > > no, they degenerate *irrespective* of them. get over the fantasy; arin > no longer plays any significant role in keeping fragmentation down. > look at the routing table, not this list. you don't need a weatherman > to know which way the wind blows. and what ipv4 free-pool run-out will do is cause ever increasing nat deployment, with v4 fronting the nats (whether they are v4 nats or nat-pt). these will be in front of almost all multi-homed sites, an ever increasing number. this will happen, again, irrespective of whether the space is exchanged on an open market or controlled by a trade association of market incumbents. it's just business. randy From owen at delong.com Sun Jun 22 06:26:04 2008 From: owen at delong.com (Owen DeLong) Date: Sun, 22 Jun 2008 03:26:04 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <485D9376.5030409@internap.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> <485D8328.6050806@psg.com> <485D9376.5030409@internap.com> Message-ID: <152B7CCD-9025-4DC0-94A5-673D681AA5EB@delong.com> On Jun 21, 2008, at 4:49 PM, Scott Leibrand wrote: > John Curran wrote: > >> Now, if we want to talk >> about smoke, where's all of the modeling from the open market >> folks regarding consequences to the routing table? > > > Whom are you referring to as "open market folks"? In the case of > 2008-2, the goal is to keep deaggregation pressures the same as they > would be under a continuation of the current system (if we had more > addresses to give out). In other words, I believe that the > extrapolation of current routing table size trend lines that Schiller > et. al. have presented represents the eventual situation under 2008-2 > about as well as possible given the inherent uncertainties. I don't believe for one second that 2008-2 as it is currently written would achieve this. I believe it will reduce the speed with which deaggregation and disaggregation pressures increase, but, in any market scenario, disaggregation pressures will increase. Some worse than others and APNICs proposal is certainly worse than 2008-2. Owen From mueller at syr.edu Sun Jun 22 10:25:53 2008 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 22 Jun 2008 10:25:53 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <20080621192820.GA68347@rommie.caida.org> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu><485BCF36.90101@sprunk.org><63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com><86372.1213980574@sa.vix.com><20080620173853.GA78555@ussenterprise.ufp.org><5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net><20080621042744.GA16756@vacation.karoshi.com.><485C84E4.7040606@internap.com><30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0DA05@SUEXCL-02.ad.syr.edu> Kc: I agree with many of your comments, but as a social scientist I can tell you that the science, modeling, empirically grounded analysis, etc., etc., that you call for is only one of many tugs and pulls on the policy making process. This is both good and bad. On the bad side, it means that things like political power, scare tactics, ignorance, inertia, and path dependency play as big a role as good science in shaping policy. On the good side, society is not a deterministic closed system like physics, social science models are inevitably a simplification and even the best of them can turn out to be outrageously wrong. So it's a relief that other factors are involved in actually influencing what happens. I agree that the "Internet community" shouldn't be patting itself on the back too much anymore, its main blunder being the lack of backwards compatibility of v6, but I also believe that compared to the historical evolution of other communication technologies (telephone, broadcasting, telegraph) I see nothing exceptionally bad about the performance of what I think Paul means by the "Internet community." Its greatest strength and greatest weakness is this assumption that the Internet is exceptional and that this legacy community bears some special responsibility that other policy shapers don't. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of k claffy > Sent: Saturday, June 21, 2008 3:28 PM > To: Paul Vixie > Cc: ARIN PPML > Subject: Re: [arin-ppml] Q1 - ARIN address transfer policy > > On Sat, Jun 21, 2008 at 04:52:49PM +0000, paul v wrote: > most of us are, in the above terms, both pro-market and anti-market. > there's > no way forward without some kind of miracle, such as 464 or LISP or > similar. > > that's inconsistent with your favorable stacking of this > community against every other regulation system anywhere in > the world any time in history. if we're so great at stewardship, > how did we get so stuck so fast? and why are we now helping > OECD call in meatspace regulatory systems to help deploy ipv6 > http://www.oecd.org/dataoecd/7/1/40605942.pdf since our > well-stacked system is failing to get it deployed? > > and while it may be irresponsible to incorporate a "necessary but > unknown > miracle" into one's plans, that's where the reduction leads in this > case. and > this is what bolsters the case for "stop prolonging the life of ipv4, we > might > all hate the costs and complexities of ipv6, but the sooner we all bite > that > bullet the better off we will all be." or even "dead or alive, you're > coming > with me" (oops, "market or no market, we're all going to be using ipv6 > soon.") > > what about the miracle that has to happen for the current > routing and economic architectures to accommodate a couple > decades years of ipv6+ipv4 growth+splintering? or did someone > get some numbers and some data to support realistic simulation > of routing and market dynamics and this option looks quantitatively > better now? or are you just recommending the option we have even > less data about than the current system, because 'how could it > possibly be as bad as what we have now?' counts as stewardship? > > 'our community' may have all the noble virtues you list, > but they aren't the metrics by which history will judge stewardship. > as we speed toward the edge of this cliff, no regulation > system anywhere in the world at any time in history would > give our system an A (or a B) for stewardship. let's be > serious, we still don't even have a web page of related work > or recommended reading, much less research of our own. we don't > have scenario planning activities. we don't have empirically > grounded analysis of any aspect of the macroeconomic dynamics. > we don't know how to measure, much less model, the phenomena > we're trying to understand. we're trying to optimize a few > parameters with no regard for how those parameters interact > with other parameters more vital to political economy. > we have made no attempt to assess how much capital is (or > should be) allocated to pursuing various solutions, or metrics > for evaluating the progress of those solutions. there is no > concerted funded effort to develop a long-term sustainable > routing and addressing architecture while we argue about how > to prolong the architecture(s) we all insist are inherently > crippled. we're mostly trying to keep up with this conversation > in addition to our day jobs, and we're proud to have as few > regulatory experts in our 'regulatory system' as possible. > > many of the smartest people i know are in this community, > but bragging doesn't seem in order. > > k > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. From mueller at syr.edu Sun Jun 22 10:42:17 2008 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 22 Jun 2008 10:42:17 -0400 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freezeperiod? In-Reply-To: <86r6aqiyvk.fsf@seastrom.com> References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu><20080620163443.GB74707@ussenterprise.ufp.org><7663C7E01D8E094989CA62F0B0D21CD901E0D9E0@SUEXCL-02.ad.syr.edu><7663C7E01D8E094989CA62F0B0D21CD901E0D9E3@SUEXCL-02.ad.syr.edu><86hcbnc7vu.fsf@seastrom.com><7663C7E01D8E094989CA62F0B0D21CD901E0D9F6@SUEXCL-02.ad.syr.edu> <86r6aqiyvk.fsf@seastrom.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0DA07@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: Robert E. Seastrom [mailto:rs at seastrom.com] On Behalf Of Robert E. > Complete disagreement here. Restrictions on the transferor and > transferee are different sides of the same coin, but restrictions on > the transferor are closer to the source and more likely to catch > people's attention. Closer to the source of what? I quite literally have no idea what you mean. >From what I've seen of your argument, you still aren't refuting my contention that you can catch speculation more effectively by restricting post-transfer sales than by slapping categorical restrictions on people who can transfer. > > As Scott noted, the only thing you want to do with the source is make > > sure that they don't sell their assignment and then come back to ARIN > > for more for free. > > Or go back into the market, driving up the prices needlessly. This comment makes no sense to me, and seems to be unrelated to the point about someone selling addresses and then restocking from the free pool. What do you mean by "go back into the market, driving up prices?" If more supply goes into the market, prices tend to go down. If onselling by transfer recipients is restricted for two years, they don't go back into the market, for two years. > I have a huge amount of faith in ARIN's analysts and believe that they > do an exceptionally good job today of making sure that requests that > are blatantly fabricated don't slip through. I do not make the error > (as you seem to have) of assuming that everything is black and white, Huh? It is the advocates of centralized needs assessment that believe everything is black and white. I believe that nothing in economics is black and white; everything is a trade off and a question of relative cost compared to close substitutes. You on the other hand seem to think that there is some fixed, divinely ordained relationship between an organization's network and the amount of addresses it needs. Black and white folks could say that _no one_ "needs" IPv4 addresses any more, because they could implement NATs or switch to IPv6. An economic perspective says, it all depends on what you have to pay to implement those various options. And since my consumption of more v4 addresses stops you from consuming them, there ought to be a price system to use to value those options. > Creating a climate in which the incentive to fib on one's applications > is increased rather than decreased, is a step away from goodness. I'm > not for it. That climate is HERE, my friend. It is caused by the increasing scarcity of v4 addresses. It will continue regardless of the fate of transfer policies. That was my point. However, you and Scott did give me an idea. If you do want to impose restrictions on transferors, then simply require that they cannot transfer _any addresses they received from ARIN_ in the past year/2 years. From sleibrand at internap.com Sun Jun 22 12:23:26 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Sun, 22 Jun 2008 09:23:26 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <152B7CCD-9025-4DC0-94A5-673D681AA5EB@delong.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> <485D8328.6050806@psg.com> <485D9376.5030409@internap.com> <152B7CCD-9025-4DC0-94A5-673D681AA5EB@delong.com> Message-ID: <485E7C7E.8070803@internap.com> Owen DeLong wrote: > > On Jun 21, 2008, at 4:49 PM, Scott Leibrand wrote: > >> In the case of >> 2008-2, the goal is to keep deaggregation pressures the same as they >> would be under a continuation of the current system (if we had more >> addresses to give out). In other words, I believe that the >> extrapolation of current routing table size trend lines that Schiller >> et. al. have presented represents the eventual situation under 2008-2 >> about as well as possible given the inherent uncertainties. > > I don't believe for one second that 2008-2 as it is currently written would > achieve this. I believe it will reduce the speed with which deaggregation > and disaggregation pressures increase, but, in any market scenario, > disaggregation pressures will increase. Some worse than others > and APNICs proposal is certainly worse than 2008-2. Yes, in any exhaustion scenario, deaggregation pressures *on existing space* will increase somewhat: as far as I can tell that's inevitable. However, I'm not convinced that the rate of increase in the routing table will necessarily increase. Currently we are "deaggregating" the free pool into one route per growing multihomed organization per year. If we instead deaggregate deployed space to meet the same demand, and apply restrictions as in 2008-2, I'm not convinced we'd see any more deaggregation than is the inevitable result of more networks joining the Internet (and that's a good thing). Do you have reason to believe that deaggregation pressures will be larger under 2008-2 than under a no-transfers exhaustion scenario, where incumbents with space lease/SWIP it to downstreams needing the space? As Randy has pointed out, most of the deaggregates in the current table are more-specifics of RIR-allocated routes. Under a no-transfer or 2008-2-type policy, I would expect that to remain the case, at least unless/until routing table growth starts to outstrip router capacity growth. -Scott From owen at delong.com Sun Jun 22 12:33:15 2008 From: owen at delong.com (Owen DeLong) Date: Sun, 22 Jun 2008 09:33:15 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <485E7C7E.8070803@internap.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> <485D8328.6050806@psg.com> <485D9376.5030409@internap.com> <152B7CCD-9025-4DC0-94A5-673D681AA5EB@delong.com> <485E7C7E.8070803@internap.com> Message-ID: > Yes, in any exhaustion scenario, deaggregation pressures *on > existing space* will increase somewhat: as far as I can tell that's > inevitable. However, I'm not convinced that the rate of increase in > the routing table will necessarily increase. Currently we are > "deaggregating" the free pool into one route per growing multihomed > organization per year. If we instead deaggregate deployed space to > meet the same demand, and apply restrictions as in 2008-2, I'm not > convinced we'd see any more deaggregation than is the inevitable > result of more networks joining the Internet (and that's a good > thing). > > Do you have reason to believe that deaggregation pressures will be > larger under 2008-2 than under a no-transfers exhaustion scenario, > where incumbents with space lease/SWIP it to downstreams needing the > space? > Yes... I think that the market will lead to a larger number of organizations multihoming in order to qualify for the ability to transfer space in because their ISP is out and they can't get space any other way. > As Randy has pointed out, most of the deaggregates in the current > table are more-specifics of RIR-allocated routes. Under a no- > transfer or 2008-2-type policy, I would expect that to remain the > case, at least unless/until routing table growth starts to outstrip > router capacity growth. > Yes. I don't see that as a bad thing. That form of growth is somewhat manageable and when those more specifics get filtered remotely, little or no damage occurs. This is not so of fractions of address space that no longer have any affiliation with a larger aggregate. Especially in scenarios where someone is still announcing said larger aggregate and may not be carrying the more specific. Owen From jmaimon at chl.com Sun Jun 22 14:07:33 2008 From: jmaimon at chl.com (Joe Maimon) Date: Sun, 22 Jun 2008 14:07:33 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> Message-ID: <485E94E5.20605@chl.com> John Curran wrote: > At 12:28 PM -0700 6/21/08, k claffy wrote: >> if we're so great at stewardship, how did we get so stuck so fast? > The medium-term outlook may even > require reducing IPv4 routing post-transition into to keep everything > running. Long-term, we all know we'll need the EID/LOC split being > explored by the IRTF RRG work. > The IRTF RRG > folks are out there working on this, and this community is waiting > patiently for results. > > /John Color me a skeptic, but talking about id's in a network that somehow dont impact the routing table somewhere, sounds like describing water that isnt wet. Even if it does exist, nobody wants to drink it. And if it does impact the table, its either upstream dependent or upstream independent. If its upstream independent its either end nodes tables only, or its all tables equally. As I see it, hierarchical routing tables and transition to routing schemes other than hop-by-hop routing are required for massive scale upstream independent routing that exceeds affordable capacity for full tables everywhere hop-by-hop routing. Joe From jmaimon at chl.com Sun Jun 22 14:07:00 2008 From: jmaimon at chl.com (Joe Maimon) Date: Sun, 22 Jun 2008 14:07:00 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <87333.1213981852@sa.vix.com> Message-ID: <485E94C4.8050706@chl.com> Owen DeLong wrote: > On Jun 20, 2008, at 10:10 AM, Paul Vixie wrote: > >>>> isn't this inevitable in times of shortage, ... >>> I don't accept your premise that a market is inevitable. > animal to extinction and then the market collapsed. In this case, > we have the option of just watching the extinction occur without > creating a market If there will be a market, it will happen with or without the registries. They will get their address space one way or another, and they will demand it be routed. The ones paying the paychecks will demand they get routed. Those who refuse to route it will cease getting paychecks. Effectively at that point ARIN is increasingly irrelevant. We dont want this scenario. This is already happening, according to anecdotal evidence. The only way this scenario doesnt play out this way is if the PHB's say, "sorry, according to my engineers, no ipv4, only ipv6", and the customers say "Great! I didnt actually want the ipv4 anyways". Depending on who you ask, thats either possible, impossible, unlikely, likely, unrealistic, naive, idealistic, overly simplistic or something or another. We dont actually know how fast things will transition to the point ipv4 has no value and ipv6 has all value. Thats the only way there wont be a market in ipv4. If it has no market value. So if there will be a market, it should be one where we can make it attractive for those we want to participate, to participate. In exchange we can gain by imposing a cost of participation inline with our needs. The balance that needs to be struck is between cost of participation and the attractiveness of participation. And if there wont be a market, its unlikely that ARIN could create one. So coming to grips with a potential increase of value IPv4 blocks will have post-runout and developing an approach for it are all about remaining relevant, so as to attempt to ensure our needs are met. A relevant ARIN is in all our best interests at this point. Joe From owen at delong.com Sun Jun 22 14:19:34 2008 From: owen at delong.com (Owen DeLong) Date: Sun, 22 Jun 2008 11:19:34 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <485E94C4.8050706@chl.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D955@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D995@SUEXCL-02.ad.syr.edu> <485AD985.70300@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <87333.1213981852@sa.vix.com> <485E94C4.8050706@chl.com> Message-ID: <8F657A24-AD5B-4623-98FE-8461CDB69040@delong.com> On Jun 22, 2008, at 11:07 AM, Joe Maimon wrote: > > > Owen DeLong wrote: >> On Jun 20, 2008, at 10:10 AM, Paul Vixie wrote: >>>>> isn't this inevitable in times of shortage, ... >>>> I don't accept your premise that a market is inevitable. > > > >> animal to extinction and then the market collapsed. In this case, >> we have the option of just watching the extinction occur without >> creating a market > > If there will be a market, it will happen with or without the > registries. > Probably, but, without the registries, I expect the market to be significantly smaller and less widely accepted. I also expect it to be less transparent and riskier to the market players. > They will get their address space one way or another, and they will > demand it be routed. The ones paying the paychecks will demand they > get routed. Those who refuse to route it will cease getting paychecks. > I don't see how this will happen. I see lots of people insisting on this position, but, the reality is that you may redistribute that small unused portion of the space which exists today, but, once that's gone, I don't see the continuing market scenario being all that effective or likely, even with the registries. Also, while I think they will get routed by their direct upstreams, I think you'll see increasing fragmentation of routing as people not getting paid to route a particular prefix begin to filter the smaller blocks they aren't getting paid for out of necessity. Eventually, that will essentially eliminate the smaller blocks from being at all useful. I don't see that as being a win for the community. > Effectively at that point ARIN is increasingly irrelevant. We dont > want this scenario. > I disagree. I think that is the point where ARIN preserving some level of addressing integrity by not allowing random transfers will be the only path to possible recovery of the routing domain for IPv4, and, even then, I am not so sure it will work. > This is already happening, according to anecdotal evidence. > In a very limited scope and with tremendous risk to the players involved. Armed robbery is already happening in most cities in America. That does not mean I want the government to start selling armed robbery permits. > The only way this scenario doesnt play out this way is if the PHB's > say, "sorry, according to my engineers, no ipv4, only ipv6", and the > customers say "Great! I didnt actually want the ipv4 anyways". > I think the reality will be somewhere between those two extremes and will slowly work its way closer to the "no ipv4, only ipv6" extreme as you described it. > Depending on who you ask, thats either possible, impossible, > unlikely, likely, unrealistic, naive, idealistic, overly simplistic > or something or another. We dont actually know how fast things will > transition to the point ipv4 has no value and ipv6 has all value. > It's overly simplistic in my opinion. There's a lot of grey between those versions of black and white and the reality will be in many different shades of gray for many different subsets of ISPs. > Thats the only way there wont be a market in ipv4. If it has no > market value. > I'm not saying we won't have a market. I'm saying that in my view of things as they have played out so far, legitimizing the market does not provide much benefit and definitely increases risk. > So if there will be a market, it should be one where we can make it > attractive for those we want to participate, to participate. > > In exchange we can gain by imposing a cost of participation inline > with our needs. > The balance that needs to be struck is between cost of participation > and the attractiveness of participation. > So, by that logic, since there will be armed robbery, the government should simply accept that and sell armed robbery permits to benefit from the revenue that is possible and do so on a basis that allows us to select more desirable armed robbers? > > And if there wont be a market, its unlikely that ARIN could create > one. > There will be a market. The true question is whether legitimizing and expanding it is a good idea. From everything I have seen, legitimizing and expanding the market carries a lot of risk both to IPv4 and to IPv6 future policies with very little reward potential. > So coming to grips with a potential increase of value IPv4 blocks > will have post-runout and developing an approach for it are all > about remaining relevant, so as to attempt to ensure our needs are > met. > I think ARIN's best way to remain relevant is to continue as we have to be good stewards of the existing IP free-pools and IP policy in general. In the future, that's going to be IPv6. For now, there is a dwindling role in IPv4. Extending that role by legitimizing a market and expanding it seems to me to be a very short-term extension and a very limited potential benefit with a whole lot of potential problem areas. > A relevant ARIN is in all our best interests at this point. > Sure. I don't think that ARIN will become irrelevant just because there is a market in IPv4 addresses that ARIN is not involved in. I think that IPv6 will become increasingly relevant and I don't see a black market in IPv6 replacing ARIN. I also don't see people developing an alternate ASN registry as being a particularly likely scenario. Owen From jcurran at istaff.org Sun Jun 22 14:28:59 2008 From: jcurran at istaff.org (John Curran) Date: Sun, 22 Jun 2008 14:28:59 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <485E94E5.20605@chl.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> <485E94E5.20605@chl.com> Message-ID: (context is IRTF RRG work for locator/eid based routing) At 2:07 PM -0400 6/22/08, Joe Maimon wrote: >... >As I see it, hierarchical routing tables and transition to routing >schemes other than hop-by-hop routing ... Exactly: "other than hop-by-hop routing" If you can reach any point via a topologically derived locator (loc) and can always translate a unique, non-topologically assigned endpoint identifier (eid) into its current list of locators, then the you're done. Topologically-derived locators don't inherently require additional routing information, except optionally for purposes such as route diversity, traffic engineering, etc. The problem is that the mapping of EID to its locators is a wide open research problem, with several alternatives being explored but no definite answers. To quote Randy Bush: ' watch out, on the third step there is a sign "magic will happen here". ' Actually working on this problem is very important long term, since the current model which combines semantics of both EID's and locators doesn't scale long-term without a strictly hierarchical PA allocation model which is not really customer friendly. /John From sleibrand at internap.com Sun Jun 22 19:04:14 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Sun, 22 Jun 2008 16:04:14 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> <485D8328.6050806@psg.com> <485D9376.5030409@internap.com> <152B7CCD-9025-4DC0-94A5-673D681AA5EB@delong.com> <485E7C7E.8070803@internap.com> Message-ID: <485EDA6E.8020908@internap.com> Owen DeLong wrote: >> Do you have reason to believe that deaggregation pressures will be >> larger under 2008-2 than under a no-transfers exhaustion scenario, >> where incumbents with space lease/SWIP it to downstreams needing the >> space? >> > Yes... I think that the market will lead to a larger number of > organizations > multihoming in order to qualify for the ability to transfer space in > because > their ISP is out and they can't get space any other way. What about the case where ISPs are the ones that acquire the address space via transfer? Do you believe that something about a transfer market will change current practice? Today, large holders (ISPs) get most of the address space from ARIN, and reassign it to their downstreams. This has several benefits, most of them related to economies of scale (fewer interactions with ARIN, staff who get more knowledgeable in IP issues since they deal with it all the time, etc.). In a post-exhaustion transfer market, it would seem that all those advantages would remain, and in addition large holders would be in a better position to acquire space on the transfer market, since they would be more knowledgeable about price trends, etc. So I would think that the only real change to your average small organization would be that after exhaustion some ISPs will begin charging slightly more for Internet service to folks who need a large number of public IPs. >> As Randy has pointed out, most of the deaggregates in the current >> table are more-specifics of RIR-allocated routes. Under a no-transfer >> or 2008-2-type policy, I would expect that to remain the case, at >> least unless/until routing table growth starts to outstrip router >> capacity growth. >> > Yes. I don't see that as a bad thing. That form of growth is somewhat > manageable and when those more specifics get filtered remotely, > little or no damage occurs. This is not so of fractions of address > space that no longer have any affiliation with a larger aggregate. > Especially in scenarios where someone is still announcing said > larger aggregate and may not be carrying the more specific. Agreed. -Scott From owen at delong.com Sun Jun 22 19:08:56 2008 From: owen at delong.com (Owen DeLong) Date: Sun, 22 Jun 2008 16:08:56 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <485EDA6E.8020908@internap.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> <485D8328.6050806@psg.com> <485D9376.5030409@internap.com> <152B7CCD-9025-4DC0-94A5-673D681AA5EB@delong.com> <485E7C7E.8070803@internap.com> <485EDA6E.8020908@internap.com> Message-ID: <1A4DC4C3-3058-45EC-8C37-DCB294E9B030@delong.com> On Jun 22, 2008, at 4:04 PM, Scott Leibrand wrote: > Owen DeLong wrote: > >>> Do you have reason to believe that deaggregation pressures will be >>> larger under 2008-2 than under a no-transfers exhaustion scenario, >>> where incumbents with space lease/SWIP it to downstreams needing >>> the space? >>> >> Yes... I think that the market will lead to a larger number of >> organizations >> multihoming in order to qualify for the ability to transfer space >> in because >> their ISP is out and they can't get space any other way. > > What about the case where ISPs are the ones that acquire the address > space via transfer? Do you believe that something about a transfer > market will change current practice? > I do not believe a transfer market will generate large enough blocks to satisfy the demands of the large(r) ISPs. Therefore, those ISPs will begin to instruct their customers on how to obtain their own space by "multihoming" and then purchasing from the market. I don't think ISPs will be the majority of recipients in the market soon after the market is created (if we do this). > Today, large holders (ISPs) get most of the address space from ARIN, > and reassign it to their downstreams. This has several benefits, > most of them related to economies of scale (fewer interactions with > ARIN, staff who get more knowledgeable in IP issues since they deal > with it all the time, etc.). In a post-exhaustion transfer market, > it would seem that all those advantages would remain, and in > addition large holders would be in a better position to acquire > space on the transfer market, since they would be more knowledgeable > about price trends, etc. So I would think that the only real change > to your average small organization would be that after exhaustion > some ISPs will begin charging slightly more for Internet service to > folks who need a large number of public IPs. > Except that in a post-exhaustion transfer market wit ha 2 year timeframe between successive acquisitions, ISPs won't be able to get enough from the market to satisfy the demands of their customers. As such, I believe that ISPs will pressure their customers who want IPv4 address space to bring their own from the market in smaller chunks. >>> As Randy has pointed out, most of the deaggregates in the current >>> table are more-specifics of RIR-allocated routes. Under a no- >>> transfer or 2008-2-type policy, I would expect that to remain the >>> case, at least unless/until routing table growth starts to >>> outstrip router capacity growth. >>> >> Yes. I don't see that as a bad thing. That form of growth is >> somewhat >> manageable and when those more specifics get filtered remotely, >> little or no damage occurs. This is not so of fractions of address >> space that no longer have any affiliation with a larger aggregate. >> Especially in scenarios where someone is still announcing said >> larger aggregate and may not be carrying the more specific. > > Agreed. > > -Scott Preserving the above scenario in a market seems impossible to me. How do you see this happening in light of my comments above? Owen From randy at psg.com Sun Jun 22 19:16:46 2008 From: randy at psg.com (Randy Bush) Date: Mon, 23 Jun 2008 08:16:46 +0900 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901E0D996@SUEXCL-02.ad.syr.edu> <485BCF36.90101@sprunk.org> <63435F31-B86E-4759-A18B-E005A8DD3D97@delong.com> <86372.1213980574@sa.vix.com> <20080620173853.GA78555@ussenterprise.ufp.org> <5BECE490-BF9B-4E65-B337-99232A4BF703@pch.net> <20080621042744.GA16756@vacation.karoshi.com.> <485C84E4.7040606@internap.com> <30546.1214067169@sa.vix.com> <20080621192820.GA68347@rommie.caida.org> <485E94E5.20605@chl.com> Message-ID: <485EDD5E.6030201@psg.com> John Curran wrote: > To quote Randy Bush: > > ' watch out, on the third step there > is a sign "magic will happen here". ' it was i quoting lucy lynch expecting usable results from the rrg is a fantasy. they mean well, but have been bashing their heads against this for decades. but, if you want to quote me, from a recent slide deck o We have been algorithmically lazy o We never engaged the maths folk o Routing is considered uninteresting in today's CS programs o We have more economists and lawyers in the game than mathematicians randy From michael.dillon at bt.com Mon Jun 23 05:18:51 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 23 Jun 2008 10:18:51 +0100 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: <86372.1213980574@sa.vix.com> Message-ID: > isn't this inevitable in times of shortage, regardless of the > shade (regulated or unregulated) of the market that > inevitably occurs when humans face shortages? if it is, then > our choice is not whether a market appears, but rather, > whether that inevitable market is regulated or unregulated. The IP address trading market has already appeared. It is already regulated by the fact that it is an illegitimate black market and that has kept the level of activity down to a murmur. What makes you think that the proposals for ARIN to tinker directly with this market will improve it in any way? Yes, humans do certain things when shortages arise, but only a fool would starve to death when there are an abundance of weeds, tree leaves and grass to eat. In the same way, only a fool would let their network starve from a lack of IPv4 addresses when there is an abundance of IPv6 addresses free for the taking. All the talk of address scarcity is about a mirage, something that has been engineered by the IP networking community. There is no real shortage of IPv4 addresses. There is no real scarcity and never will be. Every network operator has a choice to start using IPv6 addresses, or to pretend that they do not exist and play the role of someone suffering from scarcity. The fundamental problem that we are wrestling with is one of human psychology. It is all about fear of the unknown. Too many people in the IP networking industry are so afraid of the unknown IPv6 future that they are willing to create a scarcity situation and then suffer through that scarcity period. In the end, there is no need for scarcity and no need for suffering. In the end, the suffering will stop when networks start using IPv6 in earnest. But why wait 'til spring? Do it now! Let's all get beavering away and shift our lumbering networks into the future. --Michael Dillon From michael.dillon at bt.com Mon Jun 23 06:14:25 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 23 Jun 2008 11:14:25 +0100 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: Message-ID: > The problem is that the mapping of EID to its locators is a > wide open research problem, with several alternatives being > explored but no definite answers. Sorry, but you're wrong on this point. This problem was solved years ago. The solution is called MPLS. Frankly. I don't understand why the IETF community is trying to reinvent MPLS after all these years. Maybe it's just a case of not-invented-here. Of course someone will point out that MPLS is not usable end to end on a multi-AS path which is sort of true. However work is being done on MPLS interworking, and since it is a layer 2 kind of protocol, it is probably not such a good idea to treat it differently from other layer 2 protocols such as FR, ATM, Ethernet, all of which are being used by network operators today. --Michael Dillon From jcurran at istaff.org Mon Jun 23 06:57:07 2008 From: jcurran at istaff.org (John Curran) Date: Mon, 23 Jun 2008 06:57:07 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: References: Message-ID: At 11:14 AM +0100 6/23/08, wrote: > > The problem is that the mapping of EID to its locators is a >> wide open research problem, with several alternatives being >> explored but no definite answers. > >Sorry, but you're wrong on this point. This problem was solved years >ago. The solution is called MPLS. On a single network, or small set of loosely coordinated networks, sure. The problem statement above is for a mechanism which scales to Internet- wide scope (i.e. global dynamic LSP tunnels without any prior one-on-one coordination), whereas work in the IETF MPLS wg is presently addressing scaling issues just with within a single network of multiple IGP areas (i.e. ). MPLS is an answer to some questions, but using it as global EID layer for the Internet would require addressing some very tricky questions about large-scale, real-time dynamic LSP establishment. Whether such is more or less difficult to accomplish than the current RRG work is a matter of perspective; feel free to write it up if you think it is a viable solution. /John From ppml at rs.seastrom.com Mon Jun 23 08:56:52 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Mon, 23 Jun 2008 08:56:52 -0400 Subject: [arin-ppml] Q2: on Address Transfers - Overkill on the freezeperiod? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0DA07@SUEXCL-02.ad.syr.edu> (Milton L. Mueller's message of "Sun, 22 Jun 2008 10:42:17 -0400") References: <7663C7E01D8E094989CA62F0B0D21CD90188411E@SUEXCL-02.ad.syr.edu> <20080620163443.GB74707@ussenterprise.ufp.org> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E0@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0D9E3@SUEXCL-02.ad.syr.edu> <86hcbnc7vu.fsf@seastrom.com> <7663C7E01D8E094989CA62F0B0D21CD901E0D9F6@SUEXCL-02.ad.syr.edu> <86r6aqiyvk.fsf@seastrom.com> <7663C7E01D8E094989CA62F0B0D21CD901E0DA07@SUEXCL-02.ad.syr.edu> Message-ID: <863an42tt7.fsf@seastrom.com> "Milton L Mueller" writes: >> -----Original Message----- >> From: Robert E. Seastrom [mailto:rs at seastrom.com] On Behalf Of Robert > E. >> Complete disagreement here. Restrictions on the transferor and >> transferee are different sides of the same coin, but restrictions on >> the transferor are closer to the source and more likely to catch >> people's attention. > > Closer to the source of what? I quite literally have no idea what you > mean. Closer to the source of the goods that are being shlepped around, in this case blocks of IP addresses. They come from IANA to ARIN to an initial allocation, and thence under the post depletion scenario, to be transfered to another entity under ARIN approval. > From what I've seen of your argument, you still aren't refuting my > contention that you can catch speculation more effectively by > restricting post-transfer sales than by slapping categorical > restrictions on people who can transfer. I haven't seen any substantiation of your claim that downstream regulation alone is more effective than a combination of downstream and upstream regulation as called for in 2008-2. Pardon me for rejecting it out of hand under the circumstances. Note that I am advocating *both* conditions on the transferor *and* the transferee. Please present your less-is-more argument. >> > As Scott noted, the only thing you want to do with the source is > make >> > sure that they don't sell their assignment and then come back to > ARIN >> > for more for free. >> >> Or go back into the market, driving up the prices needlessly. > > This comment makes no sense to me, and seems to be unrelated to the > point about someone selling addresses and then restocking from the free > pool. > > What do you mean by "go back into the market, driving up prices?" If > more supply goes into the market, prices tend to go down. If onselling > by transfer recipients is restricted for two years, they don't go back > into the market, for two years. We aren't proposing that the transfer market be open until we've run out anyway, so don't jump to the conclusion that there will be any free pool to replentish from. Sorry for the imprecise language by the way - "go back into the market" should have been "go back to the market" or "go back into the marketplace"; it is referring to the behavior of the customer, not the destiny of the netblock. Should have been clear from the context that I wasn't referring to netblock churn, rather the entities involved, but thanks for the opportunity to clarify that. >> I have a huge amount of faith in ARIN's analysts and believe that they >> do an exceptionally good job today of making sure that requests that >> are blatantly fabricated don't slip through. I do not make the error >> (as you seem to have) of assuming that everything is black and white, > > Huh? It is the advocates of centralized needs assessment that believe > everything is black and white. I believe that nothing in economics is > black and white; everything is a trade off and a question of relative > cost compared to close substitutes. You on the other hand seem to think > that there is some fixed, divinely ordained relationship between an > organization's network and the amount of addresses it needs. I would say there is absolutely a relationship between an organization's network design and purpose, and the amount of address space it needs, just as there is a relationship in rough terms between the span/purpose/traffic on a bridge and the amount of steel it needs. Determining what resources are needed to meet desired objectives and criteria (as well as the cost tradeoffs involved) is at the core of any engineering discipline. There are no "close substitutes" for IPv4 space. IPv6 doesn't even come close. When (if) we reach a tipping point where there is a whole lot of widespread IPv6 deployment and v6 "just works" to the extent that v4 does today (including rollout of transitional technology), *then* that argument could be made. > Black and white folks could say that _no one_ "needs" IPv4 addresses any > more, because they could implement NATs or switch to IPv6. An economic > perspective says, it all depends on what you have to pay to implement > those various options. And since my consumption of more v4 addresses > stops you from consuming them, there ought to be a price system to use > to value those options. There is nothing counter to this in 2008-2; indeed, the mere existence of 2008-2 would seem to suggest that the authors and contributors, myself among them, "get it" on these points. >> Creating a climate in which the incentive to fib on one's applications >> is increased rather than decreased, is a step away from goodness. I'm >> not for it. > > That climate is HERE, my friend. It is caused by the increasing scarcity > of v4 addresses. It will continue regardless of the fate of transfer > policies. That was my point. There has always been an incentive to fib to ARIN (tempered by the refresh rules - you don't want to get so much space that it lasts you long enough that you're back into small allocation land) and it hasn't changed that much over the past 10 years in absolute terms. When exhaustion is looming larger on the horizon relative to the average lifetime of the management team at an ARIN member, *then* you're going to see a big uptick. That's not what I was addressing though, when I said "creating a climate". The scalar that represents the current-level-of-BS-incentive is irrelevant moving forward - what matters is the vector that represents ramp-up of BS-incentive that a policy creates or reinforces. > However, you and Scott did give me an idea. If you do want to impose > restrictions on transferors, then simply require that they cannot > transfer _any addresses they received from ARIN_ in the past year/2 > years. Which means you can get a bunch of addresses for the ostensible purpose of expansion or perhaps aggregation, move into those, and put the old ones on the market? Sorry, no deal. If I'm not mistaken, we hashed that one over in Reston. ---Rob From paul at vix.com Mon Jun 23 10:00:45 2008 From: paul at vix.com (Paul Vixie) Date: Mon, 23 Jun 2008 14:00:45 +0000 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: Your message of "Mon, 23 Jun 2008 10:18:51 +0100." References: Message-ID: <12852.1214229645@sa.vix.com> > The IP address trading market has already appeared. It is already regulated > by the fact that it is an illegitimate black market and that has kept the > level of activity down to a murmur. > > What makes you think that the proposals for ARIN to tinker directly with > this market will improve it in any way? i'm thinking that the murmur could turn into a riot at RIR runout. the historical parallel is "prohibition", where laws against selling a certain kind of commodity strengthened and amplified an existing black market. i recognize the imperfection of this comparison, since the scarcity was caused in that case by the laws themselves, whereas the coming ipv4 shortage is of natural causes. > Yes, humans do certain things when shortages arise, but only a fool would > starve to death when there are an abundance of weeds, tree leaves and grass > to eat. In the same way, only a fool would let their network starve from a > lack of IPv4 addresses when there is an abundance of IPv6 addresses free for > the taking. that analogy fails since the first companies who go ipv6-only will all die of starvation since "the internet" from their customers' point of view will be mostly empty. the first companies to go dual-stack are doing OK, we're getting some small first-mover advantage by generating skills and tools, but there is no first-mover revenue advantage in dual-stack. the rational individual choice for most companies has been some mixture of (wait-and-see and/or hoard). to the extent that there's revenue in dual-stack, it'll all be there waiting for the stragglers. > All the talk of address scarcity is about a mirage, something that has been > engineered by the IP networking community. There is no real shortage of IPv4 > addresses. There is no real scarcity and never will be. Every network > operator has a choice to start using IPv6 addresses, or to pretend that they > do not exist and play the role of someone suffering from scarcity. michael, if my company was ipv6-only, then we wouldn't be having this conversation. i think onlookers know this and know that ipv6 won't help them in the current fiscal year, but that dual-stack would cost them in the current fiscal year. $ dig +short bt.com in mx 10 smtp62.intersmtp.com. 10 smtp63.intersmtp.com. 10 smtp64.intersmtp.com. 10 smtpe1.intersmtp.com. 10 smtp61.intersmtp.com. $ dig +short smtp62.intersmtp.com. in aaaa $ dig +short smtp63.intersmtp.com. in aaaa $ dig +short smtp64.intersmtp.com. in aaaa $ dig +short smtpei.intersmtp.com. in aaaa $ dig +short smtp6l.intersmtp.com. in aaaa $ > The fundamental problem that we are wrestling with is one of human > psychology. It is all about fear of the unknown. Too many people in the IP > networking industry are so afraid of the unknown IPv6 future that they are > willing to create a scarcity situation and then suffer through that scarcity > period. the rational choice for many is: waiting until there are other ipv6 endpoints to connect to before adopting dual-stack. this isn't psychology, but rather "just business" as randy bush sometimes says. > In the end, there is no need for scarcity and no need for > suffering. In the end, the suffering will stop when networks start using > IPv6 in earnest. But why wait 'til spring? Do it now! Let's all get > beavering away and shift our lumbering networks into the future. isc.org's network has been dual-stack for years. what's bt.com's plan? From michael.dillon at bt.com Mon Jun 23 10:42:27 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 23 Jun 2008 15:42:27 +0100 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: <12852.1214229645@sa.vix.com> Message-ID: > that analogy fails since the first companies who go ipv6-only > will all die of starvation since "the internet" from their > customers' point of view will be mostly empty. Nobody will ever go IPv6-only for at least 10 years, and even then those will be boutique network operators who provide some special service rather than general Internet access or IP-VPNs. In the time frame where IPv4 addresses will run out, we are only talking about companies who deploy IPv6 services in addition to their existing services. Even then, this may be an IPv6-VPN service that does not require Internet access at all, but it still will ease the pressure on IPv4 address consumption. And then there is NAT-PT and friends... > the first > companies to go dual-stack are doing OK, we're getting some > small first-mover advantage by generating skills and tools, > but there is no first-mover revenue advantage in dual-stack. This also does not protect you from IPv4 exhaustion since dual stack implies that you give everything both IPv4 and IPv6 addresses. > the rational individual choice for most companies has been > some mixture of (wait-and-see and/or hoard). I disagree that this is the rational choice. My view is that this is the fool's choice. The rational move is to fully deploy IPv6 internally in a lab environment, roll all the support software changes required into ongoing software upgrade projects, and then move this into a small-scale production environment with "friendly" customers, perhaps from the federal government/DOD sphere. In fact, the governments (Federal, State and local) should be lobbied to spread their IPv6 POs around the networking industry, not just give all the IPv6 business to one or two favored suppliers. The point is that the rational choice is to spend a small amount to get ready, and steer yourself into a position where you can at least join the race when the starting pistol is fired. You don't have to be an Olympic athlete to win such a race, you just have to be able to run faster than some of the competition. No doubt people will run into scaling issues, but if you have people experienced with running IPv6 in a test lab environment, you have a chance of solving the scaling issues. > $ dig +short bt.com in mx > 10 smtp62.intersmtp.com. > $ dig +short smtp62.intersmtp.com. in aaaa You DNS gurus do love to post the output of "dig" but this is meaningless to me. I think it might be saying that we outsource our corporate email service but I'm not sure. In any case it says nothing about what we are doing with IPv6. Also, we have a global MPLS network on which we sell VPNs, and do some variuous pseudo-wire stuff. It's pretty easy for companies with such a network, and there are many of them, to do IPv6 VPNs for customers who don't expect Internet access to the VPN. MPLS is basically an automated tunnel overlay system, so the pure-IP equivalent of this is the operator who builds an IPv6 overlay network with GRE tunnels. I think that this is the better way to ease into IPv6, and then add the Internet access gateways later on. > the rational choice for many is: waiting until there are > other ipv6 endpoints to connect to before adopting > dual-stack. this isn't psychology, but rather "just > business" as randy bush sometimes says. Sounds like magnetic monopoles to me. Why not find an organization with several endpoints in different locations and connect them all up? In any case, companies with blinders on will suffer, one way or another. > isc.org's network has been dual-stack for years. what's > bt.com's plan? BT's plan is as complex as the dozen or so IP networks that we operate. A lot of network operators are in the same boat, still running 3 or 5 or 10 IP networks that result from various M&A activity and/or attempts to integrate some networks into a merged network. Fact is that there are customers on these networks so we like to go slow and make sure the service keeps running. That is why you hear so little about IPv6 from the bigger networks, because they are easing into it in a way that does not disrupt any existing customers. --Michael Dillon From paul at vix.com Mon Jun 23 12:53:11 2008 From: paul at vix.com (Paul Vixie) Date: Mon, 23 Jun 2008 16:53:11 +0000 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: Your message of "Mon, 23 Jun 2008 15:42:27 +0100." References: Message-ID: <18572.1214239991@sa.vix.com> > In the time frame where IPv4 addresses will run out, we are only talking > about companies who deploy IPv6 services in addition to their existing > services. if what they need to do is create new endpoints that need global reachability to existing endpoints, then deploying ipv6 is all cost no benefit. the cases where someone only needs limited reachability to themselves and their partners is generally being handled with IPv4 RFC1918 space today, and while ipv6 makes that better, the betterness in that case does not relieve any pressure on the non-RFC1918 ipv4 pool. > > the rational individual choice for most companies has been > > some mixture of (wait-and-see and/or hoard). > > I disagree that this is the rational choice. My view is that this is the > fool's choice. The rational move is to fully deploy IPv6 internally in a lab > environment, roll all the support software changes required into ongoing > software upgrade projects, and then move this into a small-scale production > environment with "friendly" customers, ... there are not enough ipv6-friendly customers, simply because there are not already enough ipv6-reachable endpoints. pulling oneself up by one's own bootstraps may sound wonderful but it doesn't actually work. in the long run, incorporating ipv6 into an organization's technology DNA is the rational choice, but we're not in the long run yet, and there are more costs and disadvantages than there are benefits and advantages to being a first mover, unless you're helping create the basic IPv6 technology (as in ISC's case). > You DNS gurus do love to post the output of "dig" but this is meaningless to > me. I think it might be saying that we outsource our corporate email service > but I'm not sure. it means if i only had ipv6, i could not send you e-mail today. thanks for calling me a dns guru, you made my day, even if other employees of ISC have to clean their keyboards after explosively laughing coffee out their noses. > > isc.org's network has been dual-stack for years. what's bt.com's plan? > > BT's plan is as complex as the dozen or so IP networks that we operate. A > lot of network operators are in the same boat, still running 3 or 5 or 10 IP > networks that result from various M&A activity and/or attempts to integrate > some networks into a merged network. so, it's a hairball? > Fact is that there are customers on these networks so we like to go slow and > make sure the service keeps running. That is why you hear so little about > IPv6 from the bigger networks, because they are easing into it in a way that > does not disrupt any existing customers. > > --Michael Dillon i think we all like our customers. but bt.com could show some solidarity for the long-term rational choices we'd like folks to make, if you'd make all of your corporate I.T. resources ipv6-reachable, and make all of your corporate I.T. desktops ipv6-capable. that's in addition to the technology DNA infusion you're describing, so that your company will be well positioned once everybody else has also added ipv6 to their products and services. paul From tedm at ipinc.net Mon Jun 23 15:46:11 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 23 Jun 2008 12:46:11 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the trigger date? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0D9F2@SUEXCL-02.ad.syr.edu> Message-ID: <70B67C4ACBA64A92AE542AF5DFBE7591@tedsdesk> > -----Original Message----- > From: Milton L Mueller [mailto:mueller at syr.edu] > Sent: Saturday, June 21, 2008 2:28 AM > To: Ted Mittelstaedt; PPML ppml > Subject: RE: [arin-ppml] Q1 - ARIN address transfer policy: > why the trigger date? > > > I don't think this kind of ranting is useful. > Naturally you don't. Fortunately, it doesen't matter what you think. Your goal in this thread was never to gain understanding from the beginning, it was to influence people. You put up your arguments in favor of an IP market. I put up the counters of why this is a bad idea. The list readership can read both and make up their own mind. Basically your response here is that you have no logical arguments to rebut the arguments in opposition, so your going to fall back on just labeling them as emotional "ranting" and hope that the rest of the list readership falls for it. Good luck. Ted From tedm at ipinc.net Mon Jun 23 16:13:37 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 23 Jun 2008 13:13:37 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: whythetriggerdate? In-Reply-To: <86lk0zasc0.fsf@seastrom.com> Message-ID: <2E22B483D3524EBC90ECECB29797BBA7@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Robert E. Seastrom > Sent: Saturday, June 21, 2008 5:25 AM > To: Owen DeLong > Cc: ARIN PPML > Subject: Re: [arin-ppml] Q1 - ARIN address transfer policy: > whythetriggerdate? > > And for a counterexample, I started as quite anti-market, > hoping that runout with absolutely no contingency plan for > transfer of addresses would speed v6 adoption. I'm still > concerned that creating a market will dull perceptions about > the finality of run-out; we emphatically do not want to > promulgate the belief that it will be business mostly as > usual except with higher prices. > > On the other hand, the market exists right now, it's just > unregulated and shadowy because it is prohibited by policy. > Acknowledging the existence of the market and putting a > modicum of regulation on it is certainly in the interest of > the buyers, and likely in the interest of the sellers as > well, since fair pricing can be established on more than an > anecdotal basis. > This was the same argument that was used by 29 states in the early '70s in the US to lower the drinking age to 18. However, the regulation did not result in any safer or better collegate drinking, and drunk driving accidents continued to rise, as a result those states ended up raising the drinking age back to 21 by 1988. (the National Minimum Drinking age of 1984 law also helped, of course) According to MADD the nationwide proportion of 16-20 year old drivers involved in fatal crashes dropped 33% following 1988, when the last state raised it's age. It is a given that making something illegal isn't going to stop it from happening. BUT, the idea that making IPv4 private-party to private-party address transfers sanctioned will not affect the IPv6 uptake rate is simply preposterous. For the large orgs, there's not going to be enough IPv4 for sale to meet their needs, so this discussion isn't even on their radar. But it does matter to the smaller orgs. If you make these transfers sanctioned, there WILL be some smaller orgs who put off IPv6 migration plans, and purchase more IPv4. Robert, you need to forget about this bankrupt "they are going to do it so we might as well regulate them" argument and decide if stretching out IPv4 past IPv4 runout is a good thing for the Internet or not. If you decide it is a good thing, then be in favor of this proposal for that reason - that's a respectable position to take. But, if you believe that it is not a good thing, then for heaven's sake, be a man and stand on your principles. Ted From paul at vix.com Mon Jun 23 16:56:56 2008 From: paul at vix.com (Paul Vixie) Date: Mon, 23 Jun 2008 20:56:56 +0000 Subject: [arin-ppml] Q1 - ARIN address transfer policy: whythetriggerdate? In-Reply-To: Your message of "Mon, 23 Jun 2008 13:13:37 MST." <2E22B483D3524EBC90ECECB29797BBA7@tedsdesk> References: <2E22B483D3524EBC90ECECB29797BBA7@tedsdesk> Message-ID: <26271.1214254616@sa.vix.com> > From: "Ted Mittelstaedt" > ... > It is a given that making something illegal isn't going to stop it from > happening. BUT, the idea that making IPv4 private-party to private-party > address transfers sanctioned will not affect the IPv6 uptake rate is simply > preposterous. > > For the large orgs, there's not going to be enough IPv4 for sale to meet > their needs, so this discussion isn't even on their radar. But it does > matter to the smaller orgs. If you make these transfers sanctioned, there > WILL be some smaller orgs who put off IPv6 migration plans, and purchase > more IPv4. it seems to me that until the rest of the world has upgraded, then any given org (large or small) who wants to continue growing the externally reachable parts of their network (like, for IP customers) will have to have a supply of new ipv4, even if they're deploying dual-stack at such moments. this has two corollaries: 1. the time to dual-stack is $NOW, and arin should investigate new policies that require proof of dual-stack intent and action $NOW for ipv4 allocations starting $NOW; and, 2. the problem (as always) is other people's networks, and all arguments of the form "ipv4's lifetime should not be extended" boil down to "it is bad for $ME if $OTHER_PEOPLE aren't forced to run dual-stack and get ipv6 running." for the record, the positions i'm representing on PPML are my own and do not nec'ily reflect those of ARIN's Board of Trustees, of which i am a member. paul vixie From Lee at dilkie.com Mon Jun 23 17:42:40 2008 From: Lee at dilkie.com (Lee Dilkie) Date: Mon, 23 Jun 2008 17:42:40 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: whythetriggerdate? In-Reply-To: <26271.1214254616@sa.vix.com> References: <2E22B483D3524EBC90ECECB29797BBA7@tedsdesk> <26271.1214254616@sa.vix.com> Message-ID: <486018D0.9020607@dilkie.com> Finally... something that makes sense... Paul Vixie wrote: > 1. the time to dual-stack is $NOW, and arin should investigate new policies > that require proof of dual-stack intent and action $NOW for ipv4 allocations > starting $NOW; and, > > 2. the problem (as always) is other people's networks, and all arguments of > the form "ipv4's lifetime should not be extended" boil down to "it is bad for > $ME if $OTHER_PEOPLE aren't forced to run dual-stack and get ipv6 running." > > > I think we all agree that deploying IPv6/dual-stack is a cost with no short term benefit. And it's natural for all parties to want everyone else to bear the cost, themselves excluded. Like government mandated pollution and mileage targets on automobiles, sometimes only an edict will suffice to move all parties to the same level playing field at the same time. So. What do we propose? That all future IPv4 blocks be deployed by customers/ISPs dual-stack, ARIN grants a matching IPv6 block with each IPv4 grant and insists (checks up) that it be made available to end customers (in an ISP's case?). Until you deploy dual stack, you won't get any more blocks from ARIN? This is essentially what the US government is doing to vendors, wrt IPv6. I think it's not a bad argument that ARIN should be just as insistent in "encouraging" IPv6 rollout. -lee From tedm at ipinc.net Mon Jun 23 17:43:22 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 23 Jun 2008 14:43:22 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy: whythetriggerdate? In-Reply-To: <26271.1214254616@sa.vix.com> Message-ID: <1C16F52C3E524E75947FB0212ECC8D92@tedsdesk> > -----Original Message----- > From: vixie at vix.com [mailto:vixie at vix.com] On Behalf Of Paul Vixie > Sent: Monday, June 23, 2008 1:57 PM > To: Ted Mittelstaedt > Cc: 'ARIN PPML' > Subject: Re: [arin-ppml] Q1 - ARIN address transfer policy: > whythetriggerdate? > > > > From: "Ted Mittelstaedt" > > ... > > It is a given that making something illegal isn't going to stop it > > from happening. BUT, the idea that making IPv4 private-party to > > private-party address transfers sanctioned will not affect the IPv6 > > uptake rate is simply preposterous. > > > > For the large orgs, there's not going to be enough IPv4 for sale to > > meet their needs, so this discussion isn't even on their > radar. But > > it does matter to the smaller orgs. If you make these transfers > > sanctioned, there WILL be some smaller orgs who put off > IPv6 migration > > plans, and purchase more IPv4. > > it seems to me that until the rest of the world has upgraded, > then any given org (large or small) who wants to continue > growing the externally reachable parts of their network > (like, for IP customers) will have to have a supply of new > ipv4, even if they're deploying dual-stack at such moments. This isn't true. For example, take AOL. AOL sends out the AOL software that basically tears out your existing TCP/IP stack, moving dozens of operating system files into a backup, and replaces it with their own networking and their own Winsock interface. That is why there's program incompatabilities with some networking apps and AOL software. Someone running AOL who is running a web browser is using whatever back-end AOL has created. For all I know it's IP Tunnel in Netware IPX. I CAN tell you though that it is NOT the normal Windows IP networking stack. Since AOL has control of the transport protocol they can make it IPv6 or anything else they wanted, for that matter. It's so well-known in the industry that AOL uses a massive bank of proxy servers that I shouldn't even have to mention it, but I will just in case. Those could easily be IPv6->IPv4 proxies if AOL wanted them to be. > this has two > corollaries: > > 1. the time to dual-stack is $NOW, and arin should > investigate new policies that require proof of dual-stack > intent and action $NOW for ipv4 allocations starting $NOW; and, > > 2. the problem (as always) is other people's networks, and > all arguments of the form "ipv4's lifetime should not be > extended" boil down to "it is bad for $ME if $OTHER_PEOPLE > aren't forced to run dual-stack and get ipv6 running." > Any argument can be boiled down to the form "it is bad for $ME if $OTHER_PEOPLE..." That does not mean that this argument is the primary motivator for any one person in the $ME group. But, even assuming that it is, Do I really care that everyone in the Pro-IPv6 group is operating out of greedly self-interest? Not anymore than I care that everyone in the pro-mass transit and pro-bicycle camps are operating out of greedy self-interest of wanting to get everyone else off the freeways and onto busses or bicycles, because they really want to have the freeway to themselves. And, nor for that matter, that I care that the US Constitution was written out of the greedy-self-interest of landed gentry who didn't want to pay taxes to England. In either case, we get the network switched to IPv6 or the busses full or the bicycle lanes striped on the road, or a nation created. Ted From ppml at rs.seastrom.com Mon Jun 23 20:43:57 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Mon, 23 Jun 2008 20:43:57 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: whythetriggerdate? In-Reply-To: <486018D0.9020607@dilkie.com> (Lee Dilkie's message of "Mon, 23 Jun 2008 17:42:40 -0400") References: <2E22B483D3524EBC90ECECB29797BBA7@tedsdesk> <26271.1214254616@sa.vix.com> <486018D0.9020607@dilkie.com> Message-ID: <861w2npsqa.fsf@seastrom.com> Lee Dilkie writes: > I think we all agree that deploying IPv6/dual-stack is a cost with no > short term benefit. And it's natural for all parties to want everyone > else to bear the cost, themselves excluded. Like government mandated > pollution and mileage targets on automobiles, sometimes only an edict > will suffice to move all parties to the same level playing field at the > same time. > > So. What do we propose? That all future IPv4 blocks be deployed by > customers/ISPs dual-stack, ARIN grants a matching IPv6 block with each > IPv4 grant and insists (checks up) that it be made available to end > customers (in an ISP's case?). Until you deploy dual stack, you won't > get any more blocks from ARIN? > > This is essentially what the US government is doing to vendors, wrt > IPv6. I think it's not a bad argument that ARIN should be just as > insistent in "encouraging" IPv6 rollout. I don't think ARIN has the traction to enforce this, and as a member I'm not keen on ARIN gratuitously blowing its "war chest" on lawsuits over this sort of thing. Historically, I've been in favor of making sure everyone has an IPv6 netblock and various outreach programs so that they know what to do with them. Beyond that, though... in the words of Yogi Berra, "if the fans don't want to come out to the ball park, nobody's gonna stop 'em". As with many other technologies, there is a substantial last-mover advantage to going dual-stack or single-v6. Hard to fix that without resorting to force, and governments do like to reserve that capability for themselves alone. No matter how well-intentioned that idea is, actually trying to put it in motion is a Bad Plan. ---Rob From jay at handynetworks.com Tue Jun 24 01:16:32 2008 From: jay at handynetworks.com (Jay Sudowski) Date: Mon, 23 Jun 2008 23:16:32 -0600 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: References: Message-ID: <48608330.1030606@handynetworks.com> > BT's plan is as complex as the dozen or so IP networks that we operate. > A lot of network operators are in the same boat, still running 3 or 5 or > > 10 IP networks that result from various M&A activity and/or attempts to > integrate some networks into a merged network. Fact is that there are > customers on these networks so we like to go slow and make sure the > service > keeps running. That is why you hear so little about IPv6 from the bigger > networks, because they are easing into it in a way that does not disrupt > any existing customers. > > --Michael Dillon > And hereine lies yet another problem with IPv6, at least for the smaller operator that's connected to multiple larger Tier1 ASs. If the larger operators are taking a slow and steady approach to IPv6, then how they heck is the little guy going to get IPv6 connectivity / transit? http://www.getipv6.info/index.php/Providers_Currently_Selling_IPv6_Transit This list is decidedly short ... -Jay Sudowski From paul at vix.com Tue Jun 24 01:34:23 2008 From: paul at vix.com (Paul Vixie) Date: Tue, 24 Jun 2008 05:34:23 +0000 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: Your message of "Mon, 23 Jun 2008 23:16:32 CST." <48608330.1030606@handynetworks.com> References: <48608330.1030606@handynetworks.com> Message-ID: <42752.1214285663@sa.vix.com> > And hereine lies yet another problem with IPv6, at least for the smaller > operator that's connected to multiple larger Tier1 ASs. If the larger > operators are taking a slow and steady approach to IPv6, then how they heck > is the little guy going to get IPv6 connectivity / transit? > > -Jay Sudowski if at all possible, buy transport to an IXP and buy your transit without any kind of transport lock-in. that way if your provider doesn't offer you what you need (good pricing, good support, services like ipv6, and so on) you can add a link to a provider who will offer those things. if it's not possible, you can still sample the ipv6 technology using tunnels, which is how a lot of us got started, both for transit and in our interiors, before native ipv6 was available. hurricane electric, for example, runs a tunnel broker and i think i remember that it's free of charge. From jay at handynetworks.com Tue Jun 24 01:55:10 2008 From: jay at handynetworks.com (Jay Sudowski) Date: Mon, 23 Jun 2008 23:55:10 -0600 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why thetriggerdate? In-Reply-To: <60A854C04B0E48288CA37B0E98CA830F@tedsdesk> References: <60A854C04B0E48288CA37B0E98CA830F@tedsdesk> Message-ID: <48608C3E.6040105@handynetworks.com> Ted Mittelstaedt wrote: > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jay Sudowski >> - Handy Networks LLC >> Sent: Friday, June 20, 2008 11:21 AM >> To: Owen DeLong; Stephen Sprunk >> Cc: ARIN PPML >> Subject: Re: [arin-ppml] Q1 - ARIN address transfer policy: >> why thetriggerdate? >> >> >> For those of you who don't think a rational transfer policy >> is necessary, please consider the following: >> >> 1. In the real world, many people do not view ARIN postively. >> Business people (CEO types) who run companies that require >> portable IP space view ARIN as overly punative, prohibitive >> gatekeepers to a important resource that they need access to. >> Technicians in that have to deal with ARIN infrequently for >> initial IP allocations, additional allocations, etc hold ARIN >> in the same light. Due to this, if it often easier, far less >> stressful, and far less expensive in time/opportunity cost to >> "purchase" IP space or hire someone to interact with ARIN for >> you. Put simply and bluntly, ARIN is a pain in the ass to deal with. >> >> > > So what? People don't view the US IRS in a positive light either > and lots would sign on to a movement to get rid of it. > > It's a given that a lot of people are stupid, so what? > > If you monkey around with the IRS, they will come audit you, and you will either end up owing substantial monies to them, end up in jail, or both. Last time I checked, ARIN does not have the ability to fine anyone and send people to jail. ARIN does have the ability to stymie organizations who perceive that they have a need for IPv4 address space. Instead of dealing with ARIN, they deal with a black market IP address seller or hire a consulting who does dubious things to get their client an allocation. Doing so is not illegal. The "so what" is that ARIN's policies already foster an underground blackmarket and there are decidedly few consequences for partaking in that market. This is drastically different to your IRS analogy. The "so what" is that this black market is going to take off when IPv4 depletion occurs. The "so what" is that even dual stacked orgs with growing networks will have a need for more IPv4 address space. The "so what" is that you will have the business people running organizations packing conference rooms and they aren't going to care that the RIRs are out of address space. They will leave no stone unturned trying to find more of a resource that they need. Keep in mind that even a growing, dual stacked network will need more IPv4 space. >> 2. I have been aware of people have been buying, selling and >> using subterfuge to obtain IP allocations for as long as I >> have been been in the industry (the past 8 years). Some examples: >> >> 2a. Three companies merge into one. For many months after >> they merged, they continued to interact with ARIN as separate >> entities, obtaining far more IP allocations than they would >> have been able to as a single entity. Even today, this >> single entity (which has now recently merged again), >> interacts with ARIN using two separate, but related entity >> names and two separate ORG IDs. >> >> 2b. Every month I run into people who are willing to sell me >> their /18, /19, /20 for a fee. It is my understanding that >> such transactions are usually structured so that other >> [usually worthless] assets or an entire shell entity are >> included in the sale to pass ARIN scrutiny. >> >> 2c. For a time, I did work for an entity that had previous >> bad blood with ARIN (see point 1) and managed to obtain 3 >> /18s on the after market. From what I gather, this is not >> all that unusual. >> >> 2d. There are consultants out there who, for a fee, guarantee >> you will get an IP allocation from ARIN. They are able to >> accomplish because they control a large amount of IP space >> for entities that they work for, and they SWIP out space from >> those entities to the entity paying them for the direct >> allocation. Bogus data is submitted to ARIN, the SWIP'd >> space supports the bogus allocation, and the allocation is granted. >> >> 2e. ARIN members continue to report IP usage by customers >> that have long since left their network, inflating their >> actual need and utilization percentages, allowing them to >> obtain unneccesary allocations from ARIN. >> >> For those of you who want to maintain the status quo, think >> about the above and then think about how the bad actors will >> multiply once IPv4 becomes truly scarce. >> > > Once more, so what? > > The brokers out there who are selling IP space won't last long. > When an org that needs IPv4 buys it, they will use it. It will > then no longer be available for resale. > > Imagine it this way. There's a lot of bad citizens out there > who get flood damaged cars, spruce them up, then sell them to > victims as new. One day, all the automakers announce that they > are running out of cars, and there won't be any after 2011. > > So by 2020 or so, all the cars will be in service or used up > or in wrecking yards. There won't be any left and these > nasty people will have to find some other scam. > You openly admit here that a black market will exist. Given the chance, why wouldn't you want to try to regulate these transactions? Why not craft reasonable, logical policy that protects the interests of the community, the buyers and the sellers? >> even be a market for IP space, etc. Meanwhile, people >> operating in the real world, will do what they have to do to >> put food on their table and gas in their cars. As such, they >> will continue to do what they are doing today [see 2a-e] and >> will do so with increasing frequncy and neccessity as IP >> depletion becomes reality. >> >> > > And when all the IPv4 is tied up, then what will these > people do? > They will continue to trade in IP allocations. The trading will eventually take on the feel of M&As, though. Companies that extract higher revenue per IP will buy companies that have less revenue per IP. >> The choice should be to either create a framework that >> attemps to define, regulate and bring some transparency an IP >> allocation trading/transfer market or simply come to the >> realization that the existing IP address marketplace, which >> exists in the hidden corners of the Internet, will continue >> to function and evolve as depletion comes closer and closer >> to reality. >> >> > > I've already come to the realization that the existing IP address > marketplace, which exists in the hidden corners of the Internet, > will continue to function. But I've also come to the realization > that it won't function very long after the RIR's run out of IPv4. > So why should we help it out any? > > Once again, how does it help me to assist in stretching out IPv4? > Everything you have said simply tells me that the more effort I > put into helping prolong IPv4 post-runout, the more power and > authority I give into the hands of these bad people who you seem > to think are going to run IPv4 allocations in the hidden corners > of the Internet. > I disagree. I made several distinct points that illustrate what people are doing today to obtain IP space in unsavory ways. In some cases, the companies that ultimately end up using the IP space have a legitimate need for that space; they just cannot convey it to ARIN in terms ARIN finds acceptable under current policy. And clearly, in other cases people are obtaining IP space for non legitimate reasons (hoarding, speculative purchasing, etc). Regardless, my overall statement is simple: the blackmarket for IPv4 space will escalate drastically when IPv4 depletion becomes reality. ARIN can proactively implement polices and frameworks that attempt to provide a legitimate marketplace for the trading of IP allocations. Or ARIN can sit by idly, watching helplessly on the sidelines, while business do what they have to do to continue growing their networks. I see far more harm in the later than the former > Ted > > > -Jay Sudowski From michael.dillon at bt.com Tue Jun 24 05:30:10 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 24 Jun 2008 10:30:10 +0100 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: <18572.1214239991@sa.vix.com> Message-ID: > if what they need to do is create new endpoints that need > global reachability to existing endpoints, then deploying > ipv6 is all cost no benefit. the cases where someone only > needs limited reachability to themselves and their partners > is generally being handled with IPv4 RFC1918 space today, and > while ipv6 makes that better, the betterness in that case > does not relieve any pressure on the > non-RFC1918 ipv4 pool. You are looking at the problem in black and white. But there are more than two flavours of networking. In the grey area are lots of networks which interconnect with some limited set of other autonomous networks in an IP internetwork. Because it is an internetwork, not a private network, they need to use globally unique IP addresses. However, if these people move to IPv6, then they don't have to wrestle with the global Internet connectivity problem. As for the cost benefit issue, sometimes you just have to see the writing on the wall and realize that you will have to spend money sooner or later. The benefit that you get for your cost outlay is that you get to stay in the network game. Otherwise, save your money and shut down your business when the day comes. For the rest of us the question is when do we spend the money, and how do we spend it in such a way that it doesn't harm the business. We all have to implement IPv6. Some of us will get greater benefit by moving in early and building up IPv6 capability year on year. Others will benefit by waiting a while and making the big leap just before the wall comes down. But in general, the benefits will be the following: 1. You stay in the game 2. You don't damage your overall business too much 3. You keep change to a manageable level In any case, there is no answer to the question: How do we move to IPv6? The reality is that everyone is in a slightly different situation so the movement will happen in fits and starts, sometimes in the open, sometimes in secret. There will be trial and tribulations like in the early days of the commercial Internet or the early DSL deployments. There simply is no magic bullet, and no right way to do things. --Michael Dillon From michael.dillon at bt.com Tue Jun 24 05:46:29 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 24 Jun 2008 10:46:29 +0100 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <861w2npsqa.fsf@seastrom.com> Message-ID: > As with many other technologies, there is a substantial > last-mover advantage to going dual-stack or single-v6. On what do you base this opinion? --Michael Dillon From jcurran at istaff.org Tue Jun 24 05:53:25 2008 From: jcurran at istaff.org (John Curran) Date: Tue, 24 Jun 2008 05:53:25 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: <48608C3E.6040105@handynetworks.com> References: <60A854C04B0E48288CA37B0E98CA830F@tedsdesk> <48608C3E.6040105@handynetworks.com> Message-ID: At 11:55 PM -0600 6/23/08, Jay Sudowski wrote: >In some cases, the companies that ultimately end up using the IP >space have a legitimate need for that space; they just cannot convey >it to ARIN in terms ARIN finds acceptable under current policy. Please suggest clarifications to policy if there's some ambiguity or lack in the NRPM. Otherwise, I'm not certain what you mean by "legitimate need" since that's defined by the public policy process. Thanks, /John From Lee at dilkie.com Tue Jun 24 07:44:26 2008 From: Lee at dilkie.com (Lee Dilkie) Date: Tue, 24 Jun 2008 07:44:26 -0400 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: References: Message-ID: <4860DE1A.3000808@dilkie.com> michael.dillon at bt.com wrote: >> As with many other technologies, there is a substantial >> last-mover advantage to going dual-stack or single-v6. >> > > On what do you base this opinion? > > --Michael Dillon > > Moore's Law, one would think. Delaying purchase of networking equipment will yield better performance for lower cost. From Lee at dilkie.com Tue Jun 24 07:55:54 2008 From: Lee at dilkie.com (Lee Dilkie) Date: Tue, 24 Jun 2008 07:55:54 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: whythetriggerdate? In-Reply-To: <861w2npsqa.fsf@seastrom.com> References: <2E22B483D3524EBC90ECECB29797BBA7@tedsdesk> <26271.1214254616@sa.vix.com> <486018D0.9020607@dilkie.com> <861w2npsqa.fsf@seastrom.com> Message-ID: <4860E0CA.2040709@dilkie.com> Robert E. Seastrom wrote: > I don't think ARIN has the traction to enforce this, and as a member > I'm not keen on ARIN gratuitously blowing its "war chest" on lawsuits > over this sort of thing. > Sure it does. ARIN has the "traction" to enforce it's usage rules. It can refuse additional requests if previous allocations have not met utilization. ARIN can even revoke allocations if utilizations have not been met. There's no war chest to worry about, it's simply a contractual issue with the RSA. > Historically, I've been in favor of making sure everyone has an IPv6 > netblock and various outreach programs so that they know what to do > with them. Beyond that, though... in the words of Yogi Berra, "if > the fans don't want to come out to the ball park, nobody's gonna stop > 'em". > > As with many other technologies, there is a substantial last-mover > advantage to going dual-stack or single-v6. Hard to fix that without > resorting to force, and governments do like to reserve that capability > for themselves alone. > > No matter how well-intentioned that idea is, actually trying to put it > in motion is a Bad Plan. > The thing is. This isn't a simple battle over technologies, like beta vs. VHS, and may the best tech win in the marketplace. We are dealing with the runout of a common(shared) resource, which has bad consequences for everyone. Like other governments (ARIN is essentially a government, being a good steward of IP resources), perhaps we do need to push hard for IPv6 adoption. Like minimum milage requirements and pollution controls on automobiles, when dealing with the common good it is sometimes necessary to simply force the matter by edict. -lee From ppml at rs.seastrom.com Tue Jun 24 07:59:53 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Tue, 24 Jun 2008 07:59:53 -0400 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: (michael dillon's message of "Tue, 24 Jun 2008 10:46:29 +0100") References: Message-ID: <86skv39h6u.fsf@seastrom.com> writes: >> As with many other technologies, there is a substantial >> last-mover advantage to going dual-stack or single-v6. > > On what do you base this opinion? I base it on the fact that technologies mature, that the cost to support goes way way down as the average joe becomes more familiar with it and it becomes less dodgy and idiosyncratic. Remember the joy of supporting customers who were running Trumpet Winsock or MacSLIP? If you want to relive those days, chase your customers into single-stack v6. These days, in the home gateway department for instance, we are in the flint knives and bearskins era when it comes to IPv6 support. Some of us choose to run v6 and offer it to our customers anyway, but the guy who leaves the business on the table for now and picks it up after others have blazed the table may be making a smarter business decision. Of course, we get a bunch of intangibles like early experience etc. The stockholders probably don't care. ---Rob From kkargel at polartel.com Tue Jun 24 09:21:35 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 24 Jun 2008 08:21:35 -0500 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <4860DE1A.3000808@dilkie.com> References: <4860DE1A.3000808@dilkie.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10874@mail> Don't forget the fact that IPv6 is not yet a perfect or mature service. Delaying IPv6 implementation will avoid the costs involved with development and debugging of local networks while letting others do the dirty work. I am not advocating this, just recognizing a reality. The forward thinking administrators that want to make a difference in the world will jump in and get it done, the profit driven enterprises will sit back and wait until everything is easy or unavoidable. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lee Dilkie Sent: Tuesday, June 24, 2008 6:44 AM To: michael.dillon at bt.com Cc: ppml at arin.net Subject: Re: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? michael.dillon at bt.com wrote: >> As with many other technologies, there is a substantial last-mover >> advantage to going dual-stack or single-v6. >> > > On what do you base this opinion? > > --Michael Dillon > > Moore's Law, one would think. Delaying purchase of networking equipment will yield better performance for lower cost. _______________________________________________ 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 the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From tvest at pch.net Tue Jun 24 09:55:15 2008 From: tvest at pch.net (Tom Vest) Date: Tue, 24 Jun 2008 09:55:15 -0400 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10874@mail> References: <4860DE1A.3000808@dilkie.com> <70DE64CEFD6E9A4EB7FAF3A063141066A10874@mail> Message-ID: <6DE777FC-F2F9-4FE7-8A02-58F1531B167D@pch.net> There is also the matter of asymmetrical dependence and bargaining power (detailed ad nauseam last week). Unless something changes, on the day after free pool exhaustion and every day thereafter, "incumbent" IPv4-based networks will be able to unilaterally decide whether/when they want to be transparently interoperable with native IPv6 networks, and they will be able to unilaterally act to make that possible, e.g., by going dual-stack, renumbering, or operating a symmetrical 6/4 gateway. Unless something changes, on the day after free pool exhaustion and every day thereafter, new IPv6-only networks will need to interoperate with the universe of incumbent IPv4 networks. However, they will NOT be able to unilaterally act to make that possible as long as that requires at least some IPv4, which at that point will only available from those incumbent networks, or from "pure speculators". That asymmetry is what will drive the price of IPv4 up and up, and that increasing profit potential and bargaining power -- which is just an artifact of the lingering IPv4 bottleneck between new IPv6 networks and everything still accessible only via IPv4 -- is what will incentivize incumbent IPv4 networks/IPv4 dealers to delay their own shift to transparent interoperability for as long as possible. Aspiring to be the last-mover will be the only rational strategy in the environment that an IPv4 resource transfer market will create. But maybe rationality will take a holiday :-\ TV On Jun 24, 2008, at 9:21 AM, Kevin Kargel wrote: > Don't forget the fact that IPv6 is not yet a perfect or mature > service. > Delaying IPv6 implementation will avoid the costs involved with > development and debugging of local networks while letting others do > the > dirty work. I am not advocating this, just recognizing a reality. > The > forward thinking administrators that want to make a difference in the > world will jump in and get it done, the profit driven enterprises will > sit back and wait until everything is easy or unavoidable. > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On > Behalf Of Lee Dilkie > Sent: Tuesday, June 24, 2008 6:44 AM > To: michael.dillon at bt.com > Cc: ppml at arin.net > Subject: Re: [arin-ppml] Q1 - ARIN address transferpolicy: > whythetriggerdate? > > > michael.dillon at bt.com wrote: >>> As with many other technologies, there is a substantial last-mover >>> advantage to going dual-stack or single-v6. >>> >> >> On what do you base this opinion? >> >> --Michael Dillon >> >> > Moore's Law, one would think. Delaying purchase of networking > equipment > will yield better performance for lower cost. From info at arin.net Tue Jun 24 10:25:12 2008 From: info at arin.net (Member Services) Date: Tue, 24 Jun 2008 10:25:12 -0400 Subject: [arin-ppml] ARIN Board Adopts Three Policy Proposals Message-ID: <486103C8.3050002@arin.net> On 20 June 2008 the ARIN Board of Trustees adopted three policy proposals: 2008-1: SWIP support for smaller than /29 assignments 2007-21: PIv6 for legacy holders with RSA and efficient use 2007-23: End Policy for IANA IPv4 allocations to RIRs The first two policies, 2008-1 and 2007-21, will be implemented no later than 31 August 2008. As 2007-23 is a global policy proposal, it will be implemented after ratification by the ICANN Board of Directors. Policy proposal texts are available at the Policy Proposal Archive which can be found at: http://www.arin.net/policy/proposal_archive.html Regards, Member Services Department American Registry for Internet Numbers (ARIN) From paul at vix.com Tue Jun 24 10:30:43 2008 From: paul at vix.com (Paul Vixie) Date: Tue, 24 Jun 2008 14:30:43 +0000 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: Your message of "Tue, 24 Jun 2008 10:30:10 +0100." References: Message-ID: <60600.1214317843@sa.vix.com> > As for the cost benefit issue, sometimes you just have to see the writing on > the wall and realize that you will have to spend money sooner or later. ... alas, not in america for the last couple of decades. it's all about current quarter or in-year revenue and expense. the most that many large companies can do at this point is make sure they know what they will do at RIR runout, and trigger that plan at IANA runout. that may not sound like much but it's way more than medium-to-small companies will do, which is: sit tight, wait for an ipv6 internet to appear through the efforts of larger better-funded companies, and assume that the dribs and drabs of ipv4 space needed by small companies will not be of any interest to the large companies, so feel "safe". in this part of the analysis, there's good symmetry between "can afford to be an early mover" and "is so large and with so much organizational inertia that being a late mover would be fatal". in other words the smaller entities who can't afford to invest in ipv6 until there's an in-year or in-quarter motive to do so, are also the ones who can do so the quickest when their time comes, and the "dribs and drabs" of ipv4 space that the big guys won't be able to use, will tide the little guys over just fine. note that i'm not just not speaking for the ARIN BoT here, i'm also not really speaking for my own preferences. this is the call-it-as-i-see-it department. From tvest at pch.net Tue Jun 24 10:48:22 2008 From: tvest at pch.net (Tom Vest) Date: Tue, 24 Jun 2008 10:48:22 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: <60600.1214317843@sa.vix.com> References: <60600.1214317843@sa.vix.com> Message-ID: <65E62262-77EB-47C6-AF9E-E3EB25A421D9@pch.net> On Jun 24, 2008, at 10:30 AM, Paul Vixie wrote: >> As for the cost benefit issue, sometimes you just have to see the >> writing on >> the wall and realize that you will have to spend money sooner or >> later. ... > > alas, not in america for the last couple of decades. it's all about > current > quarter or in-year revenue and expense. the most that many large > companies > can do at this point is make sure they know what they will do at RIR > runout, > and trigger that plan at IANA runout. that may not sound like much > but it's > way more than medium-to-small companies will do, which is: sit > tight, wait > for an ipv6 internet to appear through the efforts of larger better- > funded > companies, and assume that the dribs and drabs of ipv4 space needed > by small > companies will not be of any interest to the large companies, so > feel "safe". > > in this part of the analysis, there's good symmetry between "can > afford to be > an early mover" and "is so large and with so much organizational > inertia that > being a late mover would be fatal". in other words the smaller > entities who > can't afford to invest in ipv6 until there's an in-year or in- > quarter motive > to do so, are also the ones who can do so the quickest when their > time comes, > and the "dribs and drabs" of ipv4 space that the big guys won't be > able to > use, will tide the little guys over just fine. Hi Paul, How do you think the "dribs and drabs" are going to make it to the little guys? What would cause the owners of something uniquely valuable -- even something that the owner couldn't use directly -- to part with it on "reasonable" terms? Assuming they are willing to part with it at some price that's less than the absolute max that "the market will bear", what will prevent other players who are willing to pay more than little guy "reasonable terms" from buying it up and internalizing the difference? TV From paul at vix.com Tue Jun 24 10:50:53 2008 From: paul at vix.com (Paul Vixie) Date: Tue, 24 Jun 2008 14:50:53 +0000 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: Your message of "Tue, 24 Jun 2008 07:59:53 -0400." <86skv39h6u.fsf@seastrom.com> References: <86skv39h6u.fsf@seastrom.com> Message-ID: <61567.1214319053@sa.vix.com> > From: "Robert E. Seastrom" > > >> As with many other technologies, there is a substantial > >> last-mover advantage to going dual-stack or single-v6. > > > > On what do you base this opinion? > > I base it on the fact that technologies mature, that the cost to support > goes way way down as the average joe becomes more familiar with it and it > becomes less dodgy and idiosyncratic. Remember the joy of supporting > customers who were running Trumpet Winsock or MacSLIP? If you want to > relive those days, chase your customers into single-stack v6. that analogy doesn't hold, since a macslip customer back in the day would still be a customer in the second month, whereas, not so an ipv6-only customer today. > These days, in the home gateway department for instance, we are in the flint > knives and bearskins era when it comes to IPv6 support. Some of us choose > to run v6 and offer it to our customers anyway, but the guy who leaves the > business on the table for now and picks it up after others have blazed the > table may be making a smarter business decision. Of course, we get a bunch > of intangibles like early experience etc. The stockholders probably don't > care. the biggest reason why a last-mover advantage exists for ipv6 is the "network effect". when i was at paix we opened some new facilities after palo alto's runaway success, and in each city we had to set the IX port fee to $0 until there were ten ISPs connected to the switch in that city, at which point the normal pricing would kick in. nobody wanted to pay for a switch port when there was effectively no benefit to it since nobody else was connected yet. the benefit to connecting to a network is a function of the size of that network. the size of the ipv6-reachable public internet is very very small today, whereas for the last-mover it will be as large or larger than ipv4 is today. so, equipment costs and quality, and moore's law, all enter into it, but the dominant term of the "last-mover advantage" equation is the "network effect". which is why i've been saying for the last couple of years that ARIN needs to investigate a policy whereby at some date before some runout milestone, new ipv4 is only available to those who can demonstrate that they will use it on dual-stack public-facing networks. i don't LIKE this idea, but i don't see any way to soften the impact between the internet community and our brick wall otherwise. (note, as before, this is a personal position, not an ARIN BoT position, and in particular, counsel has not weighed in on its advisability.) From owen at delong.com Tue Jun 24 11:15:12 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Jun 2008 08:15:12 -0700 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <6DE777FC-F2F9-4FE7-8A02-58F1531B167D@pch.net> References: <4860DE1A.3000808@dilkie.com> <70DE64CEFD6E9A4EB7FAF3A063141066A10874@mail> <6DE777FC-F2F9-4FE7-8A02-58F1531B167D@pch.net> Message-ID: <02E3721E-9D06-4F0D-8ED3-47CF896F026A@delong.com> Tom, Absent the recent policy proposal to create a reservation for IPv6 Transitional Technologies in the ARIN IPv4 free pool, I would agree with you. However, wouldn't that policy mitigate what you are saying below? (assuming it gets adopted) Owen On Jun 24, 2008, at 6:55 AM, Tom Vest wrote: > There is also the matter of asymmetrical dependence and bargaining > power (detailed ad nauseam last week). > > Unless something changes, on the day after free pool exhaustion and > every day thereafter, "incumbent" IPv4-based networks will be able to > unilaterally decide whether/when they want to be transparently > interoperable with native IPv6 networks, and they will be able to > unilaterally act to make that possible, e.g., by going dual-stack, > renumbering, or operating a symmetrical 6/4 gateway. > > Unless something changes, on the day after free pool exhaustion and > every day thereafter, new IPv6-only networks will need to interoperate > with the universe of incumbent IPv4 networks. However, they will NOT > be able to unilaterally act to make that possible as long as that > requires at least some IPv4, which at that point will only available > from those incumbent networks, or from "pure speculators". > > That asymmetry is what will drive the price of IPv4 up and up, and > that increasing profit potential and bargaining power -- which is just > an artifact of the lingering IPv4 bottleneck between new IPv6 networks > and everything still accessible only via IPv4 -- is what will > incentivize incumbent IPv4 networks/IPv4 dealers to delay their own > shift to transparent interoperability for as long as possible. > > Aspiring to be the last-mover will be the only rational strategy in > the environment that an IPv4 resource transfer market will create. > > But maybe rationality will take a holiday :-\ > > TV > > On Jun 24, 2008, at 9:21 AM, Kevin Kargel wrote: > >> Don't forget the fact that IPv6 is not yet a perfect or mature >> service. >> Delaying IPv6 implementation will avoid the costs involved with >> development and debugging of local networks while letting others do >> the >> dirty work. I am not advocating this, just recognizing a reality. >> The >> forward thinking administrators that want to make a difference in the >> world will jump in and get it done, the profit driven enterprises >> will >> sit back and wait until everything is easy or unavoidable. >> >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >> On >> Behalf Of Lee Dilkie >> Sent: Tuesday, June 24, 2008 6:44 AM >> To: michael.dillon at bt.com >> Cc: ppml at arin.net >> Subject: Re: [arin-ppml] Q1 - ARIN address transferpolicy: >> whythetriggerdate? >> >> >> michael.dillon at bt.com wrote: >>>> As with many other technologies, there is a substantial last-mover >>>> advantage to going dual-stack or single-v6. >>>> >>> >>> On what do you base this opinion? >>> >>> --Michael Dillon >>> >>> >> Moore's Law, one would think. Delaying purchase of networking >> equipment >> will yield better performance for lower cost. > > > _______________________________________________ > 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 the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From kkargel at polartel.com Tue Jun 24 11:17:04 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 24 Jun 2008 10:17:04 -0500 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <61567.1214319053@sa.vix.com> References: <86skv39h6u.fsf@seastrom.com> <61567.1214319053@sa.vix.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10878@mail> -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Paul Vixie Sent: Tuesday, June 24, 2008 9:51 AM To: Robert E. Seastrom Cc: ppml at a rin.net Subject: Re: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? > From: "Robert E. Seastrom" >which is why i've been saying for the last couple of years that ARIN needs to investigate a policy whereby at some date before some runout >>milestone, new >ipv4 is only available to those who can demonstrate that they will use it on dual-stack public-facing networks. i don't LIKE this idea, but >i don't see any way to soften the impact between the internet community and our brick wall otherwise. (note, as before, this is a personal >position, not an ARIN BoT position, and in particular, counsel has not weighed in on its advisability.) I agree with the idea of requiring dual-stack if and when IPv6 is readily available in the market. At the present time my organization does not have access to IPv6 except through tunneling. Neither of my upstream providers offer IPv6 in this area. I strongly oppose any effort to create an artificial IP commodities market. I know it is a philosophical stand and will draw many flames, but the Americans who most benefit from access to internet are the low to middle income groups, and adding even small charges to that access could take internet out of their grasp. Anything we can do to prevent raising that cost will benefit society. While we are all more comfortable than many families, please don't forget those who have to make hard decisions budgeting for residential information services. From paul at vix.com Tue Jun 24 11:30:08 2008 From: paul at vix.com (Paul Vixie) Date: Tue, 24 Jun 2008 15:30:08 +0000 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: Your message of "Tue, 24 Jun 2008 10:48:22 -0400." <65E62262-77EB-47C6-AF9E-E3EB25A421D9@pch.net> References: <60600.1214317843@sa.vix.com> <65E62262-77EB-47C6-AF9E-E3EB25A421D9@pch.net> Message-ID: <63101.1214321408@sa.vix.com> > From: Tom Vest > > Hi Paul, > > How do you think the "dribs and drabs" are going to make it to the > little guys? some will just sit in the ARIN free pool, unusable by larger entities since they will be too small to be worth the paperwork. some will be returned and handed back out. some will be illicitly transferred via the same mechanisms that appear to have aided geoff mulligan lately. or, 2008-2 or something like it may come into existence. or your proposal to reserve some part of the pool for IPv6/IPv4 gateway networks may gain traction. > What would cause the owners of something uniquely valuable -- even > something that the owner couldn't use directly -- to part with it on > "reasonable" terms? that depends on the coming battle between the regulators and the speculators. if the buy-price is set by those who need ipv4 space to expand their networks, then large networks won't bid on small blocks, and the sell-price will be by definition something small/medium networks can afford to pay (and amortize). if the buy-price is set by those who want to sell later, as in the current world oil market, then all bets are off. the invisible hand of a free market automatically puts fungible commodities to their "highest and best use" which in the case of electric power in california in 2001 was to sideline capacity so as to push up the price. this buy-price delta is the reason i support the must-qualify provisions in 2008-2, even though i'm still on the fence as to whether i like 2008-2 at all. this delta is also why i'm particularly concerned about the geoff mulligan story, and the other anecdotes told here recently, maybe indicating a culture not unlike that during america's prohibition experiment in the 1920's, where there's a lot of winking and nodding going on and most transactions are off the books. the community has to decide whether this is what we want, since ARIN could ratchet up enforcement, but if the current system is seen by many as working, then perhaps the community should investigate a more APNIC-like transfer policy without any must-qualify provision. > Assuming they are willing to part with it at some price that's less than the > absolute max that "the market will bear", what will prevent other players > who are willing to pay more than little guy "reasonable terms" from buying > it up and internalizing the difference? speculation can be a very profitable activity for those who engage in it, but the resulting volatility is bad for consumers. i do not particularly want my actions and values to be monetized in this way, not for ipv4 space, not for oil, not for electric power in california in 2001. if we here are amateurs as randy bush has often said, then the speculators will win no matter what and we should plan for that future (which is the reasoning that led me to once call APNIC's transfer policy the "Lay Down and Die Act of 2008"). there are a couple ways to avoid volatility in the upcoming endgame. one is to find ways to accelerate ipv6 deployment, such as gating ipv4 allocations so that they are only available for dual-stack networks, starting well before runout, perhaps even starting as soon as $NOW. another is to find ways to structually drive out speculation, like offering the LRSA, pushing for the must-qualify provisions in 2008-2, ratcheting up ARIN's enforcement, asking USG to formally authorize ARIN as its successor in interest for legacy space and investigating policies like APNIC's "sign an LRSA or lose your in-addr and whois". i'd prefer that the ARIN community seriously pursue anti-volatility actions. (note, as before, this is a personal position, not nec'ily that of the BoT.) paul From sleibrand at internap.com Tue Jun 24 12:58:27 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 24 Jun 2008 09:58:27 -0700 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10878@mail> References: <86skv39h6u.fsf@seastrom.com> <61567.1214319053@sa.vix.com> <70DE64CEFD6E9A4EB7FAF3A063141066A10878@mail> Message-ID: <486127B3.8010504@internap.com> Kevin Kargel wrote: > I strongly oppose any effort to create an artificial IP commodities > market. I know it is a philosophical stand and will draw many flames, > but the Americans who most benefit from access to internet are the low > to middle income groups, and adding even small charges to that access > could take internet out of their grasp. Anything we can do to prevent > raising that cost will benefit society. While we are all more > comfortable than many families, please don't forget those who have to > make hard decisions budgeting for residential information services. Which will raise costs to those groups more: denying their ISPs the ability to get new IPv4 addresses? Or allowing them to make a choice of whether or not to get addresses on the transfer market? If you're not sure, consider an analogy: which would it be better to tell a low-income family? "I'm sorry, gas is too scarce, so we stopped selling it here: you'll need to ride the bus." or "I'm sorry gas is so expensive: if it works better for you, you might want to consider riding the bus instead." -Scott From tvest at pch.net Tue Jun 24 13:23:01 2008 From: tvest at pch.net (Tom Vest) Date: Tue, 24 Jun 2008 13:23:01 -0400 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <02E3721E-9D06-4F0D-8ED3-47CF896F026A@delong.com> References: <4860DE1A.3000808@dilkie.com> <70DE64CEFD6E9A4EB7FAF3A063141066A10874@mail> <6DE777FC-F2F9-4FE7-8A02-58F1531B167D@pch.net> <02E3721E-9D06-4F0D-8ED3-47CF896F026A@delong.com> Message-ID: <4A3971AD-52EB-485C-9B50-403ED4590870@pch.net> Hi Owen, Thanks for the question. For the most part, the answer was anticipated by Paul. If a policy like this gets approved, and the reserved pool is large enough to last long enough so that no one -- no active IPv4-based operator or outside speculator -- could even conceive of a time horizon over which exploitation of the asymmetry/bottleneck opportunity might be profitable, then perhaps this won't be a problem. For that, the reserved pool would have to be big enough, at least, to accommodate transitional resources for all new entrants, assuming the fastest plausible rate of new entry, for the longest conceivable transition to de-facto full IPv4-IPv6 substitutability -- the point when everything important is transparently accessible by IPv6-only networks. To begin estimating that quantity, I could derive the historical new entrant rate for the RIPE region, because I can distinguish the initial allocations from the subsequent allocations -- but I would have to defer to somebody else for the ARIN, et al rates... In either case, what would count as a plausible new entry rate for the next (x) years, relative to the historical rates -- what is the biggest bottleneck likely to be (address resources, routing capacity, transport facilities, etc.)? And what's the largest plausible (x) until de-facto substitutability is achieved, given (at least) the strategic considerations above? TV On Jun 24, 2008, at 11:15 AM, Owen DeLong wrote: > Tom, > Absent the recent policy proposal to create a reservation > for IPv6 Transitional Technologies in the ARIN IPv4 free pool, > I would agree with you. However, wouldn't that policy mitigate > what you are saying below? (assuming it gets adopted) > > Owen > > On Jun 24, 2008, at 6:55 AM, Tom Vest wrote: > >> There is also the matter of asymmetrical dependence and bargaining >> power (detailed ad nauseam last week). >> >> Unless something changes, on the day after free pool exhaustion and >> every day thereafter, "incumbent" IPv4-based networks will be able to >> unilaterally decide whether/when they want to be transparently >> interoperable with native IPv6 networks, and they will be able to >> unilaterally act to make that possible, e.g., by going dual-stack, >> renumbering, or operating a symmetrical 6/4 gateway. >> >> Unless something changes, on the day after free pool exhaustion and >> every day thereafter, new IPv6-only networks will need to >> interoperate >> with the universe of incumbent IPv4 networks. However, they will NOT >> be able to unilaterally act to make that possible as long as that >> requires at least some IPv4, which at that point will only available >> from those incumbent networks, or from "pure speculators". >> >> That asymmetry is what will drive the price of IPv4 up and up, and >> that increasing profit potential and bargaining power -- which is >> just >> an artifact of the lingering IPv4 bottleneck between new IPv6 >> networks >> and everything still accessible only via IPv4 -- is what will >> incentivize incumbent IPv4 networks/IPv4 dealers to delay their own >> shift to transparent interoperability for as long as possible. >> >> Aspiring to be the last-mover will be the only rational strategy in >> the environment that an IPv4 resource transfer market will create. >> >> But maybe rationality will take a holiday :-\ >> >> TV >> >> On Jun 24, 2008, at 9:21 AM, Kevin Kargel wrote: >> >>> Don't forget the fact that IPv6 is not yet a perfect or mature >>> service. >>> Delaying IPv6 implementation will avoid the costs involved with >>> development and debugging of local networks while letting others do >>> the >>> dirty work. I am not advocating this, just recognizing a reality. >>> The >>> forward thinking administrators that want to make a difference in >>> the >>> world will jump in and get it done, the profit driven enterprises >>> will >>> sit back and wait until everything is easy or unavoidable. >>> >>> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >>> On >>> Behalf Of Lee Dilkie >>> Sent: Tuesday, June 24, 2008 6:44 AM >>> To: michael.dillon at bt.com >>> Cc: ppml at arin.net >>> Subject: Re: [arin-ppml] Q1 - ARIN address transferpolicy: >>> whythetriggerdate? >>> >>> >>> michael.dillon at bt.com wrote: >>>>> As with many other technologies, there is a substantial last-mover >>>>> advantage to going dual-stack or single-v6. >>>>> >>>> >>>> On what do you base this opinion? >>>> >>>> --Michael Dillon >>>> >>>> >>> Moore's Law, one would think. Delaying purchase of networking >>> equipment >>> will yield better performance for lower cost. >> >> >> _______________________________________________ >> 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 the ARIN Member Services Help Desk at info at arin.net >> if you experience any issues. > From tvest at pch.net Tue Jun 24 13:42:14 2008 From: tvest at pch.net (Tom Vest) Date: Tue, 24 Jun 2008 13:42:14 -0400 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <486127B3.8010504@internap.com> References: <86skv39h6u.fsf@seastrom.com> <61567.1214319053@sa.vix.com> <70DE64CEFD6E9A4EB7FAF3A063141066A10878@mail> <486127B3.8010504@internap.com> Message-ID: On Jun 24, 2008, at 12:58 PM, Scott Leibrand wrote: > Kevin Kargel wrote: > >> I strongly oppose any effort to create an artificial IP commodities >> market. I know it is a philosophical stand and will draw many >> flames, >> but the Americans who most benefit from access to internet are the >> low >> to middle income groups, and adding even small charges to that access >> could take internet out of their grasp. Anything we can do to >> prevent >> raising that cost will benefit society. While we are all more >> comfortable than many families, please don't forget those who have to >> make hard decisions budgeting for residential information services. > > Which will raise costs to those groups more: denying their ISPs the > ability to get new IPv4 addresses? Or allowing them to make a > choice of > whether or not to get addresses on the transfer market? > > If you're not sure, consider an analogy: which would it be better to > tell a low-income family? "I'm sorry, gas is too scarce, so we stopped > selling it here: you'll need to ride the bus." or "I'm sorry gas is so > expensive: if it works better for you, you might want to consider > riding > the bus instead." > > -Scott If the family suspected, rightly or wrongly, that gas was so expensive because it was being hoarded/manipulated, then even a polite characterization/suggestion might not deter them from exploring "other" alternatives. If that message happened to be delivered by someone riding in a big car with a built-in lifetime supply of gas, and then some, some of those other alternatives might be of the "kill the messenger" variety. Probably best not to have to deliver messages like that at all, unless it's universally obvious that all conceivable constructive alternatives have been exhausted. TV From info at arin.net Tue Jun 24 13:49:09 2008 From: info at arin.net (Member Services) Date: Tue, 24 Jun 2008 13:49:09 -0400 Subject: [arin-ppml] Policy Proposal 2008-5 Dedicated IPv4 block to facilitate IPv6 deployment Message-ID: <48613395.3010603@arin.net> On 19 June 2008, the ARIN Advisory Council (AC) concluded its review of "Dedicated IPv4 block to facilitate IPv6 deployment" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2008-5: Dedicated IPv4 block to facilitate IPv6 deployment. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2008_5.html All persons in the community are encouraged to discuss Policy Proposal 2008-5 prior to it being presented at the October ARIN XXII Public Policy Meeting. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2008-5 Dedicated IPv4 block to facilitate IPv6 deployment Author: Alain Durand Proposal Version: 1.0 Submission Date: 6/6/2008 Proposal type: New Policy term: Permanent Policy statement: 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; 6) recipient organizations must be members in good standing of ARIN. Rationale: Rationale for reserving IPv4 space: This policy provides predictability on how the end game of IPv4 is going to be played after IANA completion. It will facilitate IPv6 deployment by ensuring that some small chunks of IPv4 space will remain available for a long time to ease the co-existence of IPv4 & IPv6. Rationale for reserving a contiguous /10 This is a balance between setting aside too much space and not having enough to facilitate IPv6 deployment for many years. Out of the last /8, that would leave the equivalent of 3 /10 to ARIN either for business as usual or for other policies in the spirit of this one. A /10 represents 4,194,304 IP addresses, If all of them were to be used in NAT-PT or NAT464 type devices with a consolidation factor of 100 users behind each IP address, that would represent about 400 million users. Most networks today filter IPv4 announcements more specific than /24. This policy creates allocations & assignment prefixes as long as /28. Allocating out of a contiguous block will mitigate the impact of this policy on filter lists. Rationale for minimum size allocation of /28 This minimum size allocation will put a cap at 250k additional entries in the global IPv4 routing table. Rationale for maximum size allocation of /24 and for the 6 month delay between allocations This maximum allocation size coupled with the requirement of a 6 months delay between allocations will prevent hoarding and make sure this pool will last several years. Rationale for forced renumbering for further allocation The minimum allocation size of /28 may create a huge increase in the IPv4 routing table size. Forcing renumbering for subsequent allocations under this policy will somehow limit the growth of the routing table size by enabling the announcement of aggregated space. It is expected that the savings in routing table entries will outweigh the pain of forced renumbering. However, renumbering is never an easy task, so it should only be considered as last resort. it is expected that sparse allocation techniques will prevent the need of force renumbering for a fairly long time. Note: This policy proposal hints that the /10 should come out of the last /8 received by ARIN from IANA. However, it does not say so explicitly, leaving the final decision up to the ARIN staff. Timetable for implementation: As soon as ARIN gets its last /8 allocation from IANA. From info at arin.net Tue Jun 24 14:54:23 2008 From: info at arin.net (Member Services) Date: Tue, 24 Jun 2008 14:54:23 -0400 Subject: [arin-ppml] Policy Proposal: Extend Experimental Renewal Timeframe - AC did not accept Message-ID: <486142DF.60002@arin.net> On 19 June 2008, the ARIN Advisory Council (AC) concluded its review of the proposed policy "Extend Experimental Timeframe" and did not accept it as a formal policy proposal. The AC provided the following explanation of their decision: "The reason we do not accept it is because this does not address a direct need of the community." During the initial review period the AC may decide to: 1) Accept the proposal as a formal policy proposal as written. 2) Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. 3) Not accept the policy proposal. In the event that the AC decides not to accept the proposal, then the author may elect to use the petition process to advance the proposal. For petition details see the section called "Petition Process" in the ARIN Internet Resource Policy Evaluation Process which can be found at: http://www.arin.net/policy/irpep.html The deadline for the author to initiate a petition per the ARIN Internet Resource Policy Evaluation Process is 40 days prior to the meeting; the petition deadline for the October ARIN XXII Public Policy Meeting is 23:59 EDT, 5 September 2008. If the author chooses not to petition or the petition is unsuccessful, then the proposed policy is closed. If a petition is successful, then the proposal will be numbered and posted for discussion and presented at ARIN's Public Policy Meeting. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Extend Experimental Renewal Timeframe Author: Azinger and Dave Meyer Proposal Version: 1 Submission Date: 4 June 2008 Proposal type: Modify Policy term: Permanent Policy statement: This proposal is to modify section 11.4 in the Policy Manual to extend the experimental timeframe from one year to two years before having to re-justify the use of an experimental block. Rationale: Currently anyone who has an experimental block is required to re-justify his or her use after just one year. Reality shows that any true experiment in technical nature that addresses the internet architecture and routing will take at least two years given the constraints of time and the simple fact of working out what could be a bug in the theory and not a show stopper. This proposal just wishes to extend the timeframe one year so that time isn?t wasted on re-justification. The revision of 11.4 would read as follows: The Numbering Resources are allocated on a lease/license basis for a period of two years. The allocation can be renewed on application to ARIN providing information as per Detail One. The identity and details of the applicant and the allocated Numbering Resources will be published under the conditions of ARIN?s normal publication policy. At the end of the experiment, resources allocated under this policy will be returned to the available pool. Timetable for implementation: Immediate From info at arin.net Tue Jun 24 16:26:41 2008 From: info at arin.net (Member Services) Date: Tue, 24 Jun 2008 16:26:41 -0400 Subject: [arin-ppml] Policy Proposal: Equitable Distribution of IPv4 Resources before IPv4 Run Out - AC did not accept Message-ID: <48615881.3040505@arin.net> On 19 June 2008, the ARIN Advisory Council (AC) concluded its review of the proposed policy "Equitable Distribution of IPv4 Resources before IPv4 Run Out" and did not accept it as a formal policy proposal. The AC provided the following explanation of their decision: "The reason we do not accept it is because there is no community support for it." During the initial review period the AC may decide to: 1) Accept the proposal as a formal policy proposal as written. 2) Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. 3) Not accept the policy proposal. In the event that the AC decides not to accept the proposal, then the author may elect to use the petition process to advance the proposal. For petition details see the section called "Petition Process" in the ARIN Internet Resource Policy Evaluation Process which can be found at: http://www.arin.net/policy/irpep.html The deadline for the author to initiate a petition per the ARIN Internet Resource Policy Evaluation Process is 40 days prior to the meeting; the petition deadline for the October ARIN XXII Public Policy Meeting is 23:59 EDT, 5 September 2008. If the author chooses not to petition or the petition is unsuccessful, then the proposed policy is closed. If a petition is successful, then the proposal will be numbered and posted for discussion and presented at ARIN's Public Policy Meeting. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Equitable Distribution of IPv4 Resources before IPv4 Run out Author: Michael K. Smith Proposal Version: 1 Submission Date: 05/20/2008 Proposal type: new Policy term: permanent Policy statement: Upon receipt of the last allocation of IPv4 address space to ARIN from IANA, ARIN will reserve address space within the allocated block for Organizations within the defined ARIN Organizational Size determinations (Extra Small, Small, Large, Extra Large) based upon the utilization percentages for each group gathered from the statistics of the last two IANA allocations to ARIN. In order to make the allocation percentages mathematically feasible, the percentages will be rounded to the closest whole number and, subsequently, the the closest bit boundary for assignment the maximum allocation size for the Organization size as defined by ARIN. Once the final IANA allocation is received, ARIN will publish the allocation percentages that will be used for the final allocation to the PPML and ARIN website with the necessary documentation supporting the assignment of percentages. Rationale: Description: This policy is designed to allow Organizations of the various defined sizes to continue to receive address allocations from the last available space and is slanted towards ensuring that organizations within the Large, Small and Extra Small groups (and more specifically, the Small and Extra Small groups) are able to get additional IPv4 space at the end of the ARIN's ability to allocate such space. Given the statistics below, it is likely that Extra Large Organizations would get most or all of the last remaining space because given the amount they have been allocated to date. This policy would help ensure that other Organizations had a statistically equal opportunity to receive space as well. Example: Please see http://www.arin.net/statistics/index.html (Note: the statistics are generated from IP allocations from 2006 and 2007). This policy would require statistics to be limited to the previous 2 IANA allocations to ARIN.) The present distribution as of May 20th 2008 is: Extra Large: 83.11% Large: 6.75% Small: 9.00% Extra Small: 1.14% With this example, ARIN would reserve address space in the final IANA allocation according to those percentages, to the extent that it is mathematically possible within the existing range. In order to make the math work, rounding would give us: Extra Large: 83% Large: 7% Small: 9% Extra Small: 1% Who is affected: All ARIN Members will be affected by this policy. I assume that smaller providers will benefit from having some space available to them beyond where they would be with an organic allocation model, and the Extra Large Organizations would experience some pain because, using the model above, they would be excluded from being allocated 17% of the remaining space, even if they had all of the necessary justifications for receiving allocations from within that space. Policy Enforcement: ARIN staff will have to enforce this policy and ensure that allocations stay within the published percentages. Financial and Liability Implications: Financially, there may be additional resources required by ARIN Staff to allocate resources using this model. These resources might include application development, staff training and tracking of allocations based upon the model. ARIN may have legal liability should Organizations that were denied space according to the model decide to contest the legality of the policy in court. Timetable for implementation: Upon receipt of finall IANA allocation (roughly 2011). From Lee.Howard at stanleyassociates.com Tue Jun 24 17:35:44 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 24 Jun 2008 17:35:44 -0400 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <4860E0CA.2040709@dilkie.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40A576F3E@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lee Dilkie > do need to push hard for IPv6 adoption. What would that look like? Lee From owen at delong.com Tue Jun 24 17:50:29 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Jun 2008 14:50:29 -0700 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <4A3971AD-52EB-485C-9B50-403ED4590870@pch.net> References: <4860DE1A.3000808@dilkie.com> <70DE64CEFD6E9A4EB7FAF3A063141066A10874@mail> <6DE777FC-F2F9-4FE7-8A02-58F1531B167D@pch.net> <02E3721E-9D06-4F0D-8ED3-47CF896F026A@delong.com> <4A3971AD-52EB-485C-9B50-403ED4590870@pch.net> Message-ID: <511E5432-F081-4FAF-A648-FDF9AAFE1489@delong.com> On Jun 24, 2008, at 10:23 AM, Tom Vest wrote: > Hi Owen, > > Thanks for the question. > For the most part, the answer was anticipated by Paul. Yeah, that's one of the reasons I like having Paul on the BoT. He's quite good that way. > > If a policy like this gets approved, and the reserved pool is large > enough to last long enough so that no one -- no active IPv4-based > operator or outside speculator -- could even conceive of a time > horizon over which exploitation of the asymmetry/bottleneck > opportunity might be profitable, then perhaps this won't be a problem. > I originally proposed a /8. The current proposal is a /10. These would probably be handed out as /24-/28 sized chunks, so, I suspect that will at least get us past the point where others might be willing to migrate away from some portion of their IPv4 stuff into other solutions. > For that, the reserved pool would have to be big enough, at least, > to accommodate transitional resources for all new entrants, assuming > the fastest plausible rate of new entry, for the longest conceivable > transition to de-facto full IPv4-IPv6 substitutability -- the point > when everything important is transparently accessible by IPv6-only > networks. > I think a /8 would provide a comfortable cushion beyond this. A /10 will likely be more than enough space as well. I think we're talking about a 5 year period beyond IPv4 exhaustion maximum. This would accommodate at least 16,384 new provider-independent entrants during that time, and, likely substantially more, possibly as much as 256k new entrants. I believe that is well above any anticipated number in a 5 year timeframe. > To begin estimating that quantity, I could derive the historical new > entrant rate for the RIPE region, because I can distinguish the > initial allocations from the subsequent allocations -- but I would > have to defer to somebody else for the ARIN, et al rates... > At this point, the rates are probably relatively similar with RIPE's rate being slightly higher. > In either case, what would count as a plausible new entry rate for > the next (x) years, relative to the historical rates -- what is the > biggest bottleneck likely to be (address resources, routing > capacity, transport facilities, etc.)? And what's the largest > plausible (x) until de-facto substitutability is achieved, given (at > least) the strategic considerations above? > In my opinion x<=5 and max plausible rate is <2000/year with likely being closer to 200/year. Owen > TV > > On Jun 24, 2008, at 11:15 AM, Owen DeLong wrote: > >> Tom, >> Absent the recent policy proposal to create a reservation >> for IPv6 Transitional Technologies in the ARIN IPv4 free pool, >> I would agree with you. However, wouldn't that policy mitigate >> what you are saying below? (assuming it gets adopted) >> >> Owen >> >> On Jun 24, 2008, at 6:55 AM, Tom Vest wrote: >> >>> There is also the matter of asymmetrical dependence and bargaining >>> power (detailed ad nauseam last week). >>> >>> Unless something changes, on the day after free pool exhaustion and >>> every day thereafter, "incumbent" IPv4-based networks will be able >>> to >>> unilaterally decide whether/when they want to be transparently >>> interoperable with native IPv6 networks, and they will be able to >>> unilaterally act to make that possible, e.g., by going dual-stack, >>> renumbering, or operating a symmetrical 6/4 gateway. >>> >>> Unless something changes, on the day after free pool exhaustion and >>> every day thereafter, new IPv6-only networks will need to >>> interoperate >>> with the universe of incumbent IPv4 networks. However, they will NOT >>> be able to unilaterally act to make that possible as long as that >>> requires at least some IPv4, which at that point will only available >>> from those incumbent networks, or from "pure speculators". >>> >>> That asymmetry is what will drive the price of IPv4 up and up, and >>> that increasing profit potential and bargaining power -- which is >>> just >>> an artifact of the lingering IPv4 bottleneck between new IPv6 >>> networks >>> and everything still accessible only via IPv4 -- is what will >>> incentivize incumbent IPv4 networks/IPv4 dealers to delay their own >>> shift to transparent interoperability for as long as possible. >>> >>> Aspiring to be the last-mover will be the only rational strategy in >>> the environment that an IPv4 resource transfer market will create. >>> >>> But maybe rationality will take a holiday :-\ >>> >>> TV >>> >>> On Jun 24, 2008, at 9:21 AM, Kevin Kargel wrote: >>> >>>> Don't forget the fact that IPv6 is not yet a perfect or mature >>>> service. >>>> Delaying IPv6 implementation will avoid the costs involved with >>>> development and debugging of local networks while letting others do >>>> the >>>> dirty work. I am not advocating this, just recognizing a reality. >>>> The >>>> forward thinking administrators that want to make a difference in >>>> the >>>> world will jump in and get it done, the profit driven enterprises >>>> will >>>> sit back and wait until everything is easy or unavoidable. >>>> >>>> >>>> -----Original Message----- >>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- >>>> bounces at arin.net] >>>> On >>>> Behalf Of Lee Dilkie >>>> Sent: Tuesday, June 24, 2008 6:44 AM >>>> To: michael.dillon at bt.com >>>> Cc: ppml at arin.net >>>> Subject: Re: [arin-ppml] Q1 - ARIN address transferpolicy: >>>> whythetriggerdate? >>>> >>>> >>>> michael.dillon at bt.com wrote: >>>>>> As with many other technologies, there is a substantial last- >>>>>> mover >>>>>> advantage to going dual-stack or single-v6. >>>>>> >>>>> >>>>> On what do you base this opinion? >>>>> >>>>> --Michael Dillon >>>>> >>>>> >>>> Moore's Law, one would think. Delaying purchase of networking >>>> equipment >>>> will yield better performance for lower cost. >>> >>> >>> _______________________________________________ >>> 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 the ARIN Member Services Help Desk at info at arin.net >>> if you experience any issues. >> From Lee at dilkie.com Tue Jun 24 20:56:50 2008 From: Lee at dilkie.com (Lee Dilkie) Date: Tue, 24 Jun 2008 20:56:50 -0400 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40A576F3E@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40A576F3E@CL-S-EX-1.stanleyassociates.com> Message-ID: <486197D2.5010802@dilkie.com> Howard, W. Lee wrote: > > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lee Dilkie >> > > >> do need to push hard for IPv6 adoption. >> > > What would that look like? > > Lee > Well, at the beginning, it would be something small, presumably. On the order of 5 to 10 pounds (2.5 to 5 Kilo's), and pink.. Oh yes, it will cry a lot. But folks on this list should be used to that ;) Seriously folks. Dual stack is the only reasonable way to both get IPv6 deployed *and* maintain legacy networking with IPv4-only hosts/applications. Your recently passed proposal to set aside IPv4 space for yet-to-be-developed v4<->v6 translators is mostly wishing for magic to happen. Not to say there won't be some application translators written but for the majority of apps, dual stack is the most reasonable solution going forward. That, I think, is why the IETF abandoned NAT-PT and came out swinging hard for dual stack. And for dual-stack to happen, we need to force the issue because it seems pretty obvious that it isn't going to happen anytime soon if we just sit and wait for folks to get on board with their good intentions. It hasn't happened yet and we've been at this for how many years now... And we are running out of time. We need to do 2 things. 1. Give out IPv6 allocations with each IPv4 allocation with instructions to use it. 2. Check that it gets used before giving out any more allocations. And by used, I mean, made available to downstream customers if applicable. There you go, no excuses, deploy dual stack or get no more allocations. once everybody "gets it", I think you'll see IPv6 connectivity being rolled out real fast, everywhere. All these big consumers of ip addresses are very smart business folks, working within a set of rules and regulations to get their job done is nothing new, if everyone has to do it, it's simply table stakes. -lee From mueller at syr.edu Wed Jun 25 05:21:28 2008 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 25 Jun 2008 05:21:28 -0400 Subject: [arin-ppml] Linking IPv4 allocations to IPv6 In-Reply-To: <486197D2.5010802@dilkie.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40A576F3E@CL-S-EX-1.stanleyassociates.com> <486197D2.5010802@dilkie.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0DAD7@SUEXCL-02.ad.syr.edu> Time to change the header, folks. Just some observations: The idea of linking v4 allocations to v6 deployment is a departure (gasp) from "needs-based assessment." You are saying that people can demonstrate need for v4 addresses and not get them if they don't also deploy dual stack. Seems also to require heavier operational monitoring by ARIN. How would one define "gets used?" > -----Original Message----- > And we are running out of time. We need to do 2 things. > > 1. Give out IPv6 allocations with each IPv4 allocation with instructions > to use it. > 2. Check that it gets used before giving out any more allocations. And > by used, I mean, made available to downstream customers if applicable. > > There you go, no excuses, deploy dual stack or get no more allocations. > once everybody "gets it", I think you'll see IPv6 connectivity being > rolled out real fast, everywhere. All these big consumers of ip > addresses are very smart business folks, working within a set of rules > and regulations to get their job done is nothing new, if everyone has to > do it, it's simply table stakes. > > -lee From mueller at syr.edu Wed Jun 25 05:48:55 2008 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 25 Jun 2008 05:48:55 -0400 Subject: [arin-ppml] Should ARIN be able to buy IPv4 addresses on the market? Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0DAD9@SUEXCL-02.ad.syr.edu> A thought inspired by reading Tom Vest's hand-wringing^D er, projections of the future of an IPv4 transfer market -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Wed Jun 25 06:38:40 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 25 Jun 2008 11:38:40 +0100 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: <60600.1214317843@sa.vix.com> Message-ID: > > As for the cost benefit issue, sometimes you just have to see the > > writing on the wall and realize that you will have to spend > money sooner or later. ... > > alas, not in america for the last couple of decades. it's > all about current quarter or in-year revenue and expense. This is a global disease known as MBA that inflicts most countries. > the most that many large companies can do at this point is > make sure they know what they will do at RIR runout, and > trigger that plan at IANA runout. that may not sound like > much but it's way more than medium-to-small companies will > do, which is: sit tight, wait for an ipv6 internet to appear > through the efforts of larger better-funded companies, and > assume that the dribs and drabs of ipv4 space needed by small > companies will not be of any interest to the large companies, > so feel "safe". Why do you feel it will be different from the commercialization of the Internet? In that era, the large telcos were the first to do something with IPv4 in the lab, but they were outrun by the smaller companies that got a product to market as quickly as they could. In the end, the large telcos did get their Internet services rolled out, and they mostly ended up buying the small fry. Why won't the IPv6 wave start with smaller more nimble companies who are not afraid of rolling out an IPv4-IPv6 gateway service that has a bugs? > in this part of the analysis, there's good symmetry between > "can afford to be an early mover" and "is so large and with > so much organizational inertia that being a late mover would > be fatal". in other words the smaller entities who can't > afford to invest in ipv6 until there's an in-year or > in-quarter motive to do so, are also the ones who can do so > the quickest when their time comes, and the "dribs and drabs" > of ipv4 space that the big guys won't be able to use, will > tide the little guys over just fine. Fair enough. But this implies that the small guys should not be waiting for the big guys (aka upstreams) to take the first steps. In fact, there may be a business case for IPv6 peering over GRE tunnels through an IPv4 upstream network as one element in a large bag of tricks. --Michael Dillon From mueller at syr.edu Wed Jun 25 07:51:59 2008 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 25 Jun 2008 07:51:59 -0400 Subject: [arin-ppml] Legacy RSAs In-Reply-To: <485AD159.1030701@arin.net> References: <485AD159.1030701@arin.net> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0DADB@SUEXCL-02.ad.syr.edu> > -----Original Message----- > > To date, there have been 92 organizations that have signed ARIN's Legacy > RSA since it was introduced on October 31, 2007. > Is it true that there are 33,000 legacy allocations out there in the ARIN region? Forgive me if that number is way off but I can't find any authoritative number on that and would like to know. --MM From michael.dillon at bt.com Wed Jun 25 08:04:01 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 25 Jun 2008 13:04:01 +0100 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40A576F3E@CL-S-EX-1.stanleyassociates.com> Message-ID: > > do need to push hard for IPv6 adoption. > > What would that look like? It would not look like lobbying or promotion. One thing that is within ARIN's scope would be to operate a public issue-tracking system for IPv6. This would allow anyone to raise an issue that is making it impossible or hard to deploy IPv6. The tracker would allow reporting of progress towards a solution and also help to collect information that will be useful to deployers. Some of the issues will name names, i.e. vendor X's box fails to properly handle situation Y or Windows Vista does not do DNS queries over IPv6. It would have to be moderated so that all issues are factual and clearly stated. I believe that the existence of such a tracker would lead to more people working on fixing the issues sooner. --Michael Dillon From jcurran at istaff.org Wed Jun 25 08:35:53 2008 From: jcurran at istaff.org (John Curran) Date: Wed, 25 Jun 2008 08:35:53 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: whythetriggerdate? In-Reply-To: References: Message-ID: At 1:04 PM +0100 6/25/08, wrote: > > > What would that look like? > >It would not look like lobbying or promotion. > >One thing that is within ARIN's scope would be to operate a public >issue-tracking system for IPv6. This would allow anyone to raise an >issue that is making it impossible or hard to deploy IPv6. The tracker >would allow reporting of progress towards a solution and also help to >collect information that will be useful to deployers. Some of the issues >will name names, i.e. vendor X's box fails to properly handle situation >Y or Windows Vista does not do DNS queries over IPv6. It would have to >be moderated so that all issues are factual and clearly stated. Michael - Presently we're swimming in web sites full of IPv6 deployment advice: http://www.getipv6.info http://www.civil-tongue.net/clusterf http://www.ipv6tf.org/ http://go6.net/ipv6-6bone/v6ops/ http://playground.sun.com/ipv6/ To quoteth Randy: "there seem to be more folk working on v6 wikis than vendors working on fully functional v6/dual-stack implementations." If there is a need for ARIN to do more in this space, then let's discuss it, but I do think it's important to consider what other initiatives are already underway. /John From kkargel at polartel.com Wed Jun 25 09:46:14 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 25 Jun 2008 08:46:14 -0500 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <486127B3.8010504@internap.com> References: <86skv39h6u.fsf@seastrom.com> <61567.1214319053@sa.vix.com> <70DE64CEFD6E9A4EB7FAF3A063141066A10878@mail> <486127B3.8010504@internap.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A1087B@mail> But those are not the only choices. Those are just the only choices that allow us (network businesses) to take advantage of the situation to take even more money. As responsible administrators we are working to maintain network operations, even through the 4-6 transition. We (network businesses) should do this without raping our customers any more than absolutely necessary. I believe we (network businesses) are for the most part doing that. Perhaps working at a Co-op my viewpoint is skewed from those of you working for a corporation, but I still have a hard time with accepting the concept that an artificial market is good, except as a profit venture. ARIN is doing a great job. I cannot express my admiration sufficiently for the way everything has worked thus far, even when I have encountered frustrations along the way. The concept of minimalist controls and governance they (we) have adopted thus far is brave, admirable and imminently functional. Have some faith in the system and the community. Cooperative anarchy has worked well for the internet up till now. I believe it will continue to serve in the future. People will continue to work together so that networks can interoperate, and will find creative and working solutions to problems when they are needed. I am trepiditious that should we (ARIN) create an artificial market that the government may see it as a commodity and emplace the controls and restrictions governing those (for the "good of the people"). Going along with that should the government "try" to govern the IP market then they will need to pay for that action somehow. The primary means the government has of paying for things is taxes. I don't know about you but I really don't want any new taxes. -----Original Message----- From: Scott Leibrand [mailto:sleibrand at internap.com] Sent: Tuesday, June 24, 2008 11:58 AM To: Kevin Kargel Cc: ppml at arin.net Subject: Re: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? Kevin Kargel wrote: > I strongly oppose any effort to create an artificial IP commodities > market. I know it is a philosophical stand and will draw many flames, > but the Americans who most benefit from access to internet are the low > to middle income groups, and adding even small charges to that access > could take internet out of their grasp. Anything we can do to prevent > raising that cost will benefit society. While we are all more > comfortable than many families, please don't forget those who have to > make hard decisions budgeting for residential information services. Which will raise costs to those groups more: denying their ISPs the ability to get new IPv4 addresses? Or allowing them to make a choice of whether or not to get addresses on the transfer market? If you're not sure, consider an analogy: which would it be better to tell a low-income family? "I'm sorry, gas is too scarce, so we stopped selling it here: you'll need to ride the bus." or "I'm sorry gas is so expensive: if it works better for you, you might want to consider riding the bus instead." -Scott From Lee at dilkie.com Wed Jun 25 09:48:32 2008 From: Lee at dilkie.com (Lee Dilkie) Date: Wed, 25 Jun 2008 09:48:32 -0400 Subject: [arin-ppml] Linking IPv4 allocations to IPv6 In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0DAD7@SUEXCL-02.ad.syr.edu> References: <369EB04A0951824ABE7D8BAC67AF9BB40A576F3E@CL-S-EX-1.stanleyassociates.com> <486197D2.5010802@dilkie.com> <7663C7E01D8E094989CA62F0B0D21CD901E0DAD7@SUEXCL-02.ad.syr.edu> Message-ID: <48624CB0.6080106@dilkie.com> Milton L Mueller wrote: > Time to change the header, folks. > Just some observations: The idea of linking v4 allocations to v6 > deployment is a departure (gasp) from "needs-based assessment." You are > saying that people can demonstrate need for v4 addresses and not get > them if they don't also deploy dual stack. Seems also to require heavier > operational monitoring by ARIN. How would one define "gets used?" > > > Essentially, yes. If you need IPv4 and don't want to also deploy IPv6 with it then you are ignoring the common good. Future IPv6-only hosts will be unable to communicate with your newly deployed IPv4 hosts. Why would we want to allow such selfish behaviour? And I don't see this as a departure of "needs based" at all. We're simply telling you, "if you need IPv4 then you also need IPv6". It's really no different than "if you need to build a power plant, then you need to build an emission scrubber to prevent acid rain". It's all about common good. It is good for all of us if these last IPv4 allocations also drive up IPv6 deployment, because we need that to get demand started (the "network effect" that someone alluded to earlier). I'll let others define "gets used", ARIN seems to have a handle on ensuring allocations are utilized properly. -lee From michael.dillon at bt.com Wed Jun 25 10:22:22 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 25 Jun 2008 15:22:22 +0100 Subject: [arin-ppml] Q1 - ARIN address transfer policy: whythetriggerdate? In-Reply-To: Message-ID: > >It would not look like lobbying or promotion. > Presently we're swimming in web sites full of IPv6 deployment advice: > > http://www.getipv6.info Agreed. There is plenty of advice, lobbying and promotion already available. > If there is a need for ARIN to do more in this space, then > let's discuss it, but I do think it's important to consider > what other initiatives are already underway. That's why we need to identify a gap in what is already out there and then fill that gap, if it is within ARIN's scope. In the modern world, any open source development and deployment effort focuses a team of developers around an issue-tracking system. But IPv6 is so amorphous that there is no such team, and even though IPv6 was originally developed in the IETF, it would be a stretch to say that the IETF "owns" it. In truth, the community owns IPv6 and the community has to get an issue tracker in place to focus a community of developers. ISSUES are anything that blocks, delays or limits IPv6 deployments. DEVELOPERS are anyone who has a role to play in analyzing, documenting, and resolving these ISSUES. An ISSUE TRACKER is a special piece of software based around a database. Although many open-source issue trackers now include things like wikis, forums, and mailing list archives with the core software, I'm only suggesting that ARIN install and operate the core issue tracking function. We already have a wiki for IPv6 and if a mailing list is needed, we already have the tool for that too. Fundamentally, this sort of thing is within the scope of ARIN's charter. Since the wikis that you listed are less focused than what I am proposing, some issues would come from information on those wikis. And as issues are resolved, I would expect folks to mine the information from the issue tracker and put it on the wikis. In addition, ARIN itself could report regular stats on the number of issues and the various severity levels. --Michael Dillon From Lee.Howard at stanleyassociates.com Wed Jun 25 10:33:34 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 25 Jun 2008 10:33:34 -0400 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <486197D2.5010802@dilkie.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40A5772B2@CL-S-EX-1.stanleyassociates.com> > And we are running out of time. We need to do 2 things. > > 1. Give out IPv6 allocations with each IPv4 allocation with > instructions to use it. > 2. Check that it gets used before giving out any more > allocations. And by used, I mean, made available to > downstream customers if applicable. This is interesting. Have you thought about how to evaluate whether addresses have been "used" on the IPv6 archipelago? How available does it have to be? I'm not challenging the idea, just trying to draw out more detail. Would a proposal like this http://www.arin.net/policy/proposals/2007_16.html accomplish this goal? Lee From jmaimon at chl.com Wed Jun 25 10:36:05 2008 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 25 Jun 2008 10:36:05 -0400 Subject: [arin-ppml] Linking IPv4 allocations to IPv6 In-Reply-To: <48624CB0.6080106@dilkie.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40A576F3E@CL-S-EX-1.stanleyassociates.com> <486197D2.5010802@dilkie.com> <7663C7E01D8E094989CA62F0B0D21CD901E0DAD7@SUEXCL-02.ad.syr.edu> <48624CB0.6080106@dilkie.com> Message-ID: <486257D5.1030309@chl.com> Lee Dilkie wrote: > > Seriously folks. > > Dual stack is the only reasonable way to both get IPv6 deployed *and* > maintain legacy networking with IPv4-only hosts/applications. > > Milton L Mueller wrote: >> Time to change the header, folks. >> Just some observations: The idea of linking v4 allocations to v6 >> deployment is a departure (gasp) from "needs-based assessment." You are >> saying that people can demonstrate need for v4 addresses and not get >> them if they don't also deploy dual stack. Seems also to require heavier >> operational monitoring by ARIN. How would one define "gets used?" >> >> >> > Essentially, yes. If you need IPv4 and don't want to also deploy IPv6 > with it then you are ignoring the common good. Future IPv6-only hosts > will be unable to communicate with your newly deployed IPv4 hosts. Aside from the many reasons why this would never fly and likely isnt a very good idea in the first place, it doesnt accomplish the stated objective or anything else positive for that matter. The only way an ipv6 only host can communicate with the entire network of interest is with translations and gateways. This is because it simply hasnt and wont happen anytime soon that every ipv4 node of interest will also have an ipv6 address. I would lay odds it isnt going to happen for 5-10 years either, if ever. No matter what runs out. Do you even think there are enough netop man hours to ipv6 every single network and node starting from today until IANA runout? So dual stack is a dead end concept that hasnt and will never fly. It is only required today because ipv6 doesnt actually connect you to a network with anyone of interest on it. Dual stack is a policy of failure. It is a failure to make ipv6 compelling and useful on its own. Not only does ipv6 need to be compelling and useful in its own right, it must also provide at least the same level of network access as v4nat. And for a nitpick, any such policy would actually have to require that all addressed nodes from the allocations be dual stack to have any hope for a change at all. So the policy would have to require that the requesting org dual stack all hosts to be addressed from the new allocation and get ipv6 transit, which last I checked is barely available most places. As for policy driving IPv6, I think that ipv6 allocations should be made available for the taking for every single asn originating ipv4 prefixes and it should be large enough that they will likely not come back again. A /32 for every AS. No questions asked. We have at least half a billion to hand out, I am sure we could spare 40-50k. In fact, the allocations should come from a range that includes the AS number. Once they have it, they might use it. Tunneled or not. But making ARIN into any more "bad cop" than absolutely necessary is a Really Bad Idea. Joe From paul at vix.com Wed Jun 25 11:15:56 2008 From: paul at vix.com (Paul Vixie) Date: Wed, 25 Jun 2008 15:15:56 +0000 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate? In-Reply-To: Your message of "Wed, 25 Jun 2008 11:38:40 +0100." References: Message-ID: <21164.1214406956@sa.vix.com> > Why do you feel it will be different from the commercialization of the > Internet? In that era, the large telcos were the first to do something with > IPv4 in the lab, but they were outrun by the smaller companies that got a > product to market as quickly as they could. In the end, the large telcos did > get their Internet services rolled out, and they mostly ended up buying the > small fry. this is a different history than the one i lived. when uunet was founded, the part of at&t research that had a connection to the internet, was not involved in productizing the internet, and at&t had no commercial interest in the internet. at&t wasn't outrun, they weren't in the race at all in any form. years later when i was operating CIX, i had to tell several large telcos who joined up, about the difference between peering and transit, and how it was that their CIX connection wasn't the only one they were going to need. and then there was the day i explained to QWEST why they couldn't use RIP, and what BGP was. (yes, this was the blind leading the blind, but there i was.) > Why won't the IPv6 wave start with smaller more nimble companies who are not > afraid of rolling out an IPv4-IPv6 gateway service that has a bugs? that's a new topic. for one, if that's how things progress, it won't matter to the end result, since there will be no planned ipv6-only networks until the larger networks are running dual-stack. for two, the larger networks are the ones who can predict their address space consumption accurately and will know well in advance when the ipv4 pool will stop being able to support their growth. but let's stay on topic. > > in this part of the analysis, there's good symmetry between "can afford to > > be an early mover" and "is so large and with so much organizational > > inertia that being a late mover would be fatal". in other words the > > smaller entities who can't afford to invest in ipv6 until there's an > > in-year or in-quarter motive to do so, are also the ones who can do so the > > quickest when their time comes, and the "dribs and drabs" of ipv4 space > > that the big guys won't be able to use, will tide the little guys over > > just fine. > > Fair enough. But this implies that the small guys should not be waiting for > the big guys (aka upstreams) to take the first steps. In fact, there may be > a business case for IPv6 peering over GRE tunnels through an IPv4 upstream > network as one element in a large bag of tricks. there just is no in-year or in-quarter motivation for a small/medium sized network to discard the last-mover advantage given the thin margins in this industry. adopting dual-stack depends on a "war chest". From mueller at syr.edu Wed Jun 25 12:00:33 2008 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 25 Jun 2008 12:00:33 -0400 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <4A3971AD-52EB-485C-9B50-403ED4590870@pch.net> References: <4860DE1A.3000808@dilkie.com><70DE64CEFD6E9A4EB7FAF3A063141066A10874@mail><6DE777FC-F2F9-4FE7-8A02-58F1531B167D@pch.net><02E3721E-9D06-4F0D-8ED3-47CF896F026A@delong.com> <4A3971AD-52EB-485C-9B50-403ED4590870@pch.net> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0DAFD@SUEXCL-02.ad.syr.edu> Tom: I'm still waiting for an explanation of how your theory that "IPv4 transfer markets will give incumbents unbreakable long term market power" squares with the fact that ETNO, the organization of telecom incumbents in Europe, has come out strongly against IPv4 address transfer markets.** And explain to me again how the absence of a market guarantees "transitional resources for all new entrants?" I thought it just meant the damn things ran out and no one got them. --MM **When the .net TLD was up for renewal, the OECD recommended auctioning it off. Some people objected that such a procedure would mean that .net would surely be re-assigned to VeriSign because "it had the most money." Then, VeriSign came out publicly with a news release strongly opposing auctions and insisting that only a beauty contest oriented around "stability and security" could possibly assign .net to the right operator. And what do you know, a few months later .net was reassigned to VeriSign, because of its "importance to the security of the Internet infrastructure..." Want other examples like this? They exist. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Tom Vest > Sent: Tuesday, June 24, 2008 1:23 PM > To: Owen DeLong > Cc: ppml at arin.net > Subject: Re: [arin-ppml] Q1 - ARIN address transferpolicy: > whythetriggerdate? > > Hi Owen, > > Thanks for the question. > For the most part, the answer was anticipated by Paul. > If a policy like this gets approved, and the reserved pool is large > enough to last long enough so that no one -- no active IPv4-based > operator or outside speculator -- could even conceive of a time > horizon over which exploitation of the asymmetry/bottleneck > opportunity might be profitable, then perhaps this won't be a problem. > > For that, the reserved pool would have to be big enough, at least, to > accommodate transitional resources for all new entrants, assuming the > fastest plausible rate of new entry, for the longest conceivable > transition to de-facto full IPv4-IPv6 substitutability -- the point > when everything important is transparently accessible by IPv6-only > networks. > > To begin estimating that quantity, I could derive the historical new > entrant rate for the RIPE region, because I can distinguish the > initial allocations from the subsequent allocations -- but I would > have to defer to somebody else for the ARIN, et al rates... > > In either case, what would count as a plausible new entry rate for the > next (x) years, relative to the historical rates -- what is the > biggest bottleneck likely to be (address resources, routing capacity, > transport facilities, etc.)? And what's the largest plausible (x) > until de-facto substitutability is achieved, given (at least) the > strategic considerations above? > > TV > > On Jun 24, 2008, at 11:15 AM, Owen DeLong wrote: > > > Tom, > > Absent the recent policy proposal to create a reservation > > for IPv6 Transitional Technologies in the ARIN IPv4 free pool, > > I would agree with you. However, wouldn't that policy mitigate > > what you are saying below? (assuming it gets adopted) > > > > Owen > > > > On Jun 24, 2008, at 6:55 AM, Tom Vest wrote: > > > >> There is also the matter of asymmetrical dependence and bargaining > >> power (detailed ad nauseam last week). > >> > >> Unless something changes, on the day after free pool exhaustion and > >> every day thereafter, "incumbent" IPv4-based networks will be able to > >> unilaterally decide whether/when they want to be transparently > >> interoperable with native IPv6 networks, and they will be able to > >> unilaterally act to make that possible, e.g., by going dual-stack, > >> renumbering, or operating a symmetrical 6/4 gateway. > >> > >> Unless something changes, on the day after free pool exhaustion and > >> every day thereafter, new IPv6-only networks will need to > >> interoperate > >> with the universe of incumbent IPv4 networks. However, they will NOT > >> be able to unilaterally act to make that possible as long as that > >> requires at least some IPv4, which at that point will only available > >> from those incumbent networks, or from "pure speculators". > >> > >> That asymmetry is what will drive the price of IPv4 up and up, and > >> that increasing profit potential and bargaining power -- which is > >> just > >> an artifact of the lingering IPv4 bottleneck between new IPv6 > >> networks > >> and everything still accessible only via IPv4 -- is what will > >> incentivize incumbent IPv4 networks/IPv4 dealers to delay their own > >> shift to transparent interoperability for as long as possible. > >> > >> Aspiring to be the last-mover will be the only rational strategy in > >> the environment that an IPv4 resource transfer market will create. > >> > >> But maybe rationality will take a holiday :-\ > >> > >> TV > >> > >> On Jun 24, 2008, at 9:21 AM, Kevin Kargel wrote: > >> > >>> Don't forget the fact that IPv6 is not yet a perfect or mature > >>> service. > >>> Delaying IPv6 implementation will avoid the costs involved with > >>> development and debugging of local networks while letting others do > >>> the > >>> dirty work. I am not advocating this, just recognizing a reality. > >>> The > >>> forward thinking administrators that want to make a difference in > >>> the > >>> world will jump in and get it done, the profit driven enterprises > >>> will > >>> sit back and wait until everything is easy or unavoidable. > >>> > >>> > >>> -----Original Message----- > >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > >>> On > >>> Behalf Of Lee Dilkie > >>> Sent: Tuesday, June 24, 2008 6:44 AM > >>> To: michael.dillon at bt.com > >>> Cc: ppml at arin.net > >>> Subject: Re: [arin-ppml] Q1 - ARIN address transferpolicy: > >>> whythetriggerdate? > >>> > >>> > >>> michael.dillon at bt.com wrote: > >>>>> As with many other technologies, there is a substantial last-mover > >>>>> advantage to going dual-stack or single-v6. > >>>>> > >>>> > >>>> On what do you base this opinion? > >>>> > >>>> --Michael Dillon > >>>> > >>>> > >>> Moore's Law, one would think. Delaying purchase of networking > >>> equipment > >>> will yield better performance for lower cost. > >> > >> > >> _______________________________________________ > >> 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 the ARIN Member Services Help Desk at info at arin.net > >> if you experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From cgrundemann at gmail.com Wed Jun 25 12:04:15 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 25 Jun 2008 10:04:15 -0600 Subject: [arin-ppml] Linking IPv4 allocations to IPv6 In-Reply-To: <486257D5.1030309@chl.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40A576F3E@CL-S-EX-1.stanleyassociates.com> <486197D2.5010802@dilkie.com> <7663C7E01D8E094989CA62F0B0D21CD901E0DAD7@SUEXCL-02.ad.syr.edu> <48624CB0.6080106@dilkie.com> <486257D5.1030309@chl.com> Message-ID: <443de7ad0806250904i7f2f0479t954e2be2375194e0@mail.gmail.com> On Wed, Jun 25, 2008 at 8:36 AM, Joe Maimon wrote: > > > Lee Dilkie wrote: >> > > Seriously folks. > > > > Dual stack is the only reasonable way to both get IPv6 deployed *and* > > maintain legacy networking with IPv4-only hosts/applications. > > >> Milton L Mueller wrote: >>> Time to change the header, folks. >>> Just some observations: The idea of linking v4 allocations to v6 >>> deployment is a departure (gasp) from "needs-based assessment." You are >>> saying that people can demonstrate need for v4 addresses and not get >>> them if they don't also deploy dual stack. Seems also to require heavier >>> operational monitoring by ARIN. How would one define "gets used?" >>> >>> >>> >> Essentially, yes. If you need IPv4 and don't want to also deploy IPv6 >> with it then you are ignoring the common good. Future IPv6-only hosts >> will be unable to communicate with your newly deployed IPv4 hosts. > > Aside from the many reasons why this would never fly and likely isnt a > very good idea in the first place, it doesnt accomplish the stated > objective or anything else positive for that matter. Moving towards a more truly 'use-able' IPv6 Internet is very positive, anything that anyone can do to encourage participation is very positive imo. > > The only way an ipv6 only host can communicate with the entire network > of interest is with translations and gateways. This is because it simply > hasnt and wont happen anytime soon that every ipv4 node of interest will > also have an ipv6 address. > > I would lay odds it isnt going to happen for 5-10 years either, if ever. > > No matter what runs out. > > Do you even think there are enough netop man hours to ipv6 every single > network and node starting from today until IANA runout? > > So dual stack is a dead end concept that hasnt and will never fly. It is > only required today because ipv6 doesnt actually connect you to a > network with anyone of interest on it. > > Dual stack is a policy of failure. It is a failure to make ipv6 > compelling and useful on its own. I could not disagree more. Dual stack is the correct approach to the v4 to v6 migration. Translations and gateways are the concepts that we are being forced to adopt because so many kept there eyes shut tight about IPv6 for so long. > > Not only does ipv6 need to be compelling and useful in its own right, it > must also provide at least the same level of network access as v4nat. And the more people who use dual stack in the interim/transition period, the more network access there is via v6. Which makes it easier for others to move to IPv6 and so on. > > And for a nitpick, any such policy would actually have to require that > all addressed nodes from the allocations be dual stack to have any hope > for a change at all. So the policy would have to require that the > requesting org dual stack all hosts to be addressed from the new > allocation and get ipv6 transit, which last I checked is barely > available most places. > > As for policy driving IPv6, I think that ipv6 allocations should be made > available for the taking for every single asn originating ipv4 prefixes > and it should be large enough that they will likely not come back again. > > A /32 for every AS. No questions asked. We have at least half a billion > to hand out, I am sure we could spare 40-50k. In fact, the allocations > should come from a range that includes the AS number. > > Once they have it, they might use it. Tunneled or not. > > But making ARIN into any more "bad cop" than absolutely necessary is a > Really Bad Idea. I think that there could be some compromise reached between forcing every node on someones network to be dual stacked and just giving out ipv6 space to everyone with no requirement for use. Maybe (as you suggest) ARIN should give out a /32 (or other block) to every AS, no questions asked. Then, based on the knowledge that they have the v6 space, you build some requirements for requesting more v4 space. I think most will agree that requiring every host to be dual stacked would both provide the most benefit and also be virtually impossible to enforce. Maybe instead, the requirement should be simply advertising the v6 block. This would require the organization to get some sort of ipv6 transit service and would thus encourage them to actually utilize it. It would also help push the demand for v6 transit. Another possible requirement is that the organizations public website have a AAAA record from the previously assigned /32 (or whatever size block). I think that these two requirements are easily measurable and would noticeably affect ipv6 adoption rates. > > 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. > -- Chris Grundemann www.linkedin.com/in/cgrundemann From Lee.Howard at stanleyassociates.com Wed Jun 25 12:59:15 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 25 Jun 2008 12:59:15 -0400 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0DAFD@SUEXCL-02.ad.syr.edu> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40A5774E1@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller > Sent: Wednesday, June 25, 2008 12:01 PM > To: Tom Vest; Owen DeLong > Cc: ppml at arin.net > Subject: Re: [arin-ppml] Q1 - ARIN address transferpolicy: > whythetriggerdate? > > Tom: > I'm still waiting for an explanation of how your theory that > "IPv4 transfer markets will give incumbents unbreakable long > term market power" squares with the fact that ETNO, the > organization of telecom incumbents in Europe, has come out > strongly against IPv4 address transfer markets.** I don't presume to speak for Tom or to interpret ETNO, but I can offer some theories. Predictability is of great value to large companies. ETNO explains. . . -- Principle 2 Development of a market for IP addresses (legal or illegal) should be discouraged. NB: This is intended to avoid any disruptive impact on Public address allocation processes that are well understood and accepted, and embodies fairness. It also maintains the public nature of this address resource. http://www.etno.be/Portals/34/ETNO%20Documents/Information%20Society%20i 2010/CP082%20-%20NANI%20CP%20IPv4%20Exhaust.pdf -- I would further speculate that pricing stability in particular is valuable to large companies, and if they began having to pay (possibly at inflated speculator prices) for a number resource that is currently negligibly cheap, it would be disruptive. > **When the .net TLD was up for renewal, the OECD recommended > auctioning it off. Some people objected that such a procedure > would mean that .net would surely be re-assigned to VeriSign > because "it had the most money." > Then, VeriSign came out publicly with a news release strongly > opposing auctions and insisting that only a beauty contest > oriented around "stability and security" could possibly > assign .net to the right operator. And what do you know, a > few months later .net was reassigned to VeriSign, because of > its "importance to the security of the Internet infrastructure..." If VeriSign would win either way, why would they choose the expensive auction path? I don't mean to suggest the I endorse either ETNO or VeriSign positions or actions. I only mean to offer the perspective that it is possible to hold two viewpoints without being inconsistent. Lee From sleibrand at internap.com Wed Jun 25 13:23:33 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 25 Jun 2008 10:23:33 -0700 Subject: [arin-ppml] Q1 - ARIN address transfer policy In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A1087B@mail> References: <86skv39h6u.fsf@seastrom.com> <61567.1214319053@sa.vix.com> <70DE64CEFD6E9A4EB7FAF3A063141066A10878@mail> <486127B3.8010504@internap.com> <70DE64CEFD6E9A4EB7FAF3A063141066A1087B@mail> Message-ID: <48627F15.40601@internap.com> Kevin Kargel wrote: > But those are not the only choices. Those are just the only choices > that allow us (network businesses) to take advantage of the situation to > take even more money. Can you elaborate on what the other options are, and how they would work? > Have some faith in the system and the community. Cooperative anarchy > has worked well for the internet up till now. I believe it will > continue to serve in the future. People will continue to work together > so that networks can interoperate, and will find creative and working > solutions to problems when they are needed. I suspect that one of those creative solutions will be to find and use ways to get around ARIN's restrictions on IPv4 address transfers. In that case, do you think we should sue such innovators, or modify our policies to allow them to do what's needed? 2008-2 does not "create an artificial market". It is simply a partial deregulation that relaxes transfer policy for IPv4 addresses, and gives the community more flexibility to deal with free pool exhaustion. > I am trepiditious that should we (ARIN) create an artificial market that > the government may see it as a commodity and emplace the controls and > restrictions governing those (for the "good of the people"). Going > along with that should the government "try" to govern the IP market then > they will need to pay for that action somehow. The primary means the > government has of paying for things is taxes. I don't know about you > but I really don't want any new taxes. Generally the US government tends to keep a hands off approach unless/until there is a major market failure. For an example, look at the history of banking regulation prior to 1929. And as a specific data point to this concern, it's worth noting that ARIN's Counsel has said that he does not consider government regulation to be a risk of adopting 2008-2. My own opinion is that we're more likely to get the government involved if we maintain current policy and try to crack down on transfer attempts than if we put in place a community-consensus-based policy setting out guidelines for allowing such transfers. -Scott > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand at internap.com] > Sent: Tuesday, June 24, 2008 11:58 AM > To: Kevin Kargel > Cc: ppml at arin.net > Subject: Re: [arin-ppml] Q1 - ARIN address transferpolicy: > whythetriggerdate? > > Kevin Kargel wrote: > >> I strongly oppose any effort to create an artificial IP commodities >> market. I know it is a philosophical stand and will draw many flames, > >> but the Americans who most benefit from access to internet are the low > >> to middle income groups, and adding even small charges to that access >> could take internet out of their grasp. Anything we can do to prevent > >> raising that cost will benefit society. While we are all more >> comfortable than many families, please don't forget those who have to >> make hard decisions budgeting for residential information services. > > Which will raise costs to those groups more: denying their ISPs the > ability to get new IPv4 addresses? Or allowing them to make a choice of > whether or not to get addresses on the transfer market? > > If you're not sure, consider an analogy: which would it be better to > tell a low-income family? "I'm sorry, gas is too scarce, so we stopped > selling it here: you'll need to ride the bus." or "I'm sorry gas is so > expensive: if it works better for you, you might want to consider riding > the bus instead." > > -Scott > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mueller at syr.edu Thu Jun 26 04:29:47 2008 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 26 Jun 2008 04:29:47 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why thetriggerdate? In-Reply-To: <63101.1214321408@sa.vix.com> References: <60600.1214317843@sa.vix.com><65E62262-77EB-47C6-AF9E-E3EB25A421D9@pch.net> <63101.1214321408@sa.vix.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0DB40@SUEXCL-02.ad.syr.edu> > -----Original Message----- > > speculation can be a very profitable activity for those who engage in it, > but the resulting volatility is bad for consumers. i do not particularly > want my actions and values to be monetized in this way, not for ipv4 > space, not for oil, not for electric power in california in 2001. if we > here are amateurs as randy bush has often said, then the speculators will > win no matter what I think the level of fear of speculation evinced on this list has lost connection with reality. All of the speculative markets cited (currency, oil, etc.) involve the flexibility to acquire and resell the commodity in days, hours or minutes. Every transfer market proposal imposes limits of 2 years on resale. Acquirors also have limits on getting addresses from ARIN. The idea that a volatile, unstable market will develop is at odds with the time limits that are being placed on both acquisition and re-sale of acquired addresses. I believe that pre-qualification is an unnecessary administrative burden and an obstacle to the functioning of a transfer market. The future will be uncertain, as all of the comments of the experts on this list demonstrate. It's perfectly acceptable and justifiable for operators to acquire addresses they _may_ need. Projections of need are just estimates. Estimates can be wrong, and if someone wants to spend the money to err on what they consider the safe side I don't see the problem. So many of the comments against transfer markets are really just hand-wringing about the implications of address scarcity. I don't think I should need to remind people that the presence or absence of a transfer policy does not change the fundamental fact of increasing scarcity in the ipv4 space. It may even mitigate it somewhat by providing incentives to release unused space. It does seem to be dawning on people that as long as IPv4 addresses will continue to be needed, and there are people who have them but don't use them and there are people who want them but don't have them, a market will develop. It will be either a transparent, open, rule-governed market or it will be a black/gray market. From tme at multicasttech.com Thu Jun 26 07:01:21 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 26 Jun 2008 07:01:21 -0400 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <486197D2.5010802@dilkie.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40A576F3E@CL-S-EX-1.stanleyassociates.com> <486197D2.5010802@dilkie.com> Message-ID: Hello; On Jun 24, 2008, at 8:56 PM, Lee Dilkie wrote: > > > Howard, W. Lee wrote: >> >> >> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net >>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lee Dilkie >>> >> >> >>> do need to push hard for IPv6 adoption. >>> >> >> What would that look like? >> >> Lee >> > Well, at the beginning, it would be something small, presumably. On > the > order of 5 to 10 pounds (2.5 to 5 Kilo's), and pink.. Oh yes, it will > cry a lot. But folks on this list should be used to that ;) > > Seriously folks. > > Dual stack is the only reasonable way to both get IPv6 deployed *and* > maintain legacy networking with IPv4-only hosts/applications. Your > recently passed proposal to set aside IPv4 space for yet-to-be- > developed > v4<->v6 translators is mostly wishing for magic to happen. Not to say > there won't be some application translators written but for the > majority > of apps, dual stack is the most reasonable solution going forward. > That, > I think, is why the IETF abandoned NAT-PT and came out swinging hard > for > dual stack. > I have been in several IETF IPv6 discussions lately about NAT-PT. It was abandoned, but it is back. Regards Marshall > And for dual-stack to happen, we need to force the issue because it > seems pretty obvious that it isn't going to happen anytime soon if we > just sit and wait for folks to get on board with their good > intentions. > It hasn't happened yet and we've been at this for how many years > now... > > And we are running out of time. We need to do 2 things. > > 1. Give out IPv6 allocations with each IPv4 allocation with > instructions > to use it. > 2. Check that it gets used before giving out any more allocations. And > by used, I mean, made available to downstream customers if applicable. > > There you go, no excuses, deploy dual stack or get no more > allocations. > once everybody "gets it", I think you'll see IPv6 connectivity being > rolled out real fast, everywhere. All these big consumers of ip > addresses are very smart business folks, working within a set of rules > and regulations to get their job done is nothing new, if everyone > has to > do it, it's simply table stakes. > > -lee > > _______________________________________________ > 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 Lee at dilkie.com Thu Jun 26 08:23:23 2008 From: Lee at dilkie.com (Lee Dilkie) Date: Thu, 26 Jun 2008 08:23:23 -0400 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40A5772B2@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40A5772B2@CL-S-EX-1.stanleyassociates.com> Message-ID: <48638A3B.9030405@dilkie.com> Howard, W. Lee wrote: > This is interesting. Have you thought about how to evaluate > whether addresses have been "used" on the IPv6 archipelago? > How available does it have to be? I'm not challenging the > idea, just trying to draw out more detail. > > Would a proposal like this > http://www.arin.net/policy/proposals/2007_16.html > accomplish this goal? > > Lee > _______________________________________________ > > Partially. Certainly the part about forcing the rollout of IPv6. But the rest of it deals with ever increasing utilization requirements and higher and higher bars to meet to get allocations. Perhaps separating the two would be more fruitful? "Used" takes on different meanings, depending on who you are. For an ISP, I would want them to bundle a /64 (or maybe a /48, open for debate) with each IPv4 address given to a downstream customer. For an end user, DNS populated with AAAA and A records for hosts located in the netblock. I'm sure others can think of better/more things. The thing of it is. Once some tipping point is reached, I think you'll see existing holders of IPv4 space coming to ARIN to get IPv6 space so they can roll out IPv6 to existing customers and get them dual-stacked as well. Then the ball is rolling... Once enough folks are dual-stacked, then v6-only can survive on it's own merits (years away, but we have to plan the route). -lee From tvest at pch.net Thu Jun 26 08:44:53 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 26 Jun 2008 08:44:53 -0400 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0DAFD@SUEXCL-02.ad.syr.edu> References: <4860DE1A.3000808@dilkie.com><70DE64CEFD6E9A4EB7FAF3A063141066A10874@mail><6DE777FC-F2F9-4FE7-8A02-58F1531B167D@pch.net><02E3721E-9D06-4F0D-8ED3-47CF896F026A@delong.com> <4A3971AD-52EB-485C-9B50-403ED4590870@pch.net> <7663C7E01D8E094989CA62F0B0D21CD901E0DAFD@SUEXCL-02.ad.syr.edu> Message-ID: <22436A16-EDF3-4256-AAD4-CE83205D38B8@pch.net> On Jun 25, 2008, at 12:00 PM, Milton L Mueller wrote: > Tom: > I'm still waiting for an explanation of how your theory that "IPv4 > transfer markets will give incumbents unbreakable long term market > power" squares with the fact that ETNO, the organization of telecom > incumbents in Europe, has come out strongly against IPv4 address > transfer markets.** Hi Milton, You're making an incorrect assumption here. I was not using the term "incumbents" pejoratively, or as code or shorthand for telcos. The use was purely descriptive, and denoted only those individuals/ institutions that will be holding IPv4 address space when the free pool of IPv4 address space is exhausted. The fact that traditional "incumbents", i.e., national facilities- based telecom carriers, advocate a continuation of existing allocation policies until the day of exhaustion speaks for itself -- but if more explanation is required Michael Dillon and others have clearly articulated some of the reasoning for preferring this approach on this list and elsewhere. > And explain to me again how the absence of a market guarantees > "transitional resources for all new entrants?" I thought it just meant > the damn things ran out and no one got them. I will explain that to you as soon as have cleared up the question of when you stopped beating your wife.* Of course the mere "absence of a market" does not guarantee anything, just as the mere "approval of a transfer proposal" does not guarantee anything, including the availability of transitional resources, or even a "market". Nothing guarantees anything, we're just trying to improve the odds of a happy outcome here. TV *disclaimer for those not familiar, this is not a personal insult/ accusation but rather a common example in logic/legal argument about the futility/disutility of responding to a (literally) "mis-leading" loaded question. > --MM > > **When the .net TLD was up for renewal, the OECD recommended > auctioning > it off. Some people objected that such a procedure would mean > that .net > would surely be re-assigned to VeriSign because "it had the most > money." > Then, VeriSign came out publicly with a news release strongly opposing > auctions and insisting that only a beauty contest oriented around > "stability and security" could possibly assign .net to the right > operator. And what do you know, a few months later .net was reassigned > to VeriSign, because of its "importance to the security of the > Internet > infrastructure..." > > Want other examples like this? They exist. > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On >> Behalf Of Tom Vest >> Sent: Tuesday, June 24, 2008 1:23 PM >> To: Owen DeLong >> Cc: ppml at arin.net >> Subject: Re: [arin-ppml] Q1 - ARIN address transferpolicy: >> whythetriggerdate? >> >> Hi Owen, >> >> Thanks for the question. >> For the most part, the answer was anticipated by Paul. >> If a policy like this gets approved, and the reserved pool is large >> enough to last long enough so that no one -- no active IPv4-based >> operator or outside speculator -- could even conceive of a time >> horizon over which exploitation of the asymmetry/bottleneck >> opportunity might be profitable, then perhaps this won't be a >> problem. >> >> For that, the reserved pool would have to be big enough, at least, to >> accommodate transitional resources for all new entrants, assuming the >> fastest plausible rate of new entry, for the longest conceivable >> transition to de-facto full IPv4-IPv6 substitutability -- the point >> when everything important is transparently accessible by IPv6-only >> networks. >> >> To begin estimating that quantity, I could derive the historical new >> entrant rate for the RIPE region, because I can distinguish the >> initial allocations from the subsequent allocations -- but I would >> have to defer to somebody else for the ARIN, et al rates... >> >> In either case, what would count as a plausible new entry rate for >> the >> next (x) years, relative to the historical rates -- what is the >> biggest bottleneck likely to be (address resources, routing capacity, >> transport facilities, etc.)? And what's the largest plausible (x) >> until de-facto substitutability is achieved, given (at least) the >> strategic considerations above? >> >> TV >> >> On Jun 24, 2008, at 11:15 AM, Owen DeLong wrote: >> >>> Tom, >>> Absent the recent policy proposal to create a reservation >>> for IPv6 Transitional Technologies in the ARIN IPv4 free pool, >>> I would agree with you. However, wouldn't that policy mitigate >>> what you are saying below? (assuming it gets adopted) >>> >>> Owen >>> >>> On Jun 24, 2008, at 6:55 AM, Tom Vest wrote: >>> >>>> There is also the matter of asymmetrical dependence and bargaining >>>> power (detailed ad nauseam last week). >>>> >>>> Unless something changes, on the day after free pool exhaustion and >>>> every day thereafter, "incumbent" IPv4-based networks will be able > to >>>> unilaterally decide whether/when they want to be transparently >>>> interoperable with native IPv6 networks, and they will be able to >>>> unilaterally act to make that possible, e.g., by going dual-stack, >>>> renumbering, or operating a symmetrical 6/4 gateway. >>>> >>>> Unless something changes, on the day after free pool exhaustion and >>>> every day thereafter, new IPv6-only networks will need to >>>> interoperate >>>> with the universe of incumbent IPv4 networks. However, they will > NOT >>>> be able to unilaterally act to make that possible as long as that >>>> requires at least some IPv4, which at that point will only > available >>>> from those incumbent networks, or from "pure speculators". >>>> >>>> That asymmetry is what will drive the price of IPv4 up and up, and >>>> that increasing profit potential and bargaining power -- which is >>>> just >>>> an artifact of the lingering IPv4 bottleneck between new IPv6 >>>> networks >>>> and everything still accessible only via IPv4 -- is what will >>>> incentivize incumbent IPv4 networks/IPv4 dealers to delay their own >>>> shift to transparent interoperability for as long as possible. >>>> >>>> Aspiring to be the last-mover will be the only rational strategy in >>>> the environment that an IPv4 resource transfer market will create. >>>> >>>> But maybe rationality will take a holiday :-\ >>>> >>>> TV >>>> >>>> On Jun 24, 2008, at 9:21 AM, Kevin Kargel wrote: >>>> >>>>> Don't forget the fact that IPv6 is not yet a perfect or mature >>>>> service. >>>>> Delaying IPv6 implementation will avoid the costs involved with >>>>> development and debugging of local networks while letting others > do >>>>> the >>>>> dirty work. I am not advocating this, just recognizing a reality. >>>>> The >>>>> forward thinking administrators that want to make a difference in >>>>> the >>>>> world will jump in and get it done, the profit driven enterprises >>>>> will >>>>> sit back and wait until everything is easy or unavoidable. >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] >>>>> On >>>>> Behalf Of Lee Dilkie >>>>> Sent: Tuesday, June 24, 2008 6:44 AM >>>>> To: michael.dillon at bt.com >>>>> Cc: ppml at arin.net >>>>> Subject: Re: [arin-ppml] Q1 - ARIN address transferpolicy: >>>>> whythetriggerdate? >>>>> >>>>> >>>>> michael.dillon at bt.com wrote: >>>>>>> As with many other technologies, there is a substantial > last-mover >>>>>>> advantage to going dual-stack or single-v6. >>>>>>> >>>>>> >>>>>> On what do you base this opinion? >>>>>> >>>>>> --Michael Dillon >>>>>> >>>>>> >>>>> Moore's Law, one would think. Delaying purchase of networking >>>>> equipment >>>>> will yield better performance for lower cost. >>>> >>>> >>>> _______________________________________________ >>>> 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 the ARIN Member Services Help Desk at 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 26 08:53:14 2008 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 26 Jun 2008 08:53:14 -0400 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <48638A3B.9030405@dilkie.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40A5772B2@CL-S-EX-1.stanleyassociates.com> <48638A3B.9030405@dilkie.com> Message-ID: <4863913A.7060909@chl.com> Lee Dilkie wrote: > > Once enough folks are dual-stacked, > then v6-only can survive on it's own merits (years away, but we have to > plan the route). This is exactly why dual stack as a migration strategy is dead. A) Since there is no inherent benefit for an ipv4 host to dual stack, its all pain and no gain. Therefore it suffers from chicken-egg, leading to contortions and coercions attempts to jumpstart. Thats the wrong approach. The only way to get this done is to get people to want to get it done. B) As you acknowledge above, dual stack migration needs years more time before ipv6 only hosts can/will be safely deployed. And its not like dual stacked migration hasnt been planned and trumpeted for years already. Witness the current (lack of) progress for the odds of its success. Projected runout doesnt give much time, hence the transfer market discussion. In fact, dual stack's only hope for voluntary widespread deployment is increasing utilization of ipv6 only hosts with gateways and translation. Behold egg followed by chicken hatching. == Proponents of dual stack as a migration strategy must believe either: a) the transfer market will extend ipv4 lifetime long enough to allow dual stack migration to ipv6 to succeed (where it hasnt so far). b) dual stack migration will happen sometime between now and runout, either because of, or indifference of, or in spite of, runout. Only the dual stack "because of" segment is logically required to be against the transfer market due to the belief it will impede progress to ipv6. Others seem to be opposed to the transfer market for a variety of other believed causes: - too much effort for too little return - rewarding bad actors - routing table bloat - speculation - hoarding - price skyrocketing - regulatory interference - fairness - will slow progress to ipv6 Joe From tvest at pch.net Thu Jun 26 11:55:09 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 26 Jun 2008 11:55:09 -0400 Subject: [arin-ppml] Q1 - ARIN address transfer policy: why thetriggerdate? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0DB40@SUEXCL-02.ad.syr.edu> References: <60600.1214317843@sa.vix.com><65E62262-77EB-47C6-AF9E-E3EB25A421D9@pch.net> <63101.1214321408@sa.vix.com> <7663C7E01D8E094989CA62F0B0D21CD901E0DB40@SUEXCL-02.ad.syr.edu> Message-ID: On Jun 26, 2008, at 4:29 AM, Milton L Mueller wrote: >> -----Original Message----- >> >> speculation can be a very profitable activity for those who engage >> in it, >> but the resulting volatility is bad for consumers. i do not >> particularly > want my actions and values to be monetized in this >> way, not for ipv4 >> space, not for oil, not for electric power in california in 2001. >> if we >> here are amateurs as randy bush has often said, then the >> speculators will >> win no matter what > > > I think the level of fear of speculation evinced on this list has lost > connection with reality. > > All of the speculative markets cited (currency, oil, etc.) involve the > flexibility to acquire and resell the commodity in days, hours or > minutes. Every transfer market proposal imposes limits of 2 years on > resale. Acquirors also have limits on getting addresses from ARIN. The > idea that a volatile, unstable market will develop is at odds with the > time limits that are being placed on both acquisition and re-sale of > acquired addresses. Hi Milton, I find it telling that you have adopted the common but self- contradictory position that: 1. A "market" is inevitable because SOME community members will (and/ or already have) refuse to adhere to the applicable policies/ restrictions -- which were developed by/within that community -- when non-adherence serves their individual interests. 2. However, once a market is created, NO community members will refuse to adhere to the new policies/restrictions -- which presumably have no more force or efficacy that those that came before -- even when non- adherence serves their individual interests. The truth, of course, is that some people will refuse to comply with some rules on some occasions no matter what they are, regardless of whether you're talking about a "self-governing" system where most of the policy effectiveness (i.e., compliance) measurement and encouragement efforts are passive or indirect (if not always entirely "voluntary"), or an "other-governing" system in which members are monitored and forced to comply by a third party.... regardless of whether your talking about a command-and-control system or a regulated market. Where there are rules, there are always rule-breakers; that is the only rule ;-) The big difference/problem, then, is not so much related to the fact of occasional noncompliance, but rather with the sustainability of the system itself. In previous messages you've explicitly declined to assert that you favor the complete (legal) privatization of IPv4, and you also passed on opportunities to declare that you favor ceding the allocation and registry functions to a government entity. I'm going to leap from those silences to the assumption that they imply that, in a future of market-driven IPv4 transfers, the community will continue to have the same "policy effectiveness (i.e., compliance) measurement and encouragement" obligations that it possesses today... And here's where the idea fails. A self-governing system can't afford the luxury of (much) hypocrisy. We generally don't/can't rely on the existence of a third party with hypothetical absolute power, either to wield threats to promote collective compliance (i.e., "coordination"), or to monitor and detect and punish the noncompliant -- or to justify the kind of magical thinking that suggests that real-world problems that require coordination have somehow disappeared (ala "there's a law against burglary, so I don't need to have a lock on my door"). For the most part, we don't have police, or even locks at the moment; what we have is a diverse, largely unintentional, organically- developed cumulation of passive and indirect compliance-encouraging mechanisms, which seem to do the job "well enough" They get better over time, generally, but since not all of the improvements are retroactive, we occasionally have a contingent one-time problem that requires special handling. It may be that we'll develop some tools like police, locks, etc. in the future (some are already in the works, but are not exactly embraced by all with great enthusiasm). But even then it would be prudent not to expect too much from them / impose too much burden on them -- unless of course those tools are as "powerful" as (or maybe just an extension of) those in the "other-governance" world... or perhaps our own magical thinking skills improve. So, now we are confronting an odd assortment of special one-time problems (legacy allocations, classful allocations, imperfect preservation of historical registry data, imperfect mechanisms for maintaining policy-to-resource-to-institution associations over time, etc.), some of which feel urgent because of the looming exhaustion of the unallocated IPv4 address pool. At the same time, we also have the looming challenge of IPv6 migration, which if managed properly could fix or moot most/all of these contingent problems, while at the same time alleviating the essential problem of number resource scarcity. That's not inevitable however; it's just business, after all, and not all businesses thrive, or even survive. At this point we have no choice but to handle both the backward- looking IPv4 and the forward-looking IPv6 challenges simultaneously, which means that conflicts and choices and tradeoffs are inevitable. Given that, which one do you think should take precedence? What calculus do you recommend for determining whether a given policy or proposal or set of proposals balances or otherwise reconciles these potentially conflicting goals well or poorly? Your support for resource transfer proposals and IPv4 markets is plain enough, but could you expand a little and help us understand your reasoning in this broader context? Thanks, TV P.S. This list includes many cynics and masters of the ironic style of writing; I may even have dabbled myself from time to time ;-) I fully expect to get plenty of that in return, all of which will be worth IF it's accompanied by an honest response to the very real question at the end. > I believe that pre-qualification is an unnecessary administrative > burden > and an obstacle to the functioning of a transfer market. The future > will > be uncertain, as all of the comments of the experts on this list > demonstrate. It's perfectly acceptable and justifiable for operators > to acquire addresses they _may_ need. Projections of need are just > estimates. Estimates can be wrong, and if someone wants to spend the > money to err on what they consider the safe side I don't see the > problem. > > So many of the comments against transfer markets are really just > hand-wringing about the implications of address scarcity. I don't > think > I should need to remind people that the presence or absence of a > transfer policy does not change the fundamental fact of increasing > scarcity in the ipv4 space. It may even mitigate it somewhat by > providing incentives to release unused space. It does seem to be > dawning > on people that as long as IPv4 addresses will continue to be needed, > and > there are people who have them but don't use them and there are people > who want them but don't have them, a market will develop. It will be > either a transparent, open, rule-governed market or it will be a > black/gray market. From tvest at pch.net Thu Jun 26 18:01:01 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 26 Jun 2008 18:01:01 -0400 Subject: [arin-ppml] The root of the disagreement? In-Reply-To: References: <60600.1214317843@sa.vix.com><65E62262-77EB-47C6-AF9E-E3EB25A421D9@pch.net> <63101.1214321408@sa.vix.com> <7663C7E01D8E094989CA62F0B0D21CD901E0DB40@SUEXCL-02.ad.syr.edu> Message-ID: <2657EF71-D66A-4BC3-BD0E-486BC840E93B@pch.net> Hi Milton, Was just reading back through Ruling the Root, when I (re)discovered your overview on methods for allocating goods. Very illuminating -- truly. Is there anyplace where those who do not have the book could peruse your chapter on "The Political Economy of Identifiers" online? The part I find most illuminating is around p. 22 in my edition, where you discuss the significance of identifier semantics, and their relationship to the value of individual identifiers, and by implication to the overall value of identifier systems. In one paragraph on domain names, you dismiss some argument (with a cite to Vixie 1995, no less) in favor of equalizing and thus eliminating semantic differences between domain names. In this context, you write that "such 'solutions' are attempts to avoid rather than cope with the problem," and that "eliminating the meaning eliminates the basis for disputes, but it also eliminates most of their value." You conclude that such arguments are akin to "proposing to cure a headache by cutting off one's head." Do you think that IP addresses are, or should have, the same semantics- based value that domain names currently have? Would you argue that the value of IP addresses, and and the overall system that they support, would be more valuable if, instead of being unique but only unidimensionally so (i.e., globally homogeneous in all other nontrivial respects), IPv4 addresses were characterized by similar hierarchies of use value (memorableness, etc.) and exchange value ($$ $) that is characteristic of individual domain names? Since domain names are used for human, intentional/purpose-directed navigation, I can understand the argument, even the necessity, for heterogeneity across those identifiers. However, since IP addresses are used for automated, dynamic, algorithmic navigation by machines (which are operated by humans who also/already have access to DNS and other, even more reliable semantic guideposts), I'm assuming that there must be some *other* rationale for thinking that they should be evaluated on the same terms...? Since that's a classic "loaded question", and on the advice of counsel I'd be invoking my Fifth Amendment right on any questions related to wife-beating anyway, I'll complete my own offload first ;-) I believe that the value of the IP address pool, and by reverse derivation the value of individual addresses, is determined first by the *number* and diversity of the things that can (maybe even "do") participate in a common/shared system of data/traffic/information/ value exchange relationships by virtue of that fact. Of course some online things are more valuable/interesting than others, for different people, at different times, but it's not clear how (or how much) overall value would be improved by facilitating differential access to IP addresses for such such popular nodes *when such differentiation would reduce the capacity for additional new valuable/interesting things to emerge thereafter.* We could revisit old debates about the relative tradeoffs between making life marginally/temporarily more complicated for current large/ popular operators vs. making independent existence impossible for a few more hypothetical/future operators if you like (all settled by the institutionalization of RFC 2050 rather than RFC 1744). However, first I want to focus on the gross "more" dimension -- the vastly more important one, IMO. Basically, the idea is this: today IPv4 and IPv6 are both technically and semantically distinct; IPv4 is proven, has had a couple of decades of development and debugging, whereas lots of hardware and software still has trouble with IPv6. Perhaps that's a transient problem, but even assuming so, the semantic gap will still be be profound absent other developments. The thing is, if those other developments *do* happen, then the overall value supported by the expanded address pool (and hence the incremental value of *all* of the individual addresses therein) gets to continue growing and growing, for a long long time at least. The alternative is what we've got today +/- 50%, if you're wildly optimistic. I believe that we really need some of those "others things" to happen, whatever they might be, so that the semantic distinction completely disappears, and the expansion of value may proceed unhindered. In other words, I believe that the same rationale that has supported the "needs-based" approach to IPv4 conservation also applies to the question of how to prioritize IPv4 preservation efforts like resource transfers vs. those that contribute to relatively faster, more orderly, but dead-certain IPv6 migration. Your turn... TV From mueller at syr.edu Fri Jun 27 05:56:55 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 27 Jun 2008 05:56:55 -0400 Subject: [arin-ppml] The root of the disagreement? In-Reply-To: <2657EF71-D66A-4BC3-BD0E-486BC840E93B@pch.net> References: <60600.1214317843@sa.vix.com><65E62262-77EB-47C6-AF9E-E3EB25A421D9@pch.net> <63101.1214321408@sa.vix.com> <7663C7E01D8E094989CA62F0B0D21CD901E0DB40@SUEXCL-02.ad.syr.edu> <2657EF71-D66A-4BC3-BD0E-486BC840E93B@pch.net> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0DB7C@SUEXCL-02.ad.syr.edu> > -----Original Message----- > > Was just reading back through Ruling the Root, when I (re)discovered > your overview on methods for allocating goods. > Very illuminating -- truly. Is there anyplace where those who do not > have the book could peruse your chapter on "The Political Economy of > Identifiers" online? Not at the moment. Might have time to make it available when returning to US. > Do you think that IP addresses are, or should have, the same semantics- > based value that domain names currently have? Of course, IP addresses do not have semantics, which moots the question whether they should have them. > Would you argue that the > value of IP addresses, and and the overall system that they support, > would be more valuable if, instead of being unique but only > unidimensionally so (i.e., globally homogeneous in all other > nontrivial respects), IPv4 addresses were characterized by similar > hierarchies of use value (memorableness, etc.) and exchange value ($$ > $) that is characteristic of individual domain names? No, I think that whole chapter was predicated on the contrast between meaningless unique identifiers that serve a technical function (IP addresses) and semantically meaningful unique identifiers, where the semantics bring conflicts over property rights related to trademark, personal names, company names, geographic indicators, etc. (we are _still_ working those out, by the way - witness the IDN ccTLD discussions in Paris at the ICANN meeting). > Since domain names are used for human, intentional/purpose-directed > navigation, I can understand the argument, even the necessity, for > heterogeneity across those identifiers. However, since IP addresses > are used for automated, dynamic, algorithmic navigation by machines > (which are operated by humans who also/already have access to DNS and > other, even more reliable semantic guideposts), I'm assuming that > there must be some *other* rationale for thinking that they should be > evaluated on the same terms...? Yes, their scarcity value, the need for rationing. From randy at psg.com Fri Jun 27 14:15:10 2008 From: randy at psg.com (Randy Bush) Date: Sat, 28 Jun 2008 03:15:10 +0900 Subject: [arin-ppml] Q1 - ARIN address transferpolicy: whythetriggerdate? In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40A5774E1@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40A5774E1@CL-S-EX-1.stanleyassociates.com> Message-ID: <48652E2E.2010302@psg.com> > I don't presume to speak for Tom or to interpret ETNO, but I > can offer some theories. > Predictability is of great value to large companies. ETNO > explains. . . follow the cash. if current policies are continued, the largest operators get 90+% of the remaining pie for not one euro cent more in cost. randy From tvest at pch.net Fri Jun 27 14:26:22 2008 From: tvest at pch.net (Tom Vest) Date: Fri, 27 Jun 2008 14:26:22 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: References: <4849f2d4.1db.4182.26981@batelnet.bs> <45479.1212809939@sa.vix.com> <84853.1212888922@sa.vix.com> <484B3ACD.5060604@merit.edu> <86051.1212891201@sa.vix.com> Message-ID: Importing some text here from a related message/thread... Begin forwarded message: > From: Owen DeLong > Date: June 24, 2008 5:50:29 PM EDT > To: Tom Vest > Cc: "Kevin Kargel" , ppml at arin.net > Subject: Re: [arin-ppml] Q1 - ARIN address transferpolicy: > whythetriggerdate? > > > On Jun 24, 2008, at 10:23 AM, Tom Vest wrote: > >> Hi Owen, >> >> Thanks for the question. >> For the most part, the answer was anticipated by Paul. > > Yeah, that's one of the reasons I like having Paul on the BoT. > He's quite good that way. >> >> If a policy like this gets approved, and the reserved pool is large >> enough to last long enough so that no one -- no active IPv4-based >> operator or outside speculator -- could even conceive of a time >> horizon over which exploitation of the asymmetry/bottleneck >> opportunity might be profitable, then perhaps this won't be a >> problem. >> > I originally proposed a /8. The current proposal is a /10. These > would probably be handed out > as /24-/28 sized chunks, so, I suspect that will at least get us > past the point where others might > be willing to migrate away from some portion of their IPv4 stuff > into other solutions. > >> For that, the reserved pool would have to be big enough, at least, >> to accommodate transitional resources for all new entrants, >> assuming the fastest plausible rate of new entry, for the longest >> conceivable transition to de-facto full IPv4-IPv6 substitutability >> -- the point when everything important is transparently accessible >> by IPv6-only networks. >> > I think a /8 would provide a comfortable cushion beyond this. A /10 > will likely be more > than enough space as well. I think we're talking about a 5 year > period beyond IPv4 > exhaustion maximum. This would accommodate at least 16,384 new > provider-independent > entrants during that time, and, likely substantially more, possibly > as much as 256k new > entrants. I believe that is well above any anticipated number in a > 5 year timeframe. If it wasn't already obvious, I support this proposal. However, I think that the reservation should envision a 20-year transition timeframe, if not longer. I am assuming that a resource transfer proposal will advance in parallel, and ultimately versions of both policies may be approved. If that happens, some very risk-averse and/or very windfall-driven IPv4 holders/users may still be tempted to hold out until the reserved pool too is exhausted. The size of the reserved pool is the only real deterrent to discourage that kind of strategy. TV >> To begin estimating that quantity, I could derive the historical >> new entrant rate for the RIPE region, because I can distinguish the >> initial allocations from the subsequent allocations -- but I would >> have to defer to somebody else for the ARIN, et al rates... >> > At this point, the rates are probably relatively similar with RIPE's > rate being slightly > higher. > >> In either case, what would count as a plausible new entry rate for >> the next (x) years, relative to the historical rates -- what is >> the biggest bottleneck likely to be (address resources, routing >> capacity, transport facilities, etc.)? And what's the largest >> plausible (x) until de-facto substitutability is achieved, given >> (at least) the strategic considerations above? >> > In my opinion x<=5 and max plausible rate is <2000/year with likely > being closer > to 200/year. > > Owen > >> TV >> >> On Jun 24, 2008, at 11:15 AM, Owen DeLong wrote: >> >>> Tom, >>> Absent the recent policy proposal to create a reservation >>> for IPv6 Transitional Technologies in the ARIN IPv4 free pool, >>> I would agree with you. However, wouldn't that policy mitigate >>> what you are saying below? (assuming it gets adopted) >>> >>> Owen >>> >>> On Jun 24, 2008, at 6:55 AM, Tom Vest wrote: >>> >>>> There is also the matter of asymmetrical dependence and bargaining >>>> power (detailed ad nauseam last week). >>>> >>>> Unless something changes, on the day after free pool exhaustion and >>>> every day thereafter, "incumbent" IPv4-based networks will be >>>> able to >>>> unilaterally decide whether/when they want to be transparently >>>> interoperable with native IPv6 networks, and they will be able to >>>> unilaterally act to make that possible, e.g., by going dual-stack, >>>> renumbering, or operating a symmetrical 6/4 gateway. >>>> >>>> Unless something changes, on the day after free pool exhaustion and >>>> every day thereafter, new IPv6-only networks will need to >>>> interoperate >>>> with the universe of incumbent IPv4 networks. However, they will >>>> NOT >>>> be able to unilaterally act to make that possible as long as that >>>> requires at least some IPv4, which at that point will only >>>> available >>>> from those incumbent networks, or from "pure speculators". >>>> >>>> That asymmetry is what will drive the price of IPv4 up and up, and >>>> that increasing profit potential and bargaining power -- which is >>>> just >>>> an artifact of the lingering IPv4 bottleneck between new IPv6 >>>> networks >>>> and everything still accessible only via IPv4 -- is what will >>>> incentivize incumbent IPv4 networks/IPv4 dealers to delay their own >>>> shift to transparent interoperability for as long as possible. >>>> >>>> Aspiring to be the last-mover will be the only rational strategy in >>>> the environment that an IPv4 resource transfer market will create. >>>> >>>> But maybe rationality will take a holiday :-\ >>>> >>>> TV >>>> >>>> On Jun 24, 2008, at 9:21 AM, Kevin Kargel wrote: >>>> >>>>> Don't forget the fact that IPv6 is not yet a perfect or mature >>>>> service. >>>>> Delaying IPv6 implementation will avoid the costs involved with >>>>> development and debugging of local networks while letting others >>>>> do >>>>> the >>>>> dirty work. I am not advocating this, just recognizing a reality. >>>>> The >>>>> forward thinking administrators that want to make a difference >>>>> in the >>>>> world will jump in and get it done, the profit driven >>>>> enterprises will >>>>> sit back and wait until everything is easy or unavoidable. >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net >>>>> ] >>>>> On >>>>> Behalf Of Lee Dilkie >>>>> Sent: Tuesday, June 24, 2008 6:44 AM >>>>> To: michael.dillon at bt.com >>>>> Cc: ppml at arin.net >>>>> Subject: Re: [arin-ppml] Q1 - ARIN address transferpolicy: >>>>> whythetriggerdate? >>>>> >>>>> >>>>> michael.dillon at bt.com wrote: >>>>>>> As with many other technologies, there is a substantial last- >>>>>>> mover >>>>>>> advantage to going dual-stack or single-v6. >>>>>>> >>>>>> >>>>>> On what do you base this opinion? >>>>>> >>>>>> --Michael Dillon >>>>>> >>>>>> >>>>> Moore's Law, one would think. Delaying purchase of networking >>>>> equipment >>>>> will yield better performance for lower cost. >>>> >>>> >>>> _______________________________________________ >>>> 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 the ARIN Member Services Help Desk at >>>> info at arin.net if you experience any issues. >>> > From tvest at pch.net Fri Jun 27 17:12:03 2008 From: tvest at pch.net (Tom Vest) Date: Fri, 27 Jun 2008 17:12:03 -0400 Subject: [arin-ppml] The root of the disagreement? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0DB7C@SUEXCL-02.ad.syr.edu> References: <60600.1214317843@sa.vix.com><65E62262-77EB-47C6-AF9E-E3EB25A421D9@pch.net> <63101.1214321408@sa.vix.com> <7663C7E01D8E094989CA62F0B0D21CD901E0DB40@SUEXCL-02.ad.syr.edu> <2657EF71-D66A-4BC3-BD0E-486BC840E93B@pch.net> <7663C7E01D8E094989CA62F0B0D21CD901E0DB7C@SUEXCL-02.ad.syr.edu> Message-ID: <3A198D0B-3AC4-4D37-8187-A645F0E98ACD@pch.net> On Jun 27, 2008, at 5:56 AM, Milton L Mueller wrote: >> -----Original Message----- >> >> Was just reading back through Ruling the Root, when I (re)discovered >> your overview on methods for allocating goods. >> Very illuminating -- truly. Is there anyplace where those who do not >> have the book could peruse your chapter on "The Political Economy of >> Identifiers" online? > > Not at the moment. Might have time to make it available when returning > to US. > >> Do you think that IP addresses are, or should have, the same > semantics- >> based value that domain names currently have? > > Of course, IP addresses do not have semantics, which moots the > question > whether they should have them. In a narrow (but instructive!) sense you may be right, as an artifact of a terminological error on my part (apparently an old and pervasive one, even in protocol design). In isolation, individual IP addresses have no function, meaning, or use value whatsoever -- by design -- so the term "semantics" has no relevant application. This is actually another foundation of "needs-based" conservation policies: it makes sense to preserve a finite and (truly) scarce resource of this kind by establishing basic eligibility rules for would-be recipients, rules that simply (and only) require that the recipient is capable of using the resource for its intended purpose -- the purpose for which it was created. Of course, individual IP addresses do have value, and *differential* value, in a context/environment of other IP addresses -- which means that the right term is not "semantics" but rather "pragmatics". Today, individual IP addresses bear important "pragmatic" distinctions, distinctions which are widely recognized both by the users (and devices) that bear them, and by every other user (and device) that also uses, or is capable of using IP addresses. Once, a long time ago, there were no "pragmatic" distinctions either; all IP addresses were uniformly public (i.e., presumed to be global- scope unique, with global-scope use value) and uniformly interoperable IPv4 addresses. However, when it was recognized that IPv6 would not be ready for global deployment in time, RFC1918 established a new class of IP addresses with different, much narrower "pragmatics" and correspondingly lower use value. The pragmatic distinction was so great in fact that an industry friend used to give regular talks describing the (often involuntary) ad hoc partitioning that resulted from their use as "evil".* But we all learned to live with it because the involuntary aspect of it, at least, was expected to be eliminated by the transition to IPv6. However, because the old and new addressing systems are not directly interoperable, the "pragmatics" of IPv6 will continue to have some critical features in common with those of RFC1918 addresses, for as long as the overwhelming majority of real online resources (users, content. etc.) are attached via IPv4. Native IPv6 users may be able to seamlessly communicate with each other when they are directly connected to each other, but they cannot communicate with each other over any IPv4-mediated distance -- or with any of the universe of IPv4- numbered edge resources -- unless they also happen to have access to some IPv4 address space. So, just by virtue of this environmental or demographic fact alone, the "pragmatics" of IPv6 will compare unfavorably to those of IPv4 for as long as the environment is largely IPv4-based. IPv4 users know it, IPv6 users know it -- and that knowledge unavoidably colors everything they do, today (like postpone adoption) and in the future. That's why decentralizing IPv4 allocation and subjecting the process to market forces is such a bad idea at this moment. Absent other policies (e.g., 2008-5), resource transfer proposals envision a world in which those IPv4 address are available only from incumbents, who are often competitors, and who will always be interested foremost in maximizing rents from those IPv4 addresses. Like it or not, we have arrived at a point where growth is causing the "pragmatics" of the public Internet to change. We could resign ourselves to this change, and a future in which direst stakeholders form a semi-permanent caste system of first-class and second-class participants (in which some may occasionally buy upward mobility or sell themselves "down"), that one day might be redeemed by the magic of the Invisible Hand. Or we can can take steps to recover the original design intent, by restoring the semantic/pragmatic opacity of IP addressing. >> Would you argue that the >> value of IP addresses, and and the overall system that they support, >> would be more valuable if, instead of being unique but only >> unidimensionally so (i.e., globally homogeneous in all other >> nontrivial respects), IPv4 addresses were characterized by similar >> hierarchies of use value (memorableness, etc.) and exchange value ($$ >> $) that is characteristic of individual domain names? > > No, I think that whole chapter was predicated on the contrast between > meaningless unique identifiers that serve a technical function (IP > addresses) and semantically meaningful unique identifiers, where the > semantics bring conflicts over property rights related to trademark, > personal names, company names, geographic indicators, etc. (we are > _still_ working those out, by the way - witness the IDN ccTLD > discussions in Paris at the ICANN meeting). > >> Since domain names are used for human, intentional/purpose-directed >> navigation, I can understand the argument, even the necessity, for >> heterogeneity across those identifiers. However, since IP addresses >> are used for automated, dynamic, algorithmic navigation by machines >> (which are operated by humans who also/already have access to DNS and >> other, even more reliable semantic guideposts), I'm assuming that >> there must be some *other* rationale for thinking that they should be >> evaluated on the same terms...? > > Yes, their scarcity value, the need for rationing. Just restating the terms "scarcity value" and "rationing" does not answer the question. The question is, given a choice, and the likelihood of having to make some short-term tradeoffs either way, which would you prefer -- which would you personally recommend to the world? 1. "Rationing" an extremely scarce resource, the few remaining units of which have both non-substitutable, global-scope "use value" (albeit for a closed/static world) and extremely high "scarcity value" (aka $$ $), using decentralized market mechanisms that can only produce a few winners and many many losers. 2. "Rationing" an extremely abundant non-substitutable resource that has no "scarcity value" at all, but the same global-scope "use value" (albeit in a open/expanding world), if necessary using centralized administrative mechanisms (aka verification of "need", or ability to use as intended) that produces many winners and no losers at all. It's okay if you don't want to answer, but we have to choose one. That's what this policy forum is for. TV *The friend is sensitive about being misquoted so here are some references to speak for themselves: http://www.sanog.org/resources/sanog7/apnic-randy-nats.pdf http://www.apnic.net/meetings/17/docs/sigs/policy/addrpol-pres-randy-nats.pdf http://www.nanog.org/mtg-0710/presentations/Bush-v6-op-reality.pdf (indirectly related) From mueller at syr.edu Mon Jun 30 17:58:53 2008 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 30 Jun 2008 17:58:53 -0400 Subject: [arin-ppml] Routing security Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0DBFC@SUEXCL-02.ad.syr.edu> People on this list would probably be interested in this blog post discussing ICANN's SSAC's request for a specific line item for "Management of certificates for the addressing system (RPKI)." http://blog.internetgovernance.org/blog/_archives/2008/6/25/3762527.html --MM -------------- next part -------------- An HTML attachment was scrubbed... URL: