From randy at psg.com Thu Jan 1 04:02:39 2009 From: randy at psg.com (Randy Bush) Date: Thu, 01 Jan 2009 18:02:39 +0900 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicy for IPv4 Addresses - Last Call In-Reply-To: References: Message-ID: <495C86AF.6080704@psg.com> ray, >> the many /8s (more than all of china has, and unused on the >> internet!) given to the us military in a late quiet side deal, > Can you provide dates regarding this "quiet side" deal and identify > the particular /8s? my abject apology. i was wrong. quite misremembered. the deal i remembered was likely the ipv6 /12, though jet lag is still dominant. again my apologies. of course the us military does have significant ipv4 space not announced by them on the internet. randy From JOHN at egh.com Thu Jan 1 09:53:53 2009 From: JOHN at egh.com (John Santos) Date: Thu, 1 Jan 2009 09:53:53 -0500 Subject: [arin-ppml] Policy Proposal 2008-6 In-Reply-To: Message-ID: <1090101095116.1974A-100000@Ives.egh.com> On Wed, 31 Dec 2008, Jo Rhett wrote: > On Dec 31, 2008, at 6:32 AM, Kevin Kargel wrote: > > I have often wondered about this "black market" myself.. everyone > > talks > > about it, but in 15+ years of working in Internet I have never been > > approached and offered IP addresses for sale. I have never seen > > anyone > > I take it you aren't a directly listed ARIN contact? > > I get ~12 queries per year about buying IP address space. I'm a listed contact and have never gotten any. Only a /24, though. Maybe size does matter. (I've gotten about 2-4 per year from someone trying to buy our domain name. Cold dead fingers and all that.) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From mueller at syr.edu Thu Jan 1 12:34:55 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 1 Jan 2009 12:34:55 -0500 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <20081230222048.GA16505@ussenterprise.ufp.org> References: <7663C7E01D8E094989CA62F0B0D21CD9028B2CF6@SUEXCL-02.ad.syr.edu><70DE64CEFD6E9A4EB7FAF3A06314106601B4AC98@mail><495A714D.50008@psg.com><20081230213649.GA14175@ussenterprise.ufp.org><495A9A9C.5070409@psg.com> <20081230222048.GA16505@ussenterprise.ufp.org> Message-ID: <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> Leo I write this half-heartedly because we are just repeating the same old positions. Those who are knee-jerk against markets (Kargel, you, etc.) have used Herrin's simple rewording proposal to reassert their view. Yawn. It might be more productive to debate the merits of the rewording. Anyway, > The thing I find odd about people who believe both of these things > is they seem to have been for "needs based" allocation in the past. Nothing odd here. The IGP paper and other analyses have explained why the rationale for needs-based administrative allocation breaks down completely when the free pool is exhausted. Once the free space is gone it is no longer about "need" is it is about "relative need"; i.e., it is possible for 2 - N applicants for the same address space to have fully justified claims on the same amount of the address space. At that point the administrator has to use some criterion other than "need" to redistribute the resource. What will it be? Even if there are no market-based transfers, the definition of "need" will change radically, to reflect the greater scarcity, as ARIN will be forced to impose tougher standards of what constitutes need based on this relativistic (scarcity-based) assessment, and to reassess the allocations of people who got them based on "need" in the past in order to reclaim them for other uses. The status quo you defend so doggedly will and must end. You are not opposing markets you are opposing the fact of scarcity, which is (as the Canute story suggests) a futile exercise. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org From mueller at syr.edu Thu Jan 1 12:52:59 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 1 Jan 2009 12:52:59 -0500 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD9028B2CF6@SUEXCL-02.ad.syr.edu> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AC98@mail> <495A714D.50008@psg.com><20081230213649.GA14175@ussenterprise.ufp.org><495A9A9C.5070409@psg.com> Message-ID: <75822E125BCB994F8446858C4B19F0D7086BAEFA@SUEX07-MBX-04.ad.syr.edu> > How are transfers going to affect (drum roll...) >registration data quality, Seems it would improve it by requiring transfering parties to go through ARIN and secure their title via accurate registrations > the risk of (intentional and/or > unintentional) address collisions ditto the above > the continuing viability of cross- > jurisdictional IP networks/services, has anyone on this list noticed that RIPE-NCC has passed its transfer policy? shouldn't this be changing the complexion of the debate somewhat, or do we all assume here than only the US matters? > the future likelihood of IPv6 > adoption Most likely, _if_ v6 migration goes slower and a transfer market drives up the price of v4 blocks it will increase the incentive to move to v6. A lot of "ifs" > or any other TCP/IP-related development? a bit of a vague question, no? > When the amateurs leave the field, are the professionals > going to take over, or will "policy" simply wither away > altogether, as earlier utopians have repeatedly predicted? Policy will never go away, and the creation of markets heightens the need for making (good) policy decisions. As for the "amateur" charge, I would say as someone with 25 years of (often professional) experience in policy, law and regulation of communications that I would not be so dismissive of the Internet technical community's perspicacity. One often finds a shocking historical and institutional ignorance in this community, some bizarre ideological prejudices (as one finds in any community), coupled with a keen sense of the implications of policy decisions on the technical infrastructure in the here and now. It's a decidedly mixed bag, and it's best to maintain civil dialogue that fosters mutual learning. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org From tvest at pch.net Thu Jan 1 13:54:40 2009 From: tvest at pch.net (Tom Vest) Date: Thu, 1 Jan 2009 13:54:40 -0500 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD9028B2CF6@SUEXCL-02.ad.syr.edu><70DE64CEFD6E9A4EB7FAF3A06314106601B4AC98@mail><495A714D.50008@psg.com><20081230213649.GA14175@ussenterprise.ufp.org><495A9A9C.5070409@psg.com> <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> Message-ID: <38FC738C-9147-41B0-99E3-7D7452A4C986@pch.net> On Jan 1, 2009, at 12:34 PM, Milton L Mueller wrote: > Leo > > I write this half-heartedly because we are just repeating the same > old positions. Those who are knee-jerk against markets (Kargel, you, > etc.) have used Herrin's simple rewording proposal to reassert their > view. Yawn. It might be more productive to debate the merits of the > rewording. Anyway, > >> The thing I find odd about people who believe both of these things >> is they seem to have been for "needs based" allocation in the past. > > Nothing odd here. The IGP paper and other analyses have explained > why the rationale for needs-based administrative allocation breaks > down completely when the free pool is exhausted. Once the free space > is gone it is no longer about "need" is it is about "relative need"; > i.e., it is possible for 2 - N applicants for the same address space > to have fully justified claims on the same amount of the address > space. At that point the administrator has to use some criterion > other than "need" to redistribute the resource. What will it be? > > Even if there are no market-based transfers, the definition of > "need" will change radically, to reflect the greater scarcity, as > ARIN will be forced to impose tougher standards of what constitutes > need based on this relativistic (scarcity-based) assessment, and to > reassess the allocations of people who got them based on "need" in > the past in order to reclaim them for other uses. > > The status quo you defend so doggedly will and must end. The status quo will definitely end. But the kind of ideological orthodoxy that has shaped everything that you've ever written, here and elsewhere, does not have to be the blueprint for what comes next. > You are not opposing markets you are opposing the fact of scarcity, > which is (as the Canute story suggests) a futile exercise. Sometimes I wish I had that kind of faith -- the kind that dictates that there is one-and-only-one choice of action given the assertion of some single, master fact. It would certainly make life a lot simpler and easier. Alas, I live in a world where "master facts" like that don't exist, or at least don't justify the suspension of all judgment and common sense about how to act in their presence. There are plenty of people in this community with strong libertarian leanings, but as a whole the community has always been fairly pragmatic about adapting to changing circumstances. May it remain so in 2009... Happy new year all, TV From owen at delong.com Thu Jan 1 13:59:40 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Jan 2009 10:59:40 -0800 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD9028B2CF6@SUEXCL-02.ad.syr.edu><70DE64CEFD6E9A4EB7FAF3A06314106601B4AC98@mail><495A714D.50008@psg.com><20081230213649.GA14175@ussenterprise.ufp.org><495A9A9C.5070409@psg.com> <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> Message-ID: <0A757D9D-47D6-42CF-BBEE-56FCE6692A16@delong.com> On Jan 1, 2009, at 9:34 AM, Milton L Mueller wrote: > Leo > > I write this half-heartedly because we are just repeating the same > old positions. Those who are knee-jerk against markets (Kargel, you, > etc.) have used Herrin's simple rewording proposal to reassert their > view. Yawn. It might be more productive to debate the merits of the > rewording. Anyway, > >> The thing I find odd about people who believe both of these things >> is they seem to have been for "needs based" allocation in the past. > > Nothing odd here. The IGP paper and other analyses have explained > why the rationale for needs-based administrative allocation breaks > down completely when the free pool is exhausted. Once the free space > is gone it is no longer about "need" is it is about "relative need"; > i.e., it is possible for 2 - N applicants for the same address space > to have fully justified claims on the same amount of the address > space. At that point the administrator has to use some criterion > other than "need" to redistribute the resource. What will it be? > The problem here, Milton, is that you assume redistribution based on relative need is required. You make no allowance for the possibility that first-come, first-served could be a perfectly valid mechanism. Once it's exhausted, it's exhausted and no need for involuntary redistribution exists. Period. I don't know whether this is the best solution or not, but, I haven't seen any evidence that a market is a significantly better process, either. The problem with first-com/first- served is the potential for early hoarding. However, hoarding can be mostly avoided by requiring justified need in order to obtain the resource and reducing (to the extent possible) the rewards available as a result of early hoarding. (Note, btw, that a market CREATES many of the rewards in question). Those organizations who want IP connectivity after the IPv4 free pool is exhausted can move to IPv6 and make use of transitional technologies. True, the current state of those technologies is less than ideal, but, organizations moving to IPv6 will, I suspect, drive significant and rapid improvement in both the transitional tools, and, the availability of IPv6 connectivity to what is currently a mostly IPv4 only internet. > Even if there are no market-based transfers, the definition of > "need" will change radically, to reflect the greater scarcity, as > ARIN will be forced to impose tougher standards of what constitutes > need based on this relativistic (scarcity-based) assessment, and to > reassess the allocations of people who got them based on "need" in > the past in order to reclaim them for other uses. > I think it is perfectly reasonable for the following scenario: 1. Status quo until IANA free pool is exhausted. 2. ARIN continues to issue under status quo until ARIN free pool's largest remaining block is a single /6 3. ARIN continues to issue what it can without invading that /6 under status quo rules. 4. Applications which cannot be satisfied under status quo rules as stated above are rejected and applicants are encouraged to apply for IPv6. 5. Applicants which receive IPv6 and require IPv4 space for transitional technologies to interconnect their IPv6 networks to the existing IPv4 world apply for small pieces of the remaining /6 under recently adopted policy (2008-5 if I recall correctly). > The status quo you defend so doggedly will and must end. You are not > opposing markets you are opposing the fact of scarcity, which is (as > the Canute story suggests) a futile exercise. > I don't see this. I think that the status quo continues, but, enters a phase we have not yet seen which is the post-runout phase of the status quo. In that phase, the IPv4 internet can no longer grow and remains largely as it exists at that time. Growth is forced to IPv6. A similar transition will occur when the world runs out of petroleum products if we don't destroy the environment first. Some other stored energy mechanism will be adopted. The transition will be painful (as will the IPv6 transition), but, when there is no more oil, there will be a migration to some other technology. Owen From iljitsch at muada.com Thu Jan 1 14:01:36 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 1 Jan 2009 20:01:36 +0100 Subject: [arin-ppml] 2008 IPv4 Address Use Report Message-ID: [ (Non-cross)posted to IETF discussions, NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. Web version for the monospace font impaired and with some links: http://www.bgpexpert.com/addrspace2008.php ] 2008 IPv4 Address Use Report As of January first, 2009, the number of unused IPv4 addresses is 925.58 million. On January 1, 2008, it was 1122.85 million. So in 2008, 197.27 million addresses were used up. With 3706.65 million usable addresses, this means that 75.3% of the available IPv4 addresses are in some kind of use, up from 69.7% a year ago. So the depletion of the IPv4 address reserves is continuing in much the same way as in previous years: Date Addresses free Used up 2006-01-01 1468.61 M 2007-01-01 1300.65 M 167.96 M 2008-01-01 1122.85 M 177.80 M (with return of 16.78 M to IANA) 2009-01-01 925.58 M 197.27 M These figures are derived from from the Internet Assigned Numbers Authority's IPv4 Global Unicast Address Assignments page and the records published on the FTP servers of the five Regional Internet Registries (RIRs): AfriNIC, which gives out address space in Africa, APNIC (Asia-Pacific region), ARIN (North America), LACNIC (Latin American and the Caribbean) and the RIPE NCC (Europe, the former Soviet Union and the Middle East). The IANA list shows the status of all 256 blocks of 16777216 addresses identified by the first 8-bit number in the IPv4 address. (Note that the file is in a somewhat different format than in previous years.) The RIR data indicates how much address space the RIRs have delegated to internet service providers (and sometimes end-users). Delegated Blocks +/- 2008 Addresses Used Available to/status (in millions) AfriNIC 2 33.55 9.18 24.37 APNIC 30 +4 503.32 454.36 48.96 ARIN 31 +4 520.09 446.06 74.03 LACNIC 6 100.66 68.88 31.78 RIPE NCC 26 436.21 423.65 12.56 LEGACY 92 +1 1543.50 1363.29 180.21 UNALLOCATED 34 -9 570.43 570.43 Totals 221 3707.76 2765.42 942.34 The difference between the 942.34 million free addresses here and 925.58 million earlier is explained by the fact that the 43.0.0.0/8 legacy block shows up as delegated in the IANA list, but not in the APNIC delegation records. In previous years, 7.0.0.0/8 didn't show up in the IANA records but it did in the ARIN records. This has now been fixed, hence the increase in legacy delegations. No legacy blocks were returned to IANA in 2008. The total number of available addresses is slightly higher than the previously mentioned figure at 3707.76 million because the table above includes 172.16.0.0/12 and 192.168.0.0/16, which are set aside for private use. Networks 0.0.0.0/8 and 127.0.0.0/8 aren't usable because of special uses and 10.0.0.0/8 is also set aside for private use. 224 - 239 are multicast addresses, and 240 - 255 is class E, which is "reserved" for future use. If the class E space could be used, it would increase the available address space by 268 million addresses. The past two years, this has been a topic of hot debate in the IETF and elsewhere. The problem is that almost all operating systems need modification to be able to use class E addresses, and a good part of the installed base of devices connected to the internet must be considered unupgradable. The 2781.07 million addresses currently in use aren't very evenly distributed over the countries in the world. The current top 15 is: 2009-01-01 2008-01-01 increase Country 1 - US 1458.21 M 1408.15 M 4% United States 2 (3) CN 181.80 M 135.31 M 34% China 3 (2) JP 151.56 M 141.47 M 7% Japan 4 - EU 120.29 M 120.35 M 0% Multi-country in Europe 5 - GB 86.31 M 83.50 M 3% United Kingdom 6 (7) DE 81.75 M 72.46 M 13% Germany 7 (6) CA 74.49 M 73.20 M 2% Canada 8 - FR 68.04 M 67.79 M 0% France 9 - KR 66.82 M 58.86 M 14% Korea 10 - AU 36.26 M 33.43 M 8% Australia 11 (12) BR 29.75 M 23.46 M 27% Brazil 12 (11) IT 29.64 M 24.04 M 23% Italy 13 (16) TW 24.01 M 19.83 M 21% Taiwan 14 (18) RU 23.18 M 17.01 M 36% Russia 15 (14) ES 21.67 M 20.42 M 6% Spain In 2008, the United States was again the biggest user of new address space with no less than 50 million addresses added to the 1.4 billion they already had at the beginning of the year. China is a close second with 46.50 million new addresses. There is no clear trend in the growth percentages. A few countries like France and the UK show very modest growth, while other countries with a large installed base like Germany and Korea saw double digit growth percentages. And in addition to China, Brazil, Taiwan and Russia, but also Italy, are catching up. The US now holds 52.4% of the IPv4 address space in use. The total for the top 15 excluding the US is 35.8%. The rest of the world gets the remaining 327.23 million addresses, or 11.8%. The size of address blocks given out was increasing until 2005, but now shows a downturn. The table below shows the number of delegations for a certain range of block sizes (equal or higher than the first, lower than the second value). 2002 2003 2004 2005 2006 2007 2008 < 1000 547 745 1022 1309 1507 1830 1896 1000 - 8000 897 1009 1516 1891 2265 2839 3235 8000 - 64k 822 1014 1100 1039 1192 1015 1129 64k - 500k 163 215 404 309 419 395 410 500k - 2M 29 46 61 60 57 62 82 > 2M 5 6 7 18 17 24 18 In millions of addresses: 2002 2003 2004 2005 2006 2007 2008 < 1000 0.18 0.25 0.35 0.44 0.51 0.63 0.65 1000 - 8000 3.23 3.45 4.49 5.07 5.83 6.93 7.75 8000 - 64k 11.35 14.00 15.99 15.46 18.01 15.67 17.40 64k - 500k 20.28 25.51 42.01 34.23 50.86 50.83 52.58 500k - 2M 21.30 31.98 44.63 41.63 46.69 45.50 57.41 > 2M 12.58 12.58 20.97 68.62 52.43 67.37 54.00 The growth in the smallest and largest categories has been curtailed, but this growth now seems to happen in the second smallest and second largest categories, so the total effect isn't all that different, as indicated by the number of addresses given out per request/delegation: Year Blocks Addresses (M) Average block size 2000 2794 78.35 28043 2001 2824 88.95 31497 2002 2463 68.93 27985 2003 3035 87.77 28921 2004 4110 128.45 31252 2005 4626 165.45 35765 2006 5457 174.32 31945 2007 6165 186.92 30320 2008 6770 189.79 28035 (The numbers of addresses given out are lower here because ARIN often attributes the delegation of new addresses to a previous year, this view doesn't correct for that.) From tvest at pch.net Thu Jan 1 15:37:52 2009 From: tvest at pch.net (Tom Vest) Date: Thu, 1 Jan 2009 15:37:52 -0500 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <75822E125BCB994F8446858C4B19F0D7086BAEFA@SUEX07-MBX-04.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD9028B2CF6@SUEXCL-02.ad.syr.edu> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AC98@mail> <495A714D.50008@psg.com><20081230213649.GA14175@ussenterprise.ufp.org><495A9A9C.5070409@psg.com> <75822E125BCB994F8446858C4B19F0D7086BAEFA@SUEX07-MBX-04.ad.syr.edu> Message-ID: Hi Milton, On Jan 1, 2009, at 12:52 PM, Milton L Mueller wrote: >> How are transfers going to affect > > (drum roll...) I guess we can consider what follows to be the jangling noise that conventionally follows the drum roll ;-) >> registration data quality, > > Seems it would improve it by requiring transfering parties to go > through ARIN and secure their title via accurate registrations I'll grant you that transfers might indeed improve registration data quality for those transferring parties *who choose to* go through ARIN because (a) they care about securing their title, (b) they think that securing it is best accomplished by accurate registrations, and (c) the think that accuracy is best achieved by registering with ARIN (or any other monolithic public registry). So for every transfer transaction, six independent variables (three each for both the parties involved) must be aligned properly in order for things to turn out as you suggest. Perceptions of overall registration data quality tend to fall exponentially as individual registry entries lose the qualities of timeliness, completeness, and completeness, so while it's anyone's guess how/how much overall quality would have to suffer before address resource registration data came to be regarded as "as useful as route registry data", my prediction is that it would not take all that much. >> the risk of (intentional and/or >> unintentional) address collisions > > ditto the above (likewise) >> the continuing viability of cross- >> jurisdictional IP networks/services, > > has anyone on this list noticed that RIPE-NCC has passed its > transfer policy? shouldn't this be changing the complexion of the > debate somewhat, or do we all assume here than only the US matters? How do you think that it should change the complexion of the debate Milton? Are you assuming here that one choice by one region is enough to settle all aspects of the matter globally? >> the future likelihood of IPv6 >> adoption > > Most likely, _if_ v6 migration goes slower and a transfer market > drives up the price of v4 blocks it will increase the incentive to > move to v6. A lot of "ifs" When the price of gas goes up, most US consumers don't jump into their electric cars or switch to public transportation, because the US economy has not presented most consumers with those options. Nor do you see a lot of home tinkerers building their own personal electric cars because the market has yet to deliver. If the price of IPv4 blocks goes way up, no doubt many incumbents will make use of alternatives address resources -- that has never been disputed. But with the fully loaded (even if imperfectly/unevenly realized) public IP addressing standard effectively gone, there's no reason to assume a priori that individual enterprise-level addressing strategies are going to somehow sum up to something like a new (equivalent if not better) public IP addressing standard -- i.e., something that, at the very least, would enable new entrants to participate the market without securing permission from a rival. Sure, there are always a lot of "ifs" in any assumptions or claims about the future. That's another master fact that doesn't excuse us from applying historical knowledge and common sense to plan for where to go from here. >> or any other TCP/IP-related development? > > a bit of a vague question, no? Not so much vague as all-encompassing -- but regardless I will try to be clearer. Lots of people are critical of IPv6 for lots of reasons. The statement was intended to cover IPv6 or any other future public IP addressing standard. But even more generally, there seems to be some (growing?) interest in the IETF community about why so many ostensibly useful new developments and standards have failed to be implemented over the years. One result of that interest is RFC5218 (http://tools.ietf.org/html/rfc5218 ). The text attempts to cover the problems specifically associated with IPv6 (e.g., in 2.1.2), but the RFC was really written from the standpoint of IPv4-based incumbents. In order to make it applicable for the coming era, the list of failure conditions will have to be expanded to include "lack of public IPv4 addresses," and all of the correlates of success will have to be amended with the clause, "Possess sufficient IPv4 addresses AND..." whatever notionally objective success condition was listed before. >> When the amateurs leave the field, are the professionals >> going to take over, or will "policy" simply wither away >> altogether, as earlier utopians have repeatedly predicted? > > Policy will never go away, and the creation of markets heightens the > need for making (good) policy decisions. The creation of a new market is itself a policy decision, and one that should take into full account what is known about the conditions that can be reasonably expected to result from the introduction of market incentives and all of their likely/common manifestations, given (no less, but no more than) reasonable efforts regulate or limit those manifestations. Some people still argue the market for credit default swaps could have been (& could still be) perfectly successful had there been sufficient institutional transparency and disclosure -- but these tend to be the same sort of people that staunchly defend the freedom *from* transparency and self-disclosure for both natural and artificial persons, under the right to privacy. You can't have it both ways, Milton, unless you're willing to just accept whatever comes as the best that one could have done, by definition -- a.k.a. "fatalism." > As for the "amateur" charge, I would say as someone with 25 years of > (often professional) experience in policy, law and regulation of > communications that I would not be so dismissive of the Internet > technical community's perspicacity. One often finds a shocking > historical and institutional ignorance in this community, some > bizarre ideological prejudices (as one finds in any community), > coupled with a keen sense of the implications of policy decisions on > the technical infrastructure in the here and now. It's a decidedly > mixed bag, and it's best to maintain civil dialogue that fosters > mutual learning. Hear hear! A civil dialogue and mutual learning sounds like another excellent idea for 2009 :-) Cheers, TV From bicknell at ufp.org Thu Jan 1 15:45:04 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 1 Jan 2009 15:45:04 -0500 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> References: <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> Message-ID: <20090101204504.GA25609@ussenterprise.ufp.org> In a message written on Thu, Jan 01, 2009 at 12:34:55PM -0500, Milton L Mueller wrote: > The status quo you defend so doggedly will and must end. You are > not opposing markets you are opposing the fact of scarcity, which > is (as the Canute story suggests) a futile exercise. One of the reasons I keep repeating myself is because clearly my position has not been understood by individuals such as yourself, as your statement clearly indicates. The status quo ends, however, when it does I have a markedly different view of the world than you do. I believe that: - IPv6 is deployed fairly rapidly, and with limited pain. - There will be very few holders of IPv4 space willing to part with their space at any price a black/white/grey market will offer. I also take a long term view; at this point IPv4 is walking dead. We can argue about if it lasts 5, 10, or 25 more years but almost everyone concedes an eventual move to IPv6. Thus I am concerned that we have an allocation system for IPv6 that continues to function for the next 100 years. If that goal requires some short term pain in IPv4 I believe that's an acceptable trade off. I also believe that creating a system that accelerates the move to IPv6 will in fact result in a more stable, cheaper, faster expanding global Internet. I have put forth back of the napkin calculations on the market multiple times before in this form. I have never ONCE seen a pro-market supporter offer up any numbers of any kind. As someone who likes to make decisions that are backed up by good data, science and reasoning I find that lack of input productive. I get the economics, IPv4 will become more scarce, therefor it becomes more valuable, thus it is more likely to be traded on a white/grey/black market. I also get that no regulation/rule/contractual provision works 100% of the time. These seem to be the only "facts" that the pro-market forces put forward, and I'm willing to stipulate to them. The fact is, all this talk about IPv4 and markets is taking focus off the real issue, transitioning to IPv6. Much of the IPv6 policy still assumes you have IPv4 as well, and we need to fix that. Much of the IPv6 policy was predicated on an ivory tower view of the Internet, and now that we have some operational experience we should fix that. We're going to get so caught up on allowing an extremely small number of people to legally profiteer off IPv4, and extend the life of IPv4 by 12-24 months that we'll totally blow having IPv6 ready for when people need it; making the problem worse. And lastly, I've suggested an alternative method where by IPv4 space can be redistributed. One which I think puts ARIN in a much better position with respect to the long term stability of ARIN and IPv6 allocations. To suggest I'm opposing a market when I put forth a proposal that creates one is rather silly. -- 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 mueller at syr.edu Thu Jan 1 16:11:25 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 1 Jan 2009 16:11:25 -0500 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <0A757D9D-47D6-42CF-BBEE-56FCE6692A16@delong.com> References: <7663C7E01D8E094989CA62F0B0D21CD9028B2CF6@SUEXCL-02.ad.syr.edu><70DE64CEFD6E9A4EB7FAF3A06314106601B4AC98@mail><495A714D.50008@psg.com><20081230213649.GA14175@ussenterprise.ufp.org><495A9A9C.5070409@psg.com> <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <0A757D9D-47D6-42CF-BBEE-56FCE6692A16@delong.com> Message-ID: <75822E125BCB994F8446858C4B19F0D7086BAEFC@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > The problem here, Milton, is that you assume redistribution based on > relative need is required. Yes, indeed I do. So do the people in the (gray) market and many others. If the transition period exceeds three years, which it probably will, any policy position that does not allow for legal, organized transfers is just plain irresponsible, and dismissive talk of "short term pain" (undoubtedly, pain that YOU will not feel, but someone else will) is not persuasive. > first-com/first- > served is the potential for early hoarding. However, hoarding can be > mostly avoided by requiring justified need in order to obtain the > resource and reducing (to the extent possible) the rewards available The early hoarding took place in 1982 - 97, my friend. > Those organizations who want IP connectivity after the IPv4 free pool > is exhausted can move to IPv6 and make use of transitional > technologies. True, the current state of those technologies is less > than ideal, oh well, so what if you lose internet connectivity for a while, or have to spend 4 times what you expected or are able to afford. I think i will collect these statements and publish them five years on. > but, organizations moving to IPv6 will, I suspect, drive > significant and rapid improvement in both the transitional tools, and, > the availability of IPv6 connectivity to what is currently a mostly > IPv4 only internet. What if what you "suspect" is wrong? If I am wrong about the need for a transfer market, nothing bad happens, people just don't use it. Fine with me. As I said at the IGF, it's primarily an insurance policy, and there are very few downsides to instituting it. Your only argument against it is that it somehow detracts or slows down the migration to v6. I don't buy that. I think that if migration to IPv6 depends on not having v4 transfers there are far more fundamental things wrong with v6 than we suspect, and the absence of transfer markets isn't going to save it. Indeed, that argument is so weak it makes me wonder what your real concern is. > I think it is perfectly reasonable for the following scenario: > > 1. Status quo until IANA free pool is exhausted. > 2. ARIN continues to issue under status quo until ARIN > free pool's > largest remaining block is a single /6 > 3. ARIN continues to issue what it can without invading > that /6 under > status quo rules. > 4. Applications which cannot be satisfied under status > quo rules as > stated above are rejected and applicants are encouraged to apply for > IPv6. > 5. Applicants which receive IPv6 and require IPv4 space for > transitional technologies to interconnect their IPv6 networks to the > existing IPv4 world apply for small pieces of the remaining /6 under > recently adopted policy (2008-5 if I recall correctly). Tell me what goes seriously wrong with this scenario if you insert "or to get addresses via transfers" at the end of #4. Seriously, what is the downside? The life of v4 is extended for 4-5 years to help those with trouble making the transition? Why is that bad? > A similar transition will occur when the world runs out of petroleum > products if we don't destroy the environment first. Some other stored > energy mechanism will be adopted. The transition will be painful (as > will the IPv6 transition), but, when there is no more oil, there will > be a migration to some other technology. Owen, try to imagine what the petroleum transition would be like if the price of oil was fixed and could not rise. I suspect you don't really grasp this, based on your comments over the past few months, so I don't look forward to the answer. There will never be "no more oil," there will be a more or less gradual adjustment in our use of oil to reflect its price. Take price change out of the equation however, and all hell breaks loose. Based on actual consumer responses to the gasoline price increases this past summer, many policy analysts are saying we don't need CAFE standards at all any more, we just need to increase the price of fuel via taxation and consumers will stop buying gas guzzlers. Much simpler and more effective than regulating technical efficiency standards. From owen at delong.com Thu Jan 1 17:04:25 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Jan 2009 14:04:25 -0800 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <75822E125BCB994F8446858C4B19F0D7086BAEFC@SUEX07-MBX-04.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD9028B2CF6@SUEXCL-02.ad.syr.edu><70DE64CEFD6E9A4EB7FAF3A06314106601B4AC98@mail><495A714D.50008@psg.com><20081230213649.GA14175@ussenterprise.ufp.org><495A9A9C.5070409@psg.com> <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <0A757D9D-47D6-42CF-BBEE-56FCE6692A16@delong.com> <75822E125BCB994F8446858C4B19F0D7086BAEFC@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Jan 1, 2009, at 1:11 PM, Milton L Mueller wrote: > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> The problem here, Milton, is that you assume redistribution based on >> relative need is required. > > Yes, indeed I do. So do the people in the (gray) market and many > others. If the transition period exceeds three years, which it > probably will, any policy position that does not allow for legal, > organized transfers is just plain irresponsible, and dismissive talk > of "short term pain" (undoubtedly, pain that YOU will not feel, but > someone else will) is not persuasive. Your assertion that I will not feel the pain of IPv4 runout is, at best, absurd. In fact, post IPv4 runout, absent an involuntary redistribution mechanism, I expect that the IPv6 transition will take less than 1 year to achieve critical mass and less than 3 years to become nearly ubiquitous. I expect that something like the following will happen: t-12 months 1. IANA IPv4 runout t0 2. First RIR runouts start to occur, large ISPs are SOL on new IPv4 space. t+3 months 3. About 6-12 months of transfer efforts in large blocks occurs before the large blocks that can be made available are exhausted. t+6 months 4. IPv6 transition begins in earnest t+15 months 5. RIRs start to run out of smaller blocks and smaller orgs begin hunting for transferable space. t+18-24 months 6. IPv4 routing table becomes irretrievably fragmented and smaller IPv4 blocks begin to become unreachable due to route filtering. 7. IPv6 is now deployed to nearly 30% of the existing internet and on the order of 80% of internet expansion is occurring in IPv6. t+30 months 8. IPv6 deployment continues at an accelerating pace. >> first-com/first- >> served is the potential for early hoarding. However, hoarding can be >> mostly avoided by requiring justified need in order to obtain the >> resource and reducing (to the extent possible) the rewards available > > The early hoarding took place in 1982 - 97, my friend. > While it is true that a large number of addresses were distributed in a manner which is considered wasteful by today's standards, I would not call that hoarding. The definition of the term hoarding requires a time of scarcity. That does not apply to 1982-97 and I don't believe that the mentality applicable to "hoarding" applied to organizations getting IP space at that time. >> Those organizations who want IP connectivity after the IPv4 free pool >> is exhausted can move to IPv6 and make use of transitional >> technologies. True, the current state of those technologies is less >> than ideal, > > oh well, so what if you lose internet connectivity for a while, or > have to spend 4 times what you expected or are able to afford. I > think i will collect these statements and publish them five years on. > In order to lose internet connectivity, you would have to have had it. Since these limitations would only apply to new entrants, your statement seems, at best, exaggerated. In fact, a market is more likely to cause people to suffer the consequences you describe than a lack of one. With a lack of one, those who have connectivity get to keep their status quo. With a market, economics will drive those less able to pay out of the internet in favor of those who can pay more. >> but, organizations moving to IPv6 will, I suspect, drive >> significant and rapid improvement in both the transitional tools, >> and, >> the availability of IPv6 connectivity to what is currently a mostly >> IPv4 only internet. > > What if what you "suspect" is wrong? If I am wrong about the need > for a transfer market, nothing bad happens, people just don't use > it. Fine with me. As I said at the IGF, it's primarily an insurance > policy, and there are very few downsides to instituting it. > I disagree. The existence of a market and the perception that space can be made available if you simply throw enough money at the problem will alter people's perception of the solution space. The existence of a market could well delay the implementation of IPv6 by shifting the need for transition from those who have resources and/or motivation to keep internet connectivity at a higher cost to those who lack the resources to keep their connectivity as addressing costs increase. If you really want to look at a good example of the kinds of problems an unregulated market situation can create in the allocation of scarce, but critical, resources, look at the California Electric Grid during the heyday of Enron. (The grid itself, as operated by Cal-ISO, not the various generation/delivery/etc. games that were simultaneously going on... Just the way Enron was gaming the grid is a pretty good example of the fact that profit motives can really screw up resource allocations in the presence of bad actors in the market). Consequences I expect are likely from a market that make me think it may not be the best solution: 1. Bad actors driving up costs for everyone. 2. Speculative trading in address resources driving up costs. 3. Large providers using address pricing to drive smaller competitors from the market place. 4. Speculative hoarding to create artificial shortages and price increases. 5. Minimal participation on the part of address holders. 6. Need + Theoretical Solution + Lack of Sellers = more plausible solution ignored in favor of non-solution = delay of useful solution > Your only argument against it is that it somehow detracts or slows > down the migration to v6. I don't buy that. I think that if > migration to IPv6 depends on not having v4 transfers there are far > more fundamental things wrong with v6 than we suspect, and the > absence of transfer markets isn't going to save it. Indeed, that > argument is so weak it makes me wonder what your real concern is. > That's 6 arguments against it. No, the migration to IPv6 does not depend on not having IPv4 transfers, but, the artificial perception that the creation of a market will somehow magically make vast quantities of addresses available will detract from efforts at a more permanent solution. A market is all about perception and has little to do with reality in most cases. >> I think it is perfectly reasonable for the following scenario: >> >> 1. Status quo until IANA free pool is exhausted. >> 2. ARIN continues to issue under status quo until ARIN >> free pool's >> largest remaining block is a single /6 >> 3. ARIN continues to issue what it can without invading >> that /6 under >> status quo rules. >> 4. Applications which cannot be satisfied under status >> quo rules as >> stated above are rejected and applicants are encouraged to apply for >> IPv6. >> 5. Applicants which receive IPv6 and require IPv4 space for >> transitional technologies to interconnect their IPv6 networks to the >> existing IPv4 world apply for small pieces of the remaining /6 under >> recently adopted policy (2008-5 if I recall correctly). > > Tell me what goes seriously wrong with this scenario if you insert > "or to get addresses via transfers" at the end of #4. > Seriously, what is the downside? The life of v4 is extended for 4-5 > years to help those with trouble making the transition? Why is that > bad? > See the 6 points I mentioned above. >> A similar transition will occur when the world runs out of petroleum >> products if we don't destroy the environment first. Some other stored >> energy mechanism will be adopted. The transition will be painful (as >> will the IPv6 transition), but, when there is no more oil, there will >> be a migration to some other technology. > > Owen, try to imagine what the petroleum transition would be like if > the price of oil was fixed and could not rise. I suspect you don't > really grasp this, based on your comments over the past few months, > so I don't look forward to the answer. > > There will never be "no more oil," there will be a more or less > gradual adjustment in our use of oil to reflect its price. Take > price change out of the equation however, and all hell breaks loose. > > Based on actual consumer responses to the gasoline price increases > this past summer, many policy analysts are saying we don't need CAFE > standards at all any more, we just need to increase the price of > fuel via taxation and consumers will stop buying gas guzzlers. Much > simpler and more effective than regulating technical efficiency > standards. > Sure... I bought a Prius when the price of fuel made it free. However, regardless of how we adjust our usage, unless we stop using altogether, there will come a time when we have used what exists. The more we reduce our rate of usage, the farther out we can move that date. However, there still remains the point that eventually there is a date where oil runs out. This, however, is the limit to where the oil analogy holds true to IPv4 resources. Oil being a physical commodity has some radically different properties from IPv4 addresses. One of the most valuable and useful things about the internet is that it is a tremendous equalizer in terms of access to information. As the internet currently stands, it provides a mechanism for people of widely varying resources to access a vast percentage of all human knowledge. It provides a mechanism for people of widely varying resources to easily reach vast numbers of other people. It provides a tremendously equalizing tool for social communication and political change. Moving IP addressing to a situation where people of lesser resources can be priced out of their connections in order for their addresses to be reallocated to organizations with greater resources will damage that situation. It will also make it easier for the organizations which have the resources to drive IPv6 transition to ignore IPv6 in favor of an ever more costly IPv4 status quo. Oil doesn't have these properties. I think that the Oil transition is going to be pretty painful when we hit it, regardless of how much of that pain is caused by price before we get there and how much of it is caused by the costs of actual transition. The pricing of oil this past summer had a number of other consequences that you are also ignoring above: Increased costs of food Increased costs of shipping, thus all products I believe that the price of oil this summer is a significant contributor to the current economic crisis. In fact, the part of the economic crisis that cannot be attributed to oil, seems to result from bad actors in the monetization of securities and securitization markets. Owen From tvest at pch.net Thu Jan 1 17:33:17 2009 From: tvest at pch.net (Tom Vest) Date: Thu, 1 Jan 2009 17:33:17 -0500 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <75822E125BCB994F8446858C4B19F0D7086BAEFC@SUEX07-MBX-04.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD9028B2CF6@SUEXCL-02.ad.syr.edu><70DE64CEFD6E9A4EB7FAF3A06314106601B4AC98@mail><495A714D.50008@psg.com><20081230213649.GA14175@ussenterprise.ufp.org><495A9A9C.5070409@psg.com> <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <0A757D9D-47D6-42CF-BBEE-56FCE6692A16@delong.com> <75822E125BCB994F8446858C4B19F0D7086BAEFC@SUEX07-MBX-04.ad.syr.edu> Message-ID: <6F016B16-8884-45F7-9787-8657337E0A46@pch.net> On Jan 1, 2009, at 4:11 PM, Milton L Mueller wrote: > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> The problem here, Milton, is that you assume redistribution based on >> relative need is required. > > Yes, indeed I do. So do the people in the (gray) market and many > others. If the transition period exceeds three years, which it > probably will, any policy position that does not allow for legal, > organized transfers is just plain irresponsible, and dismissive talk > of "short term pain" (undoubtedly, pain that YOU will not feel, but > someone else will) is not persuasive. > >> first-com/first- >> served is the potential for early hoarding. However, hoarding can be >> mostly avoided by requiring justified need in order to obtain the >> resource and reducing (to the extent possible) the rewards available > > The early hoarding took place in 1982 - 97, my friend. > >> Those organizations who want IP connectivity after the IPv4 free pool >> is exhausted can move to IPv6 and make use of transitional >> technologies. True, the current state of those technologies is less >> than ideal, > > oh well, so what if you lose internet connectivity for a while, or > have to spend 4 times what you expected or are able to afford. I > think i will collect these statements and publish them five years on. > >> but, organizations moving to IPv6 will, I suspect, drive >> significant and rapid improvement in both the transitional tools, >> and, >> the availability of IPv6 connectivity to what is currently a mostly >> IPv4 only internet. > > What if what you "suspect" is wrong? If I am wrong about the need > for a transfer market, nothing bad happens, people just don't use > it. Fine with me. As I said at the IGF, it's primarily an insurance > policy, and there are very few downsides to instituting it. > > Your only argument against it is that it somehow detracts or slows > down the migration to v6. I don't buy that. I think that if > migration to IPv6 depends on not having v4 transfers there are far > more fundamental things wrong with v6 than we suspect, and the > absence of transfer markets isn't going to save it. Indeed, that > argument is so weak it makes me wonder what your real concern is. > >> I think it is perfectly reasonable for the following scenario: >> >> 1. Status quo until IANA free pool is exhausted. >> 2. ARIN continues to issue under status quo until ARIN >> free pool's >> largest remaining block is a single /6 >> 3. ARIN continues to issue what it can without invading >> that /6 under >> status quo rules. >> 4. Applications which cannot be satisfied under status >> quo rules as >> stated above are rejected and applicants are encouraged to apply for >> IPv6. >> 5. Applicants which receive IPv6 and require IPv4 space for >> transitional technologies to interconnect their IPv6 networks to the >> existing IPv4 world apply for small pieces of the remaining /6 under >> recently adopted policy (2008-5 if I recall correctly). > > Tell me what goes seriously wrong with this scenario if you insert > "or to get addresses via transfers" at the end of #4. > Seriously, what is the downside? The life of v4 is extended for 4-5 > years to help those with trouble making the transition? Why is that > bad? > >> A similar transition will occur when the world runs out of petroleum >> products if we don't destroy the environment first. Some other stored >> energy mechanism will be adopted. The transition will be painful (as >> will the IPv6 transition), but, when there is no more oil, there will >> be a migration to some other technology. > > Owen, try to imagine what the petroleum transition would be like if > the price of oil was fixed and could not rise. I suspect you don't > really grasp this, based on your comments over the past few months, > so I don't look forward to the answer. > > There will never be "no more oil," there will be a more or less > gradual adjustment in our use of oil to reflect its price. Take > price change out of the equation however, and all hell breaks loose. > > Based on actual consumer responses to the gasoline price increases > this past summer, many policy analysts are saying we don't need CAFE > standards at all any more, we just need to increase the price of > fuel via taxation and consumers will stop buying gas guzzlers. Much > simpler and more effective than regulating technical efficiency > standards. ...Only in the case of the Internet, the oil companies / scarce resource distributors are the only ones who can make it possible for the alternative fuel vehicles to work, for anyone, for as long as they continue to exist. Once this fundamental difference is understood, oil makes for an excellent analogy. TV From michael.dillon at bt.com Fri Jan 2 04:48:17 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 2 Jan 2009 09:48:17 -0000 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <495C3D6E.9000101@sprunk.org> Message-ID: > OTOH, the market will be unable to supply the mega-ISPs with > space for long, if at all, simply because of their voracious > appetites. They will be weighing the cost (and odds) of > acquiring space on the open market with the cost of moving to > IPv6, and IMHO they will, in short order, decide that the > latter option is cheaper. I believe that most of the larger ISPs have already made this assessment in 2008 and decided, as you say, that IPv6 is cheaper. In addition, spending money on IPv6 is viewed as related to technology refresh, while buying IPv4 addresses is viewed as yet another patch to an aging vessel. Most large companies realize the necessity of periodic technology refresh in order to keep pace with changing markets and their strategic vendors. The fact is that almost all of the vendors which don't have IPv6 support today, sell software-based platforms which could have IPv6 capabilities in a flash, if the vendor could see a good reason to support that capability. The canonical example is the consumer internet gateway products which are almost all implemented using embedded Linux or BSD. > My view is that they will go to IPv6 as soon as it's cheaper > than staying on IPv4. An address market which increases the > cost of the latter will, hopefully, pull in that date rather > than push it out. Another good reason to oppose transfer policies is to delay the date at which we are forced to go to IPv6. Most people now know that this is inevitable, but there is still a lot of work to be done, and paid for. Operational Support Systems all have to be upgraded and tested. IP addresses are in all kinds of databases. This is one area where smaller companies still have an agility advantage over larger ones, and new entrants will soon be able to completely ignore legacy IPv4 services altogether. --Michael Dillon From rlc at usfamily.net Fri Jan 2 05:42:31 2009 From: rlc at usfamily.net (Ron Cleven) Date: Fri, 02 Jan 2009 04:42:31 -0600 (CST) Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD9028B2CF6@SUEXCL-02.ad.syr.edu><70DE64CEFD6E9A4EB7FAF3A06314106601B4AC98@mail><495A714D.50008@psg.com><20081230213649.GA14175@ussenterprise.ufp.org><495A9A9C.5070409@psg.com> <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <0A757D9D-47D6-42CF-BBEE-56FCE6692A16@delong.com> <75822E125BCB994F8446858C4B19F0D7086BAEFC@SUEX07-MBX-04.ad.syr.edu> Message-ID: <495DEF95.5050503@usfamily.net> The stupidity of this discussion is breathtaking. ARIN has yet to even begin to change its IPV4 billing policy to make the cost of IPV4 addresses uniform. That, in turn, would strongly encourage the large ISP's (where much of the momentum for IPV6 transition needs to take place) to begin the transition. At the same time, it would not hurt the "little guy", as their costs would change very little, if any. Instead, ARIN continues IPV4 billing practices that are encouraging the entirely WRONG behavior. Hello?!?!?!? For those of you who are certain that IPV6 can be a viable and reliable alternative to IPV4 in a reasonably short period of time (under the right conditions and incentives), I challenge you to get together and come up with a transition timeframe that all of you (and ARIN) are willing to sign onto as being realistic. Then work towards that goal with serious financial incentives aimed squarely at the large ISP's. If that timeframe is not within the IPV4 runout window, then ARIN has not been doing its job. It should have been ratcheting up IPV4 billing (leveling the per-ip pricing) to force such a change BEFORE calamity strikes. I am stunned at the number of people on this list who are complacent about the runout eventuality. If that timeframe is still within the IPV4 runout window, then great, the world may not end at that time, and ARIN, et al, still have time to institute coherent policies to make it happen in an ORDERLY fashion. To keep it very simple, if you assert that IPV6 is the answer, be willing to put your money where your mouth is. We should be able to establish a date in the not-too-distant future where renewal costs for large IPV4 allocations start to become prohibitively expensive. It would be really nice if everyone was pulling towards the same reasonable goal. Boss: How is that new inventory management system coming? Programmer: Great, we finished coding it, and it seems to work. Boss: So, when will we be ready to do some alpha/beta testing of the UI, stress testing, and parallel testing? Programmer: Oh, I don't see any need to do that. Boss: Wha????? Programmer: Our license for the old software expires at the end of the month, so we have to switch to the new system then. No point in worrying about it until then. It is inevitable, man. From BillD at cait.wustl.edu Fri Jan 2 06:12:11 2009 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 2 Jan 2009 05:12:11 -0600 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call References: <7663C7E01D8E094989CA62F0B0D21CD9028B2CF6@SUEXCL-02.ad.syr.edu><70DE64CEFD6E9A4EB7FAF3A06314106601B4AC98@mail><495A714D.50008@psg.com><20081230213649.GA14175@ussenterprise.ufp.org><495A9A9C.5070409@psg.com> <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <0A757D9D-47D6-42CF-BBEE-56FCE6692A16@delong.com> <75822E125BCB994F8446858C4B19F0D7086BAEFC@SUEX07-MBX-04.ad.syr.edu> <495DEF95.5050503@usfamily.net> Message-ID: LOL, when it is no laughing matter.... Very nice post to wake up to...both in the common sense that is expressed and the creative scenario. Bill Darte -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Ron Cleven Sent: Fri 1/2/2009 4:42 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call The stupidity of this discussion is breathtaking. ARIN has yet to even begin to change its IPV4 billing policy to make the cost of IPV4 addresses uniform. That, in turn, would strongly encourage the large ISP's (where much of the momentum for IPV6 transition needs to take place) to begin the transition. At the same time, it would not hurt the "little guy", as their costs would change very little, if any. Instead, ARIN continues IPV4 billing practices that are encouraging the entirely WRONG behavior. Hello?!?!?!? For those of you who are certain that IPV6 can be a viable and reliable alternative to IPV4 in a reasonably short period of time (under the right conditions and incentives), I challenge you to get together and come up with a transition timeframe that all of you (and ARIN) are willing to sign onto as being realistic. Then work towards that goal with serious financial incentives aimed squarely at the large ISP's. If that timeframe is not within the IPV4 runout window, then ARIN has not been doing its job. It should have been ratcheting up IPV4 billing (leveling the per-ip pricing) to force such a change BEFORE calamity strikes. I am stunned at the number of people on this list who are complacent about the runout eventuality. If that timeframe is still within the IPV4 runout window, then great, the world may not end at that time, and ARIN, et al, still have time to institute coherent policies to make it happen in an ORDERLY fashion. To keep it very simple, if you assert that IPV6 is the answer, be willing to put your money where your mouth is. We should be able to establish a date in the not-too-distant future where renewal costs for large IPV4 allocations start to become prohibitively expensive. It would be really nice if everyone was pulling towards the same reasonable goal. Boss: How is that new inventory management system coming? Programmer: Great, we finished coding it, and it seems to work. Boss: So, when will we be ready to do some alpha/beta testing of the UI, stress testing, and parallel testing? Programmer: Oh, I don't see any need to do that. Boss: Wha????? Programmer: Our license for the old software expires at the end of the month, so we have to switch to the new system then. No point in worrying about it until then. It is inevitable, man. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Fri Jan 2 06:26:05 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 2 Jan 2009 11:26:05 -0000 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <495DEF95.5050503@usfamily.net> Message-ID: > The stupidity of this discussion is breathtaking. ARIN has > yet to even begin to change its IPV4 billing policy to make > the cost of IPV4 addresses uniform. That, in turn, would > strongly encourage the large ISP's (where much of the > momentum for IPV6 transition needs to take > place) to begin the transition. At the same time, it would > not hurt the "little guy", as their costs would change very > little, if any. You should raise this issue on the ARIN members mailing list. They are the ones who set the fees, not us. This is the public policy list where anyone concerned with ARIN policy can influence the ARIN Advisory Council to make changes to policies. However, the AC has no control over billing at all. ARIN fees are controlled only by the ARIN members and the ARIN Board of Trustees. Also, it is worth noting that it is not ARIN's responsibility to transition the Internet to IPv6. That responsibility lies collectively on the ISPs who make up the Internet, many of whom are not in the ARIN region. > If that timeframe is still within the IPV4 runout window, > then great, the world may not end at that time, and ARIN, et > al, still have time to institute coherent policies to make it > happen in an ORDERLY fashion. When IPv4 addresses runout, the Internet will continue to function as normal. A very few people and companies will be inconvenienced as they try to ADD CONNECTIVITY, and of course, a few ISPs will find themselves in a postion where they cannot grow their IPv4 networks and therefore can no longer grow their business using IPv4. Even if everybody waits until this happens, before starting to offer commercial IPv6 services, it is still soon enough. The point that many have been making is that if an ISP begins IPv6 testing and deployment today, they will be in a position to take business away from lazy competitors when that day comes. This is not a bad thing and happens all the time in business and in society (Obama vs. George W.) so we don't need to change any policies to fix a non-existent problem. > Boss: So, when will we be ready to do some alpha/beta testing > of the UI, stress testing, and parallel testing? > > Programmer: Oh, I don't see any need to do that. > > Boss: Wha????? > > Programmer: Our license for the old software expires at the > end of the month, so we have to switch to the new system > then. No point in worrying about it until then. It is > inevitable, man. The fact is that many ISPs are already doing this kind of testing and raising issues with their vendors because of it. This kind of thing rarely is visible to the public, and IPv6 is no different. The best thing that all of us can do is to ask all of our suppliers how and when their products will *FULLY* support IPv6. A steady stream of such requests from customers and propective customers, will spur any company into action. If the market demands IPv6, then it will come. It does help if the market is willing to switch vendors based on IPv6 support capability. --Michael Dillon From rlc at usfamily.net Fri Jan 2 07:40:11 2009 From: rlc at usfamily.net (Ron Cleven) Date: Fri, 02 Jan 2009 06:40:11 -0600 (CST) Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: References: Message-ID: <495E0B28.50608@usfamily.net> >>The stupidity of this discussion is breathtaking. ARIN has >>yet to even begin to change its IPV4 billing policy to make >>the cost of IPV4 addresses uniform. That, in turn, would >>strongly encourage the large ISP's (where much of the >>momentum for IPV6 transition needs to take >>place) to begin the transition. At the same time, it would >>not hurt the "little guy", as their costs would change very >>little, if any. > > > You should raise this issue on the ARIN members mailing list. > They are the ones who set the fees, not us. I have posted the same opinion on that list, with similar: Don't worry, the change will happen. Embrace the change. Spooky, eh? It is not ARIN's job. Yes, ARIN is not the whole world, but it does influence the half of the Internet with all the largest ISP's who are in a position to actually DO something pre-emptive, but appear not to care. responses. However, more to the point, everyone on this list seems to find it quite agreeable to pontificate about every other facet of the IPV4 runout. Why not discuss how to avoid it and how to ensure the transition will be as smooth as possible? Would it not be better if large ISP's were busy making the transition EARLY? Do people have something against actually planning the transition? I realize it might be more entertaining to sit back and watch the chaos. I am not nearly so sanguine about taking the "don't worry, it will all work out" position. If that were the only position to take, I suppose I would, but the fact that it is completely unnecessary irks me just a little bit. > > This is the public policy list where anyone concerned > with ARIN policy can influence the ARIN Advisory Council > to make changes to policies. However, the AC has no > control over billing at all. > > ARIN fees are controlled only by the ARIN members and > the ARIN Board of Trustees. Yes, I'm sure these issues have been discussed ad nauseum by them with stellar results. > > Also, it is worth noting that it is not ARIN's responsibility > to transition the Internet to IPv6. That responsibility lies > collectively on the ISPs who make up the Internet, many of > whom are not in the ARIN region. So, I guess it is ok for them to continue with their policies that discourage, rather than encourage, the transition to IPV6? If it's good for GM, it's good for the country. Who was GM again? > > >>If that timeframe is still within the IPV4 runout window, >>then great, the world may not end at that time, and ARIN, et >>al, still have time to institute coherent policies to make it >>happen in an ORDERLY fashion. > > > When IPv4 addresses runout, the Internet will continue to > function as normal. A very few people and companies will > be inconvenienced as they try to ADD CONNECTIVITY, and > of course, a few ISPs will find themselves in a postion > where they cannot grow their IPv4 networks and therefore > can no longer grow their business using IPv4. > > Even if everybody waits until this happens, before starting > to offer commercial IPv6 services, it is still soon enough. > The point that many have been making is that if an ISP begins > IPv6 testing and deployment today, they will be in a position > to take business away from lazy competitors when that day > comes. This is not a bad thing and happens all the time in > business and in society (Obama vs. George W.) so we don't > need to change any policies to fix a non-existent problem. > Ahh, the IPV4 to IPV6 transition is a non-existent problem? Sorry, I didn't realize that. Ok, never mind. I can die peacefully now. > >>Boss: So, when will we be ready to do some alpha/beta testing >>of the UI, stress testing, and parallel testing? >> >>Programmer: Oh, I don't see any need to do that. >> >>Boss: Wha????? >> >>Programmer: Our license for the old software expires at the >>end of the month, so we have to switch to the new system >>then. No point in worrying about it until then. It is >>inevitable, man. > > > The fact is that many ISPs are already doing this kind of testing > and raising issues with their vendors because of it. This kind of > thing rarely is visible to the public, and IPv6 is no different. > Yep, the little tests in the lab are pretty much working out all of the kinks of IPV4/IPV6 peaceful coexistence that will come up once IPV6 begins to seriously roll out. > The best thing that all of us can do is to ask all of our suppliers > how and when their products will *FULLY* support IPv6. A steady > stream of such requests from customers and propective customers, > will spur any company into action. If the market demands IPv6, > then it will come. It does help if the market is willing to switch > vendors based on IPv6 support capability. > > --Michael Dillon I've actually made some of those calls, and most of the manufacturers are quite confident they'll be ready when IPV6 rolls out. Unless there is a downturn in the economy or something and they have to lay off a bunch of programmers. But that is unlikely, so, not to worry. Be happy. Let me put this a different way: What would prevent Comcast, Earthlink, MSN, and AOL (just to pick a few) from doing a large-scale roll-out of IPV6 in 1 month? What would prevent Comcast, Earthlink, MSN, and AOL from doing a large-scale roll-out of IPV6 in 3 months? What would prevent Comcast, Earthlink, MSN, and AOL from doing a large-scale roll-out of IPV6 in 6 months? What would prevent Comcast, Earthlink, MSN, and AOL from doing a large-scale roll-out of IPV6 in 1 year? What would make the answer to the previous question "Nothing."? From michael.dillon at bt.com Fri Jan 2 09:13:10 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 2 Jan 2009 14:13:10 -0000 Subject: [arin-ppml] Policy Proposal 2008-6:Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <495E0B28.50608@usfamily.net> Message-ID: > Why not discuss how to avoid it and how to ensure the > transition will be as smooth as possible? Because that is largely a technical discussion which is best held in other, more technical forums such as NANOG and MAAWG, and others. > Would it not be > better if large ISP's were busy making the transition EARLY? No. It is better if the transition happens when most people are ready, i.e. the vendors have fixed the critical bugs, and the operators have successfully completed their internal tests and trials. Personally, I would like to see some effort made to coordinate a whole suite of IPv6 Internet service offerings with the Olympics in 2012. China did something like that this year, and the Chinese are demonstrably much further ahead with IPv6 than the west is. Of course, we have to coordinate a lot more organizations, i.e. cat herding, so that takes more time, but the 2012 Olympics is at about the right time, and it focuses global attention in a positive way. Even if IANA runs out of free IPv4 addresses in 2010 and then ARIN or RIPE run out in 2011, most ISPs will have enough IPv4 addresses free to support growth for another year or so. Or, they could launch IPv6 in some limited way to recover IPv4 addresses to support growth in other services. > Do people have something against actually planning the > transition? I suspect that the best way to plan a transition is to gather all interested parties in a single forum dedicated to it. If you know of someone who could host an ipv6-2012 mailing list, that would be a good start. > > Also, it is worth noting that it is not ARIN's responsibility > > to transition the Internet to IPv6. That responsibility lies > > collectively on the ISPs who make up the Internet, many of > > whom are not in the ARIN region. > > So, I guess it is ok for them to continue with their policies that > discourage, rather than encourage, the transition to IPV6? > If it's good > for GM, it's good for the country. Who was GM again? If you can identify a specific area where ARIN policy actually does discourage IPv6 transition, then I'm sure that everyone would be receptive to a policy which fixes that. I'm under the impression that we dealt with most such issues a year or two ago. > I've actually made some of those calls, and most of the manufacturers > are quite confident they'll be ready when IPV6 rolls out. > Unless there > is a downturn in the economy or something and they have to lay off a > bunch of programmers. But that is unlikely, so, not to > worry. Be happy. I know of someone in a very large broadband ISP who made such a call to their supplier of DSL access boxes. The supplier said something like, "Since our boxes are based on Linux, we are ready to do a trial whenever you are." Said ISP has now gathered 100 volunteers from their technical organization and will begin trialing IPv6 broadband access in February. The name of the ISP and the supplier are irrelevant, since close to 100% of DSL and cable access boxes are based on embedding either Linux or BSD into the device. Both Linux and BSD have had IPv6 support for something like 10 years now. That includes stuff like IPv6 firewalling and IPv6 load balancing. Just because commercial vendors don't have it in their official product catalog today, does not mean there is a serious problem. This is a minor issue. A much bigger issue is backbone router vendors who fully support IPv6 in their routers, except that they process switch everything, i.e. use the slowest path through the device for IPv6. > What would prevent Comcast, Earthlink, MSN, and AOL (just to > pick a few) > from doing a large-scale roll-out of IPV6 in 1 month? Management decision making. I believe that Comcast has already rolled out IPv6, but making something technically possible, and getting management support to sell this to customers as a standard service, are two very different things. The whole NAT-PT, dns proxy, NAT64 issue does contribute to this problem because from a management viewpoint it looks like IPv6 is not fully-baked yet. However, this is mostly an engineering and scaling issue that some ISPs could work through in the absence of standards. > What would make the answer to the previous question "Nothing."? You will never get rid of the management decision making problem in your lifetime. Fact is that most managers nowadays, are people who have MBA training but do not have experience working at the coalface. They tend to be risk-averse, always trying to delay things, spread risk amongst as many people as possible, and wait until somebody else pioneers the path. --Michael Dillon P.S. the above are purely my personal opinions. From kkargel at polartel.com Fri Jan 2 09:47:09 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 2 Jan 2009 08:47:09 -0600 Subject: [arin-ppml] FW: Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACC2@mail> > I write this half-heartedly because we are just repeating the same old > positions. Those who are knee-jerk against markets (Kargel, you, etc.) > have used Herrin's simple rewording proposal to reassert their view. Yawn. > It might be more productive to debate the merits of the rewording. Anyway, > I am not knee-jerk against markets. I am adamantly against markets. There is a difference. I have thought long and hard about markets and the conclusions I come to say that markets will work temporarily, but at the expense of small companies and consumers. Rewording a bad idea still leaves you with a bad idea. It doesn't matter how you spice up zucchini, it is still zucchini when you are done. If you don't want to repeat the same old positions then quit trying to push the same old bad idea or come up with a new one. This pushing through of policies in the same manner that special interest groups push the same old bill to congress even though it gets voted down over and over until resistance is just eroded is getting old too. My position is simple, IP markets are bad, it doesn't matter how you re-word it, it doesn't matter what qualifications you put to it, an IP market would be bad for society. I do not feel that compromise is a useful tactic when the base theory is bad. Carrying on discussions about "well how about if we modified the market like.." are dysfunctional. Those are just attempts to legitimize a bad idea. It is a shame that so many people take the lazy approach of trying to regulate a problem by artificially raising the cost of the commodity without thought as to how that is going to affect the average family. In these times many families are already stretching their budgets to the breaking point. These people don't care about IPv4/IPv6, they just need their internet to work. They need it for their kids education, they need it to find jobs, to shop efficiently, for inexpensive entertainment.. Raising the cost of access by even 10% will seriously hurt these people and will significantly lower their quality of life. The cost of going to markets for IP addresses will be very significant and ultimately that cost will go to the consumer. The giant ISP's will not be affected by the cost as it is only transitory to them, they pay more for IP's they raise their consumer pricing, the operating budget stays stable. An IP market will not change things significantly as far as availability of IP over time, there are a finite number of IP addresses and when they are all consumed they are all consumed. Having an IP market may delay the runout date by some months, but that is all the effect it will have. Some people wishing to be IP brokers and make a lot of money in those months are pushing hard for the markets, as are some holders of legacy /8 space looking for an opportunity to take excessive profits from the IP space they have been hoarding unused. This will happen on the backs of ordinary people. Another effect of markets that has only been glancingly discussed is that markets would open the floodgate for government control of IP. Once IP addresses are valuated and treated as property it then becomes easy for governments to tax them. Once they are taxed then the empire builders have legitimized rationale for government control of the commodity. I have a hard time even speculating about the evils we will see if the internet becomes controlled by a motley collection of local governments. Discussions of IPv4 market are probably the biggest thing that is keeping holders of unused IP space from allowing it to be reclaimed. As long as people keep raising the hopes that this hoard will have great future value nobody other than a few good socially conscious people are going to release the resource. > > The thing I find odd about people who believe both of these things > > is they seem to have been for "needs based" allocation in the past. > > Nothing odd here. The IGP paper and other analyses have explained why the > rationale for needs-based administrative allocation breaks down completely > when the free pool is exhausted. Once the free space is gone it is no > longer about "need" is it is about "relative need"; i.e., it is possible > for 2 - N applicants for the same address space to have fully justified > claims on the same amount of the address space. At that point the > administrator has to use some criterion other than "need" to redistribute > the resource. What will it be? First come first served till its gone. > > Even if there are no market-based transfers, the definition of "need" will > change radically, to reflect the greater scarcity, as ARIN will be forced > to impose tougher standards of what constitutes need based on this > relativistic (scarcity-based) assessment, and to reassess the allocations > of people who got them based on "need" in the past in order to reclaim > them for other uses. > > The status quo you defend so doggedly will and must end. You are not > opposing markets you are opposing the fact of scarcity, which is (as the > Canute story suggests) a futile exercise. > > 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 info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From kkargel at polartel.com Fri Jan 2 10:04:16 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 2 Jan 2009 09:04:16 -0600 Subject: [arin-ppml] Policy Proposal 2008-6 In-Reply-To: References: <495ADB40.4030009@indiana.edu> <20081231142621.GA53224@ussenterprise.ufp.org> <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACB1@mail> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACC3@mail> > -----Original Message----- > From: Jo Rhett [mailto:jrhett at svcolo.com] > Sent: Wednesday, December 31, 2008 4:23 PM > To: Kevin Kargel > Cc: Leo Bicknell; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 2008-6 > > On Dec 31, 2008, at 6:32 AM, Kevin Kargel wrote: > > I have often wondered about this "black market" myself.. everyone > > talks > > about it, but in 15+ years of working in Internet I have never been > > approached and offered IP addresses for sale. I have never seen > > anyone > > I take it you aren't a directly listed ARIN contact? > > I get ~12 queries per year about buying IP address space. I guess it depends on what you mean a being an ARIN contact.. I am not associated with ARIN in an official capacity other than as a member at large, no, but I am POC in a number of records such as: Name: Kargel, Kevin Handle: KK564-ARIN Company: Polar Communications Address: Polar Communications Address: 110 4th Street East City: Park River StateProv: ND PostalCode: 58270 Country: US Comment: Resources Used By Organization: POLAR COMMUNICATIONS (AS14511) POLAR-COMMUNICATIONS 14511 POLAR COMMUNICATIONS POLARCOMM-BLK-1 (NET-66-231-96-0-1) 66.231.96.0 - 66.231.127.255 POLAR COMMUNICATIONS POLARCOMM-BLK-2 (NET-216-196-64-0-1) 216.196.64.0 - 216.196.95.255 POLAR COMMUNICATIONS POLARCOMM-V6 (NET6-2610-188-1) 2610:0188:0000:0000:0000:0000:0000:0000 - 2610:0188:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF TechHandle: KK564-ARIN TechName: Kargel, Kevin TechPhone: +1-701-284-7221 TechEmail: kkargel at polartel.com We are a relatively small organization as IP goes though, so I might not be on the top of the marketing lists.. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From rlc at usfamily.net Fri Jan 2 10:24:50 2009 From: rlc at usfamily.net (Ron Cleven) Date: Fri, 02 Jan 2009 09:24:50 -0600 (CST) Subject: [arin-ppml] Policy Proposal 2008-6:Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: References: Message-ID: <495E31BF.5050408@usfamily.net> michael.dillon at bt.com wrote: >>Why not discuss how to avoid it and how to ensure the >>transition will be as smooth as possible? > > > Because that is largely a technical discussion which is > best held in other, more technical forums such as NANOG > and MAAWG, and others. > But everyone on this list continues to discuss related issues forever while ignoring the central issues. However, I get it, it's not your job, it's not ARIN's job, it's not my job, mon ... > >>Would it not be >>better if large ISP's were busy making the transition EARLY? > I don't mean early before it worked. My premise was that all the IPV6 champions would get together and work out a realistic timeframe and goals. I mean early as in as soon as that timeframe is reached. > > No. It is better if the transition happens when most people > are ready, i.e. the vendors have fixed the critical bugs, > and the operators have successfully completed their internal > tests and trials. > > Personally, I would like to see some effort made to coordinate > a whole suite of IPv6 Internet service offerings with the > Olympics in 2012. China did something like that this year, > and the Chinese are demonstrably much further ahead with > IPv6 than the west is. Of course, we have to coordinate a > lot more organizations, i.e. cat herding, so that takes more > time, but the 2012 Olympics is at about the right time, and > it focuses global attention in a positive way. Even if IANA > runs out of free IPv4 addresses in 2010 and then ARIN or > RIPE run out in 2011, most ISPs will have enough IPv4 addresses > free to support growth for another year or so. Or, they could > launch IPv6 in some limited way to recover IPv4 addresses to > support growth in other services. > The good news is that the Chinese will be prepared to launch all-out IPV6 attacks just like they do IPV4 attacks. How nice for them. > >>Do people have something against actually planning the >>transition? > > > I suspect that the best way to plan a transition is to gather > all interested parties in a single forum dedicated to it. > If you know of someone who could host an ipv6-2012 mailing > list, that would be a good start. > The answer is always to have another meeting. > >>>Also, it is worth noting that it is not ARIN's responsibility >>>to transition the Internet to IPv6. That responsibility lies >>>collectively on the ISPs who make up the Internet, many of >>>whom are not in the ARIN region. >> >>So, I guess it is ok for them to continue with their policies that >>discourage, rather than encourage, the transition to IPV6? >>If it's good >>for GM, it's good for the country. Who was GM again? > > > If you can identify a specific area where ARIN policy actually does > discourage IPv6 transition, then I'm sure that everyone would be > receptive to a policy which fixes that. I'm under the impression that > we dealt with most such issues a year or two ago. > You might want to re-read my first post. That was the entire thrust of it. ARIN discourages IPV6 transition by charging IPV4 renewal rates that favor large ISP's. The renewal rates should be a flat per-ip rate. Give the windfall to charity. > >>I've actually made some of those calls, and most of the manufacturers >>are quite confident they'll be ready when IPV6 rolls out. >>Unless there >>is a downturn in the economy or something and they have to lay off a >>bunch of programmers. But that is unlikely, so, not to >>worry. Be happy. > > > I know of someone in a very large broadband ISP who made such a call > to their supplier of DSL access boxes. The supplier said something > like, "Since our boxes are based on Linux, we are ready to do a trial > whenever you are." Said ISP has now gathered 100 volunteers from their > technical organization and will begin trialing IPv6 broadband access in > February. The name of the ISP and the supplier are irrelevant, since > close to 100% of DSL and cable access boxes are based on embedding > either > Linux or BSD into the device. Both Linux and BSD have had IPv6 support > for something like 10 years now. That includes stuff like IPv6 > firewalling > and IPv6 load balancing. Just because commercial vendors don't have it > in their official product catalog today, does not mean there is a > serious > problem. This is a minor issue. > > A much bigger issue is backbone router vendors who fully support IPv6 > in their routers, except that they process switch everything, i.e. use > the slowest path through the device for IPv6. > > >>What would prevent Comcast, Earthlink, MSN, and AOL (just to >>pick a few) >>from doing a large-scale roll-out of IPV6 in 1 month? > > > Management decision making. I believe that Comcast has already rolled > out IPv6, but making something technically possible, and getting > management support to sell this to customers as a standard service, > are two very different things. The whole NAT-PT, dns proxy, NAT64 > issue does contribute to this problem because from a management > viewpoint it looks like IPv6 is not fully-baked yet. However, this > is mostly an engineering and scaling issue that some ISPs could work > through in the absence of standards. > I am NOT (I thought this was obvious) referring to issues that involve the short-sidedness of management. I am referring to legitimate technical and business issues. Things like: Costs, timeframe to roll out, and availability of routers and router software. Compatibility with the rest of the world's infrastructure. (Do the customer's games stop working? Do the customer's routers stop working? Do the customer's VOIP devices stop working? Do the old versions of Windoze stop working? etc. etc.) How many customers would they lose if they force them to convert? > >>What would make the answer to the previous question "Nothing."? > > > You will never get rid of the management decision making problem in > your lifetime. Fact is that most managers nowadays, are people who > have MBA training but do not have experience working at the coalface. > They tend to be risk-averse, always trying to delay things, spread > risk amongst as many people as possible, and wait until somebody > else pioneers the path. > > --Michael Dillon > > P.S. the above are purely my personal opinions. > From spiffnolee at yahoo.com Fri Jan 2 11:35:15 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Fri, 2 Jan 2009 08:35:15 -0800 (PST) Subject: [arin-ppml] Fees for discouraging IPv4 (was: completely unrelated to 2008-6) References: <7663C7E01D8E094989CA62F0B0D21CD9028B2CF6@SUEXCL-02.ad.syr.edu><70DE64CEFD6E9A4EB7FAF3A06314106601B4AC98@mail><495A714D.50008@psg.com><20081230213649.GA14175@ussenterprise.ufp.org><495A9A9C.5070409@psg.com> <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <0A757D9D-47D6-42CF-BBEE-56FCE6692A16@delong.com> <75822E125BCB994F8446858C4B19F0D7086BAEFC@SUEX07-MBX-04.ad.syr.edu> <495DEF95.5050503@usfamily.net> Message-ID: <323666.16144.qm@web63301.mail.re1.yahoo.com> Ron Cleven said: > The stupidity of this discussion is breathtaking. I disagree. Some very well-informed and well-intentioned people are trying to communicate their differences of well-considered opinion. > ARIN has yet to even > begin to change its IPV4 billing policy to make the cost of IPV4 > addresses uniform. In another message you clarify: > The renewal rates should be a flat per-ip rate A few people have advocated for that structure; see below. > Instead, ARIN continues IPV4 billing practices that are encouraging the > entirely WRONG behavior. Hello?!?!?!? Hello! The membership has not called for a change in the fee structure. It was last discussed in October 2008: http://lists.arin.net/pipermail/arin-discuss/2008-October/thread.html#1090 Before that, it was discussed in October 2007: http://lists.arin.net/pipermail/arin-discuss/2007-October/thread.html#432 In the 2008 thread, I think there's one person proposing fee changes, and one saying not to bother. In the 2007 thread, I count three people saying fees should be higher for larger organizations, two people saying fees are about right, three people saying they want lower fees, and two saying they don't have enough information. I don't see anything like consensus-guidance for the Board. The FinCom has considered about a dozen different proposals, and in the absence of member consensus or financial change for the organization, has not substantially changed IPv4 fees. I think both of those threads were moved from PPML to ARIN-Discuss. I encourage you to have a member post a proposal there, either for a fee schedule, or for a philosophy by which the FinCom could derive a fee schedule. Lee ARIN Treasurer, among other things From bill at herrin.us Fri Jan 2 12:46:05 2009 From: bill at herrin.us (William Herrin) Date: Fri, 2 Jan 2009 12:46:05 -0500 Subject: [arin-ppml] Fees for discouraging IPv4 (was: completely unrelated to 2008-6) In-Reply-To: <323666.16144.qm@web63301.mail.re1.yahoo.com> References: <7663C7E01D8E094989CA62F0B0D21CD9028B2CF6@SUEXCL-02.ad.syr.edu> <20081230213649.GA14175@ussenterprise.ufp.org> <495A9A9C.5070409@psg.com> <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <0A757D9D-47D6-42CF-BBEE-56FCE6692A16@delong.com> <75822E125BCB994F8446858C4B19F0D7086BAEFC@SUEX07-MBX-04.ad.syr.edu> <495DEF95.5050503@usfamily.net> <323666.16144.qm@web63301.mail.re1.yahoo.com> Message-ID: <3c3e3fca0901020946i3b50f45ek34e6eaae2c5d667a@mail.gmail.com> On Fri, Jan 2, 2009 at 11:35 AM, Lee Howard wrote: >> The renewal rates should be a flat per-ip rate > > A few people have advocated for that structure; see below. Lee, For the record, you can include me in the list of advocates, though I have no idea what to do with the excess money. It would take totals rather higher than ARIN's annual budget for the XL's to treat conservation as a financial rather than moral issue. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From matthew at matthew.at Fri Jan 2 13:04:51 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 02 Jan 2009 10:04:51 -0800 Subject: [arin-ppml] FW: Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACC2@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACC2@mail> Message-ID: <495E5743.7050506@matthew.at> Kevin Kargel wrote: > It is a shame that so many people take the lazy approach of trying to > regulate a problem by artificially raising the cost of the commodity without > thought as to how that is going to affect the average family. Yes. Instead of raising the price of beef when there's a shortage of cows, we should keep the price at the same government-set family-friendly value, and then have everyone stand in very long lines when it arrives at the butcher. I believe this was actually tried, in practice, so there's millions of folks you can ask about how it went. > > Discussions of IPv4 market are probably the biggest thing that is keeping > holders of unused IP space from allowing it to be reclaimed. As long as > people keep raising the hopes that this hoard will have great future value > nobody other than a few good socially conscious people are going to release > the resource. > > > Yes. The socially conscious people who also have zero transition cost, or who are so socially conscious that they are willing to donate their own time and equipment budgets (or those of their employer) to giving the addresses to others. The much larger group of people who would really like to release address space, but who can't get the budget from their CIO aren't going to be providing to this cause. Also not releasing their addresses are people who have address space now, and are concerned that without a way to trade it around they might never be able to get any back at any price, so will just hold theirs "just in case." And, of course we'll totally ignore the fact that transfers are already going on and will continue to go on because there is no way to stop them while continuing to allow legitimate business practices like merger and acquisition. > First come first served till its gone. > > We know that ARIN has decided to follow that course *now*, we're discussing the part that happens *after* "its gone". This would be easier if, at runout, all of the already-allocated addresses also stopped working entirely. But that's not the case, and so transfer (one way or another) will happen, and the only question is "how many lawyers do you have to hire?" Matthew Kaufman From rlc at usfamily.net Fri Jan 2 13:29:35 2009 From: rlc at usfamily.net (Ron Cleven) Date: Fri, 02 Jan 2009 12:29:35 -0600 (CST) Subject: [arin-ppml] Fees for discouraging IPv4 In-Reply-To: <323666.16144.qm@web63301.mail.re1.yahoo.com> References: <7663C7E01D8E094989CA62F0B0D21CD9028B2CF6@SUEXCL-02.ad.syr.edu><70DE64CEFD6E9A4EB7FAF3A06314106601B4AC98@mail><495A714D.50008@psg.com><20081230213649.GA14175@ussenterprise.ufp.org><495A9A9C.5070409@psg.com> <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <0A757D9D-47D6-42CF-BBEE-56FCE6692A16@delong.com> <75822E125BCB994F8446858C4B19F0D7086BAEFC@SUEX07-MBX-04.ad.syr.edu> <495DEF95.5050503@usfamily.net> <323666.16144.qm@web63301.mail.re1.yahoo.com> Message-ID: <495E5D08.6070907@usfamily.net> > >>The stupidity of this discussion is breathtaking. > > > I disagree. Some very well-informed and well-intentioned people are > trying to communicate their differences of well-considered opinion. > I agree. There are extremely intelligent people on this list all very expert in their respective fields. I am taking issue with what IS being discussed, and, more to the point, what IS NOT being discussed. They are largely spending their time discussing peripheral issues that would not even BE issues if the central issues were properly addressed. It would be nice to see all that brain-power put to use to AVOID the IPV4 runout rather than treating it as an inevitability and discussing what to do after it happens. Everyone seems to act as if there is no solution, no way to force IPV6 to be rolled out. There is, albeit I fear there may not be enough time left to do it. Just focus on forcing the large ISP's in this country to switch IN ADVANCE of the IPV4 runout. The rest of world would follow, and all the products that needed to work cleanly in the mixed IPV4/IPV6 world would magically be made to work cleanly or the companies would be out of business. Many people seem to worry about what to do with all that excess money that ARIN will collect by flat per-ip renewal pricing. For those that read my original post, I am proposing setting an IPV6 date-certain that everyone agrees is reasonable to radically ratchet up the renewal cost of the IPV4 addresses. Hence, if they believe in their own IPV6 hype, they should know that their will be no excess revenue for ARIN, because, all large ISP's will do the financially reasonable thing and convert to IPV6. Ultimately this will result in a flood of free IPV4 addresses. However, if a few ISP's don't move fast enough, just use the money for computer science scholarships or a 200-foot dike around New Orleans. There may be other better ways to completely avoid the IPV4 runout. I would love to hear the discussion focus along those lines. Just stop getting mired in the can't-do world. To borrow a phrase, "Yes, we can." or maybe, "Yes, ICANN." > >>ARIN has yet to even >>begin to change its IPV4 billing policy to make the cost of IPV4 >>addresses uniform. > > > In another message you clarify: > >>The renewal rates should be a flat per-ip rate > > > A few people have advocated for that structure; see below. > > >>Instead, ARIN continues IPV4 billing practices that are encouraging the >>entirely WRONG behavior. Hello?!?!?!? > > > Hello! > > The membership has not called for a change in the fee structure. > It was last discussed in October 2008: > http://lists.arin.net/pipermail/arin-discuss/2008-October/thread.html#1090 > Before that, it was discussed in October 2007: > http://lists.arin.net/pipermail/arin-discuss/2007-October/thread.html#432 > > In the 2008 thread, I think there's one person proposing fee changes, > and one saying not to bother. > In the 2007 thread, I count three people saying fees should be higher for > larger organizations, two people saying fees are about right, three people > saying they want lower fees, and two saying they don't have enough > information. I don't see anything like consensus-guidance for the Board. > The FinCom has considered about a dozen different proposals, and in the > absence of member consensus or financial change for the organization, > has not substantially changed IPv4 fees. Don't have to worry about them thinking outside of any boxes. > > I think both of those threads were moved from PPML to ARIN-Discuss. > I encourage you to have a member post a proposal there, either for a > fee schedule, or for a philosophy by which the FinCom could derive a > fee schedule. > > Lee > ARIN Treasurer, among other things > From bill at herrin.us Fri Jan 2 13:31:48 2009 From: bill at herrin.us (William Herrin) Date: Fri, 2 Jan 2009 13:31:48 -0500 Subject: [arin-ppml] 2008-6 inscrutable? Message-ID: <3c3e3fca0901021031ka2b1510k8373e215b3d57b10@mail.gmail.com> On Mon, Dec 29, 2008 at 7:18 PM, William Herrin wrote: > On Tue, Dec 23, 2008 at 2:15 PM, Member Services wrote: >> Policy statement: >> >> 8.4 Emergency Transfer Policy for IPv4 Addresses >> >> For a period of 3 years from policy implementation, ARIN-region number >> resources may be released, in whole or in part, to ARIN or another >> organization, by the authorized holder of the resource. >> >> Number resources may only be received under RSA, with demonstrated need, >> in the exact amount which they are able to justify under ARIN >> resource-allocation policies. > > > The language here seems labyrinthine, almost government-speak. Even > knowing that this was a transfer proposal, I had to parse it phrase by > phrase before I caught on that "or another organization" means you can > gift the released addresses to a specific registrant. Hi folks, Can we take a break from the flame war long enough to discuss this? I did not observe anyone replying to my comments by stating a belief that the policy language above is clear and concise. Notwithstanding the differing views on whether the proposed policy is good, is there is general agreement that the policy language is rather enigmatic? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From kkargel at polartel.com Fri Jan 2 14:08:58 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 2 Jan 2009 13:08:58 -0600 Subject: [arin-ppml] FW: Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <495E5743.7050506@matthew.at> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACC2@mail> <495E5743.7050506@matthew.at> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACCA@mail> > Kevin Kargel wrote: > > It is a shame that so many people take the lazy approach of trying to > > regulate a problem by artificially raising the cost of the commodity > without > > thought as to how that is going to affect the average family. > Yes. Instead of raising the price of beef when there's a shortage of > cows, we should keep the price at the same government-set > family-friendly value, and then have everyone stand in very long lines > when it arrives at the butcher. Umm, when there are only four steaks left and 40 people that want them aren't there going to be lines no matter what the price? > > I believe this was actually tried, in practice, so there's millions of > folks you can ask about how it went. > > > > Discussions of IPv4 market are probably the biggest thing that is > keeping > > holders of unused IP space from allowing it to be reclaimed. As long as > > people keep raising the hopes that this hoard will have great future > value > > nobody other than a few good socially conscious people are going to > release > > the resource. > > > > > > > Yes. The socially conscious people who also have zero transition cost, > or who are so socially conscious that they are willing to donate their > own time and equipment budgets (or those of their employer) to giving > the addresses to others. While rare, there are altruistic people and even altruistic companies out there that are concerned and active about social ethics. All I can do is bemoan their rarity and applaud their efforts and sacrifice. > > The much larger group of people who would really like to release address > space, but who can't get the budget from their CIO aren't going to be > providing to this cause. Also not releasing their addresses are people > who have address space now, and are concerned that without a way to > trade it around they might never be able to get any back at any price, > so will just hold theirs "just in case." Yes, and the possibility of a profitable market is what is reinforcing the "just in case" mentality. > > And, of course we'll totally ignore the fact that transfers are already > going on and will continue to go on because there is no way to stop them > while continuing to allow legitimate business practices like merger and > acquisition. > > First come first served till its gone. Again with the "Everyone else gets to do it Mom!" argument.. You have a choice, you can do things properly and ethically or not, you don't have to base your decision on comparative behavior. > > > > > We know that ARIN has decided to follow that course *now*, we're > discussing the part that happens *after* "its gone". > > This would be easier if, at runout, all of the already-allocated > addresses also stopped working entirely. But that's not the case, and so > transfer (one way or another) will happen, and the only question is "how > many lawyers do you have to hire?" Then perhaps we need to revisit the concept of not servicing defunct or obsolete registrations, with a grace period to renew (with a contract) before they are reallocated.. That should get some admins to refresh their data. I believe there were proposals along these lines in the not too distant past. > > Matthew Kaufman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From matthew at matthew.at Fri Jan 2 14:23:20 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 02 Jan 2009 11:23:20 -0800 Subject: [arin-ppml] FW: Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACCA@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACC2@mail> <495E5743.7050506@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACCA@mail> Message-ID: <495E69A8.3080502@matthew.at> Kevin Kargel wrote: >> Kevin Kargel wrote: >> >>> It is a shame that so many people take the lazy approach of trying to >>> regulate a problem by artificially raising the cost of the commodity >>> >> without >> >>> thought as to how that is going to affect the average family. >>> >> Yes. Instead of raising the price of beef when there's a shortage of >> cows, we should keep the price at the same government-set >> family-friendly value, and then have everyone stand in very long lines >> when it arrives at the butcher. >> > > Umm, when there are only four steaks left and 40 people that want them > aren't there going to be lines no matter what the price? > > The price should rise to that which only the top four bidders can afford, no? But my view is that if the price got *that* high, there wouldn't be "only four steaks left" any more... a whole lot of people could figure out how to renumber out of (most of) their space if that happened, *or* it would be expensive enough that the cost (mostly non-monetary) of using IPv6 instead wouldn't seem that bad. >> The socially conscious people who also have zero transition cost, >> or who are so socially conscious that they are willing to donate their >> own time and equipment budgets (or those of their employer) to giving >> the addresses to others. >> > > While rare, there are altruistic people and even altruistic companies out > there that are concerned and active about social ethics. All I can do is > bemoan their rarity and applaud their efforts and sacrifice. > > They're mostly people not subject to shareholder lawsuits for not doing the best thing for the company (in the next quarter). Matthew Kaufman From kkargel at polartel.com Fri Jan 2 14:36:25 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 2 Jan 2009 13:36:25 -0600 Subject: [arin-ppml] FW: Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <495E69A8.3080502@matthew.at> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACC2@mail> <495E5743.7050506@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACCA@mail> <495E69A8.3080502@matthew.at> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACCD@mail> > > Umm, when there are only four steaks left and 40 people that want them > > aren't there going to be lines no matter what the price? > > > > > The price should rise to that which only the top four bidders can > afford, no? Sure, if you are ok with the president of AOL getting the four steaks then I guess that would work.. > > But my view is that if the price got *that* high, there wouldn't be > "only four steaks left" any more... a whole lot of people could figure > out how to renumber out of (most of) their space if that happened, *or* > it would be expensive enough that the cost (mostly non-monetary) of > using IPv6 instead wouldn't seem that bad. > >> The socially conscious people who also have zero transition cost, > >> or who are so socially conscious that they are willing to donate their > >> own time and equipment budgets (or those of their employer) to giving > >> the addresses to others. > >> > > > > While rare, there are altruistic people and even altruistic companies > out > > there that are concerned and active about social ethics. All I can do > is > > bemoan their rarity and applaud their efforts and sacrifice. > > > > > They're mostly people not subject to shareholder lawsuits for not doing > the best thing for the company (in the next quarter). Assuming what your mean by "the best thing" is making as many dollars as possible without regard to ethics, ok.. I can buy that.. This is actually one of the reasons I really enjoy working for a cooperative as opposed to a corporation. We really can work for the best interests of our members and community instead concentrating solely on maximizing profit. I am much happier not having to continually take maximum advantage of our customers. Karma is better and I sleep well at night. > > Matthew Kaufman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From schnizlein at isoc.org Fri Jan 2 15:07:47 2009 From: schnizlein at isoc.org (John Schnizlein) Date: Fri, 2 Jan 2009 15:07:47 -0500 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <20090101204504.GA25609@ussenterprise.ufp.org> References: <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <20090101204504.GA25609@ussenterprise.ufp.org> Message-ID: I think this message of Leo's is one of the most helpful in a thread that has produced some distinctly unhelpful remarks. Attempted discussion of details embedded in context: On 2009Jan1, at 3:45 PM, Leo Bicknell wrote: > > The status quo ends, however, when it does I have a markedly different > view of the world than you do. I believe that: > > - IPv6 is deployed fairly rapidly, and with limited pain. What would prompt this sort of radical change from the deplorably slow deployment over the last several years? > - There will be very few holders of IPv4 space willing to part with > their space at any price a black/white/grey market will offer. The only way to find out is to register transfers. Avoiding registration makes it hard to know. > I also take a long term view; at this point IPv4 is walking dead. > We can argue about if it lasts 5, 10, or 25 more years but almost > everyone concedes an eventual move to IPv6. Thus I am concerned > that we have an allocation system for IPv6 that continues to function > for the next 100 years. If that goal requires some short term pain > in IPv4 I believe that's an acceptable trade off. I also believe > that creating a system that accelerates the move to IPv6 will in > fact result in a more stable, cheaper, faster expanding global > Internet. We agree that hastening the transition to IPv6 is in the global interest. I am concerned that the lack of financial incentive to undertake the non-trivial effort of conversion from IPv4 to IPv6 has already spawned renewed and expanded interest in IPv4 address translation. Unless something happens soon to change the current slow progress, I fear the IPv4-translation approaches might become so well entrenched that they become yet another obstacle to deployment of a network-layer Internet protocol with sufficient addresses for the globe. > I have put forth back of the napkin calculations on the market > multiple times before in this form. I have never ONCE seen a > pro-market supporter offer up any numbers of any kind. As someone > who likes to make decisions that are backed up by good data, science > and reasoning I find that lack of input productive. I have seen very few "pro-market supporter" positions, and fear this paragraph is a little too much like the p*@@*^% contests we have seen too much of in this thread. What I have seen quite a bit more is the view that markets are inevitable when resources become scarce. It may be that our community is split between those who believe this is an inescapable fact of economics and those who dispute it. We should be able to find workable address policy that can accommodate whichever of these beliefs is correct. > I get the economics, IPv4 will become more scarce, therefor it > becomes more valuable, thus it is more likely to be traded on a > white/grey/black market. I also get that no regulation/rule/ > contractual > provision works 100% of the time. These seem to be the only "facts" > that the pro-market forces put forward, and I'm willing to stipulate > to them. > > The fact is, all this talk about IPv4 and markets is taking focus > off the real issue, transitioning to IPv6. Much of the IPv6 policy > still assumes you have IPv4 as well, and we need to fix that. Much > of the IPv6 policy was predicated on an ivory tower view of the > Internet, and now that we have some operational experience we should > fix that. We may agree that the "long period of coexistence" was not a feasible transition plan. A real transition plan is still needed. > We're going to get so caught up on allowing an extremely > small number of people to legally profiteer off IPv4, and extend > the life of IPv4 by 12-24 months that we'll totally blow having > IPv6 ready for when people need it; making the problem worse. I don't know that there are enough organizations holding enough spare IPv4 addresses to make much of a market. Maybe we just agree on the "extremely small number of people" here. I can imagine that some organization holding enough IPv4 address space to make a difference (don't have any idea how much that is, but legacy class-C holders certainly do not qualify) could plan a conversion from IPv4 to IPv6 well enough to contract with enough equipment vendors and service providers to enable giving up its IPv4 space at a specific future time. It would cost this organization to modify its contracts with its providers and deploy IPv6. One way to motivate them to actually carry out this effort would be if they could realize compensation for giving up the IPv4 addresses. Just a few instances of large-enough organizations accomplishing the conversion to IPv6 might provide enough proof of feasibility to accelerate conversion by others. After all, the suppliers of those large-enough organizations would be interoperable over IPv6. The chicken-and-egg dilemma that now seems to delay widespread deployment of IPv6 might be broken if this scenario is played out. Compensation for giving up IPv4 addresses would be provided by organizations that choose to deploy more IPv4 rather than attempt conversion now. We can justify that hey would have to pay for address space, in part because they are not doing the Right Thing. If done right, the value of scarce IPv4 addresses increases enough to motivate conversion to IPv6, and then plummets to zero. It is possible that some parties attempt to get rich trading in IPv4 addresses, but they would be warned in advance that IPv4 addresses are a perishable commodity, and that any purchase of address space might be hastening the radical devaluing of IPv4 addresses. > And lastly, I've suggested an alternative method where by IPv4 space > can be redistributed. One which I think puts ARIN in a much better > position with respect to the long term stability of ARIN and IPv6 > allocations. To suggest I'm opposing a market when I put forth a > proposal that creates one is rather silly. It seems to me that operating a market for IPv4 addresses is a risky business. Geoff Huston has made a (persuasive to me) argument that RIRs should not attempt to act as regulators, which is what the requirement that the recipient justify its need for IPv4 address space implies. It is worth noting that RIPE has recently changed its policy to allow transfers, just after including this requirement, which it previously excluded as did APNIC. I suspect that the economic events that spread across the globe since September 2007 will prompt real regulators to want to be involved wherever there is a market. RIRs are not likely to withstand the attention of government regulators IMHO. I would not oppose the regulatory implication of the recipient justification, but expect that it will be overtaken by events. But if getting into the regulation business is risky, just imagine the risk of operating an address market as the target of regulators! Every price and transaction would be subject to scrutiny of its fairness by parties involved in the transaction and others. During the time that governments appear to be pursuing greater regulation of already established markets, a new lucrative market in IPv4 addresses would likely draw attention. What would risk the existence of RIRs less, and help preserve the stability of the Internet would be reliable registration of address authorization-to-use. John From stephen at sprunk.org Fri Jan 2 15:25:56 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 02 Jan 2009 14:25:56 -0600 Subject: [arin-ppml] 2008-6 inscrutable? In-Reply-To: <3c3e3fca0901021031ka2b1510k8373e215b3d57b10@mail.gmail.com> References: <3c3e3fca0901021031ka2b1510k8373e215b3d57b10@mail.gmail.com> Message-ID: <495E7854.7040407@sprunk.org> William Herrin wrote: > On Mon, Dec 29, 2008 at 7:18 PM, William Herrin wrote: > >> On Tue, Dec 23, 2008 at 2:15 PM, Member Services wrote: >> >>> Policy statement: >>> >>> 8.4 Emergency Transfer Policy for IPv4 Addresses >>> >>> For a period of 3 years from policy implementation, ARIN-region number resources may be released, in whole or in part, to ARIN or another organization, by the authorized holder of the resource. >>> >>> Number resources may only be received under RSA, with demonstrated need, in the exact amount which they are able to justify under ARIN resource-allocation policies. >>> >> The language here seems labyrinthine, almost government-speak. Even knowing that this was a transfer proposal, I had to parse it phrase by phrase before I caught on that "or another organization" means you can gift the released addresses to a specific registrant. >> > > Hi folks, > > Can we take a break from the flame war long enough to discuss this? > Please! > I did not observe anyone replying to my comments by stating a belief that the policy language above is clear and concise. Notwithstanding the differing views on whether the proposed policy is good, is there is general agreement that the policy language is rather enigmatic? > *shrug* I understood the intent the first time I read it, it doesn't seem worse than many existing parts of the NRPM. Our community does seem to prefer legalistic wording (say, compared to other RIRs), perhaps because it is more precise. S -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From rlc at usfamily.net Fri Jan 2 15:20:16 2009 From: rlc at usfamily.net (Ron Cleven) Date: Fri, 02 Jan 2009 14:20:16 -0600 (CST) Subject: [arin-ppml] FW: Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACCD@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACC2@mail> <495E5743.7050506@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACCA@mail> <495E69A8.3080502@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACCD@mail> Message-ID: <495E76F2.3010008@usfamily.net> Kevin Kargel wrote: >>>Umm, when there are only four steaks left and 40 people that want them >>>aren't there going to be lines no matter what the price? >>> >>> >> >>The price should rise to that which only the top four bidders can >>afford, no? > > > Sure, if you are ok with the president of AOL getting the four steaks then I > guess that would work.. > My bet is that president of AOL is going to get fired when his Board of Directors finds out that he paid a million dollars for 4 steaks and everyone else is eating chicken (IPv6) for free. From kkargel at polartel.com Fri Jan 2 15:52:38 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 2 Jan 2009 14:52:38 -0600 Subject: [arin-ppml] FW: Policy Proposal 2008-6:Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <495E76F2.3010008@usfamily.net> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACC2@mail> <495E5743.7050506@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACCA@mail> <495E69A8.3080502@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4ACCD@mail> <495E76F2.3010008@usfamily.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACCF@mail> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ron Cleven > Sent: Friday, January 02, 2009 2:20 PM > To: arin ppml > Subject: Re: [arin-ppml] FW: Policy Proposal 2008-6:Emergency > TransferPolicyfor IPv4 Addresses - Last Call > > Kevin Kargel wrote: > >>>Umm, when there are only four steaks left and 40 people that want them > >>>aren't there going to be lines no matter what the price? > >>> > >>> > >> > >>The price should rise to that which only the top four bidders can > >>afford, no? > > > > > > Sure, if you are ok with the president of AOL getting the four steaks > then I > > guess that would work.. That's just the thing, a couple million is chicken feed for them, I bet that is less than the corporate wide Christmas party budget. If they can eliminate a couple of minor competitors by cornering the resource market it may be easily justifiable on paper. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From owen at delong.com Fri Jan 2 15:53:20 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Jan 2009 12:53:20 -0800 Subject: [arin-ppml] 2008-6 What should the AC do Message-ID: <5D0F8DB0-F3EC-4AB6-A80A-241B06AE116E@delong.com> I'm glad to see a vigorous discussion about 2008-6 on the mailing list. However, since this proposal is in last call, there's a limited set of choices for the AC to make about the policy... Quoting from the ARIN web site: > The Advisory Council will review the comments collected during the > last call period and may: 1) support the proposal as is and > recommend that the Board of Trustees adopt, 2) find minor revisions > are necessary in which case the Advisory Council or author will > redraft and post again to last call, 3) find major revisions are > needed in which case the Advisory Council or author will redraft and > the proposal will be posted for the next public policy meeting, or > 4) find community support to abandon the proposal. So, I would like to encourage members of the community commenting on this proposal to express clearly which of the above four actions you believe the AC should take. I have seen the discussion range through all 4 options and it is not clear to me that there is any level of community consensus around any one of these options. Thanks, Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkargel at polartel.com Fri Jan 2 16:06:30 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 2 Jan 2009 15:06:30 -0600 Subject: [arin-ppml] 2008-6 What should the AC do In-Reply-To: <5D0F8DB0-F3EC-4AB6-A80A-241B06AE116E@delong.com> References: <5D0F8DB0-F3EC-4AB6-A80A-241B06AE116E@delong.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACD0@mail> I'm glad to see a vigorous discussion about 2008-6 on the mailing list. However, since this proposal is in last call, there's a limited set of choices for the AC to make about the policy... Quoting from the ARIN web site: The Advisory Council will review the comments collected during the last call period and may: 1) support the proposal as is and recommend that the Board of Trustees adopt, 2) find minor revisions are necessary in which case the Advisory Council or author will redraft and post again to last call, 3) find major revisions are needed in which case the Advisory Council or author will redraft and the proposal will be posted for the next public policy meeting, or 4) find community support to abandon the proposal. So, I would like to encourage members of the community commenting on this proposal to express clearly which of the above four actions you believe the AC should take. I have seen the discussion range through all 4 options and it is not clear to me that there is any level of community consensus around any one of these options. Thanks, Owen In light of this request by Owen my choice is option 4, abandon the proposal. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From stephen at sprunk.org Fri Jan 2 16:15:15 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 02 Jan 2009 15:15:15 -0600 Subject: [arin-ppml] Policy Proposal 2008-6 In-Reply-To: <495BF6BD.1050400@chl.com> References: <495BF6BD.1050400@chl.com> Message-ID: <495E83E3.3000905@sprunk.org> Joe Maimon wrote: > michael.dillon at bt.com wrote: > >>> Actually it matters a lot. There will be (are) many small businesses who will need IP addresses and depend on them for their business who will not be able to afford them. This tips the balance heavily in the favor of the big players and against the small guy and against the consumer who will ultimately have to pay for it. >>> >> In 1995 the big telecom companies were building out ATM networks >> and the big PC magazines were touting ATM to the desktop, >> > > Who wanted ATM to the desktop? > Lots of folks, apparently. ATM-25 was quite popular in certain places until Fast Ethernet switches came out and absolutely demolished it on cost and easy of deployment/maintenance. ATM switches weren't cheap, and LANE was a hideous mess in practice, but it was faster than 10Mb/s Ethernet... >> and some kind of multichannel interactive cable-TV system called the information highway. In the meantime, the little guys were building services using an uncommon protocol called IPv4. Uncommon in the sense that there were few commercial offerings of IP and few books or courses teaching it. >> >> Why would the IPv6 transition be all that different? >> > > Because nobody wants IPv6. Few people wanted (or want) IPv4 either. They want to be able to get interesting and/or profitable things done, and today that is not possible with only IPv6. Perhaps it will be by the time IPv4 exhaustion happens, but I'm not that optimistic; there are still far, far too many pieces missing. S -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From kkargel at polartel.com Fri Jan 2 16:18:16 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 2 Jan 2009 15:18:16 -0600 Subject: [arin-ppml] 2008-6 What should the AC do In-Reply-To: <5D0F8DB0-F3EC-4AB6-A80A-241B06AE116E@delong.com> References: <5D0F8DB0-F3EC-4AB6-A80A-241B06AE116E@delong.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACD1@mail> I have seen the discussion range through all 4 options and it is not clear to me that there is any level of community consensus around any one of these options. Thanks, Owen Even though I did select abandon the proposal as the best option, I do want to take a minute and offer personal thanks to everyone who worked on the proposal for their efforts and time spent toward improving the community. While we may not agree on details or even strategy's, it is great to see so many intelligent and thoughtful people participating. Kevin Kargel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From artur at eboundhost.com Fri Jan 2 16:24:50 2009 From: artur at eboundhost.com (Artur (eBoundHost)) Date: Fri, 02 Jan 2009 15:24:50 -0600 Subject: [arin-ppml] Why are ISPs allowed? Message-ID: <495E8622.9060203@eboundhost.com> My apologies if I'm asking a question that has been answered a million times, I have not been able to find an answer. Is there a reason why ISP's such as Comcast/ATT, allowed to hand out unique IP addresses, even not static ones, to end users? Why are they not required to use NAT? If ISPs were to switch to local address space, how many IP blocks would be released back into the wild? -- Best Regards, Artur eBoundHost http://www.eboundhost.com From cort at kanren.net Fri Jan 2 16:37:55 2009 From: cort at kanren.net (Cort Buffington) Date: Fri, 2 Jan 2009 15:37:55 -0600 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <495E8622.9060203@eboundhost.com> References: <495E8622.9060203@eboundhost.com> Message-ID: <0DE15DA7-A3B3-4E29-85B1-01B720044186@kanren.net> NAT enforces the client-server model. I can think of a LOT of reasons why I would not use an ISP that enforced NAT upon me. The main one being that I could only use my Internet connection for sessions I initiate.... In other words, I'm buying about 1/2 of a connection to the Internet... Actually, I'd not be buying a connection "to" the Internet at all, only a connection "from" the Internet. Once two people who wish to communicate are both behind such providers, there is no way they can send data to each other without using a third party somewhere... which is to me a real waste of resources. On Jan 2, 2009, at 3:24 PM, Artur (eBoundHost) wrote: > My apologies if I'm asking a question that has been answered a million > times, I have not been able to find an answer. > > Is there a reason why ISP's such as Comcast/ATT, allowed to hand out > unique IP addresses, even not static ones, to end users? Why are they > not required to use NAT? > > If ISPs were to switch to local address space, how many IP blocks > would > be released back into the wild? > > -- > > Best Regards, > > > Artur > eBoundHost > http://www.eboundhost.com > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- Cort Buffington Executive Director The Kansas Research and Education Network cort at kanren.net Office: +1-785-856-9800 x301 Mobile: +1-785-865-7206 From bill at herrin.us Fri Jan 2 16:39:40 2009 From: bill at herrin.us (William Herrin) Date: Fri, 2 Jan 2009 16:39:40 -0500 Subject: [arin-ppml] 2008-6 What should the AC do In-Reply-To: <5D0F8DB0-F3EC-4AB6-A80A-241B06AE116E@delong.com> References: <5D0F8DB0-F3EC-4AB6-A80A-241B06AE116E@delong.com> Message-ID: <3c3e3fca0901021339o70179d25rb316bd8f6a448cf1@mail.gmail.com> On Fri, Jan 2, 2009 at 3:53 PM, Owen DeLong wrote: > The Advisory Council will review the comments collected during the last call > period and may: 1) support the proposal as is and recommend that the Board > of Trustees adopt, 2) find minor revisions are necessary in which case the > Advisory Council or author will redraft and post again to last call, 3) find > major revisions are needed in which case the Advisory Council or author will > redraft and the proposal will be posted for the next public policy meeting, > or 4) find community support to abandon the proposal. > > So, I would like to encourage members of the community commenting > on this proposal to express clearly which of the above four actions > you believe the AC should take. Owen, Unless there's some rush to get this on the books, I'd like to see option #3. That'll give the AC a chance to fix the language and then verify (with concise language replacing amorphous explanations) that there really is consensus. If you're in a rush, #2 is probably acceptable. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From prescott at wcoil.com Fri Jan 2 16:36:15 2009 From: prescott at wcoil.com (prescott at wcoil.com) Date: Fri, 2 Jan 2009 16:36:15 -0500 (EST) Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <495E8622.9060203@eboundhost.com> References: <495E8622.9060203@eboundhost.com> Message-ID: speaking as a network administrator and consumer both, I would be really unhappy if isp(s) forced customers to nat. This would prevent many services that require "real" ip addresses from working and would greatly increase the problems admins would have to deal with due to the nat. On Fri, 2 Jan 2009, Artur (eBoundHost) wrote: > Date: Fri, 02 Jan 2009 15:24:50 -0600 > From: "Artur (eBoundHost)" > To: ARIN-PPML at arin.net > Subject: [arin-ppml] Why are ISPs allowed? > > My apologies if I'm asking a question that has been answered a million > times, I have not been able to find an answer. > > Is there a reason why ISP's such as Comcast/ATT, allowed to hand out > unique IP addresses, even not static ones, to end users? Why are they > not required to use NAT? > > If ISPs were to switch to local address space, how many IP blocks would > be released back into the wild? > > From stephen at sprunk.org Fri Jan 2 16:46:44 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 02 Jan 2009 15:46:44 -0600 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <495E8622.9060203@eboundhost.com> References: <495E8622.9060203@eboundhost.com> Message-ID: <495E8B44.3010201@sprunk.org> Artur (eBoundHost) wrote: > My apologies if I'm asking a question that has been answered a million times, I have not been able to find an answer. > > Is there a reason why ISP's such as Comcast/ATT, allowed to hand out unique IP addresses, even not static ones, to end users? Current policy says that assignments are justified if 25% of the space is used immediately and 50% of the space is used within one year. It is reasonable to assume that each customer has at least one host (otherwise, why would they buy the service?) and thus assigning one address per customer is automatically justified. > Why are they not required to use NAT? > NAT is generally considered "evil" and, so far, there is no consensus in the community that ISPs should be _required_ to use it. It is an _optional_ technology that allows folks to use fewer addresses than would be justified. > If ISPs were to switch to local address space, how many IP blocks would > be released back into the wild? > Most of them, I'd bet. S -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From kkargel at polartel.com Fri Jan 2 16:51:52 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 2 Jan 2009 15:51:52 -0600 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <0DE15DA7-A3B3-4E29-85B1-01B720044186@kanren.net> References: <495E8622.9060203@eboundhost.com> <0DE15DA7-A3B3-4E29-85B1-01B720044186@kanren.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACD2@mail> > On Jan 2, 2009, at 3:24 PM, Artur (eBoundHost) wrote: > > > My apologies if I'm asking a question that has been answered a million > > times, I have not been able to find an answer. > > > > Is there a reason why ISP's such as Comcast/ATT, allowed to hand out > > unique IP addresses, even not static ones, to end users? Why are they > > not required to use NAT? > > > > If ISPs were to switch to local address space, how many IP blocks > > would > > be released back into the wild? > > > > -- > > > > Best Regards, > > > > > > Artur > > eBoundHost > > http://www.eboundhost.com Artur, Long ago when this ISP was in it's infancy we experimented with using NAT for dialup users. There were so many things that NAT broke and so many immediate and loud complaints that we abandoned that experiment in short order. Our users found that many online games were broken, P2P features of IM's were broken, remote desktop apps were broken, among many other things. Remember that NAT for an ISP would be one to thousands, which is much different from the one to few type of NAT that you see in your home router. On your home router it is not too difficult to set up PAT rules to allow remote desktop to a specific workstation for example, but it would be a nightmare on an ISP enterprise level. Another not trivial thing that gets much more difficult in a one-to-thousands NAT would be accountability. Tracking down a malicious user from forensic data in outside log files would get very expensive. It is a good idea but not one which is practical to execute. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From scott.beuker at sjrb.ca Fri Jan 2 16:04:56 2009 From: scott.beuker at sjrb.ca (Scott Beuker) Date: Fri, 02 Jan 2009 14:04:56 -0700 Subject: [arin-ppml] 2008-6 What should the AC do In-Reply-To: <5D0F8DB0-F3EC-4AB6-A80A-241B06AE116E@delong.com> References: <5D0F8DB0-F3EC-4AB6-A80A-241B06AE116E@delong.com> Message-ID: <46A2DD1223D7BF47B61799AFFBA8AD8902B0E6E9@PRDCG4EXVW01-1.OSS.PRD> I oppose the policy as written, and would like to see it abandoned (4) or if not then given back to the author to revise to address concerns raised (3). Thanks, Scott Beuker From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, January 02, 2009 1:53 PM To: PPML ppml Subject: [arin-ppml] 2008-6 What should the AC do I'm glad to see a vigorous discussion about 2008-6 on the mailing list. However, since this proposal is in last call, there's a limited set of choices for the AC to make about the policy... Quoting from the ARIN web site: The Advisory Council will review the comments collected during the last call period and may: 1) support the proposal as is and recommend that the Board of Trustees adopt, 2) find minor revisions are necessary in which case the Advisory Council or author will redraft and post again to last call, 3) find major revisions are needed in which case the Advisory Council or author will redraft and the proposal will be posted for the next public policy meeting, or 4) find community support to abandon the proposal. So, I would like to encourage members of the community commenting on this proposal to express clearly which of the above four actions you believe the AC should take. I have seen the discussion range through all 4 options and it is not clear to me that there is any level of community consensus around any one of these options. Thanks, Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From artur at eboundhost.com Fri Jan 2 17:08:42 2009 From: artur at eboundhost.com (Artur (eBoundHost)) Date: Fri, 2 Jan 2009 22:08:42 +0000 Subject: [arin-ppml] Why are ISPs allowed? Message-ID: <1076601153-1230933992-cardhu_decombobulator_blackberry.rim.net-836677388-@bxe309.bisx.prod.on.blackberry> >Once two people who wish to communicate >are both behind such >providers, there is no way they can send >data to each other without >using a third party somewhere... This is a handful of users. We're just probably talking about p2p users mostly. I also have a home server but I really see it as a non typical use. Best Regards, Artur eBoundHost http://www.eboundhost.com From artur at eboundhost.com Fri Jan 2 17:03:31 2009 From: artur at eboundhost.com (Artur (eBoundHost)) Date: Fri, 2 Jan 2009 22:03:31 +0000 Subject: [arin-ppml] Why are ISPs allowed? Message-ID: <115990992-1230933680-cardhu_decombobulator_blackberry.rim.net-1753859872-@bxe309.bisx.prod.on.blackberry> >at least one host >(otherwise, why would they buy the >service?) and thus assigning one >address per customer is automatically >justified. I'm strictly talking about home users, not hosting providers. Best Regards, Artur eBoundHost http://www.eboundhost.com From gih at apnic.net Fri Jan 2 17:12:32 2009 From: gih at apnic.net (Geoff Huston) Date: Sat, 3 Jan 2009 09:12:32 +1100 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: References: <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <20090101204504.GA25609@ussenterprise.ufp.org> Message-ID: On 03/01/2009, at 7:07 AM, John Schnizlein wrote: >> - IPv6 is deployed fairly rapidly, and with limited pain. > > What would prompt this sort of radical change from the deplorably slow > deployment over the last several years? > Divine intervention? :-) >> > >> And lastly, I've suggested an alternative method where by IPv4 space >> can be redistributed. One which I think puts ARIN in a much better >> position with respect to the long term stability of ARIN and IPv6 >> allocations. To suggest I'm opposing a market when I put forth a >> proposal that creates one is rather silly. > > It seems to me that operating a market for IPv4 addresses is a risky > business. > yes - if you are intending to insert the RIR into the role of qualifier, facilitator, and price setter. That path poses risks that I would see as being untenable for an RIR. > Geoff Huston has made a (persuasive to me) argument that RIRs should > not attempt to act as regulators, which is what the requirement that > the recipient justify its need for IPv4 address space implies. Yes, I believe that the RIPE policy, which places RIPE in the role of a "market qualifier" places the RIPE NCC into a position that is unreasonable and, I suspect, untenable. I have the same problem with a recent policy proposal proposed in the APNIC region which contains similar words relating to the RIR performing some form of qualification of market participants. Such a role is one that exposes the RIR to extremely high levels of risk in terms of the potential liability in its assessment procedures and also places it into a role of market regulator where the RIR is singularly ill equipped to perform and it has no recognized mandate or authority to perform, and calls into question the RIR's current de facto monopoly position with respect to address distribution and price setting. The scale of risk here, as I see it, is appropriately phrased as a risk to the continued existence of the RIR structure itself. The 2008-06 policy, with the same proposed role of ARIN acting in a manner of a market regulator, in my opinion poses a similar level of risk to ARIN in its role as a de facto monopoly operation. A diligent process of review of this proposal may well benefit from some level of serious consideration of anti-trust issues within the region in which ARIN operates. > But if getting into the regulation business is risky, just imagine the > risk of operating an address market as the target of regulators! > Every price and transaction would be subject to scrutiny of its > fairness by parties involved in the transaction and others. During > the time that governments appear to be pursuing greater regulation of > already established markets, a new lucrative market in IPv4 addresses > would likely draw attention. What would risk the existence of RIRs > less, and help preserve the stability of the Internet would be > reliable registration of address authorization-to-use. A fine question - and I suspect personally that a more minimalist approach here in terms of a RIR's registry maintenance function is called for as a reasonable response. regards, Geoff From Keegan.Holley at sungard.com Fri Jan 2 17:13:10 2009 From: Keegan.Holley at sungard.com (Keegan.Holley at sungard.com) Date: Fri, 2 Jan 2009 17:13:10 -0500 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <0DE15DA7-A3B3-4E29-85B1-01B720044186@kanren.net> References: <495E8622.9060203@eboundhost.com> <0DE15DA7-A3B3-4E29-85B1-01B720044186@kanren.net> Message-ID: It is an interesting idea though. As IPv4 space becomes more and more scarce and as a result more and more valuable I wonder if it would be possible to start natting and then assign customers public TCP/UDP ports rather than IP addresses. This would be for small businesses and individual users of course, but it would save some addresses. I think making something like that mandatory would be a mistake though. > NAT enforces the client-server model. I can think of a LOT of reasons > why I would not use an ISP that enforced NAT upon me. The main one > being that I could only use my Internet connection for sessions I > initiate.... In other words, I'm buying about 1/2 of a connection to > the Internet... Actually, I'd not be buying a connection "to" the > Internet at all, only a connection "from" the Internet. > > Once two people who wish to communicate are both behind such > providers, there is no way they can send data to each other without > using a third party somewhere... which is to me a real waste of > resources. > > On Jan 2, 2009, at 3:24 PM, Artur (eBoundHost) wrote: > > > My apologies if I'm asking a question that has been answered a million > > times, I have not been able to find an answer. > > > > Is there a reason why ISP's such as Comcast/ATT, allowed to hand out > > unique IP addresses, even not static ones, to end users? Why are they > > not required to use NAT? > > > > If ISPs were to switch to local address space, how many IP blocks > > would > > be released back into the wild? > > > > -- > > > > Best Regards, > > > > > > Artur > > eBoundHost > > http://www.eboundhost.com > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > -- > Cort Buffington > Executive Director > The Kansas Research and Education Network > cort at kanren.net > Office: +1-785-856-9800 x301 > Mobile: +1-785-865-7206 > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From artur at eboundhost.com Fri Jan 2 17:18:09 2009 From: artur at eboundhost.com (Artur (eBoundHost)) Date: Fri, 2 Jan 2009 22:18:09 +0000 Subject: [arin-ppml] ARIN-PPML Digest, Vol 43, Issue 10 Message-ID: <1460848133-1230934558-cardhu_decombobulator_blackberry.rim.net-1525280338-@bxe309.bisx.prod.on.blackberry> Kevin, Thank you for the reply, that makes a lot of sense. Best Regards, Artur eBoundHost http://www.eboundhost.com From kkargel at polartel.com Fri Jan 2 17:17:27 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 2 Jan 2009 16:17:27 -0600 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <1076601153-1230933992-cardhu_decombobulator_blackberry.rim.net-836677388-@bxe309.bisx.prod.on.blackberry> References: <1076601153-1230933992-cardhu_decombobulator_blackberry.rim.net-836677388-@bxe309.bisx.prod.on.blackberry> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACD3@mail> > > >Once two people who wish to communicate >are both behind such > >providers, there is no way they can send >data to each other without > >using a third party somewhere... > > This is a handful of users. We're just probably talking about p2p users > mostly. P2P used to be only a handful of users, now they are very common, if not the majority. Based on watching traffic analysis at our network P2P apps are pretty much the norm anymore. This is not only due to the popularity of file sharing, but because of gaming consoles, webcams, stuff like that. > > I also have a home server but I really see it as a non typical use. > > Best Regards, > > Artur > eBoundHost > http://www.eboundhost.com > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From cort at kanren.net Fri Jan 2 17:31:43 2009 From: cort at kanren.net (Cort Buffington) Date: Fri, 2 Jan 2009 16:31:43 -0600 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <1076601153-1230933992-cardhu_decombobulator_blackberry.rim.net-836677388-@bxe309.bisx.prod.on.blackberry> References: <1076601153-1230933992-cardhu_decombobulator_blackberry.rim.net-836677388-@bxe309.bisx.prod.on.blackberry> Message-ID: <0FDF2FDC-4578-461D-9812-EB8CF393D8D4@kanren.net> On Jan 2, 2009, at 4:08 PM, Artur (eBoundHost) wrote: >> Once two people who wish to communicate >are both behind such >> providers, there is no way they can send >data to each other without >> using a third party somewhere... > > This is a handful of users. We're just probably talking about p2p > users mostly. Using Skype to talk to my sister in Greece or my brother in the army in Afghanistan Operating my amateur radio station remotely when I'm away from home Checking in on my cats during the day by logging into a web-cam server Sending pictures to my friends through IM directed connections Playing computer games with friends (not massively online, just a couple of us) Slingbox type media applications (not all of it is illegal) While a lot of this may be seen as p2p, I want to make sure there's no mistaking p2p with "violating copyright by trading media files". I think about a lot of things that myself and a lot of my friends and family do, we really aren't just checking our Yahoo mail or browsing the Web anymore. Sure we do a lot of it, but we do a lot of other things too, and moreover, I suspect as the Internet evolves, there will continue to be more and more applications that involve one end user communicating directly to another... We are globalizing on a personal level. While NAT can work in a lot of places, forcing it on residential users is probably very counterproductive to the evolution of information exchanges. > > I also have a home server but I really see it as a non typical use. > > Best Regards, > > Artur > eBoundHost > http://www.eboundhost.com > -- Cort Buffington Executive Director The Kansas Research and Education Network cort at kanren.net Office: +1-785-856-9800 x301 Mobile: +1-785-865-7206 From jradel at vantage.com Fri Jan 2 17:45:08 2009 From: jradel at vantage.com (Jon Radel) Date: Fri, 02 Jan 2009 17:45:08 -0500 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACD3@mail> References: <1076601153-1230933992-cardhu_decombobulator_blackberry.rim.net-836677388-@bxe309.bisx.prod.on.blackberry> <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACD3@mail> Message-ID: <495E98F4.8030907@vantage.com> Kevin Kargel wrote: >>> Once two people who wish to communicate >are both behind such >>> providers, there is no way they can send >data to each other without >>> using a third party somewhere... >>> >> This is a handful of users. We're just probably talking about p2p users >> mostly. >> > > P2P used to be only a handful of users, now they are very common, if not the > majority. Based on watching traffic analysis at our network P2P apps are > pretty much the norm anymore. This is not only due to the popularity of > file sharing, but because of gaming consoles, webcams, stuff like that. > > As a VOIP provider I'll point out that double-NATing SIP really doesn't work very well. Basically there are a lot of protocols that have been kludged to support one layer of NAT at the edge of the enterprise or home network, but if you add another layer of NAT somewhere things get really squirrelly, really fast. Also, from a more philosophical standpoint, I'm opposed to any furthering of "oh, they're just consumers; a bit of web surfing, a bit of e-mail, a bunch of the video pap we want to sell them...what on earth would they need to do anything more for?" mindset that already taints many consumer offerings. Let's keep the Internet a 2-way medium. ;-) Hasn't this topic been beaten to death in many slightly more pertinent venues? --Jon Radel jradel at vantage.com -------------- 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 stephen at sprunk.org Fri Jan 2 18:27:37 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 02 Jan 2009 17:27:37 -0600 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <115990992-1230933680-cardhu_decombobulator_blackberry.rim.net-1753859872-@bxe309.bisx.prod.on.blackberry> References: <115990992-1230933680-cardhu_decombobulator_blackberry.rim.net-1753859872-@bxe309.bisx.prod.on.blackberry> Message-ID: <495EA2E9.20100@sprunk.org> Artur (eBoundHost) wrote: >> at least one host (otherwise, why would they buy the service?) and thus assigning one address per customer is automatically justified. >> > > I'm strictly talking about home users, not hosting providers. So am I. Every customer (i.e. home) can be assumed to have at least one host, therefore one IP address per customer (i.e. home) is automatically justified by current policy. S -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From randy at psg.com Fri Jan 2 18:36:05 2009 From: randy at psg.com (Randy Bush) Date: Sat, 03 Jan 2009 08:36:05 +0900 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: References: <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <20090101204504.GA25609@ussenterprise.ufp.org> Message-ID: <495EA4E5.3080908@psg.com> On 09.01.03 07:12, Geoff Huston wrote: > I believe that the RIPE policy, which places RIPE in the role of > a "market qualifier" places the RIPE NCC into a position that is > unreasonable and, I suspect, untenable. I have the same problem with a > recent policy proposal proposed in the APNIC region which contains > similar words relating to the RIR performing some form of > qualification of market participants. Such a role is one that exposes > the RIR to extremely high levels of risk in terms of the potential > liability in its assessment procedures and also places it into a role > of market regulator where the RIR is singularly ill equipped to > perform and it has no recognized mandate or authority to perform but have been performing exactly that for some years. enough folk seem to have requested to maintain that status quo that the transfer proposal in ripe passed with it and the new one in apnic includes it to see if that will help get apnic past the thrice repeated non-consensus of a proposal without it. personally, i am not strongly religious either way. > calls into question the RIR's current de facto monopoly position with > respect to address distribution and price setting. The scale of risk > here, as I see it, is appropriately phrased as a risk to the continued > existence of the RIR structure itself. this is new? the rirs have chosen to walk this line for a long time. that it is getting thinner and thinner is no big shock. that there is no obvious bump or narrowing in this path may have led the rirs to keep slowly walking it. the level of self-righteousness in organizational self-preservation may have assisted :). it would be interesting to see a movement to where the rirs got out of (needs based) regulation of ipv4 and ipv6. i don't see much support for that in the arin or apnic communities. i am not sure what this says for the good of the internet. randy From gih at apnic.net Fri Jan 2 19:18:13 2009 From: gih at apnic.net (Geoff Huston) Date: Sat, 3 Jan 2009 11:18:13 +1100 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <495EA4E5.3080908@psg.com> References: <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <20090101204504.GA25609@ussenterprise.ufp.org> <495EA4E5.3080908@psg.com> Message-ID: <054DDA58-4E99-4FD5-AC2A-32078EA9E81E@apnic.net> On 03/01/2009, at 10:36 AM, Randy Bush wrote: > On 09.01.03 07:12, Geoff Huston wrote: >> I believe that the RIPE policy, which places RIPE in the role of >> a "market qualifier" places the RIPE NCC into a position that is >> unreasonable and, I suspect, untenable. I have the same problem >> with a >> recent policy proposal proposed in the APNIC region which contains >> similar words relating to the RIR performing some form of >> qualification of market participants. Such a role is one that exposes >> the RIR to extremely high levels of risk in terms of the potential >> liability in its assessment procedures and also places it into a role >> of market regulator where the RIR is singularly ill equipped to >> perform and it has no recognized mandate or authority to perform > > but have been performing exactly that for some years. What? Performing the role of regulator in a market for address transfers? Really? > enough folk seem to have requested to maintain that status quo that > the transfer proposal in ripe passed with it and the new one in > apnic includes it to see if that will help get apnic past the thrice > repeated non-consensus of a proposal without it. personally, i am > not strongly religious either way. "Thrice repeated non-consensus"??? That is simply not the case, and I 'm surprised given your role in the APNIC policy development process that you have such a misunderstanding of the background of this proposal. The proposal has only been presented to the open policy forum for an indication of support once to my knowledge, and that was in September 2008. Previous presentations were informational only. The upshot of that consideration by the community was that the Japanese community were to further consider the proposal at their meeting in November 2008, which has taken place. > > >> calls into question the RIR's current de facto monopoly position with >> respect to address distribution and price setting. The scale of risk >> here, as I see it, is appropriately phrased as a risk to the >> continued >> existence of the RIR structure itself. > > this is new? the rirs have chosen to walk this line for a long time. What? Performing the role of regulator in a market for address transfers? Really? > that it is getting thinner and thinner is no big shock. that there > is no obvious bump or narrowing in this path may have led the rirs > to keep slowly walking it. the level of self-righteousness in > organizational self-preservation may have assisted :). Perhaps some facts would assist your line of argument here, rather than such rather strained assertions of "self-righteousness in organizational self-preservation," or are such mere details inappropriate here? > > > it would be interesting to see a movement to where the rirs got out > of (needs based) regulation of ipv4 and ipv6. i don't see much > support for that in the arin or apnic communities. i am not sure > what this says for the good of the internet. > What would be interesting to see is an analysis of particular assertions being made in your response here that specifically relate to "the good of the internet" and how. From cgucker at onesc.net Fri Jan 2 19:54:58 2009 From: cgucker at onesc.net (Charles Gucker) Date: Fri, 2 Jan 2009 19:54:58 -0500 Subject: [arin-ppml] Fees for discouraging IPv4 (was: completely unrelated to 2008-6) In-Reply-To: <3c3e3fca0901020946i3b50f45ek34e6eaae2c5d667a@mail.gmail.com> References: <7663C7E01D8E094989CA62F0B0D21CD9028B2CF6@SUEXCL-02.ad.syr.edu> <495A9A9C.5070409@psg.com> <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <0A757D9D-47D6-42CF-BBEE-56FCE6692A16@delong.com> <75822E125BCB994F8446858C4B19F0D7086BAEFC@SUEX07-MBX-04.ad.syr.edu> <495DEF95.5050503@usfamily.net> <323666.16144.qm@web63301.mail.re1.yahoo.com> <3c3e3fca0901020946i3b50f45ek34e6eaae2c5d667a@mail.gmail.com> Message-ID: On Fri, Jan 2, 2009 at 12:46 PM, William Herrin wrote: > On Fri, Jan 2, 2009 at 11:35 AM, Lee Howard wrote: >>> The renewal rates should be a flat per-ip rate >> >> A few people have advocated for that structure; see below. > > Lee, > > For the record, you can include me in the list of advocates, though I > have no idea what to do with the excess money. It would take totals > rather higher than ARIN's annual budget for the XL's to treat > conservation as a financial rather than moral issue. Well, IMO, if ARIN was to collect higher fees for v4, it should extend the waiver for the cost for v6 until such time the "excess funds" are depleted and at that time we return to the currently planned v6 fee structure. Again, just an opinion of a single observer. charles From bicknell at ufp.org Fri Jan 2 20:38:27 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 2 Jan 2009 20:38:27 -0500 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: References: <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <20090101204504.GA25609@ussenterprise.ufp.org> Message-ID: <20090103013827.GB86274@ussenterprise.ufp.org> In a message written on Fri, Jan 02, 2009 at 03:07:47PM -0500, John Schnizlein wrote: > On 2009Jan1, at 3:45 PM, Leo Bicknell wrote: > >The status quo ends, however, when it does I have a markedly different > >view of the world than you do. I believe that: > > > > - IPv6 is deployed fairly rapidly, and with limited pain. > > What would prompt this sort of radical change from the deplorably slow > deployment over the last several years? Here's the interesting dynamic; there is almost no first-mover advantage to deploying IPv6 first. You want to deploy it before your customers want it, so you don't have to turn them away; and you want your engineers to have experience with it. However, beyond that it doesn't get you extra revenue, and may make you purchase equipment you would not otherwise purchase, run newer software with more bugs, etc. We see ISP's state this over and over, the customers do not want it, so we're not doing it. However, there is also no incentive to drag your feet once the move starts. The industry will move quikly to IPv6 once the move starts because running transition boxes (NAT, 6to4, whatever) is expensive, so most ISP's will want to be as dual-stack as possible and do as little transition as possible. ISP's will also move to push the transition costs to their competitors, last one with a transition box looses. What will start the move is customer demand, and it will be driven by the lack of IPv4 resources for large ISP's. Cox/Comcast/Time Warner/Verizon (FIOS/DSL)/Cablevision will run out. They will provision IPv6 (I believe). I think most will roll it out to their existing customers as well, in a dual-stack situation. Eyeballs will go first, and content having generally much fewer systems, a higher IQ per IP, and generally depending on protocols well tested over IPv6 will move second, and at an amazingly rapid pace. Akamai's and Limelight's I suspect could offer IPv6 services worldwide in a matter of a few weeks, if there was a reason to do so. In short, the least effort, least cost path is to delay as long as possible, then for everyone to leap forward at a brisk pace; essentially as fast as possible without paying money just to "speed it up." It is the service industry equivilent of the manufacturing industry's "just in time" delivery. You don't want inventory sitting in warehouses, which is what IPv6 configured on your network before people want it appears to be. However, if the part/service is late, it disrupts the entire line and causes a mess. > something happens soon to change the current slow progress, I fear the > IPv4-translation approaches might become so well entrenched that they > become yet another obstacle to deployment of a network-layer Internet > protocol with sufficient addresses for the globe. Translation may be a short term solution. However translation will always be more costly than native, and ISP's love to cut costs out of anything they can get their hands on. I have no fear of translation boxes becoming a long term solution. -- 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 scottleibrand at gmail.com Fri Jan 2 21:04:23 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 02 Jan 2009 18:04:23 -0800 Subject: [arin-ppml] 2008-6 inscrutable? In-Reply-To: <495E7854.7040407@sprunk.org> References: <3c3e3fca0901021031ka2b1510k8373e215b3d57b10@mail.gmail.com> <495E7854.7040407@sprunk.org> Message-ID: <495EC7A7.5020206@gmail.com> Stephen Sprunk wrote: > William Herrin wrote: >> On Mon, Dec 29, 2008 at 7:18 PM, William Herrin wrote: >> >>> On Tue, Dec 23, 2008 at 2:15 PM, Member Services wrote: >>> >>>> Policy statement: >>>> >>>> 8.4 Emergency Transfer Policy for IPv4 Addresses >>>> >>>> For a period of 3 years from policy implementation, ARIN-region >>>> number resources may be released, in whole or in part, to ARIN or >>>> another organization, by the authorized holder of the resource. >>>> >>>> Number resources may only be received under RSA, with demonstrated >>>> need, in the exact amount which they are able to justify under ARIN >>>> resource-allocation policies. >>>> >>> The language here seems labyrinthine, almost government-speak. Even >>> knowing that this was a transfer proposal, I had to parse it phrase >>> by phrase before I caught on that "or another organization" means >>> you can gift the released addresses to a specific registrant. >>> >> >> Hi folks, >> >> Can we take a break from the flame war long enough to discuss this? >> > > Please! > >> I did not observe anyone replying to my comments by stating a belief >> that the policy language above is clear and concise. Notwithstanding >> the differing views on whether the proposed policy is good, is there >> is general agreement that the policy language is rather enigmatic? >> > > *shrug* I understood the intent the first time I read it, it doesn't > seem worse than many existing parts of the NRPM. Our community does > seem to prefer legalistic wording (say, compared to other RIRs), > perhaps because it is more precise. For what it's worth, Bill Darte and I have been seriously considering your alternative wording, with the desire of restating the intent of 2008-6 in the simplest possible language. The only real concern I have with it is regards to what we informally call the "full-fill rule", which in the currently 2008-6 language is represented by the word "exact", as in "in the exact amount which they are able to justify". If we can find some additional clause or sentence to add to your language to represent that condition (that the recipient can only receive one transfer to meet their current needs, not a bunch of separate small transfers), then I wouldn't oppose using the "minor edits" action to update the language and re-post 2008-6 for another round of last call. However, as Stephen expressed, I don't see any real problems with the existing language either. So perhaps a question to the community: is there anyone who opposes 2008-6 as written, but would support it with clearer language along the lines of what Bill outlined? Thanks, Scott From packetgrrl at gmail.com Fri Jan 2 21:53:51 2009 From: packetgrrl at gmail.com (cja@daydream.com) Date: Fri, 2 Jan 2009 19:53:51 -0700 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: <20090103013827.GB86274@ussenterprise.ufp.org> References: <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <20090101204504.GA25609@ussenterprise.ufp.org> <20090103013827.GB86274@ussenterprise.ufp.org> Message-ID: The reality is that if ISPs are waiting for customers to ask for IPv6 then it's never going to get deployed. The majority of folks on the Internet don't care how they get to whatever they want, they just want to get their info, game, whatever. They are sold a service. They're not going to ask for their ISP to use OSPF either. They don't know or care. Most of us like highways too but we don't particularly care what specific compounds are used to make them. We only care that they don't have potholes and that we can get to where we want to. Maybe we care if they're plowed and that there's a high speed limit. I guess I am still waiting for someone to come up with the killer application for IPv6. Or a marketing scheme... get this new service/speed/whatever if you sign up for IPv6. Of course you have to have IPv6 deployed to sell it as part of a service. ----Cathy On Fri, Jan 2, 2009 at 6:38 PM, Leo Bicknell wrote: > In a message written on Fri, Jan 02, 2009 at 03:07:47PM -0500, John > Schnizlein wrote: > > On 2009Jan1, at 3:45 PM, Leo Bicknell wrote: > > >The status quo ends, however, when it does I have a markedly different > > >view of the world than you do. I believe that: > > > > > > - IPv6 is deployed fairly rapidly, and with limited pain. > > > > What would prompt this sort of radical change from the deplorably slow > > deployment over the last several years? > > Here's the interesting dynamic; there is almost no first-mover > advantage to deploying IPv6 first. You want to deploy it before > your customers want it, so you don't have to turn them away; and > you want your engineers to have experience with it. However, beyond > that it doesn't get you extra revenue, and may make you purchase > equipment you would not otherwise purchase, run newer software with > more bugs, etc. > > We see ISP's state this over and over, the customers do not want > it, so we're not doing it. > > However, there is also no incentive to drag your feet once the move > starts. The industry will move quikly to IPv6 once the move starts > because running transition boxes (NAT, 6to4, whatever) is expensive, > so most ISP's will want to be as dual-stack as possible and do as > little transition as possible. ISP's will also move to push the > transition costs to their competitors, last one with a transition > box looses. > > What will start the move is customer demand, and it will be driven > by the lack of IPv4 resources for large ISP's. Cox/Comcast/Time > Warner/Verizon (FIOS/DSL)/Cablevision will run out. They will > provision IPv6 (I believe). I think most will roll it out to their > existing customers as well, in a dual-stack situation. Eyeballs > will go first, and content having generally much fewer systems, a > higher IQ per IP, and generally depending on protocols well tested > over IPv6 will move second, and at an amazingly rapid pace. Akamai's > and Limelight's I suspect could offer IPv6 services worldwide in a > matter of a few weeks, if there was a reason to do so. > > In short, the least effort, least cost path is to delay as long as > possible, then for everyone to leap forward at a brisk pace; > essentially as fast as possible without paying money just to "speed > it up." > > It is the service industry equivilent of the manufacturing industry's > "just in time" delivery. You don't want inventory sitting in > warehouses, which is what IPv6 configured on your network before people > want it appears to be. However, if the part/service is late, it > disrupts the entire line and causes a mess. > > > something happens soon to change the current slow progress, I fear the > > IPv4-translation approaches might become so well entrenched that they > > become yet another obstacle to deployment of a network-layer Internet > > protocol with sufficient addresses for the globe. > > Translation may be a short term solution. However translation will > always be more costly than native, and ISP's love to cut costs out > of anything they can get their hands on. I have no fear of translation > boxes becoming a long term solution. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at sprunk.org Sat Jan 3 01:20:31 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 03 Jan 2009 00:20:31 -0600 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call In-Reply-To: References: <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <20090101204504.GA25609@ussenterprise.ufp.org> <20090103013827.GB86274@ussenterprise.ufp.org> Message-ID: <495F03AF.8040006@sprunk.org> cja at daydream.com wrote: > The reality is that if ISPs are waiting for customers to ask for IPv6 > then it's never going to get deployed. Agreed; the vast majority of customers are never going to ask for IPv6 by name. It will come in indirectly, when a new customer signs up and there are simply no new IPv4 addresses to give them, or when customers start complaining that they can't get to the Hot New Site that all their friends can because it's only on IPv6... Even that might not be enough, at first. Every few months, our product managers run the numbers and, so far, the value of deals we've lost because we don't support IPv6 is a minuscule fraction of the projected cost to implement it. Until that number approaches parity, we have other things to do with our development dollars that _will_ help us win deals -- and I can't help but think many other vendors are in the same boat. _Someone_ has to throw down the gauntlet and refuse to spend (a lot of) money on products that don't support IPv6, or it's going to keep getting pushed back indefinitely as it has for the last decade... S -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From BillD at cait.wustl.edu Sat Jan 3 09:01:27 2009 From: BillD at cait.wustl.edu (Bill Darte) Date: Sat, 3 Jan 2009 08:01:27 -0600 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org><20090103013827.GB86274@ussenterprise.ufp.org> Message-ID: .... cja at daydream.com...wrote... I guess I am still waiting for someone to come up with the killer application for IPv6. Or a marketing scheme... get this new service/speed/whatever if you sign up for IPv6. Of course you have to have IPv6 deployed to sell it as part of a service. ************* Seems to me the sell is... the future comes with IPv6...we(as an ISP) offer that service now.. if you want to be part of the future, come with us.... (then a little FUD about what happens if you don't get on board) ;-) bd -------------- next part -------------- An HTML attachment was scrubbed... URL: From BillD at cait.wustl.edu Sat Jan 3 09:10:54 2009 From: BillD at cait.wustl.edu (Bill Darte) Date: Sat, 3 Jan 2009 08:10:54 -0600 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org> <20090103013827.GB86274@ussenterprise.ufp.org> Message-ID: Definitely like the IPv6 as inventory during transition analogy. But you state that the movement toward IPv6 will start with customer demand precipitated by ISPs running out of v6 space to deploy. That is demand for communication services...that without v6 cannot be satisfied, but is not demand for v6 itself. Otherwise, I believe your analysis of how things will move and why is accurate. bd -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Leo Bicknell Sent: Fri 1/2/2009 7:38 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In a message written on Fri, Jan 02, 2009 at 03:07:47PM -0500, John Schnizlein wrote: > On 2009Jan1, at 3:45 PM, Leo Bicknell wrote: > >The status quo ends, however, when it does I have a markedly different > >view of the world than you do. I believe that: > > > > - IPv6 is deployed fairly rapidly, and with limited pain. > > What would prompt this sort of radical change from the deplorably slow > deployment over the last several years? Here's the interesting dynamic; there is almost no first-mover advantage to deploying IPv6 first. You want to deploy it before your customers want it, so you don't have to turn them away; and you want your engineers to have experience with it. However, beyond that it doesn't get you extra revenue, and may make you purchase equipment you would not otherwise purchase, run newer software with more bugs, etc. We see ISP's state this over and over, the customers do not want it, so we're not doing it. However, there is also no incentive to drag your feet once the move starts. The industry will move quikly to IPv6 once the move starts because running transition boxes (NAT, 6to4, whatever) is expensive, so most ISP's will want to be as dual-stack as possible and do as little transition as possible. ISP's will also move to push the transition costs to their competitors, last one with a transition box looses. What will start the move is customer demand, and it will be driven by the lack of IPv4 resources for large ISP's. Cox/Comcast/Time Warner/Verizon (FIOS/DSL)/Cablevision will run out. They will provision IPv6 (I believe). I think most will roll it out to their existing customers as well, in a dual-stack situation. Eyeballs will go first, and content having generally much fewer systems, a higher IQ per IP, and generally depending on protocols well tested over IPv6 will move second, and at an amazingly rapid pace. Akamai's and Limelight's I suspect could offer IPv6 services worldwide in a matter of a few weeks, if there was a reason to do so. In short, the least effort, least cost path is to delay as long as possible, then for everyone to leap forward at a brisk pace; essentially as fast as possible without paying money just to "speed it up." It is the service industry equivilent of the manufacturing industry's "just in time" delivery. You don't want inventory sitting in warehouses, which is what IPv6 configured on your network before people want it appears to be. However, if the part/service is late, it disrupts the entire line and causes a mess. > something happens soon to change the current slow progress, I fear the > IPv4-translation approaches might become so well entrenched that they > become yet another obstacle to deployment of a network-layer Internet > protocol with sufficient addresses for the globe. Translation may be a short term solution. However translation will always be more costly than native, and ISP's love to cut costs out of anything they can get their hands on. I have no fear of translation boxes becoming a long term solution. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From BillD at cait.wustl.edu Sat Jan 3 09:37:00 2009 From: BillD at cait.wustl.edu (Bill Darte) Date: Sat, 3 Jan 2009 08:37:00 -0600 Subject: [arin-ppml] 2008-6 Combined Wording Alternative Message-ID: To assist the comparison of the alternate forms of wording proposed for 2008-6, I list them below. Policy Proposal 2008-6 wording: For a period of 3 years from policy implementation, ARIN-region number resources may be released, in whole or in part, to ARIN or another organization, by the authorized holder of the resource. Number resources may only be received under RSA, with demonstrated need, in the exact amount which they are able to justify under ARIN resource-allocation policies. Bill Herrin's wording: For a period of 3 years from policy implementation, resource holders served by ARIN may designate a recipient for number resources they release to ARIN. ARIN will honor said designation provided the recipient meets all other policy criteria for registering those resources. Seems to me that Bill Herrin's version is clearer, but changes the proposal by stating the transfer of resources must involve ARIN as a transfer intermediary. 2008-6 says: "..may be released...to ARIN or another organization...." Bill says: "..may designate a recipient for numbers they release to ARIN..." Is this a semantic difference???...where in practice, the transfer is really 'on paper' and ARIN is going to record the transfer in either case? And, of course, Scott has already highlighted the lack of 2008-6's second paragraph in Bill's alternative. Could the second paragraph simply be added while eliminating the last sentence of Bill's...as that would be redundant.... And, the clause .. "with demonstrated need" ...can be removed because it is implicit in the .."able to justify"... clause... This would yield... For a period of 3 years from policy implementation, resource holders served by ARIN may designate a recipient for number resources they release to ARIN. Number resources may only be received under RSA in the exact amount which they are able to justify under ARIN resource-allocation policies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From packetgrrl at gmail.com Sat Jan 3 09:40:18 2009 From: packetgrrl at gmail.com (cja@daydream.com) Date: Sat, 3 Jan 2009 07:40:18 -0700 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: References: <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <20090101204504.GA25609@ussenterprise.ufp.org> <20090103013827.GB86274@ussenterprise.ufp.org> Message-ID: I guess Bill but again I argue that customers don't care about IPv6. They want ISPs to continue to build the highway and provide a service that gets them to where they want to go. If ISPs run out of address space, well to a customer that's just poor planning and they'll go somewhere else. I don't think ISPs have to sell IPv6 to customers. Customers will take IPv6 if it gets them where they want to go. I still argue that the fact that their highway is IPv6 should be transparent to the customer. The ISP sells a service and it may or may not include IPv6. The customer wants to buy/sell/surf/etc.... The lower level protocols should be transparent to them. No one sells OSPF, IS-IS, or BGP to a customer either. The customers just don't care. The only thing I can see a customer may care about IPv6 is being able to get a large block of address space but again that's part of a service. ----Cathy On Sat, Jan 3, 2009 at 7:01 AM, Bill Darte wrote: > > .... cja at daydream.com...wrote... > > I guess I am still waiting for someone to come up with the killer > application for IPv6. Or a marketing scheme... get this new > service/speed/whatever if you sign up for IPv6. Of course you have to have > IPv6 deployed to sell it as part of a service. > ************* > > Seems to me the sell is... the future comes with IPv6...we(as an ISP) offer > that service now.. if you want to be part of the future, come with us.... > (then a little FUD about what happens if you don't get on board) ;-) > > bd > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From BillD at cait.wustl.edu Sat Jan 3 11:01:11 2009 From: BillD at cait.wustl.edu (Bill Darte) Date: Sat, 3 Jan 2009 10:01:11 -0600 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org><20090103013827.GB86274@ussenterprise.ufp.org> Message-ID: Of course...everything you say I absolutely agree with. But, my sell proposition is not exclusively to the consumer of transport, but to management of the ISP's. It's a way to seem less impotent in the face of an investment that must be done. It's a way for the company to spin the investment into a value proposition that seems to have a revenue stream associated with it...and to differentiate themselves to the consumer. -----Original Message----- From: cja at daydream.com [mailto:packetgrrl at gmail.com] Sent: Sat 1/3/2009 8:40 AM To: Bill Darte Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call I guess Bill but again I argue that customers don't care about IPv6. They want ISPs to continue to build the highway and provide a service that gets them to where they want to go. If ISPs run out of address space, well to a customer that's just poor planning and they'll go somewhere else. I don't think ISPs have to sell IPv6 to customers. Customers will take IPv6 if it gets them where they want to go. I still argue that the fact that their highway is IPv6 should be transparent to the customer. The ISP sells a service and it may or may not include IPv6. The customer wants to buy/sell/surf/etc.... The lower level protocols should be transparent to them. No one sells OSPF, IS-IS, or BGP to a customer either. The customers just don't care. The only thing I can see a customer may care about IPv6 is being able to get a large block of address space but again that's part of a service. ----Cathy On Sat, Jan 3, 2009 at 7:01 AM, Bill Darte wrote: > > .... cja at daydream.com...wrote... > > I guess I am still waiting for someone to come up with the killer > application for IPv6. Or a marketing scheme... get this new > service/speed/whatever if you sign up for IPv6. Of course you have to have > IPv6 deployed to sell it as part of a service. > ************* > > Seems to me the sell is... the future comes with IPv6...we(as an ISP) offer > that service now.. if you want to be part of the future, come with us.... > (then a little FUD about what happens if you don't get on board) ;-) > > bd > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From JOHN at egh.com Sat Jan 3 12:03:56 2009 From: JOHN at egh.com (John Santos) Date: Sat, 3 Jan 2009 12:03:56 -0500 Subject: [arin-ppml] 2008-6 Combined Wording Alternative In-Reply-To: Message-ID: <1090103113008.1974Q-100000@Ives.egh.com> I have a minor nit with the original wording and Bill D.'s rewording that Bill H.'s version clears up. There's a "they" with no antecedent. Obviously it is intended to refer to the recipient, but literally, it refers to the number resources themselves (or possibly to ARIN.) Bill Darte wrote: > > Policy Proposal 2008-6 wording: > > For a period of 3 years from policy implementation, ARIN-region number > resources may be released, in whole or in part, to ARIN or another > organization, by the authorized holder of the resource. > > Number resources may only be received under RSA, with demonstrated need, > in the exact amount which they are able to justify under ARIN ----------------------------^^^^ > resource-allocation policies. > Alternatively, "Number resources may only be received under RSA, with demonstrated need, in the exact amount which can be justified under ARIN resource-allocation policies." The antecedent for "which" is clearly the amount of number resources. > Bill Herrin's wording: > > For a period of 3 years from policy implementation, resource holders > served by ARIN may designate a recipient for number resources they > release to ARIN. ARIN will honor said designation provided the > recipient meets all other policy criteria for registering those > resources. > > Someone else asked if this could result in fragmentation because the lack of the phrase "the exact amount" from the original. But isn't this covered by "all other policy criteria"? Which phrase also covers the dropped mention of the RSA... > Seems to me that Bill Herrin's version is clearer, but changes the > proposal by > stating the transfer of resources must involve ARIN as a transfer > intermediary. > > 2008-6 says: "..may be released...to ARIN or another organization...." > > Bill says: "..may designate a recipient for numbers they release to > ARIN..." > > Is this a semantic difference???...where in practice, the transfer is > really 'on paper' and ARIN is going to record the transfer in either case? Since only ARIN can judge whether the recipient meets ARIN's policy criteria, and the recipient has to sign an RSA, I think ARIN has to be involved even in a direct transfer from holder to recipient using the original wording, so I don't think the wording makes any difference. But IANAL :-) > > And, of course, Scott has already highlighted the lack of 2008-6's second > paragraph in Bill's alternative. Could the second paragraph simply be > added while eliminating the last sentence of Bill's...as that would be > redundant.... > > And, the clause .. "with demonstrated need" ...can be removed because it is > implicit in the .."able to justify"... clause... > > This would yield... > > For a period of 3 years from policy implementation, resource holders > served by ARIN may designate a recipient for number resources they > release to ARIN. > > Number resources may only be received under RSA in the exact amount > which they are able to justify under ARIN resource-allocation policies. --------^^^^ This reintroduces the "they"... "Recipients may receive number resources only under RSA..." would fix it here too. Alternatively, "Number resources may only be received under RSA in the exact amount which can be justified under ARIN resource-allocation policies." -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From BillD at cait.wustl.edu Sat Jan 3 13:04:50 2009 From: BillD at cait.wustl.edu (Bill Darte) Date: Sat, 3 Jan 2009 12:04:50 -0600 Subject: [arin-ppml] 2008-6 Combined Wording Alternative References: <1090103113008.1974Q-100000@Ives.egh.com> Message-ID: Given John's fix below, the 2008-6 wording becomes.... For a period of 3 years from policy implementation, resource holders served by ARIN may designate a recipient for number resources they release to ARIN. Number resources may only be received under RSA in the exact amount which can be justified under ARIN resource-allocation policies. -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of John Santos Sent: Sat 1/3/2009 11:03 AM To: Bill Darte Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2008-6 Combined Wording Alternative I have a minor nit with the original wording and Bill D.'s rewording that Bill H.'s version clears up. There's a "they" with no antecedent. Obviously it is intended to refer to the recipient, but literally, it refers to the number resources themselves (or possibly to ARIN.) Bill Darte wrote: > > Policy Proposal 2008-6 wording: > > For a period of 3 years from policy implementation, ARIN-region number > resources may be released, in whole or in part, to ARIN or another > organization, by the authorized holder of the resource. > > Number resources may only be received under RSA, with demonstrated need, > in the exact amount which they are able to justify under ARIN ----------------------------^^^^ > resource-allocation policies. > Alternatively, "Number resources may only be received under RSA, with demonstrated need, in the exact amount which can be justified under ARIN resource-allocation policies." The antecedent for "which" is clearly the amount of number resources. > Bill Herrin's wording: > > For a period of 3 years from policy implementation, resource holders > served by ARIN may designate a recipient for number resources they > release to ARIN. ARIN will honor said designation provided the > recipient meets all other policy criteria for registering those > resources. > > Someone else asked if this could result in fragmentation because the lack of the phrase "the exact amount" from the original. But isn't this covered by "all other policy criteria"? Which phrase also covers the dropped mention of the RSA... > Seems to me that Bill Herrin's version is clearer, but changes the > proposal by > stating the transfer of resources must involve ARIN as a transfer > intermediary. > > 2008-6 says: "..may be released...to ARIN or another organization...." > > Bill says: "..may designate a recipient for numbers they release to > ARIN..." > > Is this a semantic difference???...where in practice, the transfer is > really 'on paper' and ARIN is going to record the transfer in either case? Since only ARIN can judge whether the recipient meets ARIN's policy criteria, and the recipient has to sign an RSA, I think ARIN has to be involved even in a direct transfer from holder to recipient using the original wording, so I don't think the wording makes any difference. But IANAL :-) > > And, of course, Scott has already highlighted the lack of 2008-6's second > paragraph in Bill's alternative. Could the second paragraph simply be > added while eliminating the last sentence of Bill's...as that would be > redundant.... > > And, the clause .. "with demonstrated need" ...can be removed because it is > implicit in the .."able to justify"... clause... > > This would yield... > > For a period of 3 years from policy implementation, resource holders > served by ARIN may designate a recipient for number resources they > release to ARIN. > > Number resources may only be received under RSA in the exact amount > which they are able to justify under ARIN resource-allocation policies. --------^^^^ This reintroduces the "they"... "Recipients may receive number resources only under RSA..." would fix it here too. Alternatively, "Number resources may only be received under RSA in the exact amount which can be justified under ARIN resource-allocation policies." -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sat Jan 3 16:08:32 2009 From: bill at herrin.us (William Herrin) Date: Sat, 3 Jan 2009 16:08:32 -0500 Subject: [arin-ppml] 2008-6 Combined Wording Alternative In-Reply-To: References: Message-ID: <3c3e3fca0901031308l3020df01yac044db1c1c22528@mail.gmail.com> On Sat, Jan 3, 2009 at 9:37 AM, Bill Darte wrote: > Seems to me that Bill Herrin's version is clearer, but changes the proposal > by stating the transfer of resources must involve ARIN as a transfer > intermediary. Hi Bill, Are you sure that has changed? In both versions, ARIN is the arbiter of the new registrant's qualification to receive the addresses. In both versions the new registrant enters the same binding legal agreement with ARIN regardless of their agreement with the old registrant. In neither version does ARIN evaluate or record the agreement between old and new registrants. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From kloch at kl.net Sat Jan 3 16:58:16 2009 From: kloch at kl.net (Kevin Loch) Date: Sat, 03 Jan 2009 16:58:16 -0500 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <495E8622.9060203@eboundhost.com> References: <495E8622.9060203@eboundhost.com> Message-ID: <495FDF78.50707@kl.net> Artur (eBoundHost) wrote: > Is there a reason why ISP's such as Comcast/ATT, allowed to hand out > unique IP addresses, even not static ones, to end users? Why are they > not required to use NAT? NAT breaks lots of things. In addition to the obvious (p2p, services) it breaks native IPSec and ipip tunnels (6to4 and static IPv6 tunnels). There are many applications like FTP that break in various ways depending on how good/bad the hacks in the NAT box are. There will be applications that NAT vendors have never heard of. Google "nat breaks" for some other examples. Operationally this would be a disaster for the ISPs: o How do you identify which customer is responsible for what traffic? Instead of keeping a simple database of IP->customer you would have to keep complete logs of ip/port->customer mappings. This would be extraordinarily impractical. o The public natted ips would be highly attractive DDOS targets as they would take out an entire neighborhood or ISP instead of an individual customer. o If a user gets banned at a particular server an entire neighborhood or ISP of users would also be banned. o IP based secondary access controls (for example only allowing ssh from a specific IP) would be less useful. o Cable ISPs provide exactly zero customer support today. How could possibly support all of the bugs that NAT would introduce or manage the static port or public ip mappings that would be required for the things that are broken. > If ISPs were to switch to local address space, how many IP blocks would > be released back into the wild? Zero? What incentive would they have to return space they already have if they know they can't ever go back for more? - Kevin From BillD at cait.wustl.edu Sat Jan 3 17:34:07 2009 From: BillD at cait.wustl.edu (Bill Darte) Date: Sat, 3 Jan 2009 16:34:07 -0600 Subject: [arin-ppml] 2008-6 Combined Wording Alternative References: <3c3e3fca0901031308l3020df01yac044db1c1c22528@mail.gmail.com> Message-ID: I did not intend to say that ARIN would be involved in the agreement to transfer between holder and recipient. My original proposal said explicitly that ARIN would only be involved as a recorder of the transfer, not an agent in it. Your wording seems to say that the holder would return the block of appropriate size to ARIN who would then transfer that block under RSA to the new recipient. I avoided implying that ARIN would have any control over the block during transfer, just to avoid anyone thinking that there needed to be some protections with that. As I said in my earlier post, I think the issue is semantic rather than real. Thanks for you continued involvement and interest in making this proposal better... bd -----Original Message----- From: wherrin at gmail.com on behalf of William Herrin Sent: Sat 1/3/2009 3:08 PM To: Bill Darte Cc: arin-ppml at arin.net Subject: Re: 2008-6 Combined Wording Alternative On Sat, Jan 3, 2009 at 9:37 AM, Bill Darte wrote: > Seems to me that Bill Herrin's version is clearer, but changes the proposal > by stating the transfer of resources must involve ARIN as a transfer > intermediary. Hi Bill, Are you sure that has changed? In both versions, ARIN is the arbiter of the new registrant's qualification to receive the addresses. In both versions the new registrant enters the same binding legal agreement with ARIN regardless of their agreement with the old registrant. In neither version does ARIN evaluate or record the agreement between old and new registrants. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bicknell at ufp.org Sat Jan 3 18:26:58 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 3 Jan 2009 18:26:58 -0500 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: References: <20090103013827.GB86274@ussenterprise.ufp.org> Message-ID: <20090103232658.GC26575@ussenterprise.ufp.org> In a message written on Sat, Jan 03, 2009 at 08:10:54AM -0600, Bill Darte wrote: > That is demand for communication services...that without v6 cannot be > satisfied, but is not demand for v6 itself. The ISP's make this leap for the customers. Much like they have decided 1 IP is enough for "most" customers and other decisions. No ISP wants to run "ISP Grade" NAT. It's a huge cost and hassle, be it 6to4, NAT646, or any other form. While they may do it to transition, virtually none will attempt it long term. Those that do will have reams of complaints on various message boards about how it breaks games, or voip, or p2p, or whatever. So the only viable, deployable, code that works path is native IPv6. ISP's will pick that path as they only one they can feesably support in a scalable internet, and customers will be told "if you want service, this is what you get". But, not until the absolute, last second. -- 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 spiffnolee at yahoo.com Sat Jan 3 20:21:03 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Sat, 3 Jan 2009 17:21:03 -0800 (PST) Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call References: <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <20090101204504.GA25609@ussenterprise.ufp.org> <495EA4E5.3080908@psg.com> <054DDA58-4E99-4FD5-AC2A-32078EA9E81E@apnic.net> Message-ID: <723614.71627.qm@web63301.mail.re1.yahoo.com> Randy and Geoff bickered: > > enough folk seem to have requested to maintain that status quo that > > the transfer proposal in ripe passed with it and the new one in > > apnic includes it to see if that will help get apnic past the thrice > > repeated non-consensus of a proposal without it. personally, i am > > not strongly religious either way. > "Thrice repeated non-consensus"??? > That is simply not the case, and I 'm surprised given your role in the > APNIC policy development process that you have such a misunderstanding > of the background of this proposal. > Please take this to the APNIC policy mailing list. http://mailman.apnic.net/mailman/listinfo/sig-policy Lee From artur at eboundhost.com Sat Jan 3 20:47:03 2009 From: artur at eboundhost.com (eBoundHost: Artur) Date: Sat, 3 Jan 2009 19:47:03 -0600 (CST) Subject: [arin-ppml] IPV4 allocations Message-ID: <9583395.22541231033623627.JavaMail.root@em.eboundhost.com> How many IPs in use today are used for people connecting to the net vs servers? Best Regards, Artur eBoundHost.com http://www.eboundhost.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Sat Jan 3 21:16:45 2009 From: randy at psg.com (Randy Bush) Date: Sun, 04 Jan 2009 11:16:45 +0900 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <20090103232658.GC26575@ussenterprise.ufp.org> References: <20090103013827.GB86274@ussenterprise.ufp.org> <20090103232658.GC26575@ussenterprise.ufp.org> Message-ID: <49601C0D.7030208@psg.com> > No ISP wants to run "ISP Grade" NAT. you wish randy From mpetach at netflight.com Sat Jan 3 21:26:11 2009 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 3 Jan 2009 18:26:11 -0800 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: References: <20081230222048.GA16505@ussenterprise.ufp.org> <75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu> <20090101204504.GA25609@ussenterprise.ufp.org> <20090103013827.GB86274@ussenterprise.ufp.org> Message-ID: <63ac96a50901031826o415559b7rc60e8ade678e6c6f@mail.gmail.com> On 1/3/09, Bill Darte wrote: > .... cja at daydream.com...wrote... > I guess I am still waiting for someone to come up with the killer > application for IPv6. Or a marketing scheme... get this new > service/speed/whatever if you sign up for IPv6. Of course you have to have > IPv6 deployed to sell it as part of a service. > ************* > Seems to me the sell is... the future comes with IPv6...we(as an ISP) offer > that service now.. if you want to be part of the future, come with us.... > (then a little FUD about what happens if you don't get on board) ;-) As I've noticed during the "IPv6 hour" at NANOG, attempting to use that "future" at this moment in the present leads to a woefully underwhelming user experience. Running dual-stack v4/v6 or worse, v6 only, leads to a much poorer user experience than running in a v4-only environment. It's a very tough sell to pitch to your customers: "hey, the future is IPv6; come sign up for our future-proofed dual-stack offering; it still burns IPv4 addresses, so it doesn't help the runout period, but at least you can connect to all 131* sites that support IPv6 at the moment; unfortunately, you'll have longer connect times as your DNS resolver attempts to fetch quad-A records first, and then falls back to seeing if there's A records for the site, and if a site returns a quad-A record but the v6 connectivity isn't working, you'll just be broken, it won't fall back to using v4, so you'll have an overall poorer experience than your v4-only neighbor; but it's the future, so you should sign up now!!!" No credible publically-traded company in their right mind would try to offer customers a "future" oriented product that has worse performance than the "present" oriented product. *http://www.ipv6.org/v6-www.html [but if people have better lists of IPv6-capable sites, it would be interesting/amusing to get a more current count--this was simply the first link returned from search engine for "ipv6 capable sites"] > bd Matt From randy at psg.com Sat Jan 3 21:46:15 2009 From: randy at psg.com (Randy Bush) Date: Sun, 04 Jan 2009 11:46:15 +0900 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <495FDF78.50707@kl.net> References: <495E8622.9060203@eboundhost.com> <495FDF78.50707@kl.net> Message-ID: <496022F7.5070806@psg.com> > NAT breaks lots of things. In addition to the obvious (p2p, services) > it breaks native IPSec and ipip tunnels (6to4 and static IPv6 tunnels). > There are many applications like FTP that break in various ways > depending on how good/bad the hacks in the NAT box are. There will be > applications that NAT vendors have never heard of. Google "nat breaks" > for some other examples. i just had a depressing private email exchange with your small and partially-clued isp. they felt that v4/v4/v4/v4 nat was the way to go because it was easier for them and easier for the customer. all i could say was that 'easier' might not be considering the customer support costs. the v6 end user experience today is not great. vendor support is mediocre, both for dual stack and for transition tools (siit/nat-pt). and the global infrastructure is often tunneled and tromboned. neither of these will be really fixed until there is financial pressure behind them. the market, not the mailing lists, rules. randy From mpetach at netflight.com Sat Jan 3 21:47:08 2009 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 3 Jan 2009 18:47:08 -0800 Subject: [arin-ppml] IPV4 allocations In-Reply-To: <9583395.22541231033623627.JavaMail.root@em.eboundhost.com> References: <9583395.22541231033623627.JavaMail.root@em.eboundhost.com> Message-ID: <63ac96a50901031847m2e51ebi74c1d80564fd019f@mail.gmail.com> On 1/3/09, eBoundHost: Artur wrote: > How many IPs in use today are used for people connecting to the net vs > servers? Well, I've been trying to assign an IP address to my brother for years now, but it still hasn't stuck yet; so, unless you're a bit further along in your bioengineering, I imagine 100% of the IP addresses in use are used by computer-type devices, and not by people. :P Now, many of those computer-type devices may happen to be used more interactively by humans, while others may be less interactively engaged by humans; but fundamentally, every IP in use is used by a computer-type device (network gear, etc. and other special-purpose gear fall under that same ruberic of "computer-type device"). Fundamentally, we can't really distinguish among the various computer-type devices to be able to say "oh, this category or subset is fine to NAT, but these others aren't" at the ISP level. Applications today are becoming more and more highly interactive, with information flowing bidirectionally on multiple ports. Even as an end user at home running NAT, I'm finding the number of NAT rules and ACL openings that have to be allowed is increasing over time, as embedded gtalk, jabber, YIM, AIM, and other seemingly end-user applications start to need more and more bidirectional connectivity between them. Trying to stave off the IPv4 runout by arbitrarily trying to draw lines between computer-type devices that are allowed to engage in bidirectional end-to-end communication vs those that must sit behind a NAT and can only engage in unidirectional communication is a dead-end course; we'd be better off focusing our energies on paths likely to lead to positive outcomes. Matt > Best Regards, > > Artur > eBoundHost.com > http://www.eboundhost.com From McNuttJ at missouri.edu Sat Jan 3 22:30:11 2009 From: McNuttJ at missouri.edu (McNutt, Justin M.) Date: Sat, 3 Jan 2009 21:30:11 -0600 Subject: [arin-ppml] IPV4 allocations In-Reply-To: <63ac96a50901031847m2e51ebi74c1d80564fd019f@mail.gmail.com> References: <9583395.22541231033623627.JavaMail.root@em.eboundhost.com> <63ac96a50901031847m2e51ebi74c1d80564fd019f@mail.gmail.com> Message-ID: Our "look way ahead into the future" IT people are thinking about taking it even further. They predict a day when we'll throw away the firewalls for the same reason we threw away NAT: They break two-way applications. Their argument - and it seems pretty sound to me - is that we only installed firewalls because at one time, the end stations were mostly incapable of defending themselves from malicious traffic from the Internet. This forced the client-server model onto a lot of apps, but it wasn't that painful, since at the time, most two-way apps were internal (and poorly-secured) things anyway. Three things have changed since then. First, host security has improved *somewhat*. Windows works pretty hard to make you leave the firewall turned on and apply patches. Second, two-way apps between hosts at different enterprises are much more common. Third, for those people who turned off the firewall and BITS and the internal nagware reminding you to patch your system, there are intrusion prevention systems nowadays that can sit in-line on the network the way firewalls do. The IPS can drop just the attack traffic, rather than just dropping everything from the outside. (Some IPS devices can "quarantine" inside or outside hosts that do susicious things, like port scanning and so on.) Basically, they predict a more "innocent until proven guilty" model for the network, since it allows for much better communication, and that's what the network was *built* for. How about DEM apples? IPS replaces firewall and two-way apps work again. It's merely tangential to this discussion, but the above serves to underline just how committed we are to a direction opposite of NAT. To us, NAT is something you do when you want to hide what you're doing or when your upstream provider won't give you more IP space. It's something you *have* to do, not something you ever *want* to do (for any good reason). I was dismayed to find out that NAT is still possible in IPv6, though pleased that it breaks enough things that it will, perhaps, be deemed unusable enough that it is never widely used. --J > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Petach > Sent: Saturday, January 03, 2009 8:47 PM > To: eBoundHost: Artur > Cc: ppml at arin.net > Subject: Re: [arin-ppml] IPV4 allocations > > On 1/3/09, eBoundHost: Artur wrote: > > How many IPs in use today are used for people connecting to > the net vs > > servers? > > Well, I've been trying to assign an IP address to my brother for years > now, but it still hasn't stuck yet; so, unless you're a bit > further along > in your bioengineering, I imagine 100% of the IP addresses in use are > used by computer-type devices, and not by people. :P > > Now, many of those computer-type devices may happen to be used > more interactively by humans, while others may be less interactively > engaged by humans; but fundamentally, every IP in use is used by a > computer-type device (network gear, etc. and other special-purpose > gear fall under that same ruberic of "computer-type device"). > > Fundamentally, we can't really distinguish among the various > computer-type devices to be able to say "oh, this category or > subset is fine to NAT, but these others aren't" at the ISP level. > Applications today are becoming more and more highly interactive, > with information flowing bidirectionally on multiple ports. Even as > an end user at home running NAT, I'm finding the number of NAT > rules and ACL openings that have to be allowed is increasing over > time, as embedded gtalk, jabber, YIM, AIM, and other seemingly > end-user applications start to need more and more bidirectional > connectivity between them. Trying to stave off the IPv4 runout > by arbitrarily trying to draw lines between computer-type devices > that are allowed to engage in bidirectional end-to-end communication > vs those that must sit behind a NAT and can only engage in > unidirectional communication is a dead-end course; we'd be > better off focusing our energies on paths likely to lead to > positive outcomes. > > Matt > > > Best Regards, > > > > Artur > > eBoundHost.com > > http://www.eboundhost.com > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From randy at psg.com Sat Jan 3 22:49:48 2009 From: randy at psg.com (Randy Bush) Date: Sun, 04 Jan 2009 12:49:48 +0900 Subject: [arin-ppml] IPV4 allocations In-Reply-To: References: <9583395.22541231033623627.JavaMail.root@em.eboundhost.com> <63ac96a50901031847m2e51ebi74c1d80564fd019f@mail.gmail.com> Message-ID: <496031DC.8050702@psg.com> On 09.01.04 12:30, McNutt, Justin M. wrote: > Our "look way ahead into the future" IT people are thinking about taking > it even further. They predict a day when we'll throw away the firewalls > for the same reason we threw away NAT: They break two-way applications. a laudable view. we try to follow that in our little universe. but we don't have many end users. > I was dismayed to find out that NAT is still possible in IPv6, though > pleased that it breaks enough things that it will, perhaps, be deemed > unusable enough that it is never widely used. we wish. at the november ietf, v6/v6 nat was discussed in two ways: o it is inevitable so 'we' should do it so it is done right. i read this as "someone is going to load ms greenberg on the cattle car, so it might as well be we." o and than an over the top science fiction massive koolaid attack from fred that needs to be read/seen to be believed. i am not sure if it is archived somewhere in some fashion. randy From mksmith at adhost.com Sat Jan 3 23:08:07 2009 From: mksmith at adhost.com (Michael K. Smith) Date: Sat, 03 Jan 2009 20:08:07 -0800 Subject: [arin-ppml] IPV4 allocations In-Reply-To: <496031DC.8050702@psg.com> Message-ID: On 1/3/09 7:49 PM, "Randy Bush" wrote: > On 09.01.04 12:30, McNutt, Justin M. wrote: >> Our "look way ahead into the future" IT people are thinking about taking >> it even further. They predict a day when we'll throw away the firewalls >> for the same reason we threw away NAT: They break two-way applications. > > a laudable view. we try to follow that in our little universe. but we > don't have many end users. > >> I was dismayed to find out that NAT is still possible in IPv6, though >> pleased that it breaks enough things that it will, perhaps, be deemed >> unusable enough that it is never widely used. > > we wish. at the november ietf, v6/v6 nat was discussed in two ways: > > o it is inevitable so 'we' should do it so it is done right. i > read this as "someone is going to load ms greenberg on the > cattle car, so it might as well be we." > > o and than an over the top science fiction massive koolaid attack > from fred that needs to be read/seen to be believed. i am not > sure if it is archived somewhere in some fashion. > If IPv6 is going to pass through the present litany of compliance bodies then Firewalls and NAT are here to stay. PCI requires both, HIPAA doesn't specifically, but there's no other way to meet the privacy requirements without them and now Microsoft's new PII standard has similar wording to PCI. The requirements for security were developed because of known issues as mentioned and, since none of the RFC's seem to say "IPv6 will make up for bad coding, bad applications, networks and systems installed and maintained by "bob the computer guy" then IPv6 better be able to do everything IPv4 does when it comes to established security criteria. The real world can be a drag. Mike From jmaimon at chl.com Sat Jan 3 23:15:45 2009 From: jmaimon at chl.com (Joe Maimon) Date: Sat, 03 Jan 2009 23:15:45 -0500 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <495E8622.9060203@eboundhost.com> References: <495E8622.9060203@eboundhost.com> Message-ID: <496037F1.7010606@chl.com> Artur (eBoundHost) wrote: > to end users? Why are they > not required to use NAT? nobody advocates natting end *customers* if addresses arent scarce. > > If ISPs were to switch to local address space, how many IP blocks would > be released back into the wild? They just might do exactly that when ipv4 gets scarce. Along with reserving global unique ipv4 for power users willing to pay for it and dual stack ipv6, its probably a sound scheme *if* thats what all your competitors will be doing as well. From artur at eboundhost.com Sat Jan 3 23:35:51 2009 From: artur at eboundhost.com (Artur (eBoundHost)) Date: Sun, 4 Jan 2009 04:35:51 +0000 Subject: [arin-ppml] IPV4 allocations Message-ID: <803596668-1231043616-cardhu_decombobulator_blackberry.rim.net-1430067159-@bxe309.bisx.prod.on.blackberry> Matt, I disagree with one point. If ARIN is going to give ips on a per need basis then we also need to consider whether isps are doing the same. If for example end users comprise half of usable ip space and we can hold off the ip depletion by asking isps to only allow public ips on a per need basis then its entirely reasonable. For instance, our customers are given ips only if they have certain criteria and everyone else is hosted on a shared block. No reason isps can't do the same. ------Original Message------ From: Matthew Petach Sender: mpetach at gmail.com To: eBoundHost: Artur Cc: ppml at arin.net Subject: Re: [arin-ppml] IPV4 allocations Sent: Jan 3, 2009 20:47 On 1/3/09, eBoundHost: Artur wrote: > How many IPs in use today are used for people connecting to the net vs > servers? Well, I've been trying to assign an IP address to my brother for years now, but it still hasn't stuck yet; so, unless you're a bit further along in your bioengineering, I imagine 100% of the IP addresses in use are used by computer-type devices, and not by people. :P Now, many of those computer-type devices may happen to be used more interactively by humans, while others may be less interactively engaged by humans; but fundamentally, every IP in use is used by a computer-type device (network gear, etc. and other special-purpose gear fall under that same ruberic of "computer-type device"). Fundamentally, we can't really distinguish among the various computer-type devices to be able to say "oh, this category or subset is fine to NAT, but these others aren't" at the ISP level. Applications today are becoming more and more highly interactive, with information flowing bidirectionally on multiple ports. Even as an end user at home running NAT, I'm finding the number of NAT rules and ACL openings that have to be allowed is increasing over time, as embedded gtalk, jabber, YIM, AIM, and other seemingly end-user applications start to need more and more bidirectional connectivity between them. Trying to stave off the IPv4 runout by arbitrarily trying to draw lines between computer-type devices that are allowed to engage in bidirectional end-to-end communication vs those that must sit behind a NAT and can only engage in unidirectional communication is a dead-end course; we'd be better off focusing our energies on paths likely to lead to positive outcomes. Matt > Best Regards, > > Artur > eBoundHost.com > http://www.eboundhost.com Best Regards, Artur eBoundHost http://www.eboundhost.com From michael at rancid.berkeley.edu Sun Jan 4 03:26:34 2009 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Sun, 04 Jan 2009 00:26:34 -0800 Subject: [arin-ppml] IPV4 allocations In-Reply-To: <803596668-1231043616-cardhu_decombobulator_blackberry.rim.net-1430067159-@bxe309.bisx.prod.on.blackberry> References: <803596668-1231043616-cardhu_decombobulator_blackberry.rim.net-1430067159-@bxe309.bisx.prod.on.blackberry> Message-ID: <496072BA.6040201@rancid.berkeley.edu> On 1/3/09 8:35 PM, Artur (eBoundHost) wrote: > Matt, > > I disagree with one point. If ARIN is going to give ips on a per need basis then we also need to consider whether isps are doing the same. > > If for example end users comprise half of usable ip space and we can hold off the ip depletion by asking isps to only allow public ips on a per need basis then its entirely reasonable. > > For instance, our customers are given ips only if they have certain criteria and everyone else is hosted on a shared block. No reason isps can't do the same. What is a "shared block" in this context? NAT? If so, you won't have me as your customer unless you offer me end-to-end IPv6 as well. In the R&E community, dissatisfaction with NAT has driven IPv6 deployment. Perhaps you plan to bring the same to the commercial ISP community? michael From artur at eboundhost.com Sun Jan 4 08:38:40 2009 From: artur at eboundhost.com (Artur (eBoundHost)) Date: Sun, 4 Jan 2009 13:38:40 +0000 Subject: [arin-ppml] IPV4 allocations Message-ID: <1782930193-1231076186-cardhu_decombobulator_blackberry.rim.net-1486229861-@bxe309.bisx.prod.on.blackberry> >What is a "shared block" in this context? In the hosting industry, we have an option. We can allocate an ip addr for each website or we can host thousands of websites from a single 'shared' ip. A Unique IP is handed out to customers who have special needs such as anonymous ftp and ssl certs. There is a small premium to cover the extra management and arin fees ($2 per month). This is a model that works well my industry and I wonder why its not implemented with ISPs. The vast majority of customers would have no idea about NAT and it would have no effect on their experience. And those that would genuinely need a publicly visible or static ip should be able to request an allocation. Understand where I'm coming from, I'm not trying to make policy that nobody wants but trying to understand it. If we genuinely have a problem with the ips running out then options have to be considered. And if changing out current customers is a big problem then maybe the new sign ups should be handled differently. Whatever it is, saying that this is a patch and throwing hands in the air and saying 'if we don't go ipv6 right away, its not going to solve anything' is not the right way. Its not a all or nothing issue. Best Regards, Artur eBoundHost http://www.eboundhost.com From McNuttJ at missouri.edu Sun Jan 4 08:53:12 2009 From: McNuttJ at missouri.edu (McNutt, Justin M.) Date: Sun, 4 Jan 2009 07:53:12 -0600 Subject: [arin-ppml] IPV4 allocations In-Reply-To: References: <496031DC.8050702@psg.com> Message-ID: > If IPv6 is going to pass through the present litany of compliance bodies > then Firewalls and NAT are here to stay. PCI requires both, HIPAA doesn't > specifically, but there's no other way to meet the privacy requirements > without them and now Microsoft's new PII standard has similar wording to > PCI. Actually, PCI requires firewalls, but not NAT. I'm told by our compliance people that a firewall that rejects all incoming traffic makes the host "unaddressable from the Internet," which is sufficient. I've never heard an auditor complain once he was shown the accountability issue on top of it. Getting rid of firewalls is for the Grand Future, not the present. It's also for the general case. PCI-compliant implementations do not encompass the majority of our user networks, as I suspect they don't for most networks, by design (since having hundreds of users in the same security zone as the e-commerce servers would break PCI). Point being, IPv6 firewalls aren't a problem. NAT is. > The requirements for security were developed because of known issues as > mentioned and, since none of the RFC's seem to say "IPv6 will make up for > bad coding, bad applications, networks and systems installed and maintained > by "bob the computer guy" then IPv6 better be able to do everything IPv4 > does when it comes to established security criteria. The thing is, *nothing* can make up for an insurmountable wave of stupidity (bad coding, bad apps, etc.). Better to just build something good. If people do bad and stupid things with it, then blame them for doing bad and stupid things, but don't *help them do it*. Building things that we know are bad into IPv6 on purpose is moving in the wrong direction. "If a team is in a positive frame of mind, it will have a good attitude. If it has a good attitude, it will make a commitment to playing the game right. If it plays the game right, it will win-unless, of course, it doesn't have enough talent to win, and no manager can make goose-liver pate out of goose feathers, so why worry?" --Sparky Anderson > The real world can be a drag. It can, indeed. I see no reason to participate in making it worse, though. If the fools can build NAT and make it work, let them. I, for one, do not intend to even attempt to support it, if it appears on my network. --J From cliffb at cjbsys.bdb.com Sun Jan 4 10:45:34 2009 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Sun, 04 Jan 2009 10:45:34 -0500 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org><20090103013827.GB86274@ussenterprise.ufp.org> Message-ID: <4960D99E.2000406@cjbsys.bdb.com> Bill Darte wrote: > > .... cja at daydream.com...wrote... > > I guess I am still waiting for someone to come up with the killer > application for IPv6. Or a marketing scheme... get this new > service/speed/whatever if you sign up for IPv6. Of course you have to > have > IPv6 deployed to sell it as part of a service. > ************* > > Seems to me the sell is... the future comes with IPv6...we(as an ISP) > offer that service now.. if you want to be part of the future, come > with us.... > (then a little FUD about what happens if you don't get on board) ;-) > > bd > There is no way to develop a "killer ap" for IPv6. There is too much inertia with IPv4. I think the only way to get IPv6 going is to develop a transparent "magic"* gateway between IPv6 and IPv4. This is not NAT, tunneling, etc. It is a IPv6 backbone with IPv6 routers and IPv6 addresses assigned to every IPv4 host in the world. This is premised on the fact that IPv6 is so huge that every org could put a copy of the entire IPv4 space in one small section of each organization's IPv6 space. I've talked about this before but will restate it here in a somewhat different way. The gateway box passes v4 requests for addresses through the box for outside domains and knows how to translate the internal v4 address to it's external v6 address along with any changes in protocol needed. As more and more machines become IPv6, the requirements for this box will be reduced but there will probably be a need for it for a long time for legacy applications. A diagram would look something like this v6 host --\ /-v4 host(with external unique v6 address) \ local /-v4 host(with external unique v6 address) v6 server--- v6 internet--router--\--v4-v6 box / \ other v6--/ \--local v6 hosts (I hope this comes through on all the mail readers without too much distortion.) I expect there are technical problems that will have to be addressed but I keep reading about all the NATs, v6-v4 NAT this and v6-v4-v6 that and it must be possible to get this done. The key is that the backbone is NOT v4, it is v6 and v4 will only exist on local nets behind the magic gateway. Advantages are: IPV6 can start immediately IPv4 can work as long as it needs to Backbone routers will be v6 only DNS can be IPv6 only until you get to the local v4 network. We don't need a "killer" v6 app to get it going. I don't think there has ever been a successful large conversion without backwards compatibility. When I had to start dialing the area code to call my next door neighbor, the phones didn't stop working, When the phone switches went digital, my analog phone still worked. The (US) digital TV conversion didn't require that I throw out my old TV ( and if that were two way, I could send old analog video back and people would see it.) My Windows XP system runs (almost) all my DOS programs and I can boot it to DOS if I need some special DOS feature. Intel has maintained compatibility with 8086 code. Frankly, there are too many IPv4 things that will break for IPv6 to ever become the only protocol. I think dual stack has all the problems of both and none of the advantages of either. If something along the lines of what I propose above doesn't happen, I don't think IPv6 will ever take off. People will continue to NAT to the nth power until IPvX that is backward compatible will come along. I've said it before but I'll repeat it here. I think IPv6 is so similar to the OSI/GOSIP SNAFU of the 1980s that it will suffer a similar fate unless the backward compatibility problem is addressed. Cliff * as in Arthur C Clarke's "Any sufficiently advanced science is indistinguishable from magic" -------------- next part -------------- An HTML attachment was scrubbed... URL: From jradel at vantage.com Sun Jan 4 11:43:18 2009 From: jradel at vantage.com (Jon Radel) Date: Sun, 04 Jan 2009 11:43:18 -0500 Subject: [arin-ppml] IPV4 allocations In-Reply-To: <1782930193-1231076186-cardhu_decombobulator_blackberry.rim.net-1486229861-@bxe309.bisx.prod.on.blackberry> References: <1782930193-1231076186-cardhu_decombobulator_blackberry.rim.net-1486229861-@bxe309.bisx.prod.on.blackberry> Message-ID: <4960E726.3080909@vantage.com> Artur (eBoundHost) wrote: >> What is a "shared block" in this context? >> > > In the hosting industry, we have an option. We can allocate an ip addr for each website or we can host thousands of websites from a single 'shared' ip. A Unique IP is handed out to customers who have special needs such as anonymous ftp and ssl certs. There is a small premium to cover the extra management and arin fees ($2 per month). > > This is a model that works well my industry and I wonder why its not implemented with ISPs. > > At the technology level, where the bits and protocols have to actually work, using NAT and having an HTTP server which implements the (now ancient) HTTP 1.1 extensions to allow using Host: to indicate which of multiple web sites should be served have essentially nothing to do with each other. This despite having the same goal: conservation of IP addresses. > The vast majority of customers would have no idea about NAT and it would have no effect on their experience. And those that would genuinely need a publicly visible or static ip should be able to request an allocation. > > Do you have a reference for that statement? Numbers? Studies? Evidence of any sort, even if blatantly anecdotal? If not, I'm afraid that I'll be going with the folks who have reported on the results of actual experiments or have enumerated some of the many widely used protocols which would break. > Understand where I'm coming from, I'm not trying to make policy that nobody wants but trying to understand it. > > Understanding the technology also has its uses. BTW, giving your customers dedicated IP addresses just because they use SSL certs is a terrible waste of addresses. There are several mechanisms for using certs on virtual hosts that share an address. Of course, none of them actually have universal support among widely deployed browsers and CAs, but why worry about support headaches and unhappy customers when you can save an IP address? ;-) (See http://wiki.cacert.org/wiki/VhostTaskForce for a light-hearted overview.) --Jon Radel jradel at vantage.com -------------- 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 mksmith at adhost.com Sun Jan 4 13:00:47 2009 From: mksmith at adhost.com (Michael K. Smith) Date: Sun, 04 Jan 2009 10:00:47 -0800 Subject: [arin-ppml] IPV4 allocations In-Reply-To: Message-ID: I'm not sure I agree, but I'll keep it brief because this is PPML and not a PCI list after all. :-) On 1/4/09 5:53 AM, "McNutt, Justin M." wrote: > >> If IPv6 is going to pass through the present litany of compliance > bodies >> then Firewalls and NAT are here to stay. PCI requires both, HIPAA > doesn't >> specifically, but there's no other way to meet the privacy > requirements >> without them and now Microsoft's new PII standard has similar wording > to >> PCI. > > Actually, PCI requires firewalls, but not NAT. I'm told by our > compliance people that a firewall that rejects all incoming traffic > makes the host "unaddressable from the Internet," which is sufficient. > I've never heard an auditor complain once he was shown the > accountability issue on top of it. > Check out PCI DSS 1.2 Section 1.3.8 "Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address translation (NAT) technologies?for example, port address translation (PAT)." Having the cardholder data completely locked down and unavailable is also required, but you have to have NAT in front of the application that serves the whole compliant network. Regards, Mike From dwise at gni.com Sun Jan 4 14:41:29 2009 From: dwise at gni.com (Derek Wise) Date: Sun, 4 Jan 2009 11:41:29 -0800 Subject: [arin-ppml] IPV4 allocations In-Reply-To: <1782930193-1231076186-cardhu_decombobulator_blackberry.rim.net-1486229861-@bxe309.bisx.prod.on.blackberry> References: <1782930193-1231076186-cardhu_decombobulator_blackberry.rim.net-1486229861-@bxe309.bisx.prod.on.blackberry> Message-ID: We hosting companies have options? Maybe on the small hosting ($49 a month server or virtual hosting category) but in the enterprise or large scale hosting we have these guys who think they are smart as customers asking for more IP space than they can possibly justify. Abusers perpetuate their businesses while those of us that try to follow ARIN guidelines and best practices for IP conservation lose revenue. It's part ignorance and part greed that continues the abuse of IP assignments today. I have a prospective client today that wants a /24 in space (just because he wants it). My competitors are giving him the IP space he can't justify at all. Significant monthly revenue I lose because I don't have a mechanism to report the abuse (does me very little good after I lose the deal? so I don?t really care how to report) and I can't do anything about someone giving him more IP's than he can use for the next 3 years. Don't get me wrong, idiot IT Managers who ask for more space than they need just to "feel" better should be out of a job and I sure as hell don't want to help these guys get what they want. But, how can I keep generating revenue when I have to turn away otherwise good business because someone else is using abusive IP allocation practices as their competitive edge? So the competitive edge goes to the abusers... In this thread there have been a few people chime in about the business impact. I personally feel ARIN should make a much bigger effort to campaign "IP Allocation Literacy" to new and existing netblock holders. Most of the ISP's will reduce the abusive practices somewhat as I have some faith that the majority are just illiterate about what the rules are. Nothing we do with "FIX" the IPv4 space (unless you have found some new way to do math) but literacy and policy helps with confidence in the organization controlling them and will help lengthen the life of the existing space and possibly help companies stay in business that follow the rules and keep this from becoming the wild west. Derek Wise ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of Artur (eBoundHost) [artur at eboundhost.com] Sent: Sunday, January 04, 2009 5:38 AM To: Michael Sinatra Cc: ppml at arin.net; mpetach at gmail.com Subject: Re: [arin-ppml] IPV4 allocations >What is a "shared block" in this context? In the hosting industry, we have an option. We can allocate an ip addr for each website or we can host thousands of websites from a single 'shared' ip. A Unique IP is handed out to customers who have special needs such as anonymous ftp and ssl certs. There is a small premium to cover the extra management and arin fees ($2 per month). This is a model that works well my industry and I wonder why its not implemented with ISPs. The vast majority of customers would have no idea about NAT and it would have no effect on their experience. And those that would genuinely need a publicly visible or static ip should be able to request an allocation. Understand where I'm coming from, I'm not trying to make policy that nobody wants but trying to understand it. If we genuinely have a problem with the ips running out then options have to be considered. And if changing out current customers is a big problem then maybe the new sign ups should be handled differently. Whatever it is, saying that this is a patch and throwing hands in the air and saying 'if we don't go ipv6 right away, its not going to solve anything' is not the right way. Its not a all or nothing issue. Best Regards, Artur eBoundHost http://www.eboundhost.com _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. !DSPAM:4960bbac241241324873753! From mpetach at netflight.com Sun Jan 4 17:07:04 2009 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 4 Jan 2009 14:07:04 -0800 Subject: [arin-ppml] 2008-6 What should the AC do In-Reply-To: <5D0F8DB0-F3EC-4AB6-A80A-241B06AE116E@delong.com> References: <5D0F8DB0-F3EC-4AB6-A80A-241B06AE116E@delong.com> Message-ID: <63ac96a50901041407m8c17875nba4cab79209c472e@mail.gmail.com> On 1/2/09, Owen DeLong wrote: > I'm glad to see a vigorous discussion about 2008-6 on the mailing list. > > However, since this proposal is in last call, there's a limited set of > choices for the AC to make about the policy... ... > I have seen the discussion range through all 4 options and it is not > clear to me that there is any level of community consensus around > any one of these options. > > Thanks, > Owen As I'm very confident that IPv4-to-IPv6-magic-transparent-interworking won't be production ready any time soon, I'm in favour of option 2; make the necessary tweaks to the language to clear up any remaining ambiguity, and then move the proposal forward; the market will erupt once RIRs have no more space to give out, IPv6 won't save us, and we need to be ready for what will come. Thanks! Matt From martin.hannigan at batelnet.bs Sun Jan 4 23:27:28 2009 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Sun, 4 Jan 2009 23:27:28 -0500 Subject: [arin-ppml] 2008-6 What should the AC do In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACD0@mail> References: <5D0F8DB0-F3EC-4AB6-A80A-241B06AE116E@delong.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACD0@mail> Message-ID: <4607e1d50901042027w39f32deevbc34b48f63d394cb@mail.gmail.com> On Fri, Jan 2, 2009 at 4:06 PM, Kevin Kargel wrote: > > > > In light of this request by Owen my choice is option 4, abandon the > proposal. > > +1 -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmaimon at chl.com Mon Jan 5 00:26:43 2009 From: jmaimon at chl.com (Joe Maimon) Date: Mon, 05 Jan 2009 00:26:43 -0500 Subject: [arin-ppml] 2008-6 What should the AC do In-Reply-To: <5D0F8DB0-F3EC-4AB6-A80A-241B06AE116E@delong.com> References: <5D0F8DB0-F3EC-4AB6-A80A-241B06AE116E@delong.com> Message-ID: <49619A13.906@chl.com> Owen DeLong wrote: > I'm glad to see a vigorous discussion about 2008-6 on the mailing list. > > However, since this proposal is in last call, there's a limited set of > choices > for the AC to make about the policy... > > Quoting from the ARIN web site: > The proposal only seems to enable the ability for numbers to be transferred and doesn't actually put in any framework for how this should happen. Whether any such thing is required is a separate debate. This policy should stand or fall on its own merits. However, this policy is: a) necessary since ipv6 native flag day is not going to happen, b) already happening by all indications, c) desirable for everyone who uses ipv4 numbers and wants them to continue to be available and efficiently utilized, d) morally correct in the face of the alternatives such as forced reclamations and strict top down rationing of remaining resources or tolerating hijacking or worse, e) required for continuing relevancy for ARIN with regards to ipv4 numbers, f) good for ipv6 deployment goals by attaching monetary disincentives to sticking with ipv6 instead of simple engineering difficulty, because it provides accommodations for people to transfer what they may no longer need for the proper incentives to those who do need it. I would suggest that it is in all our best interests that any such transferring occur under the purview, auspices and within the community that has established ARIN to perform these number related functions. Should the need actually exist in the extent to cause this to happen without ARIN involvement, I expect nobody would be happy with that result. And if nobody wants to transfer numbers, a policy authorizing it will have no impact. If ARIN members want to transfer numbers, vocal mailing list members dont speak for the community when they raise vociferous objections to the concept, usually in the guise of a utopian ideal cutover to ipv6. Maybe it will happen. Likely it wont. But it wont have anything to do with whether ARIN policies authorizes number transferring or not. In fact, IPv6 does not have to be relevant to the question of whether ARIN should process under authorized policy ipv4 number transfers that ARIN community members may want to perform. IP address transferring is something that will or will not happen, but not because of policies ARIN adopts. Anyone notice that other RIR's seem to have already decided on this question? What makes it so difficult here? They have less available numbers than we do? >> The Advisory Council will review the comments collected during the >> last call period and may: 1) support the proposal as is and recommend >> that the Board of Trustees adopt +1 , 2) find minor revisions are >> necessary in which case the Advisory Council or author will redraft >> and post again to last call, 3) find major revisions are needed in >> which case the Advisory Council or author will redraft and the Major revisions arent warranted for this policy change -- it hits all the high notes required at this time. Authorizes transfers Maintains Need based Advances RSA contracts Comes with a sunset that can be revisited if needed Only kicks in when the status quo must change anyways Whats wrong with that? >> proposal will be posted for the next public policy meeting, or 4) find >> community support to abandon the proposal. > > So, I would like to encourage members of the community commenting > on this proposal to express clearly which of the above four actions > you believe the AC should take. > > I have seen the discussion range through all 4 options and it is not > clear to me that there is any level of community consensus around > any one of these options. Perhaps we need more direct voting by ARIN constituency members -- creating consensus by analyzing mailing posts strikes me as overly susceptible to various statistical biases. > Thanks, > > Owen > > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mpetach at netflight.com Mon Jan 5 02:32:20 2009 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 4 Jan 2009 23:32:20 -0800 Subject: [arin-ppml] Is this more desired than aTransferPolicy? Needinput In-Reply-To: <0DEFCFA8E3C646F7B60B79DEFE3AE8BB@tedsdesk> References: <11AB7C03-677F-45C0-8B49-41932765EEE2@svcolo.com> <0DEFCFA8E3C646F7B60B79DEFE3AE8BB@tedsdesk> Message-ID: <63ac96a50901042332h5f35155ev5ae1a2ccc9494aeb@mail.gmail.com> On 11/19/08, Ted Mittelstaedt wrote: ... > I simply disagree. You have to do the same amount of application > conformance > testing when your going to a new Windows OS. Consider the millions of > bucks these companies are paying Microsoft every year for their MS > site licenses. IPv6 rollouts require NO licensing fees! Can you point me to Cisco and Juniper software images that support IPv6 that do not require additional licensing costs over what the IPv4-only software version costs? All the versions I've looked at so far, the IPv6 capable software is different from the IPv4 software, and getting IPv6 functionality requires paying additional license fees, which is a stumbling point for a lot of sites. I think until we can remove these artificial hurdles in the path of IPv6 deployments, we're going to see a lot of resistance towards moving to IPv6 due to increased costs associated with trying to deploy IPv6. For some products, in fact, vendors are actively *removing* IPv6 support. In the past, I would have been able to get IPv6 images for the routers I use at home; but Cisco has removed all IPv6 support for the product line, and has made it impossible for me to run IPv6 on it now, even though at one time they did offer versions of IOS for it that supported IPv6. These types of hurdles make deploying IPv6 an uphill battle for many people. So we really do need to look at what other possible scenarios there are, other than just assuming everyone will simply move to IPv6. Matt From michael at rancid.berkeley.edu Mon Jan 5 02:58:33 2009 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Sun, 04 Jan 2009 23:58:33 -0800 Subject: [arin-ppml] Is this more desired than aTransferPolicy? Needinput In-Reply-To: <63ac96a50901042332h5f35155ev5ae1a2ccc9494aeb@mail.gmail.com> References: <11AB7C03-677F-45C0-8B49-41932765EEE2@svcolo.com> <0DEFCFA8E3C646F7B60B79DEFE3AE8BB@tedsdesk> <63ac96a50901042332h5f35155ev5ae1a2ccc9494aeb@mail.gmail.com> Message-ID: <4961BDA9.7000304@rancid.berkeley.edu> On 1/4/09 11:32 PM, Matthew Petach wrote: > On 11/19/08, Ted Mittelstaedt wrote: > ... >> I simply disagree. You have to do the same amount of application >> conformance >> testing when your going to a new Windows OS. Consider the millions of >> bucks these companies are paying Microsoft every year for their MS >> site licenses. IPv6 rollouts require NO licensing fees! > > Can you point me to Cisco and Juniper software images that > support IPv6 that do not require additional licensing costs > over what the IPv4-only software version costs? IOS 12.2(33)SXI (the latest release for the 6500 platform) All JunOS releases for the M and T series. > All the versions > I've looked at so far, the IPv6 capable software is different from > the IPv4 software, and getting IPv6 functionality requires > paying additional license fees, which is a stumbling point > for a lot of sites. Yes, there are some platforms for brand c and brand j (and others) that require additional licensing, but there are also those that don't. For a long time, Juniper made it an advertising point that they did not require any different image train or fees. The fact that they are doing this for some of their newer platforms is not only disappointing, it's downright slimy, given the real need to move to IPv6. > I think until we can remove these artificial > hurdles in the path of IPv6 deployments, we're going to see > a lot of resistance towards moving to IPv6 due to increased > costs associated with trying to deploy IPv6. I hope you give your vendor salescritters and SEs as much of a tongue-lashing as I do about this behavior. The fact that Cisco is now moving in the right direction on the 6500 (and possibly 7600) platforms is encouraging. > For some products, in fact, vendors are actively *removing* > IPv6 support. In the past, I would have been able to get > IPv6 images for the routers I use at home; but Cisco has > removed all IPv6 support for the product line, and has made > it impossible for me to run IPv6 on it now, even though at > one time they did offer versions of IOS for it that supported > IPv6. These types of hurdles make deploying IPv6 an uphill > battle for many people. So we really do need to look at > what other possible scenarios there are, other than just > assuming everyone will simply move to IPv6. I think ARIN should be pushing IPv6 as hard as it can, and not relying on vendors to do the right thing first. We need to draw a line in the sand for vendors. This is the same rationale I would argue for not extending the timeline for transition to 4-byte ASNs. Policies need to be realistic, but they also need to drive the right behavior by vendors and users alike. We shouldn't be compromising good policy because vendors are doing frankly stupid things. michael From michael.dillon at bt.com Mon Jan 5 03:35:52 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 5 Jan 2009 08:35:52 -0000 Subject: [arin-ppml] 2008-6 What should the AC do In-Reply-To: <5D0F8DB0-F3EC-4AB6-A80A-241B06AE116E@delong.com> Message-ID: > So, I would like to encourage members of the community > commenting on this proposal to express clearly which of the > above four actions you believe the AC should take. Abandon the proposal. --Michael Dillon From michael.dillon at bt.com Mon Jan 5 03:42:56 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 5 Jan 2009 08:42:56 -0000 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <495E8622.9060203@eboundhost.com> Message-ID: > Is there a reason why ISP's such as Comcast/ATT, allowed to > hand out unique IP addresses, even not static ones, to end > users? Why are they not required to use NAT? > > If ISPs were to switch to local address space, how many IP > blocks would be released back into the wild? A few years ago, Comcast noted that there was not enough addresses in the RFC 1918 space for them to fully number their network, therefore, they began the move to using IPv6 internally. There is a pointer on this page to a Comcast presentation about how and why. --Michael Dillon From michael.dillon at bt.com Mon Jan 5 03:47:49 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 5 Jan 2009 08:47:49 -0000 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <495E98F4.8030907@vantage.com> Message-ID: > Basically there are a lot of protocols that have been kludged > to support one layer of NAT at the edge of the enterprise or > home network, but if you add another layer of NAT somewhere > things get really squirrelly, really fast. Also, from a more > philosophical standpoint, I'm opposed to any furthering of > "oh, they're just consumers; a bit of web surfing, a bit of > e-mail, a bunch of the video pap we want to sell them...what > on earth would they need to do anything more for?" mindset > that already > taints many consumer offerings. Let's keep the Internet a 2-way > medium. ;-) The biggest problem is not the NAT (Network Address Translation), it is the extension of the network address space by using port numbers as well. Pure one-to-one NAT is less of a problem. > Hasn't this topic been beaten to death in many slightly more > pertinent venues? Not only that, but some of those venues have developed NPAT and NAT64 to allow the use of NAT to be reduced to only enable access of those sites which have not yet switched to IPv6. This kind of NAT is far less of a problem than v4 NAT and double NAT. Basically if you are going to the trouble and expense of using NAT as a hedge against IPv4 exhaustion, you get more bang for the buck with NPAT and/or NAT64. --Michael Dillon From michael.dillon at bt.com Mon Jan 5 04:13:34 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 5 Jan 2009 09:13:34 -0000 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <20090103013827.GB86274@ussenterprise.ufp.org> Message-ID: > Here's the interesting dynamic; there is almost no > first-mover advantage to deploying IPv6 first. This is not entirely true. There are now large organizations that have decided to deploy IPv6 for strategic reasons and that want one or more network operators to supply them with IPv6 services in order to assist them with their tests and trials. The number of such organizations is on the increase and this presents the "first mover" ISPs with the opportunity to break existing supplier relationships with their competitors who do not offer IPv6 yet. > However, beyond that it doesn't get you > extra revenue, and may make you purchase equipment you would > not otherwise purchase, run newer software with more bugs, etc. Existing network hardware (servers and routers) has had IPv6 support for years now. Nobody is seriously suggesting that there is a need to buy new equipment beyond the normal technology refresh cycle. As for software, I don't believe that there is a correlation with newness and bug counts. In general, software packages continually get newer features added whether you use the features or not. This is what drives bug counts, and you will not escape this by not deploying IPv6. > We see ISP's state this over and over, the customers do not > want it, so we're not doing it. But when the customers do start asking for it, will these ISPs be ready with a tested service, or will they start losing those customers to their competition? > ISP's will also move to push the transition costs > to their competitors, last one with a transition box looses. Makes more sense to push that cost onto customers because you have less issues of scaling if the customer has the transition box on their premises. > Akamai's and > Limelight's I suspect could offer IPv6 services worldwide in > a matter of a few weeks, if there was a reason to do so. Yes, and there are a couple of companies working on virtualized IPv4 machines with IPv6 translation bundled in. Basically, they copy your server's hard drives into a virtual machine hard drive running XEN or VMWare, and then the host machine layer transparently does the NATPT or NAT64 services transparently to the legacy v4 server which has now been virtualised. > In short, the least effort, least cost path is to delay as > long as possible, then for everyone to leap forward at a > brisk pace; essentially as fast as possible without paying > money just to "speed it up." No argument there, just that everybody has to be deploying IPv6 today in their test and trial facilities to make this work. Most of the big companies are doing so, but we need to get more of the mid-sized ISPs doing this as well. --Michael Dillon From kkargel at polartel.com Mon Jan 5 09:25:30 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 5 Jan 2009 08:25:30 -0600 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <0FDF2FDC-4578-461D-9812-EB8CF393D8D4@kanren.net> References: <1076601153-1230933992-cardhu_decombobulator_blackberry.rim.net-836677388-@bxe309.bisx.prod.on.blackberry> <0FDF2FDC-4578-461D-9812-EB8CF393D8D4@kanren.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACD5@mail> > Using Skype to talk to my sister in Greece or my brother in the army > in Afghanistan > Operating my amateur radio station remotely when I'm away from home > Checking in on my cats during the day by logging into a web-cam server > Sending pictures to my friends through IM directed connections > Playing computer games with friends (not massively online, just a > couple of us) > Slingbox type media applications (not all of it is illegal) > > While a lot of this may be seen as p2p, I want to make sure there's no > mistaking p2p with "violating copyright by trading media files". I > think about a lot of things that myself and a lot of my friends and > family do, we really aren't just checking our Yahoo mail or browsing > the Web anymore. Sure we do a lot of it, but we do a lot of other > things too, and moreover, I suspect as the Internet evolves, there > will continue to be more and more applications that involve one end > user communicating directly to another... We are globalizing on a > personal level. While NAT can work in a lot of places, forcing it on > residential users is probably very counterproductive to the evolution > of information exchanges. > > > > With the advent of IPv6 this will be even more prevalent. When every device in your house can have it's own IP address there is then your lights, furnace, water heater, telephone answering machine, kitchen oven , even your toaster can be controlled by IP as remotely as you want. No more wondering if you left the coffee pot on as you get on the plane.. Of course you will need a pretty darn good firewall.. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From bicknell at ufp.org Mon Jan 5 09:29:04 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 5 Jan 2009 09:29:04 -0500 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: References: <20090103013827.GB86274@ussenterprise.ufp.org> Message-ID: <20090105142904.GA11805@ussenterprise.ufp.org> This may quickly dive into the weeds, but I wanted to reply to a couple of points. In a message written on Mon, Jan 05, 2009 at 09:13:34AM -0000, michael.dillon at bt.com wrote: > > Here's the interesting dynamic; there is almost no > > first-mover advantage to deploying IPv6 first. > > This is not entirely true. There are now large organizations Hence the almost. Note that, ISP's deploying before their customers want it is not "first mover", but rather the way it has to be done. ISP's have to get their backbones in order, provisioning systems in order, and so on before they can take on customers. There are several ISP's offering IPv6 services now. If there were a significant first mover advantage they would be growing at a rate far outpacing the rest of the industry as a result. At least from my perspective I don't see that. > > However, beyond that it doesn't get you > > extra revenue, and may make you purchase equipment you would > > not otherwise purchase, run newer software with more bugs, etc. > > Existing network hardware (servers and routers) has had IPv6 > support for years now. Nobody is seriously suggesting that there > is a need to buy new equipment beyond the normal technology > refresh cycle. As for software, I don't believe that there is Actually, I am, but not in the way you're thinking (I believe). Will a backbone provider need to buy significant amounts of new hardware? I doubt it. Will enterprises and the like have to buy significant amounts of new hardware, quite likely. While there are plenty of 2501's out there terminating T1's for low bandwidth apps (e.g. POS) that might need to be forklifted to get the ram, flash, and heft to run new code the more interesting case to me is things like 2800's lacking ram and flash. The act of upgrading a box at a remote office with no qualified remote hands is probably more painful than just swapping out a backbone box in a data center. So while the hardware may be simple (ram, flash, disk) the act of installing it may be hugely complicated. Let's also not forget things like the cable co's, where they need to upgrade to DOCSIS 3.0, which probably means new hardware. So there's plenty of hardware that needs to be replaced/upgraded; it's just further to the edge than we normally discuss. Fortunately, the edge is typically easier, it can be done in smaller increments. > > We see ISP's state this over and over, the customers do not > > want it, so we're not doing it. > > But when the customers do start asking for it, will these ISPs > be ready with a tested service, or will they start losing those > customers to their competition? This to me is the only entertaining part of IPv6. There is asbolutely a game of chicken going on. Which ISP will move first, and how agressively will they move their customers, and how many problems will they have. Some ISP's will win big, some will loose big. Some are going to deploy a fiscal year too late and miss the boat, some a year early and blow capital they could have better used on something else. -- 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 kkargel at polartel.com Mon Jan 5 09:36:11 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 5 Jan 2009 08:36:11 -0600 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <20090103013827.GB86274@ussenterprise.ufp.org> References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org> <20090103013827.GB86274@ussenterprise.ufp.org> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACD6@mail> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Leo Bicknell > Sent: Friday, January 02, 2009 7:38 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 2008-6: Emergency > TransferPolicyforIPv4 Addresses - Last Call > > In a message written on Fri, Jan 02, 2009 at 03:07:47PM -0500, John > Schnizlein wrote: > > On 2009Jan1, at 3:45 PM, Leo Bicknell wrote: > > >The status quo ends, however, when it does I have a markedly different > > >view of the world than you do. I believe that: > > > > > > - IPv6 is deployed fairly rapidly, and with limited pain. > > > > What would prompt this sort of radical change from the deplorably slow > > deployment over the last several years? > > Here's the interesting dynamic; there is almost no first-mover > advantage to deploying IPv6 first. You want to deploy it before > your customers want it, so you don't have to turn them away; and > you want your engineers to have experience with it. However, beyond > that it doesn't get you extra revenue, and may make you purchase > equipment you would not otherwise purchase, run newer software with > more bugs, etc. > > We see ISP's state this over and over, the customers do not want > it, so we're not doing it. > Right now the biggest incentive for an ISP to implement (notice I didn't say 'move to') IPv6 is a social one. ISP's are technical service offerings and the ability to say "We did it first" is not trivial. Aside from that many administrators at ISP's are tech junkies and are anxious to get in and play with the new technology. Many ISP's keep ahead of the hardware curve and have hardware that is already IPv6 capable. The admins at these companies will be able to implement some level of IPv6 for little more than the cost of configuring an IPv6 DNS and the time (this time may be significant) it takes to plan the routing scheme and firewall. These pioneers are the guys that will get it started. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From kkargel at polartel.com Mon Jan 5 09:42:06 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 5 Jan 2009 08:42:06 -0600 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org><20090103013827.GB86274@ussenterprise.ufp.org> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACD7@mail> I guess I am still waiting for someone to come up with the killer application for IPv6. Or a marketing scheme... get this new service/speed/whatever if you sign up for IPv6. Of course you have to have IPv6 deployed to sell it as part of a service. I am afraid the major driver will be one of two things. Either someone will offer porn content on IPv6 that is not available on IPv4, or people will find that IPv6 P2P file sharing will not have the restrictions or problems that it does on IPv4. If either of these comes to pass then the public will clamor for IPv6. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From bicknell at ufp.org Mon Jan 5 09:57:27 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 5 Jan 2009 09:57:27 -0500 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACD7@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACD7@mail> Message-ID: <20090105145727.GA13390@ussenterprise.ufp.org> In a message written on Mon, Jan 05, 2009 at 08:42:06AM -0600, Kevin Kargel wrote: > I guess I am still waiting for someone to come up with the killer > application for IPv6. Or a marketing scheme... get this new > service/speed/whatever if you sign up for IPv6. Of course you have to > have IPv6 deployed to sell it as part of a service. I think it's quite likely we'll see the following offered by various ISP's: * Replace your hardware at your cost and get faster speeds, along with IPv6. Cable companies are particularly well poised for this offering, IPv6 requires DOCSIS 3.0, which also allows them to offer more speed in the same frequencies. I totaly expect offers like "If you buy a new DOCSIS 3.0 cable modem and self install your speeds will automatically go from 8/1 to 12/2, and you'll get IPv6 for free!". Note, this also works for traditional ISP's, who can also make margin on it; "The managed service router you purchased from us is now 8 years old, and can't support new technology. Buy a new one from us and we'll configure it ready to drop in place, complete with IPv6 support. Order now and we'll bump the CIR on all your frame PVC's by 10% for the same price." * Upgrade to IPv6 and we won't rate shape for enforce transfer limits on your IPv6 traffic for the next 12 months! * Return the IPv4 /24 to us that we provided you with your service, and in return we'll ship you a brand new 2800 to replace your 2500 for free, preconfigured for IPv6 with your own /48. There's hundreds of other creative things that could, and I'm sure will, be done. > I am afraid the major driver will be one of two things. Either > someone will offer porn content on IPv6 that is not available on IPv4, > or people will find that IPv6 P2P file sharing will not have the > restrictions or problems that it does on IPv4. If either of these > comes to pass then the public will clamor for IPv6. Both of those have already happened, as well documented on NANOG. While it is possible that we could have taken a different path to this point as an industry, moving on things like ubiqitous IPSec end to end and thus driving IPv6 from an application perspective the reality is we didn't. IPv6 is IPv4 with larger numbers. As such there is not, and never will be a "killer app" that drives it. IPv4 exhaustion will be the driver, and likely the only one. -- 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 michael.dillon at bt.com Mon Jan 5 10:01:03 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 5 Jan 2009 15:01:03 -0000 Subject: [arin-ppml] Policy Proposal 2008-6: EmergencyTransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACD7@mail> Message-ID: > I guess I am still waiting for someone to come up with the > killer application for IPv6. It is called Voice-over-IP. On the PSTN, anyone in the world can dial your number and make your phone ring. On the IPv4 Internet, this is hard to do because of widespread NAT. But on the IPv6 Internet, we will once again have the flexibility of the PSTN, without the need for huge centralised control systems. This will enable the large ISPs, most of whom are already PSTN operators of one sort or another, to dump several generations of old technology (TDM, PDH, ISDN, ATM, frame-relay, and even SDH) and replace it all with IPv6 based services. Why is this a killer app? Because it leads to much deeper and widespread standardisation, thus enabling much cheaper operating costs. This meets the market demand for cheaper and cheaper voice communications costs. Everything will run over IPv6 over Ethernet over fiber or wireless. Got a hard drive at home that you want to access from the office? Just mount it using iSCSI. Someone ring your doorbell while you are on the beach in St. Tropez? Just connect to your intercom and ask them what they want. All the pieces of this are out there already, it just takes some vision to put it into play. > I am afraid the major driver will be one of two things. > Either someone will offer porn content on IPv6 that is not > available on IPv4, or people will find that IPv6 P2P file > sharing will not have the restrictions or problems that it > does on IPv4. If either of these comes to pass then the > public will clamor for IPv6. I don't believe in either of those scenarios. The IPv6 transition is not like marketing a new product. It is fixing some issues with the network infrastructure in order to enable new products and in order to ensure continued growth of the network. Companies are adding a new capability to their network. --Michael Dillon From bmackey at constantcontact.com Mon Jan 5 10:55:23 2009 From: bmackey at constantcontact.com (Mackey, Bruce) Date: Mon, 5 Jan 2009 10:55:23 -0500 Subject: [arin-ppml] 2008-6 What should the AC do In-Reply-To: References: Message-ID: Bruce Mackey Sr. Network Engineer >> So, I would like to encourage members of the community commenting on >> this proposal to express clearly which of the above four actions you >> believe the AC should take. > >Abandon the proposal. > >--Michael Dillon +1 Bruce Mackey Sr. Network Engineer Constant Contact From craig.finseth at state.mn.us Mon Jan 5 10:58:07 2009 From: craig.finseth at state.mn.us (Craig Finseth) Date: Mon, 5 Jan 2009 09:58:07 -0600 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACD6@mail> (kkargel@polartel.com) References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org> <20090103013827.GB86274@ussenterprise.ufp.org> <70DE64CEFD6E9A4EB7FAF3A06314106601B4ACD6@mail> Message-ID: <200901051558.n05Fw7ee014999@inana.itg.state.mn.us> Many ISP's keep ahead of the hardware curve and have hardware that is already IPv6 capable. The admins at these companies will be able to implement some level of IPv6 for little more than the cost of configuring an IPv6 DNS and the time (this time may be significant) it takes to plan the routing scheme and firewall. These pioneers are the guys that will get it started. Speaking as someone associated with an ISP that is trying to get it started (we support it on the backbone, we support it in our DNS), the problems are NOT in the routers, but in the supporting applications. Things like network management, SIEM (log mangement), and others. For example, we are in the RFP process for a SEIM solution. Pretty much all major players responded. Only 1 - yes 1 - claimed to offer IPv6 support. NONE of the rest offered it or even claimed to be working on it. (Yes, we encouraged them to tell us if they were.) How do I support IPv6 if we don't wind up buying that particular solution? (There are over 250 questions on that RFP and IPv6 is only one: it can't dominate the decision.) And this is as current information as you're going to get. Craig A. Finseth craig.finseth at state.mn.us Systems Architect +1 651 201 1011 desk State of Minnesota, Office of Enterprise Technology 658 Cedar Ave +1 651 297 5368 fax St Paul MN 55155 +1 651 297 1111 TAC, for reporting problems From tedm at ipinc.net Mon Jan 5 18:40:21 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 5 Jan 2009 15:40:21 -0800 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <115990992-1230933680-cardhu_decombobulator_blackberry.rim.net-1753859872-@bxe309.bisx.prod.on.blackberry> Message-ID: <0C09DEECB7C24B518351DC907942096F@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Artur (eBoundHost) > Sent: Friday, January 02, 2009 2:04 PM > To: Stephen Sprunk > Cc: ARIN-PPML at arin.net > Subject: Re: [arin-ppml] Why are ISPs allowed? > > > >at least one host > >(otherwise, why would they buy the >service?) and thus assigning one > >address per customer is automatically >justified. > > I'm strictly talking about home users, not hosting providers. > This ISP has also experimented with using NAT. The biggest problem with it is that if 1 single customer on the NAT gets infected with a virus it takes down the entire lot of them. Your typical run-of-the-mill virus, as soon as it infects a PC it commences to contact tens of thousands of other PC's on the Internet to propagate itself. Worse, most viruses are spam generators also and send out tens of thousands of spams. Because there is no central list of hosts on the Internet the viruses guess, often by iteration, attempting to contact IP's like 1.1.1.1 1.1.1.2 1.1.1.3 1.1.1.4 . . . etc. Since most of these IP's are bogus what happens is the translator opens the outgoing TCP connect, but never sees a TCP acknowledgement from the remote side. This uses up a "translation table entry" in the translator, that is held open until the NAT times it out. (it can't close it any other way since there is never a TCP close that will come from the remote side) While it's doing this, the virus continues to the next victim it is guessing. As a result a single PC can literally tie up several thousand (or even more, if the PC is fast) translation slots in the NAT. This usually chews up all free ram in the translator until the NAT then crashes. Ted From farmer at umn.edu Mon Jan 5 19:31:50 2009 From: farmer at umn.edu (David Farmer) Date: Mon, 05 Jan 2009 18:31:50 -0600 Subject: [arin-ppml] Is this more desired than aTransferPolicy? Needinput In-Reply-To: <4961BDA9.7000304@rancid.berkeley.edu> References: <11AB7C03-677F-45C0-8B49-41932765EEE2@svcolo.com>, <63ac96a50901042332h5f35155ev5ae1a2ccc9494aeb@mail.gmail.com>, <4961BDA9.7000304@rancid.berkeley.edu> Message-ID: <49625216.16168.1AAC7DC@farmer.umn.edu> On 4 Jan 2009 Michael Sinatra wrote: > On 1/4/09 11:32 PM, Matthew Petach wrote: > > On 11/19/08, Ted Mittelstaedt wrote: ... > > Can you point me to Cisco and Juniper software images that > > support IPv6 that do not require additional licensing costs > > over what the IPv4-only software version costs? > > IOS 12.2(33)SXI (the latest release for the 6500 platform) > All JunOS releases for the M and T series. > > > All the versions > > I've looked at so far, the IPv6 capable software is different from > > the IPv4 software, and getting IPv6 functionality requires paying > > additional license fees, which is a stumbling point for a lot of > > sites. > > Yes, there are some platforms for brand c and brand j (and others) > that require additional licensing, but there are also those that > don't. For a long time, Juniper made it an advertising point that > they did not require any different image train or fees. The fact that > they are doing this for some of their newer platforms is not only > disappointing, it's downright slimy, given the real need to move to > IPv6. The following is the first time I've seen this in print from Cisco, I've had private assurances that this was the direction for about a year now. But since this is a published Cisco document I felt I could say something publicly. So, I personally expect that over the next release or two for most Cisco platforms you should see similar moves for IPv6/IPv4 feature packaging parity. Now, they need to keep working on IPv6/IPv4 feature availability parity. Note the reference to "regional registries issuing advisory to the Internet community to adopt IPv6" Way to go Cisco!!! And good job, ARIN and the other RIRs too!!! I haven't looked for anything similar from Juniper, but hopefully Juniper and others vendors will follow suit. From: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8802/ps6970/ps6017/ ps9673/product_bulletin_c25-503086.html 2. Release 12.2(33)SXI IP Version 6 (IPV6) Repackaging For years, Cisco IOS has expanded support of IPv6 to the majority of its technology areas and hardware platforms. Originally added to the former IP Plus packaging, IPv6 support is currently available in Advanced IP Services, Enterprise Services and above features sets. Due to market trends such as available IPv4 address pool exhaustion and regional registries issuing advisory to the Internet community to adopt IPv6 and national mandates, Cisco IOS packaging for IPv6 is now evolving. Cisco is investing and offers IPv6 support for more and more technologies in order to accelerate and increase deployments based on Cisco IOS Software release. Cisco is taking this a step further by offering packaging parity for IPv6 with IPv4 such that IPv6 feature support for a technology will be packaged in the same feature set as IPv4. For example, IPv6 feature support for BGP will be packaged in IP Services where BGP for IPv4 resides today. This new IOS packaging for IPv6 is starting on Cisco IOS Software Release 12.2(33)SXI, and will get propagated to other IOS release trains in future. PS. You might ask why are you being a shill for Cisco Dave? Well, I slapped them pretty hard publicly about a year ago on this issue, so I felt I owed them an equally public acknowledgment that they got the message and are delivering. See: http://events.internet2.edu/2008/jt- hawaii/sessionDetails.cfm?session=3638&event=278 ======================================================= David Farmer Email: farmer at umn.edu Office of Information Technology Networking & Telecomunication Services University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ======================================================= From artur at eboundhost.com Mon Jan 5 19:54:23 2009 From: artur at eboundhost.com (Artur (eBoundHost)) Date: Tue, 6 Jan 2009 00:54:23 +0000 Subject: [arin-ppml] Why are ISPs allowed? Message-ID: <475932483-1231203125-cardhu_decombobulator_blackberry.rim.net-1064554992-@bxe309.bisx.prod.on.blackberry> Thank you everyone for good explanations I'm glad I asked. Learned a lot of interesting facts. ------Original Message------ From: Ted Mittelstaedt To: artur at eboundhost.com Cc: ARIN-PPML at arin.net Subject: RE: [arin-ppml] Why are ISPs allowed? Sent: Jan 5, 2009 17:40 > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Artur (eBoundHost) > Sent: Friday, January 02, 2009 2:04 PM > To: Stephen Sprunk > Cc: ARIN-PPML at arin.net > Subject: Re: [arin-ppml] Why are ISPs allowed? > > > >at least one host > >(otherwise, why would they buy the >service?) and thus assigning one > >address per customer is automatically >justified. > > I'm strictly talking about home users, not hosting providers. > This ISP has also experimented with using NAT. The biggest problem with it is that if 1 single customer on the NAT gets infected with a virus it takes down the entire lot of them. Your typical run-of-the-mill virus, as soon as it infects a PC it commences to contact tens of thousands of other PC's on the Internet to propagate itself. Worse, most viruses are spam generators also and send out tens of thousands of spams. Because there is no central list of hosts on the Internet the viruses guess, often by iteration, attempting to contact IP's like 1.1.1.1 1.1.1.2 1.1.1.3 1.1.1.4 . . . etc. Since most of these IP's are bogus what happens is the translator opens the outgoing TCP connect, but never sees a TCP acknowledgement from the remote side. This uses up a "translation table entry" in the translator, that is held open until the NAT times it out. (it can't close it any other way since there is never a TCP close that will come from the remote side) While it's doing this, the virus continues to the next victim it is guessing. As a result a single PC can literally tie up several thousand (or even more, if the PC is fast) translation slots in the NAT. This usually chews up all free ram in the translator until the NAT then crashes. Ted Best Regards, Artur eBoundHost http://www.eboundhost.com From mueller at syr.edu Tue Jan 6 11:15:21 2009 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 6 Jan 2009 11:15:21 -0500 Subject: [arin-ppml] 2008-6 Combined Wording Alternative In-Reply-To: References: <1090103113008.1974Q-100000@Ives.egh.com> Message-ID: <75822E125BCB994F8446858C4B19F0D7086BAF02@SUEX07-MBX-04.ad.syr.edu> This wording is acceptable to me. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org Given John's fix below, the 2008-6 wording becomes.... For a period of 3 years from policy implementation, resource holders served by ARIN may designate a recipient for number resources they release to ARIN. Number resources may only be received under RSA in the exact amount which can be justified under ARIN resource-allocation policies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Tue Jan 6 15:11:54 2009 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 6 Jan 2009 15:11:54 -0500 Subject: [arin-ppml] 2008-6 What should the AC do In-Reply-To: <63ac96a50901041407m8c17875nba4cab79209c472e@mail.gmail.com> References: <5D0F8DB0-F3EC-4AB6-A80A-241B06AE116E@delong.com> <63ac96a50901041407m8c17875nba4cab79209c472e@mail.gmail.com> Message-ID: <75822E125BCB994F8446858C4B19F0D7086BAF09@SUEX07-MBX-04.ad.syr.edu> This is my preferred approach as well. as indicated in an earier message, Darte's revision of Herrin's proposed revision is actually acceptable as is. also, inaction is not an option. in this case, not to decide is to decide. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Petach > Sent: Sunday, January 04, 2009 5:07 PM > I'm in favour of option 2; make > the necessary tweaks to the language to clear up any > remaining ambiguity, and then move the proposal forward > From info at arin.net Wed Jan 7 17:20:43 2009 From: info at arin.net (Member Services) Date: Wed, 07 Jan 2009 17:20:43 -0500 Subject: [arin-ppml] ARIN Policy Development Process Message-ID: <49652ABB.9060703@arin.net> On 3 December 2008 the ARIN Board of Trustees adopted the ARIN Policy Development Process (PDP), available at: http://www.arin.net/policy/pdp.html The new PDP is effective today, 7 January 2009. All open proposals have been transitioned to the new PDP. The following two proposals are still in last call. After last call the ARIN Advisory Council (AC) will conduct their last call review: 2007-14: Resource Review Process 2008-6: Emergency Transfer Policy for IPv4 Addresses The following two proposals were presented at the last ARIN Public Policy Meeting and the AC elected to continue to work on them. They are on the AC?s docket: 2008-3: Community Networks IPv6 Allocation 2008-7: Whois Integrity Policy Proposal The following two proposals are in the first stage of the policy development process. They will be reviewed by ARIN staff for clarity and understanding, and a report of that review will be provided to the AC: Policy Proposal: IPv4 Recovery Fund Policy Proposal: Depleted IPv4 reserves All of these proposals can be found at the Proposal Archive at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) From bicknell at ufp.org Thu Jan 8 10:29:35 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 8 Jan 2009 10:29:35 -0500 Subject: [arin-ppml] Google Embraces IPv6 Message-ID: <20090108152935.GA15082@ussenterprise.ufp.org> Google has now provided a public page on their IPv6 efforts: http://www.google.com/intl/en/ipv6/ It's nice to see something from the "Big Content" side of the world. -- 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 farmer at umn.edu Thu Jan 8 10:34:55 2009 From: farmer at umn.edu (David Farmer) Date: Thu, 08 Jan 2009 09:34:55 -0600 Subject: [arin-ppml] Google Embraces IPv6 In-Reply-To: <20090108152935.GA15082@ussenterprise.ufp.org> References: <20090108152935.GA15082@ussenterprise.ufp.org> Message-ID: <4965C8BF.23235.35CFDF0@farmer.umn.edu> Back in November, Google had enabled IPv6 for the IETF meeting network. It worked great!!! Good to see they are making this public. On 8 Jan 2009 Leo Bicknell wrote: > > Google has now provided a public page on their IPv6 efforts: > > http://www.google.com/intl/en/ipv6/ > > It's nice to see something from the "Big Content" side of the world. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > ======================================================= David Farmer Email: farmer at umn.edu Office of Information Technology Networking & Telecomunication Services University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ======================================================= From ocl at gih.com Thu Jan 8 12:06:49 2009 From: ocl at gih.com (Olivier MJ Crepin-Leblond) Date: Thu, 8 Jan 2009 18:06:49 +0100 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org> <20090103013827.GB86274@ussenterprise.ufp.org> Message-ID: <25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK> Leo Bicknell wrote: >Here's the interesting dynamic; there is almost no first-mover >advantage to deploying IPv6 first. You want to deploy it before >your customers want it, so you don't have to turn them away; and >you want your engineers to have experience with it. However, beyond >that it doesn't get you extra revenue, and may make you purchase >equipment you would not otherwise purchase, run newer software with >more bugs, etc. > >We see ISP's state this over and over, the customers do not want >it, so we're not doing it. (forgive me for this rant - I know it's a rant, but I just have to get this off my chest. Leo, this is not aimed at you - I am aiming this at the community as a whole, because I am saddened to read the dynamic which you describe and which I have also noticed. Sadly, "dynamic" is too much of a positive word to use) I have now heard this "no advantage for deploying IPv6" speech so many times from so many people, that I understand why recession has hit us. Those of us who were in Silicon Valley in the 1990s (and I was only there for a short while, but I met with many young industry pioneers), there was a pioneering spirit which brought technical and marketing genius together, along with funding from people who believed in this genius. Everybody was looking forward to the future and some of the most successful companies out there were created around that time. Companies providing a lot of jobs and generating lot of revenue. "Can we do it? YES WE CAN!" was what I used to hear every day. Today instead, most people seem to be looking at the past. IPv4 transfer policies monopolise discussions. Some say IPv6 might *never* be implemented - do you use electricity at home or are you still running with candles? This is the past! I see no imagination, no innovation, no foresight, no vision of the future in any of the points made by v6 nay-sayers. I also see no proof that IPv6 rollout will be as expensive as it is rumoured to be (by them). How else would French ISP free.fr function if it was such an expensive thing to roll-out IPv6? Read through their documentation and you'll find out that they faced only a fraction of the problems advertised by those individuals warning of v6 doom. When did innovation stop living in Silicon Valley? So your 20 year old legacy system will stop working? It's about time you replace it! We don't drive steam cars anymore, so don't complain if they stopped selling coal at the gas station. Best wishes, O. -- Olivier MJ Cr?pin-Leblond, PhD http://www.gih.com/ocl.html From dwhite at olp.net Thu Jan 8 12:49:11 2009 From: dwhite at olp.net (Dan White) Date: Thu, 08 Jan 2009 11:49:11 -0600 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK> References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org> <20090103013827.GB86274@ussenterprise.ufp.org> <25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK> Message-ID: <49663C97.4020006@olp.net> Olivier MJ Crepin-Leblond wrote: > Those of us who were in Silicon Valley in the 1990s (and I was only there > for a short while, but I met with many young industry pioneers), there was a > pioneering spirit which brought technical and marketing genius together, > along with funding from people who believed in this genius. Everybody was > looking forward to the future and some of the most successful companies out > there were created around that time. Companies providing a lot of jobs and > generating lot of revenue. "Can we do it? YES WE CAN!" was what I used to > hear every day. > That was probably because the focus at that time wasn't really on IPv4, but on getting 'on' the internet and providing services. There's nothing really all that sexy about rolling out IPv6, in the eyes of a marketing department or accounts. We really can't approach an IPv6 installation like we did with original turnups. It's hard to phrase the debate in terms of what new customers we'll get or new gadgets we can support. This is more of an infrastructure debate. Perhaps it would be benefitial to engage in a conversation with the think tanks and politicians who are churning towards a massive investment in broadband infrastructure. We should be raising a red flag on what potential effects that will have on the remaining IPv4 address pool. In my opinion, it would be a mistake of the policy makers did not put IPv6 requirements on any funding they provide to networking infrastructure. - Dan From geneb at deltasoft.com Thu Jan 8 12:49:56 2009 From: geneb at deltasoft.com (Gene Buckle) Date: Thu, 8 Jan 2009 09:49:56 -0800 (PST) Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK> References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org> <20090103013827.GB86274@ussenterprise.ufp.org> <25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK> Message-ID: On Thu, 8 Jan 2009, Olivier MJ Crepin-Leblond wrote: > When did innovation stop living in Silicon Valley? So your 20 year old It happened when the accountants took control from the technologists. It happened when "maximizing shareholder value" became the driving force behind "innovation". I learned a long time ago that any technology company that is run by accountants is a failed company that doesn't know it yet. IPv6 uptake will only happen "for real" when the accountants are (metaphorically) pushed off the roof. I've yet to see any hard evidence that getting an MBA doesn't include someone rooting around your frontal lobe with a melon baller as a graduation requirement. :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. From michael.dillon at bt.com Thu Jan 8 13:02:15 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 8 Jan 2009 18:02:15 -0000 Subject: [arin-ppml] Policy Proposal 2008-6: EmergencyTransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK> Message-ID: > How else > would French ISP free.fr function if it was such an expensive > thing to roll-out IPv6? Read through their documentation and > you'll find out that they faced only a fraction of the > problems advertised by those individuals warning of v6 doom. Tr?s interessant. Ou puis-je trouver cette documentation? Peut-?tre ce n'est qu'un probl?me de communication et si on publicise les le?ons lern?s par free.fr, d'autres peuvent aussi se profiter. Je suppose qu'il n y aura pas des objections si j'?crit en fran?ais, car ARIN se concerne aussi avec la region francophone de l'Am?rique. --Michael Dillon From owen at delong.com Thu Jan 8 13:43:59 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Jan 2009 10:43:59 -0800 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <49663C97.4020006@olp.net> References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org> <20090103013827.GB86274@ussenterprise.ufp.org> <25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK> <49663C97.4020006@olp.net> Message-ID: <61E5F205-5744-4128-98A4-C9245EF28E23@delong.com> > > We really can't approach an IPv6 installation like we did with > original > turnups. It's hard to phrase the debate in terms of what new customers > we'll get or new gadgets we can support. This is more of an > infrastructure debate. The infrastructure statement here got me thinking... Perhaps a good infrastructure analogy is earthquake retrofitting of freeway overpasses. In California, it was well known that this was needed for many years before 1989 (the Loma Prietta 7.5 quake) and yet there were always "higher priority" things for the available funding. IPv6 is much the same. We all know that to continue the growth of the internet, IPv6 is necessary, but, there are always better things to do more immediately with available resources. I suspect that IPv4 runout (or slightly later transferable IPv4 runout) will hit the industry much like the Loma Prietta quake hit California. Sure, nobody will die and most existing functionality will still be there, but, companies depending on growing their customer base to survive will be thrust into an environment where bringing IPv6 at least to dual stack support will become significantly more urgent, and, this will drive getting it done much as the Loma Prietta quake drove a massive effort on bridge retrofits. Note, quake: 1989, now it's 2009 (almost 20 years later) and the bridge retrofits still aren't complete, but, there's a lot more done than got done in the 20 years leading up to 1989. Owen From rlc at usfamily.net Thu Jan 8 14:02:46 2009 From: rlc at usfamily.net (Ron Cleven) Date: Thu, 08 Jan 2009 13:02:46 -0600 (CST) Subject: [arin-ppml] Policy Proposal 2008-6: EmergencyTransferPolicyforIPv4 Addresses - Last Call In-Reply-To: References: Message-ID: <49664DD5.9010304@usfamily.net> You are correct, nobody is going to complain if you write in French. michael.dillon at bt.com wrote: >>How else >>would French ISP free.fr function if it was such an expensive >>thing to roll-out IPv6? Read through their documentation and >>you'll find out that they faced only a fraction of the >>problems advertised by those individuals warning of v6 doom. > > > Tr?s interessant. Ou puis-je trouver cette documentation? > Peut-?tre ce n'est qu'un probl?me de communication et si > on publicise les le?ons lern?s par free.fr, d'autres > peuvent aussi se profiter. > > Je suppose qu'il n y aura pas des objections si j'?crit > en fran?ais, car ARIN se concerne aussi avec la region > francophone de l'Am?rique. > > --Michael Dillon > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From ocl at gih.com Thu Jan 8 14:53:37 2009 From: ocl at gih.com (Olivier MJ Crepin-Leblond) Date: Thu, 8 Jan 2009 20:53:37 +0100 Subject: [arin-ppml] Policy Proposal 2008-6:EmergencyTransferPolicyforIPv4 Addresses - Last Call References: Message-ID: Hello Michael: Lessons learnt - not currently available although there's a presentation containing FREE.FR as an example, by CISCO's Mark Townsley available on: http://www.netnod.se/presentations/ipv6ws080423/netnod-ipv6-townsley.pdf It is interesting that around 5% of their subscribers have "opted in" in 6 months. I have no link with free.fr whatsoever, but here are some links (and there is a selection on the right which translated the pages to English, Chinese or Turkish: http://www.free.fr http://www.free.fr/adsl/pages/internet/connexion/adresse-ip-en-protocole-ipv6.html IPv6 is shown as a key success factor, an advantage over the competition: http://www.free.fr/adsl/pages/accueil/plus-de-20-exclusivites.html and here's how a subscriber switches IPv6 on: http://www.free.fr/assistance/707-freebox-adresse-ip-et-reverse-dns-ipv6.html That's what I call pioneering. Free is using 6rd encapsulation (a kind of 6in4 encapsulation). IMHO, other ISPs should learn from this strategy. Those who don't might disappear. O. ----- Original Message ----- From: To: Sent: Thursday, January 08, 2009 7:02 PM Subject: Re: [arin-ppml] Policy Proposal 2008-6:EmergencyTransferPolicyforIPv4 Addresses - Last Call >> How else >> would French ISP free.fr function if it was such an expensive >> thing to roll-out IPv6? Read through their documentation and >> you'll find out that they faced only a fraction of the >> problems advertised by those individuals warning of v6 doom. > > Tr?s interessant. Ou puis-je trouver cette documentation? > Peut-?tre ce n'est qu'un probl?me de communication et si > on publicise les le?ons lern?s par free.fr, d'autres > peuvent aussi se profiter. > > Je suppose qu'il n y aura pas des objections si j'?crit > en fran?ais, car ARIN se concerne aussi avec la region > francophone de l'Am?rique. > > --Michael Dillon > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From info at arin.net Thu Jan 8 16:01:38 2009 From: info at arin.net (Member Services) Date: Thu, 08 Jan 2009 16:01:38 -0500 Subject: [arin-ppml] Board adopts 2008-5: Dedicated IPv4 block to facilitate IPv6 Deployment Message-ID: <496669B2.7030107@arin.net> On 5 January 2009 the ARIN Board of Trustees adopted the following policy proposal: 2008-5: Dedicated IPv4 block to facilitate IPv6 Deployment 2008-5 will be implemented no later than 31 May 2009. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2008_5.html Regards, Member Services Department American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2008-5 Dedicated IPv4 block to facilitate IPv6 deployment 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. 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 Thu Jan 8 16:02:37 2009 From: info at arin.net (Member Services) Date: Thu, 08 Jan 2009 16:02:37 -0500 Subject: [arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised Message-ID: <496669ED.8040903@arin.net> Policy Proposal IPv4 Recovery Fund This proposal is in the first stage of the ARIN Policy Development Process. The proposal originator submitted a revised version of the proposal. ARIN staff will perform the Clarity and Understanding step of the Policy Development Process. Staff does not evaluate the proposal itself at this time, their only aim is to make sure that they understand the proposal and believe that the community will as well. Staff will report the results of this step to the ARIN Advisory Council (AC) within 10 days. The AC will review this proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal. The decision will be announced to 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 Policy Development Process can be found at: http://www.arin.net/policy/pdp.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: IPv4 Recovery Fund Proposal originator: Leo Bicknell Proposal Version: 4.0 Date: 1/8/2009 Proposal type: New Policy term: Permanent Policy statement: (Create new section in section 4, represented by "4.X".) 4.X IPv4 Recovery Fund 4.X.1 Implementation Timing Upon receiving a valid request for a block larger than ARIN can satisfy from its existing free pool, or, by obtaining additional space from IANA, ARIN shall begin offering financial incentives for returned IP blocks according to this policy. 4.X.2 Recovery of IPv4 Space ARIN believes that organizations should voluntarily return unused and/or unneeded IP resources to the community. However, upon implementation of this policy, ARIN will offer financial incentives for the return of IPv4 resources to ARIN relinquishment of any future claims to those resources. ARIN will continue to accept voluntary returns. 4.X.3 Allocation of Recovered Space Once approved for IPv4 space ARIN will ask the requester to specify a bid of how much they are willing to pay for reclamation of address space. ARIN will use this bid in determining what incentives to offer for return of space. The requester may make a higher bid at any time, which is treated as a brand new bid replacing their old bid. If ARIN recovers space and offers it to requester at or below the specified bid within 60 days of the time the bid was made then the bid shall be binding on requester at the price ARIN offers the space. 4.X.4 Address Block Management ARIN may not offer a partial fill, that is provide a block smaller than the one for which the requester was approved. ARIN may split recovered blocks into multiple smaller blocks at the staff's discretion using the following principals: - It is unlikely a request will be made for the address block size involved in the next 60 days. - The block is divided into as few parts as practical. - There are enough bids to allow the entire block to be allocated. 4.X.5 Transparency ARIN staff shall make public the current and historical prices of asks, bids, and executed transactions in a manor that facilitates the bidding process. ARIN staff must regularly report on the amount of address space obtained and distributed via this mechanism, number of blocks subdivided, as well as aggregate financial numbers. 4.X.6 Cost Recovery ARIN shall manage the address space recovery program with a goal of cost recovery. ARIN may: - Use ARIN funds to reclaim blocks when there is no specific demand; if such reclamation is deemed in the best interest of the community and there is a significant likelyhood of future demand. - Use a portion of the funds collected under this program to pay for the implementation of this program. Rationale: Many have recognized that in order for unused or poorly used IPv4 resources to be returned to the free pool that financial compensation will be required. This is particularly the case in poorly used assets where the current holder may have to expend time and money to renumber in order to free the blocks. This proposal sets up a fund administered by ARIN to encourage the return of space. Effectively ARIN will offer financial incentives to return unused or poorly used IPv4 resources and place them back into the IPv4 free pool. The intention is for this activity to be revenue neutral to ARIN. To achieve that goal those requesting IPv4 resources will be requested to bid on a one-time payment to the recovery fund to cover the cost of the resources they have received. The proposal is intentionally vague on the exact implementation details to staff because: - Transactions with those returning space and obtaining space may occur in any order. - The bidding process may need to evolve over time, and may not be as simple as highest bidder wins. It may include aspects such as a dutch auction style format (all winners pay the lowest winning price), or may include other factors such as which size blocks ARIN has free in an effort to limit deaggregation. - ARIN will have to develop contracts and procedures around this activity that are better suited for staff and legal than the policy process. Compared to other "transfer proposals", this proposal has the following benefits: - Maintains that IP addresses are not property. - Maintains the concept that unused addresses should be returned to the free pool. - Maintains need based addressing. - Removes the need for those with excess resources to find those without resources. There is no need for any sort of listing service, eBay, etc. - All transactions are two party transactions with ARIN as one of the parties. The potential for multi-party legal disputes is reduced. - ARIN can absorb spikes in supply or demand, creating more level prices over time. - ARIN can provide transparency across all transactions in this system. - Reduces confusion to new entrants over where they should go to receive address space. Change Log: - Changed "monetary" to "financial" to allow for the possibility of ARIN offering things other than direct payment (like fee credits). Credit: Robert Bonomi. - Updated numbering so there were not two 4.10.2's. Also changed to using a place holder for section. Credit: Robert Bonomi - Changed the cost recovery language to be more clear and provide some additional flexibility. - Clarified 4.10.2 about future claims. Credit: Ted Mittelstaedt - Split 10.X.3 into 10.X.3 and 10.X.3 with better titles. - Left the exact algorithm to staff. Removed examples as a result. Timetable for implementation: Staff should begin developing procedures and updated templates immediately. Policy would not go into effect until the criteria listed occurs. From vixie at isc.org Thu Jan 8 18:39:19 2009 From: vixie at isc.org (Paul Vixie) Date: Thu, 08 Jan 2009 23:39:19 +0000 Subject: [arin-ppml] Google Embraces IPv6 In-Reply-To: <4965C8BF.23235.35CFDF0@farmer.umn.edu> (David Farmer's message of "Thu\, 08 Jan 2009 09\:34\:55 -0600") References: <20090108152935.GA15082@ussenterprise.ufp.org> <4965C8BF.23235.35CFDF0@farmer.umn.edu> Message-ID: i'll be happier when they have some IPv6-reachable name servers, so that i won't need IPv4 transport to receive these AAAA answers. but i agree it's progress. re: farmer at umn.edu ("David Farmer") writes: > Back in November, Google had enabled IPv6 for the IETF meeting network. > It worked great!!! Good to see they are making this public. > > On 8 Jan 2009 Leo Bicknell wrote: > >> >> Google has now provided a public page on their IPv6 efforts: >> >> http://www.google.com/intl/en/ipv6/ >> >> It's nice to see something from the "Big Content" side of the world. -- Paul Vixie From mueller at syr.edu Fri Jan 9 14:10:59 2009 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 9 Jan 2009 14:10:59 -0500 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <49663C97.4020006@olp.net> References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org> <20090103013827.GB86274@ussenterprise.ufp.org> <25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK> <49663C97.4020006@olp.net> Message-ID: <75822E125BCB994F8446858C4B19F0D7086BAF17@SUEX07-MBX-04.ad.syr.edu> > Perhaps it would be benefitial to engage in a conversation with the > think tanks and politicians who are churning towards a massive > investment in broadband infrastructure. We should be raising > a red flag > on what potential effects that will have on the remaining IPv4 address > pool. In my opinion, it would be a mistake of the policy > makers did not > put IPv6 requirements on any funding they provide to networking > infrastructure. I love it. ISPs, this is your chance: ask for a v6 bailout! ;-) Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org From kbanks at giantcomm.net Fri Jan 9 14:21:27 2009 From: kbanks at giantcomm.net (Kyle Banks) Date: Fri, 9 Jan 2009 13:21:27 -0600 Subject: [arin-ppml] Policy Proposal 2008-6:Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <75822E125BCB994F8446858C4B19F0D7086BAF17@SUEX07-MBX-04.ad.syr.edu> References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org><20090103013827.GB86274@ussenterprise.ufp.org><25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK> <49663C97.4020006@olp.net> <75822E125BCB994F8446858C4B19F0D7086BAF17@SUEX07-MBX-04.ad.syr.edu> Message-ID: <001601c9728f$78b2e6d0$3501a8c0@macc173.net> >I love it. ISPs, this is your chance: ask for a v6 bailout! ;-) We would, But it wouldn't be beneficial for the Smaller providers, just the larger ones... Kyle V. Banks Service/Technical Representative Giant Communications 785-362-9331 EXT. 108 kbanks at giantcomm.net -- Blessed is he who expects nothing, for he shall never be disappointed--Benjamin Franklin -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller Sent: Friday, January 09, 2009 1:11 PM To: 'Dan White' Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 2008-6:Emergency TransferPolicyforIPv4 Addresses - Last Call > Perhaps it would be benefitial to engage in a conversation with the > think tanks and politicians who are churning towards a massive > investment in broadband infrastructure. We should be raising > a red flag > on what potential effects that will have on the remaining IPv4 address > pool. In my opinion, it would be a mistake of the policy > makers did not > put IPv6 requirements on any funding they provide to networking > infrastructure. I love it. ISPs, this is your chance: ask for a v6 bailout! ;-) 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 info at arin.net if you experience any issues. From kkargel at polartel.com Fri Jan 9 14:25:28 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 9 Jan 2009 13:25:28 -0600 Subject: [arin-ppml] Policy Proposal2008-6:Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <001601c9728f$78b2e6d0$3501a8c0@macc173.net> References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org><20090103013827.GB86274@ussenterprise.ufp.org><25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK><49663C97.4020006@olp.net><75822E125BCB994F8446858C4B19F0D7086BAF17@SUEX07-MBX-04.ad.syr.edu> <001601c9728f$78b2e6d0$3501a8c0@macc173.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD1B@mail> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Kyle Banks > Sent: Friday, January 09, 2009 1:21 PM > To: 'Milton L Mueller'; 'Dan White' > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal2008-6:Emergency > TransferPolicyforIPv4 Addresses - Last Call > > >I love it. ISPs, this is your chance: ask for a v6 bailout! ;-) > > We would, But it wouldn't be beneficial for the Smaller providers, just > the > larger ones... > > > Kyle V. Banks > Service/Technical Representative > Giant Communications > 785-362-9331 EXT. 108 > kbanks at giantcomm.net > Actually, I thought I remembered there being some technology money built in to our President elect's campaign promises for IPV6 and rural connectivity.. I am speaking prematurely because I don't have a reference ready at hand. I shall have to dig back and see if I can find what I am thinking about.. > > > -- Blessed is he who expects nothing, for he shall never be > disappointed--Benjamin Franklin > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Milton L Mueller > Sent: Friday, January 09, 2009 1:11 PM > To: 'Dan White' > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 2008-6:Emergency > TransferPolicyforIPv4 Addresses - Last Call > > > Perhaps it would be benefitial to engage in a conversation with the > > think tanks and politicians who are churning towards a massive > > investment in broadband infrastructure. We should be raising > > a red flag > > on what potential effects that will have on the remaining IPv4 address > > pool. In my opinion, it would be a mistake of the policy > > makers did not > > put IPv6 requirements on any funding they provide to networking > > infrastructure. > > > I love it. ISPs, this is your chance: ask for a v6 bailout! ;-) > > 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 info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From kbanks at giantcomm.net Fri Jan 9 14:36:24 2009 From: kbanks at giantcomm.net (Kyle Banks) Date: Fri, 9 Jan 2009 13:36:24 -0600 Subject: [arin-ppml] Policy Proposal2008-6:Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD1B@mail> References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org><20090103013827.GB86274@ussenterprise.ufp.org><25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK><49663C97.4020006@olp.net><75822E125BCB994F8446858C4B19F0D7086BAF17@SUEX07-MBX-04.ad.syr.edu> <001601c9728f$78b2e6d0$3501a8c0@macc173.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD1B@mail> Message-ID: <002601c97291$8f6b0630$3501a8c0@macc173.net> >Actually, I thought I remembered there being some technology money built in >to our President elect's campaign promises for IPV6 and rural >connectivity.. >I am speaking prematurely because I don't have a reference ready at hand. >I >shall have to dig back and see if I can find what I am thinking about.. I don't think you were speaking prematurely, but your comment puzzled me, so I had to do a little research... I didn't recall this campaign promise, but now that I think about it, I think I may have heard some people in the office talking about it... This may be beneficial to us after all, Working in middle-of-nowhere Kansas... Thanks for the insight "Connect Rural America: Barack Obama and Joe Biden will ensure that rural Americans have access to a modern communications infrastructure. They will modernize an FCC program that supports rural phone service so that it promotes affordable broadband coverage across rural America as well." REF: http://skypejournal.com/2008/09/rural-internet-access-is-obama-priority.html Kyle V. Banks Service/Technical Representative Giant Communications 785-362-9331 EXT. 108 kbanks at giantcomm.net -- Blessed is he who expects nothing, for he shall never be disappointed--Benjamin Franklin -----Original Message----- From: Kevin Kargel [mailto:kkargel at polartel.com] Sent: Friday, January 09, 2009 1:25 PM To: Kyle Banks; Milton L Mueller; Dan White Cc: arin-ppml at arin.net Subject: RE: [arin-ppml] Policy Proposal2008-6:Emergency TransferPolicyforIPv4 Addresses - Last Call > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Kyle Banks > Sent: Friday, January 09, 2009 1:21 PM > To: 'Milton L Mueller'; 'Dan White' > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal2008-6:Emergency > TransferPolicyforIPv4 Addresses - Last Call > > >I love it. ISPs, this is your chance: ask for a v6 bailout! ;-) > > We would, But it wouldn't be beneficial for the Smaller providers, just > the > larger ones... > > > Kyle V. Banks > Service/Technical Representative > Giant Communications > 785-362-9331 EXT. 108 > kbanks at giantcomm.net > Actually, I thought I remembered there being some technology money built in to our President elect's campaign promises for IPV6 and rural connectivity.. I am speaking prematurely because I don't have a reference ready at hand. I shall have to dig back and see if I can find what I am thinking about.. > > > -- Blessed is he who expects nothing, for he shall never be > disappointed--Benjamin Franklin > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Milton L Mueller > Sent: Friday, January 09, 2009 1:11 PM > To: 'Dan White' > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 2008-6:Emergency > TransferPolicyforIPv4 Addresses - Last Call > > > Perhaps it would be benefitial to engage in a conversation with the > > think tanks and politicians who are churning towards a massive > > investment in broadband infrastructure. We should be raising > > a red flag > > on what potential effects that will have on the remaining IPv4 address > > pool. In my opinion, it would be a mistake of the policy > > makers did not > > put IPv6 requirements on any funding they provide to networking > > infrastructure. > > > I love it. ISPs, this is your chance: ask for a v6 bailout! ;-) > > 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 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 kkargel at polartel.com Fri Jan 9 14:39:10 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 9 Jan 2009 13:39:10 -0600 Subject: [arin-ppml] Policy Proposal2008-6:Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <002601c97291$8f6b0630$3501a8c0@macc173.net> References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org><20090103013827.GB86274@ussenterprise.ufp.org><25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK><49663C97.4020006@olp.net><75822E125BCB994F8446858C4B19F0D7086BAF17@SUEX07-MBX-04.ad.syr.edu> <001601c9728f$78b2e6d0$3501a8c0@macc173.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD1B@mail> <002601c97291$8f6b0630$3501a8c0@macc173.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD1D@mail> > -----Original Message----- > From: Kyle Banks [mailto:kbanks at giantcomm.net] > Sent: Friday, January 09, 2009 1:36 PM > To: Kevin Kargel; 'Milton L Mueller'; 'Dan White' > Cc: arin-ppml at arin.net > Subject: RE: [arin-ppml] Policy Proposal2008-6:Emergency > TransferPolicyforIPv4 Addresses - Last Call > > > >Actually, I thought I remembered there being some technology money built > in > >to our President elect's campaign promises for IPV6 and rural > >connectivity.. > >I am speaking prematurely because I don't have a reference ready at hand. > >I > >shall have to dig back and see if I can find what I am thinking about.. > > I don't think you were speaking prematurely, but your comment puzzled me, > so > I had to do a little research... I didn't recall this campaign promise, > but > now that I think about it, I think I may have heard some people in the > office talking about it... This may be beneficial to us after all, Working > in middle-of-nowhere Kansas... Thanks for the insight > > > "Connect Rural America: Barack Obama and Joe Biden will ensure that rural > Americans have access to a modern communications infrastructure. They will > modernize an FCC program that supports rural phone service so that it > promotes affordable broadband coverage across rural America as well." > > One reference I found quickly from the "official" page that directly relates to smaller network carriers getting better access to tech monies.. Snippet from: http://my.barackobama.com/page/content/ruralplan/ * Reform the Telephone Universal Service Program: Obama will direct the Federal Communications Commission to propose reforms changing the Universal Service Fund program from one that supports voice communications to one that supports affordable broadband. End of Snippet I still don't quite understand where he thinks all this economic incentive money is coming from, but I guess it's not up to me anyway.. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From rlc at usfamily.net Fri Jan 9 14:45:13 2009 From: rlc at usfamily.net (Ron Cleven) Date: Fri, 09 Jan 2009 13:45:13 -0600 (CST) Subject: [arin-ppml] Policy Proposal2008-6:Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <002601c97291$8f6b0630$3501a8c0@macc173.net> References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org><20090103013827.GB86274@ussenterprise.ufp.org><25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK><49663C97.4020006@olp.net><75822E125BCB994F8446858C4B19F0D7086BAF17@SUEX07-MBX-04.ad.syr.edu> <001601c9728f$78b2e6d0$3501a8c0@macc173.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD1B@mail> <002601c97291$8f6b0630$3501a8c0@macc173.net> Message-ID: <4967A949.1030700@usfamily.net> The actual implementation plan is a little tricky. The first phase involves moving everyone in the country to North and South Dakota (roughly an area about the size of Japan, but much flatter). This will allow us to very efficiently run fiber to everyone. Kyle Banks wrote: >>Actually, I thought I remembered there being some technology money built in >>to our President elect's campaign promises for IPV6 and rural >>connectivity.. >>I am speaking prematurely because I don't have a reference ready at hand. >>I >>shall have to dig back and see if I can find what I am thinking about.. > > > I don't think you were speaking prematurely, but your comment puzzled me, so > I had to do a little research... I didn't recall this campaign promise, but > now that I think about it, I think I may have heard some people in the > office talking about it... This may be beneficial to us after all, Working > in middle-of-nowhere Kansas... Thanks for the insight > > > "Connect Rural America: Barack Obama and Joe Biden will ensure that rural > Americans have access to a modern communications infrastructure. They will > modernize an FCC program that supports rural phone service so that it > promotes affordable broadband coverage across rural America as well." > > > REF: > http://skypejournal.com/2008/09/rural-internet-access-is-obama-priority.html > > > Kyle V. Banks > Service/Technical Representative > Giant Communications > 785-362-9331 EXT. 108 > kbanks at giantcomm.net > > > > -- Blessed is he who expects nothing, for he shall never be > disappointed--Benjamin Franklin > > > -----Original Message----- > From: Kevin Kargel [mailto:kkargel at polartel.com] > Sent: Friday, January 09, 2009 1:25 PM > To: Kyle Banks; Milton L Mueller; Dan White > Cc: arin-ppml at arin.net > Subject: RE: [arin-ppml] Policy Proposal2008-6:Emergency > TransferPolicyforIPv4 Addresses - Last Call > > > >>-----Original Message----- >>From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >>Behalf Of Kyle Banks >>Sent: Friday, January 09, 2009 1:21 PM >>To: 'Milton L Mueller'; 'Dan White' >>Cc: arin-ppml at arin.net >>Subject: Re: [arin-ppml] Policy Proposal2008-6:Emergency >>TransferPolicyforIPv4 Addresses - Last Call >> >> >>>I love it. ISPs, this is your chance: ask for a v6 bailout! ;-) >> >>We would, But it wouldn't be beneficial for the Smaller providers, just >>the >>larger ones... >> >> >>Kyle V. Banks >>Service/Technical Representative >>Giant Communications >>785-362-9331 EXT. 108 >>kbanks at giantcomm.net >> > > Actually, I thought I remembered there being some technology money built in > to our President elect's campaign promises for IPV6 and rural connectivity.. > I am speaking prematurely because I don't have a reference ready at hand. I > shall have to dig back and see if I can find what I am thinking about.. > > >> >>-- Blessed is he who expects nothing, for he shall never be >>disappointed--Benjamin Franklin >> >> >>-----Original Message----- >>From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >>Behalf Of Milton L Mueller >>Sent: Friday, January 09, 2009 1:11 PM >>To: 'Dan White' >>Cc: arin-ppml at arin.net >>Subject: Re: [arin-ppml] Policy Proposal 2008-6:Emergency >>TransferPolicyforIPv4 Addresses - Last Call >> >> >>>Perhaps it would be benefitial to engage in a conversation with the >>>think tanks and politicians who are churning towards a massive >>>investment in broadband infrastructure. We should be raising >>>a red flag >>>on what potential effects that will have on the remaining IPv4 address >>>pool. In my opinion, it would be a mistake of the policy >>>makers did not >>>put IPv6 requirements on any funding they provide to networking >>>infrastructure. >> >> >>I love it. ISPs, this is your chance: ask for a v6 bailout! ;-) >> >>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 info at arin.net if you experience any issues. >> >>_______________________________________________ >>PPML >>You are receiving this message because you are subscribed to >>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>Unsubscribe or manage your mailing list subscription at: >>http://lists.arin.net/mailman/listinfo/arin-ppml >>Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From kbanks at giantcomm.net Fri Jan 9 14:50:08 2009 From: kbanks at giantcomm.net (Kyle Banks) Date: Fri, 9 Jan 2009 13:50:08 -0600 Subject: [arin-ppml] PolicyProposal2008-6:Emergency TransferPolicyforIPv4 Addresses - Last Call In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD1D@mail> References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org><20090103013827.GB86274@ussenterprise.ufp.org><25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK><49663C97.4020006@olp.net><75822E125BCB994F8446858C4B19F0D7086BAF17@SUEX07-MBX-04.ad.syr.edu><001601c9728f$78b2e6d0$3501a8c0@macc173.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4AD1B@mail><002601c97291$8f6b0630$3501a8c0@macc173.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD1D@mail> Message-ID: <004001c97293$7a6e0780$3501a8c0@macc173.net> >One reference I found quickly from the "official" page that directly >relates >to smaller network carriers getting better access to tech monies.. >Snippet from: http://my.barackobama.com/page/content/ruralplan/ > * Reform the Telephone Universal Service Program: Obama will direct the >Federal Communications Commission to propose reforms changing the Universal >Service Fund program from one that supports voice communications to one >that >supports affordable broadband. >End of Snippet >I still don't quite understand where he thinks all this economic incentive >money is coming from, but I guess it's not up to me anyway.. Actually, most of that fund should be coming from the FUSC, Which I think stands for the Federal Universal Service Fund (which I know isn't right, seeing as that would make it FUSF, But its something along those lines) The FUSC Is around to "Help Out" us Little guys in the country, by balancing the costs to provide service. As in NY or California you may have 1000 people in several blocks, whereas here in KS we may have around 1000 people in an entire county. I believe that fund gains value by a charge paid by the people on their monthly phone bill, but I may be mistaken Kyle V. Banks Service/Technical Representative Giant Communications 785-362-9331 EXT. 108 kbanks at giantcomm.net -- Blessed is he who expects nothing, for he shall never be disappointed--Benjamin Franklin -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel Sent: Friday, January 09, 2009 1:39 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] PolicyProposal2008-6:Emergency TransferPolicyforIPv4 Addresses - Last Call > -----Original Message----- > From: Kyle Banks [mailto:kbanks at giantcomm.net] > Sent: Friday, January 09, 2009 1:36 PM > To: Kevin Kargel; 'Milton L Mueller'; 'Dan White' > Cc: arin-ppml at arin.net > Subject: RE: [arin-ppml] Policy Proposal2008-6:Emergency > TransferPolicyforIPv4 Addresses - Last Call > > > >Actually, I thought I remembered there being some technology money built > in > >to our President elect's campaign promises for IPV6 and rural > >connectivity.. > >I am speaking prematurely because I don't have a reference ready at hand. > >I > >shall have to dig back and see if I can find what I am thinking about.. > > I don't think you were speaking prematurely, but your comment puzzled me, > so > I had to do a little research... I didn't recall this campaign promise, > but > now that I think about it, I think I may have heard some people in the > office talking about it... This may be beneficial to us after all, Working > in middle-of-nowhere Kansas... Thanks for the insight > > > "Connect Rural America: Barack Obama and Joe Biden will ensure that rural > Americans have access to a modern communications infrastructure. They will > modernize an FCC program that supports rural phone service so that it > promotes affordable broadband coverage across rural America as well." > > One reference I found quickly from the "official" page that directly relates to smaller network carriers getting better access to tech monies.. Snippet from: http://my.barackobama.com/page/content/ruralplan/ * Reform the Telephone Universal Service Program: Obama will direct the Federal Communications Commission to propose reforms changing the Universal Service Fund program from one that supports voice communications to one that supports affordable broadband. End of Snippet I still don't quite understand where he thinks all this economic incentive money is coming from, but I guess it's not up to me anyway.. From kbanks at giantcomm.net Fri Jan 9 14:52:07 2009 From: kbanks at giantcomm.net (Kyle Banks) Date: Fri, 9 Jan 2009 13:52:07 -0600 Subject: [arin-ppml] PolicyProposal2008-6:Emergency TransferPolicyforIPv4Addresses - Last Call In-Reply-To: <004001c97293$7a6e0780$3501a8c0@macc173.net> References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org><20090103013827.GB86274@ussenterprise.ufp.org><25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK><49663C97.4020006@olp.net><75822E125BCB994F8446858C4B19F0D7086BAF17@SUEX07-MBX-04.ad.syr.edu><001601c9728f$78b2e6d0$3501a8c0@macc173.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4AD1B@mail><002601c97291$8f6b0630$3501a8c0@macc173.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4AD1D@mail> <004001c97293$7a6e0780$3501a8c0@macc173.net> Message-ID: <004101c97293$c0dda540$3501a8c0@macc173.net> To Correct my Error, it isn't FUSC it is in fact FUSF, The Federal Universal Service Fund Kyle V. Banks Service/Technical Representative Giant Communications 785-362-9331 EXT. 108 kbanks at giantcomm.net -- Blessed is he who expects nothing, for he shall never be disappointed--Benjamin Franklin -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kyle Banks Sent: Friday, January 09, 2009 1:50 PM To: 'Kevin Kargel'; arin-ppml at arin.net Subject: Re: [arin-ppml] PolicyProposal2008-6:Emergency TransferPolicyforIPv4Addresses - Last Call >One reference I found quickly from the "official" page that directly >relates >to smaller network carriers getting better access to tech monies.. >Snippet from: http://my.barackobama.com/page/content/ruralplan/ > * Reform the Telephone Universal Service Program: Obama will direct the >Federal Communications Commission to propose reforms changing the Universal >Service Fund program from one that supports voice communications to one >that >supports affordable broadband. >End of Snippet >I still don't quite understand where he thinks all this economic incentive >money is coming from, but I guess it's not up to me anyway.. Actually, most of that fund should be coming from the FUSC, Which I think stands for the Federal Universal Service Fund (which I know isn't right, seeing as that would make it FUSF, But its something along those lines) The FUSC Is around to "Help Out" us Little guys in the country, by balancing the costs to provide service. As in NY or California you may have 1000 people in several blocks, whereas here in KS we may have around 1000 people in an entire county. I believe that fund gains value by a charge paid by the people on their monthly phone bill, but I may be mistaken Kyle V. Banks Service/Technical Representative Giant Communications 785-362-9331 EXT. 108 kbanks at giantcomm.net -- Blessed is he who expects nothing, for he shall never be disappointed--Benjamin Franklin -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel Sent: Friday, January 09, 2009 1:39 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] PolicyProposal2008-6:Emergency TransferPolicyforIPv4 Addresses - Last Call > -----Original Message----- > From: Kyle Banks [mailto:kbanks at giantcomm.net] > Sent: Friday, January 09, 2009 1:36 PM > To: Kevin Kargel; 'Milton L Mueller'; 'Dan White' > Cc: arin-ppml at arin.net > Subject: RE: [arin-ppml] Policy Proposal2008-6:Emergency > TransferPolicyforIPv4 Addresses - Last Call > > > >Actually, I thought I remembered there being some technology money built > in > >to our President elect's campaign promises for IPV6 and rural > >connectivity.. > >I am speaking prematurely because I don't have a reference ready at hand. > >I > >shall have to dig back and see if I can find what I am thinking about.. > > I don't think you were speaking prematurely, but your comment puzzled me, > so > I had to do a little research... I didn't recall this campaign promise, > but > now that I think about it, I think I may have heard some people in the > office talking about it... This may be beneficial to us after all, Working > in middle-of-nowhere Kansas... Thanks for the insight > > > "Connect Rural America: Barack Obama and Joe Biden will ensure that rural > Americans have access to a modern communications infrastructure. They will > modernize an FCC program that supports rural phone service so that it > promotes affordable broadband coverage across rural America as well." > > One reference I found quickly from the "official" page that directly relates to smaller network carriers getting better access to tech monies.. Snippet from: http://my.barackobama.com/page/content/ruralplan/ * Reform the Telephone Universal Service Program: Obama will direct the Federal Communications Commission to propose reforms changing the Universal Service Fund program from one that supports voice communications to one that supports affordable broadband. End of Snippet I still don't quite understand where he thinks all this economic incentive money is coming from, but I guess it's not up to me anyway.. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From kkargel at polartel.com Fri Jan 9 14:53:54 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 9 Jan 2009 13:53:54 -0600 Subject: [arin-ppml] Policy Proposal2008-6:Emergency TransferPolicyforIPv4Addresses - Last Call In-Reply-To: <4967A949.1030700@usfamily.net> References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org><20090103013827.GB86274@ussenterprise.ufp.org><25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK><49663C97.4020006@olp.net><75822E125BCB994F8446858C4B19F0D7086BAF17@SUEX07-MBX-04.ad.syr.edu> <001601c9728f$78b2e6d0$3501a8c0@macc173.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD1B@mail><002601c97291$8f6b0630$3501a8c0@macc173.net> <4967A949.1030700@usfamily.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD1E@mail> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ron Cleven > Sent: Friday, January 09, 2009 1:45 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml]Policy Proposal2008-6:Emergency > TransferPolicyforIPv4Addresses - Last Call > > The actual implementation plan is a little tricky. The first phase > involves moving everyone in the country to North and South Dakota > (roughly an area about the size of Japan, but much flatter). This will > allow us to very efficiently run fiber to everyone. > > Don't do that.. we work way to hard to keep people from moving here as it is. Hmm.. I guess it is time to start recirculating the stories of all the bicyclists that froze to death up here, the deaths from boredom, et.al.. Actually the Dakotas are a great place to live, just don't expect someone else to entertain you up here. And actually companies in ND *are* working on running fiber to everyone.. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From kkargel at polartel.com Fri Jan 9 14:58:12 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 9 Jan 2009 13:58:12 -0600 Subject: [arin-ppml] PolicyProposal2008-6:Emergency TransferPolicyforIPv4Addresses - Last Call In-Reply-To: <004101c97293$c0dda540$3501a8c0@macc173.net> References: <20081230222048.GA16505@ussenterprise.ufp.org><75822E125BCB994F8446858C4B19F0D7086BAEF9@SUEX07-MBX-04.ad.syr.edu><20090101204504.GA25609@ussenterprise.ufp.org><20090103013827.GB86274@ussenterprise.ufp.org><25D86B2103D349B9A83A764D54A10E4E@GIH.CO.UK><49663C97.4020006@olp.net><75822E125BCB994F8446858C4B19F0D7086BAF17@SUEX07-MBX-04.ad.syr.edu><001601c9728f$78b2e6d0$3501a8c0@macc173.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4AD1B@mail><002601c97291$8f6b0630$3501a8c0@macc173.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4AD1D@mail> <004001c97293$7a6e0780$3501a8c0@macc173.net> <004101c97293$c0dda540$3501a8c0@macc173.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD20@mail> > -----Original Message----- > From: Kyle Banks [mailto:kbanks at giantcomm.net] > Sent: Friday, January 09, 2009 1:52 PM > To: 'Kyle Banks'; Kevin Kargel; arin-ppml at arin.net > Subject: RE: [arin-ppml] PolicyProposal2008-6:Emergency > TransferPolicyforIPv4Addresses - Last Call > > To Correct my Error, it isn't FUSC it is in fact FUSF, The Federal > Universal > Service Fund > Don't forget the tie-ins with NECA, who administers the FCC's "access charge" plan .. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From fw at deneb.enyo.de Sun Jan 11 16:01:17 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 11 Jan 2009 22:01:17 +0100 Subject: [arin-ppml] Google Embraces IPv6 In-Reply-To: <20090108152935.GA15082@ussenterprise.ufp.org> (Leo Bicknell's message of "Thu, 8 Jan 2009 10:29:35 -0500") References: <20090108152935.GA15082@ussenterprise.ufp.org> Message-ID: <87prito8v6.fsf@mid.deneb.enyo.de> * Leo Bicknell: > Google has now provided a public page on their IPv6 efforts: > > http://www.google.com/intl/en/ipv6/ > > It's nice to see something from the "Big Content" side of the world. Even if they are aiming for Tier 1 status? From michael.dillon at bt.com Mon Jan 12 04:36:25 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 12 Jan 2009 09:36:25 -0000 Subject: [arin-ppml] Google Embraces IPv6 In-Reply-To: <87prito8v6.fsf@mid.deneb.enyo.de> Message-ID: > > Google has now provided a public page on their IPv6 efforts: > > > > http://www.google.com/intl/en/ipv6/ > > > > It's nice to see something from the "Big Content" side of the world. > > Even if they are aiming for Tier 1 status? Tier 1 status is a historical anomaly. Back in the mid-90's, the early Internet backbone providers were able to maintain a dominant position in the peering ecology because they got there first, and therefore they tended to have both the content, and the eyeballs, that other providers needed to access. Nowadays, it is a very different landscape, with the Internet extended throughout the world. The world's largest ISP is China Telecom, but their users are a tiny fraction of the 40 million unique vistors per month to the major Internet portal rambler.ru. The reason is that a quarter billion Chinese speaking users rarely have an interest in a Russian language portal. What does that have to do with Google, an American content provider? Not much, but then Google is not an American content provider any more. They are an international company with data centers in places like Ireland, Brazil, Germany, Japan, Italy and China. You simply cannot use a simple metric like Tier 1, 2 or 3 in a meaningful way any more. The Internet is evolving. Some networks like Cogent or China Telecom, primarily function in one language/culture. Others like Google cut across multiple linguistic/cultural boundaries and are redefining what is the core of the Internet. --Michael Dillon From info at arin.net Mon Jan 12 09:15:00 2009 From: info at arin.net (Member Services) Date: Mon, 12 Jan 2009 09:15:00 -0500 Subject: [arin-ppml] Policy Development Process - Submit policy proposals at any time Message-ID: <496B5064.8050002@arin.net> In the past ARIN staff posted reminders of the deadline for submitting policy proposals. The new Policy Development Process (PDP), published last week, does not contain such a deadline. The current PDP is designed to bring forth clear, technically sound and useful policy. Since good ideas can happen at any time, policy proposals may be submitted at any time. Despite there being no deadline, the new PDP does have several time requirements: ? Policy originators need time to think about and write policy proposals, ? ARIN staff needs time to conduct the Clarity and Understanding review, ? The AC needs time to make a decision and create draft policy, ? ARIN staff and legal counsel must be given time to perform staff assessments, ? And, draft policies must be posted to PPML at least 35 days prior to an ARIN meeting to be considered for that meeting?s agenda. If you are considering submitting a policy proposal, the sooner you submit it the better the chances are of it being acted upon in the first half of 2009. The Policy Development Process and Policy Proposal Template are available at: http://www.arin.net/policy/pdp.html Policy proposals and draft policies under discussion are available at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Jan 13 14:15:53 2009 From: info at arin.net (Member Services) Date: Tue, 13 Jan 2009 14:15:53 -0500 Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks to Regional Internet Registries Message-ID: <496CE869.7010902@arin.net> ARIN received the following global policy proposal. In accordance with the ARIN Policy Development Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML). This proposal is in the first stage of the ARIN Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal itself at this time, their only aim is to make sure that they understand the proposal and believe that the community will as well. Staff will report the results of this step to the ARIN Advisory Council (AC) within 10 days. The AC will review this proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal. The decision will be announced to 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 Policy Development Process can be found at: http://www.arin.net/policy/pdp.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: Allocation of IPv4 Blocks to Regional Internet Registries Proposal Originator: This proposal was developed by a team consisting of persons from each of the 5 RIRs. Adiel A. Akplogan" AfriNIC Raul Echeberria LACNIC MAEMURA Akinori APNIC Axel Pawlik RIPE NCC Ray Plzak ARIN Oscar A. Robles-Garay" LACNIC Nigel Titley RIPE NCC Paul Wilson APNIC Proposal Version: 1.0 Date: 13 January 2009 Proposal type: New Policy term: Permanent Policy statement: This document describes the policy governing the allocation of IPv4 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements should be specified by appropriate agreements among the RIRs and ICANN. This policy is to be implemented in two phases. A. Phase I: Recovery of IPv4 Address Space Upon ratification of this policy by the ICANN Board of Directors the IANA shall establish a mechanism to receive IPv4 address space which is returned to it by the RIRs, and hold that address space in a 'recovered IPv4 pool'. Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration. Each RIR shall at quarterly intervals return any such recovered address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. During Phase I, no allocations will be made from the recovered IPv4 pool. B. Phase II: Allocation of Recovered IPv4 address space by the IANA Upon ratification of this policy by the ICANN Board of Directors and a declaration by the IANA that its existing free pool of unallocated IPv4 addresses space is depleted; Global Addressing Policy ASO-001-2 (adopted by ICANN Board 8 April 2005) is rescinded. IANA will then commence to allocate the IPv4 address space from the recovered IPv4 pool. 1. Allocation of IPv4 Address Space a. For the purposes of this policy, an 'IPv4 allocation period' is defined as a 6-month period following 1 March or 1 September in each year. b. At the beginning of each IPv4 allocation period, the IANA will determine the 'IPv4 allocation unit' for that period, as 1/10 of its IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary. c. In each allocation period, each RIR may issue one IPv4 request to the IANA. Providing that the RIR satisfies the allocation criteria described in paragraph B.2, the IANA will allocate a single allocation unit, composed of the smallest possible number of blocks available in its IPv4 address pool. 2. IPv4 Address Space Allocation Criteria A RIR is eligible to receive additional IPv4 address space from the IANA when the total of its IPv4 address holdings is less than 50% of the current IPv4 allocation unit, and providing that it has not already received an IPv4 allocation from the IANA during the current IPv4 allocation period. 3. Initial Allocation of IPv4 Address Space Each new RIR shall, at the moment of recognition, be allocated one (1) allocation unit by the IANA. If an allocation unit is not available, then the IANA will issue this block as soon as one is available. This allocation will be made regardless of the newly formed RIR's projected utilization figures and shall be independent of the IPv4 address space that may have been transferred to the new RIR by the already existing RIRs as part of the formal transition process. 4. Reporting a. All returned space is to be recorded in an IANA-published log of IPv4 address space transactions, with each log entry detailing the returned address block, the date of the return, and the returning RIR. b. All allocated space is also to be recorded in this IANA-published log of IPv4 address space transactions, with each log entry detailing the address blocks, the date of the allocation and the recipient RIR. c. The IANA will maintain a public registry of the current disposition of all IPv4 address space, detailing all reservations and current allocations and current IANA-held address space that is unallocated. d) The IANA may make public announcements of IPv4 address block transactions that occur under this policy. The IANA will make appropriate modifications to the "Internet Protocol V4 Address Space" page of the IANA website and may make announcements to its own appropriate announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated. Rationale: With the depletion of the IANA free pool of IPv4 address space, the current policy regarding the allocation of IPv4 address space to the RIRs will become moot. The RIRs may, according to their individual policies and procedures, recover IPv4 address space. This policy provides a mechanism for the RIRs to retro allocate the recovered IPv4 address space to the IANA and provides the IANA the policy by which it can allocate it back to the RIRs on a needs basis. This policy creates a new global pool of IPv4 address space that can be allocated where it is needed on a global basis without a transfer of address space between the RIRs. Timetable for implementation: This policy is to be implemented immediately upon ratification by the ICANN Board of Directors according to the global policy process described in the ASO MoU. From scottleibrand at gmail.com Tue Jan 13 14:27:12 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 13 Jan 2009 11:27:12 -0800 Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks to Regional Internet Registries In-Reply-To: <496CE869.7010902@arin.net> References: <496CE869.7010902@arin.net> Message-ID: <496CEB10.9000901@gmail.com> One thing I'm not completely clear on: is the return of returned space to IANA intended to be mandatory? From my reading it appears to be ("Each RIR shall at quarterly intervals return...") I'm not sure of my own position on that yet, but I think it's important to discuss the ramifications of returning all returned space to IANA, redistributing it amongst all RIRs, and only then re-allocating it to LIRs and end users. (Without such a policy, I assume that the process of re-allocation would be much faster, with each RIR acting independently.) It would also be worthwhile to consider whether any transfer policies or incentivized return policies would be affected by this. (For example, if ARIN pays someone to renumber and return space, would that space have to be returned to IANA?) A very interesting and important proposal. I look forward to discussing it. -Scott Member Services wrote: > ARIN received the following global policy proposal. In accordance with > the ARIN Policy Development Process, the proposal is being posted to the > ARIN Public Policy Mailing List (PPML). > > This proposal is in the first stage of the ARIN Policy Development > Process. ARIN staff will perform the Clarity and Understanding step. > Staff does not evaluate the proposal itself at this time, their only aim > is to make sure that they understand the proposal and believe that the > community will as well. Staff will report the results of this step to > the ARIN Advisory Council (AC) within 10 days. > > The AC will review this proposal at their next regularly scheduled > meeting (if the period before the next regularly scheduled meeting is > less than 10 days, then the period may be extended to the subsequent > regularly scheduled meeting). The AC will decide how to utilize the > proposal. The decision will be announced to 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 Policy Development Process can be found at: > http://www.arin.net/policy/pdp.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: Allocation of IPv4 Blocks to Regional Internet > Registries > > Proposal Originator: > > This proposal was developed by a team consisting of persons from each of > the 5 RIRs. > > Adiel A. Akplogan" AfriNIC > > Raul Echeberria LACNIC > > MAEMURA Akinori APNIC > > Axel Pawlik RIPE NCC > > Ray Plzak ARIN > > Oscar A. Robles-Garay" LACNIC > > Nigel Titley RIPE NCC > > Paul Wilson APNIC > > Proposal Version: 1.0 > > Date: 13 January 2009 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > This document describes the policy governing the allocation of IPv4 > address space from the IANA to the Regional Internet Registries (RIRs). > This document does not stipulate performance requirements in the > provision of services by IANA to an RIR in accordance with this policy. > Such requirements should be specified by appropriate agreements among > the RIRs and ICANN. > > This policy is to be implemented in two phases. > > A. Phase I: Recovery of IPv4 Address Space > > Upon ratification of this policy by the ICANN Board of Directors the > IANA shall establish a mechanism to receive IPv4 address space which is > returned to it by the RIRs, and hold that address space in a 'recovered > IPv4 pool'. > > Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration. Each RIR > shall at quarterly intervals return any such recovered address space to > the IANA in aggregated blocks of /24 or larger, for inclusion in the > recovered IPv4 pool. > > During Phase I, no allocations will be made from the recovered IPv4 pool. > > B. Phase II: Allocation of Recovered IPv4 address space by the IANA > > Upon ratification of this policy by the ICANN Board of Directors and a > declaration by the IANA that its existing free pool of unallocated IPv4 > addresses space is depleted; Global Addressing Policy ASO-001-2 (adopted > by ICANN Board 8 April 2005) is rescinded. IANA will then commence to > allocate the IPv4 address space from the recovered IPv4 pool. > > 1. Allocation of IPv4 Address Space > > a. For the purposes of this policy, an 'IPv4 allocation period' is > defined as a 6-month period following 1 March or 1 September in each year. > > b. At the beginning of each IPv4 allocation period, the IANA will > determine the 'IPv4 allocation unit' for that period, as 1/10 of its > IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary. > > c. In each allocation period, each RIR may issue one IPv4 request to the > IANA. Providing that the RIR satisfies the allocation criteria > described in paragraph B.2, the IANA will allocate a single allocation > unit, composed of the smallest possible number of blocks available in > its IPv4 address pool. > > 2. IPv4 Address Space Allocation Criteria > > A RIR is eligible to receive additional IPv4 address space from the IANA > when the total of its IPv4 address holdings is less than 50% of the > current IPv4 allocation unit, and providing that it has not already > received an IPv4 allocation from the IANA during the current IPv4 > allocation period. > > 3. Initial Allocation of IPv4 Address Space > > Each new RIR shall, at the moment of recognition, be allocated one (1) > allocation unit by the IANA. If an allocation unit is not available, > then the IANA will issue this block as soon as one is available. This > allocation will be made regardless of the newly formed RIR's projected > utilization figures and shall be independent of the IPv4 address space > that may have been transferred to the new RIR by the already existing > RIRs as part of the formal transition process. > > 4. Reporting > > a. All returned space is to be recorded in an IANA-published log of IPv4 > address space transactions, with each log entry detailing the returned > address block, the date of the return, and the returning RIR. > > b. All allocated space is also to be recorded in this IANA-published log > of IPv4 address space transactions, with each log entry detailing the > address blocks, the date of the allocation and the recipient RIR. > > c. The IANA will maintain a public registry of the current disposition > of all IPv4 address space, detailing all reservations and current > allocations and current IANA-held address space that is unallocated. > > d) The IANA may make public announcements of IPv4 address block transactions > that occur under this policy. The IANA will make appropriate > modifications to the "Internet Protocol V4 Address Space" page of the > IANA website and may make announcements to its own appropriate > announcement lists. The IANA announcements will be limited to which > address ranges, the time of allocation and to which Registry they have > been allocated. > > Rationale: > > With the depletion of the IANA free pool of IPv4 address space, the > current policy regarding the allocation of IPv4 address space to the > RIRs will become moot. The RIRs may, according to their individual > policies and procedures, recover IPv4 address space. This policy > provides a mechanism for the RIRs to retro allocate the recovered IPv4 > address space to the IANA and provides the IANA the policy by which it > can allocate it back to the RIRs on a needs basis. This policy creates a > new global pool of IPv4 address space that can be allocated where it is > needed on a global basis without a transfer of address space between the > RIRs. > > > Timetable for implementation: > > This policy is to be implemented immediately upon ratification by the > ICANN Board of Directors according to the global policy process > described in the ASO MoU. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From Fred.Wettling at Bechtel.com Thu Jan 15 09:47:14 2009 From: Fred.Wettling at Bechtel.com (Wettling, Fred) Date: Thu, 15 Jan 2009 09:47:14 -0500 Subject: [arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised In-Reply-To: <496669ED.8040903@arin.net> References: <496669ED.8040903@arin.net> Message-ID: Bechtel Internal / Non-Record// I'm generally opposed to this ARIN Policy Proposal. Here's why... RIR policies should be structured, in part, to influence the desired long-term behavior of the supported community within the charter and jurisdiction of the RIR. The desired behavior that is being addresses is returning unused IPv4 blocks to the ARIN pool for reallocation. The IPv4 Recovery Fund Policy Proposal is attempting to establish a market-based mechanism that will, in effect, pay organizations to return IPv4 addresses to ARIN. This approach will add additional administrative burden to ARIN and not result in the desired behavior. Rationale: Organizations sitting on large blocks of unused IPv4 addresses will be incented to HOLD ON to the addresses until the IPv4 address scarcity increases and the market price if IPv4 addresses correspondingly skyrocket. This would be a one-time benefit to the "selling" organization. An alternative would be a very substantial increase on the annual fee for IPv4 address holders in the large and X-Large categories (greater than /16). Consider a 5X, 10X, or larger increase to these groups, raising the Large annual IPv4 fee to $45-90K and the X-Large fee to $90K-180K. Rationale: Organizations will be incented to released unused IPv4 blocks to avoid large RECURRING costs. No additional administrative burden to ARIN. Regards - Fred Bechtel Internal / Non-Record// -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6040 bytes Desc: not available URL: From kkargel at polartel.com Thu Jan 15 12:44:46 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 15 Jan 2009 11:44:46 -0600 Subject: [arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised In-Reply-To: References: <496669ED.8040903@arin.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD4A@mail> I am vigorously opposed to ANY incentive based on artificial fees for the sole purpose of controlling behavior. This is nothing more than a punitive fine for good behavior. If you have enough money in your budget to incentivize yourself this way go ahead, you can send it to me and I will happily relieve you of the burden of excess wealth, but please do not try to destroy my business to solve the problem. Work with carrots, quit hitting me with sticks.. if you hit folks with sticks enough they will start hitting back. There is nothing making ARIN an authority other than cooperation. If you de-incent people enough they will stop cooperating and any authority will evaporate. There is nothing stopping any large (or even small) group of ISP's from forming ARIN2 and setting up their own authority and routing. It will screw the internet for a while but if the folks are screwed because they can't afford IP's anyway then they won't care. If you leave folks without a choice they may find a choice you don't like. To illustrate this, if I have a working IP of 66.231.1.1 and my peer ISP had a working IP of 66.231.2.1 and that's all we had, and we needed a class c block to route between us, we *could* pick any class C block we didn't need to talk to and set each other as the next hop address for that block and it would route just fine regardless of what was in the public routing tables. Then if another ISP saw what we were doing and wanted to join in they could put in their own static routes and also talk to the class C block and maybe abscond with a block of their own. The only downside is that none of the organizations involved would be able to talk to the legitimate class C blocks without some serious router tricks. In fact nobody would even notice unless the legitimate block tried to communicate with the consortium. I realize this is not a perfect example, but it would work and it could grow fractally. It would be a very bad thing to do, I am advocating against anything like this, but it is possible if cooperation breaks down. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Wettling, Fred > Sent: Thursday, January 15, 2009 8:47 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised > > Bechtel Internal / Non-Record// > > > I'm generally opposed to this ARIN Policy Proposal. Here's why... > > RIR policies should be structured, in part, to influence the desired > long-term behavior of the supported community within the charter and > jurisdiction of the RIR. The desired behavior that is being addresses is > returning unused IPv4 blocks to the ARIN pool for reallocation. > > The IPv4 Recovery Fund Policy Proposal is attempting to establish a > market-based mechanism that will, in effect, pay organizations to return > IPv4 addresses to ARIN. This approach will add additional administrative > burden to ARIN and not result in the desired behavior. > > Rationale: > Organizations sitting on large blocks of unused IPv4 addresses will be > incented to HOLD ON to the addresses until the IPv4 address scarcity > increases and the market price if IPv4 addresses correspondingly > skyrocket. > This would be a one-time benefit to the "selling" organization. > > An alternative would be a very substantial increase on the annual fee for > IPv4 address holders in the large and X-Large categories (greater than > /16). > Consider a 5X, 10X, or larger increase to these groups, raising the Large > annual IPv4 fee to $45-90K and the X-Large fee to $90K-180K. > > Rationale: > Organizations will be incented to released unused IPv4 blocks to avoid > large > RECURRING costs. No additional administrative burden to ARIN. > > Regards - Fred > > Bechtel Internal / Non-Record// -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From mueller at syr.edu Thu Jan 15 16:46:09 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 15 Jan 2009 16:46:09 -0500 Subject: [arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised In-Reply-To: References: <496669ED.8040903@arin.net> Message-ID: <75822E125BCB994F8446858C4B19F0D7086D7E79@SUEX07-MBX-04.ad.syr.edu> This won't work. Most of the low-hanging fruit would be legacy holdings not under any RSA, and thus not subject to any annual fees. Plus, you can't raise fees on people who don't need addresses without also raising them on people who do need them. --MM > -----Original Message----- > > An alternative would be a very substantial increase on the annual fee for > IPv4 address holders in the large and X-Large categories (greater than > /16). Consider a 5X, 10X, or larger increase to these groups, raising the > Large annual IPv4 fee to $45-90K and the X-Large fee to $90K-180K. > > Rationale: > Organizations will be incented to released unused IPv4 blocks to avoid > large > RECURRING costs. No additional administrative burden to ARIN. > > Regards - Fred > > Bechtel Internal / Non-Record// From raul at lacnic.net Mon Jan 19 09:38:19 2009 From: raul at lacnic.net (Raul Echeberria) Date: Mon, 19 Jan 2009 12:38:19 -0200 Subject: [arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised In-Reply-To: <75822E125BCB994F8446858C4B19F0D7086D7E79@SUEX07-MBX-04.ad.syr.edu> References: <496669ED.8040903@arin.net> <75822E125BCB994F8446858C4B19F0D7086D7E79@SUEX07-MBX-04.ad.syr.edu> Message-ID: <571277B9-7399-488D-9391-569A69CF05FB@lacnic.net> Milton: This is not "THE POLICY" for dealing with IPv4 depletion and the transition to IPv6. No policy will be "THE POLICY" for that. It is just one of the needed policies (at least for the authors). It is clear that there will be (and already are) other proposals for dealing with other aspects of this issue, like legacy space for example. Ra?l El 15/01/2009, a las 07:46 p.m., Milton L Mueller escribi?: > This won't work. Most of the low-hanging fruit would be legacy > holdings not under any RSA, and thus not subject to any annual fees. > Plus, you can't raise fees on people who don't need addresses > without also raising them on people who do need them. > > --MM > >> -----Original Message----- >> >> An alternative would be a very substantial increase on the annual >> fee for >> IPv4 address holders in the large and X-Large categories (greater >> than >> /16). Consider a 5X, 10X, or larger increase to these groups, >> raising the >> Large annual IPv4 fee to $45-90K and the X-Large fee to $90K-180K. >> >> Rationale: >> Organizations will be incented to released unused IPv4 blocks to >> avoid >> large >> RECURRING costs. No additional administrative burden to ARIN. >> >> Regards - Fred >> >> Bechtel Internal / Non-Record// > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 artur at eboundhost.com Mon Jan 19 12:53:11 2009 From: artur at eboundhost.com (Artur (eBoundHost)) Date: Mon, 19 Jan 2009 17:53:11 +0000 Subject: [arin-ppml] ARIN-PPML Digest, Vol 43, Issue 34 Message-ID: <798936389-1232387585-cardhu_decombobulator_blackberry.rim.net-621283002-@bxe032.bisx.prod.on.blackberry> I'm against any fee changes. Don't we already have rules that the ip space needs to be well used? How about some enforcement? Best Regards, Artur eBoundHost http://www.eboundhost.com From stephen at sprunk.org Mon Jan 19 23:05:25 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 19 Jan 2009 22:05:25 -0600 Subject: [arin-ppml] ARIN-PPML Digest, Vol 43, Issue 34 In-Reply-To: <798936389-1232387585-cardhu_decombobulator_blackberry.rim.net-621283002-@bxe032.bisx.prod.on.blackberry> References: <798936389-1232387585-cardhu_decombobulator_blackberry.rim.net-621283002-@bxe032.bisx.prod.on.blackberry> Message-ID: <49754D85.60104@sprunk.org> Artur (eBoundHost) wrote: > I'm against any fee changes. Don't we already have rules that the ip space needs to be well used? Close. For new number resources to be allocated/assigned to an organization, it must show that existing allocations/assignments are properly utilized and new resources are justified. That's not quite the same thing. > How about some enforcement? That is one purpose of 2007-14, which recently completed Last Call and should be adopted by the ARIN BoT fairly soon. Then, ARIN staff will have the power to enforce utilization requirements on existing non-legacy resources. However, a significant part (many would say most) of the suspected abuse is in legacy space, and 2007-14 exempts that. I will be submitting a proposal to remove that exemption once 2007-14 is adopted, and we will see whether or not there is consensus on that point; in the past, there has been significant resistance to the idea. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From Fred.Wettling at Bechtel.com Tue Jan 20 09:55:04 2009 From: Fred.Wettling at Bechtel.com (Wettling, Fred) Date: Tue, 20 Jan 2009 09:55:04 -0500 Subject: [arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised In-Reply-To: <496669ED.8040903@arin.net> References: <496669ED.8040903@arin.net> Message-ID: Additional comments about the Policy Proposal: IPv4 Recovery Fund - Revised ***You cannot sell something you do not own. The policy proposal strikes at a fundamental premise of IANA, RIRs, NIRs, and LIRs. that of IP address ownership. Organizations that receive IP address allocations from a recognized registry do not own the addresses. They are simply granted use of the addresses under the conditions of the service agreement with their registry. The current ARIN Service Agreement (Version 9.2) makes this perfectly clear. Section 9. NO PROPERTY RIGHTS Applicant acknowledges and agrees that the number resources are not property (real, personal, or intellectual) and that Applicant shall not acquire any property rights in or to any number resources by virtue of this Agreement or otherwise. Applicant further agrees that it will not attempt, directly or indirectly, to obtain or assert any trademark, service mark, copyright, or any other form of property rights in any number resources in the United States or any other country. ***ARIN's Role ARIN should not get in the role of broker for the sale of Internet addresses. In addition to a direct conflict with Section 9 of the current Service Agreement, this sets a very bad precedent. What would stop eBay or anyone else from getting into the "IPv4 Fire Sale" business (for a fee, of course)? ***Delaying release of IPv4 blocks Simple economics at work here. IPv4 resources will become more scarce over time. Organizations with any financial acumen would not "sell" any available IPv4 blocks for years... until the price is driven very high. Regards - Fred Wettling Fred Wettling Bechtel Corporation Fred.Wettling at Bechtel.com -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services Sent: Thursday, January 08, 2009 4:03 PM To: arin-ppml at arin.net Subject: [arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6040 bytes Desc: not available URL: From bicknell at ufp.org Tue Jan 20 10:14:55 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 20 Jan 2009 10:14:55 -0500 Subject: [arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised In-Reply-To: References: <496669ED.8040903@arin.net> Message-ID: <20090120151455.GA36472@ussenterprise.ufp.org> In a message written on Tue, Jan 20, 2009 at 09:55:04AM -0500, Wettling, Fred wrote: > The policy proposal strikes at a fundamental premise of IANA, RIRs, NIRs, > and LIRs. that of IP address ownership. Organizations that receive IP > address allocations from a recognized registry do not own the addresses. > They are simply granted use of the addresses under the conditions of the > service agreement with their registry. The current ARIN Service Agreement > (Version 9.2) makes this perfectly clear. I'm curious about your comment, because it is the opposite of what I intended with the policy and thus i wonder if the wording is not clear. Under this proposal a resource holder can't sell (or transfer) addresses to anyone. The only thing you can do is the same thing you can do today, return them to ARIN. Yes, ARIN may offer you some compensation, which can either be thought of as payment for your trouble to return them, or can be thought of payment to terminate the contract, but ARIN does not buy the addresses. Offering compensation in these forms does not make the addresses property, indeed its done between two parties who already have a contract in place denying all property rights. ARIN would pay for this activity by new fees on resource recipients, although rather than a yearly fee it would be a one time fee at the time of issue. -- 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 Fred.Wettling at Bechtel.com Tue Jan 20 10:56:03 2009 From: Fred.Wettling at Bechtel.com (Wettling, Fred) Date: Tue, 20 Jan 2009 10:56:03 -0500 Subject: [arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised In-Reply-To: <20090120151455.GA36472@ussenterprise.ufp.org> References: <496669ED.8040903@arin.net> <20090120151455.GA36472@ussenterprise.ufp.org> Message-ID: Revised In a message written on Tue, Jan 20, 2009 at 09:55:04AM -0500, Wettling, Fred wrote: The policy proposal strikes at a fundamental premise of IANA, RIRs, NIRs, and LIRs. that of IP address ownership. Organizations that receive IP address allocations from a recognized registry do not own the addresses. They are simply granted use of the addresses under the conditions of the service agreement with their registry. The current ARIN Service Agreement (Version 9.2) makes this perfectly clear. On Tuesday, January 20, 2009 10:15 AM, Leo Bicknell replied I'm curious about your comment, because it is the opposite of what I intended with the policy and thus i wonder if the wording is not clear. Under this proposal a resource holder can't sell (or transfer) addresses to anyone. The only thing you can do is the same thing you can do today, return them to ARIN. Yes, ARIN may offer you some compensation, which can either be thought of as payment for your trouble to return them, or can be thought of payment to terminate the contract, but ARIN does not buy the addresses. Offering compensation in these forms does not make the addresses property, indeed its done between two parties who already have a contract in place denying all property rights. ARIN would pay for this activity by new fees on resource recipients, although rather than a yearly fee it would be a one time fee at the time of issue. ~~~~~~~~~~~~~~~~~~~~ Leo - The policy proposal 4.X.2 (Recovery of IPv4 Space) states ...However, upon implementation of this policy, ARIN will offer financial incentives for the return of IPv4 resources to ARIN relinquishment of any future claims to those resources.... The policy proposal 4.X.5 (Transparency) states... ARIN staff shall make public the current and historical prices of asks, bids, and executed transactions in a manor that facilitates the bidding process. ARIN staff must regularly report on the amount of address space obtained and distributed via this mechanism, number of blocks subdivided, as well as aggregate financial numbers. My comments are within the context of the verb "sell" as defined by Merriam-Webster and other dictionaries. (1) to give up (property) to another for something of value (as money), (2) exchange or deliver for money or its equivalent, (3) give up for a price or reward. ""Financial incentives", "bids", and "asks" appear to me to be terms related to sales. I believe the common interpretation of the policy, if/when compensation is offered to the resource holder, will be that of a sale. CFOs, Controllers, or others responsible for the financial well-being of their organization, will book the money received from ARIN as revenue on their income statements. I agree that lack of vision and very poor foresight by ISPs and end-users will cause some level of discomfort as the world shifts to IPv6. However, I believe that additional "life support" for IPv4 is simply extending the inevitable. Regards - Fred From mueller at syr.edu Tue Jan 20 14:11:48 2009 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 20 Jan 2009 14:11:48 -0500 Subject: [arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised In-Reply-To: References: <496669ED.8040903@arin.net> Message-ID: <75822E125BCB994F8446858C4B19F0D70F45F053@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > The policy proposal strikes at a fundamental premise of IANA, RIRs, NIRs, > and LIRs. that of IP address ownership. Organizations that receive IP > address allocations from a recognized registry do not own the addresses. > They are simply granted use of the addresses under the conditions of the > service agreement with their registry. Another good example of how many members of this community get stuck in ideological ruts. That was a policy put into place in the mid-1990s to serve a specific purpose, namely route aggregation. The "leasing" model (as opposed to "ownership") was not handed down by God on stone tablets but was seen as the only feasible way at the time to prevent fragmentation of the address space. A new proposed policy should thus be evaluated on the basis of the extent to which it leads to such fragmentation or not. Whatever one's opinion of Leo's proposed policy, there is nothing about ARIN buying back addresses that produces the route deaggregation problems that led to the leading model in the first place. And yet, Fred's comments puts the ideology first and forgets about its orginal function. And as for your argument that you can't sell what you don't own, remember we are in a leasing model now, and its perfectly possible, legally ethically and contractually, for a lessor to buy back a leased item from a lessee. > What would stop eBay > or anyone else from getting into the "IPv4 Fire Sale" business > (for a fee, of course)? The fact that ARIN has a monopoly on the registry and wouldn't allow the address to be registered unless it consented to such a role for third parties: that's what. We should be so lucky as to have an organized process that permitted third parties to get involved. Indeed, I respectfully suggest that you ought to be more concerned about the long term implications of ARIN's monopoly power than about deviations from the ownership religion. > IPv4 resources will become more scarce > over time. Organizations with any financial acumen would not "sell" any > available IPv4 blocks for years... until the price is driven very high. Obviously false. V4 addresses MIGHT become more valuable, or they might not. Organizations who held them too long might easily find them worthless From bicknell at ufp.org Tue Jan 20 14:30:30 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 20 Jan 2009 14:30:30 -0500 Subject: [arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised In-Reply-To: References: <20090120151455.GA36472@ussenterprise.ufp.org> Message-ID: <20090120193030.GA46835@ussenterprise.ufp.org> In a message written on Tue, Jan 20, 2009 at 10:56:03AM -0500, Wettling, Fred wrote: > I believe the common interpretation of the policy, if/when compensation > is offered to the resource holder, will be that of a sale. CFOs, > Controllers, or others responsible for the financial well-being of their > organization, will book the money received from ARIN as revenue on their > income statements. This a key point of my proposal, and a major area where it differs from the other transfer proposals. In the other transfer proposals what will be allowed is for two independant parties to write a contract, and then ARIN will recognize that a transfer has taken place. It is entirely possible that the parities will codify the transaction like this: "Fred offers 192.168.0.0/16 to Leo for the sum of $1,000." That looks a lot like a sale. In my proposal there is something quite different going on, first, there is already a contract with ARIN: "Fred agrees that Fred has the use of the number resource 192.168.0.0/16 under the terms laid out in the ARIN RSA." Note that this contract in theory exists forever. [Note, I'm sure legal professionals will pit the nit about a contract that lasts forever compared to one that auto-renews, I'm trying to stay out of those weeds.] That is, as long as Fred pays the yearly renewal and abides by the terms of the RSA (e.g. follows ARIN policies) ARIN will allow Fred to keep using the number resource. What this policy allows is for ARIN to come along and say: "ARIN agrees to pay Fred $1,000 to terminate the existing contract for services right now." It's similar to someone leasing a commercial building for 20 years, but then 10 years in the landlord tells them "I will pay you $50,000 to move out now and let me out of the last 10 years of the contract." Such an agreement in no way means the leaseholder now has ownership of the building. ARIN is /not/ paying for the number. ARIN is paying for your trouble to deconfigure it from your routers, similar to how the landlord might offer to pay your moving expenses to move out early. Neither of those payments change your ownership position. To me it is a very small, but very key difference. I worry a lot about proposals like 2008-2 and 2008-6 and what effect they may have on the "IPs as property" argument. This proposal has been crafted to avoid that problem completely by making the payment have nothing to do with the numbers, and everything to do with the trouble of ending the contract early. -- 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 farmer at umn.edu Wed Jan 21 13:04:47 2009 From: farmer at umn.edu (David Farmer) Date: Wed, 21 Jan 2009 12:04:47 -0600 Subject: [arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised In-Reply-To: <20090120193030.GA46835@ussenterprise.ufp.org> References: <20090120151455.GA36472@ussenterprise.ufp.org>, , <20090120193030.GA46835@ussenterprise.ufp.org> Message-ID: <49770F5F.12448.387A62A@farmer.umn.edu> Leo, Staff, or Counsel, Since, payments are made to ARIN in this proposal, beyond the usual fees, does this create an additional tax liability for ARIN? Does the size of the payments matter? Even for a not-for-profit, not all kinds of income/revenue are tax free. Conversely, even if it doesn't create a tax burden, since ARIN makes payments to other entities in this proposal, does this create a reporting burden on ARIN? Again, does the size of the payments matter to the answer? Would this kind of activity, create any problems for ARIN's tax exempt status? What kind of accounting burden would these transactions create for ARIN? I really don't know the answers, I'm not even claiming to, but I think these are important questions to know the answers to, before I could support this direction. In the end, these are really matters for the Board, but I would hate to go all the way down this policy road and find out in the end it is completely unworkable for some kind of tax or accounting reason. Even if you can't provide an immediate answer, when would it be reasonable to get an answer? Also, even if you can't provide authoritative answers, an initial impression could be helpful too. Like, are these probably big problems, probably not problems, or something in between? Leo, I think this is a creative solution to some of the problems of the other transfer proposals, and I'm really attracted to the logic behind it. But, I'm a little worried that it might create more problems than it actually solves, and that those problems might be more intractable than the problems other proposals have. ======================================================= David Farmer Email: farmer at umn.edu Office of Information Technology Networking & Telecomunication Services University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ======================================================= From spiffnolee at yahoo.com Wed Jan 21 16:36:23 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Wed, 21 Jan 2009 13:36:23 -0800 (PST) Subject: [arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised References: <20090120151455.GA36472@ussenterprise.ufp.org>, , <20090120193030.GA46835@ussenterprise.ufp.org> <49770F5F.12448.387A62A@farmer.umn.edu> Message-ID: <117845.90511.qm@web63303.mail.re1.yahoo.com> Counsel will provide a detailed analysis at some point. I understand why you might be concerned about these kinds of transactions affecting ARIN's tax-exempt status as a not-for-profit organization. My reading of http://www.irs.gov/charities/nonprofits/article/0,,id=169366,00.html suggests that as long as ARIN's primary purpose is to promote the common business interest of our community, financial transactions (including sales) are acceptable. So, based on that preliminary reading of the unofficial IRS guidelines, don't let concern for ARIN's tax status be the sole reason not to support this proposal. If a better reading comes with official review, you're free to change your mind. Lee ----- Original Message ---- > From: David Farmer > To: arin-ppml at arin.net; Leo Bicknell > Sent: Wednesday, January 21, 2009 1:04:47 PM > Subject: Re: [arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised > > Leo, Staff, or Counsel, > > Since, payments are made to ARIN in this proposal, beyond the usual fees, > does this create an additional tax liability for ARIN? Does the size of the > payments matter? Even for a not-for-profit, not all kinds of income/revenue > are tax free. > > Conversely, even if it doesn't create a tax burden, since ARIN makes > payments to other entities in this proposal, does this create a reporting > burden on ARIN? Again, does the size of the payments matter to the > answer? > > Would this kind of activity, create any problems for ARIN's tax exempt > status? > > What kind of accounting burden would these transactions create for ARIN? > > I really don't know the answers, I'm not even claiming to, but I think these > are important questions to know the answers to, before I could support this > direction. In the end, these are really matters for the Board, but I would hate > > to go all the way down this policy road and find out in the end it is completely > > unworkable for some kind of tax or accounting reason. > > Even if you can't provide an immediate answer, when would it be reasonable > to get an answer? Also, even if you can't provide authoritative answers, an > initial impression could be helpful too. Like, are these probably big > problems, probably not problems, or something in between? > > Leo, I think this is a creative solution to some of the problems of the other > transfer proposals, and I'm really attracted to the logic behind it. But, I'm a > > little worried that it might create more problems than it actually solves, and > that those problems might be more intractable than the problems other > proposals have. > > > ======================================================= > David Farmer Email: farmer at umn.edu > Office of Information Technology > Networking & Telecomunication Services > University of Minnesota Phone: 612-626-0815 > 2218 University Ave SE Cell: 612-812-9952 > Minneapolis, MN 55414-3029 FAX: 612-626-1818 > ======================================================= > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From info at arin.net Fri Jan 23 11:15:25 2009 From: info at arin.net (Member Services) Date: Fri, 23 Jan 2009 11:15:25 -0500 Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks to Regional Internet Registries In-Reply-To: <496CE869.7010902@arin.net> References: <496CE869.7010902@arin.net> Message-ID: <4979ED1D.9050403@arin.net> The shepherds from the ARIN Advisory Council for this proposal are Scott Leibrand and Marla Azinger. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > ARIN received the following global policy proposal. In accordance with > the ARIN Policy Development Process, the proposal is being posted to the > ARIN Public Policy Mailing List (PPML). > > This proposal is in the first stage of the ARIN Policy Development > Process. ARIN staff will perform the Clarity and Understanding step. > Staff does not evaluate the proposal itself at this time, their only aim > is to make sure that they understand the proposal and believe that the > community will as well. Staff will report the results of this step to > the ARIN Advisory Council (AC) within 10 days. > > The AC will review this proposal at their next regularly scheduled > meeting (if the period before the next regularly scheduled meeting is > less than 10 days, then the period may be extended to the subsequent > regularly scheduled meeting). The AC will decide how to utilize the > proposal. The decision will be announced to 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 Policy Development Process can be found at: > http://www.arin.net/policy/pdp.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: Allocation of IPv4 Blocks to Regional Internet > Registries > > Proposal Originator: > > This proposal was developed by a team consisting of persons from each of > the 5 RIRs. > > Adiel A. Akplogan" AfriNIC > > Raul Echeberria LACNIC > > MAEMURA Akinori APNIC > > Axel Pawlik RIPE NCC > > Ray Plzak ARIN > > Oscar A. Robles-Garay" LACNIC > > Nigel Titley RIPE NCC > > Paul Wilson APNIC > > Proposal Version: 1.0 > > Date: 13 January 2009 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > This document describes the policy governing the allocation of IPv4 > address space from the IANA to the Regional Internet Registries (RIRs). > This document does not stipulate performance requirements in the > provision of services by IANA to an RIR in accordance with this policy. > Such requirements should be specified by appropriate agreements among > the RIRs and ICANN. > > This policy is to be implemented in two phases. > > A. Phase I: Recovery of IPv4 Address Space > > Upon ratification of this policy by the ICANN Board of Directors the > IANA shall establish a mechanism to receive IPv4 address space which is > returned to it by the RIRs, and hold that address space in a 'recovered > IPv4 pool'. > > Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration. Each RIR > shall at quarterly intervals return any such recovered address space to > the IANA in aggregated blocks of /24 or larger, for inclusion in the > recovered IPv4 pool. > > During Phase I, no allocations will be made from the recovered IPv4 pool. > > B. Phase II: Allocation of Recovered IPv4 address space by the IANA > > Upon ratification of this policy by the ICANN Board of Directors and a > declaration by the IANA that its existing free pool of unallocated IPv4 > addresses space is depleted; Global Addressing Policy ASO-001-2 (adopted > by ICANN Board 8 April 2005) is rescinded. IANA will then commence to > allocate the IPv4 address space from the recovered IPv4 pool. > > 1. Allocation of IPv4 Address Space > > a. For the purposes of this policy, an 'IPv4 allocation period' is > defined as a 6-month period following 1 March or 1 September in each year. > > b. At the beginning of each IPv4 allocation period, the IANA will > determine the 'IPv4 allocation unit' for that period, as 1/10 of its > IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary. > > c. In each allocation period, each RIR may issue one IPv4 request to the > IANA. Providing that the RIR satisfies the allocation criteria > described in paragraph B.2, the IANA will allocate a single allocation > unit, composed of the smallest possible number of blocks available in > its IPv4 address pool. > > 2. IPv4 Address Space Allocation Criteria > > A RIR is eligible to receive additional IPv4 address space from the IANA > when the total of its IPv4 address holdings is less than 50% of the > current IPv4 allocation unit, and providing that it has not already > received an IPv4 allocation from the IANA during the current IPv4 > allocation period. > > 3. Initial Allocation of IPv4 Address Space > > Each new RIR shall, at the moment of recognition, be allocated one (1) > allocation unit by the IANA. If an allocation unit is not available, > then the IANA will issue this block as soon as one is available. This > allocation will be made regardless of the newly formed RIR's projected > utilization figures and shall be independent of the IPv4 address space > that may have been transferred to the new RIR by the already existing > RIRs as part of the formal transition process. > > 4. Reporting > > a. All returned space is to be recorded in an IANA-published log of IPv4 > address space transactions, with each log entry detailing the returned > address block, the date of the return, and the returning RIR. > > b. All allocated space is also to be recorded in this IANA-published log > of IPv4 address space transactions, with each log entry detailing the > address blocks, the date of the allocation and the recipient RIR. > > c. The IANA will maintain a public registry of the current disposition > of all IPv4 address space, detailing all reservations and current > allocations and current IANA-held address space that is unallocated. > > d) The IANA may make public announcements of IPv4 address block transactions > that occur under this policy. The IANA will make appropriate > modifications to the "Internet Protocol V4 Address Space" page of the > IANA website and may make announcements to its own appropriate > announcement lists. The IANA announcements will be limited to which > address ranges, the time of allocation and to which Registry they have > been allocated. > > Rationale: > > With the depletion of the IANA free pool of IPv4 address space, the > current policy regarding the allocation of IPv4 address space to the > RIRs will become moot. The RIRs may, according to their individual > policies and procedures, recover IPv4 address space. This policy > provides a mechanism for the RIRs to retro allocate the recovered IPv4 > address space to the IANA and provides the IANA the policy by which it > can allocate it back to the RIRs on a needs basis. This policy creates a > new global pool of IPv4 address space that can be allocated where it is > needed on a global basis without a transfer of address space between the > RIRs. > > > Timetable for implementation: > > This policy is to be implemented immediately upon ratification by the > ICANN Board of Directors according to the global policy process > described in the ASO MoU. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > From joey at spiretech.com Mon Jan 26 22:50:31 2009 From: joey at spiretech.com (Joe Pruett) Date: Mon, 26 Jan 2009 19:50:31 -0800 (PST) Subject: [arin-ppml] Why are ISPs allowed? Message-ID: On Sun, 4 Jan 2009, Randy Bush wrote: > i just had a depressing private email exchange with your small and > partially-clued isp. they felt that v4/v4/v4/v4 nat was the way to go > because it was easier for them and easier for the customer. all i could > say was that 'easier' might not be considering the customer support costs. > > the v6 end user experience today is not great. vendor support is > mediocre, both for dual stack and for transition tools (siit/nat-pt). > and the global infrastructure is often tunneled and tromboned. neither > of these will be really fixed until there is financial pressure behind > them. the market, not the mailing lists, rules. i'll fess up to being that partially-clued isp. i didn't think that multilayer nat is the right thing to do, but unless someone builds a good v6<->v4 nat device, then multilevel nat is probably what will happen. it already happens nowadays and people survive (think wireless gateway behind dsl gateway). my research into the v6<->v4 nat state of affairs leads me to believe that multilayer v4 nat is much better understood at this point. From Fred.Wettling at Bechtel.com Tue Jan 27 09:51:21 2009 From: Fred.Wettling at Bechtel.com (Wettling, Fred) Date: Tue, 27 Jan 2009 09:51:21 -0500 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: References: Message-ID: Bechtel Internal / Non-Record// From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Joe Pruett Sent: Monday, January 26, 2009 10:51 PM I'll fess up to being that partially-clued isp. i didn't think that multilayer nat is the right thing to do, but unless someone builds a good v6<->v4 nat device, then multilevel nat is probably what will happen. it already happens nowadays and people survive (think wireless gateway behind dsl gateway). my research into the v6<->v4 nat state of affairs leads me to believe that multilayer v4 nat is much better understood at this point. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reply It would appear that a lot of problems and potential problems would evaporate if carriers & service providers would simply provide native dual-stack to the prem - home & office. Latest computer operating systems already have IPv6 turned on by default. Positioning residential customers for the future is important. CPE devices sold / rented by service providers could help the transition... like the DOCSIS 3.0-based Motorola Surfboard sb6120. Regards - Fred Bechtel Internal / Non-Record// -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6040 bytes Desc: not available URL: From michael.dillon at bt.com Tue Jan 27 10:10:21 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 27 Jan 2009 15:10:21 -0000 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: Message-ID: > CPE devices sold / rented by service providers > could help the transition... like the DOCSIS 3.0-based > Motorola Surfboard sb6120. The Broadband Forum, (formerly DSL Forum) has included IPv6 in its BroadbandSuite specification X.X which is intended to be released in 2009-2010. This covers DSL providers. In fact, many of the existing DSL boxes have the technical capability to support IPv6 today because they are Linux systems. They just have to install and test the software and integrate it into their control panel. More info here including contact info for the Broadband Forum WG that is working on this. --Michael Dillon From kkargel at polartel.com Tue Jan 27 11:21:53 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 27 Jan 2009 10:21:53 -0600 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: References: Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD95@mail> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of michael.dillon at bt.com > Sent: Tuesday, January 27, 2009 9:10 AM > To: ARIN-PPML at arin.net > Subject: Re: [arin-ppml] Why are ISPs allowed? > > > > CPE devices sold / rented by service providers > > could help the transition... like the DOCSIS 3.0-based > > Motorola Surfboard sb6120. > > The Broadband Forum, (formerly DSL Forum) has included IPv6 in its > BroadbandSuite specification X.X which is intended to be released in > 2009-2010. This covers DSL providers. In fact, many of the existing DSL > boxes have the technical capability to support IPv6 today because they > are Linux systems. They just have to install and test the software and > integrate it into their control panel. Wow that sounds easy.. all I have to do is roll a truck to 4000 customers, upgrade the firmware on their modems, install and test the software and integrate it in to their control panels. It actually is easy if you are doing it for yourself and you are technically competent.. but when you are talking about what amounts to a forklift upgrade for an entire class of customer the cost of this easy 'no new hardware' task is no longer trivial. > > More info here > including contact info for the Broadband Forum WG that is working on > this. > > --Michael Dillon > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From tedm at ipinc.net Tue Jan 27 13:51:45 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 27 Jan 2009 10:51:45 -0800 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD95@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD95@mail> Message-ID: Q: How do you eat an elephant? A: In small bites! It's not impossible to upgrade 4K customers if you plan it and allocate enough time. However, realistically what your actually seeing here is a political effort that should be supported. All of the Linux-based DSL modems out there that are in production have already had the R&D money spent to develop their firmware code. Their manufacturers never planned or allocated funding to develop IPv6 code for these devices. What the Broadband Forum is attempting to do is apply enough pressure to force these manufacturers to go back and spend more money developing firmware updates for devices that have already shipped out. It's an admirable attempt and if it can get 1 or 2 manufacturers out there to develop firmware for some devices then it's worth the effort. I would for example like to see Netopia release IPv6 firmware for the Motorola model 3347 DSL modem that Qwest is currently shipping, and I don't think it would kill 2wire to release IPv6 firmware for it's model 2701 that both Qwest and SBC have used. At the least for the Linux-based stuff these manufacturers should be prevailed on to release the firmware source so that the Linux community can add in IPv6 support if it wanted to. The DD-WRT community already has a lot of experience doing this - and frankly, anything developed with Linux is required to release source under the terms of the GPL anyway. My feeling, though, is that what really is going to be needed is a new generation of DSL modems with much faster processors that can do stateful inspection, because after IPv6 we can't depend on the pseudo-firewalling of a NAT to protect customer devices. Just about all DSL modems in the field can be put into bridged mode so that is always an option - to bridge them then put an IPv6 router behind them. Ted > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel > Sent: Tuesday, January 27, 2009 8:22 AM > To: ARIN-PPML at arin.net > Subject: Re: [arin-ppml] Why are ISPs allowed? > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] > > On Behalf Of michael.dillon at bt.com > > Sent: Tuesday, January 27, 2009 9:10 AM > > To: ARIN-PPML at arin.net > > Subject: Re: [arin-ppml] Why are ISPs allowed? > > > > > > > CPE devices sold / rented by service providers could help the > > > transition... like the DOCSIS 3.0-based Motorola Surfboard sb6120. > > > > The Broadband Forum, (formerly DSL Forum) has included IPv6 in its > > BroadbandSuite specification X.X which is intended to be > released in > > 2009-2010. This covers DSL providers. In fact, many of the existing > > DSL boxes have the technical capability to support IPv6 > today because > > they are Linux systems. They just have to install and test the > > software and integrate it into their control panel. > > Wow that sounds easy.. all I have to do is roll a truck to > 4000 customers, upgrade the firmware on their modems, install > and test the software and integrate it in to their control panels. > > It actually is easy if you are doing it for yourself and you > are technically competent.. but when you are talking about > what amounts to a forklift upgrade for an entire class of > customer the cost of this easy 'no new hardware' task is no > longer trivial. > > > > > More info here > > including contact info for the Broadband Forum WG that is > working on > > this. > > > > --Michael Dillon > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed > to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > From tedm at ipinc.net Tue Jan 27 14:06:39 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 27 Jan 2009 11:06:39 -0800 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: References: Message-ID: <14A056791437438082931CEB18546A44@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Joe Pruett > Sent: Monday, January 26, 2009 7:51 PM > To: ARIN-PPML at arin.net > Subject: Re: [arin-ppml] Why are ISPs allowed? > > > i'll fess up to being that partially-clued isp. i didn't > think that multilayer nat is the right thing to do, but > unless someone builds a good v6<->v4 nat device, then > multilevel nat is probably what will happen. it already > happens nowadays and people survive (think wireless gateway > behind dsl gateway). my research into the v6<->v4 nat state > of affairs leads me to believe that multilayer v4 nat is much > better understood at this point. > > Every time I have got involved in setting up a multilayer NAT at a customer site (mainly because the customer has bought themselves a wireless gateway router, against our recommendations, instead of an access point and is behind a DSL modem (ie: M1000) that doesen't work properly in bridged mode) I have observed a significant drop in throughput. I came to the conclusion a long time ago that multilayer NAT was a dead-end and I'm surprised that anyone is still giving it any credibility. I'm glad you don't think that multilayer NAT is the right thing to do, but I disagree with your assumption that this is what will happen anyway. People demand reliability on their circuits - it's bad enough trying to explain to them that in a storm, their DSL line is lower-priority than a voiceline down the street. I've heard enough "I'm losing thousands of dollars of business every hours the Internet connection is down" excuses to last me a lifetime. The idea they would put up with the unreliability of a multilayer NAT is IMHO false. Ted From kkargel at polartel.com Tue Jan 27 16:00:22 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 27 Jan 2009 15:00:22 -0600 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD95@mail> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9D@mail> > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Tuesday, January 27, 2009 12:52 PM > To: Kevin Kargel; ARIN-PPML at arin.net > Subject: RE: [arin-ppml] Why are ISPs allowed? > > > Q: How do you eat an elephant? > > A: In small bites! > > It's not impossible to upgrade 4K customers if you plan it and allocate > enough time. However, realistically what your actually seeing here is > a political effort that should be supported. In no way did I mean to imply that this was impossible or even undoable. It is eminently possible, the doable just depends on how much expense you are willing to expend. In a best case world you would have a bunch of customers within a stones throw of an excellent technician that worked for minimum wage (Ha! Like that's gonna happen).. if he takes a half hour to get to and work each customer and you add in the cost of the truck and overhead and admin costs you are still spending $30-$50 per customer for the upgrade. This in itself doesn't sound like much until you start to figure out what the recovery time is for that money when you are talking about a $29.95/month DSL customer. I am also not saying we will not invest this. It is just something that will naturally cause resistance to change. > > All of the Linux-based DSL modems out there that are in production > have already had the R&D money spent to develop their firmware code. > Their manufacturers never planned or allocated funding to develop > IPv6 code for these devices. What the Broadband Forum is attempting > to do is apply enough pressure to force these manufacturers to go back > and spend more money developing firmware updates for devices that have > already shipped out. It's an admirable attempt and if it can get 1 > or 2 manufacturers out there to develop firmware for some devices then > it's worth the effort. I would for example like to see Netopia release > IPv6 firmware for the Motorola model 3347 DSL modem that Qwest is > currently > shipping, and I don't think it would kill 2wire to release IPv6 firmware > for it's model 2701 that both Qwest and SBC have used. > > At the least for the Linux-based stuff these manufacturers should be > prevailed on to release the firmware source so that the Linux community > can add in IPv6 support if it wanted to. The DD-WRT community already > has a lot of experience doing this - and frankly, anything developed with > Linux is required to release source under the terms of the GPL anyway. > > My feeling, though, is that what really is going to be needed is a > new generation of DSL modems with much faster processors that can > do stateful inspection, because after IPv6 we can't depend on the > pseudo-firewalling of a NAT to protect customer devices. > > Just about all DSL modems in the field can be put into bridged mode > so that is always an option - to bridge them then put an IPv6 router > behind them. > > Ted > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel > > Sent: Tuesday, January 27, 2009 8:22 AM > > To: ARIN-PPML at arin.net > > Subject: Re: [arin-ppml] Why are ISPs allowed? > > > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] > > > On Behalf Of michael.dillon at bt.com > > > Sent: Tuesday, January 27, 2009 9:10 AM > > > To: ARIN-PPML at arin.net > > > Subject: Re: [arin-ppml] Why are ISPs allowed? > > > > > > > > > > CPE devices sold / rented by service providers could help the > > > > transition... like the DOCSIS 3.0-based Motorola Surfboard sb6120. > > > > > > The Broadband Forum, (formerly DSL Forum) has included IPv6 in its > > > BroadbandSuite specification X.X which is intended to be > > released in > > > 2009-2010. This covers DSL providers. In fact, many of the existing > > > DSL boxes have the technical capability to support IPv6 > > today because > > > they are Linux systems. They just have to install and test the > > > software and integrate it into their control panel. > > > > Wow that sounds easy.. all I have to do is roll a truck to > > 4000 customers, upgrade the firmware on their modems, install > > and test the software and integrate it in to their control panels. > > > > It actually is easy if you are doing it for yourself and you > > are technically competent.. but when you are talking about > > what amounts to a forklift upgrade for an entire class of > > customer the cost of this easy 'no new hardware' task is no > > longer trivial. > > > > > > > > More info here > > > including contact info for the Broadband Forum WG that is > > working on > > > this. > > > > > > --Michael Dillon > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed > > to the ARIN > > > Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From matthew at matthew.at Tue Jan 27 16:16:25 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 27 Jan 2009 13:16:25 -0800 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD95@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD95@mail> Message-ID: <497F79A9.6030600@matthew.at> Kevin Kargel wrote: > Wow that sounds easy.. all I have to do is roll a truck to 4000 customers, > upgrade the firmware on their modems, install and test the software and > integrate it in to their control panels. > Right. And when the tech is on site, he loads up the customer database record that hasn't yet been upgraded to support having an IPv6 block assigned to each customer and sets the router to have the address that's in there. Then the network management system that monitors the status of the customer connections that is no longer supported and never did IPv6 gets replaced for free with open source software that costs nothing to maintain, and you set that up using the same data that's not in the customer database. It of course ties right into the flow monitoring system that also doesn't support IPv6 which is how you track down DoS sources and heavy BitTorrent users. There's a reason people aren't just rushing out to do this... it isn't free, and the benefits are vastly outweighed (at present) by the very real costs. Matthew Kaufman From dwhite at olp.net Tue Jan 27 16:21:24 2009 From: dwhite at olp.net (Dan White) Date: Tue, 27 Jan 2009 15:21:24 -0600 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9D@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD95@mail> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9D@mail> Message-ID: <497F7AD4.9010701@olp.net> Kevin Kargel wrote: > >> -----Original Message----- >> From: Ted Mittelstaedt [mailto:tedm at ipinc.net] >> Sent: Tuesday, January 27, 2009 12:52 PM >> To: Kevin Kargel; ARIN-PPML at arin.net >> Subject: RE: [arin-ppml] Why are ISPs allowed? >> >> >> Q: How do you eat an elephant? >> >> A: In small bites! >> >> It's not impossible to upgrade 4K customers if you plan it and allocate >> enough time. However, realistically what your actually seeing here is >> a political effort that should be supported. >> > > In no way did I mean to imply that this was impossible or even undoable. It > is eminently possible, the doable just depends on how much expense you are > willing to expend. > > We've gone through about 3 generations of CPEs in our DSL network, usually to support a new DSL standard or service. Of course there are always those handful of customers who still somehow manage with >5 year old DSL modems, but a large majority of those tend to be removed by attrition over time. The trick is to know how much turnover time you're going to need in your network before you want to start introducing IPv6 to the majority of your customers. For those customers who want it today (or when I have an IPv6 modem in hand), experience tells me they'd be perfectly happy to drop by an office to exchange the modem out, if they believe they're getting value out of the switch. - Dan From owen at delong.com Tue Jan 27 16:36:26 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Jan 2009 13:36:26 -0800 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9D@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD95@mail> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9D@mail> Message-ID: On Jan 27, 2009, at 1:00 PM, Kevin Kargel wrote: > > >> -----Original Message----- >> From: Ted Mittelstaedt [mailto:tedm at ipinc.net] >> Sent: Tuesday, January 27, 2009 12:52 PM >> To: Kevin Kargel; ARIN-PPML at arin.net >> Subject: RE: [arin-ppml] Why are ISPs allowed? >> >> >> Q: How do you eat an elephant? >> >> A: In small bites! >> >> It's not impossible to upgrade 4K customers if you plan it and >> allocate >> enough time. However, realistically what your actually seeing here >> is >> a political effort that should be supported. > > In no way did I mean to imply that this was impossible or even > undoable. It > is eminently possible, the doable just depends on how much expense > you are > willing to expend. > > In a best case world you would have a bunch of customers within a > stones > throw of an excellent technician that worked for minimum wage (Ha! > Like > that's gonna happen).. if he takes a half hour to get to and work > each > customer and you add in the cost of the truck and overhead and admin > costs > you are still spending $30-$50 per customer for the upgrade. > That seems like a horribly expensive approach. I would think that with the kind of coverage you're talking about, you could negotiate a pretty good rate with some shipping carrier of your choosing for the following process: 1. Procure ~200 "upgrade" units. These units would have all the latest software and support and you would do any (ideally none) preparation necessary for them to be installed as CPE prior to shipping. 2. Ship these units to your first 200 customers with a return label requesting that they replace their existing unit with this new unit and return their existing unit within 15 days. Customers who opt out of this upgrade are obliged to return the new unit and procure their own compatible (read speaks IPv6) unit for continued uninterrupted service. 3. Recycle the returned units for the next round of upgrades. 20 rounds and you've upgraded 4000 customers. Sure, it takes almost two years to complete the process, but, if you start now, that's probably about right. Probably costs around $20 per customer instead of $50, and, for those few customers that return broken units or fail to return, you can, if you choose, pass the additional unit cost along to them. Now, instead of comparing that $20/customer to the $30/month you get, compare it to the cost of losing half your customers to some other ISP who is just using IPv6 compatible equipment for all their new customers. Sure, that latter scenario seems unlikely today, but, I think it is coming. As you pointed out, all ISPs are going to have to find a migration path. Those that delay will probably pay more in a shorter period of time with less flexibility in how they do so than those who start earlier. Owen From heather.skanks at gmail.com Tue Jan 27 17:00:24 2009 From: heather.skanks at gmail.com (heather skanks) Date: Tue, 27 Jan 2009 17:00:24 -0500 Subject: [arin-ppml] Renumber and Return inconsistencies in the NRPM Message-ID: <616812070901271400v42d2740bv18d5314d7da24359@mail.gmail.com> Why are the renumber and return policies different for multihomed vs non-multihomed ISP's? It seems to be optional for non-multihomed and required for multihomed - when the level of effort/hassle would be the same. ..and then there is no mention of renumbering for End Users? Is there some history or reasoning to this I'm missing? Standard/Non Multihomed ISP's 4.2.2.1.4. Renumber and return ISPs receiving a new /20 may wish to renumber out of their previously allocated space. In this case, an ISP must use the new /20 to renumber out of that previously allocated block of address space and must return the space to its upstream provider. Multihomed ISP's 4.2.2.2.3. Renumber and return Agree that the newly requested IP address space will be used to renumber out of the current addresses which will be returned to their upstream provider(s). End User Nada - there is nothing about renumber and return in the End User section --Heather -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkargel at polartel.com Tue Jan 27 17:45:38 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 27 Jan 2009 16:45:38 -0600 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <497F7AD4.9010701@olp.net> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD95@mail> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9D@mail> <497F7AD4.9010701@olp.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9F@mail> > -----Original Message----- > From: Dan White [mailto:dwhite at olp.net] > Sent: Tuesday, January 27, 2009 3:21 PM > To: Kevin Kargel > Cc: Ted Mittelstaedt; ARIN-PPML at arin.net > Subject: Re: [arin-ppml] Why are ISPs allowed? > {snip} > For those customers who want it today (or when I have an IPv6 modem in > hand), experience tells me they'd be perfectly happy to drop by an > office to exchange the modem out, if they believe they're getting value > out of the switch. > > - Dan Therin lies the rub, what people are talking about is not change out by attrition over years with a gradual fade to v6, they are talking about an enterprise network rollout changing to v6 across the board in a relatively short time.. a different animal altogether.. this may be an elephant, but it would be an elephant with a short shelf life.. Rotation by attrition would not meet the need. Support of the v4 stack and netblock would necessarily be maintained as long as there is one customer in the netblock. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From dwhite at olp.net Tue Jan 27 17:58:44 2009 From: dwhite at olp.net (Dan White) Date: Tue, 27 Jan 2009 16:58:44 -0600 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9F@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD95@mail> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9D@mail> <497F7AD4.9010701@olp.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9F@mail> Message-ID: <497F91A4.6090008@olp.net> Kevin Kargel wrote: >> -----Original Message----- >> From: Dan White [mailto:dwhite at olp.net] >> Sent: Tuesday, January 27, 2009 3:21 PM >> To: Kevin Kargel >> Cc: Ted Mittelstaedt; ARIN-PPML at arin.net >> Subject: Re: [arin-ppml] Why are ISPs allowed? >> >> > {snip} > >> For those customers who want it today (or when I have an IPv6 modem in >> hand), experience tells me they'd be perfectly happy to drop by an >> office to exchange the modem out, if they believe they're getting value >> out of the switch. >> >> - Dan >> > > Therin lies the rub, what people are talking about is not change out by > attrition over years with a gradual fade to v6, they are talking about an > enterprise network rollout changing to v6 across the board in a relatively > short time.. a different animal altogether.. this may be an elephant, but > it would be an elephant with a short shelf life.. > > Rotation by attrition would not meet the need. Support of the v4 stack and > netblock would necessarily be maintained as long as there is one customer in > the netblock. > I would certainly advise against a 'big power switch' flip. The amount of gradual role out you're afforded is directly proportional to how early you start. - Dan From matthew at matthew.at Tue Jan 27 18:17:55 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 27 Jan 2009 15:17:55 -0800 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <497F91A4.6090008@olp.net> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD95@mail> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9D@mail> <497F7AD4.9010701@olp.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9F@mail> <497F91A4.6090008@olp.net> Message-ID: <497F9623.8030209@matthew.at> Dan White wrote: > > > The amount of gradual role out you're afforded is directly proportional > to how early you start. > > Yes. Those of us who start five years ago will have much more pain those those of us who start ten years ago. Starting today or later, however, is too late. Matthew Kaufman From scottleibrand at gmail.com Tue Jan 27 18:45:14 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 27 Jan 2009 15:45:14 -0800 Subject: [arin-ppml] Renumber and Return inconsistencies in the NRPM In-Reply-To: <616812070901271400v42d2740bv18d5314d7da24359@mail.gmail.com> References: <616812070901271400v42d2740bv18d5314d7da24359@mail.gmail.com> Message-ID: <497F9C8A.40705@gmail.com> As far as I know, the Standard ISP, Multihomed ISP, and End User policies were developed more or less independently, and we've never gone back and tried to make them all consistent. I think a policy to simplify the complete text of all three policies (not just the renumbering and return part), and make them consistent with each other, would be worthwhile for us to take up... -Scott heather skanks wrote: > Why are the renumber and return policies different for multihomed vs > non-multihomed ISP's? It seems to be optional for non-multihomed and > required for multihomed - when the level of effort/hassle would be the > same. ..and then there is no mention of renumbering for End Users? > Is there some history or reasoning to this I'm missing? > > > Standard/Non Multihomed ISP's > > 4.2.2.1.4. Renumber and return > ISPs receiving a new /20 may wish to renumber out of their previously > allocated space. In this case, an ISP must use the new /20 to renumber > out of that previously allocated block of address space and must > return the space to its upstream provider. > > > > Multihomed ISP's > > 4.2.2.2.3. Renumber and return > > Agree that the newly requested IP address space will be used to > renumber out of the current addresses which will be returned to their > upstream provider(s). > > > End User > > Nada - there is nothing about renumber and return in the End User section > > > --Heather > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 Tue Jan 27 18:57:13 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 27 Jan 2009 16:57:13 -0700 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <497F9623.8030209@matthew.at> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD95@mail> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9D@mail> <497F7AD4.9010701@olp.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9F@mail> <497F91A4.6090008@olp.net> <497F9623.8030209@matthew.at> Message-ID: <443de7ad0901271557t36db86e2i239851f20d29c58e@mail.gmail.com> On Tue, Jan 27, 2009 at 16:17, Matthew Kaufman wrote: > Dan White wrote: >> >> >> The amount of gradual role out you're afforded is directly proportional >> to how early you start. >> >> > Yes. Those of us who start five years ago will have much more pain those > those of us who start ten years ago. > > Starting today or later, however, is too late. I must disagree. Starting now is much better than not starting, too late implies that we should all throw our hands up - if we do that it will be even worse than not starting 10 years ago. ~Chris > > Matthew Kaufman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- Chris Grundemann www.chrisgrundemann.com From john.sweeting at twcable.com Tue Jan 27 19:31:01 2009 From: john.sweeting at twcable.com (Sweeting, John) Date: Tue, 27 Jan 2009 19:31:01 -0500 Subject: [arin-ppml] Renumber and Return inconsistencies in the NRPM Message-ID: <58174FA985B92A42B9E3142C4DD2CC04A0027C@PRVPVSMAIL07.corp.twcable.com> Does anyone (Bill or Cathy for instance) have some hstorical perspective they can share? P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible. ----- Original Message ----- From: arin-ppml-bounces at arin.net To: heather skanks Cc: arin ppml Sent: Tue Jan 27 18:45:14 2009 Subject: Re: [arin-ppml] Renumber and Return inconsistencies in the NRPM As far as I know, the Standard ISP, Multihomed ISP, and End User policies were developed more or less independently, and we've never gone back and tried to make them all consistent. I think a policy to simplify the complete text of all three policies (not just the renumbering and return part), and make them consistent with each other, would be worthwhile for us to take up... -Scott heather skanks wrote: > Why are the renumber and return policies different for multihomed vs > non-multihomed ISP's? It seems to be optional for non-multihomed and > required for multihomed - when the level of effort/hassle would be the > same. ..and then there is no mention of renumbering for End Users? > Is there some history or reasoning to this I'm missing? > > > Standard/Non Multihomed ISP's > > 4.2.2.1.4. Renumber and return > ISPs receiving a new /20 may wish to renumber out of their previously > allocated space. In this case, an ISP must use the new /20 to renumber > out of that previously allocated block of address space and must > return the space to its upstream provider. > > > > Multihomed ISP's > > 4.2.2.2.3. Renumber and return > > Agree that the newly requested IP address space will be used to > renumber out of the current addresses which will be returned to their > upstream provider(s). > > > End User > > Nada - there is nothing about renumber and return in the End User section > > > --Heather > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From michael.dillon at bt.com Tue Jan 27 20:07:54 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 28 Jan 2009 01:07:54 -0000 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD95@mail> Message-ID: > Wow that sounds easy.. all I have to do is roll a truck to > 4000 customers, upgrade the firmware on their modems, install > and test the software and integrate it in to their control panels. The control panel that I referred to is the one that is internal to the DSL access device. Some ISPs do firmware upgrades on customer DSL devices remotely with no truck rolls. And most ISPs don't give new devices to the customer unless they pay for them. Let's be clear here, the IPv4 Internet still works fine even when we run out of addresses to grow it. It is the new customers who will buy the DSL access devices, either bundled with your service or not, and begin growing the IPv6 Internet. > It actually is easy if you are doing it for yourself and you > are technically competent.. but when you are talking about > what amounts to a forklift upgrade for an entire class of > customer the cost of this easy 'no new hardware' task is no > longer trivial. The only ISPs that will upgrade an entire class of customer will be doing so because they want to recover IPv4 addresses for use with more profitable, probably business customers. They will be robbing Peter to pay Paul, and won't be concerned about losing a few of them due to the chaos. You can't really avoid some level of chaos with this transition, only try to minimize it. --Michael Dillon From stephen at sprunk.org Tue Jan 27 21:10:38 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 27 Jan 2009 20:10:38 -0600 Subject: [arin-ppml] Renumber and Return inconsistencies in the NRPM In-Reply-To: <616812070901271400v42d2740bv18d5314d7da24359@mail.gmail.com> References: <616812070901271400v42d2740bv18d5314d7da24359@mail.gmail.com> Message-ID: <497FBE9E.8090504@sprunk.org> heather skanks wrote: > Why are the renumber and return policies different for multihomed vs > non-multihomed ISP's? It seems to be optional for non-multihomed and > required for multihomed - when the level of effort/hassle would be the > same. ..and then there is no mention of renumbering for End Users? > Is there some history or reasoning to this I'm missing? > > Standard/Non Multihomed ISP's > > 4.2.2.1.4. Renumber and return > ISPs receiving a new /20 may wish to renumber out of their previously > allocated space. In this case, an ISP must use the new /20 to renumber > out of that previously allocated block of address space and must > return the space to its upstream provider. > > Multihomed ISP's > > 4.2.2.2.3. Renumber and return > Agree that the newly requested IP address space will be used to > renumber out of the current addresses which will be returned to their > upstream provider(s). > > > End User > Nada - there is nothing about renumber and return in the End User section The differences certainly are problematic. Reading those sections in isolation, it seems that the rationale is that if you're using hosts in PA space to justify their first PI block, then you should be required to renumber those hosts rather than keeping them in the PA space. If that is indeed the idea, it should be separated out from the above three cases into one general one and made /much/ more clear. As to how it ended up this way, well, they were different policies written by different people at different times, and the trend (with a few notable exceptions) has been to divide things and write new language rather than reference other sections of the NRPM or reorganize/combine sections that are redundant... S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From stephen at sprunk.org Tue Jan 27 21:32:27 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 27 Jan 2009 20:32:27 -0600 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9D@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD95@mail> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9D@mail> Message-ID: <497FC3BB.9050302@sprunk.org> Kevin Kargel wrote: >> -----Original Message----- >> From: Ted Mittelstaedt [mailto:tedm at ipinc.net] >> Sent: Tuesday, January 27, 2009 12:52 PM >> To: Kevin Kargel; ARIN-PPML at arin.net >> Subject: RE: [arin-ppml] Why are ISPs allowed? >> >> >> Q: How do you eat an elephant? >> >> A: In small bites! >> >> It's not impossible to upgrade 4K customers if you plan it and allocate >> enough time. However, realistically what your actually seeing here is >> a political effort that should be supported. >> > > In no way did I mean to imply that this was impossible or even undoable. It is eminently possible, the doable just depends on how much expense you are willing to expend. > > In a best case world you would have a bunch of customers within a stones throw of an excellent technician that worked for minimum wage (Ha! Like that's gonna happen).. if he takes a half hour to get to and work each customer and you add in the cost of the truck and overhead and admin costs you are still spending $30-$50 per customer for the upgrade. > Why would you need to roll a truck to do a software upgrade of ISP-provided CPE? I don't know about your ISP, but mine rolls out firmware updates every 4-6 months. And, as an employee of $VENDOR, I can tell you our products are specifically designed to make that as easy as possible since it's a top concern of our customers -- and we'd be out of business if we didn't offer at least some capability in that area. (In our case, the devices check a server for new software and configuration every time they boot up and/or at a configurable interval; rolling out an upgrade is just a matter of copying a new binary to the server and asking the NOC to notify you of problems -- not rolling trucks.) Now, customer-provided CPE is an entirely different beast. Many vendors don't put out software updates for older models to fix bugs, much less introduce new features, nor do they provide any sort of "phone home" feature to look for updates even if such existed. However, the ISP isn't responsible for those devices either, and customers can cope with buying a new one if necessary -- or they could if there were actually any on the shelves that did IPv6... S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From info at arin.net Wed Jan 28 11:12:16 2009 From: info at arin.net (Member Services) Date: Wed, 28 Jan 2009 11:12:16 -0500 Subject: [arin-ppml] Advisory Council Draft Policy and Proposal Decisions Message-ID: <498083E0.9020202@arin.net> Advisory Council Draft Policy and Proposal Decisions On 24 January 2009 the ARIN Advisory Council (AC), acting under the provisions of the ARIN Policy Development Process, recommended that the ARIN Board of Trustees adopt: Draft Policy 2007-14: Resource Review Process http://www.arin.net/policy/proposals/2007_14.html In addition, the AC, acting under the provisions of the ARIN Policy Development Process, recommended that the ARIN Board of Trustees adopt a revised version of 2008-6: Draft Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses http://www.arin.net/policy/proposals/2008_6.html The next step for the above two proposals is a review by the ARIN Board of Trustees. The AC reviewed the following three proposals and accepted them onto the AC's docket for development and evaluation: Policy Proposal: IPv4 Recovery Fund Policy Proposal: Depleted IPv4 reserves Policy Proposal: Allocation of IPv4 Blocks to Regional Internet Registries Proposal texts are available at: http://www.arin.net/policy/proposals/proposal_archive.html The ARIN Policy Development Process can be found at: http://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) From joey at spiretech.com Wed Jan 28 12:09:31 2009 From: joey at spiretech.com (Joe Pruett) Date: Wed, 28 Jan 2009 09:09:31 -0800 (PST) Subject: [arin-ppml] Why are ISPs allowed? Message-ID: On Tue, 27 Jan 2009, Wettling, Fred wrote: > It would appear that a lot of problems and potential problems would > evaporate if carriers & service providers would simply provide native > dual-stack to the prem - home & office. Latest computer operating systems > already have IPv6 turned on by default. Positioning residential customers > for the future is important. CPE devices sold / rented by service providers > could help the transition... like the DOCSIS 3.0-based Motorola Surfboard think of all the devices inside the network that are v4 only and will probably never have v6. tivo, xbox, wii, webcam, x10 gateway, voip adapter, etc. some of those will eventually have a need to talk to a v6 only device. if we can fit a v6<->v4 nat system into all home gateways, then maybe we have a chance, but that is quite a bit of work for those small boxes to handle because of the need to proxy dns at the very least, and ftp, sip, etc to give the best behavior. From tedm at ipinc.net Wed Jan 28 12:33:34 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 28 Jan 2009 09:33:34 -0800 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <497FC3BB.9050302@sprunk.org> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD95@mail> <70DE64CEFD6E9A4EB7FAF3A06314106601B4AD9D@mail> <497FC3BB.9050302@sprunk.org> Message-ID: <2A16AC9AD9A04A66A38592D77BCBA829@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Stephen Sprunk > Sent: Tuesday, January 27, 2009 6:32 PM > To: Kevin Kargel; ARIN PPML > Subject: Re: [arin-ppml] Why are ISPs allowed? > > Now, customer-provided CPE is an entirely different beast. > Many vendors don't put out software updates for older models > to fix bugs, much less introduce new features, nor do they > provide any sort of "phone home" > feature to look for updates even if such existed. However, > the ISP isn't responsible for those devices either, and > customers can cope with buying a new one if necessary -- or > they could if there were actually any on the shelves that did IPv6... Totally unnecessary - most CPEs even old ones can be put into bridged mode and a new router that does DHCP or PPP or whatever your poison and that is IPv6 compliant can be placed behind the CPE. Ted From tedm at ipinc.net Wed Jan 28 12:45:26 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 28 Jan 2009 09:45:26 -0800 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: References: Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Joe Pruett > Sent: Wednesday, January 28, 2009 9:10 AM > To: ARIN-PPML at arin.net > Subject: Re: [arin-ppml] Why are ISPs allowed? > > On Tue, 27 Jan 2009, Wettling, Fred wrote: > > > It would appear that a lot of problems and potential > problems would > > evaporate if carriers & service providers would simply > provide native > > dual-stack to the prem - home & office. Latest computer operating > > systems already have IPv6 turned on by default. Positioning > > residential customers for the future is important. CPE > devices sold > > / rented by service providers could help the transition... > like the > > DOCSIS 3.0-based Motorola Surfboard > > think of all the devices inside the network that are v4 only > and will probably never have v6. tivo, xbox, wii, webcam, > x10 gateway, voip adapter, etc. some of those will > eventually have a need to talk to a v6 only device. WHAT kind of device are we talking about here? > if we > can fit a v6<->v4 nat system into all home gateways, then > maybe we have a chance, but that is quite a bit of work for > those small boxes to handle because of the need to proxy dns > at the very least, and ftp, sip, etc to give the best behavior. > IPv6<>IPv4 proxies have been successfully demonstrated and I think most customers would accept the statement that their 4 year old Xbox or wii will not be able to surf the IPv6 web unless they either upgrade it, or use the ISP-supplied proxy IPv6<>IPv4 server. As for VoIP gear that's a no-brainer, Vonage and the other extract-$25-a-month-from-your-wallet VoIP providers are more than happy to hand out new IPv6-compliant VoIP adapters like free candy. As for the rest of it, like your Windows 98 or ME system that your just dying to NetMeeting into, or your Solaris 2.5 system you simply must telnet into, well your going to have to setup a bastion host that speaks both IPv6 and IPv4, and remote into that from the outside. The big concern really is if television manufacturers ever pull their heads out of their butts and start including the ability to plug an Ethernet cable into your 42" Plasma and stream television shows off nbc.com and suchlike. But so far the only acknowledgement that they seem to have made that television can come into the TV from a source other than a cable line or an antenna is to stick a VGA port on the TV. And more and more flatscreens are lacking even that now. Ted From owen at delong.com Wed Jan 28 12:41:29 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 28 Jan 2009 09:41:29 -0800 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: References: Message-ID: <230555B4-ADF9-4952-BAE9-FFEBF855FE66@delong.com> On Jan 28, 2009, at 9:09 AM, Joe Pruett wrote: > On Tue, 27 Jan 2009, Wettling, Fred wrote: > >> It would appear that a lot of problems and potential problems would >> evaporate if carriers & service providers would simply provide native >> dual-stack to the prem - home & office. Latest computer operating >> systems >> already have IPv6 turned on by default. Positioning residential >> customers >> for the future is important. CPE devices sold / rented by service >> providers >> could help the transition... like the DOCSIS 3.0-based Motorola >> Surfboard > > think of all the devices inside the network that are v4 only and > will probably > never have v6. tivo, xbox, wii, webcam, x10 gateway, voip adapter, > etc. some > of those will eventually have a need to talk to a v6 only device. > if we can > fit a v6<->v4 nat system into all home gateways, then maybe we have > a chance, > but that is quite a bit of work for those small boxes to handle > because of the > need to proxy dns at the very least, and ftp, sip, etc to give the > best > behavior. > TiVo and Xbox will probably have IPv6 as soon as either company sees substantial meaningful deployment. Same with PS/3. TiVo is built on linux so IPv6 support will not require much more than some added UI code. Xbox is built on a variant of Windows, which has IPv6 support and I doubt it will be a major issue for Micr0$0ft to bring that along. Webcams that are IP based and not host-attached will probably be forklift upgrades over time and will probably be part of the cost of decommissioning IPv4 when that time comes. Same with x10 and the various VOIP adapters. They're relatively inexpensive on a per unit basis. That leaves WII. I doubt Nintendo will have that much trouble updating their software to accommodate IPv6 when they feel it is needed. Owen From joey at spiretech.com Wed Jan 28 13:16:18 2009 From: joey at spiretech.com (Joe Pruett) Date: Wed, 28 Jan 2009 10:16:18 -0800 (PST) Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <230555B4-ADF9-4952-BAE9-FFEBF855FE66@delong.com> References: <230555B4-ADF9-4952-BAE9-FFEBF855FE66@delong.com> Message-ID: On Wed, 28 Jan 2009, Owen DeLong wrote: > TiVo and Xbox will probably have IPv6 as soon as either company sees > substantial meaningful deployment. Same with PS/3. TiVo is built on > linux so IPv6 support will not require much more than some added UI > code. Xbox is built on a variant of Windows, which has IPv6 support > and I doubt it will be a major issue for Micr0$0ft to bring that along. > > Webcams that are IP based and not host-attached will probably be > forklift upgrades over time and will probably be part of the cost of > decommissioning IPv4 when that time comes. Same with x10 and > the various VOIP adapters. They're relatively inexpensive on a per > unit basis. > > That leaves WII. I doubt Nintendo will have that much trouble updating > their software to accommodate IPv6 when they feel it is needed. my list was just examples. yes, some will get v6, quite a few things won't. when i get to the point that i only have v6 addresses to hand out to customers, i need to have hardware to sell/give them that will allow their existing network to continue to run. your typical residential customer isn't going to accept that some of their existing equipment won't work with my network when "giant isp" that has managed to hoard enough v4 addresses can give them a connection where everything works fine. so far i am not seeing any sign of such a piece of hardware... From tedm at ipinc.net Wed Jan 28 14:01:17 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 28 Jan 2009 11:01:17 -0800 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: References: <230555B4-ADF9-4952-BAE9-FFEBF855FE66@delong.com> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Joe Pruett > Sent: Wednesday, January 28, 2009 10:16 AM > To: ARIN-PPML at arin.net > Subject: Re: [arin-ppml] Why are ISPs allowed? > > On Wed, 28 Jan 2009, Owen DeLong wrote: > > > TiVo and Xbox will probably have IPv6 as soon as either > company sees > > substantial meaningful deployment. Same with PS/3. TiVo > is built on > > linux so IPv6 support will not require much more than some added UI > > code. Xbox is built on a variant of Windows, which has > IPv6 support > > and I doubt it will be a major issue for Micr0$0ft to bring > that along. > > > > Webcams that are IP based and not host-attached will probably be > > forklift upgrades over time and will probably be part of > the cost of > > decommissioning IPv4 when that time comes. Same with x10 and the > > various VOIP adapters. They're relatively inexpensive on a > per unit > > basis. > > > > That leaves WII. I doubt Nintendo will have that much trouble > > updating their software to accommodate IPv6 when they feel > it is needed. > > my list was just examples. yes, some will get v6, quite a > few things won't. when i get to the point that i only have > v6 addresses to hand out to customers, i need to have > hardware to sell/give them that will allow their existing > network to continue to run. your typical residential > customer Whoah, hold on here. How many typical residential customers have a "network"? Most residential customers have at most a couple PC's, and from time to time you run into a gamer with a gaming console that's plugged in. Are we talking business connections or residential connections? They are NOT the same thing. > isn't going to accept that some of their existing > equipment won't work with my network when "giant isp" that > has managed to hoard enough v4 addresses can give them a > connection where everything works fine. so far i am not > seeing any sign of such a piece of hardware... There's nothing that is preventing you from remaking your network so that you hand out a /24 of private IPv4 numbering to every customer that comes to you asking for IPv4. You can NAT that and provide your customers enough numbering so they can simply route to you, thus avoiding double-natting. There's plenty of firewalls out there that do stateful inspection and that don't require the firewall to act as a translator. If your customers want to screw up their throughput by slapping a translator on their own network, that's their business. Now, as for the other arguments, If you're an ISP now then you have sufficient IPv4. If you don't, then get cracking and get that application submitted for more numbering pronto. The giant ISPs can't build a business model around thieving away customers based on having hoarded IPv4. For starters, if any of them were to openly advertise such a thing, they would face intense scrutiny that they violated the NPRM when they obtained their last IPv4 block and lied to obtain more than the maximum allowable IPv4 they could justify. Since all the other "giant isps" are just as vulnerable to IPv4 customer theft as you are, I'm sure that they will be looking for an org they can string up on the nearest tree to serve as an example, post-IPv4 runout. Any giant org that were to openly market this would almost certainly be sued for fraud by ARIN - and even more dangerous would be the risk of having IPv4 withdrawn on the grounds of fraud. Not to mention the unofficial response which would be even more deadly. Do you really want Comcast or someone like that turning a blind eye to an operating DDoS ring on their network that has decided to hose you down because your advertising you have IPv4 and Comcast doesen't? I think your going to see the "giant ISP's" collude with each other to present a unified front to the customers - approximately a year or so after IPv4 runout, all of them will announce that they cannot hand out new IPv4 to customers unless the customer pays a premium for it. It is in their own selfish self-interest to do this. Check out the almost unified screaming by the television industry to the Obama administrations move to push back the HDTV broadcast switchover from Feb 17th. Using your logic the large networks should be happy about the pushback since it allows them to keep away analog-only customers from smaller TV networks that are already doing digital-only HD broadcasting. Instead, they are all mad about it. Ted From michael.dillon at bt.com Wed Jan 28 15:23:35 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 28 Jan 2009 20:23:35 -0000 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: Message-ID: > Not to mention the unofficial response which would be > even more deadly. Big companies have shareholders, stock analysts and the SEC to worry about. They have to answer questions about IPv6 truthfully and they can't hide any known issues that could have a material impact on the company. > I think your going to see the "giant ISP's" collude with each > other to present a unified front to the customers - > approximately a year or so after IPv4 runout, all of them > will announce that they cannot hand out new IPv4 to customers > unless the customer pays a premium for it. It is in their > own selfish self-interest to do this. This won't be collusion. It will be because they all rely on the same set of vendors for boxes that support IPv6, and when those vendors all reach a certain point of IPv6 support, all the ISPs will move to v6 more or less at the same time. This is good for the consumer because it increases the network effect of IPv6 and ensures that they will be able to get some communications value out of the switch. Since a consumer customer is inherently less profitable than a business customer, and their technical disruption of going to IPv6 is minimal and controlled, it makes sense for all ISPs to mine for IPv4 by migrating consumers to IPv6. This will allow them to continue to provide IPv4 service to the slower moving businesses for years and years. Hosting providers seem to be the first organizations to take IPv6 seriously (think Google Docs) probably because their scaling and load-balancing architectures are well thought out and can handle shifting to IPv6 as consumer traffic builds. > Check out the almost unified screaming by the television > industry to the Obama administrations move to push back the > HDTV broadcast switchover from Feb 17th. This is an excellent event for IPv6. Now we have a concrete way to tell people in the USA that they have to act and cannot delay the change. The IPv4 runout is not like the switch to digital TV where you can delay things by legislating it. It's like the millenium bug where you have to get stuff fixed now, not later. --Michael Dillon From ocl at gih.com Wed Jan 28 18:03:34 2009 From: ocl at gih.com (Olivier MJ Crepin-Leblond) Date: Thu, 29 Jan 2009 00:03:34 +0100 Subject: [arin-ppml] Why are ISPs allowed? References: Message-ID: <124AA6D10AFE4D53AEA5EFEFEE36FADD@GIH.CO.UK> "Joe Pruett" wrote: > think of all the devices inside the network that are v4 only and > will probably > never have v6. tivo, xbox, wii, webcam, x10 gateway, voip adapter, > etc. some > of those will eventually have a need to talk to a v6 only device. Perhaps - but then again, you and many others here are forgetting one main word which I'd like to re-introduce to the whole list: *obsolete* One day, the laptop which you have just purchased and is currently at the edge of technology will be obsolete. It will be disposed of in the trash (and hopefully recycled). If, like me, you have lived through countless generations of computers, PCs and other networking gear you'll know that it all used to end up in a landfill site. Hopefully we'll find better things to do in the future now that we're a little more concerned about the environment. Try running the latest version of Windows on an 80386. (I've tried and failed) Try running Mac OSX on a Mac Plus. (I've tried and failed) Try surfing the Web on an Apple II. (I've tried and failed) You get the point - migration to IPv6 will make some devices obsolete. Judging from what's happened in other occurences of obsolescence, some programmers/manufacturers will probably serve this niche market, until it doesn't make financial sense to propose such products anymore. These devices will then either be kept in a basement somewhere, as "sentimental value goods", or disposed of. O. From geneb at deltasoft.com Wed Jan 28 18:22:23 2009 From: geneb at deltasoft.com (Gene Buckle) Date: Wed, 28 Jan 2009 15:22:23 -0800 (PST) Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: <124AA6D10AFE4D53AEA5EFEFEE36FADD@GIH.CO.UK> References: <124AA6D10AFE4D53AEA5EFEFEE36FADD@GIH.CO.UK> Message-ID: On Thu, 29 Jan 2009, Olivier MJ Crepin-Leblond wrote: > Try running the latest version of Windows on an 80386. (I've tried and > failed) I call shennanigans. Not that it wouldn't work - that's obvious - but that you ever tried. You'd know better before hand. At least I hope. Windows95 (maybe) or Windows 3.11 (definately) would both work on that platform and have a working TCP/IP stack. > Try running Mac OSX on a Mac Plus. (I've tried and failed) See above. I don't know what the last release of MacOS was that supported the Plus, but it may have TCP/IP support and maybe NSCA Mosaic. Not sure. > Try surfing the Web on an Apple II. (I've tried and failed) > See above. Again. Contiki. Here's a link with more information: http://www.sics.se/contiki/perspective/browsing-the-web-from-an-apple-ii-with-contiki.html > You get the point - migration to IPv6 will make some devices obsolete. You're entirely correct on this point. However, specious hyperbole doesn't make that case. Oh, and I've also seen people browse the web on a Commodore 64. Don't ever tell a geek something can't be done. You'll get beat in spades. :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. From ocl at gih.com Wed Jan 28 18:27:39 2009 From: ocl at gih.com (Olivier MJ Crepin-Leblond) Date: Thu, 29 Jan 2009 00:27:39 +0100 Subject: [arin-ppml] Why are ISPs allowed? References: Message-ID: <6E09C58F98D34AEFABBD517CAF0F9E10@GIH.CO.UK> "Ted Mittelstaedt" wrote: > The big concern really is if television manufacturers ever pull > their heads out of their butts and start including the ability to > plug an Ethernet cable into your 42" Plasma and stream television > shows off nbc.com and suchlike. But so far the only acknowledgement > that they seem to have made that television can come into the TV > from > a source other than a cable line or an antenna is to stick a VGA > port > on the TV. And more and more flatscreens are lacking even that now. Not so. Check: http://www.dlna.org/about_us/roadmap/ Oh - and you can see that IPv6 is featured here as being an enabling technology. :-> O. From ocl at gih.com Wed Jan 28 19:06:30 2009 From: ocl at gih.com (Olivier MJ Crepin-Leblond) Date: Thu, 29 Jan 2009 01:06:30 +0100 Subject: [arin-ppml] Why are ISPs allowed? References: <124AA6D10AFE4D53AEA5EFEFEE36FADD@GIH.CO.UK> Message-ID: "Gene Buckle" wrote: > On Thu, 29 Jan 2009, Olivier MJ Crepin-Leblond wrote: > >> Try running the latest version of Windows on an 80386. (I've tried >> and >> failed) > > I call shennanigans. Not that it wouldn't work - that's obvious - > but > that you ever tried. You'd know better before hand. At least I > hope. I tried Win95. It worked (32-bit O/S so it was ok) Win 98 (using /mm switch) worked but was very slow - I suspect memory was more of an issue than anything else. Win 98 SE coughed. I don't know why and I gave up after wasting too much time. Win XP was un-installable. > Windows95 (maybe) or Windows 3.11 (definately) would both work on > that > platform and have a working TCP/IP stack. > >> Try running Mac OSX on a Mac Plus. (I've tried and failed) > See above. I don't know what the last release of MacOS was that > supported > the Plus, but it may have TCP/IP support and maybe NSCA Mosaic. Not > sure. It used to work using Telnet, Gopher, WAIS, etc. I never tried with Mosaic but... many web sites now reject NSCA Mosaic & other early browsers. Pages just hang - because so much unrecognised information is now present. :-( > >> Try surfing the Web on an Apple II. (I've tried and failed) >> > See above. Again. Contiki. > > Here's a link with more information: > http://www.sics.se/contiki/perspective/browsing-the-web-from-an-apple-ii-with-contiki.html That's not surfing the Web - it's more painful than using Gopher! My set-up was: - Apple IIgs (a souped up Apple II using the 65816 instead of 6502 proc) - 4Mb add-on memory card (3rd party) - external 3.5in drive - external 100mb hard drive (3rd party) - ProDos 16 (or was it GS-OS, I can't remember) No ethernet card because this was virtually impossible to get a hold of. I hooked up a 56K US Robotics modem and tried running various hacks found on the Internet (logging in on a Linux Box to download data by FTP & using Kermit to download to the Apple II). I have *never* managed to get any kind of browser working correctly - except using Linx remotely - but that's cheating! > >> You get the point - migration to IPv6 will make some devices >> obsolete. > > You're entirely correct on this point. However, specious hyperbole > doesn't make that case. > > Oh, and I've also seen people browse the web on a Commodore 64. > Don't > ever tell a geek something can't be done. You'll get beat in > spades. :) I can be a geek too. :-) Apologies to others for the length of the intermission. O. From mueller at syr.edu Thu Jan 29 11:25:21 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 29 Jan 2009 11:25:21 -0500 Subject: [arin-ppml] DTV and IPv6 In-Reply-To: References: Message-ID: <75822E125BCB994F8446858C4B19F0D70F4961B1@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > This is an excellent event for IPv6. Now we have a concrete way > to tell people in the USA that they have to act and cannot > delay the change. The IPv4 runout is not like the switch to > digital TV where you can delay things by legislating it. It's > like the millenium bug where you have to get stuff fixed now, > not later. > The DTV delay is a very bad sign for the v6 migration. It indicates that politicians in the US are so fearful of the possibility that people will be stranded when analog is shut off that they are willing to maintain very costly "dual stack" equivalents (broacasting on two channels) for another 6 months (or more). It indicates that after 13 years of planning for this transition no one has any confidence that it will work when we actually pull the trigger. Yes, as Dillon there is says one critical difference: broadcasting is a highly regulated industry with an overlay of political control and responsibility lodged directly in governments. (This hierarchical, political form of control has done as much to delay the transition as hasten it, as anyone familiar with the politics of U.S. broadcasting knows.) But anyone who thinks that this somehow demonstrates that we should laugh in the face of v4 address runout and that running into a brick wall will somehow facilitate a smooth and effective transition, is being irresponsible. What the DTV case really indicates is that such migrations are complex, unpredictable and difficult to manage. Anyone who imposes an artificial constraint on that migration, such as not fully utilizing underutilized v4 addresses in the vain hope that this will "force" people to behave the way they want them to behave, is playing a game of chicken. Who will be responsible when the internet gets into the crash? Some guy on a listserv who urged ARIN to speed up as it approached the brick wall? Do you think politicians will remain on the sidelines when the game of chicken results in a smash-up? From sethm at rollernet.us Thu Jan 29 13:07:08 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 29 Jan 2009 10:07:08 -0800 Subject: [arin-ppml] DTV and IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D70F4961B1@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D70F4961B1@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4981F04C.4080002@rollernet.us> Milton L Mueller wrote: >> -----Original Message----- > >> This is an excellent event for IPv6. Now we have a concrete way >> to tell people in the USA that they have to act and cannot >> delay the change. The IPv4 runout is not like the switch to >> digital TV where you can delay things by legislating it. It's >> like the millenium bug where you have to get stuff fixed now, >> not later. >> > > The DTV delay is a very bad sign for the v6 migration. It indicates that politicians in the US are so fearful of the possibility that people will be stranded when analog is shut off that they are willing to maintain very costly "dual stack" equivalents (broacasting on two channels) for another 6 months (or more). It indicates that after 13 years of planning for this transition no one has any confidence that it will work when we actually pull the trigger. > > Yes, as Dillon there is says one critical difference: broadcasting is a highly regulated industry with an overlay of political control and responsibility lodged directly in governments. (This hierarchical, political form of control has done as much to delay the transition as hasten it, as anyone familiar with the politics of U.S. broadcasting knows.) > > But anyone who thinks that this somehow demonstrates that we should laugh in the face of v4 address runout and that running into a brick wall will somehow facilitate a smooth and effective transition, is being irresponsible. What the DTV case really indicates is that such migrations are complex, unpredictable and difficult to manage. Anyone who imposes an artificial constraint on that migration, such as not fully utilizing underutilized v4 addresses in the vain hope that this will "force" people to behave the way they want them to behave, is playing a game of chicken. Who will be responsible when the internet gets into the crash? Some guy on a listserv who urged ARIN to speed up as it approached the brick wall? > > Do you think politicians will remain on the sidelines when the game of chicken results in a smash-up? > It's not entirely a matter of confidence. Irrespective of all the DTV transition ads, people have no clue it means, don't want to get a box, don't think they need a box, or don't want the government telling them they should change. There's no apparent value in getting a box right now when as far as they can see their TV still works fine. ~Seth From kbanks at giantcomm.net Thu Jan 29 13:18:38 2009 From: kbanks at giantcomm.net (Kyle Banks) Date: Thu, 29 Jan 2009 12:18:38 -0600 Subject: [arin-ppml] DTV and IPv6 In-Reply-To: <4981F04C.4080002@rollernet.us> References: <75822E125BCB994F8446858C4B19F0D70F4961B1@SUEX07-MBX-04.ad.syr.edu> <4981F04C.4080002@rollernet.us> Message-ID: <002f01c9823e$025e5690$3501a8c0@macc173.net> Speaking solely as a guy that works for a cable company, I think the whole DTV Delay, could have been solved by a little better planning on the manufacturers level. The main reason for the delay is the manufacturers lack of supplies, Now if they would have started running that add about a year earlier, and actually had the boxes available, then I think this could have been avoided...And the fact that the Ads, banners, and informational material, just recently started noting the fact that if you are on a cable tv system then you don't need to take any action whatsoever, Is kinda BS... If people were better informed when they're forced to take action it would create a lot less turmoil, anger, and confusion... I mean seriously, If I'm being forced into a van by a guy with a gun, at least tell me where I'm going... Kyle V. Banks Service/Technical Representative Giant Communications 785-362-9331 EXT. 108 kbanks at giantcomm.net -- Blessed is he who expects nothing, for he shall never be disappointed--Benjamin Franklin -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Seth Mattinen Sent: Thursday, January 29, 2009 12:07 PM To: ARIN-PPML at arin.net Subject: Re: [arin-ppml] DTV and IPv6 Milton L Mueller wrote: >> -----Original Message----- > >> This is an excellent event for IPv6. Now we have a concrete way >> to tell people in the USA that they have to act and cannot >> delay the change. The IPv4 runout is not like the switch to >> digital TV where you can delay things by legislating it. It's >> like the millenium bug where you have to get stuff fixed now, >> not later. >> > > The DTV delay is a very bad sign for the v6 migration. It indicates that politicians in the US are so fearful of the possibility that people will be stranded when analog is shut off that they are willing to maintain very costly "dual stack" equivalents (broacasting on two channels) for another 6 months (or more). It indicates that after 13 years of planning for this transition no one has any confidence that it will work when we actually pull the trigger. > > Yes, as Dillon there is says one critical difference: broadcasting is a highly regulated industry with an overlay of political control and responsibility lodged directly in governments. (This hierarchical, political form of control has done as much to delay the transition as hasten it, as anyone familiar with the politics of U.S. broadcasting knows.) > > But anyone who thinks that this somehow demonstrates that we should laugh in the face of v4 address runout and that running into a brick wall will somehow facilitate a smooth and effective transition, is being irresponsible. What the DTV case really indicates is that such migrations are complex, unpredictable and difficult to manage. Anyone who imposes an artificial constraint on that migration, such as not fully utilizing underutilized v4 addresses in the vain hope that this will "force" people to behave the way they want them to behave, is playing a game of chicken. Who will be responsible when the internet gets into the crash? Some guy on a listserv who urged ARIN to speed up as it approached the brick wall? > > Do you think politicians will remain on the sidelines when the game of chicken results in a smash-up? > It's not entirely a matter of confidence. Irrespective of all the DTV transition ads, people have no clue it means, don't want to get a box, don't think they need a box, or don't want the government telling them they should change. There's no apparent value in getting a box right now when as far as they can see their TV still works fine. ~Seth _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Thu Jan 29 15:14:55 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 29 Jan 2009 12:14:55 -0800 Subject: [arin-ppml] Why are ISPs allowed? In-Reply-To: References: <124AA6D10AFE4D53AEA5EFEFEE36FADD@GIH.CO.UK> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Olivier MJ > Crepin-Leblond > Sent: Wednesday, January 28, 2009 4:07 PM > To: Gene Buckle; arin-ppml at arin.net > Subject: Re: [arin-ppml] Why are ISPs allowed? > > > > >> Try running Mac OSX on a Mac Plus. (I've tried and failed) > > See above. I don't know what the last release of MacOS was that > > supported the Plus, but it may have TCP/IP support and maybe NSCA > > Mosaic. Not sure. > > It used to work using Telnet, Gopher, WAIS, etc. I never > tried with Mosaic but... > many web sites now reject NSCA Mosaic & other early browsers. > Pages just hang - because so much unrecognised information is > now present. > :-( > I always love a good divergence! ;-) Officially, MacOS X never ran on any 68k gear without a FPU (like the Plus) your talking System 7 here. And the 68k Mac systems can still be made to browse the Internet by using iCab 3.X: http://www.icab.de/ iCab 2.2.9 will run on MacOS 7.5 Unofficially, you an emulate a PPC on a 68k Mac, here's a guy who did it on his Centris: http://mactalk.com.au/articles/68kpanther/ I love the line: "...That's around 4000 times slower than the Athlon boots, and since that takes roughly 2 and a half minutes - I'm looking at at least 6.99 days. One week to boot!..." NetBSD will also boot may older 68k Macs: http://www.macbsd.com/macbsd/macbsd-docs/machine-status/ as will Linux 68k. Assuming you can get X to run you could build whatever browser you want. It would be painfully slow, but this would be for amusement value only. You know, your not a real geek unless you have at one time in your life, run NCSA Telnet on a PC XT with an ethernet card in it to log in into a real system... ;-) Some gear, though, is apparently NEVER obsoleted - ponder the dichotomy of websites like the following: http://www.tubedepot.com/ Ted From michael.dillon at bt.com Thu Jan 29 16:42:28 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 29 Jan 2009 21:42:28 -0000 Subject: [arin-ppml] DTV and IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D70F4961B1@SUEX07-MBX-04.ad.syr.edu> Message-ID: > But anyone who thinks that this somehow demonstrates that we > should laugh in the face of v4 address runout and that > running into a brick wall will somehow facilitate a smooth > and effective transition, is being irresponsible. I agree. Good thing that I was not laughing in the face of anything. In fact, I was pointing out that IPv4 addresses will runout. There is no sign that the global Internet growth is slowing down. This means that organizations who depend on continued growth of their part of the Internet, must act to deploy IPv6, even if they only do that to recover IPv4 addresses to use in the parts of their network where they plan to delay upgrading. As far as smooth and effective transitions go, we gave up that option some years ago. The only way that we are going to dig ourselves out of the IPv4 mess is painfully in the midst of technical and economic chaos. The die is cast, now we must act. > What the > DTV case really indicates is that such migrations are > complex, unpredictable and difficult to manage. You are preaching to the converted here. Most of us have lots of experience with migrations and have seen the disruption and bloodletting up close. > Anyone who > imposes an artificial constraint on that migration, such as > not fully utilizing underutilized v4 addresses in the vain > hope that this will "force" people to behave the way they > want them to behave, is playing a game of chicken. IP addressing and routing is designed to waste addresses favour of structured topology. Vain hope comes from those who want to fully utilise something that has been designed and deployed to NOT EVER be fully utilised. There is a bottom line here, and that is capex and opex. You cannot get something for nothing. Running a business or a network closer to the cliff edge costs more in opex to monitor things closely and act quickly when problems arise. Or you could cut your opex costs by investing capex to give your business or network some elbow room. IPv6 is a capex investment that will pay dividends for many, many years. Trying to optimize IPv4 use in some way may also involve some capex but it also drives up opex costs which will cut your profits for many, many years. Look at what the big ISPs are all doing. They aren't sitting around waiting for the axe to fall. They have all begun the capex investment in IPv6 tests and trials. They are gearing up and preparing for thr transition to IPv6 because they are all run by business people who understand the importance of minimizing downside risk. All the IPv4 optimization strategies come with a large downside risk and that is why the folks holding the pursestrings are not going that way. --Michael Dillon From tedm at ipinc.net Thu Jan 29 16:52:15 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 29 Jan 2009 13:52:15 -0800 Subject: [arin-ppml] DTV and IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D70F4961B1@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D70F4961B1@SUEX07-MBX-04.ad.syr.edu> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller > Sent: Thursday, January 29, 2009 8:25 AM > To: ARIN-PPML at arin.net > Subject: [arin-ppml] DTV and IPv6 > > > > -----Original Message----- > > > This is an excellent event for IPv6. Now we have a concrete way to > > tell people in the USA that they have to act and cannot delay the > > change. The IPv4 runout is not like the switch to digital > TV where you > > can delay things by legislating it. It's like the millenium > bug where > > you have to get stuff fixed now, not later. > > > > The DTV delay is a very bad sign for the v6 migration. It > indicates that politicians in the US are so fearful of the > possibility that people will be stranded when analog is shut > off that they are willing to maintain very costly "dual > stack" equivalents (broacasting on two channels) for another > 6 months (or more). It indicates that after 13 years of > planning for this transition no one has any confidence that > it will work when we actually pull the trigger. > No that isn't what it means. The failure of the HDTV transition in the US cannot be understood without understanding the impact of the US Government's $40 coupon/converter box program, and why that program is such a failure. And it contains a lesson for us for the IPv6 switch. The coupon box program failed in 4 major ways: 1) It ran out of money too early. They stopped issuing coupons in January 2009 a month before the actual conversion. I understand that included in the proposed economic stimulus bill is more money for this program, which is likely part of the reason for the delay. The program was funded by sales of the VHF spectrum and the government got billions for that - and only allocated a miserable amount of this to the program. 2) Coupons were for a fixed amount of $40 that could ONLY be spent on certified converter boxes. HOWEVER all that a person really needs is conversion of the signal from digital to analog - and that can be performed by MANY devices OTHER than just a converter box. A MUCH MORE LOGICAL purchase than a converter box would have been a purchase of a DVR/DVD player with HD tuner and analog outputs - such as for example the LG Electronics model LST-3510a. For citizens who wished to use the $40 coupon to OFFSET the purchase of a more expensive device, they should have been allowed to do it. Citizens should also have been permitted to COMBINE the 2 coupons to purchase a more expensive device AS LONG AS it converted from digital signal to analog. OR to purchase a brand new HDTV set. Remember the HDTV switch obsoleted millions of VCRs too - unless your going to record the inferior converted signal. The government ASSUMED that retailers and manufacturers would provide converter boxes that were MUCH CHEAPER than the $40 so as to be able to not have to pay out the full $40 per coupon. This showed extreme naievity in how retail works. It is only now, AFTER the coupon program has run out of money and no new $40 coupons are being issued, that the retailers are actually discounting below $40. Any smart consumer could have told you that would happen. Furthermore, virtually everyone who participated in the converter box program bought their 2 converter boxes. A LARGE NUMBER of people who have cable or satellite or new HDTV's who didn't even need the converters went and participated in the program anyway - because they figured once they got their $9.95 converter box, they could turn around and sell it for $30 or so. Check out Craigslist - there's tons of new converter boxes for sale right now. The effect of the government pushing converter boxes instead of simply giving everyone a choice to use the $80 to help buy a new TV set (Target is selling $119.00 HDTVs right now, in fact) or DVR player was to flood the country with converter boxes. More about this later. 3) The coupons COULD NOT be used to purchase antennas. Most HDTV stations broadcast on UHF and most analog on VHF so anyone in a rural area or poor-signal area had an outside antenna - and most of these were VHF antennas. And the HDTV UHF band is slightly larger than the analog UHF band so older UHF antenna designs have to be slightly retuned for optimal reception (they work fine in the city with stronger signal, though) All the HDTV advertising is watered down to be useless since it's one-size-fits-all. The ads come on and tell you to get ready for the switch but they don't tell you what retailers are selling converters, or even what a converter box is or what it looks like. And they say you MIGHT need a new TV antenna - in reality you WILL need a new antenna - and they don't show you a picture of what antenna to get. So, now there's a huge trade on unscruplous manufacturers selling powered indoor set-top HDTV antennas that merely amplify noise instead of collecting more usable signal. So a lot of people are buying these at $60 a pop and finding out they don't work then replacing them with a passive dual bow-tie channel master or something for $40. It would have been better for the advertising to show a dual or stacked bow-tie HDTV antenna. Instead the advertising refers people to antennaweb.org that just shows you how to aim it which is utterly STUPID - bow-tie antennas ARE NOT DIRECTIONAL unless they are mounted in front of a reflector! And in most cities the HDTV stations are scattered around so a city resident DOES NOT EVEN WANT a directional HDTV antenna!!!! bow-tie UHF antennas have been around for years and patents on them have long ago run out - which is why they are cheap - and people can make indoor ones with coat hangars if they want that work great - plans are on the Internet. 4) There were big distribution problems with the coupons. They didn't send them to PO boxes - so a lot of poor people who live in apartments, who are the people who really would have benefited more from the coupons - couldn't get them. Some people reported getting the coupons in the mail a week before the coupon expired. And many people who got coupons early couldn't find a retailer local to them that sold the converter boxes, and so the coupon ended up expiring. The coupons had 90 day expirations on them. Those reasons are why that program was a failure. Probably the worst of all of this is that since they decided to go the converter box route is that they set HDTV deployment back MANY years. These converter boxes are simple devices with no moving parts so they are going to last - within 2 years your going to see the secondary market saturated with converter boxes. That will simply make it so that nobody will be throwing away obsolete technology TV sets. We are going to end up with millions of Americans who take the cheap way out - get the $49.95 converter box that costs $9.95 with the coupon - and plug that into a crappy TV with horrible resolution. It will GREATLY delay TV show producers from moving to full-width HDTV broadcasts so everyone who spends the money on a decent HDTV set is going to be screwed since they won't be seeing full-width TV programs for years - meanwhile the broadcasters had to spend all the money on broadcast gear that WOULD do full-width TV shows. Even commercials - you would think when an advertiser is paying gazillions of dollars a minute for a TV commercial that they would want to utilize every scrap of screen real estate - but there are very few TV commercials in HD. Unbelievable! > Yes, as Dillon there is says one critical difference: > broadcasting is a highly regulated industry with an overlay > of political control and responsibility lodged directly in > governments. (This hierarchical, political form of control > has done as much to delay the transition as hasten it, as > anyone familiar with the politics of U.S. broadcasting knows.) > The politicians did not want to be critized for sending millions of pounds of lead into the nation's landfills by basically telling everyone to go out and scrap their TV and buy a new TV. What this ignores is that those TV's are going to eventually fail and be scrapped out anyway. That is why they focused on the converter box program. The principle lesson we can take from this is that with the IPv6 switchover, the VERY BEST way to do it would be to simply tell everyone to scrap out their older IPv4-only gear. Sure, there will be some screams. Sure there will be some wack jobs complaining about filling landfills. But any attempt to accommodate IPv4 merely hampers forward progress on IPv6 which screws over the responsible people who do what they are supposed to and spend the money on IPv6 gear. And for most people, the costs to going to IPv6 really are not high at all. Ted From ocl at gih.com Thu Jan 29 17:38:58 2009 From: ocl at gih.com (Olivier MJ Crepin-Leblond) Date: Thu, 29 Jan 2009 23:38:58 +0100 Subject: [arin-ppml] DTV and IPv6 References: Message-ID: wrote: > Look at what the big ISPs are all doing. They aren't sitting around > waiting for the axe to fall. They have all begun the capex > investment > in IPv6 tests and trials. Absolutely - and from the BGP allocations & doing some trace routing around, I was impressed about the extent of the backbone networks already deployed, with some players strategically positioning themselves now. They're keeping quiet about it, but they're there looking to capture a big chunk of tomorrow's network - and the experience they are gaining as we speak is likely to cause a few upsets in the future for those ISPs not currently involved. O. From mueller at syr.edu Thu Jan 29 18:17:57 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 29 Jan 2009 18:17:57 -0500 Subject: [arin-ppml] DTV and IPv6 In-Reply-To: References: <75822E125BCB994F8446858C4B19F0D70F4961B1@SUEX07-MBX-04.ad.syr.edu> Message-ID: <75822E125BCB994F8446858C4B19F0D70F45F2AA@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > > The DTV delay is a very bad sign for the v6 migration. It > > indicates that politicians in the US are so fearful of the > > possibility that people will be stranded when analog is shut > > off that they are willing to maintain very costly "dual > > stack" equivalents (broacasting on two channels) for another > > 6 months (or more). It indicates that after 13 years of > > planning for this transition no one has any confidence that > > it will work when we actually pull the trigger. > > > > No that isn't what it means. As far as I can tell, nothing in your detailed exposition of the DTV coupon program contradicts anything said above. Yes, the govt ran out of coupons and that coupon program had some poorly designed elements. Thus, as I said, they feared that when they pulled the trigger lots of people would not be ready. I am not exactly sure what your point is. Why the coupon program was chosen is an interesting story we need not go into here, but the explanations are mostly political. And by the way this is not the first delay, there were others before the coupon program was even created. But we all appreciate your research into the DTV coupon program. By the way, this is not a HDTV transition it is a DTV transition. > The politicians did not want to be critized for sending millions > of pounds of lead into the nation's landfills by basically > telling everyone to go out and scrap their TV and buy a new TV. > What this ignores is that those TV's are going to eventually fail > and be scrapped out anyway. That is why they focused on the > converter box program. Indeed, I think "the politicians" were pretty good judges in this case of what their constituents want to hear and want to be done. > The principle lesson we can take from this is that with the > IPv6 switchover, the VERY BEST way to do it would be to simply > tell everyone to scrap out their older IPv4-only gear. Yah. Right. You tell 'em. From heather.skanks at gmail.com Fri Jan 30 11:57:28 2009 From: heather.skanks at gmail.com (heather skanks) Date: Fri, 30 Jan 2009 11:57:28 -0500 Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks to Regional Internet Registries In-Reply-To: <4979ED1D.9050403@arin.net> References: <496CE869.7010902@arin.net> <4979ED1D.9050403@arin.net> Message-ID: <616812070901300857p6657c119u13316da24e574f4a@mail.gmail.com> I don't really have an opinion as to whether the concept is good/worthwhile yet - but I have a lot of concerns about how this would work, what the repercussions could be and whether it is worth it. As written, I'm currently opposed to this policy. Here's a run down of my questions/concerns. It is not clear whether it is mandatory that RIR's proactively recover space, but it sounds as though it is mandatory that recovered space be turned over to IANA. Is this a conflict? Does this create a dis-incentive to recover space? If address space is returned to an RIR, and they have an immediate need for that space, can they assign it? or *must* they wait for the quarterly interval and return it to IANA? IMO, they shouldn't be forced to return it if they have requests within their region that could be met by reassigning the recovered space. Does this have the potential to break/change rDNS delegations? Geo-location stuff? RPKI? What effect would this have on the RIR's db's? How much work would it be on staff and the db's to break up their aggregates in order to return something? What does this do to aggregation? How will preferences to aggregation be made? It sounds like first come, first serve.. gets the most aggregated prefixes. It sounds as though you can't return space after phase1, is this correct? Intentional? Whatever space starts in the queue by definition could be depleted in 1 year, if each RIR makes a request each 6 months. Is it worth it to extend the "free pool" for one year? Especially if there is no incentive/proactive process to recover space? If RIR's can reassign returned space until the quarterly interval, there may be little if anything to return to IANA. I think this policy doesn't really do anything to extend the free pool or soften the blow of depletion. I imagine there would be the least amount of address space in the queue the first year when it is most needed. If a mechanism to return space after phase 1 existed - the amount of space to delegate could go up - but probably wouldn't for several years, until IPv6 adoption took hold. --Heather On Fri, Jan 23, 2009 at 11:15 AM, Member Services wrote: > > The shepherds from the ARIN Advisory Council for this proposal are Scott > Leibrand and Marla Azinger. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > Member Services wrote: > > ARIN received the following global policy proposal. In accordance with > > the ARIN Policy Development Process, the proposal is being posted to the > > ARIN Public Policy Mailing List (PPML). > > > > This proposal is in the first stage of the ARIN Policy Development > > Process. ARIN staff will perform the Clarity and Understanding step. > > Staff does not evaluate the proposal itself at this time, their only aim > > is to make sure that they understand the proposal and believe that the > > community will as well. Staff will report the results of this step to > > the ARIN Advisory Council (AC) within 10 days. > > > > The AC will review this proposal at their next regularly scheduled > > meeting (if the period before the next regularly scheduled meeting is > > less than 10 days, then the period may be extended to the subsequent > > regularly scheduled meeting). The AC will decide how to utilize the > > proposal. The decision will be announced to 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 Policy Development Process can be found at: > > http://www.arin.net/policy/pdp.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: Allocation of IPv4 Blocks to Regional Internet > > Registries > > > > Proposal Originator: > > > > This proposal was developed by a team consisting of persons from each of > > the 5 RIRs. > > > > Adiel A. Akplogan" AfriNIC > > > > Raul Echeberria LACNIC > > > > MAEMURA Akinori APNIC > > > > Axel Pawlik RIPE NCC > > > > Ray Plzak ARIN > > > > Oscar A. Robles-Garay" LACNIC > > > > Nigel Titley RIPE NCC > > > > Paul Wilson APNIC > > > > Proposal Version: 1.0 > > > > Date: 13 January 2009 > > > > Proposal type: New > > > > Policy term: Permanent > > > > Policy statement: > > > > This document describes the policy governing the allocation of IPv4 > > address space from the IANA to the Regional Internet Registries (RIRs). > > This document does not stipulate performance requirements in the > > provision of services by IANA to an RIR in accordance with this policy. > > Such requirements should be specified by appropriate agreements among > > the RIRs and ICANN. > > > > This policy is to be implemented in two phases. > > > > A. Phase I: Recovery of IPv4 Address Space > > > > Upon ratification of this policy by the ICANN Board of Directors the > > IANA shall establish a mechanism to receive IPv4 address space which is > > returned to it by the RIRs, and hold that address space in a 'recovered > > IPv4 pool'. > > > > Each RIR through their respective chosen policies and strategies may > > recover IPv4 address space which is under their administration. Each RIR > > shall at quarterly intervals return any such recovered address space to > > the IANA in aggregated blocks of /24 or larger, for inclusion in the > > recovered IPv4 pool. > > > > During Phase I, no allocations will be made from the recovered IPv4 pool. > > > > B. Phase II: Allocation of Recovered IPv4 address space by the IANA > > > > Upon ratification of this policy by the ICANN Board of Directors and a > > declaration by the IANA that its existing free pool of unallocated IPv4 > > addresses space is depleted; Global Addressing Policy ASO-001-2 (adopted > > by ICANN Board 8 April 2005) is rescinded. IANA will then commence to > > allocate the IPv4 address space from the recovered IPv4 pool. > > > > 1. Allocation of IPv4 Address Space > > > > a. For the purposes of this policy, an 'IPv4 allocation period' is > > defined as a 6-month period following 1 March or 1 September in each year. > > > > b. At the beginning of each IPv4 allocation period, the IANA will > > determine the 'IPv4 allocation unit' for that period, as 1/10 of its > > IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary. > > > > c. In each allocation period, each RIR may issue one IPv4 request to the > > IANA. Providing that the RIR satisfies the allocation criteria > > described in paragraph B.2, the IANA will allocate a single allocation > > unit, composed of the smallest possible number of blocks available in > > its IPv4 address pool. > > > > 2. IPv4 Address Space Allocation Criteria > > > > A RIR is eligible to receive additional IPv4 address space from the IANA > > when the total of its IPv4 address holdings is less than 50% of the > > current IPv4 allocation unit, and providing that it has not already > > received an IPv4 allocation from the IANA during the current IPv4 > > allocation period. > > > > 3. Initial Allocation of IPv4 Address Space > > > > Each new RIR shall, at the moment of recognition, be allocated one (1) > > allocation unit by the IANA. If an allocation unit is not available, > > then the IANA will issue this block as soon as one is available. This > > allocation will be made regardless of the newly formed RIR's projected > > utilization figures and shall be independent of the IPv4 address space > > that may have been transferred to the new RIR by the already existing > > RIRs as part of the formal transition process. > > > > 4. Reporting > > > > a. All returned space is to be recorded in an IANA-published log of IPv4 > > address space transactions, with each log entry detailing the returned > > address block, the date of the return, and the returning RIR. > > > > b. All allocated space is also to be recorded in this IANA-published log > > of IPv4 address space transactions, with each log entry detailing the > > address blocks, the date of the allocation and the recipient RIR. > > > > c. The IANA will maintain a public registry of the current disposition > > of all IPv4 address space, detailing all reservations and current > > allocations and current IANA-held address space that is unallocated. > > > > d) The IANA may make public announcements of IPv4 address block transactions > > that occur under this policy. The IANA will make appropriate > > modifications to the "Internet Protocol V4 Address Space" page of the > > IANA website and may make announcements to its own appropriate > > announcement lists. The IANA announcements will be limited to which > > address ranges, the time of allocation and to which Registry they have > > been allocated. > > > > Rationale: > > > > With the depletion of the IANA free pool of IPv4 address space, the > > current policy regarding the allocation of IPv4 address space to the > > RIRs will become moot. The RIRs may, according to their individual > > policies and procedures, recover IPv4 address space. This policy > > provides a mechanism for the RIRs to retro allocate the recovered IPv4 > > address space to the IANA and provides the IANA the policy by which it > > can allocate it back to the RIRs on a needs basis. This policy creates a > > new global pool of IPv4 address space that can be allocated where it is > > needed on a global basis without a transfer of address space between the > > RIRs. > > > > > > Timetable for implementation: > > > > This policy is to be implemented immediately upon ratification by the > > ICANN Board of Directors according to the global policy process > > described in the ASO MoU. > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From randy at psg.com Fri Jan 30 12:33:02 2009 From: randy at psg.com (Randy Bush) Date: Sat, 31 Jan 2009 02:33:02 +0900 Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks to Regional Internet Registries In-Reply-To: <616812070901300857p6657c119u13316da24e574f4a@mail.gmail.com> References: <496CE869.7010902@arin.net> <4979ED1D.9050403@arin.net> <616812070901300857p6657c119u13316da24e574f4a@mail.gmail.com> Message-ID: [ also not particularly for this policy, bureaucratic flim flam ] > I think this policy doesn't really do anything to extend the free > pool or soften the blow of depletion. agree, but wish to borrow your hammer to drive the sad nails of reality once again. nothing will literally extend the free pool. small finite cardinals are funny that way (there are no negative ip addresses:). we are dealing with a finite resource which folk consume in large amounts, and we are getting near the end of it. there is nothing that will soften that blow. the only policies of which i am aware which provide any real longevity in ipv4 space are based on extreme rationing, e.g. apnic prop-0062 and it's sibling being worked on in ripe. randy From tedm at ipinc.net Fri Jan 30 14:55:23 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 30 Jan 2009 11:55:23 -0800 Subject: [arin-ppml] DTV and IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D70F45F2AA@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D70F4961B1@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D70F45F2AA@SUEX07-MBX-04.ad.syr.edu> Message-ID: <98C8B8A7540842D592974548CC94B07D@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller > Sent: Thursday, January 29, 2009 3:18 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] DTV and IPv6 > > > > -----Original Message----- > > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > > > The DTV delay is a very bad sign for the v6 migration. It > indicates > > > that politicians in the US are so fearful of the possibility that > > > people will be stranded when analog is shut off that they are > > > willing to maintain very costly "dual stack" equivalents > > > (broacasting on two channels) for another > > > 6 months (or more). It indicates that after 13 years of > planning for > > > this transition no one has any confidence that it will > work when we > > > actually pull the trigger. > > > > > > > No that isn't what it means. > > As far as I can tell, nothing in your detailed exposition of > the DTV coupon program contradicts anything said above. Yes, > the govt ran out of coupons and that coupon program had some > poorly designed elements. Thus, as I said, they feared that > when they pulled the trigger lots of people would not be > ready. I am not exactly sure what your point is. > > Why the coupon program was chosen is an interesting story we > need not go into here, but the explanations are mostly > political. And by the way this is not the first delay, there > were others before the coupon program was even created. Yes there were but I don't consider those delays failures because they were delays created many months before the transition date - not at the 11th hour. It's like when in 1994 we say "IPv4 will run out in 2000" then in 1998 we say "oops, IPv4 will run out in 2005" and so on. In short, those are not failures, those are merely reworking of a master plan that is mostly not executed. > But > we all appreciate your research into the DTV coupon program. > There are many parallels to this deployment that are very applicable. I don't understand why your sneering at it. Perhaps because it is clear that the HDTV transition is going to happen, will work, and will break a few eggs but go forward anyway, your afraid of drawing parallels? > By the way, this is not a HDTV transition it is a DTV transition. > Claiming this is merely a DTV transition is disingenuous - no plans ever existed to transition NTSC formats to digital. Analog HDTV was demonstrated back in 1969 in Japan, the first HDTV demonstration was held in the US in 1981. The problem was that the larger bandwidth required for analog HDTV would have necessitated either reslicing up VHF to make larger channels with less channel separation, or going to UHF and abandoning VHF, all of which were considered too left-field to do more than just speculate over. The movement to go HDTV didn't get steam up until digital broadcasting became a reality - and that didn't happen until the silicone was fast and cheap enough to implement affordable video compressors, and the industry standardized on mpeg-2 derivitaves. It was similar to the alternatives to IPv4 that were proposed years ago - such as the aborted RFC 1190 (IPv5). It wasn't until everyone had standardized on what IPv6 would constitute that IPv6 began to gain traction. > > > The politicians did not want to be critized for sending millions of > > pounds of lead into the nation's landfills by basically telling > > everyone to go out and scrap their TV and buy a new TV. > > What this ignores is that those TV's are going to > eventually fail and > > be scrapped out anyway. That is why they focused on the > converter box > > program. > > Indeed, I think "the politicians" were pretty good judges in > this case of what their constituents want to hear and want to > be done. > In MANY matters of public policy there is this see-saw back and forth of what is best for the individual NOW, and what is best for the society IN THE LONG RUN. HDTV is one of these, as is IPv6. For the majority of people, TV is a pointless, mindless exercise, and it makes no difference if they are ruining their intellect watching episodes of "The View" and "Lost" in high-definition or in NTSC, instead of reading a book. For the majority of people, suring the web is a pointless exercise that is mostly used to view porno and post mindless drivel to mailing lists, and it makes no difference if they are ruining their intellect downloading episodes of "The View" and "Lost" over IPv4 instead of IPv6. Of course, freeing up the VHF spectrum may ultimately allow things like reliable wireless Internet that may help that majority of people sometime in the future. That's not NOW. Of course, allowing billions of additional IP addresses on the Internet may ultimately allow things like IP addresses on your refrigerator, which may help that majority of people sometime in the future. That's not NOW. Thus, any movement to a different TV standard that will obsolete existing TV sets is a bad thing NOW even though it may be a good thing IN THE LONG RUN. Similarly, any movement to IPv6 is a bad thing NOW for most people since they have to spend money to accommodate it - even though IN THE LONG RUN it will be better. Kapeesh? ;-) In the US the general politicians in Congress are mostly ignoramuses, who are told which way to vote on things by the bureaucrats and business lobbies. When HDTV became a reality it was something that the TV industry and the FCC worked out, quietly, and the general ignoramuses in Congress were almost certainly unaware of it. When the FCC and industry were ready, they went to Congress and got it voted in. When the delays came down a few years ago, that was industry and FCC telling congress what to do. This is what WE are doing - ARIN is going to tell the ignoramuses in Congress what to do and the sheeple will do it. The proposal your seeing now to delay it, is the general ignoramuses (like Gene Kimmelman of the Consumers Union) becoming aware that there's a problem - because the general population is suddenly realizing HDTV is bad for them NOW. The general population does NOT give a damn what is good for them IN THE LONG RUN. Undoubtedly, the ignoramuses in Congress will also start bleeting in panic the day the last IPv4 number is assigned and their constituents start having to spend real money on switching to IPv6. It remains to be seen how this plays out. Repsonsible politicians need to "take the heat" and do what is best IN THE LONG RUN. President Barak Obama has made this very clear with his initative forcing the US auto industry to go to electric cars (through allowing regulations through on emissions) because IN THE LONG RUN it will be better for the US if the US loses it's dependence on foreign oil. But, there is no way for the general population in the US to make the transition to EVs without increased short term expense - so, moving off foreign oil dependence is not something they are EVER going to want to do NOW no matter how much lip service they give it. Ironically it is Obama who pushed the HDTV delay - apparently, it's OK to do the right thing in the long run for electric cars, but it's NOT OK to do the right thing in the long run for HDTV. > > The principle lesson we can take from this is that with the > > IPv6 switchover, the VERY BEST way to do it would be to simply tell > > everyone to scrap out their older IPv4-only gear. > > Yah. Right. You tell 'em. > You are perhaps aware, are you not, that the House voted against extending the DTV/HDTV transition date - and until that vote changes, the delay isn't going to happen? http://blog.wired.com/business/2009/01/house-kills-dig.html Sometimes even sheeple demonstrate enough intelligence to come in out of the rain. I should also mention that many US TV stations have announced that they will be making the change on Feb. 17th, even if the federal government does extend the change deadline. Here's a link to the article for the city I live in - all tv stations are shifting on the 17th, regardless: http://www.oregonlive.com/business/oregonian/index.ssf?/base/business/123328 950331610.xml&coll=7 As I said, regardless of the screamers, you just go ahead and do it. Other, cooler heads in the television industry are figuring this out right now. Ted From mueller at syr.edu Fri Jan 30 15:54:51 2009 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 30 Jan 2009 15:54:51 -0500 Subject: [arin-ppml] DTV and IPv6 In-Reply-To: <98C8B8A7540842D592974548CC94B07D@tedsdesk> References: <75822E125BCB994F8446858C4B19F0D70F4961B1@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D70F45F2AA@SUEX07-MBX-04.ad.syr.edu> <98C8B8A7540842D592974548CC94B07D@tedsdesk> Message-ID: <75822E125BCB994F8446858C4B19F0D70F4961C0@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > > But > > we all appreciate your research into the DTV coupon program. > > > > There are many parallels to this deployment that are very applicable. > I don't understand why your sneering at it. Perhaps because it is I wasn't sneering at it, on the contrary, was quite impressed with the accuracy and detail with which you detailed the coupon program. It just seemed a bit out of place and, as i said, not really adding much to the discussion of ipv6 migration. --MM From gih at apnic.net Fri Jan 30 16:05:07 2009 From: gih at apnic.net (Geoff Huston) Date: Sat, 31 Jan 2009 08:05:07 +1100 Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks to Regional Internet Registries In-Reply-To: References: <496CE869.7010902@arin.net> <4979ED1D.9050403@arin.net> <616812070901300857p6657c119u13316da24e574f4a@mail.gmail.com> Message-ID: I couldn't help noticing:... On 31/01/2009, at 4:33 AM, Randy Bush wrote: > > nothing will literally extend the free pool. small finite > cardinals are funny that way (there are no negative ip addresses:). [...] > > the only policies of which i am aware which provide any real > longevity in ipv4 space are based on extreme rationing, e.g. apnic > prop-0062 and it's sibling being worked on in ripe. If the former assertion is in fact the case, then that contradicts the second assertion, doesn't it. Geoff, speaking for noone, not even myself. From info at arin.net Fri Jan 30 17:46:52 2009 From: info at arin.net (Member Services) Date: Fri, 30 Jan 2009 17:46:52 -0500 Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks to Regional Internet Registries - Revised Message-ID: <4983835C.1030109@arin.net> Policy Proposal (Global) Allocation of IPv4 Blocks to Regional Internet Registries The proposal originator submitted a revised version of the proposal. The proposal will be forwarded to the ARIN Advisory Council for their consideration. The proposal is on the AC's docket for development and evaluation. The ARIN Policy Development Process can be found at: http://www.arin.net/policy/pdp.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: Allocation of IPv4 Blocks to Regional Internet Registries Proposal Originator: This proposal was developed by a team consisting of persons from each of the 5 RIRs. Adiel A. Akplogan AfriNIC Raul Echeberria LACNIC Geoff Huston APNIC MAEMURA Akinori APNIC Axel Pawlik RIPE NCC Ray Plzak ARIN Oscar A. Robles-Garay" LACNIC Nigel Titley RIPE NCC Paul Wilson APNIC Proposal Version: 2.0 Date: 30 January 2009 Proposal type: New Global Policy term: Permanent Policy statement: This document describes the policy governing the allocation of IPv4 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements should be specified by appropriate agreements among the RIRs and ICANN. This policy is to be implemented in two phases. A. Phase I: Recovery of IPv4 Address Space Upon ratification of this policy by the ICANN Board of Directors the IANA shall establish a mechanism to receive IPv4 address space which is returned to it by the RIRs, and hold that address space in a 'recovered IPv4 pool'. Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration. Each RIR shall at quarterly intervals return any such recovered address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. During Phase I, no allocations will be made from the recovered IPv4 pool. B. Phase II: Allocation of Recovered IPv4 address space by the IANA Upon ratification of this policy by the ICANN Board of Directors and a declaration by the IANA that its existing free pool of unallocated IPv4 address space is depleted; Global Addressing Policy ASO-001-2 (adopted by ICANN Board 8 April 2005) is rescinded. IANA will then commence to allocate the IPv4 address space from the recovered IPv4 pool. 1. The following definitions apply to this policy: a. Recovered Address Space. Recovered address space is that address space that is returned to an RIR as a result of any activity that seeks to reclaim unused address space or is voluntarily returned to the RIR or is reclaimed by the RIR as a result of legal action or abuse determination. Recovered address space does not include that address space that is reclaimed because of non-payment of contractual fees whose reclamation date is less than 1 year at the time of the report. b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4 address space held by an RIR to include recovered address space not yet returned less that address space that is committed in accordance with the RIR's reservation policy and practices. 2. Allocation of IPv4 Address Space a. For the purposes of this policy, an 'IPv4 allocation period' is defined as a 6-month period following 1 March or 1 September in each year. b. At the beginning of each IPv4 allocation period, the IANA will determine the 'IPv4 allocation unit' for that period, as 1/10 of its IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary. c. In each allocation period, each RIR may issue one IPv4 request to the IANA. Providing that the RIR satisfies the allocation criteria described in paragraph B.2, the IANA will allocate a single allocation unit, composed of the smallest possible number of blocks available in its IPv4 address pool. 3. IPv4 Address Space Allocation Criteria A RIR is eligible to receive additional IPv4 address space from the IANA when the total of its IPv4 address holdings is less than 50% of the current IPv4 allocation unit, and providing that it has not already received an IPv4 allocation from the IANA during the current IPv4 allocation period. 4. Initial Allocation of IPv4 Address Space Each new RIR shall, at the moment of recognition, be allocated one (1) allocation unit by the IANA. If an allocation unit is not available, then the IANA will issue this block as soon as one is available. This allocation will be made regardless of the newly formed RIR's projected utilization figures and shall be independent of the IPv4 address space that may have been transferred to the new RIR by the already existing RIRs as part of the formal transition process. 5. Reporting a. All returned space is to be recorded in an IANA-published log of IPv4 address space transactions, with each log entry detailing the returned address block, the date of the return, and the returning RIR. b. All allocated space is also to be recorded in this IANA-published log of IPv4 address space transactions, with each log entry detailing the address blocks, the date of the allocation and the recipient RIR. c. The IANA will maintain a public registry of the current disposition of all IPv4 address space, detailing all reservations and current allocations and current IANA-held address space that is unallocated. d) The IANA may make public announcements of IPv4 address block transactions that occur under this policy. The IANA will make appropriate modifications to the "Internet Protocol V4 Address Space" page of the IANA website and may make announcements to its own appropriate announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated. Rationale: This version is the result of clarification questions and comments submitted to the authors by the ARIN staff in accordance with the ARIN Policy Development Process (PDP). Specifically this revision does the following: a. Inserts a new paragraph 1 in Section B and renumbers the subsequent paragraphs. The new paragraph 1 contains the definitions that were crafted in response to several comments by the ARIN staff. b. Corrects a typo noted in the stem paragraph of Section B. Timetable for implementation: This policy is to be implemented immediately upon ratification by the ICANN Board of Directors according to the global policy process described in the ASO MoU. From randy at psg.com Fri Jan 30 19:04:14 2009 From: randy at psg.com (Randy Bush) Date: Sat, 31 Jan 2009 09:04:14 +0900 Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks to Regional Internet Registries In-Reply-To: References: <496CE869.7010902@arin.net> <4979ED1D.9050403@arin.net> <616812070901300857p6657c119u13316da24e574f4a@mail.gmail.com> Message-ID: >> nothing will literally extend the free pool. small finite >> cardinals are funny that way (there are no negative ip addresses:). > >> the only policies of which i am aware which provide any real >> longevity in ipv4 space are based on extreme rationing, e.g. apnic >> prop-0062 and it's sibling being worked on in ripe. > If the former assertion is in fact the case, then that contradicts the > second assertion, doesn't it. no. nothing will literally extend the free pool. it is drawn from a small number of finite cardinals. policies can extend the length of time some of those cardinals can be distributed. but only by distributing the few remaining ones under extreme rationing. now that was not all that hard to understand, was it? randy, foolishly responding when he knows it's an utter waste From tedm at ipinc.net Fri Jan 30 19:25:14 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 30 Jan 2009 16:25:14 -0800 Subject: [arin-ppml] DTV and IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D70F4961C0@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D70F4961B1@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D70F45F2AA@SUEX07-MBX-04.ad.syr.edu> <98C8B8A7540842D592974548CC94B07D@tedsdesk> <75822E125BCB994F8446858C4B19F0D70F4961C0@SUEX07-MBX-04.ad.syr.edu> Message-ID: <097BB06508794398BAD185F3224903F1@tedsdesk> > -----Original Message----- > From: Milton L Mueller [mailto:mueller at syr.edu] > Sent: Friday, January 30, 2009 12:55 PM > To: 'Ted Mittelstaedt'; arin-ppml at arin.net > Subject: RE: [arin-ppml] DTV and IPv6 > > > > -----Original Message----- > > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > > > But > > > we all appreciate your research into the DTV coupon program. > > > > > > > There are many parallels to this deployment that are very > applicable. > > I don't understand why your sneering at it. Perhaps because it is > > I wasn't sneering at it, on the contrary, was quite impressed > with the accuracy and detail with which you detailed the > coupon program. It just seemed a bit out of place and, as i > said, not really adding much to the discussion of ipv6 migration. > Well, we don't CURRENTLY have a "coupon" analogy with the IPv4->IPv6 transition - BUT one could argue that the various proposals on the list to allow "selling" of IPv4 are suspiciously close to this. The "coupon" program was an attempt to funnel compensation to those owning an older TV (since they would have to spend money to upgrade it). The "selling" proposals are similar attempts to funnel compensation to those owning obsolete IPv4 blocks. (since they will have to spend money to upgrade to IPv6) Ted From tvest at pch.net Fri Jan 30 22:30:44 2009 From: tvest at pch.net (Tom Vest) Date: Fri, 30 Jan 2009 22:30:44 -0500 Subject: [arin-ppml] DTV and IPv6 In-Reply-To: <097BB06508794398BAD185F3224903F1@tedsdesk> References: <75822E125BCB994F8446858C4B19F0D70F4961B1@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D70F45F2AA@SUEX07-MBX-04.ad.syr.edu> <98C8B8A7540842D592974548CC94B07D@tedsdesk> <75822E125BCB994F8446858C4B19F0D70F4961C0@SUEX07-MBX-04.ad.syr.edu> <097BB06508794398BAD185F3224903F1@tedsdesk> Message-ID: <49D90EFC-4408-43E1-B63D-E3B26AA4FF68@pch.net> On Jan 30, 2009, at 7:25 PM, Ted Mittelstaedt wrote: > > >> -----Original Message----- >> From: Milton L Mueller [mailto:mueller at syr.edu] >> Sent: Friday, January 30, 2009 12:55 PM >> To: 'Ted Mittelstaedt'; arin-ppml at arin.net >> Subject: RE: [arin-ppml] DTV and IPv6 >> >> >>> -----Original Message----- >>> From: Ted Mittelstaedt [mailto:tedm at ipinc.net] >>>> But >>>> we all appreciate your research into the DTV coupon program. >>>> >>> >>> There are many parallels to this deployment that are very >> applicable. >>> I don't understand why your sneering at it. Perhaps because it is >> >> I wasn't sneering at it, on the contrary, was quite impressed >> with the accuracy and detail with which you detailed the >> coupon program. It just seemed a bit out of place and, as i >> said, not really adding much to the discussion of ipv6 migration. >> > > Well, we don't CURRENTLY have a "coupon" analogy with the IPv4->IPv6 > transition - BUT one could argue that the various proposals on > the list to allow "selling" of IPv4 are suspiciously close to > this. The "coupon" program was an attempt to funnel compensation > to those owning an older TV (since they would have to spend money to > upgrade it). The "selling" proposals are similar attempts to > funnel compensation to those owning obsolete IPv4 blocks. (since > they will have to spend money to upgrade to IPv6) > > Ted A coupon is not fungible; it is a classic example of "inside money" -- can only be used as dictated by the issuer. An instrument like this may be issued with some confidence that the recipients will actually use it as intended, since doing anything else is difficult if not impossible. The analogy would be applicable if surplus IPv4 holders could only be compensated for IPv4 transfers with something like "IPv6 renumbering service credits." Of course there won't be any such restrictions; IPv4 transferors will be compensated by whatever means that they define, typically in "outside money" or something else that permits equal flexibility to use however the recipient might like. IPv6 integration is one possibility, trivially, but there's no reason to assume that's how all (or any) of the proceeds will actually be used. TV