From ocl at gih.com Fri May 1 03:38:17 2009 From: ocl at gih.com (Olivier MJ Crepin-Leblond) Date: Fri, 1 May 2009 09:38:17 +0200 Subject: [arin-ppml] Effect of ARIN's Letters References: <20090430221050.GA15713@ussenterprise.ufp.org><0CA06E8D-6F3B-4158-A2C3-AD9A11BD09C3@isoc.org> Message-ID: <601D86C65A31411B800B6288D628613D@GIH.CO.UK> Tony Valenti writes: What is interesting about the Slashdot post is that they said "there appears to be no business case for IPV6". That's because *today* there isn't. In fact, there will *not* be a business case until lack of IPv4 addresses make it hurt, and believe me it *will* hurt. The lack of a business case stems from the fact that nobody has (yet) come up with a Mathematical equation to forecast pain caused by IPv4 addresses exhaustion. Having discussed IPv4-IPv6 issues at length in various meetings, from ICANN to IETF, to local conferences, I have noticed that there are two schools of thought: a. avoid the pain and invest into IPv6 now b. wait for the pain to make you invest into IPv6 Trouble is, without pain, there is no business case for (a). So let's all wait for the pain to take hold, and you'll see how the business case will appear quickly indeed. The good news is that we're discussing this on the ARIN list, rather than debating policies about IPv4 reclaiming which I personally equate to reclaiming and sharing of crumbs. Nobody's ever survived on crumbs that size. -- Olivier MJ Cr?pin-Leblond, PhD http://www.gih.com/ocl.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Fri May 1 05:04:58 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 1 May 2009 10:04:58 +0100 Subject: [arin-ppml] Effect of ARIN's Letters In-Reply-To: <49FA3088.3040506@utma.com> Message-ID: <28E139F46D45AF49A31950F88C497458E13F1F@E03MVZ2-UKDY.domain1.systemhost.net> > I don't think it's realistic to expect to run V6 only > webservers, Sure it is. Either install your own 6to4 relay so that v4 users can access it, or set up web proxy servers that mediate between v4 and v6. It is quite realistic to use pure v6 web servers today. Google does something like this, but not with v6. They have a proprietary protocol that is used internally in their data centres, and it is only the front end servers that speak IPv4 or IPv6. And let's get really realistic here. If you sit around thinking up reasons why you can't use IPv6 anywhere today, then when you need to get v6 turned on you will not have any experience. And you won't be able to buy in that experience because there will be a shortage of experienced people. The wise move is to start using v6 today, wherever you can. Don't assume that something will not work. Set it up, try it and find out specifically what does not work and why. Then chase the vendors to get that problem fixed. Rinse, repeat, and become an IPv6 expert in the process. > We are all going to be running v4 and v6 in > parallel for quite some time. Why parallel? If you haven't actually deployed IPv6 and tested it, then how do you know that running v6 and v4 in parallel is the right way to go? You don't. > What we need to do is get V6 > and V4 talking with each other, which would make it easy to > turn new customers up on V6 only, and leave existing > customers on V4, for now. The cost savings and ease of > transition would be orders of magnitude better with this model. Exactly! You need to get off your butt and set up 6to4 relays, Teredo servers, NAT-PT boxes, and get testing. The technology is there , now go out and figure out how to best make it work in your network infrastructure. Most of the big ISPs are doing exactly that, even with selected customers on IPv6 because there are a lot of large companies that are also testing and trialing IPv6 internally. --Michael Dillon From michael.dillon at bt.com Fri May 1 05:25:57 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 1 May 2009 10:25:57 +0100 Subject: [arin-ppml] Effect of ARIN's Letters In-Reply-To: <601D86C65A31411B800B6288D628613D@GIH.CO.UK> Message-ID: <28E139F46D45AF49A31950F88C497458E13F9E@E03MVZ2-UKDY.domain1.systemhost.net> >> they said "there appears to be no business case for IPV6". > That's because *today* there isn't. In fact, there will *not* > be a business case until lack of IPv4 addresses make it hurt, > and believe me it *will* hurt. This just isn't true, at least not in Europe. For starters, in the UK, there is an ISP who provides broadband services which support IPv6 . This company clearly sees a business case for IPv6. My own company has customers in several countries in Europe who are buying IPv6 Internet access from us. It's only available in a few limited cities and for special customers right now, but there is a business case or we wouldn't be doing it. In addition, some large companies now include IPv6 in their RFPs, not as a checklist requirement, but because they only want to sign contracts for service with an ISP who is serious about IPv6. For us, the business case is that we can get these contracts for IPv4 services today, because we have a serious plan to deploy IPv6 before the v4 addressing crisis becomes real. I'd like to emphasise this point. The business case for IPv6 is to have a smooth and steady transition through the IPv4 addressing crisis in order to sign contracts for IPv4 services with companies who want to INSURE themselves against problems during the crisis. There is an awful lot of money at stake here. Some people want business models handed to them on a platter so that they can just turn the crank and make money. Today there are no simplistic IPv6 business models like that, but there are definitely revenue-positive business cases to be made for people who can think out of the box. Note that the IPv4 addressing crisis will also not be a simple thing. On the one hand we are running out of v4 and ISPs may not be able to get more addresses, while on the other hand RIR actions may bring the crisis to us sooner than pure numerical analysis would suggest. At the same time, there are transfer policies in place that will attract speculators, regardless of the rules. This will muddy the waters, contributing to the crisis. There are a whole raft of minor and major technical issues with v6 support in certain pieces of hardware and certain software packages. If you lived through the mid 90's with IPv4, you will have an idea of what I mean. Some deployments of v6 will be stable, but others will not due to these technical issues. This also contributes to the crisis. You cannot rely on other people to solve this crisis for you, or make it go away. The only reasonable strategy is to prepare contingency plans today, which includes doing a lot of technical work testing and trialing IPv6. But it also includes planning what products to discontinue in order to recover IPv4 addresses so that the network can continue to grow and sell the more profitable IPv4 products. --Michael Dillon P.S. Some people on this list are confused and think that I speak for some company or other. To be perfectly clear, the above opinions are mine and not the opinions of some company or other. From JOHN at egh.com Fri May 1 05:29:05 2009 From: JOHN at egh.com (John Santos) Date: Fri, 1 May 2009 05:29:05 -0400 Subject: [arin-ppml] Effect of ARIN's Letters In-Reply-To: <28E139F46D45AF49A31950F88C497458E13F1F@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <1090501052542.41551A-100000@Ives.egh.com> On Fri, 1 May 2009 michael.dillon at bt.com wrote: > > I don't think it's realistic to expect to run V6 only > > webservers, > > Sure it is. Either install your own 6to4 relay so that v4 > users can access it, or set up web proxy servers that > mediate between v4 and v6. It is quite realistic to use > pure v6 web servers today. Totally irrelevent to the topic at hand. Either way, you still need a static, routable, externally visible IPv4 address for your web server. > > Google does something like this, but not with v6. They > have a proprietary protocol that is used internally in > their data centres, and it is only the front end servers > that speak IPv4 or IPv6. > > And let's get really realistic here. If you sit around thinking > up reasons why you can't use IPv6 anywhere today, then when > you need to get v6 turned on you will not have any experience. > And you won't be able to buy in that experience because there > will be a shortage of experienced people. The wise move is to > start using v6 today, wherever you can. This isn't a reason why you *can't* use IPv6. It is a reason why you *have to* use IPv4 as well. > > Don't assume that something will not work. Set it up, try it > and find out specifically what does not work and why. Then chase > the vendors to get that problem fixed. Rinse, repeat, and become > an IPv6 expert in the process. > > > > We are all going to be running v4 and v6 in > > parallel for quite some time. > > Why parallel? If you haven't actually deployed IPv6 and tested > it, then how do you know that running v6 and v4 in parallel is > the right way to go? You don't. > > > What we need to do is get V6 > > and V4 talking with each other, which would make it easy to > > turn new customers up on V6 only, and leave existing > > customers on V4, for now. The cost savings and ease of > > transition would be orders of magnitude better with this model. > > Exactly! You need to get off your butt and set up 6to4 relays, > Teredo servers, NAT-PT boxes, and get testing. The technology is > there , now go out and figure out how > to best make it work in your network infrastructure. > > Most of the big ISPs are doing exactly that, even with selected > customers on IPv6 because there are a lot of large companies that > are also testing and trialing IPv6 internally. > > --Michael Dillon -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From Charles.King at dsusd.us Fri May 1 10:44:35 2009 From: Charles.King at dsusd.us (King, Charles) Date: Fri, 1 May 2009 07:44:35 -0700 Subject: [arin-ppml] Bounce Score... charles.king@dsusd.us Message-ID: I noticed, upon logging in to my Arin account for charles.king at dsusd.us, that we have a bounce score of 2. Our apologies for that, it may be that firewall maintenance may have been the issue. You may reset the bounce score to 0 if you like. We continue to do business and our firewalls and mail servers are all up and running. We use the Cisco Ironport product as our anti-spam solution and we seem to be managing our email quite effectively. Thanks Chuck King Supervisor of Computer Network Services Desert Sands Unified School District charles.king at dsusd.us 760-771-8579 Statement of Confidentiality: The contents of this e-mail message and any attachments are intended solely for the addressee. The information may also be confidential and/or legally privileged. This transmission is sent for the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction, or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail and delete this message and its attachments, if any. E-mail is covered by the Electronic Communications Privacy Act, 18 USC SS 2510-2521 and is legally privileged. P Go Green! Print this email only when necessary. Thank you for helping DSUSD be environmentally responsible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Charles.King at dsusd.us Fri May 1 10:46:50 2009 From: Charles.King at dsusd.us (King, Charles) Date: Fri, 1 May 2009 07:46:50 -0700 Subject: [arin-ppml] Bounce Score... charles.king@dsusd.k12.ca.us Message-ID: I noticed, upon logging in to my Arin account for charles.king at dsusd.k12.ca.us , that we have a bounce score of 2. Our apologies for that, it may be that firewall maintenance may have been the issue. You may reset the bounce score to 0 if you like. We continue to do business and our firewalls and mail servers are all up and running. We use the Cisco Ironport product as our anti-spam solution and we seem to be managing our email quite effectively. Thanks Chuck King Supervisor of Computer Network Services Desert Sands Unified School District charles.king at dsusd.us 760-771-8579 Statement of Confidentiality: The contents of this e-mail message and any attachments are intended solely for the addressee. The information may also be confidential and/or legally privileged. This transmission is sent for the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction, or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail and delete this message and its attachments, if any. E-mail is covered by the Electronic Communications Privacy Act, 18 USC SS 2510-2521 and is legally privileged. P Go Green! Print this email only when necessary. Thank you for helping DSUSD be environmentally responsible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Fri May 1 13:01:50 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 1 May 2009 10:01:50 -0700 Subject: [arin-ppml] Effect of ARIN's Letters In-Reply-To: <601D86C65A31411B800B6288D628613D@GIH.CO.UK> References: <20090430221050.GA15713@ussenterprise.ufp.org><0CA06E8D-6F3B-4158-A2C3-AD9A11BD09C3@isoc.org> <601D86C65A31411B800B6288D628613D@GIH.CO.UK> Message-ID: <932A4005699341C597E0787DD1941DF0@tedsdesk> The problem is what do your customers want? As a smaller ISP we can't set policy on the Internet. We aren't bringing customers onboard at the rate of hundreds a day where we can afford to scrape the 2-3 annoying and demanding ones off our shoes. We are concerned about losing even a single customer - it won't break us, but we aren't complacent about it either. As long as there's customers on the Internet that can demand and get routable IPv4 addresses from our competitors, we will have to offer IPv4. We don't have the luxury of a Verizon or a Qwest to be able to look that customer in the eye and say "NO, and nobody else is going to give you one either" and have the customer curse and swear at us but, due to cut-rate pricing or contracts, other bundling and marketing stuff that allows us to lock in that customer, be able to force our will on them. And before you start saying that these large ISPs can't force customers to do anything, I see it happening all the time. All they have to do is cut their monthly rate below ours - and it doesn't take much - and there's a lot of customers out there who will do whatever they tell them to. We have even lost customers to the big guys who ended up paying MORE to the big guys - but went to them solely because they got a unified telephone/internet bill from a single provider, and they had some accountant 2000 miles away paying the bill who wanted it that way. SO, we will be more than happy to 'reclaim and share those crumbs". It will keep us alive for a long enough time for the big guys to start playing hardball with their customers and forcing them to IPv6. Once the big guys start telling their customers NO (or more likely that it will cost them plenty) to get IPv4, then we will be able to raise prices or do whatever it takes to make our customers go to IPv6 as well. Ted _____ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Olivier MJ Crepin-Leblond Sent: Friday, May 01, 2009 12:38 AM To: ppml at arin.net Subject: Re: [arin-ppml] Effect of ARIN's Letters The good news is that we're discussing this on the ARIN list, rather than debating policies about IPv4 reclaiming which I personally equate to reclaiming and sharing of crumbs. Nobody's ever survived on crumbs that size. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george at dmu.edu Fri May 1 13:44:45 2009 From: george at dmu.edu (Davey, George) Date: Fri, 1 May 2009 12:44:45 -0500 Subject: [arin-ppml] Effect of ARIN's Letters In-Reply-To: <932A4005699341C597E0787DD1941DF0@tedsdesk> References: <20090430221050.GA15713@ussenterprise.ufp.org><0CA06E8D-6F3B-4158-A2C3-AD9A11BD09C3@isoc.org> <601D86C65A31411B800B6288D628613D@GIH.CO.UK> <932A4005699341C597E0787DD1941DF0@tedsdesk> Message-ID: The interesting thing is that the big ISPs do not want IPV6 because once the IPV4 addresses run out, they have a monopoly and they love monopolies. The telcos are expressing this desire by their apparent reluctance to IPV6. There is also the expense factor and the non-desire of customers to care about IPV anything. They just want web pages to come up and IPV6 inhibits not helps. The thing for ARIN and ICANN need to do is to set a sunset date by which IPV4 IPs are obsolete and by which the ASN database for them will be purged. Problem is there is no ASN to replace them and that is the flaw in the IPV6 implementational logic. IPv4 will persist until such time. Hopefully they can come up with BGP6 for IPV6 that will host millions of ISPs not just 65,535, and set a sunset date for BGP4 and the current ASN numbers associated with them. This will force a "Gold Rush" and if ARIN was smart instead of just a steward (whatever that is) they would open it back up just like it was 1992 all over again. A whole new crop of ISPs would take part in the Gold Rush. Until then I will grasp my IPV4 blocks until they pry them from my cold dead hands. [cid:image001.gif at 01C9CA59.AC6881C0] George Davey, B.S. MCSE Network Administrator 3200 Grand Avenue Des Moines, IA 50312 515.271.1544 FAX 515.271.7063 CELL 515.480.1605 George.Davey at dmu.edu www.dmu.edu From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Friday, May 01, 2009 12:02 PM To: 'Olivier MJ Crepin-Leblond'; ppml at arin.net Subject: Re: [arin-ppml] Effect of ARIN's Letters The problem is what do your customers want? As a smaller ISP we can't set policy on the Internet. We aren't bringing customers onboard at the rate of hundreds a day where we can afford to scrape the 2-3 annoying and demanding ones off our shoes. We are concerned about losing even a single customer - it won't break us, but we aren't complacent about it either. As long as there's customers on the Internet that can demand and get routable IPv4 addresses from our competitors, we will have to offer IPv4. We don't have the luxury of a Verizon or a Qwest to be able to look that customer in the eye and say "NO, and nobody else is going to give you one either" and have the customer curse and swear at us but, due to cut-rate pricing or contracts, other bundling and marketing stuff that allows us to lock in that customer, be able to force our will on them. And before you start saying that these large ISPs can't force customers to do anything, I see it happening all the time. All they have to do is cut their monthly rate below ours - and it doesn't take much - and there's a lot of customers out there who will do whatever they tell them to. We have even lost customers to the big guys who ended up paying MORE to the big guys - but went to them solely because they got a unified telephone/internet bill from a single provider, and they had some accountant 2000 miles away paying the bill who wanted it that way. SO, we will be more than happy to 'reclaim and share those crumbs". It will keep us alive for a long enough time for the big guys to start playing hardball with their customers and forcing them to IPv6. Once the big guys start telling their customers NO (or more likely that it will cost them plenty) to get IPv4, then we will be able to raise prices or do whatever it takes to make our customers go to IPv6 as well. Ted ________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Olivier MJ Crepin-Leblond Sent: Friday, May 01, 2009 12:38 AM To: ppml at arin.net Subject: Re: [arin-ppml] Effect of ARIN's Letters The good news is that we're discussing this on the ARIN list, rather than debating policies about IPv4 reclaiming which I personally equate to reclaiming and sharing of crumbs. Nobody's ever survived on crumbs that size. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2167 bytes Desc: image001.gif URL: From scottleibrand at gmail.com Fri May 1 13:57:50 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 01 May 2009 12:57:50 -0500 Subject: [arin-ppml] Effect of ARIN's Letters In-Reply-To: References: <20090430221050.GA15713@ussenterprise.ufp.org><0CA06E8D-6F3B-4158-A2C3-AD9A11BD09C3@isoc.org> <601D86C65A31411B800B6288D628613D@GIH.CO.UK> <932A4005699341C597E0787DD1941DF0@tedsdesk> Message-ID: <49FB381E.4060300@gmail.com> George, I'll let others discuss the relative merits of trying to force people to stop using IPv4... It's worth noting, though, that what you are describing as BGP6 is actually already in place, and is called 4-byte (or 32-bit) ASNs. The RIRs are already giving out 4-byte ASNs to organizations that request ASNs, unless they specifically request a 2-byte ASN (which most still do, unfortunately, because router OS support itsn't there yet for many platforms). Also, I don't see any link between the ASN type (2-byte vs. 4-byte) and the IP version (IPv4 vs. IPv6). They just happen to be to different numbering spaces that both have to be expanded at about the same time. -Scott Davey, George wrote: > > The interesting thing is that the big ISPs do not want IPV6 because > once the IPV4 addresses run out, they have a monopoly and they love > monopolies. > > The telcos are expressing this desire by their apparent reluctance to > IPV6. > > There is also the expense factor and the non-desire of customers to > care about IPV anything. They just want web pages to come up and IPV6 > inhibits not helps. > > The thing for ARIN and ICANN need to do is to set a sunset date by > which IPV4 IPs are obsolete and by which the ASN database for them > will be purged. > > Problem is there is no ASN to replace them and that is the flaw in the > IPV6 implementational logic. > > IPv4 will persist until such time. > > Hopefully they can come up with BGP6 for IPV6 that will host millions > of ISPs not just 65,535, and set a sunset date for BGP4 and the > current ASN numbers associated with them. > > This will force a ?Gold Rush? and if ARIN was smart instead of just a > steward (whatever that is) they would open it back up just like it was > 1992 all over again. > > A whole new crop of ISPs would take part in the Gold Rush. > > Until then I will grasp my IPV4 blocks until they pry them from my > cold dead hands. > > > > > < Des Moines University - Osteopathic Medical Center > > > > > > > George Davey, B.S. MCSE > /Network Administrator/ > 3200 Grand Avenue > Des Moines, IA 50312 > 515.271.1544 > FAX 515.271.7063 > > CELL 515.480.1605 > George.Davey at dmu.edu > www.dmu.edu > > > > *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > *On Behalf Of *Ted Mittelstaedt > *Sent:* Friday, May 01, 2009 12:02 PM > *To:* 'Olivier MJ Crepin-Leblond'; ppml at arin.net > *Subject:* Re: [arin-ppml] Effect of ARIN's Letters > > The problem is what do your customers want? > > As a smaller ISP we can't set policy on the Internet. We aren't > bringing customers onboard at the > > rate of hundreds a day where we can afford to scrape the 2-3 annoying > and demanding ones off our > > shoes. We are concerned about losing even a single customer - it won't > break us, but we aren't > > complacent about it either. > > As long as there's customers on the Internet that can demand and get > routable IPv4 addresses from > > our competitors, we will have to offer IPv4. We don't have the luxury > of a Verizon or a Qwest to be > > able to look that customer in the eye and say "NO, and nobody else is > going to give you one either" > > and have the customer curse and swear at us but, due to cut-rate > pricing or contracts, other bundling and > > marketing stuff that allows us to lock in that customer, be able to > force our will on them. > > And before you start saying that these large ISPs can't force > customers to do anything, I see it > > happening all the time. All they have to do is cut their monthly rate > below ours - and it doesn't > > take much - and there's a lot of customers out there who will do > whatever they tell them to. We have > > even lost customers to the big guys who ended up paying MORE to the > big guys - but went to them > > solely because they got a unified telephone/internet bill from a > single provider, and they had some > > accountant 2000 miles away paying the bill who wanted it that way. > > SO, we will be more than happy to 'reclaim and share those crumbs". It > will keep us alive for > > a long enough time for the big guys to start playing hardball with > their customers and forcing > > them to IPv6. Once the big guys start telling their customers NO (or > more likely that it will > > cost them plenty) to get IPv4, then we will be able to raise prices or > do whatever it takes to make > > our customers go to IPv6 as well. > > Ted > > ------------------------------------------------------------------------ > > *From:* arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *Olivier MJ > Crepin-Leblond > *Sent:* Friday, May 01, 2009 12:38 AM > *To:* ppml at arin.net > *Subject:* Re: [arin-ppml] Effect of ARIN's Letters > > The good news is that we're discussing this on the ARIN list, > rather than debating policies about IPv4 reclaiming which I > personally equate to reclaiming and sharing of crumbs. Nobody's > ever survived on crumbs that size. > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 lsc at prgmr.com Fri May 1 14:39:32 2009 From: lsc at prgmr.com (Luke S Crawford) Date: 01 May 2009 14:39:32 -0400 Subject: [arin-ppml] Effect of ARIN's Letters In-Reply-To: <601D86C65A31411B800B6288D628613D@GIH.CO.UK> References: <20090430221050.GA15713@ussenterprise.ufp.org> <0CA06E8D-6F3B-4158-A2C3-AD9A11BD09C3@isoc.org> <601D86C65A31411B800B6288D628613D@GIH.CO.UK> Message-ID: "Olivier MJ Crepin-Leblond" writes: > a. avoid the pain and invest into IPv6 now > b. wait for the pain to make you invest into IPv6 > > Trouble is, without pain, there is no business case for (a). So let's all wait for the pain to take hold, and you'll see how the business case will appear quickly indeed. I think B is the business case for A. Risk mitigation. You know something will change 2-3 years from now. Are you willing to bet the business that Nat Hell will win? Right now, if I screw up my IPv6 connectivity, I get complaints, but I fix it and do a writeup about what happened, and people seem to understand. If I screw up my IPv4 connectivity, people get mad and leave. I want to make all my newbie IPv6 mistakes now, not three years from now. From tedm at ipinc.net Fri May 1 15:10:22 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 1 May 2009 12:10:22 -0700 Subject: [arin-ppml] Effect of ARIN's Letters In-Reply-To: <49FB381E.4060300@gmail.com> References: <20090430221050.GA15713@ussenterprise.ufp.org><0CA06E8D-6F3B-4158-A2C3-AD9A11BD09C3@isoc.org> <601D86C65A31411B800B6288D628613D@GIH.CO.UK> <932A4005699341C597E0787DD1941DF0@tedsdesk> <49FB381E.4060300@gmail.com> Message-ID: > -----Original Message----- > From: Scott Leibrand [mailto:scottleibrand at gmail.com] > Sent: Friday, May 01, 2009 10:58 AM > To: Davey, George > Cc: Ted Mittelstaedt; ppml at arin.net > Subject: Re: [arin-ppml] Effect of ARIN's Letters > > George, > > I'll let others discuss the relative merits of trying to > force people to stop using IPv4... > There's no need to force people to STOP using IPv4, since that implies they already have it. If they already have it then it was assigned to them when it was available. The issue is forcing people who have no connectivity at all and who want to get it, to take IPv6 instead of IPv4. Also, in our politically correct society, it's important to understand that nobody actually SAYS right out that they are forcing anyone to do anything. They just raise prices, or use other means which essentially forces the market, so that they can protest that their hands are clean if anyone accuses them of trying to force anyone to do anything. Ted From spiffnolee at yahoo.com Fri May 1 17:46:06 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Fri, 1 May 2009 14:46:06 -0700 (PDT) Subject: [arin-ppml] Effect of ARIN's Letters In-Reply-To: References: <20090430221050.GA15713@ussenterprise.ufp.org><0CA06E8D-6F3B-4158-A2C3-AD9A11BD09C3@isoc.org> <601D86C65A31411B800B6288D628613D@GIH.CO.UK> <932A4005699341C597E0787DD1941DF0@tedsdesk> Message-ID: <949971.75334.qm@web63302.mail.re1.yahoo.com> I have discussed IPv6 with people from most big ISPs, including telcos, and essentially all of them are planning for IPv6. None of them believes that their IPv4 size will sustain them through the depletion of unassigned IPv4.. Admittedly, some are not as far along as they'd like, either in planning or in capital spending. I don't understand what ASN database you mean, and I don't know how ARIN and ICANN could effect a sunset. Could you suggest details? What problems do you see with BGP with IPv6? It might be appropriate to raise them at the IRTF's Routing Research Group, or in one of the IETF's Routing Area WGs. (Internet search to find them) What do you want ARIN to "open back up"? Do you think the requirements for an IPv6 allocation or 32-bit ASN are too strict? What would you propose? Lee ________________________________ From: "Davey, George" To: Ted Mittelstaedt Cc: "ppml at arin.net" Sent: Friday, May 1, 2009 1:44:45 PM Subject: Re: [arin-ppml] Effect of ARIN's Letters The interesting thing is that the big ISPs do not want IPV6 because once the IPV4 addresses run out, they have a monopoly and they love monopolies. The telcos are expressing this desire by their apparent reluctance to IPV6. There is also the expense factor and the non-desire of customers to care about IPV anything. They just want web pages to come up and IPV6 inhibits not helps. The thing for ARIN and ICANN need to do is to set a sunset date by which IPV4 IPs are obsolete and by which the ASN database for them will be purged.. Problem is there is no ASN to replace them and that is the flaw in the IPV6 implementational logic. IPv4 will persist until such time. Hopefully they can come up with BGP6 for IPV6 that will host millions of ISPs not just 65,535, and set a sunset date for BGP4 and the current ASN numbers associated with them. This will force a ?Gold Rush? and if ARIN was smart instead of just a steward (whatever that is) they would open it back up just like it was 1992 all over again. A whole new crop of ISPs would take part in the Gold Rush. Until then I will grasp my IPV4 blocks until they pry them from my cold dead hands. George Davey, B.S. MCSE Network Administrator 3200 Grand Avenue Des Moines, IA 50312 515.271.1544 FAX 515.271.7063 CELL 515.480.1605 George.Davey at dmu.edu www.dmu.edu From:arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Friday, May 01, 2009 12:02 PM To: 'Olivier MJ Crepin-Leblond'; ppml at arin.net Subject: Re: [arin-ppml] Effect of ARIN's Letters The problem is what do your customers want? As a smaller ISP we can't set policy on the Internet. We aren't bringing customers onboard at the rate of hundreds a day where we can afford to scrape the 2-3 annoying and demanding ones off our shoes. We are concerned about losing even a single customer - it won't break us, but we aren't complacent about it either. As long as there's customers on the Internet that can demand and get routable IPv4 addresses from our competitors, we will have to offer IPv4. We don't have the luxury of a Verizon or a Qwest to be able to look that customer in the eye and say "NO, and nobody else is going to give you one either" and have the customer curse and swear at us but, due to cut-rate pricing or contracts, other bundling and marketing stuff that allows us to lock in that customer, be able to force our will on them. And before you start saying that these large ISPs can't force customers to do anything, I see it happening all the time. All they have to do is cut their monthly rate below ours - and it doesn't take much - and there's a lot of customers out there who will do whatever they tell them to. We have even lost customers to the big guys who ended up paying MORE to the big guys - but went to them solely because they got a unified telephone/internet bill from a single provider, and they had some accountant 2000 miles away paying the bill who wanted it that way. SO, we will be more than happy to 'reclaim and share those crumbs". It will keep us alive for a long enough time for the big guys to start playing hardball with their customers and forcing them to IPv6. Once the big guys start telling their customers NO (or more likely that it will cost them plenty) to get IPv4, then we will be able to raise prices or do whatever it takes to make our customers go to IPv6 as well. Ted ________________________________ From:arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Olivier MJ Crepin-Leblond Sent: Friday, May 01, 2009 12:38 AM To: ppml at arin.net Subject: Re: [arin-ppml] Effect of ARIN's Letters The good news is that we're discussing this on the ARIN list, rather than debating policies about IPv4 reclaiming which I personally equate to reclaiming and sharing of crumbs. Nobody's ever survived on crumbs that size. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2167 bytes Desc: image001.gif URL: From fred at cisco.com Sat May 2 13:00:56 2009 From: fred at cisco.com (Fred Baker) Date: Sat, 2 May 2009 10:00:56 -0700 Subject: [arin-ppml] Effect of ARIN's Letters In-Reply-To: References: <20090430221050.GA15713@ussenterprise.ufp.org><0CA06E8D-6F3B-4158-A2C3-AD9A11BD09C3@isoc.org> <601D86C65A31411B800B6288D628613D@GIH.CO.UK> <932A4005699341C597E0787DD1941DF0@tedsdesk> <49FB381E.4060300@gmail.com> Message-ID: <87006973-CC36-41F7-9F47-59E7F7F5C015@cisco.com> On May 1, 2009, at 12:10 PM, Ted Mittelstaedt wrote: > The issue is forcing people who have no connectivity at all > and who want to get it, to take IPv6 instead of IPv4. Far more importantly in the near term, to take IPv6 as well as IPv4, and if they have IPv4, to add IPv6. The point will come a few years from now when IPv6-only stares us in the face, but right now it's about being ready when that day comes. As some have said on this list, making the mistakes now instead of then, sorting out address plans now instead of then, and having content online for those folks to view. From marquis at roble.com Sun May 3 15:33:51 2009 From: marquis at roble.com (Roger Marquis) Date: Sun, 3 May 2009 12:33:51 -0700 (PDT) Subject: [arin-ppml] Effect of ARIN's Letters In-Reply-To: References: Message-ID: <20090503193351.84C6B2B21F9@mx5.roble.com> Fred Baker wrote: > On May 1, 2009, at 12:10 PM, Ted Mittelstaedt wrote: >> The issue is forcing people who have no connectivity at all >> and who want to get it, to take IPv6 instead of IPv4. > > Far more importantly in the near term, to take IPv6 as well as IPv4, > and if they have IPv4, to add IPv6. The point will come a few years > from now when IPv6-only stares us in the face, but right now it's > about being ready when that day comes. As some have said on this list, > making the mistakes now instead of then, sorting out address plans now > instead of then, and having content online for those folks to view. Has anyone made a Gantt chart of ways a transition to IPv6 would work? I'd love to see it, especially if it doesn't contain the one pre-requisite which, IMO, appears inevitable: 100% reachability. While a small number of nodes will be able to live with a single protocol, and limited access during a prolonged transition, the rest of us will need to be able to reach hosts which speak either protocol. So a critical path (project management speak) would be predicated on 100% reachability. If you agree with this hypothetical CP there are at least three paths: A) NAT everywhere. IPv4 clients and servers will need an IPv6 gateway and IPv6 clients and servers will need an IPv4 gateway, or B) dual-stack everywhere. Not really everywhere but on all servers and clients, C) NAT everywhere that's not dual-stack. The key here is everywhere, 100% reachability, i.e., D) EVERY CLIENT and EVERY SERVER At least this is how it appears in my imaginary project plan. If there's another way to do this, or something I've missed, please do follow-up. As the IETF appears to be dropping the ball with regards to a NAT standards (for the usual reasons, mainly incumbents hoping to turn a profit on the "shortage") smaller ISPs will likely end up having to do most of the work by implementing dual-stack where possible and nonstandard NAT everywhere else. To that end is there a centralized FAQ: A) listing netgear that supports v4-v6 NAT today, B) Windows, Mac, Linux, Unix dual-stack HowTos, C) a DNS with IPv6 NAT HowTo, and D) list of providers who are already routing IPv6 AND assigning IPv6 addresses along with all IPv4 addresses? Roger Marquis From bicknell at ufp.org Sun May 3 16:13:30 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 3 May 2009 16:13:30 -0400 Subject: [arin-ppml] Effect of ARIN's Letters In-Reply-To: <20090503193351.84C6B2B21F9@mx5.roble.com> References: <20090503193351.84C6B2B21F9@mx5.roble.com> Message-ID: <20090503201330.GA60038@ussenterprise.ufp.org> In a message written on Sun, May 03, 2009 at 12:33:51PM -0700, Roger Marquis wrote: > The key here is everywhere, 100% reachability, i.e., > > D) EVERY CLIENT and EVERY SERVER Nope. While it may be necessary in some enviornments, it is not necessary in all. A couple of quick examples. If I'm a large web site, www.bigname.com, I don't care if one client can talk to another client, just that they all can talk to me. If I dual stack my servers it is unlikely I will care if clients are IPv4 only, IPv6 only, or dual-stacked. There are many protocols, like BitTorrent, that adapt to their enviornment. If you're IPv6 only it will only go to other IPv6 nodes. Users may not notice at all, or they may see slower downloads, or in some cases faster downloads. The key to me is that the servers need to be dual stacked. If all of an ISP's servers were dual stacked (e.g. the mail servers), and all of "big content" was dual stacked a lot of users would work just fine on an IPv6 only connection. That's not to say there aren't hundreds of pitfalls and corner cases; but "EVERY CLIENT and EVERY SERVER", no, not required at all to be useful. -- 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 Sun May 3 17:19:47 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 3 May 2009 17:19:47 -0400 Subject: [arin-ppml] Mighten it happen like this? In-Reply-To: <8E4BFEDAB8434B80A198B89373F2AF1C@tedsdesk> References: <8E4BFEDAB8434B80A198B89373F2AF1C@tedsdesk> Message-ID: <75822E125BCB994F8446858C4B19F0D775EEC301@SUEX07-MBX-04.ad.syr.edu> Nice. You're starting to think like an economist. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Thursday, April 30, 2009 6:06 PM > To: 'ARIN PPML' > Subject: [arin-ppml] Mighten it happen like this? > > > In thinking about this IPv4 runout it occurs to me that it might possible > go something like this. > > After the last /8 is assigned to ARIN, the hostmasters there will get out > their knives and start slicing off subnets from it. A handful of Very > Large > requests will be satisfied from it, then a lot more smaller requests, then > the /8 will be as the turkey is on the platter during the last > Thanksgiving > - > the large breasts gutted but still plenty of edible meat in smaller > chunks. > > Then the reclamation efforts will start turning up even smaller and > smaller > chunks of IPv4 abandonded years earlier - nothing to satisfy the large > consumers, > but still plenty of smaller tasty bits. And in the meantime they will > still > be stripping the carcass of the /8 for the last usable bits. > > Then the carcass will be done and reclamation will be in full swing now - > but > the IPv4 coming in from reclamation will be somewhat less tasty - > ex-spammers > blocks, stinky old swampland that may or may not have been used. > > Then reclamation will start petering off and the IPv4 bits coming in from > it > will be very nasty indeed - blocks with squatters in it that the obtainer > of the block will have to actively evict, blocks where the original > occupier > is still fighting with ARIN over ownership. > > Then they will get down to the nitty-gritty of trying to piece together > minimal > sized blocks to allocate from scattered /24's some of which are > abandonded, > some > not - begging and pleading with owners to please move over to this other > /24 > so > we can use the one your on to aggregate together a larger block. > > Somewhere along the way some kind of transfer market may spring up - short > lived > though it may be, with a few folks making a killing off selling blocks - > but > as > time passes it will die down. > > During this time the number of orgs wanting IPv4 will be decreasing as > more > and more of the requestors give up hope of getting usable IPv4 and more > and > more > of them migrate to IPv6. > > So, perhaps maybe fully 4 years after the last /8 is allocated to ARIN > then > the > very last aggregated subnet of any size will be given out - reclamation > will > be > exhausted, and pretty much nobody will have any hope left of getting IPv4 > allocations > except from the transfer market. That might mark the "official" end of > ARIN-assigned > "free" IPv4. > > The transfer market will be peaking right around now - as prices get so > rediculous > that it becomes cost effective for even the most retrogade networks to go > to > IPv6. > > Then a tipping point will be reached and over a few months the bottom will > drop > out of the transfer market and the market will crash, and we will see the > commencement > of an accellerated schedule of more and more networks dropping IPv4. > > A few years after that then reports will begin to show up of routing > unreliability > of the IPv4 Internet in certain spots on the Internet. > > By 4 years after the "official end" of ARIN-assigned IPv4, we will start > to > see > websites set up with countdown clocks predicting the very last day that > IPv4 > traffic > will exist on the Internet. > > Then, sometime in 2020, some politician will send an e-mail titled > "Goodbye" > at a > ribbon-cutting ceremony that will mark the last time that a real IPv4 > packet > will > be sent over the public Internet from a public client to a public server. > > Around 2025, Cisco will make proficiency in IPv4 an optional part of it's > assesment test. > > Around 2030, Juniper and Cisco will release firmware that won't have IPv4 > support in > the base load. > > Does seem like a realistic end-game? > > Ted > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From info at arin.net Mon May 4 12:11:49 2009 From: info at arin.net (Member Services) Date: Mon, 04 May 2009 12:11:49 -0400 Subject: [arin-ppml] 2009-2 and 2009-4 Abandoned Message-ID: <49FF13C5.7090600@arin.net> The ARIN Advisory Council (AC) met on 29 April 2009 and decided to abandon the following two draft policies: * Draft Policy 2009-2: Depleted IPv4 reserves * Draft Policy 2009-4: IPv4 Recovery Fund The AC met in accordance with the ARIN Policy Development Process which requires the AC to meet within 30 days of the conclusion of the Public Policy Meeting to make decisions about the draft policies that had been presented. These draft policies have been abandoned by the AC. This action may be petitioned. The PDP states, ?Any member of the community, including a proposal originator, may initiate a Last Call Petition if they are dissatisfied with the action taken by the Advisory Council regarding any draft policy. If successful, this petition will move the draft policy to last call discussion and review by the community on the PPML.? The deadline to begin a petition for these draft policies is 8 May 2009. Petitions must include the draft policy text and a petition statement. Once begun, a petition lasts for 5 business days. Success is measured as support from at least 10 different people from 10 different organizations. Should a petition begin, ARIN staff will post additional information. If there are no petitions or petitions fail, then these draft policies will be closed. The text for Draft Policies and Proposals is available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Mon May 4 12:13:59 2009 From: info at arin.net (Member Services) Date: Mon, 04 May 2009 12:13:59 -0400 Subject: [arin-ppml] =?windows-1252?q?2009-3_and_2008-3_to_remain_on_AC=92?= =?windows-1252?q?s_docket?= Message-ID: <49FF1447.8090700@arin.net> The ARIN Advisory Council (AC) met on 29 April 2009 and kept the following two draft policies on the AC?s docket for further development and evaluation: ? Draft Policy 2009-3 (Global): Allocation of IPv4 Blocks to Regional Internet Registries ? Draft Policy 2008-3: Community Networks IPv6 Assignment The AC met in accordance with the ARIN Policy Development Process which requires the AC to meet within 30 days of the conclusion of the Public Policy Meeting to make decisions about the draft policies that had been presented. The PDP states that draft policies that are neither sent to last call nor abandoned are to remain on the AC?s docket for further development and evaluation. 2009-3 was purposefully kept for further work. 2008-3 was kept because both votes to move it to last call, and votes to abandon, failed. These draft policies did not go to last call. This action may be petitioned. The PDP states, ?Any member of the community, including a proposal originator, may initiate a Last Call Petition if they are dissatisfied with the action taken by the Advisory Council regarding any draft policy. If successful, this petition will move the draft policy to last call discussion and review by the community on the PPML.? The deadline to begin a petition for these draft policies is 8 May 2009. Petitions must include the draft policy text and a petition statement. Once begun, a petition lasts for 5 business days. Success is measured as support from at least 10 different people from 10 different organizations. Should a petition begin, ARIN staff will post additional information. The text for Draft Policies and Proposals is available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Mon May 4 12:15:16 2009 From: info at arin.net (Member Services) Date: Mon, 04 May 2009 12:15:16 -0400 Subject: [arin-ppml] =?windows-1252?q?2008-7=3A_Identify_Invalid_WHOIS_POC?= =?windows-1252?q?=92s_-_Last_Call_as_Revised?= Message-ID: <49FF1494.1050007@arin.net> The ARIN Advisory Council (AC) met on 29 April 2009 and decided to send a revised version of the following draft policy to last call: Draft Policy 2008-7: Identify Invalid WHOIS POC?s The AC met in accordance with the ARIN Policy Development Process which requires the AC to meet within 30 days of the conclusion of the Public Policy Meeting to make decisions about the draft policies that had been presented. The AC revised the draft policy text. Feedback is encouraged during this last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 15 May 2009. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2008-7 Identify Invalid WHOIS POC?s Date: 4 May 2009 Policy Statement: Section 3.6 Annual WHOIS POC Validation 3.6.1 Method of Annual Verification During ARINs annual WHOIS POC validation, an e-mail will be sent to every POC in the WHOIS database. Each POC will have a maximum of 60 days to respond with an affirmative that their WHOIS contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk WHOIS policy. Implementation time frame: Staff should begin implementation as soon as practical, but the AC understands that the initial pass through the database may take more than one year. From info at arin.net Mon May 4 12:19:07 2009 From: info at arin.net (Member Services) Date: Mon, 04 May 2009 12:19:07 -0400 Subject: [arin-ppml] Policy Proposal 86: Clarify Board of Trustees Emergency Authority - Abandoned Message-ID: <49FF157B.50401@arin.net> Policy Proposal 86: Clarify Board of Trustees Emergency Authority On 29 April 2009 the ARIN Advisory Council (AC) abandoned Policy Proposal 86. The AC provided the following explanation of their decision: ##### The process by which the ARIN Advisory Council evaluates proposed number resource policies was initially codified in the Internet Resource Policy Evaluation Process (IRPEP), which in January 2009 was replaced with the Policy Development Process (PDP). The PDP (and IRPEP in the past) serve to facilitate the advancement of number resource policy proposals from initial concept to finished form through an open, transparent, bottom-up process. The collected output of ARIN policy proposals over time is recorded in the Number Resource Policy Manual (NRPM). Conspicuously absent from both the PDP and the IRPEP are any mechanisms to modify corporate instruments other than the NRPM (e.g. mission statement, charter, corporate bylaws, etc). Therefore, the PDP cannot be utilized and is not the proper vehicle under which to petition for changes to the process by which the Board of Trustees makes emergency policy decisions. The Board of Trustees of any non-profit corporation have fiduciary and other common law duties to make wise decisions that preserve the organization's capability to carry out its mission. This responsibility cannot be completely delegated to any body, including an advisory council, or any other means for community input. If a better understanding is needed as to how the Board will act during any future exercise of Section 7.1 Emergency PDP, there was unanimous agreement at the AC meeting that the proper way to achieve this discussion and goal would be via the ARIN Consultation and Suggestion Process (ACSP). https://www.arin.net/policy/pdp.html section 4.5 https://www.arin.net/participate/acsp/index.html ##### The AC abandoned the proposal. This action may be petitioned. Per the ARIN Policy Development Process, ?Any member of the community, including a proposal originator, may initiate a Discussion Petition if they are dissatisfied with the action taken by the Advisory Council regarding any specific policy proposal. If successful, this petition will change the policy proposal to a draft policy which will be published for discussion and review by the community on the PPML and at an upcoming public policy meeting.? The deadline to begin a petition for this proposal is 8 May 2009. Petitions must include the proposal and a petition statement. Once begun, a petition lasts for 5 business days. Success is measured as support from at least 10 different people from 10 different organizations. Should an actual petition begin, ARIN staff will post additional information. If there is no petition, or the petition fails, then this proposal will be closed. The text for Draft Policies and Proposals is available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 86: Clarify Board of Trustees Emergency Authority Proposal Originator: William Herrin Proposal Version: 1.0 Date: 4/3/2009 Proposal type: modify Policy term: permanent Policy statement: In the ARIN Policy Development Process (PDP) section 7.1, replace the sentence: The Board of Trustees may initiate the Emergency PDP by declaring an emergency and posting a draft policy to the PPML for discussion for a minimum of 10 business days. With the following text: If faced with an extant problem for which a delay of six months is reasonably expected to have grave consequences, the Board of Trustees may initiate the Emergency PDP by declaring an emergency and drafting a proposal constrained to preventing actions which the Number Resource Policy Manual would otherwise allow. The draft policy must then be posted to the PPML for discussion for a minimum of 10 business days. Rationale: Section 1 of the ARIN Policy Development Process (PDP) wisely excludes the Board of Trustees (BoT) from participating in the drafting of ARIN policy for inclusion in the NRPM. Such participation would mean that the same individuals both write and approve the organization's policy. Historically, giving the same individuals both the power to write policy and the power to approve it has demonstrated itself to be ripe for abuse. Section 7 of the PDP exists so that if some mad genius comes up with a technically correct way to requisition all the remaining IP addresses, something can be done quickly enough to block it. It does not exist to allow the BoT a convenient way to forge new policy in violation of the section 1 proscriptions. With emergency policy proposal 2009-1, the BoT exhibited an imperfect understanding of the purpose of section 7. This proposal seeks to clarify it. Timetable for implementation: immediate From info at arin.net Mon May 4 12:21:01 2009 From: info at arin.net (Member Services) Date: Mon, 04 May 2009 12:21:01 -0400 Subject: [arin-ppml] =?windows-1252?q?Draft_Policy_2009-1=3A_Transfer_Poli?= =?windows-1252?q?cy_=96_Revised_and_forwarded_to_the_Board?= Message-ID: <49FF15ED.4070902@arin.net> The ARIN Advisory Council (AC) met on 29 April 2009 and decided to send a revised version of 2009-1 to the Board for their consideration: Draft Policy 2009-1: Transfer Policy The original 2009-1 is a result of the utilization the Emergency PDP provision of the ARIN Policy Development Process by the ARIN Board of Trustees. The AC was required to make a recommendation about 2009-1 within 5 business days of the conclusion of the discussion period (the discussion period for 2009-1 ended on 29 April 2009). The AC used the feedback from the community on the PPML and at the Public Policy Meeting in San Antonio as guidance in suggesting revisions to the draft policy text. The PDP tasks the Board to review the AC?s recommendation. The AC?s revised version of 2009-1 is below. The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-1 Transfer Policy as revised by the AC Originator: ARIN Board of Trustees (using the Emergency PDP provision in the ARIN Policy Development Process) Date: 29 April 2009 Policy statement: Replace Section 8 as follows: *8. Transfers* *8.1. Principles* Number resources are non-transferable and are not assignable to any other organization unless ARIN has expressly and in writing approved a request for transfer. ARIN is tasked with making prudent decisions on whether to approve the transfer of number resources. It should be understood that number resources are not "sold" under ARIN administration. Rather, number resources are assigned to an organization for its exclusive use for the purpose stated in the request, provided the terms of the Registration Services Agreement continue to be met and the stated purpose for the number resources remains the same. Number resources are administered and assigned according to ARIN's published policies. Number resources are issued, based on justified need, to organizations, not to individuals representing those organizations. Thus, if a company goes out of business, regardless of the reason, the point of contact (POC) listed for the number resource does not have the authority to sell, transfer, assign, or give the number resource to any other person or organization. The POC must notify ARIN if a business fails so the assigned number resources can be returned to the available pool of number resources if a transfer is not requested and justified. *8.2. Mergers and Acquisitions* ARIN will consider requests for the transfer of number resources in the case of mergers and acquisitions upon receipt of evidence that the new entity has acquired the assets which had, as of the date of the acquisition or proposed reorganization, justified the current entity's use of the number resource. Examples of assets that justify use of the number resource include, but are not limited to: * Existing customer base * Qualified hardware inventory * Specific software requirements. In evaluating a request for transfer, ARIN may require the requesting organization to provide any of the following documents, as applicable, plus any other documents deemed appropriate: * An authenticated copy of the instrument(s) effecting the transfer of assets, e.g., bill of sale, certificate of merger, contract, deed, or court decree. * A detailed inventory of all assets utilized by the requesting party in maintaining and using the number resource. * A list of the requesting party's customers using the number resource. If further justification is required, the requesting party may be asked to provide any of the following, or other supporting documentation, as applicable: * A general listing of the assets or components acquired * A specific description of acquisitions, including: o Type and quantity of equipment o Customer base * A description of how number resources are being utilized * Network engineering plans, including: Host counts Subnet masking Network diagrams Reassignments to customers *8.3 Transfers to Specified Recipients* IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies. ##### Changes to 2009-1 as revised by the AC: * Removed 2.8 organization definition * Limited to IPv4 address space * Maintained ARIN as the intermediary * Maintained requirement of source and recipient being in region, and explicitly added the RSA requirement *Added text to clarify need must be a single aggregate From joe at utma.com Mon May 4 12:37:33 2009 From: joe at utma.com (Joe Miller) Date: Mon, 04 May 2009 11:37:33 -0500 Subject: [arin-ppml] =?windows-1252?q?Draft_Policy_2009-1=3A_Transfer_Poli?= =?windows-1252?q?cy_=96_Revised_and_forwarded_to_the_Board?= In-Reply-To: <49FF15ED.4070902@arin.net> References: <49FF15ED.4070902@arin.net> Message-ID: <49FF19CD.4080506@utma.com> I think this is a much better version of the policy than anything else that has been presented so far. This draft specifies IPv4 now, but I would still like to see additional language making the policy less ambiguous with respect to pertaining to IPv4 versus IPv6. I wouldn't mind seeing ARIN having more authority to deny transactions for other reasons, possibly even a blanket "for any other reason deemed by ARIN" statement, perhaps with an appeal process? --joe Member Services wrote: > The ARIN Advisory Council (AC) met on 29 April 2009 and decided to send > a revised version of 2009-1 to the Board for their consideration: > > Draft Policy 2009-1: Transfer Policy > > The original 2009-1 is a result of the utilization the Emergency PDP > provision of the ARIN Policy Development Process by the ARIN Board of > Trustees. The AC was required to make a recommendation about 2009-1 > within 5 business days of the conclusion of the discussion period (the > discussion period for 2009-1 ended on 29 April 2009). The AC used the > feedback from the community on the PPML and at the Public Policy Meeting > in San Antonio as guidance in suggesting revisions to the draft policy > text. The PDP tasks the Board to review the AC?s recommendation. > > The AC?s revised version of 2009-1 is below. > > The ARIN Policy Development Process is available at: > > https://www.arin.net/policy/pdp.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > Draft Policy 2009-1 Transfer Policy as revised by the AC > > Originator: ARIN Board of Trustees (using the Emergency PDP provision in > the ARIN Policy Development Process) > > Date: 29 April 2009 > > Policy statement: > > Replace Section 8 as follows: > > *8. Transfers* > > *8.1. Principles* > Number resources are non-transferable and are not assignable to any > other organization unless ARIN has expressly and in writing approved a > request for transfer. ARIN is tasked with making prudent decisions on > whether to approve the transfer of number resources. > > It should be understood that number resources are not "sold" under ARIN > administration. Rather, number resources are assigned to an organization > for its exclusive use for the purpose stated in the request, provided > the terms of the Registration Services Agreement continue to be met and > the stated purpose for the number resources remains the same. Number > resources are administered and assigned according to ARIN's published > policies. > > Number resources are issued, based on justified need, to organizations, > not to individuals representing those organizations. Thus, if a company > goes out of business, regardless of the reason, the point of contact > (POC) listed for the number resource does not have the authority to > sell, transfer, assign, or give the number resource to any other person > or organization. The POC must notify ARIN if a business fails so the > assigned number resources can be returned to the available pool of > number resources if a transfer is not requested and justified. > > *8.2. Mergers and Acquisitions* > ARIN will consider requests for the transfer of number resources in the > case of mergers and acquisitions upon receipt of evidence that the new > entity has acquired the assets which had, as of the date of the > acquisition or proposed reorganization, justified the current entity's > use of the number resource. Examples of assets that justify use of the > number resource include, but are not limited to: > > * Existing customer base > * Qualified hardware inventory > * Specific software requirements. > > In evaluating a request for transfer, ARIN may require the requesting > organization to provide any of the following documents, as applicable, > plus any other documents deemed appropriate: > > * An authenticated copy of the instrument(s) effecting the transfer > of assets, e.g., bill of sale, certificate of merger, contract, > deed, or court decree. > * A detailed inventory of all assets utilized by the requesting > party in maintaining and using the number resource. > * A list of the requesting party's customers using the number resource. > > If further justification is required, the requesting party may be asked > to provide any of the following, or other supporting documentation, as > applicable: > > * A general listing of the assets or components acquired > * A specific description of acquisitions, including: > > o Type and quantity of equipment > o Customer base > > * A description of how number resources are being utilized > * Network engineering plans, including: > > Host counts > Subnet masking > Network diagrams > Reassignments to customers > > *8.3 Transfers to Specified Recipients* > IPv4 number resources within the ARIN region may be released to ARIN by > the authorized resource holder, in whole or in part, for transfer to > another specified organizational recipient. Such transferred number > resources may only be received under RSA by organizations that are > within the ARIN region and can demonstrate the need for such resources, > as a single aggregate, in the exact amount which they can justify under > current ARIN policies. > > ##### > > Changes to 2009-1 as revised by the AC: > > * Removed 2.8 organization definition > * Limited to IPv4 address space > * Maintained ARIN as the intermediary > * Maintained requirement of source and recipient being in region, > and explicitly added the RSA requirement > *Added text to clarify need must be a single aggregate > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > From farmer at umn.edu Mon May 4 13:04:52 2009 From: farmer at umn.edu (David Farmer) Date: Mon, 04 May 2009 12:04:52 -0500 Subject: [arin-ppml] =?utf-8?q?Draft_Policy_2009-1=3A_Transfer_Policy_?= =?utf-8?q?=E2=80=93_Revised_and_forwarded_to_the_Board?= In-Reply-To: <49FF19CD.4080506@utma.com> References: <49FF15ED.4070902@arin.net>, <49FF19CD.4080506@utma.com> Message-ID: <49FED9E4.5096.E2DB439@farmer.umn.edu> This is completely restating the whole Transfer section of the NRPM, section #8, including the Transfers that are allowed today in the current NRPM. Section 8.2 "Mergers and Acquisitions", actually does apply to all number resources including IPv6 and ASNs as it should. This section is in the NPRM today and it currently applies to IPv4, IPv6, and ASNs. If you buy a company or merge with another company you need to be able to transfer the resources of the company to the new company, including IPv6 and ASNs. This constitutes nothing new, it simple does some minor edits and reorganization of the NRPM text. Section 8.3 "Transfers to Specified Recipients", is unambiguous to me, it only applies to IPv4. This is what is actually new and constitutes a more liberal transfer policy for IPv4 only, etc... Hope that helps; On 4 May 2009 Joe Miller wrote: > I think this is a much better version of the policy than anything else > that has been presented so far. This draft specifies IPv4 now, but I > would still like to see additional language making the policy less > ambiguous with respect to pertaining to IPv4 versus IPv6. .... > --joe =============================================== 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 tedm at ipinc.net Mon May 4 13:12:53 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 4 May 2009 10:12:53 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised and forwarded to the Board In-Reply-To: <49FF15ED.4070902@arin.net> References: <49FF15ED.4070902@arin.net> Message-ID: We still oppose 2009-1 as the removal of the sunset clause by the Board fundamentally changed the proposal, and the mixture of "merger" transfers in 8.2 and "unrestricted" transfers in 8.3 did not allow for the community to separately comment and consider the 2 issues. If Section 8.3 was struck out we would not oppose the proposal. Ted > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > Sent: Monday, May 04, 2009 9:21 AM > To: arin ppml > Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - > Revised and forwarded to the Board > > The ARIN Advisory Council (AC) met on 29 April 2009 and > decided to send a revised version of 2009-1 to the Board for > their consideration: > > Draft Policy 2009-1: Transfer Policy > > The original 2009-1 is a result of the utilization the > Emergency PDP provision of the ARIN Policy Development > Process by the ARIN Board of Trustees. The AC was required to > make a recommendation about 2009-1 within 5 business days of > the conclusion of the discussion period (the discussion > period for 2009-1 ended on 29 April 2009). The AC used the > feedback from the community on the PPML and at the Public > Policy Meeting in San Antonio as guidance in suggesting > revisions to the draft policy text. The PDP tasks the Board > to review the AC's recommendation. > > The AC's revised version of 2009-1 is below. > > The ARIN Policy Development Process is available at: > > https://www.arin.net/policy/pdp.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > Draft Policy 2009-1 Transfer Policy as revised by the AC > > Originator: ARIN Board of Trustees (using the Emergency PDP > provision in the ARIN Policy Development Process) > > Date: 29 April 2009 > > Policy statement: > > Replace Section 8 as follows: > > *8. Transfers* > > *8.1. Principles* > Number resources are non-transferable and are not assignable > to any other organization unless ARIN has expressly and in > writing approved a request for transfer. ARIN is tasked with > making prudent decisions on whether to approve the transfer > of number resources. > > It should be understood that number resources are not "sold" > under ARIN administration. Rather, number resources are > assigned to an organization for its exclusive use for the > purpose stated in the request, provided the terms of the > Registration Services Agreement continue to be met and the > stated purpose for the number resources remains the same. > Number resources are administered and assigned according to > ARIN's published policies. > > Number resources are issued, based on justified need, to > organizations, not to individuals representing those > organizations. Thus, if a company goes out of business, > regardless of the reason, the point of contact > (POC) listed for the number resource does not have the > authority to sell, transfer, assign, or give the number > resource to any other person or organization. The POC must > notify ARIN if a business fails so the assigned number > resources can be returned to the available pool of number > resources if a transfer is not requested and justified. > > *8.2. Mergers and Acquisitions* > ARIN will consider requests for the transfer of number > resources in the case of mergers and acquisitions upon > receipt of evidence that the new entity has acquired the > assets which had, as of the date of the acquisition or > proposed reorganization, justified the current entity's use > of the number resource. Examples of assets that justify use > of the number resource include, but are not limited to: > > * Existing customer base > * Qualified hardware inventory > * Specific software requirements. > > In evaluating a request for transfer, ARIN may require the > requesting organization to provide any of the following > documents, as applicable, plus any other documents deemed appropriate: > > * An authenticated copy of the instrument(s) effecting the > transfer of assets, e.g., bill of sale, certificate of > merger, contract, deed, or court decree. > * A detailed inventory of all assets utilized by the > requesting party in maintaining and using the number resource. > * A list of the requesting party's customers using the number > resource. > > If further justification is required, the requesting party > may be asked to provide any of the following, or other > supporting documentation, as > applicable: > > * A general listing of the assets or components acquired > * A specific description of acquisitions, including: > > o Type and quantity of equipment > o Customer base > > * A description of how number resources are being utilized > * Network engineering plans, including: > > Host counts > Subnet masking > Network diagrams > Reassignments to customers > > *8.3 Transfers to Specified Recipients* > IPv4 number resources within the ARIN region may be released > to ARIN by the authorized resource holder, in whole or in > part, for transfer to another specified organizational > recipient. Such transferred number resources may only be > received under RSA by organizations that are within the ARIN > region and can demonstrate the need for such resources, as a > single aggregate, in the exact amount which they can justify > under current ARIN policies. > > ##### > > Changes to 2009-1 as revised by the AC: > > * Removed 2.8 organization definition > * Limited to IPv4 address space > * Maintained ARIN as the intermediary > * Maintained requirement of source and recipient being in region, > and explicitly added the RSA requirement > *Added text to clarify need must be a single aggregate > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > From john.sweeting at twcable.com Mon May 4 14:39:36 2009 From: john.sweeting at twcable.com (John Sweeting) Date: Mon, 04 May 2009 14:39:36 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: Message-ID: Hi Ted, Please see David Farmer?s earlier reply to Joe Miller. Also please be more specific on who the ?we? are in your email. On 5/4/09 1:12 PM, "Ted Mittelstaedt" wrote: > > > We still oppose 2009-1 as the removal of the sunset clause by the > Board fundamentally changed the proposal, and the mixture of > "merger" transfers in 8.2 and "unrestricted" transfers in 8.3 > did not allow for the community to separately comment and consider > the 2 issues. > > If Section 8.3 was struck out we would not oppose the proposal. > > Ted > >> > 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 >> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services >> > Sent: Monday, May 04, 2009 9:21 AM >> > To: arin ppml >> > Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - >> > Revised and forwarded to the Board >> > >> > The ARIN Advisory Council (AC) met on 29 April 2009 and >> > decided to send a revised version of 2009-1 to the Board for >> > their consideration: >> > >> > Draft Policy 2009-1: Transfer Policy >> > >> > The original 2009-1 is a result of the utilization the >> > Emergency PDP provision of the ARIN Policy Development >> > Process by the ARIN Board of Trustees. The AC was required to >> > make a recommendation about 2009-1 within 5 business days of >> > the conclusion of the discussion period (the discussion >> > period for 2009-1 ended on 29 April 2009). The AC used the >> > feedback from the community on the PPML and at the Public >> > Policy Meeting in San Antonio as guidance in suggesting >> > revisions to the draft policy text. The PDP tasks the Board >> > to review the AC's recommendation. >> > >> > The AC's revised version of 2009-1 is below. >> > >> > The ARIN Policy Development Process is available at: >> > >> > https://www.arin.net/policy/pdp.html >> > >> > Regards, >> > >> > Member Services >> > American Registry for Internet Numbers (ARIN) >> > >> > >> > ## * ## >> > >> > Draft Policy 2009-1 Transfer Policy as revised by the AC >> > >> > Originator: ARIN Board of Trustees (using the Emergency PDP >> > provision in the ARIN Policy Development Process) >> > >> > Date: 29 April 2009 >> > >> > Policy statement: >> > >> > Replace Section 8 as follows: >> > >> > *8. Transfers* >> > >> > *8.1. Principles* >> > Number resources are non-transferable and are not assignable >> > to any other organization unless ARIN has expressly and in >> > writing approved a request for transfer. ARIN is tasked with >> > making prudent decisions on whether to approve the transfer >> > of number resources. >> > >> > It should be understood that number resources are not "sold" >> > under ARIN administration. Rather, number resources are >> > assigned to an organization for its exclusive use for the >> > purpose stated in the request, provided the terms of the >> > Registration Services Agreement continue to be met and the >> > stated purpose for the number resources remains the same. >> > Number resources are administered and assigned according to >> > ARIN's published policies. >> > >> > Number resources are issued, based on justified need, to >> > organizations, not to individuals representing those >> > organizations. Thus, if a company goes out of business, >> > regardless of the reason, the point of contact >> > (POC) listed for the number resource does not have the >> > authority to sell, transfer, assign, or give the number >> > resource to any other person or organization. The POC must >> > notify ARIN if a business fails so the assigned number >> > resources can be returned to the available pool of number >> > resources if a transfer is not requested and justified. >> > >> > *8.2. Mergers and Acquisitions* >> > ARIN will consider requests for the transfer of number >> > resources in the case of mergers and acquisitions upon >> > receipt of evidence that the new entity has acquired the >> > assets which had, as of the date of the acquisition or >> > proposed reorganization, justified the current entity's use >> > of the number resource. Examples of assets that justify use >> > of the number resource include, but are not limited to: >> > >> > * Existing customer base >> > * Qualified hardware inventory >> > * Specific software requirements. >> > >> > In evaluating a request for transfer, ARIN may require the >> > requesting organization to provide any of the following >> > documents, as applicable, plus any other documents deemed appropriate: >> > >> > * An authenticated copy of the instrument(s) effecting the >> > transfer of assets, e.g., bill of sale, certificate of >> > merger, contract, deed, or court decree. >> > * A detailed inventory of all assets utilized by the >> > requesting party in maintaining and using the number resource. >> > * A list of the requesting party's customers using the number >> > resource. >> > >> > If further justification is required, the requesting party >> > may be asked to provide any of the following, or other >> > supporting documentation, as >> > applicable: >> > >> > * A general listing of the assets or components acquired >> > * A specific description of acquisitions, including: >> > >> > o Type and quantity of equipment >> > o Customer base >> > >> > * A description of how number resources are being utilized >> > * Network engineering plans, including: >> > >> > Host counts >> > Subnet masking >> > Network diagrams >> > Reassignments to customers >> > >> > *8.3 Transfers to Specified Recipients* >> > IPv4 number resources within the ARIN region may be released >> > to ARIN by the authorized resource holder, in whole or in >> > part, for transfer to another specified organizational >> > recipient. Such transferred number resources may only be >> > received under RSA by organizations that are within the ARIN >> > region and can demonstrate the need for such resources, as a >> > single aggregate, in the exact amount which they can justify >> > under current ARIN policies. >> > >> > ##### >> > >> > Changes to 2009-1 as revised by the AC: >> > >> > * Removed 2.8 organization definition >> > * Limited to IPv4 address space >> > * Maintained ARIN as the intermediary >> > * Maintained requirement of source and recipient being in region, >> > and explicitly added the RSA requirement >> > *Added text to clarify need must be a single aggregate >> > >> > _______________________________________________ >> > PPML >> > You are receiving this message because you are subscribed to >> > the ARIN Public Policy Mailing 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bicknell at ufp.org Mon May 4 15:00:29 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 4 May 2009 15:00:29 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revised and forwarded to the Board In-Reply-To: <49FF15ED.4070902@arin.net> References: <49FF15ED.4070902@arin.net> Message-ID: <20090504190028.GB57395@ussenterprise.ufp.org> In a message written on Mon, May 04, 2009 at 12:21:01PM -0400, Member Services wrote: > The ARIN Advisory Council (AC) met on 29 April 2009 and decided to send > a revised version of 2009-1 to the Board for their consideration: This policy isn't in "last-call" per se, but given the PDP process I feel this is the only appropriate time for me to make these remarks. I am a member of the Advisory Council, speaking only for myself. During the various reviews and discussions the Advisory Council performs after the meeting a particular aspect of this policy was brought to (most of?) the AC's attention. I would like to bring it to the community's attention as well. I did not write notes on this at the time, so I am doing this from memory. If I get it wrong, I hope someone corrects me. Billy has a /16, and he's using it for dial up services which is not paying the bills anymore. Suzie wants a /16 for her hot new social networking experiment. Billy and Suzie find each other and agree to transfer Billy's /16 to Suzie under the result of 2008-6 + 2009-1. Billy goes to ARIN and says "Here's a /16, please give it to Suzie." Suzie goes to ARIN and says, "I'm here for Billy's /16". In the process, ARIN checks Suzie's justification, and realizes Suzie can only justify a /18. My understanding of the current interpretation of 2008-6 + 2009-1 is that ARIN would give Suzie a /18, and keep a /18 and /17 in the free pool. Billy has given up his /16, and Suzie only got a /18 of it. This ends up being an artifact of the legal requirement that transfers must occur through ARIN. My own personal view on how this would work prior to finding this out was if Suzie couldn't receive Billy's /16 for any reason, Billy would retain the /16. Thus my surprise, and I'm wondering if this isn't a surprise for others in the community. The recommended "fix", is that Suzie will be able to "pre-qualify", that is go to ARIN with all of her paperwork and get approved for a /18 before Billy and Suzie do a deal, so Suzie knows this will not happen. I think this ends up being bad for three distinct reasons: Technically: This causes deaggregation. In the example given a /16 was turned into a /17 and two /18's. However, because a /17 and /18 are both now in the free pool they may be further subdivided into /20's (or smaller, in some cases). Business: It is likely Billy and Suzie exchanged something of value during this transaction to make it happen. Suzie has now "overpaid" for her /18, and is likely to demand a refund from Billy, or challenge ARIN's stance she can only justify a /18, or both. Billy, of course, isn't going to want to give a refund as he is out the entire /16, but he may also be unhappy at ARIN for only approving her for a /18. It sounds like a good way to get all the parties in a transaction unhappy. But also, it opens up an interesting fraud. Alice could go to Billy and offer to buy the /16 for a hundred million dollars. Billy gets so excited over the idea of retiring from the dial up business that he takes the deal. Alice gives him a fake check, and Billy fills out the ARIN paperwork. But you see, it is a fake check, and Alice had no intention of ever justifying the addresses to ARIN. Billy figures out two weeks later the check is fake from the bank, but he's already released the addresses to ARIN and can't get them back. What's Alice's motivation? Well, her alter-ego Janice is sitting near the front of the line of folks waiting for space to end up in the free pool. Good for her, a /16 just showed up. But really this is all added risk, and what business wants to participate in a system with extra risk? Politically: This interpretation of the policy is likely to affect the most vulnerable the most. The savvy folks who are doing all sorts of transfers are reading this post on PPML now, and will understand the pitfalls of the system and work around these issues by doing things like prequalifing. This issue is much more likely to trip up the "one time" casual transferor or transferee who last delt with ARIN in 1999 and doesn't do this as a day job anymore. They are the ones who will accidently encounter this situation. Personally, I think ARIN should not let this happen. The simplest fix I have come up with is to require Suzie to fill out the recipient paperwork first. Billy should not be able to designate a recipient without having some assurance that end of the transaction is already approved from ARIN. This could be as simple as Suzie giving Billy the ticket number under which Suzie was approved, and Billy having to provide that ticket number to release resources. In this way an exact match could be insured, eliminating all of the problems listed above. The AC obviously moved this proposal on; so this was not seen as a show-stopper issue by the majority of the AC. At a minimum, I wanted to get the issue out to the community so if nothing is changed the community is aware of the issue and will be able to avoid it. I would hope this would end up documented on the ARIN web site in fairly clear language as well; but given the accelerated timetable for this proposal I didn't want to wait for that to occur first. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From tedm at ipinc.net Mon May 4 15:06:52 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 4 May 2009 12:06:52 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: References: Message-ID: "we" is the org I'm the POC for, Internet Partners, Inc., as opposed to me -not- speaking officially for that org (which I normally do on this list) Sorry to not make that more clear. Yes, I saw Daves reply. The fact that 8.3 is "new" does not remove the need for the minor edits and reorganization of the NRPM text that Dave was referring to, that's why we support it. And yes I also know that the Board is going to do what it wants, so it is kind of futile to even bother commenting in opposition or support at this point. But I don't want the board to actually start believing it's own back-patting that everything is all fixed now. Ted _____ From: John Sweeting [mailto:john.sweeting at twcable.com] Sent: Monday, May 04, 2009 11:40 AM To: Ted Mittelstaedt; Member Services; arin ppml Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board Hi Ted, Please see David Farmer's earlier reply to Joe Miller. Also please be more specific on who the "we" are in your email. On 5/4/09 1:12 PM, "Ted Mittelstaedt" wrote: We still oppose 2009-1 as the removal of the sunset clause by the Board fundamentally changed the proposal, and the mixture of "merger" transfers in 8.2 and "unrestricted" transfers in 8.3 did not allow for the community to separately comment and consider the 2 issues. If Section 8.3 was struck out we would not oppose the proposal. Ted > 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 > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > Sent: Monday, May 04, 2009 9:21 AM > To: arin ppml > Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - > Revised and forwarded to the Board > > The ARIN Advisory Council (AC) met on 29 April 2009 and > decided to send a revised version of 2009-1 to the Board for > their consideration: > > Draft Policy 2009-1: Transfer Policy > > The original 2009-1 is a result of the utilization the > Emergency PDP provision of the ARIN Policy Development > Process by the ARIN Board of Trustees. The AC was required to > make a recommendation about 2009-1 within 5 business days of > the conclusion of the discussion period (the discussion > period for 2009-1 ended on 29 April 2009). The AC used the > feedback from the community on the PPML and at the Public > Policy Meeting in San Antonio as guidance in suggesting > revisions to the draft policy text. The PDP tasks the Board > to review the AC's recommendation. > > The AC's revised version of 2009-1 is below. > > The ARIN Policy Development Process is available at: > > https://www.arin.net/policy/pdp.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > Draft Policy 2009-1 Transfer Policy as revised by the AC > > Originator: ARIN Board of Trustees (using the Emergency PDP > provision in the ARIN Policy Development Process) > > Date: 29 April 2009 > > Policy statement: > > Replace Section 8 as follows: > > *8. Transfers* > > *8.1. Principles* > Number resources are non-transferable and are not assignable > to any other organization unless ARIN has expressly and in > writing approved a request for transfer. ARIN is tasked with > making prudent decisions on whether to approve the transfer > of number resources. > > It should be understood that number resources are not "sold" > under ARIN administration. Rather, number resources are > assigned to an organization for its exclusive use for the > purpose stated in the request, provided the terms of the > Registration Services Agreement continue to be met and the > stated purpose for the number resources remains the same. > Number resources are administered and assigned according to > ARIN's published policies. > > Number resources are issued, based on justified need, to > organizations, not to individuals representing those > organizations. Thus, if a company goes out of business, > regardless of the reason, the point of contact > (POC) listed for the number resource does not have the > authority to sell, transfer, assign, or give the number > resource to any other person or organization. The POC must > notify ARIN if a business fails so the assigned number > resources can be returned to the available pool of number > resources if a transfer is not requested and justified. > > *8.2. Mergers and Acquisitions* > ARIN will consider requests for the transfer of number > resources in the case of mergers and acquisitions upon > receipt of evidence that the new entity has acquired the > assets which had, as of the date of the acquisition or > proposed reorganization, justified the current entity's use > of the number resource. Examples of assets that justify use > of the number resource include, but are not limited to: > > * Existing customer base > * Qualified hardware inventory > * Specific software requirements. > > In evaluating a request for transfer, ARIN may require the > requesting organization to provide any of the following > documents, as applicable, plus any other documents deemed appropriate: > > * An authenticated copy of the instrument(s) effecting the > transfer of assets, e.g., bill of sale, certificate of > merger, contract, deed, or court decree. > * A detailed inventory of all assets utilized by the > requesting party in maintaining and using the number resource. > * A list of the requesting party's customers using the number > resource. > > If further justification is required, the requesting party > may be asked to provide any of the following, or other > supporting documentation, as > applicable: > > * A general listing of the assets or components acquired > * A specific description of acquisitions, including: > > o Type and quantity of equipment > o Customer base > > * A description of how number resources are being utilized > * Network engineering plans, including: > > Host counts > Subnet masking > Network diagrams > Reassignments to customers > > *8.3 Transfers to Specified Recipients* > IPv4 number resources within the ARIN region may be released > to ARIN by the authorized resource holder, in whole or in > part, for transfer to another specified organizational > recipient. Such transferred number resources may only be > received under RSA by organizations that are within the ARIN > region and can demonstrate the need for such resources, as a > single aggregate, in the exact amount which they can justify > under current ARIN policies. > > ##### > > Changes to 2009-1 as revised by the AC: > > * Removed 2.8 organization definition > * Limited to IPv4 address space > * Maintained ARIN as the intermediary > * Maintained requirement of source and recipient being in region, > and explicitly added the RSA requirement > *Added text to clarify need must be a single aggregate > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.sweeting at twcable.com Mon May 4 15:09:36 2009 From: john.sweeting at twcable.com (John Sweeting) Date: Mon, 04 May 2009 15:09:36 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: Message-ID: Thanks for the clarification Ted. On 5/4/09 3:06 PM, "Ted Mittelstaedt" wrote: > "we" is the org I'm the POC for, Internet Partners, Inc., as opposed to me > -not- speaking officially > for that org (which I normally do on this list) Sorry to not make that more > clear. > > Yes, I saw Daves reply. The fact that 8.3 is "new" does not remove the need > for the minor > edits and reorganization of the NRPM text that Dave was referring to, that's > why we > support it. > > And yes I also know that the Board is going to do what it wants, so it is kind > of futile to > even bother commenting in opposition or support at this point. But I don't > want the board > to actually start believing it's own back-patting that everything is all fixed > now. > > > Ted > >> >> >> >> From: John Sweeting [mailto:john.sweeting at twcable.com] >> Sent: Monday, May 04, 2009 11:40 AM >> To: Ted Mittelstaedt; Member Services; arin ppml >> Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised >> andforwarded to the Board >> >> >> >> >> Hi Ted, >> >> Please see David Farmer?s earlier reply to Joe Miller. Also please be more >> specific on who the ?we? are in your email. >> >> >> On 5/4/09 1:12 PM, "Ted Mittelstaedt" wrote: >> >> >>> >>> >>> We still oppose 2009-1 as the removal of the sunset clause by the >>> Board fundamentally changed the proposal, and the mixture of >>> "merger" transfers in 8.2 and "unrestricted" transfers in 8.3 >>> did not allow for the community to separately comment and consider >>> the 2 issues. >>> >>> If Section 8.3 was struck out we would not oppose the proposal. >>> >>> Ted >>> >>>> > >> >> 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 >>>> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services >>>> > Sent: Monday, May 04, 2009 9:21 AM >>>> > To: arin ppml >>>> > Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - >>>> > Revised and forwarded to the Board >>>> > >>>> > The ARIN Advisory Council (AC) met on 29 April 2009 and >>>> > decided to send a revised version of 2009-1 to the Board for >>>> > their consideration: >>>> > >>>> > Draft Policy 2009-1: Transfer Policy >>>> > >>>> > The original 2009-1 is a result of the utilization the >>>> > Emergency PDP provision of the ARIN Policy Development >>>> > Process by the ARIN Board of Trustees. The AC was required to >>>> > make a recommendation about 2009-1 within 5 business days of >>>> > the conclusion of the discussion period (the discussion >>>> > period for 2009-1 ended on 29 April 2009). The AC used the >>>> > feedback from the community on the PPML and at the Public >>>> > Policy Meeting in San Antonio as guidance in suggesting >>>> > revisions to the draft policy text. The PDP tasks the Board >>>> > to review the AC's recommendation. >>>> > >>>> > The AC's revised version of 2009-1 is below. >>>> > >>>> > The ARIN Policy Development Process is available at: >>>> > >>>> > https://www.arin.net/policy/pdp.html >>>> > >>>> > Regards, >>>> > >>>> > Member Services >>>> > American Registry for Internet Numbers (ARIN) >>>> > >>>> > >>>> > ## * ## >>>> > >>>> > Draft Policy 2009-1 Transfer Policy as revised by the AC >>>> > >>>> > Originator: ARIN Board of Trustees (using the Emergency PDP >>>> > provision in the ARIN Policy Development Process) >>>> > >>>> > Date: 29 April 2009 >>>> > >>>> > Policy statement: >>>> > >>>> > Replace Section 8 as follows: >>>> > >>>> > *8. Transfers* >>>> > >>>> > *8.1. Principles* >>>> > Number resources are non-transferable and are not assignable >>>> > to any other organization unless ARIN has expressly and in >>>> > writing approved a request for transfer. ARIN is tasked with >>>> > making prudent decisions on whether to approve the transfer >>>> > of number resources. >>>> > >>>> > It should be understood that number resources are not "sold" >>>> > under ARIN administration. Rather, number resources are >>>> > assigned to an organization for its exclusive use for the >>>> > purpose stated in the request, provided the terms of the >>>> > Registration Services Agreement continue to be met and the >>>> > stated purpose for the number resources remains the same. >>>> > Number resources are administered and assigned according to >>>> > ARIN's published policies. >>>> > >>>> > Number resources are issued, based on justified need, to >>>> > organizations, not to individuals representing those >>>> > organizations. Thus, if a company goes out of business, >>>> > regardless of the reason, the point of contact >>>> > (POC) listed for the number resource does not have the >>>> > authority to sell, transfer, assign, or give the number >>>> > resource to any other person or organization. The POC must >>>> > notify ARIN if a business fails so the assigned number >>>> > resources can be returned to the available pool of number >>>> > resources if a transfer is not requested and justified. >>>> > >>>> > *8.2. Mergers and Acquisitions* >>>> > ARIN will consider requests for the transfer of number >>>> > resources in the case of mergers and acquisitions upon >>>> > receipt of evidence that the new entity has acquired the >>>> > assets which had, as of the date of the acquisition or >>>> > proposed reorganization, justified the current entity's use >>>> > of the number resource. Examples of assets that justify use >>>> > of the number resource include, but are not limited to: >>>> > >>>> > * Existing customer base >>>> > * Qualified hardware inventory >>>> > * Specific software requirements. >>>> > >>>> > In evaluating a request for transfer, ARIN may require the >>>> > requesting organization to provide any of the following >>>> > documents, as applicable, plus any other documents deemed appropriate: >>>> > >>>> > * An authenticated copy of the instrument(s) effecting the >>>> > transfer of assets, e.g., bill of sale, certificate of >>>> > merger, contract, deed, or court decree. >>>> > * A detailed inventory of all assets utilized by the >>>> > requesting party in maintaining and using the number resource. >>>> > * A list of the requesting party's customers using the number >>>> > resource. >>>> > >>>> > If further justification is required, the requesting party >>>> > may be asked to provide any of the following, or other >>>> > supporting documentation, as >>>> > applicable: >>>> > >>>> > * A general listing of the assets or components acquired >>>> > * A specific description of acquisitions, including: >>>> > >>>> > o Type and quantity of equipment >>>> > o Customer base >>>> > >>>> > * A description of how number resources are being utilized >>>> > * Network engineering plans, including: >>>> > >>>> > Host counts >>>> > Subnet masking >>>> > Network diagrams >>>> > Reassignments to customers >>>> > >>>> > *8.3 Transfers to Specified Recipients* >>>> > IPv4 number resources within the ARIN region may be released >>>> > to ARIN by the authorized resource holder, in whole or in >>>> > part, for transfer to another specified organizational >>>> > recipient. Such transferred number resources may only be >>>> > received under RSA by organizations that are within the ARIN >>>> > region and can demonstrate the need for such resources, as a >>>> > single aggregate, in the exact amount which they can justify >>>> > under current ARIN policies. >>>> > >>>> > ##### >>>> > >>>> > Changes to 2009-1 as revised by the AC: >>>> > >>>> > * Removed 2.8 organization definition >>>> > * Limited to IPv4 address space >>>> > * Maintained ARIN as the intermediary >>>> > * Maintained requirement of source and recipient being in region, >>>> > and explicitly added the RSA requirement >>>> > *Added text to clarify need must be a single aggregate >>>> > >>>> > _______________________________________________ >>>> > PPML >>>> > You are receiving this message because you are subscribed to >>>> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> > Unsubscribe or manage your mailing list subscription at: >>>> > http://lists.arin.net/mailman/listinfo/arin-ppml >>>> > Please contact info at arin.net if you experience any issues. >>>> > >>>> > >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >> >> >> This E-mail and any of its attachments may contain Time Warner >> Cable proprietary information, which is privileged, confidential, >> or subject to copyright belonging to Time Warner Cable. This E-mail >> is intended solely for the use of the individual or entity to which >> it is addressed. If you are not the intended recipient of this >> E-mail, you are hereby notified that any dissemination, >> distribution, copying, or action taken in relation to the contents >> of and attachments to this E-mail is strictly prohibited and may be >> unlawful. If you have received this E-mail in error, please notify >> the sender immediately and permanently delete the original and any >> copy of this E-mail and any printout. >> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Mon May 4 15:10:15 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 4 May 2009 12:10:15 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revisedandforwarded to the Board In-Reply-To: References: Message-ID: <369F43E6C9B94BD2BE578A9BE799F8B4@tedsdesk> "that's why we support it." (it in this context is the minor changes in 8.2) Ted _____ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Monday, May 04, 2009 12:07 PM To: 'John Sweeting'; 'Member Services'; 'arin ppml' Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revisedandforwarded to the Board "we" is the org I'm the POC for, Internet Partners, Inc., as opposed to me -not- speaking officially for that org (which I normally do on this list) Sorry to not make that more clear. Yes, I saw Daves reply. The fact that 8.3 is "new" does not remove the need for the minor edits and reorganization of the NRPM text that Dave was referring to, that's why we support it. And yes I also know that the Board is going to do what it wants, so it is kind of futile to even bother commenting in opposition or support at this point. But I don't want the board to actually start believing it's own back-patting that everything is all fixed now. Ted _____ From: John Sweeting [mailto:john.sweeting at twcable.com] Sent: Monday, May 04, 2009 11:40 AM To: Ted Mittelstaedt; Member Services; arin ppml Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board Hi Ted, Please see David Farmer's earlier reply to Joe Miller. Also please be more specific on who the "we" are in your email. On 5/4/09 1:12 PM, "Ted Mittelstaedt" wrote: We still oppose 2009-1 as the removal of the sunset clause by the Board fundamentally changed the proposal, and the mixture of "merger" transfers in 8.2 and "unrestricted" transfers in 8.3 did not allow for the community to separately comment and consider the 2 issues. If Section 8.3 was struck out we would not oppose the proposal. Ted > 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 > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > Sent: Monday, May 04, 2009 9:21 AM > To: arin ppml > Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - > Revised and forwarded to the Board > > The ARIN Advisory Council (AC) met on 29 April 2009 and > decided to send a revised version of 2009-1 to the Board for > their consideration: > > Draft Policy 2009-1: Transfer Policy > > The original 2009-1 is a result of the utilization the > Emergency PDP provision of the ARIN Policy Development > Process by the ARIN Board of Trustees. The AC was required to > make a recommendation about 2009-1 within 5 business days of > the conclusion of the discussion period (the discussion > period for 2009-1 ended on 29 April 2009). The AC used the > feedback from the community on the PPML and at the Public > Policy Meeting in San Antonio as guidance in suggesting > revisions to the draft policy text. The PDP tasks the Board > to review the AC's recommendation. > > The AC's revised version of 2009-1 is below. > > The ARIN Policy Development Process is available at: > > https://www.arin.net/policy/pdp.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > Draft Policy 2009-1 Transfer Policy as revised by the AC > > Originator: ARIN Board of Trustees (using the Emergency PDP > provision in the ARIN Policy Development Process) > > Date: 29 April 2009 > > Policy statement: > > Replace Section 8 as follows: > > *8. Transfers* > > *8.1. Principles* > Number resources are non-transferable and are not assignable > to any other organization unless ARIN has expressly and in > writing approved a request for transfer. ARIN is tasked with > making prudent decisions on whether to approve the transfer > of number resources. > > It should be understood that number resources are not "sold" > under ARIN administration. Rather, number resources are > assigned to an organization for its exclusive use for the > purpose stated in the request, provided the terms of the > Registration Services Agreement continue to be met and the > stated purpose for the number resources remains the same. > Number resources are administered and assigned according to > ARIN's published policies. > > Number resources are issued, based on justified need, to > organizations, not to individuals representing those > organizations. Thus, if a company goes out of business, > regardless of the reason, the point of contact > (POC) listed for the number resource does not have the > authority to sell, transfer, assign, or give the number > resource to any other person or organization. The POC must > notify ARIN if a business fails so the assigned number > resources can be returned to the available pool of number > resources if a transfer is not requested and justified. > > *8.2. Mergers and Acquisitions* > ARIN will consider requests for the transfer of number > resources in the case of mergers and acquisitions upon > receipt of evidence that the new entity has acquired the > assets which had, as of the date of the acquisition or > proposed reorganization, justified the current entity's use > of the number resource. Examples of assets that justify use > of the number resource include, but are not limited to: > > * Existing customer base > * Qualified hardware inventory > * Specific software requirements. > > In evaluating a request for transfer, ARIN may require the > requesting organization to provide any of the following > documents, as applicable, plus any other documents deemed appropriate: > > * An authenticated copy of the instrument(s) effecting the > transfer of assets, e.g., bill of sale, certificate of > merger, contract, deed, or court decree. > * A detailed inventory of all assets utilized by the > requesting party in maintaining and using the number resource. > * A list of the requesting party's customers using the number > resource. > > If further justification is required, the requesting party > may be asked to provide any of the following, or other > supporting documentation, as > applicable: > > * A general listing of the assets or components acquired > * A specific description of acquisitions, including: > > o Type and quantity of equipment > o Customer base > > * A description of how number resources are being utilized > * Network engineering plans, including: > > Host counts > Subnet masking > Network diagrams > Reassignments to customers > > *8.3 Transfers to Specified Recipients* > IPv4 number resources within the ARIN region may be released > to ARIN by the authorized resource holder, in whole or in > part, for transfer to another specified organizational > recipient. Such transferred number resources may only be > received under RSA by organizations that are within the ARIN > region and can demonstrate the need for such resources, as a > single aggregate, in the exact amount which they can justify > under current ARIN policies. > > ##### > > Changes to 2009-1 as revised by the AC: > > * Removed 2.8 organization definition > * Limited to IPv4 address space > * Maintained ARIN as the intermediary > * Maintained requirement of source and recipient being in region, > and explicitly added the RSA requirement > *Added text to clarify need must be a single aggregate > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Mon May 4 15:10:57 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 04 May 2009 14:10:57 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revised and forwarded to the Board In-Reply-To: <20090504190028.GB57395@ussenterprise.ufp.org> References: <49FF15ED.4070902@arin.net> <20090504190028.GB57395@ussenterprise.ufp.org> Message-ID: <49FF3DC1.5050601@gmail.com> Leo, Thanks for bringing this up. As we discussed at the AC meeting, I think this is something that can (and should/will) be dealt with by ARIN staff as they implement the transfer policy. Here's how I see it working: Billy goes to ARIN and says "Here's a /16, please give it to Suzie." ARIN says to Billy, "Suzie hasn't yet been approved for a /16, so you may want to hold on to your /16 while we process her application." Suzie goes to ARIN and says, "I'm here for Billy's /16". In the process, ARIN checks Suzie's justification, and realizes Suzie can only justify a /18. ARIN tell Suzie and Billy that Suzie is only approved for a /18, and asks Billy if he still wants to return the whole /16, or do something else. Now that you've raised this issue, I am confident that ARIN staff will create operational procedures to deal with it in such a way that no one ends up surprised. -Scott Leo Bicknell wrote: > In a message written on Mon, May 04, 2009 at 12:21:01PM -0400, Member Services wrote: > >> The ARIN Advisory Council (AC) met on 29 April 2009 and decided to send >> a revised version of 2009-1 to the Board for their consideration: >> > > This policy isn't in "last-call" per se, but given the PDP process > I feel this is the only appropriate time for me to make these > remarks. > > I am a member of the Advisory Council, speaking only for myself. > During the various reviews and discussions the Advisory Council > performs after the meeting a particular aspect of this policy was > brought to (most of?) the AC's attention. I would like to bring > it to the community's attention as well. I did not write notes on > this at the time, so I am doing this from memory. If I get it > wrong, I hope someone corrects me. > > Billy has a /16, and he's using it for dial up services which is > not paying the bills anymore. > > Suzie wants a /16 for her hot new social networking experiment. > > Billy and Suzie find each other and agree to transfer Billy's /16 > to Suzie under the result of 2008-6 + 2009-1. > > Billy goes to ARIN and says "Here's a /16, please give it to Suzie." > > Suzie goes to ARIN and says, "I'm here for Billy's /16". In the > process, ARIN checks Suzie's justification, and realizes Suzie can > only justify a /18. > > My understanding of the current interpretation of 2008-6 + 2009-1 > is that ARIN would give Suzie a /18, and keep a /18 and /17 in the > free pool. > > Billy has given up his /16, and Suzie only got a /18 of it. > > This ends up being an artifact of the legal requirement that transfers > must occur through ARIN. My own personal view on how this would > work prior to finding this out was if Suzie couldn't receive Billy's > /16 for any reason, Billy would retain the /16. Thus my surprise, > and I'm wondering if this isn't a surprise for others in the > community. > > The recommended "fix", is that Suzie will be able to "pre-qualify", > that is go to ARIN with all of her paperwork and get approved for > a /18 before Billy and Suzie do a deal, so Suzie knows this will > not happen. > > I think this ends up being bad for three distinct reasons: > > Technically: > > This causes deaggregation. In the example given a /16 was turned into > a /17 and two /18's. However, because a /17 and /18 are both now in > the free pool they may be further subdivided into /20's (or smaller, > in some cases). > > Business: > > It is likely Billy and Suzie exchanged something of value during this > transaction to make it happen. Suzie has now "overpaid" for her /18, > and is likely to demand a refund from Billy, or challenge ARIN's > stance she can only justify a /18, or both. Billy, of course, isn't > going to want to give a refund as he is out the entire /16, but he may > also be unhappy at ARIN for only approving her for a /18. It sounds > like a good way to get all the parties in a transaction unhappy. > > But also, it opens up an interesting fraud. Alice could go to Billy > and offer to buy the /16 for a hundred million dollars. Billy gets > so excited over the idea of retiring from the dial up business that > he takes the deal. Alice gives him a fake check, and Billy fills out > the ARIN paperwork. > > But you see, it is a fake check, and Alice had no intention of ever > justifying the addresses to ARIN. Billy figures out two weeks later > the check is fake from the bank, but he's already released the addresses > to ARIN and can't get them back. What's Alice's motivation? Well, > her alter-ego Janice is sitting near the front of the line of folks > waiting for space to end up in the free pool. Good for her, a /16 > just showed up. > > But really this is all added risk, and what business wants to > participate in a system with extra risk? > > Politically: > > This interpretation of the policy is likely to affect the most > vulnerable the most. The savvy folks who are doing all sorts of > transfers are reading this post on PPML now, and will understand > the pitfalls of the system and work around these issues by doing > things like prequalifing. > > This issue is much more likely to trip up the "one time" casual > transferor or transferee who last delt with ARIN in 1999 and > doesn't do this as a day job anymore. They are the ones who will > accidently encounter this situation. > > Personally, I think ARIN should not let this happen. The simplest > fix I have come up with is to require Suzie to fill out the recipient > paperwork first. Billy should not be able to designate a recipient > without having some assurance that end of the transaction is already > approved from ARIN. This could be as simple as Suzie giving Billy > the ticket number under which Suzie was approved, and Billy having > to provide that ticket number to release resources. In this way > an exact match could be insured, eliminating all of the problems > listed above. > > The AC obviously moved this proposal on; so this was not seen as a > show-stopper issue by the majority of the AC. At a minimum, I > wanted to get the issue out to the community so if nothing is changed > the community is aware of the issue and will be able to avoid it. > I would hope this would end up documented on the ARIN web site in > fairly clear language as well; but given the accelerated timetable > for this proposal I didn't want to wait for that to occur first. > > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From john.sweeting at twcable.com Mon May 4 15:27:47 2009 From: john.sweeting at twcable.com (John Sweeting) Date: Mon, 04 May 2009 15:27:47 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revised andforwarded to the Board In-Reply-To: <20090504190028.GB57395@ussenterprise.ufp.org> Message-ID: A few more bits of information. One reason that the AC moved this proposal forward was that 2008-6 was already approved and set to be implemented on June 1 so the issue was already there. I believe it was accepted that the AC would make further review and come up with a proposal that would deal with this impact. Also a point to note is that this policy must be recertified at the next Public Policy Meeting since it went through the Emergency Policy process. On 5/4/09 3:00 PM, "Leo Bicknell" wrote: > In a message written on Mon, May 04, 2009 at 12:21:01PM -0400, Member Services > wrote: >> > The ARIN Advisory Council (AC) met on 29 April 2009 and decided to send >> > a revised version of 2009-1 to the Board for their consideration: > > This policy isn't in "last-call" per se, but given the PDP process > I feel this is the only appropriate time for me to make these > remarks. > > I am a member of the Advisory Council, speaking only for myself. > During the various reviews and discussions the Advisory Council > performs after the meeting a particular aspect of this policy was > brought to (most of?) the AC's attention. I would like to bring > it to the community's attention as well. I did not write notes on > this at the time, so I am doing this from memory. If I get it > wrong, I hope someone corrects me. > > Billy has a /16, and he's using it for dial up services which is > not paying the bills anymore. > > Suzie wants a /16 for her hot new social networking experiment. > > Billy and Suzie find each other and agree to transfer Billy's /16 > to Suzie under the result of 2008-6 + 2009-1. > > Billy goes to ARIN and says "Here's a /16, please give it to Suzie." > > Suzie goes to ARIN and says, "I'm here for Billy's /16". In the > process, ARIN checks Suzie's justification, and realizes Suzie can > only justify a /18. > > My understanding of the current interpretation of 2008-6 + 2009-1 > is that ARIN would give Suzie a /18, and keep a /18 and /17 in the > free pool. > > Billy has given up his /16, and Suzie only got a /18 of it. > > This ends up being an artifact of the legal requirement that transfers > must occur through ARIN. My own personal view on how this would > work prior to finding this out was if Suzie couldn't receive Billy's > /16 for any reason, Billy would retain the /16. Thus my surprise, > and I'm wondering if this isn't a surprise for others in the > community. > > The recommended "fix", is that Suzie will be able to "pre-qualify", > that is go to ARIN with all of her paperwork and get approved for > a /18 before Billy and Suzie do a deal, so Suzie knows this will > not happen. > > I think this ends up being bad for three distinct reasons: > > Technically: > > This causes deaggregation. In the example given a /16 was turned into > a /17 and two /18's. However, because a /17 and /18 are both now in > the free pool they may be further subdivided into /20's (or smaller, > in some cases). > > Business: > > It is likely Billy and Suzie exchanged something of value during this > transaction to make it happen. Suzie has now "overpaid" for her /18, > and is likely to demand a refund from Billy, or challenge ARIN's > stance she can only justify a /18, or both. Billy, of course, isn't > going to want to give a refund as he is out the entire /16, but he may > also be unhappy at ARIN for only approving her for a /18. It sounds > like a good way to get all the parties in a transaction unhappy. > > But also, it opens up an interesting fraud. Alice could go to Billy > and offer to buy the /16 for a hundred million dollars. Billy gets > so excited over the idea of retiring from the dial up business that > he takes the deal. Alice gives him a fake check, and Billy fills out > the ARIN paperwork. > > But you see, it is a fake check, and Alice had no intention of ever > justifying the addresses to ARIN. Billy figures out two weeks later > the check is fake from the bank, but he's already released the addresses > to ARIN and can't get them back. What's Alice's motivation? Well, > her alter-ego Janice is sitting near the front of the line of folks > waiting for space to end up in the free pool. Good for her, a /16 > just showed up. > > But really this is all added risk, and what business wants to > participate in a system with extra risk? > > Politically: > > This interpretation of the policy is likely to affect the most > vulnerable the most. The savvy folks who are doing all sorts of > transfers are reading this post on PPML now, and will understand > the pitfalls of the system and work around these issues by doing > things like prequalifing. > > This issue is much more likely to trip up the "one time" casual > transferor or transferee who last delt with ARIN in 1999 and > doesn't do this as a day job anymore. They are the ones who will > accidently encounter this situation. > > Personally, I think ARIN should not let this happen. The simplest > fix I have come up with is to require Suzie to fill out the recipient > paperwork first. Billy should not be able to designate a recipient > without having some assurance that end of the transaction is already > approved from ARIN. This could be as simple as Suzie giving Billy > the ticket number under which Suzie was approved, and Billy having > to provide that ticket number to release resources. In this way > an exact match could be insured, eliminating all of the problems > listed above. > > The AC obviously moved this proposal on; so this was not seen as a > show-stopper issue by the majority of the AC. At a minimum, I > wanted to get the issue out to the community so if nothing is changed > the community is aware of the issue and will be able to avoid it. > I would hope this would end up documented on the ARIN web site in > fairly clear language as well; but given the accelerated timetable > for this proposal I didn't want to wait for that to occur first. > > -- > 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. P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Mon May 4 15:41:52 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 4 May 2009 12:41:52 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revised andforwarded to the Board In-Reply-To: <20090504190028.GB57395@ussenterprise.ufp.org> References: <49FF15ED.4070902@arin.net> <20090504190028.GB57395@ussenterprise.ufp.org> Message-ID: <074B794A4B8146CDA76C063644C02EA9@tedsdesk> Leo, IN 8.3: "... Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, AS A SINGLE AGGREGATE..." So yes, I quite believe that your statement that "own personal view on how this would work prior to finding this out was if Suzie couldn't receive Billy's /16 for any reason, Billy would retain the /16." is how MOST PEOPLE simply reading this policy proposal would interpret it. 2008-6 specificed exact match, also. Ted > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell > Sent: Monday, May 04, 2009 12:00 PM > To: arin ppml > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy > ? Revised andforwarded to the Board > > In a message written on Mon, May 04, 2009 at 12:21:01PM > -0400, Member Services wrote: > > The ARIN Advisory Council (AC) met on 29 April 2009 and decided to > > send a revised version of 2009-1 to the Board for their > consideration: > > This policy isn't in "last-call" per se, but given the PDP > process I feel this is the only appropriate time for me to > make these remarks. > > I am a member of the Advisory Council, speaking only for myself. > During the various reviews and discussions the Advisory > Council performs after the meeting a particular aspect of > this policy was brought to (most of?) the AC's attention. I > would like to bring it to the community's attention as well. > I did not write notes on this at the time, so I am doing this > from memory. If I get it wrong, I hope someone corrects me. > > Billy has a /16, and he's using it for dial up services which > is not paying the bills anymore. > > Suzie wants a /16 for her hot new social networking experiment. > > Billy and Suzie find each other and agree to transfer Billy's > /16 to Suzie under the result of 2008-6 + 2009-1. > > Billy goes to ARIN and says "Here's a /16, please give it to Suzie." > > Suzie goes to ARIN and says, "I'm here for Billy's /16". In > the process, ARIN checks Suzie's justification, and realizes > Suzie can only justify a /18. > > My understanding of the current interpretation of 2008-6 + > 2009-1 is that ARIN would give Suzie a /18, and keep a /18 > and /17 in the free pool. > > Billy has given up his /16, and Suzie only got a /18 of it. > > This ends up being an artifact of the legal requirement that > transfers must occur through ARIN. My own personal view on > how this would work prior to finding this out was if Suzie > couldn't receive Billy's > /16 for any reason, Billy would retain the /16. Thus my > surprise, and I'm wondering if this isn't a surprise for > others in the community. > > The recommended "fix", is that Suzie will be able to > "pre-qualify", that is go to ARIN with all of her paperwork > and get approved for a /18 before Billy and Suzie do a deal, > so Suzie knows this will not happen. > > I think this ends up being bad for three distinct reasons: > > Technically: > > This causes deaggregation. In the example given a /16 was > turned into > a /17 and two /18's. However, because a /17 and /18 are both now in > the free pool they may be further subdivided into /20's (or smaller, > in some cases). > > Business: > > It is likely Billy and Suzie exchanged something of value > during this > transaction to make it happen. Suzie has now "overpaid" > for her /18, > and is likely to demand a refund from Billy, or challenge ARIN's > stance she can only justify a /18, or both. Billy, of course, isn't > going to want to give a refund as he is out the entire /16, > but he may > also be unhappy at ARIN for only approving her for a /18. It sounds > like a good way to get all the parties in a transaction unhappy. > > But also, it opens up an interesting fraud. Alice could go to Billy > and offer to buy the /16 for a hundred million dollars. Billy gets > so excited over the idea of retiring from the dial up business that > he takes the deal. Alice gives him a fake check, and Billy > fills out > the ARIN paperwork. > > But you see, it is a fake check, and Alice had no intention of ever > justifying the addresses to ARIN. Billy figures out two weeks later > the check is fake from the bank, but he's already released > the addresses > to ARIN and can't get them back. What's Alice's motivation? Well, > her alter-ego Janice is sitting near the front of the line of folks > waiting for space to end up in the free pool. Good for her, a /16 > just showed up. > > But really this is all added risk, and what business wants to > participate in a system with extra risk? > > Politically: > > This interpretation of the policy is likely to affect the most > vulnerable the most. The savvy folks who are doing all sorts of > transfers are reading this post on PPML now, and will understand > the pitfalls of the system and work around these issues by doing > things like prequalifing. > > This issue is much more likely to trip up the "one time" casual > transferor or transferee who last delt with ARIN in 1999 and > doesn't do this as a day job anymore. They are the ones who will > accidently encounter this situation. > > Personally, I think ARIN should not let this happen. The > simplest fix I have come up with is to require Suzie to fill > out the recipient paperwork first. Billy should not be able > to designate a recipient without having some assurance that > end of the transaction is already approved from ARIN. This > could be as simple as Suzie giving Billy the ticket number > under which Suzie was approved, and Billy having to provide > that ticket number to release resources. In this way an > exact match could be insured, eliminating all of the problems > listed above. > > The AC obviously moved this proposal on; so this was not seen > as a show-stopper issue by the majority of the AC. At a > minimum, I wanted to get the issue out to the community so if > nothing is changed the community is aware of the issue and > will be able to avoid it. > I would hope this would end up documented on the ARIN web > site in fairly clear language as well; but given the > accelerated timetable for this proposal I didn't want to wait > for that to occur first. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > From kkargel at polartel.com Mon May 4 15:56:24 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 4 May 2009 14:56:24 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised and forwarded to the Board In-Reply-To: <49FF15ED.4070902@arin.net> References: <49FF15ED.4070902@arin.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail> I agree that this version of 2009-1 is much better than the last. I still believe that section 8.3 establishes a de facto commodities market in IPv4 addresses. It is still my opinion that any IP addresses surrendered should be made available to the community as a whole. Allowing specified recipients destroys the level playing field and will hurt the community. We are inviting speculators to take control of IP allocations, and allowing the establishment of IP brokerage houses. This is not a good thing for anyone except the profit takers that will take advantage of it. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Member Services > Sent: Monday, May 04, 2009 11:21 AM > To: arin ppml > Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised and > forwarded to the Board > > The ARIN Advisory Council (AC) met on 29 April 2009 and decided to send > a revised version of 2009-1 to the Board for their consideration: > > Draft Policy 2009-1: Transfer Policy > > The original 2009-1 is a result of the utilization the Emergency PDP > provision of the ARIN Policy Development Process by the ARIN Board of > Trustees. The AC was required to make a recommendation about 2009-1 > within 5 business days of the conclusion of the discussion period (the > discussion period for 2009-1 ended on 29 April 2009). The AC used the > feedback from the community on the PPML and at the Public Policy Meeting > in San Antonio as guidance in suggesting revisions to the draft policy > text. The PDP tasks the Board to review the AC's recommendation. > > The AC's revised version of 2009-1 is below. > > The ARIN Policy Development Process is available at: > > https://www.arin.net/policy/pdp.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > Draft Policy 2009-1 Transfer Policy as revised by the AC > > Originator: ARIN Board of Trustees (using the Emergency PDP provision in > the ARIN Policy Development Process) > > Date: 29 April 2009 > > Policy statement: > > Replace Section 8 as follows: > > *8. Transfers* > > *8.1. Principles* > Number resources are non-transferable and are not assignable to any > other organization unless ARIN has expressly and in writing approved a > request for transfer. ARIN is tasked with making prudent decisions on > whether to approve the transfer of number resources. > > It should be understood that number resources are not "sold" under ARIN > administration. Rather, number resources are assigned to an organization > for its exclusive use for the purpose stated in the request, provided > the terms of the Registration Services Agreement continue to be met and > the stated purpose for the number resources remains the same. Number > resources are administered and assigned according to ARIN's published > policies. > > Number resources are issued, based on justified need, to organizations, > not to individuals representing those organizations. Thus, if a company > goes out of business, regardless of the reason, the point of contact > (POC) listed for the number resource does not have the authority to > sell, transfer, assign, or give the number resource to any other person > or organization. The POC must notify ARIN if a business fails so the > assigned number resources can be returned to the available pool of > number resources if a transfer is not requested and justified. > > *8.2. Mergers and Acquisitions* > ARIN will consider requests for the transfer of number resources in the > case of mergers and acquisitions upon receipt of evidence that the new > entity has acquired the assets which had, as of the date of the > acquisition or proposed reorganization, justified the current entity's > use of the number resource. Examples of assets that justify use of the > number resource include, but are not limited to: > > * Existing customer base > * Qualified hardware inventory > * Specific software requirements. > > In evaluating a request for transfer, ARIN may require the requesting > organization to provide any of the following documents, as applicable, > plus any other documents deemed appropriate: > > * An authenticated copy of the instrument(s) effecting the transfer > of assets, e.g., bill of sale, certificate of merger, contract, > deed, or court decree. > * A detailed inventory of all assets utilized by the requesting > party in maintaining and using the number resource. > * A list of the requesting party's customers using the number resource. > > If further justification is required, the requesting party may be asked > to provide any of the following, or other supporting documentation, as > applicable: > > * A general listing of the assets or components acquired > * A specific description of acquisitions, including: > > o Type and quantity of equipment > o Customer base > > * A description of how number resources are being utilized > * Network engineering plans, including: > > Host counts > Subnet masking > Network diagrams > Reassignments to customers > > *8.3 Transfers to Specified Recipients* > IPv4 number resources within the ARIN region may be released to ARIN by > the authorized resource holder, in whole or in part, for transfer to > another specified organizational recipient. Such transferred number > resources may only be received under RSA by organizations that are > within the ARIN region and can demonstrate the need for such resources, > as a single aggregate, in the exact amount which they can justify under > current ARIN policies. > > ##### > > Changes to 2009-1 as revised by the AC: > > * Removed 2.8 organization definition > * Limited to IPv4 address space > * Maintained ARIN as the intermediary > * Maintained requirement of source and recipient being in region, > and explicitly added the RSA requirement > *Added text to clarify need must be a single aggregate > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 Mon May 4 16:18:08 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 4 May 2009 15:18:08 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised and forwarded to the Board In-Reply-To: <49FF4A18.90503@matthew.at> References: <49FF15ED.4070902@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail> <49FF4A18.90503@matthew.at> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> > -----Original Message----- > From: Matthew Kaufman [mailto:matthew at matthew.at] > Sent: Monday, May 04, 2009 3:04 PM > To: Kevin Kargel > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised > and forwarded to the Board > > Kevin Kargel wrote: > > I agree that this version of 2009-1 is much better than the last. > > > > I still believe that section 8.3 establishes a de facto commodities > market > > in IPv4 addresses. It is still my opinion that any IP addresses > surrendered > > should be made available to the community as a whole. > > > > > If there's IP addresses that would be available if financial leverage > was applied (for instance, people who could buy a big NAT with some of > the money and release most of what they're using now), and you believe > that the addresses surrendered should be made available under the > existing inexpensive first-come, first-served basis, then perhaps either > you or ARIN should find a way to outbid the people who'll be using this > or the existing transfer policies to acquire addresses after run-out, > and do that. > > We already have a way to free up the addresses that people are willing > to turn back in with no renumeration... what, other than you or ARIN > applying money to the problem will free up others? > > Matthew Kaufman Why do we have to force others to free up IP addresses in the first place? Why do you think that creating a commodities market is mandatory? Why do you think that money is the only motivator? Continuing on the established functional road without fixing what isn't broken is a very legitimate option. Perhaps you would be surprised to discover that if there were not an artificial value placed on IPv4 space then as it became less useful organizations would return it voluntarily. So long as there is the possibility that we are going to establish and allow an IP commodities market then nobody - including me - is ever going to be able to voluntarily return space. The bean counters won't allow it. Rather than helping the problem the fact that this market is being discussed is exactly what is causing the hoarding. By holding the carrot of financial gain in front of resource holders you are guaranteeing that none of them (with the exception of government) will be able to return space. The cure is actually exacerbating the condition. What will ease the problem will be if ARIN states unequivocally that orgs will never be able to legally get monetary reward for IP addresses. At that point Admins will have the freedom to return IPv4 space. Most organizations try to operate legally and ethically. Most organizations are concerned about the health of the community. Creating an IPv4 commodities market is very definitely an example of 'cutting off your nose to spite your face'. -------------- 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 May 4 16:38:34 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 4 May 2009 15:38:34 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised and forwarded to the Board In-Reply-To: <49FF4A18.90503@matthew.at> References: <49FF15ED.4070902@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail> <49FF4A18.90503@matthew.at> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B1@mail> > > We already have a way to free up the addresses that people are willing > to turn back in with no renumeration... what, other than you or ARIN > applying money to the problem will free up others? > > Matthew Kaufman There are many motivators that will work besides greed. Remember the group of people you are working with. Status and recognition come to mind as excellent motivators off the top of my head. I bet there would be a rush to turn in space if a market were not a possibility and for a limited time you could get a t-shirt and a coffee cup that said "I helped save the Internet by returning 4,096 IP addresses!" Other things that may be considered could be lifetime ARIN membership status for POC's that return space, or perhaps trusted and expedited service or privilege in some area within ARIN's domain? Even something as simple as getting an arin.net address to tie to the POC might make a difference. It doesn't take that big a push to get people to act responsibly and ethically if that option is not swamped by gross financial incentive. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From tedm at ipinc.net Mon May 4 17:40:21 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 4 May 2009 14:40:21 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revisedandforwarded to the Board In-Reply-To: References: <20090504190028.GB57395@ussenterprise.ufp.org> Message-ID: <22D8831E297C4E65AD76184F0A5EC3A5@tedsdesk> AC had no need to make further policy to deal with the impact since 2008-6 had an automatic sunset. The entire point of the sunset in 2008-6 was to see what the unintended consequences would be and the only way to find them out was to implement the policy and see what happened. I think most people expected that after a year or so of 2008-6 that, armed with the knowledge learned from the experiment, we would write a much more comprehensive policy that would supersede 2008-6. The sunset was a deadline that guaranteed this would happen. Ted _____ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Sweeting Sent: Monday, May 04, 2009 12:28 PM To: Leo Bicknell; arin ppml Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revisedandforwarded to the Board A few more bits of information. One reason that the AC moved this proposal forward was that 2008-6 was already approved and set to be implemented on June 1 so the issue was already there. I believe it was accepted that the AC would make further review and come up with a proposal that would deal with this impact. Also a point to note is that this policy must be recertified at the next Public Policy Meeting since it went through the Emergency Policy process. On 5/4/09 3:00 PM, "Leo Bicknell" wrote: In a message written on Mon, May 04, 2009 at 12:21:01PM -0400, Member Services wrote: > The ARIN Advisory Council (AC) met on 29 April 2009 and decided to send > a revised version of 2009-1 to the Board for their consideration: This policy isn't in "last-call" per se, but given the PDP process I feel this is the only appropriate time for me to make these remarks. I am a member of the Advisory Council, speaking only for myself. During the various reviews and discussions the Advisory Council performs after the meeting a particular aspect of this policy was brought to (most of?) the AC's attention. I would like to bring it to the community's attention as well. I did not write notes on this at the time, so I am doing this from memory. If I get it wrong, I hope someone corrects me. Billy has a /16, and he's using it for dial up services which is not paying the bills anymore. Suzie wants a /16 for her hot new social networking experiment. Billy and Suzie find each other and agree to transfer Billy's /16 to Suzie under the result of 2008-6 + 2009-1. Billy goes to ARIN and says "Here's a /16, please give it to Suzie." Suzie goes to ARIN and says, "I'm here for Billy's /16". In the process, ARIN checks Suzie's justification, and realizes Suzie can only justify a /18. My understanding of the current interpretation of 2008-6 + 2009-1 is that ARIN would give Suzie a /18, and keep a /18 and /17 in the free pool. Billy has given up his /16, and Suzie only got a /18 of it. This ends up being an artifact of the legal requirement that transfers must occur through ARIN. My own personal view on how this would work prior to finding this out was if Suzie couldn't receive Billy's /16 for any reason, Billy would retain the /16. Thus my surprise, and I'm wondering if this isn't a surprise for others in the community. The recommended "fix", is that Suzie will be able to "pre-qualify", that is go to ARIN with all of her paperwork and get approved for a /18 before Billy and Suzie do a deal, so Suzie knows this will not happen. I think this ends up being bad for three distinct reasons: Technically: This causes deaggregation. In the example given a /16 was turned into a /17 and two /18's. However, because a /17 and /18 are both now in the free pool they may be further subdivided into /20's (or smaller, in some cases). Business: It is likely Billy and Suzie exchanged something of value during this transaction to make it happen. Suzie has now "overpaid" for her /18, and is likely to demand a refund from Billy, or challenge ARIN's stance she can only justify a /18, or both. Billy, of course, isn't going to want to give a refund as he is out the entire /16, but he may also be unhappy at ARIN for only approving her for a /18. It sounds like a good way to get all the parties in a transaction unhappy. But also, it opens up an interesting fraud. Alice could go to Billy and offer to buy the /16 for a hundred million dollars. Billy gets so excited over the idea of retiring from the dial up business that he takes the deal. Alice gives him a fake check, and Billy fills out the ARIN paperwork. But you see, it is a fake check, and Alice had no intention of ever justifying the addresses to ARIN. Billy figures out two weeks later the check is fake from the bank, but he's already released the addresses to ARIN and can't get them back. What's Alice's motivation? Well, her alter-ego Janice is sitting near the front of the line of folks waiting for space to end up in the free pool. Good for her, a /16 just showed up. But really this is all added risk, and what business wants to participate in a system with extra risk? Politically: This interpretation of the policy is likely to affect the most vulnerable the most. The savvy folks who are doing all sorts of transfers are reading this post on PPML now, and will understand the pitfalls of the system and work around these issues by doing things like prequalifing. This issue is much more likely to trip up the "one time" casual transferor or transferee who last delt with ARIN in 1999 and doesn't do this as a day job anymore. They are the ones who will accidently encounter this situation. Personally, I think ARIN should not let this happen. The simplest fix I have come up with is to require Suzie to fill out the recipient paperwork first. Billy should not be able to designate a recipient without having some assurance that end of the transaction is already approved from ARIN. This could be as simple as Suzie giving Billy the ticket number under which Suzie was approved, and Billy having to provide that ticket number to release resources. In this way an exact match could be insured, eliminating all of the problems listed above. The AC obviously moved this proposal on; so this was not seen as a show-stopper issue by the majority of the AC. At a minimum, I wanted to get the issue out to the community so if nothing is changed the community is aware of the issue and will be able to avoid it. I would hope this would end up documented on the ARIN web site in fairly clear language as well; but given the accelerated timetable for this proposal I didn't want to wait for that to occur first. -- 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. P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Mon May 4 17:49:27 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 4 May 2009 14:49:27 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revisedandforwarded to the Board In-Reply-To: <22D8831E297C4E65AD76184F0A5EC3A5@tedsdesk> References: <20090504190028.GB57395@ussenterprise.ufp.org> <22D8831E297C4E65AD76184F0A5EC3A5@tedsdesk> Message-ID: <38C5FAC4-4930-417D-A22F-42594F5570E5@gmail.com> Ted, I feel that a 3-year sunset would be bad policy given the immediate imlementation of 2008-6. I think 5 years, or 3 years after IANA exhaustion, would be appropriate, but I feel that would be best discussed as a normal policy proposal. Anyone is welcome to introduce such a policy if you think it's important. It would most likely be on the agenda this fall along with 2009-1. -Scott On May 4, 2009, at 2:40 PM, "Ted Mittelstaedt" wrote: > AC had no need to make further policy to deal with the impact since > 2008-6 had an > automatic sunset. The entire point of the sunset in 2008-6 was to > see what the > unintended consequences would be and the only way to find them out > was to > implement the policy and see what happened. I think most people > expected that > after a year or so of 2008-6 that, armed with the knowledge learned > from the > experiment, we would write a much more comprehensive policy that would > supersede 2008-6. The sunset was a deadline that guaranteed this > would > happen. > > Ted > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of John Sweeting > Sent: Monday, May 04, 2009 12:28 PM > To: Leo Bicknell; arin ppml > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? > Revisedandforwarded to the Board > > A few more bits of information. One reason that the AC moved this > proposal forward was that 2008-6 was already approved and set to be > implemented on June 1 so the issue was already there. I believe it > was accepted that the AC would make further review and come up with > a proposal that would deal with this impact. Also a point to note is > that this policy must be recertified at the next Public Policy > Meeting since it went through the Emergency Policy process. > > > On 5/4/09 3:00 PM, "Leo Bicknell" wrote: > > > In a message written on Mon, May 04, 2009 at 12:21:01PM -0400, > Member Services wrote: > > The ARIN Advisory Council (AC) met on 29 April 2009 and decided to > send > > a revised version of 2009-1 to the Board for their consideration: > > This policy isn't in "last-call" per se, but given the PDP process > I feel this is the only appropriate time for me to make these > remarks. > > I am a member of the Advisory Council, speaking only for myself. > During the various reviews and discussions the Advisory Council > performs after the meeting a particular aspect of this policy was > brought to (most of?) the AC's attention. I would like to bring > it to the community's attention as well. I did not write notes on > this at the time, so I am doing this from memory. If I get it > wrong, I hope someone corrects me. > > Billy has a /16, and he's using it for dial up services which is > not paying the bills anymore. > > Suzie wants a /16 for her hot new social networking experiment. > > Billy and Suzie find each other and agree to transfer Billy's /16 > to Suzie under the result of 2008-6 + 2009-1. > > Billy goes to ARIN and says "Here's a /16, please give it to Suzie." > > Suzie goes to ARIN and says, "I'm here for Billy's /16". In the > process, ARIN checks Suzie's justification, and realizes Suzie can > only justify a /18. > > My understanding of the current interpretation of 2008-6 + 2009-1 > is that ARIN would give Suzie a /18, and keep a /18 and /17 in the > free pool. > > Billy has given up his /16, and Suzie only got a /18 of it. > > This ends up being an artifact of the legal requirement that transfers > must occur through ARIN. My own personal view on how this would > work prior to finding this out was if Suzie couldn't receive Billy's > /16 for any reason, Billy would retain the /16. Thus my surprise, > and I'm wondering if this isn't a surprise for others in the > community. > > The recommended "fix", is that Suzie will be able to "pre-qualify", > that is go to ARIN with all of her paperwork and get approved for > a /18 before Billy and Suzie do a deal, so Suzie knows this will > not happen. > > I think this ends up being bad for three distinct reasons: > > Technically: > > This causes deaggregation. In the example given a /16 was turned > into > a /17 and two /18's. However, because a /17 and /18 are both now in > the free pool they may be further subdivided into /20's (or smaller, > in some cases). > > Business: > > It is likely Billy and Suzie exchanged something of value during > this > transaction to make it happen. Suzie has now "overpaid" for her / > 18, > and is likely to demand a refund from Billy, or challenge ARIN's > stance she can only justify a /18, or both. Billy, of course, isn't > going to want to give a refund as he is out the entire /16, but he > may > also be unhappy at ARIN for only approving her for a /18. It sounds > like a good way to get all the parties in a transaction unhappy. > > But also, it opens up an interesting fraud. Alice could go to Billy > and offer to buy the /16 for a hundred million dollars. Billy gets > so excited over the idea of retiring from the dial up business that > he takes the deal. Alice gives him a fake check, and Billy fills > out > the ARIN paperwork. > > But you see, it is a fake check, and Alice had no intention of ever > justifying the addresses to ARIN. Billy figures out two weeks later > the check is fake from the bank, but he's already released the > addresses > to ARIN and can't get them back. What's Alice's motivation? Well, > her alter-ego Janice is sitting near the front of the line of folks > waiting for space to end up in the free pool. Good for her, a /16 > just showed up. > > But really this is all added risk, and what business wants to > participate in a system with extra risk? > > Politically: > > This interpretation of the policy is likely to affect the most > vulnerable the most. The savvy folks who are doing all sorts of > transfers are reading this post on PPML now, and will understand > the pitfalls of the system and work around these issues by doing > things like prequalifing. > > This issue is much more likely to trip up the "one time" casual > transferor or transferee who last delt with ARIN in 1999 and > doesn't do this as a day job anymore. They are the ones who will > accidently encounter this situation. > > Personally, I think ARIN should not let this happen. The simplest > fix I have come up with is to require Suzie to fill out the recipient > paperwork first. Billy should not be able to designate a recipient > without having some assurance that end of the transaction is already > approved from ARIN. This could be as simple as Suzie giving Billy > the ticket number under which Suzie was approved, and Billy having > to provide that ticket number to release resources. In this way > an exact match could be insured, eliminating all of the problems > listed above. > > The AC obviously moved this proposal on; so this was not seen as a > show-stopper issue by the majority of the AC. At a minimum, I > wanted to get the issue out to the community so if nothing is changed > the community is aware of the issue and will be able to avoid it. > I would hope this would end up documented on the ARIN web site in > fairly clear language as well; but given the accelerated timetable > for this proposal I didn't want to wait for that to occur first. > > -- > 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. > > P Go Green! Print this email only when necessary. Thank you for > helping Time Warner Cable be environmentally responsible. > > > > > This E-mail and any of its attachments may contain Time Warner > Cable proprietary information, which is privileged, confidential, > or subject to copyright belonging to Time Warner Cable. This E-mail > is intended solely for the use of the individual or entity to which > it is addressed. If you are not the intended recipient of this > E-mail, you are hereby notified that any dissemination, > distribution, copying, or action taken in relation to the contents > of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.hannigan at batelnet.bs Mon May 4 17:57:27 2009 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Mon, 4 May 2009 17:57:27 -0400 Subject: [arin-ppml] Mighten it happen like this? In-Reply-To: <75822E125BCB994F8446858C4B19F0D775EEC301@SUEX07-MBX-04.ad.syr.edu> References: <8E4BFEDAB8434B80A198B89373F2AF1C@tedsdesk> <75822E125BCB994F8446858C4B19F0D775EEC301@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4607e1d50905041457u1017f239j2080700c6de26925@mail.gmail.com> ....And policy will _follow_ most of these problems. Just like in the real world. Best, Marty On 5/3/09, Milton L Mueller wrote: > Nice. You're starting to think like an economist. > > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Ted Mittelstaedt >> Sent: Thursday, April 30, 2009 6:06 PM >> To: 'ARIN PPML' >> Subject: [arin-ppml] Mighten it happen like this? >> >> >> In thinking about this IPv4 runout it occurs to me that it might possible >> go something like this. >> >> After the last /8 is assigned to ARIN, the hostmasters there will get out >> their knives and start slicing off subnets from it. A handful of Very >> Large >> requests will be satisfied from it, then a lot more smaller requests, then >> the /8 will be as the turkey is on the platter during the last >> Thanksgiving >> - >> the large breasts gutted but still plenty of edible meat in smaller >> chunks. >> >> Then the reclamation efforts will start turning up even smaller and >> smaller >> chunks of IPv4 abandonded years earlier - nothing to satisfy the large >> consumers, >> but still plenty of smaller tasty bits. And in the meantime they will >> still >> be stripping the carcass of the /8 for the last usable bits. >> >> Then the carcass will be done and reclamation will be in full swing now - >> but >> the IPv4 coming in from reclamation will be somewhat less tasty - >> ex-spammers >> blocks, stinky old swampland that may or may not have been used. >> >> Then reclamation will start petering off and the IPv4 bits coming in from >> it >> will be very nasty indeed - blocks with squatters in it that the obtainer >> of the block will have to actively evict, blocks where the original >> occupier >> is still fighting with ARIN over ownership. >> >> Then they will get down to the nitty-gritty of trying to piece together >> minimal >> sized blocks to allocate from scattered /24's some of which are >> abandonded, >> some >> not - begging and pleading with owners to please move over to this other >> /24 >> so >> we can use the one your on to aggregate together a larger block. >> >> Somewhere along the way some kind of transfer market may spring up - short >> lived >> though it may be, with a few folks making a killing off selling blocks - >> but >> as >> time passes it will die down. >> >> During this time the number of orgs wanting IPv4 will be decreasing as >> more >> and more of the requestors give up hope of getting usable IPv4 and more >> and >> more >> of them migrate to IPv6. >> >> So, perhaps maybe fully 4 years after the last /8 is allocated to ARIN >> then >> the >> very last aggregated subnet of any size will be given out - reclamation >> will >> be >> exhausted, and pretty much nobody will have any hope left of getting IPv4 >> allocations >> except from the transfer market. That might mark the "official" end of >> ARIN-assigned >> "free" IPv4. >> >> The transfer market will be peaking right around now - as prices get so >> rediculous >> that it becomes cost effective for even the most retrogade networks to go >> to >> IPv6. >> >> Then a tipping point will be reached and over a few months the bottom will >> drop >> out of the transfer market and the market will crash, and we will see the >> commencement >> of an accellerated schedule of more and more networks dropping IPv4. >> >> A few years after that then reports will begin to show up of routing >> unreliability >> of the IPv4 Internet in certain spots on the Internet. >> >> By 4 years after the "official end" of ARIN-assigned IPv4, we will start >> to >> see >> websites set up with countdown clocks predicting the very last day that >> IPv4 >> traffic >> will exist on the Internet. >> >> Then, sometime in 2020, some politician will send an e-mail titled >> "Goodbye" >> at a >> ribbon-cutting ceremony that will mark the last time that a real IPv4 >> packet >> will >> be sent over the public Internet from a public client to a public server. >> >> Around 2025, Cisco will make proficiency in IPv4 an optional part of it's >> assesment test. >> >> Around 2030, Juniper and Cisco will release firmware that won't have IPv4 >> support in >> the base load. >> >> Does seem like a realistic end-game? >> >> Ted >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 Tue May 5 08:37:39 2009 From: Fred.Wettling at Bechtel.com (Wettling, Fred) Date: Tue, 5 May 2009 08:37:39 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised and forwarded to the Board In-Reply-To: <49FF15ED.4070902@arin.net> References: <49FF15ED.4070902@arin.net> Message-ID: -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services Sent: Monday, May 04, 2009 12:21 PM To: arin ppml *8.2. Mergers and Acquisitions* *8.3 Transfers to Specified Recipients* RESPONSE from Fred Wettling Revised 2009-1 is looking good. I suggest sections 8.2 & 8.3 be revised to accommodate divestitures. VMware is an example... Founded in 1998 (new allocation); acquired by EMC in 2004 (M&A); IPO in August 2007 (Divestiture) From vixie at isc.org Tue May 5 15:50:39 2009 From: vixie at isc.org (Paul Vixie) Date: Tue, 05 May 2009 19:50:39 +0000 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised and forwarded to the Board In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail> (Kevin Kargel's message of "Mon\, 4 May 2009 14\:56\:24 -0500") References: <49FF15ED.4070902@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail> Message-ID: kkargel at polartel.com ("Kevin Kargel") writes: > I agree that this version of 2009-1 is much better than the last. > > I still believe that section 8.3 establishes a de facto commodities > market in IPv4 addresses. It is still my opinion that any IP addresses > surrendered should be made available to the community as a whole. > > Allowing specified recipients destroys the level playing field and will > hurt the community. > > We are inviting speculators to take control of IP allocations, and > allowing the establishment of IP brokerage houses. This is not a good > thing for anyone except the profit takers that will take advantage of it. kevin, can you look at , and tell us whether this policy (which has been adopted but not implemented) also appears to have the flaw you're describing here? 2009-1 is a cleanup of 2008-6, so if you're objecting to specified recipients in 2009-1, then i wonder if you also object to specified recipients in 2008-6 (as adopted)? -- Paul Vixie Chair, ARIN BoT KI6YSY From tedm at ipinc.net Tue May 5 18:19:04 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 5 May 2009 15:19:04 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revisedandforwarded to the Board In-Reply-To: <38C5FAC4-4930-417D-A22F-42594F5570E5@gmail.com> References: <20090504190028.GB57395@ussenterprise.ufp.org> <22D8831E297C4E65AD76184F0A5EC3A5@tedsdesk> <38C5FAC4-4930-417D-A22F-42594F5570E5@gmail.com> Message-ID: <5EE810004162480AA9761B240FB6C89E@tedsdesk> Scott, Owen already attempted to submit a policy change to 2009-1 that re-instituted the sunset clause into 2009-1 and on April 8th the AC used (IMHO) a procedural trick to abandon his policy submission, claiming that 2009-1 is already reviewing whether to remove a sunset clause from the NRPM or not. Of course, all "reviewing" has come up with NOT reintroducing the sunset clause, (a foregone conclusion) so when 2009-1 is instituted it will have no sunset clause. That is very strong disincentive from the Board to use sunset clauses on this transfer market business. It is also very strong disincentive to ever again bother with submitting any proposals at all. Ted _____ From: Scott Leibrand [mailto:scottleibrand at gmail.com] Sent: Monday, May 04, 2009 2:49 PM To: Ted Mittelstaedt Cc: John Sweeting; arin ppml Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revisedandforwarded to the Board Ted, I feel that a 3-year sunset would be bad policy given the immediate imlementation of 2008-6. I think 5 years, or 3 years after IANA exhaustion, would be appropriate, but I feel that would be best discussed as a normal policy proposal. Anyone is welcome to introduce such a policy if you think it's important. It would most likely be on the agenda this fall along with 2009-1. -Scott On May 4, 2009, at 2:40 PM, "Ted Mittelstaedt" wrote: AC had no need to make further policy to deal with the impact since 2008-6 had an automatic sunset. The entire point of the sunset in 2008-6 was to see what the unintended consequences would be and the only way to find them out was to implement the policy and see what happened. I think most people expected that after a year or so of 2008-6 that, armed with the knowledge learned from the experiment, we would write a much more comprehensive policy that would supersede 2008-6. The sunset was a deadline that guaranteed this would happen. Ted _____ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Sweeting Sent: Monday, May 04, 2009 12:28 PM To: Leo Bicknell; arin ppml Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revisedandforwarded to the Board A few more bits of information. One reason that the AC moved this proposal forward was that 2008-6 was already approved and set to be implemented on June 1 so the issue was already there. I believe it was accepted that the AC would make further review and come up with a proposal that would deal with this impact. Also a point to note is that this policy must be recertified at the next Public Policy Meeting since it went through the Emergency Policy process. On 5/4/09 3:00 PM, "Leo Bicknell" wrote: In a message written on Mon, May 04, 2009 at 12:21:01PM -0400, Member Services wrote: > The ARIN Advisory Council (AC) met on 29 April 2009 and decided to send > a revised version of 2009-1 to the Board for their consideration: This policy isn't in "last-call" per se, but given the PDP process I feel this is the only appropriate time for me to make these remarks. I am a member of the Advisory Council, speaking only for myself. During the various reviews and discussions the Advisory Council performs after the meeting a particular aspect of this policy was brought to (most of?) the AC's attention. I would like to bring it to the community's attention as well. I did not write notes on this at the time, so I am doing this from memory. If I get it wrong, I hope someone corrects me. Billy has a /16, and he's using it for dial up services which is not paying the bills anymore. Suzie wants a /16 for her hot new social networking experiment. Billy and Suzie find each other and agree to transfer Billy's /16 to Suzie under the result of 2008-6 + 2009-1. Billy goes to ARIN and says "Here's a /16, please give it to Suzie." Suzie goes to ARIN and says, "I'm here for Billy's /16". In the process, ARIN checks Suzie's justification, and realizes Suzie can only justify a /18. My understanding of the current interpretation of 2008-6 + 2009-1 is that ARIN would give Suzie a /18, and keep a /18 and /17 in the free pool. Billy has given up his /16, and Suzie only got a /18 of it. This ends up being an artifact of the legal requirement that transfers must occur through ARIN. My own personal view on how this would work prior to finding this out was if Suzie couldn't receive Billy's /16 for any reason, Billy would retain the /16. Thus my surprise, and I'm wondering if this isn't a surprise for others in the community. The recommended "fix", is that Suzie will be able to "pre-qualify", that is go to ARIN with all of her paperwork and get approved for a /18 before Billy and Suzie do a deal, so Suzie knows this will not happen. I think this ends up being bad for three distinct reasons: Technically: This causes deaggregation. In the example given a /16 was turned into a /17 and two /18's. However, because a /17 and /18 are both now in the free pool they may be further subdivided into /20's (or smaller, in some cases). Business: It is likely Billy and Suzie exchanged something of value during this transaction to make it happen. Suzie has now "overpaid" for her /18, and is likely to demand a refund from Billy, or challenge ARIN's stance she can only justify a /18, or both. Billy, of course, isn't going to want to give a refund as he is out the entire /16, but he may also be unhappy at ARIN for only approving her for a /18. It sounds like a good way to get all the parties in a transaction unhappy. But also, it opens up an interesting fraud. Alice could go to Billy and offer to buy the /16 for a hundred million dollars. Billy gets so excited over the idea of retiring from the dial up business that he takes the deal. Alice gives him a fake check, and Billy fills out the ARIN paperwork. But you see, it is a fake check, and Alice had no intention of ever justifying the addresses to ARIN. Billy figures out two weeks later the check is fake from the bank, but he's already released the addresses to ARIN and can't get them back. What's Alice's motivation? Well, her alter-ego Janice is sitting near the front of the line of folks waiting for space to end up in the free pool. Good for her, a /16 just showed up. But really this is all added risk, and what business wants to participate in a system with extra risk? Politically: This interpretation of the policy is likely to affect the most vulnerable the most. The savvy folks who are doing all sorts of transfers are reading this post on PPML now, and will understand the pitfalls of the system and work around these issues by doing things like prequalifing. This issue is much more likely to trip up the "one time" casual transferor or transferee who last delt with ARIN in 1999 and doesn't do this as a day job anymore. They are the ones who will accidently encounter this situation. Personally, I think ARIN should not let this happen. The simplest fix I have come up with is to require Suzie to fill out the recipient paperwork first. Billy should not be able to designate a recipient without having some assurance that end of the transaction is already approved from ARIN. This could be as simple as Suzie giving Billy the ticket number under which Suzie was approved, and Billy having to provide that ticket number to release resources. In this way an exact match could be insured, eliminating all of the problems listed above. The AC obviously moved this proposal on; so this was not seen as a show-stopper issue by the majority of the AC. At a minimum, I wanted to get the issue out to the community so if nothing is changed the community is aware of the issue and will be able to avoid it. I would hope this would end up documented on the ARIN web site in fairly clear language as well; but given the accelerated timetable for this proposal I didn't want to wait for that to occur first. -- 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. P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Tue May 5 18:36:59 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 5 May 2009 15:36:59 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> Message-ID: <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel > Sent: Monday, May 04, 2009 1:18 PM > To: matthew at matthew.at > Cc: arin ppml > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy > - Revised andforwarded to the Board > > Rather than helping the problem the fact that this market is > being discussed is exactly what is causing the hoarding. I have to cry foul with this. There's been implications of hoarding on this list and in the last meeting but I have only seen a single allegation posted on this list of an illigitimate IPv4 holding, and that was a year ago. (and it wasn't a hoarding situation) Since true hoarding implies false data submitted for an IPv4 application, if anyone hs any concrete evidence that someone has falsified an application then they should immediately post it, as well as turn it over to ARIN's hostmaster. We have no problems in the US with posting all manner of discovered illegalities of companies doing actions like illegal dumping, so I see no legal barrier to yelling foul if you can prove that someone's cheating with an IPv4 application. I agree that once an unrestricted transfer proposal is in NRPM that it will be an incentive to hoard, but it isn't in the NRPM yet. And once it is in, it will only be an incentive, we don't know if people will actually cheat/hoard. Remember, the people who are pusing this transfer thing are ALSO waving around the spectre of hoarding as an emotional appeal to try to get support for their transfer allowance into the NRPM. Please take the high road on this. Ted From tedm at ipinc.net Tue May 5 18:38:47 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 5 May 2009 15:38:47 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B1@mail> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B1@mail> Message-ID: <9399B5FF76AC45CC8EDE842F4124FC8B@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel > Sent: Monday, May 04, 2009 1:39 PM > To: matthew at matthew.at > Cc: arin ppml > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy > - Revised andforwarded to the Board > > > > > We already have a way to free up the addresses that people > are willing > > to turn back in with no renumeration... what, other than > you or ARIN > > applying money to the problem will free up others? > > > > Matthew Kaufman > > There are many motivators that will work besides greed. > Remember the group of people you are working with. Status > and recognition come to mind as excellent motivators off the > top of my head. > > I bet there would be a rush to turn in space if a market were > not a possibility and for a limited time you could get a > t-shirt and a coffee cup that said "I helped save the > Internet by returning 4,096 IP addresses!" > I'd rather see: "I helped save the Internet by deploying IPv6 addresses!" Maybe ARIN can put this on a bumper sticker for distribution at the next trade show? Ted From kkargel at polartel.com Tue May 5 18:59:56 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 5 May 2009 17:59:56 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Tuesday, May 05, 2009 5:37 PM > To: Kevin Kargel; matthew at matthew.at > Cc: 'arin ppml' > Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised > andforwarded to the Board > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel > > Sent: Monday, May 04, 2009 1:18 PM > > To: matthew at matthew.at > > Cc: arin ppml > > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy > > - Revised andforwarded to the Board > > > > > Rather than helping the problem the fact that this market is > > being discussed is exactly what is causing the hoarding. > > I have to cry foul with this. There's been implications > of hoarding on this list and in the last meeting but I have only > seen a single allegation posted on this list of an illigitimate > IPv4 holding, and that was a year ago. (and it wasn't a hoarding > situation) Cry foul all you want but the situation still exists. Perhaps I am misusing the term 'hoarding'. Please suggest another term for "holding on to unused IPv4 space with disregard for the good of the community until the IPv4 space is worth a lot of money so I can sell it". At this point whether or not the applications for space were filled out faithfully is moot. Also much of the unused space was granted long before the applications we use today existed. > > Since true hoarding implies false data submitted for an IPv4 > application, if anyone hs any concrete evidence that someone has > falsified an application then they should immediately post it, > as well as turn it over to ARIN's hostmaster. > > We have no problems in the US with posting all manner of > discovered illegalities of companies doing actions like illegal > dumping, so I see no legal barrier to yelling foul if you > can prove that someone's cheating with an IPv4 application. > > I agree that once an unrestricted transfer proposal is in NRPM that > it will be an incentive to hoard, but it isn't in the NRPM yet. > And once it is in, it will only be an incentive, we don't know > if people will actually cheat/hoard. You don't think 2008-6 is an unrestricted transfer proposal? > > Remember, the people who are pusing this transfer thing are ALSO > waving around the spectre of hoarding as an emotional appeal to > try to get support for their transfer allowance into the NRPM. Please > take the high road on this. I believe I am taking the high road and looking out for what IMO is the good of the community. I just happen to believe that it is necessary in this instance to be vocal. I very rarely purposefully take the low road. > > Ted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From scottleibrand at gmail.com Tue May 5 19:24:19 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 05 May 2009 16:24:19 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revisedandforwarded to the Board In-Reply-To: <5EE810004162480AA9761B240FB6C89E@tedsdesk> References: <20090504190028.GB57395@ussenterprise.ufp.org> <22D8831E297C4E65AD76184F0A5EC3A5@tedsdesk> <38C5FAC4-4930-417D-A22F-42594F5570E5@gmail.com> <5EE810004162480AA9761B240FB6C89E@tedsdesk> Message-ID: <4A00CAA3.5030906@gmail.com> Ted, Owen's proposal was rejected by the AC simply because the timing was poor. If a similar proposal were to be resubmitted (by Owen or anyone else) I would vote to accept it onto our docket, develop it into draft policy, and have it on the agenda at the fall meeting. -Scott Ted Mittelstaedt wrote: > Scott, > > Owen already attempted to submit a policy change to 2009-1 that > re-instituted the sunset clause into 2009-1 > and on April 8th the AC used (IMHO) a procedural trick to abandon his > policy submission, claiming that 2009-1 > is already reviewing whether to remove a sunset clause from the NRPM > or not. Of course, all "reviewing" has > come up with NOT reintroducing the sunset clause, (a foregone > conclusion) so when 2009-1 is instituted it will > have no sunset clause. > > That is very strong disincentive from the Board to use sunset > clauses on this transfer market business. > It is also very strong disincentive to ever again bother with > submitting any proposals at all. > > Ted > > ------------------------------------------------------------------------ > *From:* Scott Leibrand [mailto:scottleibrand at gmail.com] > *Sent:* Monday, May 04, 2009 2:49 PM > *To:* Ted Mittelstaedt > *Cc:* John Sweeting; arin ppml > *Subject:* Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? > Revisedandforwarded to the Board > > Ted, > > I feel that a 3-year sunset would be bad policy given the > immediate imlementation of 2008-6. I think 5 years, or 3 years > after IANA exhaustion, would be appropriate, but I feel that would > be best discussed as a normal policy proposal. Anyone is welcome > to introduce such a policy if you think it's important. It would > most likely be on the agenda this fall along with 2009-1. > > -Scott > > On May 4, 2009, at 2:40 PM, "Ted Mittelstaedt" > wrote: > >> AC had no need to make further policy to deal with the impact >> since 2008-6 had an >> automatic sunset. The entire point of the sunset in 2008-6 was >> to see what the >> unintended consequences would be and the only way to find them >> out was to >> implement the policy and see what happened. I think most people >> expected that >> after a year or so of 2008-6 that, armed with the knowledge >> learned from the >> experiment, we would write a much more comprehensive policy that >> would >> supersede 2008-6. The sunset was a deadline that guaranteed this >> would >> happen. >> >> Ted >> >> ------------------------------------------------------------------------ >> *From:* arin-ppml-bounces at arin.net >> >> [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *John Sweeting >> *Sent:* Monday, May 04, 2009 12:28 PM >> *To:* Leo Bicknell; arin ppml >> *Subject:* Re: [arin-ppml] Draft Policy 2009-1: Transfer >> Policy ? Revisedandforwarded to the Board >> >> A few more bits of information. One reason that the AC moved >> this proposal forward was that 2008-6 was already approved >> and set to be implemented on June 1 so the issue was already >> there. I believe it was accepted that the AC would make >> further review and come up with a proposal that would deal >> with this impact. Also a point to note is that this policy >> must be recertified at the next Public Policy Meeting since >> it went through the Emergency Policy process. >> >> >> On 5/4/09 3:00 PM, "Leo Bicknell" > > wrote: >> >> In a message written on Mon, May 04, 2009 at 12:21:01PM >> -0400, Member Services wrote: >> > The ARIN Advisory Council (AC) met on 29 April 2009 and >> decided to send >> > a revised version of 2009-1 to the Board for their >> consideration: >> >> This policy isn't in "last-call" per se, but given the >> PDP process >> I feel this is the only appropriate time for me to make these >> remarks. >> >> I am a member of the Advisory Council, speaking only for >> myself. >> During the various reviews and discussions the Advisory >> Council >> performs after the meeting a particular aspect of this >> policy was >> brought to (most of?) the AC's attention. I would like >> to bring >> it to the community's attention as well. I did not write >> notes on >> this at the time, so I am doing this from memory. If I >> get it >> wrong, I hope someone corrects me. >> >> Billy has a /16, and he's using it for dial up services >> which is >> not paying the bills anymore. >> >> Suzie wants a /16 for her hot new social networking >> experiment. >> >> Billy and Suzie find each other and agree to transfer >> Billy's /16 >> to Suzie under the result of 2008-6 + 2009-1. >> >> Billy goes to ARIN and says "Here's a /16, please give it >> to Suzie." >> >> Suzie goes to ARIN and says, "I'm here for Billy's /16". >> In the >> process, ARIN checks Suzie's justification, and realizes >> Suzie can >> only justify a /18. >> >> My understanding of the current interpretation of 2008-6 >> + 2009-1 >> is that ARIN would give Suzie a /18, and keep a /18 and >> /17 in the >> free pool. >> >> Billy has given up his /16, and Suzie only got a /18 of it. >> >> This ends up being an artifact of the legal requirement >> that transfers >> must occur through ARIN. My own personal view on how >> this would >> work prior to finding this out was if Suzie couldn't >> receive Billy's >> /16 for any reason, Billy would retain the /16. Thus my >> surprise, >> and I'm wondering if this isn't a surprise for others in the >> community. >> >> The recommended "fix", is that Suzie will be able to >> "pre-qualify", >> that is go to ARIN with all of her paperwork and get >> approved for >> a /18 before Billy and Suzie do a deal, so Suzie knows >> this will >> not happen. >> >> I think this ends up being bad for three distinct reasons: >> >> Technically: >> >> This causes deaggregation. In the example given a /16 >> was turned into >> a /17 and two /18's. However, because a /17 and /18 >> are both now in >> the free pool they may be further subdivided into /20's >> (or smaller, >> in some cases). >> >> Business: >> >> It is likely Billy and Suzie exchanged something of >> value during this >> transaction to make it happen. Suzie has now >> "overpaid" for her /18, >> and is likely to demand a refund from Billy, or >> challenge ARIN's >> stance she can only justify a /18, or both. Billy, of >> course, isn't >> going to want to give a refund as he is out the entire >> /16, but he may >> also be unhappy at ARIN for only approving her for a >> /18. It sounds >> like a good way to get all the parties in a transaction >> unhappy. >> >> But also, it opens up an interesting fraud. Alice >> could go to Billy >> and offer to buy the /16 for a hundred million dollars. >> Billy gets >> so excited over the idea of retiring from the dial up >> business that >> he takes the deal. Alice gives him a fake check, and >> Billy fills out >> the ARIN paperwork. >> >> But you see, it is a fake check, and Alice had no >> intention of ever >> justifying the addresses to ARIN. Billy figures out >> two weeks later >> the check is fake from the bank, but he's already >> released the addresses >> to ARIN and can't get them back. What's Alice's >> motivation? Well, >> her alter-ego Janice is sitting near the front of the >> line of folks >> waiting for space to end up in the free pool. Good for >> her, a /16 >> just showed up. >> >> But really this is all added risk, and what business >> wants to >> participate in a system with extra risk? >> >> Politically: >> >> This interpretation of the policy is likely to affect >> the most >> vulnerable the most. The savvy folks who are doing all >> sorts of >> transfers are reading this post on PPML now, and will >> understand >> the pitfalls of the system and work around these issues >> by doing >> things like prequalifing. >> >> This issue is much more likely to trip up the "one >> time" casual >> transferor or transferee who last delt with ARIN in >> 1999 and >> doesn't do this as a day job anymore. They are the >> ones who will >> accidently encounter this situation. >> >> Personally, I think ARIN should not let this happen. The >> simplest >> fix I have come up with is to require Suzie to fill out >> the recipient >> paperwork first. Billy should not be able to designate a >> recipient >> without having some assurance that end of the transaction >> is already >> approved from ARIN. This could be as simple as Suzie >> giving Billy >> the ticket number under which Suzie was approved, and >> Billy having >> to provide that ticket number to release resources. In >> this way >> an exact match could be insured, eliminating all of the >> problems >> listed above. >> >> The AC obviously moved this proposal on; so this was not >> seen as a >> show-stopper issue by the majority of the AC. At a >> minimum, I >> wanted to get the issue out to the community so if >> nothing is changed >> the community is aware of the issue and will be able to >> avoid it. >> I would hope this would end up documented on the ARIN web >> site in >> fairly clear language as well; but given the accelerated >> timetable >> for this proposal I didn't want to wait for that to occur >> first. >> >> -- >> 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. >> >> >> P Go Green! Print this email only when necessary. Thank you >> for helping Time Warner Cable be environmentally responsible. >> >> >> >> This E-mail and any of its attachments may contain Time Warner >> Cable proprietary information, which is privileged, confidential, >> or subject to copyright belonging to Time Warner Cable. This E-mail >> is intended solely for the use of the individual or entity to which >> it is addressed. If you are not the intended recipient of this >> E-mail, you are hereby notified that any dissemination, >> distribution, copying, or action taken in relation to the contents >> of and attachments to this E-mail is strictly prohibited and may be >> unlawful. If you have received this E-mail in error, please notify >> the sender immediately and permanently delete the original and any >> copy of this E-mail and any printout. >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >> ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you >> experience any issues. > From farmer at umn.edu Tue May 5 19:27:46 2009 From: farmer at umn.edu (David Farmer) Date: Tue, 05 May 2009 18:27:46 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revisedandforwarded to the Board In-Reply-To: <5EE810004162480AA9761B240FB6C89E@tedsdesk> References: <20090504190028.GB57395@ussenterprise.ufp.org>, <38C5FAC4-4930-417D-A22F-42594F5570E5@gmail.com>, <5EE810004162480AA9761B240FB6C89E@tedsdesk> Message-ID: <4A008522.27054.14B2A88B@farmer.umn.edu> I don't think it was a procedural trick at all. I think it was a premature proposal, ill-timed, and it was very awkward to deal with reinstituting a sunset that hadn't actually been eliminated yet. There were also some issues with how the new PDP works, that I think made it cleaner for the AC to abandon it and reintroduce a new proposal if needed after dealing with 2009- 1. While I'm not sure a proposal to reintroduce a sunset would gain consensus. Note: The show of hands last week was 24 in favor of removing the sunset and 19 against removing it. However, I believe a proposal to reintroduce a sunset would now be in order. I have been personally thinking about if I should reintroduce such a proposal and when. I have given much thought to the whole issue of a sunset since the introduction of 2009-1and believe if it were reintroduced it should have a specific date associated with it. Further, I agree with Scott that something around 5 years or so from now is about right, with a minimum of 3 years after IANA free pool exhaustion. I have been thinking about December 31st, 2014, as a sunset date. Hopefully IPv6 will have succeeded by then or we will have some kind of new way of thinking about all of this, maybe both. Further, this is far enough after a Fall 2014 Public Policy Meeting to implement policy to extend it or replace it with new policy. One of the many reasons I supported removing the sunset as it was in 2008-6, without a specific date there could be some really unfortunate timing created. By picking a specific date you can do a much better job of eliminating those timing issues. As for when to reintroduce it, we could do it now, but I know for a fact that many people are really tired of the whole issue. It might be more effective to wait a while, at least one policy cycle, maybe until IANA exhaustion, or maybe all the way until 2013 or 2014. By waiting until at least IANA exhaustion we could insure we set the right date and not need to change it again. On 5 May 2009 Ted Mittelstaedt wrote: > Scott, > > Owen already attempted to submit a policy change to 2009-1 that > re-instituted the sunset clause into 2009-1 > and on April 8th the AC used (IMHO) a procedural trick to abandon his policy > submission, claiming that 2009-1 > is already reviewing whether to remove a sunset clause from the NRPM or not. > Of course, all "reviewing" has > come up with NOT reintroducing the sunset clause, (a foregone conclusion) so > when 2009-1 is instituted it will > have no sunset clause. > > That is very strong disincentive from the Board to use sunset clauses on > this transfer market business. > It is also very strong disincentive to ever again bother with submitting any > proposals at all. > > Ted > > > > _____ > > From: Scott Leibrand [mailto:scottleibrand at gmail.com] > Sent: Monday, May 04, 2009 2:49 PM > To: Ted Mittelstaedt > Cc: John Sweeting; arin ppml > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? > Revisedandforwarded to the Board > > > Ted, > > I feel that a 3-year sunset would be bad policy given the immediate > imlementation of 2008-6. I think 5 years, or 3 years after IANA exhaustion, > would be appropriate, but I feel that would be best discussed as a normal > policy proposal. Anyone is welcome to introduce such a policy if you think > it's important. It would most likely be on the agenda this fall along with > 2009-1. > > > -Scott > > On May 4, 2009, at 2:40 PM, "Ted Mittelstaedt" wrote: > > > > AC had no need to make further policy to deal with the impact since 2008-6 > had an > automatic sunset. The entire point of the sunset in 2008-6 was to see what > the > unintended consequences would be and the only way to find them out was to > implement the policy and see what happened. I think most people expected > that > after a year or so of 2008-6 that, armed with the knowledge learned from the > experiment, we would write a much more comprehensive policy that would > supersede 2008-6. The sunset was a deadline that guaranteed this would > happen. > > Ted > > > _____ > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of John Sweeting > Sent: Monday, May 04, 2009 12:28 PM > To: Leo Bicknell; arin ppml > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? > Revisedandforwarded to the Board > > > > A few more bits of information. One reason that the AC moved this proposal > forward was that 2008-6 was already approved and set to be implemented on > June 1 so the issue was already there. I believe it was accepted that the AC > would make further review and come up with a proposal that would deal with > this impact. Also a point to note is that this policy must be recertified at > the next Public Policy Meeting since it went through the Emergency Policy > process. > > > On 5/4/09 3:00 PM, "Leo Bicknell" wrote: > > > > In a message written on Mon, May 04, 2009 at 12:21:01PM -0400, Member > Services wrote: > > The ARIN Advisory Council (AC) met on 29 April 2009 and decided to send > > a revised version of 2009-1 to the Board for their consideration: > > This policy isn't in "last-call" per se, but given the PDP process > I feel this is the only appropriate time for me to make these > remarks. > > I am a member of the Advisory Council, speaking only for myself. > During the various reviews and discussions the Advisory Council > performs after the meeting a particular aspect of this policy was > brought to (most of?) the AC's attention. I would like to bring > it to the community's attention as well. I did not write notes on > this at the time, so I am doing this from memory. If I get it > wrong, I hope someone corrects me. > > Billy has a /16, and he's using it for dial up services which is > not paying the bills anymore. > > Suzie wants a /16 for her hot new social networking experiment. > > Billy and Suzie find each other and agree to transfer Billy's /16 > to Suzie under the result of 2008-6 + 2009-1. > > Billy goes to ARIN and says "Here's a /16, please give it to Suzie." > > Suzie goes to ARIN and says, "I'm here for Billy's /16". In the > process, ARIN checks Suzie's justification, and realizes Suzie can > only justify a /18. > > My understanding of the current interpretation of 2008-6 + 2009-1 > is that ARIN would give Suzie a /18, and keep a /18 and /17 in the > free pool. > > Billy has given up his /16, and Suzie only got a /18 of it. > > This ends up being an artifact of the legal requirement that transfers > must occur through ARIN. My own personal view on how this would > work prior to finding this out was if Suzie couldn't receive Billy's > /16 for any reason, Billy would retain the /16. Thus my surprise, > and I'm wondering if this isn't a surprise for others in the > community. > > The recommended "fix", is that Suzie will be able to "pre-qualify", > that is go to ARIN with all of her paperwork and get approved for > a /18 before Billy and Suzie do a deal, so Suzie knows this will > not happen. > > I think this ends up being bad for three distinct reasons: > > Technically: > > This causes deaggregation. In the example given a /16 was turned into > a /17 and two /18's. However, because a /17 and /18 are both now in > the free pool they may be further subdivided into /20's (or smaller, > in some cases). > > Business: > > It is likely Billy and Suzie exchanged something of value during this > transaction to make it happen. Suzie has now "overpaid" for her /18, > and is likely to demand a refund from Billy, or challenge ARIN's > stance she can only justify a /18, or both. Billy, of course, isn't > going to want to give a refund as he is out the entire /16, but he may > also be unhappy at ARIN for only approving her for a /18. It sounds > like a good way to get all the parties in a transaction unhappy. > > But also, it opens up an interesting fraud. Alice could go to Billy > and offer to buy the /16 for a hundred million dollars. Billy gets > so excited over the idea of retiring from the dial up business that > he takes the deal. Alice gives him a fake check, and Billy fills out > the ARIN paperwork. > > But you see, it is a fake check, and Alice had no intention of ever > justifying the addresses to ARIN. Billy figures out two weeks later > the check is fake from the bank, but he's already released the addresses > to ARIN and can't get them back. What's Alice's motivation? Well, > her alter-ego Janice is sitting near the front of the line of folks > waiting for space to end up in the free pool. Good for her, a /16 > just showed up. > > But really this is all added risk, and what business wants to > participate in a system with extra risk? > > Politically: > > This interpretation of the policy is likely to affect the most > vulnerable the most. The savvy folks who are doing all sorts of > transfers are reading this post on PPML now, and will understand > the pitfalls of the system and work around these issues by doing > things like prequalifing. > > This issue is much more likely to trip up the "one time" casual > transferor or transferee who last delt with ARIN in 1999 and > doesn't do this as a day job anymore. They are the ones who will > accidently encounter this situation. > > Personally, I think ARIN should not let this happen. The simplest > fix I have come up with is to require Suzie to fill out the recipient > paperwork first. Billy should not be able to designate a recipient > without having some assurance that end of the transaction is already > approved from ARIN. This could be as simple as Suzie giving Billy > the ticket number under which Suzie was approved, and Billy having > to provide that ticket number to release resources. In this way > an exact match could be insured, eliminating all of the problems > listed above. > > The AC obviously moved this proposal on; so this was not seen as a > show-stopper issue by the majority of the AC. At a minimum, I > wanted to get the issue out to the community so if nothing is changed > the community is aware of the issue and will be able to avoid it. > I would hope this would end up documented on the ARIN web site in > fairly clear language as well; but given the accelerated timetable > for this proposal I didn't want to wait for that to occur first. > > -- > 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. > > > > P Go Green! Print this email only when necessary. Thank you for helping Time > Warner Cable be environmentally responsible. > > > > > > > > > > > > > > This E-mail and any of its attachments may contain Time Warner > > Cable proprietary information, which is privileged, confidential, > > or subject to copyright belonging to Time Warner Cable. This E-mail > > is intended solely for the use of the individual or entity to which > > it is addressed. If you are not the intended recipient of this > > E-mail, you are hereby notified that any dissemination, > > distribution, copying, or action taken in relation to the contents > > of and attachments to this E-mail is strictly prohibited and may be > > unlawful. If you have received this E-mail in error, please notify > > the sender immediately and permanently delete the original and any > > copy of this E-mail and any printout. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > =============================================== 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 tedm at ipinc.net Tue May 5 19:31:28 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 5 May 2009 16:31:28 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> Message-ID: <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> > -----Original Message----- > From: Kevin Kargel [mailto:kkargel at polartel.com] > Sent: Tuesday, May 05, 2009 4:00 PM > To: Ted Mittelstaedt; matthew at matthew.at > Cc: arin ppml > Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy > - Revised andforwarded to the Board > > > > > -----Original Message----- > > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > > Sent: Tuesday, May 05, 2009 5:37 PM > > To: Kevin Kargel; matthew at matthew.at > > Cc: 'arin ppml' > > Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy - > > Revised andforwarded to the Board > > > > > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel > > > Sent: Monday, May 04, 2009 1:18 PM > > > To: matthew at matthew.at > > > Cc: arin ppml > > > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy > > > - Revised andforwarded to the Board > > > > > > > > Rather than helping the problem the fact that this market > is being > > > discussed is exactly what is causing the hoarding. > > > > I have to cry foul with this. There's been implications of > hoarding > > on this list and in the last meeting but I have only seen a single > > allegation posted on this list of an illigitimate > > IPv4 holding, and that was a year ago. (and it wasn't a hoarding > > situation) > > Cry foul all you want but the situation still exists. > Perhaps I am misusing the term 'hoarding'. Please suggest > another term for "holding on to unused > IPv4 space with disregard for the good of the community until > the IPv4 space is worth a lot of money so I can sell it". > OK, your referring to people not giving it up post-IPv4 runout, not land-grabs pre-IPv4 runout Also I think what your talking about is speculation, not hoarding. > At this point whether or not the applications for space were > filled out faithfully is moot. Also much of the unused space > was granted long before the applications we use today existed. > > > > > Since true hoarding implies false data submitted for an IPv4 > > application, if anyone hs any concrete evidence that someone has > > falsified an application then they should immediately post > it, as well > > as turn it over to ARIN's hostmaster. > > > > We have no problems in the US with posting all manner of discovered > > illegalities of companies doing actions like illegal > dumping, so I see > > no legal barrier to yelling foul if you can prove that someone's > > cheating with an IPv4 application. > > > > I agree that once an unrestricted transfer proposal is in > NRPM that it > > will be an incentive to hoard, but it isn't in the NRPM yet. > > And once it is in, it will only be an incentive, we don't know if > > people will actually cheat/hoard. > > You don't think 2008-6 is an unrestricted transfer proposal? > No. It is restricted because of the sunset clause of 3 years in it. Granted that's not the kind of restrictions I think you were thinking about but it is a restriction. > > > > Remember, the people who are pusing this transfer thing are ALSO > > waving around the spectre of hoarding as an emotional > appeal to try to > > get support for their transfer allowance into the NRPM. > Please take > > the high road on this. > > I believe I am taking the high road and looking out for what > IMO is the good of the community. I just happen to believe > that it is necessary in this instance to be vocal. I very > rarely purposefully take the low road. > I am just leery of people saying that such-and-such is happening right now and offering no proof that it's actually happening. Ted From tedm at ipinc.net Tue May 5 19:32:40 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 5 May 2009 16:32:40 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revisedandforwarded to the Board In-Reply-To: <4A00CAA3.5030906@gmail.com> References: <20090504190028.GB57395@ussenterprise.ufp.org> <22D8831E297C4E65AD76184F0A5EC3A5@tedsdesk> <38C5FAC4-4930-417D-A22F-42594F5570E5@gmail.com> <5EE810004162480AA9761B240FB6C89E@tedsdesk> <4A00CAA3.5030906@gmail.com> Message-ID: <5EAA1DBFB22C4C13A3C4280FEE486E09@tedsdesk> I am glad to hear that. Ted > -----Original Message----- > From: Scott Leibrand [mailto:scottleibrand at gmail.com] > Sent: Tuesday, May 05, 2009 4:24 PM > To: Ted Mittelstaedt > Cc: 'arin ppml' > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy > ? Revisedandforwarded to the Board > > Ted, > > Owen's proposal was rejected by the AC simply because the > timing was poor. If a similar proposal were to be > resubmitted (by Owen or anyone > else) I would vote to accept it onto our docket, develop it > into draft policy, and have it on the agenda at the fall meeting. > > -Scott > > Ted Mittelstaedt wrote: > > Scott, > > > > Owen already attempted to submit a policy change to 2009-1 that > > re-instituted the sunset clause into 2009-1 and on April 8th the AC > > used (IMHO) a procedural trick to abandon his policy submission, > > claiming that 2009-1 is already reviewing whether to remove > a sunset > > clause from the NRPM or not. Of course, all "reviewing" > has come up > > with NOT reintroducing the sunset clause, (a foregone > > conclusion) so when 2009-1 is instituted it will have no sunset > > clause. > > > > That is very strong disincentive from the Board to use sunset > > clauses on this transfer market business. > > It is also very strong disincentive to ever again bother with > > submitting any proposals at all. > > > > Ted > > > > > -------------------------------------------------------------- > ---------- > > *From:* Scott Leibrand [mailto:scottleibrand at gmail.com] > > *Sent:* Monday, May 04, 2009 2:49 PM > > *To:* Ted Mittelstaedt > > *Cc:* John Sweeting; arin ppml > > *Subject:* Re: [arin-ppml] Draft Policy 2009-1: > Transfer Policy ? > > Revisedandforwarded to the Board > > > > Ted, > > > > I feel that a 3-year sunset would be bad policy given the > > immediate imlementation of 2008-6. I think 5 years, or 3 years > > after IANA exhaustion, would be appropriate, but I feel > that would > > be best discussed as a normal policy proposal. Anyone is welcome > > to introduce such a policy if you think it's important. It would > > most likely be on the agenda this fall along with 2009-1. > > > > -Scott > > > > On May 4, 2009, at 2:40 PM, "Ted Mittelstaedt" > > wrote: > > > >> AC had no need to make further policy to deal with the impact > >> since 2008-6 had an > >> automatic sunset. The entire point of the sunset in 2008-6 was > >> to see what the > >> unintended consequences would be and the only way to find them > >> out was to > >> implement the policy and see what happened. I think > most people > >> expected that > >> after a year or so of 2008-6 that, armed with the knowledge > >> learned from the > >> experiment, we would write a much more comprehensive > policy that > >> would > >> supersede 2008-6. The sunset was a deadline that > guaranteed this > >> would > >> happen. > >> > >> Ted > >> > >> > -------------------------------------------------------------- > ---------- > >> *From:* arin-ppml-bounces at arin.net > >> > >> [mailto:arin-ppml-bounces at arin.net] *On Behalf Of > *John Sweeting > >> *Sent:* Monday, May 04, 2009 12:28 PM > >> *To:* Leo Bicknell; arin ppml > >> *Subject:* Re: [arin-ppml] Draft Policy 2009-1: Transfer > >> Policy ? Revisedandforwarded to the Board > >> > >> A few more bits of information. One reason that > the AC moved > >> this proposal forward was that 2008-6 was already approved > >> and set to be implemented on June 1 so the issue > was already > >> there. I believe it was accepted that the AC would make > >> further review and come up with a proposal that would deal > >> with this impact. Also a point to note is that this policy > >> must be recertified at the next Public Policy Meeting since > >> it went through the Emergency Policy process. > >> > >> > >> On 5/4/09 3:00 PM, "Leo Bicknell" >> > wrote: > >> > >> In a message written on Mon, May 04, 2009 at 12:21:01PM > >> -0400, Member Services wrote: > >> > The ARIN Advisory Council (AC) met on 29 > April 2009 and > >> decided to send > >> > a revised version of 2009-1 to the Board for their > >> consideration: > >> > >> This policy isn't in "last-call" per se, but given the > >> PDP process > >> I feel this is the only appropriate time for > me to make these > >> remarks. > >> > >> I am a member of the Advisory Council, > speaking only for > >> myself. > >> During the various reviews and discussions the Advisory > >> Council > >> performs after the meeting a particular aspect of this > >> policy was > >> brought to (most of?) the AC's attention. I would like > >> to bring > >> it to the community's attention as well. I > did not write > >> notes on > >> this at the time, so I am doing this from memory. If I > >> get it > >> wrong, I hope someone corrects me. > >> > >> Billy has a /16, and he's using it for dial up services > >> which is > >> not paying the bills anymore. > >> > >> Suzie wants a /16 for her hot new social networking > >> experiment. > >> > >> Billy and Suzie find each other and agree to transfer > >> Billy's /16 > >> to Suzie under the result of 2008-6 + 2009-1. > >> > >> Billy goes to ARIN and says "Here's a /16, > please give it > >> to Suzie." > >> > >> Suzie goes to ARIN and says, "I'm here for > Billy's /16". > >> In the > >> process, ARIN checks Suzie's justification, > and realizes > >> Suzie can > >> only justify a /18. > >> > >> My understanding of the current interpretation > of 2008-6 > >> + 2009-1 > >> is that ARIN would give Suzie a /18, and keep a /18 and > >> /17 in the > >> free pool. > >> > >> Billy has given up his /16, and Suzie only got > a /18 of it. > >> > >> This ends up being an artifact of the legal requirement > >> that transfers > >> must occur through ARIN. My own personal view on how > >> this would > >> work prior to finding this out was if Suzie couldn't > >> receive Billy's > >> /16 for any reason, Billy would retain the > /16. Thus my > >> surprise, > >> and I'm wondering if this isn't a surprise for > others in the > >> community. > >> > >> The recommended "fix", is that Suzie will be able to > >> "pre-qualify", > >> that is go to ARIN with all of her paperwork and get > >> approved for > >> a /18 before Billy and Suzie do a deal, so Suzie knows > >> this will > >> not happen. > >> > >> I think this ends up being bad for three > distinct reasons: > >> > >> Technically: > >> > >> This causes deaggregation. In the example > given a /16 > >> was turned into > >> a /17 and two /18's. However, because a /17 and /18 > >> are both now in > >> the free pool they may be further subdivided > into /20's > >> (or smaller, > >> in some cases). > >> > >> Business: > >> > >> It is likely Billy and Suzie exchanged something of > >> value during this > >> transaction to make it happen. Suzie has now > >> "overpaid" for her /18, > >> and is likely to demand a refund from Billy, or > >> challenge ARIN's > >> stance she can only justify a /18, or both. > Billy, of > >> course, isn't > >> going to want to give a refund as he is out > the entire > >> /16, but he may > >> also be unhappy at ARIN for only approving her for a > >> /18. It sounds > >> like a good way to get all the parties in a > transaction > >> unhappy. > >> > >> But also, it opens up an interesting fraud. Alice > >> could go to Billy > >> and offer to buy the /16 for a hundred > million dollars. > >> Billy gets > >> so excited over the idea of retiring from the dial up > >> business that > >> he takes the deal. Alice gives him a fake check, and > >> Billy fills out > >> the ARIN paperwork. > >> > >> But you see, it is a fake check, and Alice had no > >> intention of ever > >> justifying the addresses to ARIN. Billy figures out > >> two weeks later > >> the check is fake from the bank, but he's already > >> released the addresses > >> to ARIN and can't get them back. What's Alice's > >> motivation? Well, > >> her alter-ego Janice is sitting near the front of the > >> line of folks > >> waiting for space to end up in the free > pool. Good for > >> her, a /16 > >> just showed up. > >> > >> But really this is all added risk, and what business > >> wants to > >> participate in a system with extra risk? > >> > >> Politically: > >> > >> This interpretation of the policy is likely to affect > >> the most > >> vulnerable the most. The savvy folks who > are doing all > >> sorts of > >> transfers are reading this post on PPML now, and will > >> understand > >> the pitfalls of the system and work around > these issues > >> by doing > >> things like prequalifing. > >> > >> This issue is much more likely to trip up the "one > >> time" casual > >> transferor or transferee who last delt with ARIN in > >> 1999 and > >> doesn't do this as a day job anymore. They are the > >> ones who will > >> accidently encounter this situation. > >> > >> Personally, I think ARIN should not let this > happen. The > >> simplest > >> fix I have come up with is to require Suzie to fill out > >> the recipient > >> paperwork first. Billy should not be able to > designate a > >> recipient > >> without having some assurance that end of the > transaction > >> is already > >> approved from ARIN. This could be as simple as Suzie > >> giving Billy > >> the ticket number under which Suzie was approved, and > >> Billy having > >> to provide that ticket number to release resources. In > >> this way > >> an exact match could be insured, eliminating all of the > >> problems > >> listed above. > >> > >> The AC obviously moved this proposal on; so > this was not > >> seen as a > >> show-stopper issue by the majority of the AC. At a > >> minimum, I > >> wanted to get the issue out to the community so if > >> nothing is changed > >> the community is aware of the issue and will be able to > >> avoid it. > >> I would hope this would end up documented on > the ARIN web > >> site in > >> fairly clear language as well; but given the > accelerated > >> timetable > >> for this proposal I didn't want to wait for > that to occur > >> first. > >> > >> -- > >> 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. > >> > >> > >> P Go Green! Print this email only when necessary. Thank you > >> for helping Time Warner Cable be environmentally > responsible. > >> > >> > >> > >> This E-mail and any of its attachments may contain > Time Warner > >> Cable proprietary information, which is > privileged, confidential, > >> or subject to copyright belonging to Time Warner > Cable. This E-mail > >> is intended solely for the use of the individual > or entity to which > >> it is addressed. If you are not the intended > recipient of this > >> E-mail, you are hereby notified that any dissemination, > >> distribution, copying, or action taken in relation > to the contents > >> of and attachments to this E-mail is strictly > prohibited and may be > >> unlawful. If you have received this E-mail in > error, please notify > >> the sender immediately and permanently delete the > original and any > >> copy of this E-mail and any printout. > >> > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > >> ). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you > >> experience any issues. > > > From bicknell at ufp.org Tue May 5 19:54:41 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 5 May 2009 19:54:41 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revisedandforwarded to the Board In-Reply-To: <4A008522.27054.14B2A88B@farmer.umn.edu> References: <5EE810004162480AA9761B240FB6C89E@tedsdesk> <4A008522.27054.14B2A88B@farmer.umn.edu> Message-ID: <20090505235441.GA64842@ussenterprise.ufp.org> In a message written on Tue, May 05, 2009 at 06:27:46PM -0500, David Farmer wrote: > As for when to reintroduce it, we could do it now, but I know for > a fact that many people are really tired of the whole issue. It > might be more effective to wait a while, at least one policy > cycle, maybe until IANA exhaustion, or maybe all the way until > 2013 or 2014. By waiting until at least IANA exhaustion we > could insure we set the right date and not need to change it > again. I'm afraid you have missed entirely the purpose of a sunset clause, at least in this context. As many have pointed out, a proposal to repeal 2008-6 / 2009-1 can be introduced at any time. There is no need for a sunset clause for those on the "other side of the fence" to challenge the status quo. There is also no reason in this context to use a sunset for "clean up", we can clean up via policy, and should transfers no longer be used by the community there is no significant harm to having the text still in the NRPM. The sunset clause was about building trust. It was about finding a compromise that brought everyone under the same tent. It was a promise to the unsure that there would be a top-to-bottom review. It was about setting a higher bar for that review, that there must be consensus that this is an idea worth continuing; rather tha consensus it is worth stopping. Those are not opposites, but very different bars. I am one of the folks who originally agreed to come into the tent in part due to the sunset clause. Now that it has been removed I feel as if I have been aggrieved. Restoring the sunset will not remove that feeling, and as much as I would like to say otherwise I see no reason to revisit the issue at this time. These events have left me smarter though. I now realize sunset provisions don't work. The promise of a comprehensive review, on a timetable, has already been broken. The next time such a compromise is presented I will not bite, I will put all my energy into opposing the policy rather than working towards a compromise based on trust. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From tedm at ipinc.net Tue May 5 20:59:14 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 5 May 2009 17:59:14 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revisedandforwarded to the Board In-Reply-To: <4A008522.27054.14B2A88B@farmer.umn.edu> References: <20090504190028.GB57395@ussenterprise.ufp.org>, <38C5FAC4-4930-417D-A22F-42594F5570E5@gmail.com>, <5EE810004162480AA9761B240FB6C89E@tedsdesk> <4A008522.27054.14B2A88B@farmer.umn.edu> Message-ID: <4965BB968A4345ABA110CEBA7971EDFA@tedsdesk> > -----Original Message----- > From: David Farmer [mailto:farmer at umn.edu] > Sent: Tuesday, May 05, 2009 4:28 PM > To: Ted Mittelstaedt > Cc: 'arin ppml' > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy > ? Revisedandforwarded to the Board > > I don't think it was a procedural trick at all. I think it > was a premature proposal, ill-timed, and it was very awkward > to deal with reinstituting a sunset that hadn't actually been > eliminated yet. There were also some issues with how the new > PDP works, that I think made it cleaner for the AC to abandon > it and reintroduce a new proposal if needed after dealing > with 2009- 1. > It would have been even cleaner to retain the sunset in 2009-1 and avoid the appearance of thwarting the original proposal. > While I'm not sure a proposal to reintroduce a sunset would > gain consensus. Note: The show of hands last week was 24 in > favor of removing the sunset and 19 against removing it. > However, I believe a proposal to reintroduce a sunset would > now be in order. I have been personally thinking about if I > should reintroduce such a proposal and when. > > I have given much thought to the whole issue of a sunset > since the introduction of 2009-1and believe if it were > reintroduced it should have a specific date associated with > it. Further, I agree with Scott that something around 5 > years or so from now is about right, with a minimum of 3 > years after IANA free pool exhaustion. > > I have been thinking about December 31st, 2014, as a sunset > date. Hopefully IPv6 will have succeeded by then or we will > have some kind of new way of thinking about all of this, > maybe both. Further, this is far enough after a Fall 2014 > Public Policy Meeting to implement policy to extend it or > replace it with new policy. > > One of the many reasons I supported removing the sunset as it > was in 2008-6, without a specific date there could be some > really unfortunate timing created. By picking a specific > date you can do a much better job of eliminating those timing issues. > > As for when to reintroduce it, we could do it now, but I know > for a fact that many people are really tired of the whole > issue. I think many people are resigned to the sunset idea being thwarted and figure the Board has "won" this round. The show of hands was a recognition that if the membership voted to retain the sunset the Board would override them anyway and simply further damage the trust of the proposal process. It would go a long way toward rebuilding trust for an AC member who voted to get rid of the sunset to reintroduce a sunset proposal now. By ignoring this and saying that we should wait your just reinforcing the image that the Board is going to get it's way no matter what. Also, a sunset clause's maximum usefulness is that of a deterrent against speculation and the longer you wait the less effective it will be. Right now, people are familiar with the discussion so there isn't a need to rehash the entire thing. And if people are tired of it, then they are much less likely to want to rehash the whole thing. > It might be more effective to wait a while, at least > one policy cycle, maybe until IANA exhaustion, or maybe all > the way until > 2013 or 2014. By waiting until at least IANA exhaustion we > could insure we set the right date and not need to change it again. > I think that there isn't anything wrong with the 2014 date. As you said, this is far enough after a Fall 2014 Public Policy Meeting to implement policy to extend it or replace it with new policy. Keep in mind I never supported any of the transfer proposals prior to 2008-6 and I -only- supported 2008-6 because of the sunset, as a way of shutting up the clamor from the pro-transfer camp without causing permanent damage, and I didn't and don't support 2009-1 section 8.3 When I supported 2008-6 it never had occurred to me that anyone would change the sunset after implementation, if it had I wouldn't have supported it either. My feeling has always been that talk of a transfer market is very misguided, that there's plenty of "mineable" IPv4 in allocations already made that have been abandonded, and our reclamation efforts should focus there first. As Kevin said, the existence of a transfer market complicates reclamation. Prior to 2009-1, if ARIN staff contacted an org, perhaps as a result of the POC cleanup efforts, and mentioned that a block they had didn't have a valid POC, it might have resulted in the org saying "You mean we are still paying for that, I thought we gave that back to you years ago" Post 2009-1, if ARIN does that the org will not hand it back, they will demand to keep it then go hawking it off on the "used IPv4 block" market. Lest you laugh, I just ran across a block last month that still had my own org's POC on it, that we abandonded back to 2004. It consisted of a /23 assigned to us by Verizon in 1995, and I had to go through a lot of rigamarole with Level 3 for them to file a delete SWIP on it. We had NOT been paying anyone, either Verizon or ARIN, for this block. If you don't believe me I can give you the ARIN-assigned trouble ticket numbers regarding that case. Some of these large networks are -extremely- disorganized and don't know what they have. Level-3 had got that from acquision of Genuity which had got it from acquision of Verizon Data Services. It was extremely obvious talking to Level 3 that they had no idea of what holdings they had which originated from the Genuity acquisition since the bloc was not in any of their current schemes. Prior to the transfer market, the ARIN hostmaster could have quietly handled this with Level 3 and perhaps aggregated it with adjacent blocks, also abandonded. The transfer market makes that impossible since the Level 3 peons have no authority to give up assets, and a /23 is not large enough for someone in Level 3 with authority to bother with selling it. As Kevin said, ultimately the transfer market is going to work against reclamation. Ted From michael.dillon at bt.com Wed May 6 04:27:53 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 6 May 2009 09:27:53 +0100 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy ?Revisedandforwarded to the Board In-Reply-To: <20090505235441.GA64842@ussenterprise.ufp.org> Message-ID: <28E139F46D45AF49A31950F88C497458F2CA73@E03MVZ2-UKDY.domain1.systemhost.net> > The sunset clause was about building trust. It was about > finding a compromise that brought everyone under the same > tent. It was a promise to the unsure that there would be a > top-to-bottom review. Wait a minute, that is not a sunset clause, that is a review date. A sunset clause says that something will end on that date, period. No review. No renewal. Nothing. If you want some kind of policy that includes a built-in reveiew date then please say so in plain English and don't pussyfoot around with redefining the meaning of words and pompous language. Instead of attaching an explanation of what you mean, hone the wording of the policy until it is clear and and unambiguous. > These events have left me smarter though. I now realize > sunset provisions don't work. Yes they do. After the sunset date, the policy or law is no longer operative. > The promise of a comprehensive > review, on a timetable, has already been broken. That is not a sunset clause. --Michael Dillon From michael.dillon at bt.com Wed May 6 04:38:29 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 6 May 2009 09:38:29 +0100 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy ?Revisedandforwarded to the Board In-Reply-To: <4965BB968A4345ABA110CEBA7971EDFA@tedsdesk> Message-ID: <28E139F46D45AF49A31950F88C497458F2CAA6@E03MVZ2-UKDY.domain1.systemhost.net> > My feeling has always been that talk of a transfer market is > very misguided, that there's plenty of "mineable" IPv4 in > allocations already made that have been abandonded, and our > reclamation efforts should focus there first. Lots of that minable IPv4 is in the hands of the ISPs who will need it. In other words, when some organization realizes that they need more IPv4 addresses and ARIN can no longer supply them, they will be able to invest the money into mining their own supply rather than spending money on buying addresses from someone else. Some of these minable addresses might fall under the category that some people call "hoarding" although I don't think that is a proper term for it. But lots of them are perfectly legitimately held IP addresses, for instance assignments to DHCP pools used by broadband DSL customers. When the runout occurs, many companies will be able to identify blocks of IPv4 internally, which do not supply as much profit per IP address as another service which is short of addresses. The "mining" activity is to either shut off less profitable customers or to forcefully migrate them to IPv6 services. At that point, the freed up IPv4 addresses can be repurposed. Also, most large telecoms companies have a problem with cleaning up after customers are disconnected, or after they upgrade to a service which requires a new circuit. Part of that cleanup is to recover the unused IPv4 addresses. There is not a lot of incenctive to do this cleanup today, but there will be when ARIN runs out of IPv4. A company where I used to work was spending over $2 million dollars per month on unused access lines because of not cleaning up after disconnects. So, we don't need ARIN to organize any reclamation effort because the organizations with the minable IPv4 addresses will have plenty of incentive to do it themselves. --Michael Dillon From lear at cisco.com Wed May 6 08:04:06 2009 From: lear at cisco.com (Eliot Lear) Date: Wed, 06 May 2009 14:04:06 +0200 Subject: [arin-ppml] Some data relating to IPv4 address exhaustion (or not) In-Reply-To: <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> Message-ID: <4A017CB6.4040503@cisco.com> Ted, Here are some interesting data points for this group to consider. According to the U.N., world economic growth dropped from 3.5-4% in 2003-2007 to 2.5% in 2008, and the prediction is for around 1% growth in 2009. At the same time, Geoff Huston's numbers have been shifting to the right. In the case of IANA the number has shifted out 6 months in 6 months. We have not seen quite the same shift for RIR numbers, however. Is world economic growth a controlling variable in the equation of IP address consumption, or merely a coincidence, and how can we tell? Eliot From michael.dillon at bt.com Wed May 6 08:36:20 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 6 May 2009 13:36:20 +0100 Subject: [arin-ppml] Some data relating to IPv4 address exhaustion (or not) In-Reply-To: <4A017CB6.4040503@cisco.com> Message-ID: <28E139F46D45AF49A31950F88C497458F2D063@E03MVZ2-UKDY.domain1.systemhost.net> > Here are some interesting data points for this group to consider. > According to the U.N., world economic growth dropped from 3.5-4% in > 2003-2007 to 2.5% in 2008, and the prediction is for around > 1% growth in 2009. At the same time, Geoff Huston's numbers > have been shifting to the right. In the case of IANA the > number has shifted out 6 months in 6 months. We have not > seen quite the same shift for RIR numbers, however. Is world > economic growth a controlling variable in the equation of IP > address consumption, or merely a coincidence, and how can we tell? Wait five years, look at the numbers, and you will know. In the past recessions have caused an increase in spending on various types of IT products, such as IP networks. So it is entirely possible that the world economic slowdown will slightly speed up the runout of IPv4 addresses. If there were going to be a significant negative impact, I think that we would have seen some sign of it by now, which suggests to me that the overall economic situation does not strongly impact IP address consumption one way or another. There is probably a combination of things going on which include some people cutting back and disconnecting sites from the network, and others adding more network connections in order to increase the use of teleconferencing services to save money on travel and avoid the downside risks of the global flu epidemic this autumn. Personally, I don't think it is productive for ARIN to engage in building economic models to use in forecasting IP address consumption. --Michael Dillon From kkargel at polartel.com Wed May 6 11:06:34 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 6 May 2009 10:06:34 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C2@mail> > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Tuesday, May 05, 2009 6:31 PM > To: Kevin Kargel; matthew at matthew.at > Cc: 'arin ppml' > Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised > andforwarded to the Board > > {much freely done snipping} > > I am just leery of people saying that such-and-such is happening right > now and offering no proof that it's actually happening. > > Ted I believe the proof of what I am talking about is all of the unused IPv4 space that is not being returned so that it can be held as a speculative commodity. Inaction in itself is a proof. I must say I feel better now. For a while there Ted and I were agreeing on most issues. It had me concerned. (Light hearted levity Ted, don't take it serious ;) ) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From cliffb at cjbsys.bdb.com Wed May 6 11:48:07 2009 From: cliffb at cjbsys.bdb.com (Cliff) Date: Wed, 6 May 2009 11:48:07 -0400 (EDT) Subject: [arin-ppml] [a-p] Draft Policy 2009-1: Transfer Policy In-Reply-To: <28E139F46D45AF49A31950F88C497458F2CA73@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <200905061548.n46Fm7Tb001160@cjbsys.bdb.com> > > > The sunset clause was about building trust. It was about > > finding a compromise that brought everyone under the same > > tent. It was a promise to the unsure that there would be a > > top-to-bottom review. > > Wait a minute, that is not a sunset clause, that is a review > date. A sunset clause says that something will end on that > date, period. No review. No renewal. Nothing. You can argue the semantics about it but in a group such as this where you can change policy, a sunset policy is always available for review even after it sunsets. All the sunset clause did was say that unless ARIN takes some action to change whatever will expire, it will expire. When I started working, 65 was the age for full retirement. For me it's now 66 and for all you youngsters, it's even later. It's like opt-in emails or opt-out. Both work but one is better for one group while the other is better for a second group. I don't have a strong feeling one way or the other about the sunset clause but in reading this group, it appears that many went along with 2008-6 because it had a sunset clause to limit the marketing of IPv4 addresses. I think they all knew that as the sunset approached, the sunset clause was subject to review and change but if no other action was taken, 2008-6 would expire. For that group, it was more appealing to have it stop by default rather than have to take action to stop it. As I said, I won't be buying or selling so I don't care but it appears to me that those who reluctantly went along because of the sunset have been sandbagged by 2009-1. I don't blame them for being upset. As a relative newbie to the group, I was impressed by the general feeling that like Google, ARIN was run on the idea of "doing good". As we approach runout of IPv4, it seems to me that many of those who believe in "doing good" (whatever your definition is) feel that the tenor of ARIN governance is changing to more of a business model and aren't sure that's the proper way to go. I'd like to see more "doing good" than "business model" but I don't think you can ignore what is going on in the real world. 2008-6 seemed to have about the right tension between them based on the tone of the debate but 2009-1 seems to be tilting toward the business model. Given all my ramblings above, I think the sunset clause should remain. Cliff > > If you want some kind of policy that includes a built-in reveiew > date then please say so in plain English and don't pussyfoot > around with redefining the meaning of words and pompous > language. Instead of attaching an explanation of what you mean, > hone the wording of the policy until it is clear and > and unambiguous. > > > These events have left me smarter though. I now realize > > sunset provisions don't work. > > Yes they do. After the sunset date, the policy or law is no > longer operative. > > > The promise of a comprehensive > > review, on a timetable, has already been broken. > > That is not a sunset clause. > > --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. > -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From lear at cisco.com Wed May 6 12:09:32 2009 From: lear at cisco.com (Eliot Lear) Date: Wed, 06 May 2009 18:09:32 +0200 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C2@mail> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C2@mail> Message-ID: <4A01B63C.20909@cisco.com> On this point: > I believe the proof of what I am talking about is all of the unused IPv4 > space that is not being returned so that it can be held as a speculative > commodity. Inaction in itself is a proof. > A lot of people have tried to quantify this number and have not been able to do so. From bonomi at mail.r-bonomi.com Wed May 6 12:54:19 2009 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Wed, 6 May 2009 11:54:19 -0500 (CDT) Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board Message-ID: <200905061654.n46GsJnG003047@mail.r-bonomi.com> > Date: Wed, 6 May 2009 10:06:34 -0500 > From: "Kevin Kargel" > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised > andforwarded to the Board > > > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > > Sent: Tuesday, May 05, 2009 6:31 PM > > Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised > > andforwarded to the Board > > > > > {much freely done snipping} > > > > > I am just leery of people saying that such-and-such is happening right > > now and offering no proof that it's actually happening. > > > > Ted > > I believe the proof of what I am talking about is all of the unused IPv4 > space that is not being returned so that it can be held as a speculative > commodity. Inaction in itself is a proof. Unfortunately, that claim is simply -not- true. FIRST, you have not shown that there is, in actual fact, 'all that UNUSED, _allocated_, IPv4 address space. Just because it is unrouted and unreachable on the 'public internet' does -not- mean that it is "unused". Allocations were available for 'non-connected' use. I =will= grant that it is "generally believed to be true" that there are non-trivial amounts of addresses in blocks that are not being actively used for anything. HOWEVER, even accepting as "given" that there are such 'idle' blocks, you are asserting a particular "why" for those blocks being 'idle', *without* any direct evidence to support that assertation. I can think of at least three other reasons why any particular block, or sub- block of addrsses "could" be sitting idle. From kkargel at polartel.com Wed May 6 12:16:46 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 6 May 2009 11:16:46 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <4A01B63C.20909@cisco.com> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C2@mail> <4A01B63C.20909@cisco.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C9@mail> > -----Original Message----- > From: Eliot Lear [mailto:lear at cisco.com] > Sent: Wednesday, May 06, 2009 11:10 AM > To: Kevin Kargel > Cc: arin ppml > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised > andforwarded to the Board > > On this point: > > > I believe the proof of what I am talking about is all of the unused IPv4 > > space that is not being returned so that it can be held as a speculative > > commodity. Inaction in itself is a proof. > > > > A lot of people have tried to quantify this number and have not been > able to do so. There are too many unknowns to be able to quantify anything. That does not invalidate the existence of the issue. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From dave at connetrix.com Wed May 6 11:49:50 2009 From: dave at connetrix.com (Dave Feuer) Date: Wed, 6 May 2009 11:49:50 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C2@mail> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C2@mail> Message-ID: <00c401c9ce62$4a2d7620$de886260$@com> Looking back on some old IP assignments that were allocated to us and others I have dealt with by providers over the years I can say that there are a lot of old blocks not being reallocated to other customers. Some of these have not been active in over 6 years. And this is not for just a /29 or something. We are talking multiple /24 and better. -Dave -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel Sent: Wednesday, May 06, 2009 11:07 AM To: arin ppml Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Tuesday, May 05, 2009 6:31 PM > To: Kevin Kargel; matthew at matthew.at > Cc: 'arin ppml' > Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy - > Revised andforwarded to the Board > > {much freely done snipping} > > I am just leery of people saying that such-and-such is happening right > now and offering no proof that it's actually happening. > > Ted I believe the proof of what I am talking about is all of the unused IPv4 space that is not being returned so that it can be held as a speculative commodity. Inaction in itself is a proof. I must say I feel better now. For a while there Ted and I were agreeing on most issues. It had me concerned. (Light hearted levity Ted, don't take it serious ;) ) From michael.dillon at bt.com Wed May 6 12:29:26 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 6 May 2009 17:29:26 +0100 Subject: [arin-ppml] [a-p] Draft Policy 2009-1: Transfer Policy In-Reply-To: <200905061548.n46Fm7Tb001160@cjbsys.bdb.com> Message-ID: <28E139F46D45AF49A31950F88C497458F87100@E03MVZ2-UKDY.domain1.systemhost.net> > > Wait a minute, that is not a sunset clause, that is a > review date. A > > sunset clause says that something will end on that date, period. No > > review. No renewal. Nothing. > > You can argue the semantics about it but in a group such as > this where you can change policy, a sunset policy is always > available for review even after it sunsets. All the sunset > clause did was say that unless ARIN takes some action to > change whatever will expire, it will expire. The point is that if you want to force a review of the policy at some point in time, then say that plainly in the policy. Don't just expire it and assume that everyone will remember why it expires on that day. If you don't say what you mean, then people won't debate what you mean. Instead, they will debate what you said and you have an uphill battle trying to convince them that you didn't mean what you say but you said it that way because of some environmental force which makes it roughly \ equivalent in this specific instance and context. > I don't have a strong feeling one way or the other about the > sunset clause but in reading this group, it appears that many > went along with 2008-6 because it had a sunset clause to > limit the marketing of IPv4 addresses. I think they all knew > that as the sunset approached, the sunset clause was subject > to review and change but if no other action was taken, 2008-6 > would expire. For that group, it was more appealing to have > it stop by default rather than have to take action to stop it. Right. So the policy originally went through because people were happy to have the wool pulled over their eyes because it was knitted, not felt, and they could still sort of see OK if they nodded their head up and down. > As a relative newbie to the group, I was impressed by the > general feeling that like Google, ARIN was run on the idea of > "doing good". Wherever do you get such strange ideas. As someone who was around since before ARIN was formed, I've never heard of anyone refer to ARIN as "doing good". More often I've seen bitter quarrels and many, many threats of lawsuits, often caused by complete misunderstanding. > As we approach runout of IPv4, it seems to me > that many of those who believe in "doing good" > (whatever your definition is) feel that the tenor of ARIN > governance is changing to more of a business model and aren't > sure that's the proper way to go. In fact there seem to be less bitter quarrels, and less threats of lawsuits these days. ARIN is a much milder and tamer place than it was. It still doesn't do good. ARIN just does what it does and that works out as good for some folks, and not so good for others. > Given all my ramblings above, I think the sunset clause > should remain. At this point, I've forgotten everything about that particular policy except that some words were deleted and some folks consider those words to be a sunset clause. --Michael Dillon From michael.dillon at bt.com Wed May 6 13:13:51 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 6 May 2009 18:13:51 +0100 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revised andforwarded to the Board In-Reply-To: <00c401c9ce62$4a2d7620$de886260$@com> Message-ID: <28E139F46D45AF49A31950F88C497458F8715E@E03MVZ2-UKDY.domain1.systemhost.net> > Looking back on some old IP assignments that were allocated > to us and others I have dealt with by providers over the > years I can say that there are a lot of old blocks not being > reallocated to other customers. Some of these have not been > active in over 6 years. And this is not for just a /29 or > something. We are talking multiple /24 and better. Sloppy management of addresses. That is why ARIN is now going to require a corporate officer to attest to any address usage reports. That should trigger companies to do proper audits, with trained auditors, and that will uncover the slop which they will then recover and reuse internally. ARIN is powerless to do anything with those "lost" addresses. The best case scenario is that all the ISPs discover the wealth that they have in-house and make use of it to cover the gap until IPv6 is fully deployed. After that it won't matter anymore. --Michael Dillon From wlehr at MIT.EDU Wed May 6 13:15:20 2009 From: wlehr at MIT.EDU (William Lehr) Date: Wed, 06 May 2009 13:15:20 -0400 Subject: [arin-ppml] Some data relating to IPv4 address exhaustion (or not) In-Reply-To: <19A03C0B-FA32-481F-B037-5EA64A399065@americafree.tv> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> <4A017CB6.4040503@cisco.com> <19A03C0B-FA32-481F-B037-5EA64A399065@americafree.tv> Message-ID: <4A01C5A8.4080705@mit.edu> That is a reasonable hypothesis, but I would not be surprised if there were no correlation at all because of the complex dynamics associated with address usage. Basically, IP addresses are a small share of costs to run a network and even smaller share of corporate IT budgets so should not be closely correlated with it. Yes, there is presumably rough correlation between number of employees, corporate capital expenditures, and other such indicators associated with overall economy, but I would expect that to be very noisy. Issues like architecture reconfiguration could increase or decrease need for addresses and so direction of impact of business cycles on IP address demand would be ambiguous. On other hand, since addresses are allocated in one-way process (from unallocated pool to demanders) and new allocations justified by need to meet expanded user-base, there is implicit linkage between business cycles and demand, and that seems likely to make it a leading indicator. But in some sense an artificial indicator that is partially due to current allocation mechanism rather than real "demand." (That is, does address utilitization correlate with demand? My earlier discussion focused more on address utilization.) Interesting academic questions, but I am surprised it makes much of a difference in policy debate. Exhaustion is still pre-ordained conclusion, right? Do a few months one way or other make a big difference? Marshall Eubanks wrote: > > On May 6, 2009, at 8:04 AM, Eliot Lear wrote: > >> Ted, >> >> Here are some interesting data points for this group to consider. >> According to the U.N., world economic growth dropped from 3.5-4% in >> 2003-2007 to 2.5% in 2008, and the prediction is for around 1% growth in >> 2009. At the same time, Geoff Huston's numbers have been shifting to >> the right. In the case of IANA the number has shifted out 6 months in 6 >> months. We have not seen quite the same shift for RIR numbers, >> however. Is world economic growth a controlling variable in the >> equation of IP address consumption, or merely a coincidence, and how can >> we tell? >> > > I would expect the RIR allocation requests to be a lagging indicator > of the economic situation, and > that address usage would be simultaneous with or even a leading > indicator of the economy. > > Regards > Marshall > >> Eliot >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing 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. >> > > Regards > Marshall Eubanks > CEO / AmericaFree.TV > > -- ==+==+==+==+==+==+==+==+==+==+==+==+==+ Dr. William Lehr Research Associate MIT Communications Futures Program MIT Office: Massachusetts Institute of Technology 32 Vassar Street (32-G814) Cambridge, MA 02139 tel: 617-258-0630 fax: 617-253-2673 Home Office (preferred): 94 Hubbard street Concord, MA 01742 tel: 978-287-0709 cell: 978-618-3775 website: http://csail.mit.edu/~wlehr email: wlehr at mit.edu ==+==+==+==+==+==+==+==+==+==+==+==+==+ From lear at cisco.com Wed May 6 13:22:26 2009 From: lear at cisco.com (Eliot Lear) Date: Wed, 06 May 2009 19:22:26 +0200 Subject: [arin-ppml] Some data relating to IPv4 address exhaustion (or not) In-Reply-To: <4A01C5A8.4080705@mit.edu> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> <4A017CB6.4040503@cisco.com> <19A03C0B-FA32-481F-B037-5EA64A399065@americafree.tv> <4A01C5A8.4080705@mit.edu> Message-ID: <4A01C752.6050606@cisco.com> Bill, Here is my real question: if demand for new address allocations is weak post-runout (meaning greater than 100% allocated when the cost is 0), what happens when the cost is > 0 in such an environment? At what point do we hit a knee of some form? Regards, Eliot On 5/6/09 7:15 PM, William Lehr wrote: > That is a reasonable hypothesis, but I would not be surprised if there > were no correlation at all because of the complex dynamics associated > with address usage. > > Basically, IP addresses are a small share of costs to run a network > and even smaller share of corporate IT budgets so should not be > closely correlated with it. Yes, there is presumably rough correlation > between number of employees, corporate capital expenditures, and other > such indicators associated with overall economy, but I would expect > that to be very noisy. Issues like architecture reconfiguration could > increase or decrease need for addresses and so direction of impact of > business cycles on IP address demand would be ambiguous. > > On other hand, since addresses are allocated in one-way process (from > unallocated pool to demanders) and new allocations justified by need > to meet expanded user-base, there is implicit linkage between business > cycles and demand, and that seems likely to make it a leading > indicator. But in some sense an artificial indicator that is partially > due to current allocation mechanism rather than real "demand." (That > is, does address utilitization correlate with demand? My earlier > discussion focused more on address utilization.) > > Interesting academic questions, but I am surprised it makes much of a > difference in policy debate. Exhaustion is still pre-ordained > conclusion, right? Do a few months one way or other make a big > difference? > > Marshall Eubanks wrote: >> >> On May 6, 2009, at 8:04 AM, Eliot Lear wrote: >> >>> Ted, >>> >>> Here are some interesting data points for this group to consider. >>> According to the U.N., world economic growth dropped from 3.5-4% in >>> 2003-2007 to 2.5% in 2008, and the prediction is for around 1% >>> growth in >>> 2009. At the same time, Geoff Huston's numbers have been shifting to >>> the right. In the case of IANA the number has shifted out 6 months >>> in 6 >>> months. We have not seen quite the same shift for RIR numbers, >>> however. Is world economic growth a controlling variable in the >>> equation of IP address consumption, or merely a coincidence, and how >>> can >>> we tell? >>> >> >> I would expect the RIR allocation requests to be a lagging indicator >> of the economic situation, and >> that address usage would be simultaneous with or even a leading >> indicator of the economy. >> >> Regards >> Marshall >> >>> Eliot >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing 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. >>> >> >> Regards >> Marshall Eubanks >> CEO / AmericaFree.TV >> >> > From dave at connetrix.com Wed May 6 13:40:15 2009 From: dave at connetrix.com (Dave Feuer) Date: Wed, 6 May 2009 13:40:15 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revised andforwarded to the Board In-Reply-To: <28E139F46D45AF49A31950F88C497458F8715E@E03MVZ2-UKDY.domain1.systemhost.net> References: <00c401c9ce62$4a2d7620$de886260$@com> <28E139F46D45AF49A31950F88C497458F8715E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <011001c9ce71$b74d69e0$25e83da0$@com> And I'm sure a lot of this is caused by M&A issues and the integration of multiple networks. Forgot who --> UUNet --> MCI --> Verizon BUT I just did a bit more checking, my old college had a /18 back in the 90's. That one is long gone and now they have another /19. (Bunch of schools merged into one university group) guess what the old /18 still resolves to them and I know for a fact that they are not broadcasting it at all, nor do they even have the old ASN active. Just for s--ts and giggles I tried the email addresses and phone #s associated with it and none of them work. Anybody want 16k addresses. These are issues that ARIN can resolve in house with a bit of auditing. And no, I won't reveal the school. I still do business and have a working relationship with the IT and other staff there, I did however just mention it to my contacts there. They are going to look into it after the end of semester / graduation / beginning of summer class registration mess is finished. -Dave -----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: Wednesday, May 06, 2009 1:14 PM To: ARIN-PPML at arin.net Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revised andforwarded to the Board > Looking back on some old IP assignments that were allocated > to us and others I have dealt with by providers over the > years I can say that there are a lot of old blocks not being > reallocated to other customers. Some of these have not been > active in over 6 years. And this is not for just a /29 or > something. We are talking multiple /24 and better. Sloppy management of addresses. That is why ARIN is now going to require a corporate officer to attest to any address usage reports. That should trigger companies to do proper audits, with trained auditors, and that will uncover the slop which they will then recover and reuse internally. ARIN is powerless to do anything with those "lost" addresses. The best case scenario is that all the ISPs discover the wealth that they have in-house and make use of it to cover the gap until IPv6 is fully deployed. After that it won't matter anymore. --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 Wed May 6 13:53:24 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 6 May 2009 10:53:24 -0700 Subject: [arin-ppml] Some data relating to IPv4 address exhaustion (or not) In-Reply-To: <4A017CB6.4040503@cisco.com> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> <4A017CB6.4040503@cisco.com> Message-ID: <7B3806B2AB0A46B2B5763BC3BBF5EFCE@tedsdesk> In simple terms, yes. In my opinion there are other, more accurate, controlling variables in the equation of IP address consumption, SOME of these variables are also controlling variables of world economic growth. It is like saying that US auto ownership is a controlling variable of US oil consumption. There is a casual relationship there but I think in the overall analysis, both those figures track US economic activity more than they track each other. If you want to play with this, here's some suggestions of controlling variables: Growth of networkable hosts - this is the count of all networkable hosts in the world at any given time and is easily estimated by graphing the uptake of MAC addresses. Distribution of networkable hosts - this is the density of networkable hosts in a given area. The idea here is that just because a host has a network interface, it is not necessarly plugged into anything and it takes a critical mass of hosts in a given "cultural group" to ignite the demand for Internet connectivity. You could estimate this figure by assuming that, say, today 80% of all networkable hosts exist in a cultural group that has reached critical mass, and developing a historical graph. You could also divide up the world into areas and count the number of routers on the Internet in those areas. I say "cultural group" because it's obvious if, for example, a person is a member of a culture which doesn't have much of interest on the Internet (Amish perhaps?) they might have a computer but they likely wouldn't have interest in connecting it to the Internet. They would more likely be interested in connecting it to an internal network like a corporate network or something which wouldn't demand connectivity. Type of networkable hosts - some hosts like PC's running Windows or Mac's running MacOS demand full time Internet connectivity for patch updates, and are most likely to be connected to the Internet. Some hosts, like a network print server, may spend their entire production life never sending a packet to the Internet. The distribution figures of various host types can be roughly estimated by looking at cell network expansion (number of cell towers, since smart phones demand MAC addresses but seldom use public IP addresses, and smartphone use is a percentage of all cell phone use) computer sales, and MAC address uptake. Location of host growth. Some areas of the world are growing in IPv6 demand much more than North America and are not growing in IPv4 demand. Length if time networkable hosts are in service in a given area - this is the idea that the longer a "cultural group" of networkable hosts are in service, the more likely that they will connect. My gut feeling, though, is that the reason we are seeing a rolloff of IPv4 uptake is that the largest consumers of IPv4 - the cellular networks - commenced shifting to IPv6 several years ago, and I am guessing that the very last IPv4 block that was handed out to a cell network for assignment to phones was handed out in 2008. The $64,000 question, though, is what are the other large consumers of IPv4 planning on doing? I'm thinking specifically of the cable TV networks but there's also the wireless and DSL people too. They certainly see IPv4-runout getting closer and closer and clearly they will have to shift to IPv6. If they wait until the last /8 is assigned then shift, runout will happen more quickly than if they shift a year or so in advance. Recall I posted a week ago that I think there's a good chance that IPv4 runout will not be a single, cataclysmic event that will happen on a single date, but will be more gradual. For example, a common myth is that the automobile made the horse drawn carriage obsolete and signaled the end of buggy whip manufacture. In actual fact, there are still buggy whip manufacturers today. Horse drawn carriage manufacturing didn't die at a single date - it was a process that took years for carriage & buggy whip manufacture to die down to the niche market it is today. (people love to talk about similar shifts like the introduction of electricity and introduction of the telephone as happening with lightning speed when they happened, but those are myths, too) Note that I've set followups to arin-discuss Ted > -----Original Message----- > From: Eliot Lear [mailto:lear at cisco.com] > Sent: Wednesday, May 06, 2009 5:04 AM > To: Ted Mittelstaedt > Cc: 'arin ppml'; William Lehr > Subject: Some data relating to IPv4 address exhaustion (or not) > > Ted, > > Here are some interesting data points for this group to consider. > According to the U.N., world economic growth dropped from 3.5-4% in > 2003-2007 to 2.5% in 2008, and the prediction is for around > 1% growth in 2009. At the same time, Geoff Huston's numbers > have been shifting to the right. In the case of IANA the > number has shifted out 6 months in 6 months. We have not > seen quite the same shift for RIR numbers, however. Is world > economic growth a controlling variable in the equation of IP > address consumption, or merely a coincidence, and how can we tell? > > Eliot > From tvest at pch.net Wed May 6 13:58:55 2009 From: tvest at pch.net (Tom Vest) Date: Wed, 6 May 2009 19:58:55 +0200 Subject: [arin-ppml] Some data relating to IPv4 address exhaustion (or not) In-Reply-To: <4A01C752.6050606@cisco.com> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> <4A017CB6.4040503@cisco.com> <19A03C0B-FA32-481F-B037-5EA64A399065@americafree.tv> <4A01C5A8.4080705@mit.edu> <4A01C752.6050606@cisco.com> Message-ID: <81E916D1-E9F5-4669-8EDA-431BDE3C78DC@pch.net> FYI, global demand for "initial allocations" a.k.a., new entrants in the routing services market -- those for whom neither RFC 1918 nor IPv6 (as of today) is even remotely substitutable for IPv4 -- stood at about avg. 2-3 successful seekers *per day* at the lowest moment in recorded history, c. late 2002, at the bottom of the post-telecom collapse slump. The Internet is twice as "big" as it was then, and a similar drop-off today from the long-term trend would probably yield an equivalent daily demand rate much greater than the old all-time low. Any observed deviation from the long-term trend that is substantially larger or longer than the one in 2002 is going to have only two possible explanations: supply/pricing constraints (market power either way) and/or the non-observability of what is really going (i.e., incremental failure of the registration system). TV On May 6, 2009, at 7:22 PM, Eliot Lear wrote: > Bill, > > Here is my real question: if demand for new address allocations is > weak > post-runout (meaning greater than 100% allocated when the cost is 0), > what happens when the cost is > 0 in such an environment? At what > point > do we hit a knee of some form? > > Regards, > > Eliot > > On 5/6/09 7:15 PM, William Lehr wrote: >> That is a reasonable hypothesis, but I would not be surprised if >> there >> were no correlation at all because of the complex dynamics associated >> with address usage. >> >> Basically, IP addresses are a small share of costs to run a network >> and even smaller share of corporate IT budgets so should not be >> closely correlated with it. Yes, there is presumably rough >> correlation >> between number of employees, corporate capital expenditures, and >> other >> such indicators associated with overall economy, but I would expect >> that to be very noisy. Issues like architecture reconfiguration could >> increase or decrease need for addresses and so direction of impact of >> business cycles on IP address demand would be ambiguous. >> >> On other hand, since addresses are allocated in one-way process (from >> unallocated pool to demanders) and new allocations justified by need >> to meet expanded user-base, there is implicit linkage between >> business >> cycles and demand, and that seems likely to make it a leading >> indicator. But in some sense an artificial indicator that is >> partially >> due to current allocation mechanism rather than real "demand." (That >> is, does address utilitization correlate with demand? My earlier >> discussion focused more on address utilization.) >> >> Interesting academic questions, but I am surprised it makes much of a >> difference in policy debate. Exhaustion is still pre-ordained >> conclusion, right? Do a few months one way or other make a big >> difference? >> >> Marshall Eubanks wrote: >>> >>> On May 6, 2009, at 8:04 AM, Eliot Lear wrote: >>> >>>> Ted, >>>> >>>> Here are some interesting data points for this group to consider. >>>> According to the U.N., world economic growth dropped from 3.5-4% in >>>> 2003-2007 to 2.5% in 2008, and the prediction is for around 1% >>>> growth in >>>> 2009. At the same time, Geoff Huston's numbers have been >>>> shifting to >>>> the right. In the case of IANA the number has shifted out 6 months >>>> in 6 >>>> months. We have not seen quite the same shift for RIR numbers, >>>> however. Is world economic growth a controlling variable in the >>>> equation of IP address consumption, or merely a coincidence, and >>>> how >>>> can >>>> we tell? >>>> >>> >>> I would expect the RIR allocation requests to be a lagging indicator >>> of the economic situation, and >>> that address usage would be simultaneous with or even a leading >>> indicator of the economy. >>> >>> Regards >>> Marshall >>> >>>> Eliot >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing 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. >>>> >>> >>> Regards >>> Marshall Eubanks >>> CEO / AmericaFree.TV >>> >>> >> > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From lear at cisco.com Wed May 6 14:07:47 2009 From: lear at cisco.com (Eliot Lear) Date: Wed, 06 May 2009 20:07:47 +0200 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C9@mail> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C2@mail> <4A01B63C.20909@cisco.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C9@mail> Message-ID: <4A01D1F3.3000205@cisco.com> On 5/6/09 6:16 PM, Kevin Kargel wrote: > There are too many unknowns to be able to quantify anything. That does not > invalidate the existence of the issue. > Neither does it validate it. Eliot From bill at herrin.us Wed May 6 14:14:29 2009 From: bill at herrin.us (William Herrin) Date: Wed, 6 May 2009 14:14:29 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> References: <49FF15ED.4070902@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> Message-ID: <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> On Tue, May 5, 2009 at 6:36 PM, Ted Mittelstaedt wrote: > I have to cry foul with this. ?There's been implications > of hoarding on this list and in the last meeting but I have only > seen a single allegation posted on this list of an illigitimate > IPv4 holding, and that was a year ago. ?(and it wasn't a hoarding > situation) Ted, When a hurricane is coming and you buy all the flashlights at your local store, you're hoarding. There was nothing illegitimate about your purchase. You paid full price. You didn't steal anything. You may even use them all. But you're still hoarding. Verizon is hoarding addresses. They requested and acquired millions of addresses for use on cell phones in their wireless arm. The requests were perfectly legitimate. Every address matches an actual physical device and they're not doubling up. Nevertheless, they're hoarding addresses. The way they use IP addresses on the cell phones, they'd have been A-OK with RFC1918 addresses plus a few public IPs for the NAT gateways. They'll surely discover the magic of NAT... in about 4 years when they need those IP addresses somewhere else in the company. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bicknell at ufp.org Wed May 6 14:50:19 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 6 May 2009 14:50:19 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> References: <49FF15ED.4070902@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> Message-ID: <20090506185019.GA31911@ussenterprise.ufp.org> In a message written on Wed, May 06, 2009 at 02:14:29PM -0400, William Herrin wrote: > Verizon is hoarding addresses. They requested and acquired millions of Several folks have made the same mistaken in recent messages, so this is not to single out William... Please refrain from referring to companies by name when discussing policy. Generally it's not necessary, generic terms like "a wireless company", "a DSL company", or "a cable company" work just fine to set a frame of reference. Using the names is problematic for two reasons; first we don't want policies that single out particular companies we want policies that work for all players. Second, most of the time folks generally don't have internal knowledge of these companies when they use them by name, and thus are making assumptions that are often not true. At best this leads to confusion, at worst, outright anger from those on the other side of the fence. If you do want to make a specific claim of wrong-doing, then using the mailing list is absolutely the wrong way to report it, use the form at https://www.arin.net/resources/fraud/index.html. We're not all perfect, I have slipped up on this more than a few times myself. It's best for everyone if we try hard to stay generic. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From tedm at ipinc.net Wed May 6 15:57:11 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 6 May 2009 12:57:11 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy?Revisedandforwarded to the Board In-Reply-To: <28E139F46D45AF49A31950F88C497458F2CAA6@E03MVZ2-UKDY.domain1.systemhost.net> References: <4965BB968A4345ABA110CEBA7971EDFA@tedsdesk> <28E139F46D45AF49A31950F88C497458F2CAA6@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B7F23B7397D449B89F09FF1769ED41C@tedsdesk> Michael, All of that is fine with one problem and that is that these large telecoms like Level 3 who had my name on a netblock SWIP for 4 years after it was unused, are essentially committing fraud when they apply for new IPv4 allocations, and use my name as part of their justification that they need more IPv4. Granted, it's not fraud from the perspective that it meets a legal test for fraud - since there's a lack of intent, here. But, morally it's fraud. Let me put it this way. You and your wife are living your life, saving money, having a good relationship otherwise. You need a new laptop and you tell your wife and she agrees and you go to the store to buy one. When you get to the store you discover your missing a pen and paper so you dig through your glovebox to find one, and you come across an envelope that you stuck in the car glovebox 4 years ago before you were married, that has 5 100 dollar bills in it. You then remember the money is a leftover from a trip you took to Vegas at that time and you just never put it back in the bank. You had already told your wife the new laptop would cost $800 and she was OK with that. But you realize now that with the $1300 that you could get a much more expensive laptop that has a TV tuner and blueray burner in it, plus a really cool video card that you can play the latest Quake on. You don't need these things but they would be really fun addons to have. Do you add the extra $500 to the money you were going to spend on the laptop or not? You see, this is essentially the moral situation your laying out. The morally right thing to do would be to call your wife from the store and let her know what you found and ask if she didn't mind if you spent the $500. But what your advocating here in my view is similar to the guy just buying the $1300 laptop and then saying nothing about it, using the excuse that he "found" the IPv4 addresses I mean $500 because he was housecleaning his network I mean car glovebox. Do you get what I'm saying? Ted > -----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: Wednesday, May 06, 2009 1:38 AM > To: ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer > Policy?Revisedandforwarded to the Board > > > My feeling has always been that talk of a transfer market is very > > misguided, that there's plenty of "mineable" IPv4 in allocations > > already made that have been abandonded, and our reclamation efforts > > should focus there first. > > Lots of that minable IPv4 is in the hands of the ISPs who > will need it. In other words, when some organization realizes > that they need more IPv4 addresses and ARIN can no longer > supply them, they will be able to invest the money into > mining their own supply rather than spending money on buying > addresses from someone else. Some of these minable addresses > might fall under the category that some people call > "hoarding" although I don't think that is a proper term for > it. But lots of them are perfectly legitimately held IP > addresses, for instance assignments to DHCP pools used by > broadband DSL customers. > > When the runout occurs, many companies will be able to > identify blocks of IPv4 internally, which do not supply as > much profit per IP address as another service which is short > of addresses. > The "mining" activity is to either shut off less profitable > customers or to forcefully migrate them to IPv6 services. At > that point, the freed up IPv4 addresses can be repurposed. > > Also, most large telecoms companies have a problem with > cleaning up after customers are disconnected, or after they > upgrade to a service which requires a new circuit. Part of > that cleanup is to recover the unused IPv4 addresses. There > is not a lot of incenctive to do this cleanup today, but > there will be when ARIN runs out of IPv4. A company where I > used to work was spending over > $2 million dollars per month on unused access lines because > of not cleaning up after disconnects. > > So, we don't need ARIN to organize any reclamation effort > because the organizations with the minable IPv4 addresses > will have plenty of incentive to do it themselves. > > --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 owen at delong.com Wed May 6 17:58:24 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 6 May 2009 14:58:24 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy ?Revisedandforwarded to the Board In-Reply-To: <28E139F46D45AF49A31950F88C497458F2CA73@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458F2CA73@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <25B0DF1D-B360-4452-ABD8-7196270A7139@delong.com> On May 6, 2009, at 1:27 AM, wrote: >> The sunset clause was about building trust. It was about >> finding a compromise that brought everyone under the same >> tent. It was a promise to the unsure that there would be a >> top-to-bottom review. > > Wait a minute, that is not a sunset clause, that is a review > date. A sunset clause says that something will end on that > date, period. No review. No renewal. Nothing. > No... The difference between a sunset clause and a review clause is the default outcome of such a review. If there is a review clause, it just means that a review has to be conducted, but, absent consensus to do something as a result of that review, nothing changes. If there is a sunset clause, then, absent a review and consensus, the policy expires and we return to the previous state before the policy was enacted. This default return is what was expected by the proponents of the sunset clause and the members of the community that accepted the proposal on the basis of it containing a sunset clause. Personally, I feel that the interaction between the existing sunset clause and the board's decision to implement on a much faster timetable than the AC anticipated created a difficult conundrum for the AC. There were no good options open to the AC under the circumstance. > If you want some kind of policy that includes a built-in reveiew > date then please say so in plain English and don't pussyfoot > around with redefining the meaning of words and pompous > language. Instead of attaching an explanation of what you mean, > hone the wording of the policy until it is clear and > and unambiguous. > The desire was to force a review date with a strong prejudice for terminating the policy unless there was consensus to continue it. That's what a sunset clause effectively does. >> These events have left me smarter though. I now realize >> sunset provisions don't work. > > Yes they do. After the sunset date, the policy or law is no > longer operative. > Sunset provisions can work, but, the processing of these two policies (2008-6 and 2009-1) has identified a number of areas for further evaluation of the ARIN PDP which I believe the AC and the board will be working on in the near future and for some time. >> The promise of a comprehensive >> review, on a timetable, has already been broken. > > That is not a sunset clause. > A sunset clause is ONE mechanism for ensuring such a thing and setting a particular default outcome. There are others with different default outcomes. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From Fred.Wettling at Bechtel.com Wed May 6 18:11:17 2009 From: Fred.Wettling at Bechtel.com (Wettling, Fred) Date: Wed, 6 May 2009 18:11:17 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised and forwarded to the Board In-Reply-To: <49FF15ED.4070902@arin.net> References: <49FF15ED.4070902@arin.net> Message-ID: I oppose the insertion of a sunset clause, expiration date, review date, or renewal date in Draft Policy 2009-1. From my perspective, date constraints add no value to the objective of this proposal. Needs-based reviews are part of the natural policy management cycle. Section 8 is in ARIN's Number Resource Policy Manual (NRPM) today and proposed changes are being discussed in the PPML. If another change is needed in the future, we should use the appropriate ARIN review process at that point in time. Regards - Fred Wettling From bill at herrin.us Wed May 6 19:46:51 2009 From: bill at herrin.us (William Herrin) Date: Wed, 6 May 2009 19:46:51 -0400 Subject: [arin-ppml] =?windows-1252?q?Draft_Policy_2009-1=3A_Transfer_Poli?= =?windows-1252?q?cy_=96_Revised_and_forwarded_to_the_Board?= In-Reply-To: <49FF15ED.4070902@arin.net> References: <49FF15ED.4070902@arin.net> Message-ID: <3c3e3fca0905061646o5fbdda5cj93841c53ca590fc5@mail.gmail.com> On Mon, May 4, 2009 at 12:21 PM, Member Services wrote: > The ARIN Advisory Council (AC) met on 29 April 2009 and decided to send > a revised version of 2009-1 to the Board for their consideration: > Draft Policy 2009-1: Transfer Policy I support the AC-modified proposal 2009-1. I would still prefer to see a sunset date. Virginia sunsetted its stop-light cameras. As a result they went away: the statistics didn't bear out the proponents claims that they'd reduce accidents. So when the time came the legislators didn't vote to renew it. Not that I run stoplights or anything, but those cameras were plain evil. My point is that when you have a very contentious issue which hinges on its proponents demonstrating something that can't be proven until after the idea is tried out in practice, a sunset date is a healthy thing. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Wed May 6 19:58:23 2009 From: bill at herrin.us (William Herrin) Date: Wed, 6 May 2009 19:58:23 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <20090506185019.GA31911@ussenterprise.ufp.org> References: <49FF15ED.4070902@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> Message-ID: <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> On Wed, May 6, 2009 at 2:50 PM, Leo Bicknell wrote: > In a message written on Wed, May 06, 2009 at 02:14:29PM -0400, William Herrin wrote: >> Verizon is hoarding addresses. They requested and acquired millions of > > Please refrain from referring to companies by name when discussing > policy. ?Generally it's not necessary, generic terms like "a wireless > company", "a DSL company", or "a cable company" work just fine to > set a frame of reference. Leo, I respectfully disagree with your assessment. Ted said: "There's been implications of hoarding on this list and in the last meeting but I have only seen a single allegation." That's a fair complaint. Who are these unnamed hoarders we're so worried about and why isn't current policy stopping them? The question calls for specificity. Proof by example that the hoarders exist. While you're right that I don't have internal company knowledge, I do have one of the vendor's phones using one of the hoarded IP addresses and I've done enough testing with it to confirm that its only capable of initiating connections outbound to the Internet, the key criteria for a NAT-compatible device. Inbound connections are blocked, not by the device but by the vendor's upstream firewall. > If you do want to make a specific claim of wrong-doing, then using > the mailing list is absolutely the wrong way to report it, use the > form at https://www.arin.net/resources/fraud/index.html. A big part of my point was that many of the obvious and egregious cases of hoarding are specifically *not* instances of fraud. My favorite vendor is hoarding, apparently in meticulous compliance with all applicable policies. Thus equating hoarding with fraud is incorrect. They are distinct phenomena. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From marquis at roble.com Wed May 6 22:41:47 2009 From: marquis at roble.com (Roger Marquis) Date: Wed, 6 May 2009 19:41:47 -0700 (PDT) Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> Message-ID: <20090507024147.A228E2B21FC@mx5.roble.com> Ted Mittelstaedt wrote: >> Rather than helping the problem the fact that this market is >> being discussed is exactly what is causing the hoarding. > > I have to cry foul with this. There's been implications > of hoarding on this list and in the last meeting but I have only > seen a single allegation posted on this list of an illigitimate > IPv4 holding, and that was a year ago. (and it wasn't a hoarding > situation) If hoarding includes large netblocks (mainly /16s) that are not used and/or not needed I can name several, and even a cursory audit will show dozens. > Since true hoarding implies false data submitted for an IPv4 This may be a source of confusion. Hoarding does not imply false data submitted for an IPv4. Roger Marquis From mksmith at adhost.com Wed May 6 23:22:46 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 6 May 2009 20:22:46 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <20090507024147.A228E2B21FC@mx5.roble.com> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail><81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <20090507024147.A228E2B21FC@mx5.roble.com> Message-ID: <17838240D9A5544AAA5FF95F8D5203160605CC47@ad-exh01.adhost.lan> > Ted Mittelstaedt wrote: > >> Rather than helping the problem the fact that this market is > >> being discussed is exactly what is causing the hoarding. > > > > I have to cry foul with this. There's been implications > > of hoarding on this list and in the last meeting but I have only > > seen a single allegation posted on this list of an illigitimate > > IPv4 holding, and that was a year ago. (and it wasn't a hoarding > > situation) > > If hoarding includes large netblocks (mainly /16s) that are not used > and/or > not needed I can name several, and even a cursory audit will show > dozens. > > > Since true hoarding implies false data submitted for an IPv4 > > This may be a source of confusion. Hoarding does not imply false data > submitted for an IPv4. > > Roger Marquis I would argue that the present state of things actually facilitates hoarding, given that only the last allocation is assessed as part of the allocation of the next. Any previous allocations could be unused, barely used or used less. Thus, you can hoard addresses by only assigning from your last allocation and still be playing strictly by the rules. Sadly, the concept of having to justify all of your allocations to get your next one doesn't seem to get much traction. Mike From tedm at ipinc.net Wed May 6 23:26:08 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 6 May 2009 20:26:08 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revisedandforwarded to the Board In-Reply-To: <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail><81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk><3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com><20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> Message-ID: William and Leo, Referring to specific names of companies in a positive way is not usually the problem in the generic kind of discussions (like this one) that so often split off from the policy being discussed. The problem is making a negative statement that is not provable. Hoarding is an unproven negative term, and use of such unproven negative terms in conjunction with a specific company should be avoided. But, here is where the politically correct movement can help solve the problem. Instead of use of the term "hoarder" may I suggest the politically correct term: "negative-deficiency" So, instead of saying that Wonkulating Gronkulator is an IP address hoarder, you can say: Wonkulating Gronkulator is a negatively-deficient IP address consumer. Problem solved! ;-) Ted > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin > Sent: Wednesday, May 06, 2009 4:58 PM > To: arin ppml > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy > - Revisedandforwarded to the Board > > On Wed, May 6, 2009 at 2:50 PM, Leo Bicknell wrote: > > In a message written on Wed, May 06, 2009 at 02:14:29PM > -0400, William Herrin wrote: > >> Verizon is hoarding addresses. They requested and acquired > millions > >> of > > > > Please refrain from referring to companies by name when discussing > > policy. ?Generally it's not necessary, generic terms like > "a wireless > > company", "a DSL company", or "a cable company" work just > fine to set > > a frame of reference. > > Leo, > > I respectfully disagree with your assessment. > > Ted said: "There's been implications of hoarding on this list > and in the last meeting but I have only seen a single allegation." > > That's a fair complaint. Who are these unnamed hoarders we're > so worried about and why isn't current policy stopping them? > The question calls for specificity. Proof by example that the > hoarders exist. > > While you're right that I don't have internal company > knowledge, I do have one of the vendor's phones using one of > the hoarded IP addresses and I've done enough testing with it > to confirm that its only capable of initiating connections > outbound to the Internet, the key criteria for a > NAT-compatible device. Inbound connections are blocked, not > by the device but by the vendor's upstream firewall. > > > > If you do want to make a specific claim of wrong-doing, > then using the > > mailing list is absolutely the wrong way to report it, use > the form at > > https://www.arin.net/resources/fraud/index.html. > > A big part of my point was that many of the obvious and > egregious cases of hoarding are specifically *not* instances > of fraud. My favorite vendor is hoarding, apparently in > meticulous compliance with all applicable policies. > > Thus equating hoarding with fraud is incorrect. They are > distinct phenomena. > > Regards, > Bill Herrin > > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > From scottleibrand at gmail.com Wed May 6 23:59:31 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 6 May 2009 20:59:31 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <17838240D9A5544AAA5FF95F8D5203160605CC47@ad-exh01.adhost.lan> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail><81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <20090507024147.A228E2B21FC@mx5.roble.com> <17838240D9A5544AAA5FF95F8D5203160605CC47@ad-exh01.adhost.lan> Message-ID: Michael, I just re-read the ISP and end-user sections of the NRPM, and both require 80% usage of ALL previous allocations. Can you clarify whether you were referring to the NRPM, operational practice, or something else? Thanks, Scott On May 6, 2009, at 8:22 PM, "Michael K. Smith - Adhost" wrote: >> Ted Mittelstaedt wrote: >>>> Rather than helping the problem the fact that this market is >>>> being discussed is exactly what is causing the hoarding. >>> >>> I have to cry foul with this. There's been implications >>> of hoarding on this list and in the last meeting but I have only >>> seen a single allegation posted on this list of an illigitimate >>> IPv4 holding, and that was a year ago. (and it wasn't a hoarding >>> situation) >> >> If hoarding includes large netblocks (mainly /16s) that are not used >> and/or >> not needed I can name several, and even a cursory audit will show >> dozens. >> >>> Since true hoarding implies false data submitted for an IPv4 >> >> This may be a source of confusion. Hoarding does not imply false >> data >> submitted for an IPv4. >> >> Roger Marquis > > I would argue that the present state of things actually facilitates > hoarding, given that only the last allocation is assessed as part of > the > allocation of the next. Any previous allocations could be unused, > barely used or used less. Thus, you can hoard addresses by only > assigning from your last allocation and still be playing strictly by > the > rules. > > Sadly, the concept of having to justify all of your allocations to get > your next one doesn't seem to get much traction. > > Mike > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 martin.hannigan at batelnet.bs Thu May 7 00:27:58 2009 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Thu, 7 May 2009 00:27:58 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> References: <49FF15ED.4070902@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> Message-ID: <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> On Wed, May 6, 2009 at 7:58 PM, William Herrin wrote: > On Wed, May 6, 2009 at 2:50 PM, Leo Bicknell wrote: >> In a message written on Wed, May 06, 2009 at 02:14:29PM -0400, William Herrin wrote: >>> Verizon is hoarding addresses. They requested and acquired millions of >> >> Please refrain from referring to companies by name when discussing >> policy. ?Generally it's not necessary, generic terms like "a wireless >> company", "a DSL company", or "a cable company" work just fine to >> set a frame of reference. > > Leo, > > I respectfully disagree with your assessment. > > Ted said: "There's been implications of hoarding on this list and in > the last meeting but I have only seen a single allegation." > That's a fair complaint. Who are these unnamed hoarders we're so > worried about and why isn't current policy stopping them? The question > calls for specificity. Proof by example that the hoarders exist. > > While you're right that I don't have internal company knowledge, I do > have one of the vendor's phones using one of the hoarded IP addresses > and I've done enough testing with it to confirm that its only capable > of initiating connections outbound to the Internet, the key criteria > for a NAT-compatible device. Inbound connections are blocked, not by > the device but by the vendor's upstream firewall. > > >> If you do want to make a specific claim of wrong-doing, then using >> the mailing list is absolutely the wrong way to report it, use the >> form at https://www.arin.net/resources/fraud/index.html. > > A big part of my point was that many of the obvious and egregious > cases of hoarding are specifically *not* instances of fraud. My > favorite vendor is hoarding, apparently in meticulous compliance with > all applicable policies. > Trying to tell us that technology limitations = hoarding is not helpful. > Thus equating hoarding with fraud is incorrect. They are distinct phenomena. And inaccurate and even out of context. Let's not play games with companies reputations here even if there is specific, hard, evidence. This isn't the place for it. This is the policy list. Not the accusations list. I agree with Leo. In the interest of cooking policy, we don't need to use names. From tedm at ipinc.net Thu May 7 00:31:35 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 6 May 2009 21:31:35 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revisedandforwarded to the Board In-Reply-To: References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail><81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk><20090507024147.A228E2B21FC@mx5.roble.com><17838240D9A5544AAA5FF95F8D5203160605CC47@ad-exh01.adhost.lan> Message-ID: Scott, I think your right but keep the following in mind Let's say the first year the ISP obtains a /20. A year later they have reached 80% on this and get a second /20. A year later on this they have reached 80% on the second and get a third /20 This happens for 5 years in a row. At the end of the 5 years even though they have 80% utilization on all /20's, and can request another /20 by the rules, the fact is that they now have a /20's worth of unused IP addresses. Perhaps we need a policy change that states that additional IPv4 allocation requests from ISP's cannot equal or be smaller than the amount of unallocated space they already have, regardless of the 80 percentile rule? Ted > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand > Sent: Wednesday, May 06, 2009 9:00 PM > To: Michael K. Smith - Adhost > Cc: Roger Marquis; > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy > - Revisedandforwarded to the Board > > Michael, > > I just re-read the ISP and end-user sections of the NRPM, and > both require 80% usage of ALL previous allocations. Can you > clarify whether you were referring to the NRPM, operational > practice, or something else? > > Thanks, > Scott > > On May 6, 2009, at 8:22 PM, "Michael K. Smith - Adhost" > wrote: > > >> Ted Mittelstaedt wrote: > >>>> Rather than helping the problem the fact that this > market is being > >>>> discussed is exactly what is causing the hoarding. > >>> > >>> I have to cry foul with this. There's been implications > of hoarding > >>> on this list and in the last meeting but I have only seen > a single > >>> allegation posted on this list of an illigitimate > >>> IPv4 holding, and that was a year ago. (and it wasn't a hoarding > >>> situation) > >> > >> If hoarding includes large netblocks (mainly /16s) that > are not used > >> and/or not needed I can name several, and even a cursory > audit will > >> show dozens. > >> > >>> Since true hoarding implies false data submitted for an IPv4 > >> > >> This may be a source of confusion. Hoarding does not imply false > >> data submitted for an IPv4. > >> > >> Roger Marquis > > > > I would argue that the present state of things actually facilitates > > hoarding, given that only the last allocation is assessed > as part of > > the allocation of the next. Any previous allocations could > be unused, > > barely used or used less. Thus, you can hoard addresses by only > > assigning from your last allocation and still be playing > strictly by > > the rules. > > > > Sadly, the concept of having to justify all of your > allocations to get > > your next one doesn't seem to get much traction. > > > > Mike > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed > to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From bill at herrin.us Thu May 7 00:41:32 2009 From: bill at herrin.us (William Herrin) Date: Thu, 7 May 2009 00:41:32 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> References: <49FF15ED.4070902@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> Message-ID: <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> On Thu, May 7, 2009 at 12:27 AM, Martin Hannigan wrote: > On Wed, May 6, 2009 at 7:58 PM, William Herrin wrote: >> On Wed, May 6, 2009 at 2:50 PM, Leo Bicknell wrote: >>> In a message written on Wed, May 06, 2009 at 02:14:29PM -0400, William Herrin wrote: >>>> Verizon is hoarding addresses. They requested and acquired millions of >> While you're right that I don't have internal company knowledge, I do >> have one of the vendor's phones using one of the hoarded IP addresses >> and I've done enough testing with it to confirm that its only capable >> of initiating connections outbound to the Internet, the key criteria >> for a NAT-compatible device. Inbound connections are blocked, not by >> the device but by the vendor's upstream firewall. >> >> A big part of my point was that many of the obvious and egregious >> cases of hoarding are specifically *not* instances of fraud. My >> favorite vendor is hoarding, apparently in meticulous compliance with >> all applicable policies. > > Trying to tell us that technology limitations = hoarding is not helpful. Martin, NAT = conserves IP addresses. Meets criteria for NAT-compatible device = could be built with NAT Not built with NAT + millions of devices = consumes millions of IP addresses Not built with NAT + could be + consumes millions = hoarding If you got "technology limitations = hoarding" from that, you ain't readin' it right. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From martin.hannigan at batelnet.bs Thu May 7 00:54:10 2009 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Thu, 7 May 2009 00:54:10 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> References: <49FF15ED.4070902@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> Message-ID: <4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com> On Thu, May 7, 2009 at 12:41 AM, William Herrin wrote: > On Thu, May 7, 2009 at 12:27 AM, Martin Hannigan > wrote: >> On Wed, May 6, 2009 at 7:58 PM, William Herrin wrote: >>> On Wed, May 6, 2009 at 2:50 PM, Leo Bicknell wrote: >>>> In a message written on Wed, May 06, 2009 at 02:14:29PM -0400, William Herrin wrote: >>>>> Verizon is hoarding addresses. They requested and acquired millions of >>> While you're right that I don't have internal company knowledge, I do >>> have one of the vendor's phones using one of the hoarded IP addresses >>> and I've done enough testing with it to confirm that its only capable >>> of initiating connections outbound to the Internet, the key criteria >>> for a NAT-compatible device. Inbound connections are blocked, not by >>> the device but by the vendor's upstream firewall. >>> >>> A big part of my point was that many of the obvious and egregious >>> cases of hoarding are specifically *not* instances of fraud. My >>> favorite vendor is hoarding, apparently in meticulous compliance with >>> all applicable policies. >> >> Trying to tell us that technology limitations = hoarding is not helpful. > > Martin, > > NAT = conserves IP addresses. > Meets criteria for NAT-compatible device = could be built with NAT > Not built with NAT + millions of devices = consumes millions of IP addresses > Not built with NAT + could be + consumes millions = hoarding > > If you got "technology limitations = hoarding" from that, you ain't > readin' it right. William, You're saying that just about every service provider on the planet is "hoarding". Am I reading you correct? Best, Martin From jradel at vantage.com Thu May 7 01:05:09 2009 From: jradel at vantage.com (Jon Radel) Date: Thu, 07 May 2009 01:05:09 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> References: <49FF15ED.4070902@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> Message-ID: <4A026C05.2010601@vantage.com> William Herrin wrote: > NAT = conserves IP addresses. > Meets criteria for NAT-compatible device = could be built with NAT > Not built with NAT + millions of devices = consumes millions of IP addresses > Not built with NAT + could be + consumes millions = hoarding > > If you got "technology limitations = hoarding" from that, you ain't > readin' it right. > > I would say that your little equations show some anecdotal evidence of "waste." "Hoarding" generally carries implications about intent which you're not, and probably can't, demonstrate. -- Jon Radel Senior Director of Engineering Vantage Communications p: 267-756-1014 f: 202-742-5661 e: jradel at vantage.com "When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the state of science, whatever the matter may be." ~Lord Kelvin -------------- 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 bill at herrin.us Thu May 7 01:29:59 2009 From: bill at herrin.us (William Herrin) Date: Thu, 7 May 2009 01:29:59 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com> References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> <4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com> Message-ID: <3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> On Thu, May 7, 2009 at 12:54 AM, Martin Hannigan wrote: > On Thu, May 7, 2009 at 12:41 AM, William Herrin wrote: >>>>> In a message written on Wed, May 06, 2009 at 02:14:29PM -0400, William Herrin wrote: >>>>>> Verizon is hoarding addresses. They requested and acquired millions of >> NAT = conserves IP addresses. >> Meets criteria for NAT-compatible device = could be built with NAT >> Not built with NAT + millions of devices = consumes millions of IP addresses >> Not built with NAT + could be + consumes millions = hoarding >> >> If you got "technology limitations = hoarding" from that, you ain't >> readin' it right. > > You're saying that just about every service provider on the planet is > "hoarding". Am I reading you correct? Martin, No. I'm saying that the ones who deliver stateful firewalled service to a large base of customers using global IPs instead of private IPs, and who deliberately built it that way just in the last couple of years did so knowing the score. The number of service providers delivering that kind of service is relatively small but scope of some of those services is quite large. And some of them are hoarding. On Thu, May 7, 2009 at 1:05 AM, Jon Radel wrote: > "Hoarding" generally carries implications about intent which > you're not, and probably can't, demonstrate. Jon, You're quite right. And I still won't be able to demonstrate that it was pre-planned half a decade from now when they "discover" that they can re-engineer with NAT and then move the addresses to more valuable uses within the company. I'll be able to say, "I told you so," but I won't be able to prove that the six-figures-paid address administrator over at my favorite vendor added two plus two several years ahead of the deadline. Which brings me to my second major point: the hoarding is a fact of life. There is little if anything we can do to stop it. So if we can't stop the hoarding, how do we deal with the results? Step 1. The carrot. Transfer market. Incent the hoarders to sell the addresses so that they become available for general consumption. Step 2. The stick. Give the ARIN board the authority to declare categories of use of IP addresses "no longer sufficiently justified" if after depletion they find there are too few addresses available on the transfer market. Before you explode about step 2, let me point out that ARIN has made comparable policy changes before. There was a time when multiple IP addresses for each site on a web server was a valid justification for more addresses. And then the policy changed so that it wasn't. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scottleibrand at gmail.com Thu May 7 01:35:28 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 06 May 2009 22:35:28 -0700 Subject: [arin-ppml] Policy to reduce inefficiency in IPv4 address use In-Reply-To: <4A026C05.2010601@vantage.com> References: <49FF15ED.4070902@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> <4A026C05.2010601@vantage.com> Message-ID: <4A027320.2010503@gmail.com> I would agree that "waste" is a pretty good word to describe the behavior we're seeing now. Perhaps an even less emotionally charged word would be "inefficiency". I think we're all in agreement that, whatever you call it, such inefficiency of IPv4 address use is not contrary to current policy. If anyone can think of a good way to tighten up policy that would result in more efficient use of IPv4 addresses, in time to make a difference, and without much collateral damage, I'm all ears. Keep in mind that we've tried at least one such policy proposal already that didn't get consensus (IPv4 soft landing), so any suggestions will need to improve on that. I, for one, believe that most of the inefficiency will get wrung out of the system as we hit free pool exhaustion, especially now that we'll have a transfer policy in place. I understand the argument that such a course of events is unfair, and that any actions that would be taken when IPv4 addresses are scarce should be taken now. I'm just not sure how to administratively enforce that. As a possibly interesting tangent, this problem actually bears some similarities to the cap and trade debate going on right now in Congress. Many people are advocating for an allocation of permits to existing emitters, to reduce the disruptive impact of the cap. That's more or less the default situation we have with the current IPv4 policy framework, where existing IPv4 address holders become the suppliers when a transfer market develops. On the other hand are people who think that the government should auction off 100% of the emissions permits, and redistribute the money in some way. But I'm not sure what the analogous policy would be for IPv4, since ARIN is a nonprofit that doesn't really have the authority to (for example) collect and redistribute large sums of money auctioning off the remaining IPv4 addresses... -Scott Jon Radel wrote: > > > William Herrin wrote: >> NAT = conserves IP addresses. >> Meets criteria for NAT-compatible device = could be built with NAT >> Not built with NAT + millions of devices = consumes millions of IP >> addresses >> Not built with NAT + could be + consumes millions = hoarding >> >> If you got "technology limitations = hoarding" from that, you ain't >> readin' it right. >> >> > I would say that your little equations show some anecdotal evidence of > "waste." "Hoarding" generally carries implications about intent which > you're not, and probably can't, demonstrate. > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From michael.dillon at bt.com Thu May 7 04:18:03 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 May 2009 09:18:03 +0100 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy?Revisedandforwarded to the Board In-Reply-To: <4B7F23B7397D449B89F09FF1769ED41C@tedsdesk> Message-ID: <28E139F46D45AF49A31950F88C497458F87361@E03MVZ2-UKDY.domain1.systemhost.net> > Do you get > what I'm saying? No. Company X has the addresses but their SWIP recordkeeping is sloppy. Company X uses the addresses but doesn't update the SWIP. So what? Fact is that the next time around, a company officer will have to attest to the records so there is likely to be a proper audit of the records and many of these sloppy records will be found and fixed. Smart companies are setting up that audit right now with their finance department to ensure that it is properly done by trained auditors. --Michael Dillon From michael.dillon at bt.com Thu May 7 04:34:44 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 May 2009 09:34:44 +0100 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revisedandforwarded to the Board In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458F873CF@E03MVZ2-UKDY.domain1.systemhost.net> > Wonkulating Gronkulator is a negatively-deficient IP > address consumer. Right. So all organizations that have more than a /19 allocation from ARIN are negatively deficient IP address consumers. What do we do now? Maybe we should force them to supply an IP address audit report signed by a corporate officer? Wait! ARIN already did that and without any policy discussion. Hmmm. Maybe this is not a policy matter at all. --Michael Dillon From info at arin.net Thu May 7 06:27:42 2009 From: info at arin.net (Member Services) Date: Thu, 07 May 2009 06:27:42 -0400 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments Message-ID: <4A02B79E.8060807@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at:https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Extend 16 bit ASN Assignments Proposal Originator: Marla Azinger Proposal Version: 1 Submission Date: 6 May 2009 Proposal type: Modify Policy term: Permanent Policy statement: This proposal is to modify section 5.1 in the NRPM to extend the 16-bit ASN assignment timeframe for one more year further than the current text. The expiration requiring removal of section 5.1 is also being removed. Rationale: Currently users of 32-bit ASN?s are encountering technical issues that they can?t immediately overcome and therefore require 16-bit ASN?s to operate. As a result in the ARIN region to date, 204 of the 216 32-bit ASN?s that have been assigned have been returned and exchanged for a 16 bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction between 32-bit and 16-bit ASN?s. This proposal is to change the date on the third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s to be assigned. If these changes are made then ARIN RIR ASN policy will read clearly and remove any misconceptions of 16-bit cutoff post run out and enable technology to catch up to the ASN bit change. The expiration date that requires removal of section 5.1 after zero distinction occurs is to be removed. Instead section 5.1 will be left in place in the NRPM for value added historical purposes. The revision of 5.1 would read as follows: 5.1 16-bit and 32-bit AS Numbers ? Commencing 1 January 2007, ARIN will process applications that specifically request 32-bit only AS Numbers and assign such AS numbers as requested by the applicant. In the absence of any specific request for a 32-bit only AS Number, a 16-bit only AS Number will be assigned. ? Commencing 1 January 2009, ARIN will process applications that specifically request 16-bit only AS Numbers and assign such AS Numbers as requested by the applicant. In the absence of any specific request for a 16-bit only AS Number, a 32-bit only AS Number will be assigned. ? Commencing 1 January 2011, ARIN will cease to make any distinction between 16-bit only AS Numbers and 32-bit only AS Numbers, and will operate AS number assignments from an undifferentiated 32-bit AS Number pool. Terminology ? "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 ? "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 - 4,294,967,295 ? "32-bit AS Numbers" refers to AS Numbers in the range 0 - 4,294,967,295 Timetable for implementation: Immediate From michael.dillon at bt.com Thu May 7 07:13:17 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 May 2009 12:13:17 +0100 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <4A02B79E.8060807@arin.net> Message-ID: <28E139F46D45AF49A31950F88C497458F8776D@E03MVZ2-UKDY.domain1.systemhost.net> If this part of the policy is to be changed in any way, I don't see any value in retaining this structure: > * Commencing 1 January 2007, > * Commencing 1 January 2009, > * Commencing 1 January 2011, Just state the way things are now, and the way that they will be after 01Jan2011. In fact, make it three clauses like so: ZZ.1 this is how it is ZZ.2 after 01Jan2011 the contents of ZZ.1 are replaced with the following: ZZ.2.1 this is how it will be ZZ.3 on 01Jan2011 clauses ZZ.2 and ZZ.3 will be removed --Michael Dillon From cliffb at cjbsys.bdb.com Thu May 7 07:54:48 2009 From: cliffb at cjbsys.bdb.com (Cliff) Date: Thu, 7 May 2009 07:54:48 -0400 (EDT) Subject: [arin-ppml] WSJ aticle on numbers Message-ID: <200905071154.n47Bsmrm012191@cjbsys.bdb.com> >From WSJ 5/5/09 http://online.wsj.com/article/SB124156880475489823.html I found this tidbit interesting. "Most likely, the transition to a system that can accommodate that many addresses will be messy but not catastrophic. The worst-case scenario: "Organizations that have money will have addresses, while organizations that don't have money will fall off the 'Net," says Tony Hain, a fellow at the IPv6 Forum, a group backing a new, expanded Internet-addressing system." Cliff -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From spiffnolee at yahoo.com Thu May 7 10:37:04 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Thu, 7 May 2009 07:37:04 -0700 (PDT) Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> <4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com> <3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> Message-ID: <395570.6547.qm@web63304.mail.re1.yahoo.com> > No. I'm saying that the ones who deliver stateful firewalled service > to a large base of customers using global IPs instead of private IPs, > and who deliberately built it that way just in the last couple of > years did so knowing the score. > > The number of service providers delivering that kind of service is > relatively small but scope of some of those services is quite large. > And some of them are hoarding. Which of these statements better reflects your position? If an organization can use NAT44, they SHOULD. If an organization can use NAT44, they MUST. Do we need a policy proposal requiring NAT44, or requiring demonstration why NAT44 can't be used? Lee From jmaimon at chl.com Thu May 7 10:58:42 2009 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 07 May 2009 10:58:42 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> <4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com> <3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> Message-ID: <4A02F722.5070607@chl.com> William Herrin wrote: > No. I'm saying that the ones who deliver stateful firewalled service > to a large base of customers using global IPs instead of private IPs, > and who deliberately built it that way just in the last couple of > years did so knowing the score. I suppose in this definition, hoarding would be exposed by assigning a non trivial dollar value to each address. Then you would see where it was really necessary and justified and where it would be engineered out. In other words inefficiency is only relevant in a cost versus benefit scenario. > The number of service providers delivering that kind of service is > relatively small but scope of some of those services is quite large. > And some of them are hoarding. And if they want as many cracks at it as they can get, I suppose the abandonment of 2009-2 is good news for that. I seem to recall a recent /9 allocation that seemed to fit this bill exactly. A /9 at 18g costs 0.2 cents per address. > And I still won't be able to demonstrate that it > was pre-planned half a decade from now when they "discover" that they > can re-engineer with NAT Or IPv6. Then they would even be doing the right thing. > and then move the addresses to more valuable > uses within the company. I'll be able to say, "I told you so," but I > won't be able to prove that the six-figures-paid address administrator > over at my favorite vendor added two plus two several years ahead of > the deadline. If we can figure out justifiable within-the-norm behavior right now that can reap large benefits later, so can they. In fact they would be remiss to not do so. Just to be helpful to all these large companies, I will try to clarify some modes of this behavior. * ignoring dead and underutilized customer space * taking customer space request at near face value * no verification of customer space utilization * /30 on serials instead of /31, unnumbered, rfc1918 * all other underutilization and dont say they dont exist. Due to the fee structure these behaviors are not only strategically beneficial, but carry the most trivial of costs. In fact, doing otherwise is actually more complex and difficult and bears higher costs of business. A small ISP cannot afford to behave that way, and likely would have a much harder time trying to do so. To refine: There is no benefit and only loss with complying with any more than the normative behavior with regards to policy. Use addresses now so that you may have them recycled later. > Which brings me to my second major point: the hoarding is a fact of > life. There is little if anything we can do to stop it. So if we can't > stop the hoarding, how do we deal with the results? > > Step 1. The carrot. Transfer market. Incent the hoarders to sell the > addresses so that they become available for general consumption. > > Step 2. The stick. Give the ARIN board the authority to declare > categories of use of IP addresses "no longer sufficiently justified" > if after depletion they find there are too few addresses available on > the transfer market. Step 2 is only useful in the context of either reclamation or as review of entire space to justify more. Step 3. 2009-2 Abandoned. Any chance of petition or modified proposals in the works? How about adding to justification requirements explanation of how nat or ipv6 would not eliminate or reduce the size of the request? Step 4. Encourage ARIN to do something about the up to 500x disparity in fees. This could be accompanied with significant credits as reward for returns. I expect any impartial external observer would view the pie charts in this presentation as egregious. 82% of space held by 15% revenue. Is this the norm elsewhere? http://www.arin.net/participate/meetings/reports/ARIN_XXIII/pdf/wednesday/treasurers_report.pdf In fact, I would consider this a political and public relations liability, affording easy opportunity for anyone to paint ARIN as a monopolies' puppet, placing barrier to entry and increased friction of operation for the more numerous small players, a victim of regulatory capture. The only reasonable excuse has been that ARIN doesnt need the money a change in disparity would bring under almost any reasonable formula. I dont assign much credibility to the notion of lower admin overhead per request - that suggests rubber stamping and equal overhead per request. Large requests should be deserving of far greater scrutiny, they should involve much more effort than small requests. With all the proposals and discussions being floated and flaunted here that incur significant overhead, reclamation, verification, outreach, training, software advancement, lobbying, lawyers and what-not, I should think more revenue would come in handy. Of course, organizations tend to resist shrinkage, so we would have to live with the results for quite some time. The question becomes, with a significantly higher percentage of revenue attributable to large players, does ARIN face significant risk increases of regulatory capture? Or could the large players stage a coup, and would they? Joe From kkargel at polartel.com Thu May 7 11:26:53 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 7 May 2009 10:26:53 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revisedandforwarded to the Board In-Reply-To: <395570.6547.qm@web63304.mail.re1.yahoo.com> References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail><81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk><3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com><20090506185019.GA31911@ussenterprise.ufp.org><3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com><4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com><3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com><4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com><3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> <395570.6547.qm@web63304.mail.re1.yahoo.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0DD@mail> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Lee Howard > Sent: Thursday, May 07, 2009 9:37 AM > To: William Herrin; Martin Hannigan > Cc: arin ppml > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy - > Revisedandforwarded to the Board > > > > > No. I'm saying that the ones who deliver stateful firewalled service > > to a large base of customers using global IPs instead of private IPs, > > and who deliberately built it that way just in the last couple of > > years did so knowing the score. > > > > The number of service providers delivering that kind of service is > > relatively small but scope of some of those services is quite large. > > And some of them are hoarding. > > Which of these statements better reflects your position? > If an organization can use NAT44, they SHOULD. > If an organization can use NAT44, they MUST. > > Do we need a policy proposal requiring NAT44, or requiring > demonstration why NAT44 can't be used? > > Lee > We have had this discussion before and beat it soundly to death. A great many organizations (such as ISP's) cannot successfully deploy NAT to their customers. Reasonable configurations of NAT break many p2p applications that are demanded by customers. Residential customers demand that now common applications such as IM file transfers, p2p file sharing (not always bad or illegal), VOIP, remote desktop all work without needing to do custom configurations or silly router tricks. The customers demand that these things work out of the box. Also remember that what we commonly call NAT is actually PAT, and operates differently. A single PAT at a residential installation where no more than one instance of an application will be running will work with minimal configuration. The rub comes in when you try to put dozens, or even thousands of customers who could all be running the same application behind one IP address. This can be resolved by putting RFC1918 addresses behind a pool of public addresses in a 1-1 relationship, but then there is no conservative gain. Can tech savvy customers do custom configurations so that these apps work? Sure. Are they willing to do so? Nope. Will they take their business next door where it will work? You bet. NAT is a reasonable conservation solution for corporate enterprises, but not globally for end user transit providers (ISP's). ISP's are huge consumers of IPv4. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From cgrundemann at gmail.com Thu May 7 11:27:31 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 7 May 2009 09:27:31 -0600 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy ?Revisedandforwarded to the Board In-Reply-To: <25B0DF1D-B360-4452-ABD8-7196270A7139@delong.com> References: <28E139F46D45AF49A31950F88C497458F2CA73@E03MVZ2-UKDY.domain1.systemhost.net> <25B0DF1D-B360-4452-ABD8-7196270A7139@delong.com> Message-ID: <443de7ad0905070827o2b0bb1eek142b6b511767551c@mail.gmail.com> On Wed, May 6, 2009 at 15:58, Owen DeLong wrote: > > On May 6, 2009, at 1:27 AM, wrote: > >>> The sunset clause was about building trust. ?It was about >>> finding a compromise that brought everyone under the same >>> tent. ?It was a promise to the unsure that there would be a >>> top-to-bottom review. >> >> Wait a minute, that is not a sunset clause, that is a review >> date. A sunset clause says that something will end on that >> date, period. No review. No renewal. Nothing. >> > No... The difference between a sunset clause and a review > clause is the default outcome of such a review. > > If there is a review clause, it just means that a review has > to be conducted, but, absent consensus to do something as > a result of that review, nothing changes. > > If there is a sunset clause, then, absent a review and consensus, > the policy expires and we return to the previous state before the > policy was enacted. ?This default return is what was expected > by the proponents of the sunset clause and the members of the > community that accepted the proposal on the basis of it containing > a sunset clause. > > Personally, I feel that the interaction between the existing > sunset clause and the board's decision to implement on > a much faster timetable than the AC anticipated created > a difficult conundrum for the AC. There were no good options > open to the AC under the circumstance. IMHO, removing the sunset was a "no good option" but there were/are others; extending the sunset date (to 5 years instead of 3, or to 3 years after IANA depletion, etc) would have been a much better course of action since that clause was a major factor in the community consensus around 2008-6. >> If you want some kind of policy that includes a built-in reveiew >> date then please say so in plain English and don't pussyfoot >> around with redefining the meaning of words and pompous >> language. Instead of attaching an explanation of what you mean, >> hone the wording of the policy until it is clear and >> and unambiguous. >> > The desire was to force a review date with a strong prejudice > for terminating the policy unless there was consensus to continue > it. That's what a sunset clause effectively does. > >>> These events have left me smarter though. ?I now realize >>> sunset provisions don't work. >> >> Yes they do. After the sunset date, the policy or law is no >> longer operative. >> > Sunset provisions can work, but, the processing of these > two policies (2008-6 and 2009-1) has identified a number > of areas for further evaluation of the ARIN PDP which I > believe the AC and the board will be working on in the > near future and for some time. > >>> The promise of a comprehensive >>> review, on a timetable, has already been broken. >> >> That is not a sunset clause. >> > A sunset clause is ONE mechanism for ensuring such a thing > and setting a particular default outcome. There are others with > different default outcomes. > > 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. -- Chris Grundemann weblog.chrisgrundemann.com From michael.dillon at bt.com Thu May 7 11:39:15 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 May 2009 16:39:15 +0100 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <4A02F722.5070607@chl.com> Message-ID: <28E139F46D45AF49A31950F88C497458F87D21@E03MVZ2-UKDY.domain1.systemhost.net> > I suppose in this definition, hoarding would be exposed by > assigning a non trivial dollar value to each address. This is 2009. 1999 is over thataway... > Encourage ARIN to do something about the up to 500x disparity in fees. This is ARIN-PPML. ARIN-DISCUSS is over thisaway: --Michael Dillon From kkargel at polartel.com Thu May 7 12:14:52 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 7 May 2009 11:14:52 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - comments as requested In-Reply-To: <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0DF@mail> At special request I will to restate my objections to section 8.3 of both 2008-6 (as adopted) and 2009-1. With all due respect to the AC and the BoT and recognition for amazing good works I make these comments. 2008-6 should be nullified because it contradicts itself. In one sentence it states that "This policy is not intended to create a 'market'" and then it goes on to state that "resource holders served by ARIN may designate a recipient for number resources" which is pretty much the definition of creating a market. If the goal is to create a market then let's state that in the open and avoid the sophistries and strike the contradictory statement from 2008-6. If I say I am not going to do something and then go on immediately to do it I have done it, whether or not I said I wasn't going to. There was a sunset clause built in to 2008-6 by the community as a protection against untested policy. The sunset clause was IMO the vehicle through which what community consensus that did come together was reached. Without the sunset clause it is unlikely that the community would have supported 2008-6. Whether this makes any sense or not it is what the community wanted. I realize that ARIN is not a democracy. This was appropriately driven home by Mr. Vixie at the Public Policy meeting. Even with this being true, I feel the BoT should respect the wishes of the community. The sunset clause for 2008-6 should be reinstated or 2008-6 should be nullified. Problems I see with 2009-1, in addition to those stated above for 2008-6, are that there are few protections in it for the community. If the intent is truly "not to create a market" but still allow IP addresses to be exchanged for value (is that contradictory?) at a minimum there should be some sort of rate limit on exchanges. If a receiving party could only accept one or two allocations per year then at least it would make it more difficult (not impossible) to set up as a brokerage house. At a maximum 2009-1 should conform or subscribe to the current rate limits in place for allocation requests, and should increment the allocation request count. In other words, the Transfer Process should not be available as a means to sidestep policy rate limiting general allocations. I would also suggest that 2009-1 would be an appropriate place to insert an account review, making sure that RSA's are in place for all allocations of both parties, and that POC's are current and up to date for all allocations held by both parties before the transfer is effected. It should also be required that ARIN fees are current and that both parties are members in good standing. It is very reasonable to demand that transfers happen only between RSA covered ARIN members in good standing. Requiring ARIN to only service members in this regard would be a good thing. These account tests should be able to be checked with reasonable expense by ARIN. If transfers such as this incur expense over and above what exists with current transfers then ARIN should implement a "Transfer Fee" sufficient to cover additional operational costs. 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 mueller at syr.edu Thu May 7 12:50:48 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 7 May 2009 12:50:48 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> References: <49FF15ED.4070902@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> Message-ID: <75822E125BCB994F8446858C4B19F0D775EEC425@SUEX07-MBX-04.ad.syr.edu> Bill: Hoarding, no. You are misusing the term for emotional purposes. What you're proving, really, is that "needs-based" assignments don't work in this situation and you need an effective price system to make users pay the full cost of their exclusion of others. Because by definition you admit that Verizon meets the criteria established by the RIRs (i.e. it "needs" them for a quantifiable use). And yet they excluding more people than they have to because there is no additional cost for using more rather than less addresses. If Verizon had to pay more for its consumption then it would probably adopt the RFC 1918 approach. > > Ted, > > When a hurricane is coming and you buy all the flashlights at your > local store, you're hoarding. There was nothing illegitimate about > your purchase. You paid full price. You didn't steal anything. You may > even use them all. But you're still hoarding. > > Verizon is hoarding addresses. They requested and acquired millions of > addresses for use on cell phones in their wireless arm. The requests > were perfectly legitimate. Every address matches an actual physical > device and they're not doubling up. > > Nevertheless, they're hoarding addresses. The way they use IP > addresses on the cell phones, they'd have been A-OK with RFC1918 > addresses plus a few public IPs for the NAT gateways. They'll surely > discover the magic of NAT... in about 4 years when they need those IP > addresses somewhere else in the company. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Thu May 7 13:03:23 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 7 May 2009 10:03:23 -0700 Subject: [arin-ppml] WSJ aticle on numbers In-Reply-To: <200905071154.n47Bsmrm012191@cjbsys.bdb.com> References: <200905071154.n47Bsmrm012191@cjbsys.bdb.com> Message-ID: On May 7, 2009, at 4:54 AM, Cliff wrote: >> From WSJ 5/5/09 > http://online.wsj.com/article/SB124156880475489823.html > > I found this tidbit interesting. > > "Most likely, the transition to a system that can accommodate that > many > addresses will be messy but not catastrophic. The worst-case scenario: > "Organizations that have money will have addresses, while > organizations that > don't have money will fall off the 'Net," says Tony Hain, a fellow > at the IPv6 > Forum, a group backing a new, expanded Internet-addressing system." I guess whether you see that as catastrophic or not depends on whether you (or your organization) has money or not. Since Mr. Hain works for $LARGE_EQUIPMENT_VENDOR, I'm guessing his organization has plenty of addresses and money. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Thu May 7 13:00:30 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 7 May 2009 10:00:30 -0700 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <4A02B79E.8060807@arin.net> References: <4A02B79E.8060807@arin.net> Message-ID: NIT: The revised text of 5.1 (or at least specific amendments to it) should be stated as part of the Policy statement. The rationale section is not a binding part of the policy. Substance: This policy simply isn't needed. Current software for most routers supports 32 bit ASNs. There's been ample warning for providers and other organizations to update their management systems, scripts, etc. If they haven't done it by now, they are only going to do it in response to the change actually happening. Putting it off further does not really benefit the community. I am opposed to this policy as written. > ## * ## > > > Policy Proposal Name: Extend 16 bit ASN Assignments > > Proposal Originator: Marla Azinger > > Proposal Version: 1 > > Submission Date: 6 May 2009 > > Proposal type: Modify > > Policy term: Permanent > > Policy statement: This proposal is to modify section 5.1 in the NRPM > to > extend the 16-bit ASN assignment timeframe for one more year further > than the current text. The expiration requiring removal of section 5.1 > is also being removed. > > Rationale: > > Currently users of 32-bit ASN?s are encountering technical issues that > they can?t immediately overcome and therefore require 16-bit ASN?s to > operate. As a result in the ARIN region to date, 204 of the 216 32-bit > ASN?s that have been assigned have been returned and exchanged for a > 16 > bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction between > 32-bit and 16-bit ASN?s. This proposal is to change the date on the > third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s to be > assigned. If these changes are made then ARIN RIR ASN policy will read > clearly and remove any misconceptions of 16-bit cutoff post run out > and > enable technology to catch up to the ASN bit change. The expiration > date > that requires removal of section 5.1 after zero distinction occurs > is to > be removed. Instead section 5.1 will be left in place in the NRPM for > value added historical purposes. > > The revision of 5.1 would read as follows: > > 5.1 16-bit and 32-bit AS Numbers > > ? Commencing 1 January 2007, ARIN will process applications that > specifically request 32-bit only AS Numbers and assign such AS numbers > as requested by the applicant. In the absence of any specific request > for a 32-bit only AS Number, a 16-bit only AS Number will be assigned. > > ? Commencing 1 January 2009, ARIN will process applications that > specifically request 16-bit only AS Numbers and assign such AS Numbers > as requested by the applicant. In the absence of any specific request > for a 16-bit only AS Number, a 32-bit only AS Number will be assigned. > > ? Commencing 1 January 2011, ARIN will cease to make any distinction > between 16-bit only AS Numbers and 32-bit only AS Numbers, and will > operate AS number assignments from an undifferentiated 32-bit AS > Number > pool. > > Terminology > > ? "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 > > ? "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 - > 4,294,967,295 > > ? "32-bit AS Numbers" refers to AS Numbers in the range 0 - > 4,294,967,295 > > Timetable for implementation: Immediate > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Thu May 7 13:06:13 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 7 May 2009 10:06:13 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <395570.6547.qm@web63304.mail.re1.yahoo.com> References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> <4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com> <3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> <395570.6547.qm@web63304.mail.re1.yahoo.com> Message-ID: <7E4B2F50-D7E5-4639-B664-2D746C5A9FA2@delong.com> On May 7, 2009, at 7:37 AM, Lee Howard wrote: > > >> No. I'm saying that the ones who deliver stateful firewalled service >> to a large base of customers using global IPs instead of private IPs, >> and who deliberately built it that way just in the last couple of >> years did so knowing the score. >> >> The number of service providers delivering that kind of service is >> relatively small but scope of some of those services is quite large. >> And some of them are hoarding. > > Which of these statements better reflects your position? > If an organization can use NAT44, they SHOULD. > If an organization can use NAT44, they MUST. > If an organization can use NAT44, they should at least consider it. > Do we need a policy proposal requiring NAT44, or requiring > demonstration why NAT44 can't be used? > I would vehemently oppose any such policy. NAT breaks too many things and is, in my view, an abysmal hack which is a necessary evil to deal with a temporary shortage of IPv4 addresses while we work towards IPv6. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From kkargel at polartel.com Thu May 7 13:58:50 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 7 May 2009 12:58:50 -0500 Subject: [arin-ppml] general vendor comment Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0E2@mail> First I apologize to the list in advance if this is not an appropriate place for this comment. I am making a point of ending any conversation with a vendor with the question "What is your roadmap for IPv6. Future purchase and renewal decisions will be affected.". Almost invariably the answer is "Gee, you are the first person that has asked. We don't have a roadmap. I will forward this on to our development team and when there is a need I am sure we will pursue it." I would suggest to everyone that we all start requesting IPv6 information from our vendors, and submit feature requests when appropriate. Hardware and software vendors are not going to spend money to address this issue until they see a widespread business case to do so. Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From Wesley.E.George at sprint.com Thu May 7 14:20:59 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Thu, 7 May 2009 13:20:59 -0500 Subject: [arin-ppml] general vendor comment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0E2@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0E2@mail> Message-ID: I will say this... (echoing the apologies if this isn't the appropriate forum) It needs to go beyond just asking if there's a roadmap or a plan to support IPv6. While there are vendors that don't have one yet, there are plenty that do. IPv6 has been an RFP checkbox for a long time now, so lots of companies have a "story to tell" when asked. It mostly translates to "eventually..." At this point, it has to ratchet up a bit to underscore the urgency. The hope is that people are starting to get a feel for how long it will be before they have the ability/need to roll out IPv6 in their production environment. That timeline needs to be communicated to your vendors, with the expectation that if they aren't working to meet your required timeline, future contract renewals and new business would be in jeopardy. You want to keep complaining that your upstream doesn't support IPv6? This is a way to fix it. Thanks, Wes George -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel Sent: Thursday, May 07, 2009 1:59 PM To: arin ppml Subject: [arin-ppml] general vendor comment First I apologize to the list in advance if this is not an appropriate place for this comment. I am making a point of ending any conversation with a vendor with the question "What is your roadmap for IPv6. Future purchase and renewal decisions will be affected.". Almost invariably the answer is "Gee, you are the first person that has asked. We don't have a roadmap. I will forward this on to our development team and when there is a need I am sure we will pursue it." I would suggest to everyone that we all start requesting IPv6 information from our vendors, and submit feature requests when appropriate. Hardware and software vendors are not going to spend money to address this issue until they see a widespread business case to do so. Kevin This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From farmer at umn.edu Thu May 7 14:28:37 2009 From: farmer at umn.edu (David Farmer) Date: Thu, 07 May 2009 13:28:37 -0500 Subject: [arin-ppml] general vendor comment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0E2@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0E2@mail> Message-ID: <4A02E205.18307.915A328@farmer.umn.edu> IPv6 has been a desired feature (gives you a better score) in all our RFPs for about 5 years now, and the weight for IPv6 has been going up and up over the years. A good road map counted to, but actual support counted more. By the way most, but not all, network gear we have purchased over the past 5 years can support IPv6, at least by now after software upgrades delivered from those road maps. I expect all future RFPs for network gear will have IPv6 as a required feature. If you don't have it, we don't buy, no matter how good your product is otherwise. While this isn't really a ARIN policy issue, it is a really good policy for all of us to implement locally. I'll bet, ARIN probably subscribes to this policy internally for its purchases too. On 7 May 2009 Kevin Kargel wrote: > First I apologize to the list in advance if this is not an appropriate place > for this comment. > > I am making a point of ending any conversation with a vendor with the > question "What is your roadmap for IPv6. Future purchase and renewal > decisions will be affected.". Almost invariably the answer is "Gee, you are > the first person that has asked. We don't have a roadmap. I will forward > this on to our development team and when there is a need I am sure we will > pursue it." > > I would suggest to everyone that we all start requesting IPv6 information > from our vendors, and submit feature requests when appropriate. Hardware > and software vendors are not going to spend money to address this issue > until they see a widespread business case to do so. > > Kevin > > =============================================== 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 tedm at ipinc.net Thu May 7 14:34:16 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 7 May 2009 11:34:16 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy-Revisedandforwarded to the Board In-Reply-To: <28E139F46D45AF49A31950F88C497458F873CF@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458F873CF@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <7192314E2826466496EAFC30283EFCDB@tedsdesk> Take a deep breath, Michael. That was a joke. You should have been tipped off by the use of the name Wonkulating Gronkulator which is a bastardization of the name gonkulator. You can read all about gonkulators here: http://www.fortunecity.com/silverstone/renault/59/gonk/gonk.html It's very amusing. Ted > -----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: Thursday, May 07, 2009 1:35 AM > To: ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer > Policy-Revisedandforwarded to the Board > > > Wonkulating Gronkulator is a negatively-deficient IP address > > consumer. > > Right. So all organizations that have more than a /19 > allocation from ARIN are negatively deficient IP address consumers. > > What do we do now? > > Maybe we should force them to supply an IP address audit > report signed by a corporate officer? > > Wait! ARIN already did that and without any policy > discussion. Hmmm. Maybe this is not a policy matter at all. > > --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 fred at cisco.com Thu May 7 14:41:42 2009 From: fred at cisco.com (Fred Baker) Date: Thu, 7 May 2009 11:41:42 -0700 Subject: [arin-ppml] general vendor comment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0E2@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0E2@mail> Message-ID: <959AAF24-0F16-4E12-B3AC-4575A052BADA@cisco.com> On May 7, 2009, at 10:58 AM, Kevin Kargel wrote: > I am making a point of ending any conversation with a vendor with > the question "What is your roadmap for IPv6. Future purchase and > renewal decisions will be affected.". Almost invariably the answer > is "Gee, you are the first person that has asked. We don't have a > roadmap. I will forward this on to our development team and when > there is a need I am sure we will pursue it." For the record, they are almost certainly telling the next person who asks the question the same thing. But yes, do ask. From fred at cisco.com Thu May 7 14:43:41 2009 From: fred at cisco.com (Fred Baker) Date: Thu, 7 May 2009 11:43:41 -0700 Subject: [arin-ppml] general vendor comment In-Reply-To: References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0E2@mail> Message-ID: On May 7, 2009, at 11:20 AM, George, Wes E [NTK] wrote: > It needs to go beyond just asking if there's a roadmap or a plan to > support IPv6. While there are vendors that don't have one yet, there > are plenty that do. > IPv6 has been an RFP checkbox for a long time now, so lots of > companies have a "story to tell" when asked. It mostly translates to > "eventually..." > > At this point, it has to ratchet up a bit to underscore the urgency. > The hope is that people are starting to get a feel for how long it > will be before they have the ability/need to roll out IPv6 in their > production environment. That timeline needs to be communicated to > your vendors, with the expectation that if they aren't working to > meet your required timeline, future contract renewals and new > business would be in jeopardy. You want to keep complaining that > your upstream doesn't support IPv6? This is a way to fix it. Personally, I think the way to go about it is to schedule a separate meeting with them with this as the topic. Make it clear that you are meeting with lots of vendors, and ask them to come with a prepared presentation with dates. At least that seems to be what our customers do. From michael.dillon at bt.com Thu May 7 14:59:58 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 May 2009 19:59:58 +0100 Subject: [arin-ppml] general vendor comment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0E2@mail> Message-ID: <28E139F46D45AF49A31950F88C497458FFC57F@E03MVZ2-UKDY.domain1.systemhost.net> > I am making a point of ending any conversation with a vendor > with the question "What is your roadmap for IPv6. Future > purchase and renewal decisions will be affected.". >From a strategy point of view, I would suggest that you START the conversation this way. > Almost > invariably the answer is "Gee, you are the first person that > has asked. We don't have a roadmap. I will forward this on > to our development team and when there is a need I am sure we > will pursue it." And if you get this kind of answer ask for a contact with the development team where you can ask further questions. Then do follow up with those people and ask them for their roadmap. > I would suggest to everyone that we all start requesting IPv6 > information from our vendors, and submit feature requests > when appropriate. Hardware and software vendors are not > going to spend money to address this issue until they see a > widespread business case to do so. In addition to asking the technical question about IPv6 support, you might also consider asking a more business oriented question. I'm concerned whether you will still be in business in two to three years time. You have no roadmap for IPv6 but in just a couple of years, it will be an essential feature and vendors who don't have it will be history. How can you show me that your company is serious about staying in business? We still have enough time to prepare, but only if everybody including vendors, puts some effort into planning for it today. We are getting close to the point where those with no plans will not have enough time to get ready. --Michael Dillon From michael.dillon at bt.com Thu May 7 15:06:32 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 May 2009 20:06:32 +0100 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy-Revisedandforwarded to the Board In-Reply-To: <7192314E2826466496EAFC30283EFCDB@tedsdesk> Message-ID: <28E139F46D45AF49A31950F88C497458FFC585@E03MVZ2-UKDY.domain1.systemhost.net> > Take a deep breath, Michael. That was a joke. You should > have been tipped off by the use of the name Wonkulating > Gronkulator which is a bastardization of the name gonkulator. Who cares about that? The point is that every ISP above a certain size has a "hoard" of IPv4 addresses that have slipped through the cracks and could be used in a pinch. This isn't a question of finding a few evil organizations who are holding onto a big stock of addresses. It is a case of darn near everybody having a small stock of addresses that no one has estimated or taken into consideration when calculating runout dates. First IANA runs out. Then ARIN runs out. Then you scramble to find lost addresses in your systems and spreadsheets. Then you cannibalize your low-margin products to supply IPv4 to high margin products. And then IPv6 is business as usual unless you fall into Chapter 11 or get bought out cheap by a competitor who has all their IPv6 systems up to scratch. --Michael Dillon P.S. I chose to ignore the joke part because this is a policy discussion, not a free for all. From Wesley.E.George at sprint.com Thu May 7 15:30:50 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Thu, 7 May 2009 14:30:50 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> <4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com> <3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> Message-ID: First, I support the updated text as written. Big ISPs and other unnamed speculators are getting cited as an example a lot in the overall transfer market discussion, and while I can't say that they're blameless on this, I think some people are assuming that they understand way too much about how things actually work in these companies in accusing them of all of this hoarding and potential IP address speculation. I'm not buying the argument of transfer policy = opportunity for big/greedy/evil companies to exploit the system and continue being big/greedy/evil at the expense of smaller companies. There are opportunities for abuse and speculation, but that should not be a reason to prevent transfers of this type. Rather, that's why it's better for ARIN to be involved to regulate. First, as to whether or not the "big bad ISPs" are building a war chest of IP addresses, merely waiting with steepled fingers (Mr. Burns style) for IPv4 space to turn into a fungible asset that they can make money on, I think you're giving them too much credit for malevolent intelligence. Waste or inefficient use is a much better way to characterize it. They played by the same rules as everyone else, but happened to be bigger, and therefore the amount of addresses potentially wasted by percentage amounts to a larger amount of addresses wasted than an ISP 1/10th the size. Yes, not having the address space to start with or having a high cost associated would have driven different solutions. However, that doesn't change the past. I agree that a transfer market is a carrot, but I think you're missing the point about the incentive. This is not about profit, it's about breaking even on what would otherwise be expensive, but *optional* work for many organizations to reclaim IP space for the good of the Internet community. There's enough anecdotal evidence even over the last couple of days on this list to say that the appearance of a transfer market will shake loose some of the "lost" IP blocks pretty quickly, but even those require manpower to be used for audits and records keeping, and that's not free. If it's relatively cheap, especially in a non-profit, you might be able to justify throwing some interns at it in the interest of being a good internet citizen, and/or make a few bucks. Once those easy ones are exhausted, then comes the harder stuff. I say harder because this is address space that is in use, but inefficiently, and will require a non-trivial amount of work to free up. So let's use an example, picking on an auto company that happens to be in the top 15 IPv4 address holders... I'll call them "Bored." [Note, the following is speculation, I have no knowledge of the company in question's networking practices, I'm just using it as an example] Bored has no need to use 1918 space, so they've been busily allocating all of their PCs, all of their manufacturing robots, everything that speaks IP, a public address even if it doesn't talk to the internet. They have firewalls, but no NAT. They look at their current network, and realize that they could probably recover 3/4 or more of their IP space through a conversion to private addressing + NAT. However, they realize that this will cost them $5M in IT parts and labor if they do it in 6 months, and $3M if they do it in 12, and will generate no net benefit to them over doing nothing. Means it'll never happen unless someone forces them to do it, especially given the auto market at the moment. Now, if another company that's in need of space feels that Bored's /9 is worth the money it would cost them to free it up, then maybe it happens, but that assumes that this work is all done in time for "NeedIPCo" to use it long enough to recover their investment before the high demand for IPv4 goes away (aka majority has IPv6 deployed), and that no one else comes along with a similar sized block that they can free up for much cheaper which pops the bubble. The rough values established by this market will serve as a cost justification for those that have not been careful about their IP usage - in other words, there's a business case for me to spend money on more efficient numbering/records/renumbering (in whatever form) if what I have to spend internally is less than what I'd have to pay to get it on the open market. Either way, the net benefit is an increase in the efficiency of IPv4 allocations' usage. On a tangent (feel free to stop reading here if you aren't interested in Mr. Herrin's VZ=hoarder discussion) Regarding whether the existence of a firewall to protect inbound connections directly to the phone/PC constitutes hoarding because it's not done using private addresses... I don't want to get into a discussion about whether a walled garden is a good thing or not, because it has no bearing on the discussion (which is already a large tangent). Most carriers view their wireless bandwidth as a very scarce resource, and insert things to protect their infrastructure and customers from (often unsolicited) inbound traffic sucking up that resource. Would you like your data connection to stop working because a worm is trying to talk to/port-scan/infect every device on a given tower? Didn't think so. Does that automatically mean that they should be NATting behind that firewall? I won't re-cover the "NAT doesn't actually work" discussion, as Kevin has covered it. As to private addresses. Let's do some math here to go with your equation... 10/8 = 16M addresses 172.16/12 = 1M addresses 192.168/16 = 65K addresses So...using all of the available private space, I get a grand total of 17.1M addresses. VZW subscriber count = 86.6M Adding, so that we don't keep singling out VZ: ATT subscriber count = 78.2M (6M of which are iPhones) Sprint subscriber count = 49.3M At best, we're talking about nearly 3:1 oversub on addresses, at worst, 5:1. There's only so much time that reducing DHCP lease times and moving blocks around continues to work as more and more customers adopt data usage, and more always-on applications roll out. How many of you have both a wireless data card AND a phone with internet access? Assuming that 1918 isn't large enough, you're left with the prospect of having to reuse those private blocks multiple times in the same network, meaning that you now have to NAT *between* devices (yes there are applications where the devices talk directly to one another), as well as out to the internet, and $Deity help you if you have any internal devices/services that are numbered out of private space that need to talk to a handset, because you need another NAT between them. So maybe you do more bad things like using publically allocated space (say 11/8 and 12/8) as private space, and promise never ever to accidentally announce it to the internet. Is that better or worse than your definition of hoarding? And before anyone says it, yes, IPv6 *is* the correct answer to this problem, but that's being simplistic. It is not easy to retrofit existing devices for IPv6 support at that scale. Even if one of these carriers was ready to turn on IPv6 tomorrow, only a fraction of the existing devices could use it, and so while carriers are doing the right thing in enabling IPv6, their IPv4 needs are not going to suddenly and precipitously drop anytime in the next 2 years at least. I'm not saying that there are no methods to segment hosts into types and use NAT or even go IPv6-only where appropriate, but the act of enabling IPv6 will not eliminate the need for IPv4 addresses completely. Things like transfer policies cover those eventualities post-runout. Thanks, Wes George -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Thursday, May 07, 2009 1:30 AM To: Martin Hannigan Cc: arin ppml Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board On Thu, May 7, 2009 at 12:54 AM, Martin Hannigan wrote: > On Thu, May 7, 2009 at 12:41 AM, William Herrin wrote: >>>>> In a message written on Wed, May 06, 2009 at 02:14:29PM -0400, William Herrin wrote: >>>>>> Verizon is hoarding addresses. They requested and acquired millions of >> NAT = conserves IP addresses. >> Meets criteria for NAT-compatible device = could be built with NAT >> Not built with NAT + millions of devices = consumes millions of IP addresses >> Not built with NAT + could be + consumes millions = hoarding >> >> If you got "technology limitations = hoarding" from that, you ain't >> readin' it right. > > You're saying that just about every service provider on the planet is > "hoarding". Am I reading you correct? Martin, No. I'm saying that the ones who deliver stateful firewalled service to a large base of customers using global IPs instead of private IPs, and who deliberately built it that way just in the last couple of years did so knowing the score. The number of service providers delivering that kind of service is relatively small but scope of some of those services is quite large. And some of them are hoarding. On Thu, May 7, 2009 at 1:05 AM, Jon Radel wrote: > "Hoarding" generally carries implications about intent which > you're not, and probably can't, demonstrate. Jon, You're quite right. And I still won't be able to demonstrate that it was pre-planned half a decade from now when they "discover" that they can re-engineer with NAT and then move the addresses to more valuable uses within the company. I'll be able to say, "I told you so," but I won't be able to prove that the six-figures-paid address administrator over at my favorite vendor added two plus two several years ahead of the deadline. Which brings me to my second major point: the hoarding is a fact of life. There is little if anything we can do to stop it. So if we can't stop the hoarding, how do we deal with the results? Step 1. The carrot. Transfer market. Incent the hoarders to sell the addresses so that they become available for general consumption. Step 2. The stick. Give the ARIN board the authority to declare categories of use of IP addresses "no longer sufficiently justified" if after depletion they find there are too few addresses available on the transfer market. Before you explode about step 2, let me point out that ARIN has made comparable policy changes before. There was a time when multiple IP addresses for each site on a web server was a valid justification for more addresses. And then the policy changed so that it wasn't. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From mksmith at adhost.com Thu May 7 15:39:57 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 7 May 2009 12:39:57 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail><81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <20090507024147.A228E2B21FC@mx5.roble.com> <17838240D9A5544AAA5FF95F8D5203160605CC47@ad-exh01.adhost.lan> Message-ID: <17838240D9A5544AAA5FF95F8D5203160605CCBC@ad-exh01.adhost.lan> > On Wed, 6 May 2009, Michael K. Smith - Adhost wrote: > > > I would argue that the present state of things actually facilitates > > hoarding, given that only the last allocation is assessed as part of > the > > allocation of the next. Any previous allocations could be unused, > > barely used or used less. Thus, you can hoard addresses by only > > assigning from your last allocation and still be playing strictly by > the > > rules. > > > > Sadly, the concept of having to justify all of your allocations to > get > > your next one doesn't seem to get much traction. > > IIRC, the rules aren't written this way, but I had the impression ARIN > did > look at more than just your last allocation when considering a new > allocation. Honestly, I'm not sure what they do on the back end. What I've seen is that supporting documentation is requested for the previous allocation only. Perhaps they're doing more in-depth SWIP analysis outside of the request thread. Regards, Mike From jlewis at lewis.org Thu May 7 15:38:23 2009 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 7 May 2009 15:38:23 -0400 (EDT) Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <17838240D9A5544AAA5FF95F8D5203160605CC47@ad-exh01.adhost.lan> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail><81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <20090507024147.A228E2B21FC@mx5.roble.com> <17838240D9A5544AAA5FF95F8D5203160605CC47@ad-exh01.adhost.lan> Message-ID: On Wed, 6 May 2009, Michael K. Smith - Adhost wrote: > I would argue that the present state of things actually facilitates > hoarding, given that only the last allocation is assessed as part of the > allocation of the next. Any previous allocations could be unused, > barely used or used less. Thus, you can hoard addresses by only > assigning from your last allocation and still be playing strictly by the > rules. > > Sadly, the concept of having to justify all of your allocations to get > your next one doesn't seem to get much traction. IIRC, the rules aren't written this way, but I had the impression ARIN did look at more than just your last allocation when considering a new allocation. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From scottleibrand at gmail.com Thu May 7 16:19:36 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 07 May 2009 13:19:36 -0700 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: References: <4A02B79E.8060807@arin.net> Message-ID: <4A034258.3000302@gmail.com> I disagree. We are still waiting to get a release of the code train we use on the Cisco 7600 platform that supports 32-bit ASNs. It sounds like they're finally getting close, but I think a further extension probably would be helpful. We'll have a much better view of what's required by the fall meeting, when this is up for discussion. Since that will be our last chance to change policy before the current 1 Jan 2010 deadline, I definitely think this needs to be on the agenda. -Scott Owen DeLong wrote: > NIT: The revised text of 5.1 (or at least specific amendments to it) > should be > stated as part of the Policy statement. The rationale section is not a > binding > part of the policy. > > Substance: This policy simply isn't needed. Current software for most > routers supports 32 bit ASNs. There's been ample warning for providers > and other organizations to update their management systems, scripts, > etc. If they haven't done it by now, they are only going to do it in > response > to the change actually happening. Putting it off further does not really > benefit the community. > > I am opposed to this policy as written. > >> ## * ## >> >> >> Policy Proposal Name: Extend 16 bit ASN Assignments >> >> Proposal Originator: Marla Azinger >> >> Proposal Version: 1 >> >> Submission Date: 6 May 2009 >> >> Proposal type: Modify >> >> Policy term: Permanent >> >> Policy statement: This proposal is to modify section 5.1 in the NRPM to >> extend the 16-bit ASN assignment timeframe for one more year further >> than the current text. The expiration requiring removal of section 5.1 >> is also being removed. >> >> Rationale: >> >> Currently users of 32-bit ASN?s are encountering technical issues that >> they can?t immediately overcome and therefore require 16-bit ASN?s to >> operate. As a result in the ARIN region to date, 204 of the 216 32-bit >> ASN?s that have been assigned have been returned and exchanged for a 16 >> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction between >> 32-bit and 16-bit ASN?s. This proposal is to change the date on the >> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s to be >> assigned. If these changes are made then ARIN RIR ASN policy will read >> clearly and remove any misconceptions of 16-bit cutoff post run out and >> enable technology to catch up to the ASN bit change. The expiration date >> that requires removal of section 5.1 after zero distinction occurs is to >> be removed. Instead section 5.1 will be left in place in the NRPM for >> value added historical purposes. >> >> The revision of 5.1 would read as follows: >> >> 5.1 16-bit and 32-bit AS Numbers >> >> ? Commencing 1 January 2007, ARIN will process applications that >> specifically request 32-bit only AS Numbers and assign such AS numbers >> as requested by the applicant. In the absence of any specific request >> for a 32-bit only AS Number, a 16-bit only AS Number will be assigned. >> >> ? Commencing 1 January 2009, ARIN will process applications that >> specifically request 16-bit only AS Numbers and assign such AS Numbers >> as requested by the applicant. In the absence of any specific request >> for a 16-bit only AS Number, a 32-bit only AS Number will be assigned. >> >> ? Commencing 1 January 2011, ARIN will cease to make any distinction >> between 16-bit only AS Numbers and 32-bit only AS Numbers, and will >> operate AS number assignments from an undifferentiated 32-bit AS Number >> pool. >> >> Terminology >> >> ? "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 >> >> ? "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 - >> 4,294,967,295 >> >> ? "32-bit AS Numbers" refers to AS Numbers in the range 0 - >> 4,294,967,295 >> >> Timetable for implementation: Immediate >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Thu May 7 16:50:18 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 7 May 2009 13:50:18 -0700 Subject: [arin-ppml] Draft Policy 2009-1: TransferPolicy-Revisedandforwarded to the Board In-Reply-To: <28E139F46D45AF49A31950F88C497458FFC585@E03MVZ2-UKDY.domain1.systemhost.net> References: <7192314E2826466496EAFC30283EFCDB@tedsdesk> <28E139F46D45AF49A31950F88C497458FFC585@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <5E562C80B3E045798C739BF85D1CF313@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com > Sent: Thursday, May 07, 2009 12:07 PM > To: ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy 2009-1: > TransferPolicy-Revisedandforwarded to the Board > > > P.S. I chose to ignore the joke part because this is a policy > discussion, not a free for all. It stopped being a policy discussion about 2009-1 a long time ago. That's a done deal, Michael. 2009-1 is just the latest convenient peg to hang our overall argument over transfer markets on to. Before 2009-1 or even 2008-6 there were other pegs, and I am sure that this argument will continue for years after the last "virgin" block is assigned by an RIR. I submit that if someone's belief is solid that IPv6 will make IPv4 obsolete in short order, that they are not participating in this argument. Ted From aaronh at bind.com Thu May 7 16:51:51 2009 From: aaronh at bind.com (Aaron Hughes) Date: Thu, 7 May 2009 13:51:51 -0700 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <4A034258.3000302@gmail.com> References: <4A02B79E.8060807@arin.net> <4A034258.3000302@gmail.com> Message-ID: <20090507205151.GE67888@trace.bind.com> I oppose this policy as written. Looking at ARIN's historical statistics, it appears as though ARIN issues 1,600 to 1,700 ASNs each year. Looking at IANA's stats: 35840-36863 Assigned by ARIN 2005-02 39936-40959 Assigned by ARIN 2006-03-29 46080-47103 Assigned by ARIN 2008-03-27 53248-54271 Assigned by ARIN 2009-04-21 54272-55295 Assigned by ARIN 2009-04-21 Excluding April 2009, ARIN has only requested 3,072 ASNs since February 2005. Looking again at ARIN's historical statistics, they have issued 6,550 ASNs from 2005 through 2008, but have only gotten 3,072 ASNs from the IANA. Where's the difference? In San Antonio, Leslie gave a presentation that included information about returned and revoked ASNs. Slide 10 of the presentation indicates 4,357 ASNs have been returned to ARIN since January 2005. So it looks like ARIN is recycling unused ASNs, prolonging the lifespan of the free 16-bit ASN pool. Projecting this forward, at current consumption rates it should take approximately 32 months for ARIN to use up the 2,048 ASNs issued on 2009-04-21 by IANA, which puts us somewhere near December 2012. ARIN's historical statistics: https://www.arin.net/knowledge/statistics/historical.html IANA's stats: http://www.iana.org/assignments/as-numbers/ Presentation foils: https://www.arin.net/participate/meetings/reports/ARIN_XXIII/ppt/wednesday/rsd.ppt Cheers, Aaron On Thu, May 07, 2009 at 01:19:36PM -0700, Scott Leibrand wrote: > I disagree. We are still waiting to get a release of the code train we > use on the Cisco 7600 platform that supports 32-bit ASNs. It sounds > like they're finally getting close, but I think a further extension > probably would be helpful. > > We'll have a much better view of what's required by the fall meeting, > when this is up for discussion. Since that will be our last chance to > change policy before the current 1 Jan 2010 deadline, I definitely think > this needs to be on the agenda. > > -Scott > > Owen DeLong wrote: > > NIT: The revised text of 5.1 (or at least specific amendments to it) > > should be > > stated as part of the Policy statement. The rationale section is not a > > binding > > part of the policy. > > > > Substance: This policy simply isn't needed. Current software for most > > routers supports 32 bit ASNs. There's been ample warning for providers > > and other organizations to update their management systems, scripts, > > etc. If they haven't done it by now, they are only going to do it in > > response > > to the change actually happening. Putting it off further does not really > > benefit the community. > > > > I am opposed to this policy as written. > > > >> ## * ## > >> > >> > >> Policy Proposal Name: Extend 16 bit ASN Assignments > >> > >> Proposal Originator: Marla Azinger > >> > >> Proposal Version: 1 > >> > >> Submission Date: 6 May 2009 > >> > >> Proposal type: Modify > >> > >> Policy term: Permanent > >> > >> Policy statement: This proposal is to modify section 5.1 in the NRPM to > >> extend the 16-bit ASN assignment timeframe for one more year further > >> than the current text. The expiration requiring removal of section 5.1 > >> is also being removed. > >> > >> Rationale: > >> > >> Currently users of 32-bit ASN?s are encountering technical issues that > >> they can?t immediately overcome and therefore require 16-bit ASN?s to > >> operate. As a result in the ARIN region to date, 204 of the 216 32-bit > >> ASN?s that have been assigned have been returned and exchanged for a 16 > >> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction between > >> 32-bit and 16-bit ASN?s. This proposal is to change the date on the > >> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s to be > >> assigned. If these changes are made then ARIN RIR ASN policy will read > >> clearly and remove any misconceptions of 16-bit cutoff post run out and > >> enable technology to catch up to the ASN bit change. The expiration date > >> that requires removal of section 5.1 after zero distinction occurs is to > >> be removed. Instead section 5.1 will be left in place in the NRPM for > >> value added historical purposes. > >> > >> The revision of 5.1 would read as follows: > >> > >> 5.1 16-bit and 32-bit AS Numbers > >> > >> ? Commencing 1 January 2007, ARIN will process applications that > >> specifically request 32-bit only AS Numbers and assign such AS numbers > >> as requested by the applicant. In the absence of any specific request > >> for a 32-bit only AS Number, a 16-bit only AS Number will be assigned. > >> > >> ? Commencing 1 January 2009, ARIN will process applications that > >> specifically request 16-bit only AS Numbers and assign such AS Numbers > >> as requested by the applicant. In the absence of any specific request > >> for a 16-bit only AS Number, a 32-bit only AS Number will be assigned. > >> > >> ? Commencing 1 January 2011, ARIN will cease to make any distinction > >> between 16-bit only AS Numbers and 32-bit only AS Numbers, and will > >> operate AS number assignments from an undifferentiated 32-bit AS Number > >> pool. > >> > >> Terminology > >> > >> ? "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 > >> > >> ? "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 - > >> 4,294,967,295 > >> > >> ? "32-bit AS Numbers" refers to AS Numbers in the range 0 - > >> 4,294,967,295 > >> > >> Timetable for implementation: Immediate > >> > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > -- > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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. -- Aaron Hughes aaronh at bind.com (703) 244-0427 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From tedm at ipinc.net Thu May 7 16:54:56 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 7 May 2009 13:54:56 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revised andforwarded to the Board In-Reply-To: References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail><81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk><3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com><20090506185019.GA31911@ussenterprise.ufp.org><3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com><4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com><3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com><4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com><3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of George, Wes E [NTK] > Sent: Thursday, May 07, 2009 12:31 PM > To: William Herrin; Martin Hannigan > Cc: arin ppml > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy > -Revised andforwarded to the Board > > even on what would > otherwise be expensive, but *optional* work for many > organizations to reclaim IP space for the good of the > Internet community. I just want to remind you that there isn't really consensus on this list that reclamation of IPv4 is really for the good of the Internet community. > > And before anyone says it, yes, IPv6 *is* the correct answer > to this problem, but that's being simplistic. No it is not. The project that always takes the longest is the one that is never started. If you want to eat an elephant you do it a spoonfull at a time. Ted From kkargel at polartel.com Thu May 7 16:57:03 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 7 May 2009 15:57:03 -0500 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <4A034258.3000302@gmail.com> References: <4A02B79E.8060807@arin.net> <4A034258.3000302@gmail.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0EA@mail> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Scott Leibrand > Sent: Thursday, May 07, 2009 3:20 PM > To: Owen DeLong > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments > > I disagree. We are still waiting to get a release of the code train we > use on the Cisco 7600 platform that supports 32-bit ASNs. It sounds > like they're finally getting close, but I think a further extension > probably would be helpful. > > We'll have a much better view of what's required by the fall meeting, > when this is up for discussion. Since that will be our last chance to > change policy before the current 1 Jan 2010 deadline, I definitely think > this needs to be on the agenda. > > -Scott > My understanding of the current Cisco code we are using {12.2(33)} is that it will route with 32bit ASN's it gets from BGP with no issue, but that I can only enter a 16 bit ASN in to my config. I haven't quite figured out why this disparity exists. 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 Wesley.E.George at sprint.com Thu May 7 17:05:02 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Thu, 7 May 2009 16:05:02 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revised andforwarded to the Board In-Reply-To: References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail><81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk><3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com><20090506185019.GA31911@ussenterprise.ufp.org><3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com><4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com><3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com><4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com><3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> Message-ID: -----Original Message----- From: Ted Mittelstaedt [mailto:tedm at ipinc.net] Sent: Thursday, May 07, 2009 4:55 PM To: George, Wes E [NTK]; 'William Herrin'; 'Martin Hannigan' Cc: 'arin ppml' Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revised andforwarded to the Board >> And before anyone says it, yes, IPv6 *is* the correct answer >> to this problem, but that's being simplistic. >No it is not. The project that always takes the longest is the >one that is never started. If you want to eat an elephant you >do it a spoonfull at a time. >Ted I think you misinterpret my intent. I'm not saying that IPv6 isn't the answer. I would very much have liked to see my company implement 2 years ago so that this wasn't a problem. However, reality is reality. I'm saying that from a timing perspective, we don't have enough spoons, not that we refuse to pick one up. The project is underway, but will take longer than we have based on current projections. Therefore the means to keep the network functional in the intervening time will be important. Waving off any attempt to manage how the IPv4 endgame plays out by saying, "I don't care, move to IPv6" is what is being simplistic. Wes George This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From farmer at umn.edu Thu May 7 17:06:13 2009 From: farmer at umn.edu (David Farmer) Date: Thu, 07 May 2009 16:06:13 -0500 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <4A034258.3000302@gmail.com> References: <4A02B79E.8060807@arin.net>, , <4A034258.3000302@gmail.com> Message-ID: <4A0306F5.12705.9A5EB60@farmer.umn.edu> This may seem contradictory but I agree with both Scott and Owen. This should become a Draft Policy and go the the Fall PPM. Then be reviewed by the community there before the deadline and at that time I expect I would oppose the draft policy. Why, I think it is really important for the community to do a full review of this policy at the fall PPM, so the Board can in good consensus resist any pressure for another emergency PDP action. On 7 May 2009 Scott Leibrand wrote: > I disagree. We are still waiting to get a release of the code train we > use on the Cisco 7600 platform that supports 32-bit ASNs. It sounds > like they're finally getting close, but I think a further extension > probably would be helpful. > > We'll have a much better view of what's required by the fall meeting, > when this is up for discussion. Since that will be our last chance to > change policy before the current 1 Jan 2010 deadline, I definitely think > this needs to be on the agenda. > > -Scott > > Owen DeLong wrote: > > NIT: The revised text of 5.1 (or at least specific amendments to it) > > should be > > stated as part of the Policy statement. The rationale section is not a > > binding > > part of the policy. > > > > Substance: This policy simply isn't needed. Current software for most > > routers supports 32 bit ASNs. There's been ample warning for providers > > and other organizations to update their management systems, scripts, > > etc. If they haven't done it by now, they are only going to do it in > > response > > to the change actually happening. Putting it off further does not really > > benefit the community. > > > > I am opposed to this policy as written. > > > >> ## * ## > >> > >> > >> Policy Proposal Name: Extend 16 bit ASN Assignments > >> > >> Proposal Originator: Marla Azinger > >> > >> Proposal Version: 1 > >> > >> Submission Date: 6 May 2009 > >> > >> Proposal type: Modify > >> > >> Policy term: Permanent > >> > >> Policy statement: This proposal is to modify section 5.1 in the NRPM to > >> extend the 16-bit ASN assignment timeframe for one more year further > >> than the current text. The expiration requiring removal of section 5.1 > >> is also being removed. > >> > >> Rationale: > >> > >> Currently users of 32-bit ASN?s are encountering technical issues that > >> they can?t immediately overcome and therefore require 16-bit ASN?s to > >> operate. As a result in the ARIN region to date, 204 of the 216 32-bit > >> ASN?s that have been assigned have been returned and exchanged for a 16 > >> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction between > >> 32-bit and 16-bit ASN?s. This proposal is to change the date on the > >> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s to be > >> assigned. If these changes are made then ARIN RIR ASN policy will read > >> clearly and remove any misconceptions of 16-bit cutoff post run out and > >> enable technology to catch up to the ASN bit change. The expiration date > >> that requires removal of section 5.1 after zero distinction occurs is to > >> be removed. Instead section 5.1 will be left in place in the NRPM for > >> value added historical purposes. > >> > >> The revision of 5.1 would read as follows: > >> > >> 5.1 16-bit and 32-bit AS Numbers > >> > >> o Commencing 1 January 2007, ARIN will process applications that > >> specifically request 32-bit only AS Numbers and assign such AS numbers > >> as requested by the applicant. In the absence of any specific request > >> for a 32-bit only AS Number, a 16-bit only AS Number will be assigned. > >> > >> o Commencing 1 January 2009, ARIN will process applications that > >> specifically request 16-bit only AS Numbers and assign such AS Numbers > >> as requested by the applicant. In the absence of any specific request > >> for a 16-bit only AS Number, a 32-bit only AS Number will be assigned. > >> > >> o Commencing 1 January 2011, ARIN will cease to make any distinction > >> between 16-bit only AS Numbers and 32-bit only AS Numbers, and will > >> operate AS number assignments from an undifferentiated 32-bit AS Number > >> pool. > >> > >> Terminology > >> > >> o "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 > >> > >> o "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 - > >> 4,294,967,295 > >> > >> o "32-bit AS Numbers" refers to AS Numbers in the range 0 - > >> 4,294,967,295 > >> > >> Timetable for implementation: Immediate > >> > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. =============================================== David Farmer Email:farmer at umn.edu 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 mksmith at adhost.com Thu May 7 17:10:54 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 7 May 2009 14:10:54 -0700 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <4A02B79E.8060807@arin.net> References: <4A02B79E.8060807@arin.net> Message-ID: <17838240D9A5544AAA5FF95F8D5203160605CCEA@ad-exh01.adhost.lan> I support this policy as written. I think that forcing new ARIN members to use a resource that may cause them reachability issues on the Internet is a bad idea and this policy recognizes that problem and seeks to remedy it within a specific window of time. Regards, Mike > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Member Services > Sent: Thursday, May 07, 2009 3:28 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with Policy Development > Process. > > This proposal is in the first stage of the Policy Development Process. > ARIN staff will perform the Clarity and Understanding step. Staff does > not evaluate the proposal at this time, their goal is to make sure that > they understand the proposal and believe the community will as well. > Staff will report their results to the ARIN Advisory Council (AC) > within > 10 days. > > The AC will review the proposal at their next regularly scheduled > meeting (if the period before the next regularly scheduled meeting is > less than 10 days, then the period may be extended to the subsequent > regularly scheduled meeting). The AC will decide how to utilize the > proposal and announce the decision to the PPML. > > In the meantime, the AC invites everyone to comment on the proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their > deliberations. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at:https://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Extend 16 bit ASN Assignments > > Proposal Originator: Marla Azinger > > Proposal Version: 1 > > Submission Date: 6 May 2009 > > Proposal type: Modify > > Policy term: Permanent > > Policy statement: This proposal is to modify section 5.1 in the NRPM to > extend the 16-bit ASN assignment timeframe for one more year further > than the current text. The expiration requiring removal of section 5.1 > is also being removed. > > Rationale: > > Currently users of 32-bit ASN's are encountering technical issues that > they can't immediately overcome and therefore require 16-bit ASN's to > operate. As a result in the ARIN region to date, 204 of the 216 32-bit > ASN's that have been assigned have been returned and exchanged for a 16 > bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction between > 32-bit and 16-bit ASN's. This proposal is to change the date on the > third line of NRPM 5.1 and extend the timeframe for 16 bit ASN's to be > assigned. If these changes are made then ARIN RIR ASN policy will read > clearly and remove any misconceptions of 16-bit cutoff post run out and > enable technology to catch up to the ASN bit change. The expiration > date > that requires removal of section 5.1 after zero distinction occurs is > to > be removed. Instead section 5.1 will be left in place in the NRPM for > value added historical purposes. > > The revision of 5.1 would read as follows: > > 5.1 16-bit and 32-bit AS Numbers > > * Commencing 1 January 2007, ARIN will process applications that > specifically request 32-bit only AS Numbers and assign such AS numbers > as requested by the applicant. In the absence of any specific request > for a 32-bit only AS Number, a 16-bit only AS Number will be assigned. > > * Commencing 1 January 2009, ARIN will process applications that > specifically request 16-bit only AS Numbers and assign such AS Numbers > as requested by the applicant. In the absence of any specific request > for a 16-bit only AS Number, a 32-bit only AS Number will be assigned. > > * Commencing 1 January 2011, ARIN will cease to make any distinction > between 16-bit only AS Numbers and 32-bit only AS Numbers, and will > operate AS number assignments from an undifferentiated 32-bit AS Number > pool. > > Terminology > > * "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 > > * "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 - > 4,294,967,295 > > * "32-bit AS Numbers" refers to AS Numbers in the range 0 - > 4,294,967,295 > > Timetable for implementation: Immediate > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From vixie at isc.org Thu May 7 17:11:26 2009 From: vixie at isc.org (Paul Vixie) Date: Thu, 07 May 2009 21:11:26 +0000 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - comments as requested In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0DF@mail> (Kevin Kargel's message of "Thu\, 7 May 2009 11\:14\:52 -0500") References: <49FF15ED.4070902@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0DF@mail> Message-ID: kkargel at polartel.com ("Kevin Kargel") writes: >... > I realize that ARIN is not a democracy. This was appropriately driven home > by Mr. Vixie at the Public Policy meeting. ... to be clear, i said that ARIN is not a *direct* democracy. i say this when polling for support/opposition to make clear to those in the room that we're not voting on a policy proposal, but rather gathering community input for use by the ARIN Advisory Committee (who are, BTW, elected) in their deliberations. -- Paul Vixie Chair, ARIN BoT KI6YSY From bicknell at ufp.org Thu May 7 17:14:31 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 7 May 2009 17:14:31 -0400 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0EA@mail> References: <4A034258.3000302@gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0EA@mail> Message-ID: <20090507211431.GB80472@ussenterprise.ufp.org> In a message written on Thu, May 07, 2009 at 03:57:03PM -0500, Kevin Kargel wrote: > My understanding of the current Cisco code we are using {12.2(33)} is that > it will route with 32bit ASN's it gets from BGP with no issue, but that I > can only enter a 16 bit ASN in to my config. I haven't quite figured out > why this disparity exists. The answer is, "it's complicated." Google for "ASN 23456" to get some of the information. The short form is that a 32 bit ASN can pass through a 16 bit ASN only network by using ASN 23456 and some transitional magic. Lots of people who think they need /all/ of their devices to support 32 bit ASN's do not, although depending on how you use these transition mechanisms it may complicate your path to move to 32 bit clean code. -- 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: 825 bytes Desc: not available URL: From aaronh at bind.com Thu May 7 17:36:15 2009 From: aaronh at bind.com (Aaron Hughes) Date: Thu, 7 May 2009 14:36:15 -0700 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <20090507205151.GE67888@trace.bind.com> References: <4A02B79E.8060807@arin.net> <4A034258.3000302@gmail.com> <20090507205151.GE67888@trace.bind.com> Message-ID: <20090507213615.GF67888@trace.bind.com> Fellow PPML participates, Just to make sure this is 100% clear. RIPE is very likely to run out of 16bit ASNs next year as they appear to have no reclamation process (based on the 8 blocks of 1,024 ASNs recently assigned by IANA to the RIPE region). This means, operator support will happen. ARIN, on the other hand, will have 16 bit ASNs to give out until ~2013. If we simply let ARIN give out 16it until they run out and they start issuing 32bit, we will get BOTH the benefit of continuing to hand out 16bit ASNs AND push for operational support. Global proliferation of 4-byte ASNs in 2010-2011 is a foregone conclusion. More to the point, ARIN has ~3.5 years of 2-byte inventory because of their efficiency. So the proposal to stop ARIN from unifying the two pools is unnecessary. Cheers, Aaron On Thu, May 07, 2009 at 01:51:51PM -0700, Aaron Hughes wrote: > > I oppose this policy as written. > > Looking at ARIN's historical statistics, it appears as though ARIN issues 1,600 to 1,700 ASNs each year. > > Looking at IANA's stats: > 35840-36863 Assigned by ARIN 2005-02 > 39936-40959 Assigned by ARIN 2006-03-29 > 46080-47103 Assigned by ARIN 2008-03-27 > 53248-54271 Assigned by ARIN 2009-04-21 > 54272-55295 Assigned by ARIN 2009-04-21 > Excluding April 2009, ARIN has only requested 3,072 ASNs since February 2005. > > Looking again at ARIN's historical statistics, they have issued 6,550 ASNs from 2005 through 2008, but have only gotten 3,072 ASNs from the IANA. > > Where's the difference? > In San Antonio, Leslie gave a presentation that included information about returned and revoked ASNs. Slide 10 of the presentation indicates 4,357 ASNs have been returned to ARIN since January 2005. > > So it looks like ARIN is recycling unused ASNs, prolonging the lifespan of the free 16-bit ASN pool. > Projecting this forward, at current consumption rates it should take approximately 32 months for ARIN to use up the 2,048 ASNs issued on 2009-04-21 by IANA, which puts us somewhere near December 2012. > > ARIN's historical statistics: > https://www.arin.net/knowledge/statistics/historical.html > IANA's stats: > http://www.iana.org/assignments/as-numbers/ > Presentation foils: > https://www.arin.net/participate/meetings/reports/ARIN_XXIII/ppt/wednesday/rsd.ppt > > Cheers, > Aaron > > > On Thu, May 07, 2009 at 01:19:36PM -0700, Scott Leibrand wrote: > > I disagree. We are still waiting to get a release of the code train we > > use on the Cisco 7600 platform that supports 32-bit ASNs. It sounds > > like they're finally getting close, but I think a further extension > > probably would be helpful. > > > > We'll have a much better view of what's required by the fall meeting, > > when this is up for discussion. Since that will be our last chance to > > change policy before the current 1 Jan 2010 deadline, I definitely think > > this needs to be on the agenda. > > > > -Scott > > > > Owen DeLong wrote: > > > NIT: The revised text of 5.1 (or at least specific amendments to it) > > > should be > > > stated as part of the Policy statement. The rationale section is not a > > > binding > > > part of the policy. > > > > > > Substance: This policy simply isn't needed. Current software for most > > > routers supports 32 bit ASNs. There's been ample warning for providers > > > and other organizations to update their management systems, scripts, > > > etc. If they haven't done it by now, they are only going to do it in > > > response > > > to the change actually happening. Putting it off further does not really > > > benefit the community. > > > > > > I am opposed to this policy as written. > > > > > >> ## * ## > > >> > > >> > > >> Policy Proposal Name: Extend 16 bit ASN Assignments > > >> > > >> Proposal Originator: Marla Azinger > > >> > > >> Proposal Version: 1 > > >> > > >> Submission Date: 6 May 2009 > > >> > > >> Proposal type: Modify > > >> > > >> Policy term: Permanent > > >> > > >> Policy statement: This proposal is to modify section 5.1 in the NRPM to > > >> extend the 16-bit ASN assignment timeframe for one more year further > > >> than the current text. The expiration requiring removal of section 5.1 > > >> is also being removed. > > >> > > >> Rationale: > > >> > > >> Currently users of 32-bit ASN?s are encountering technical issues that > > >> they can?t immediately overcome and therefore require 16-bit ASN?s to > > >> operate. As a result in the ARIN region to date, 204 of the 216 32-bit > > >> ASN?s that have been assigned have been returned and exchanged for a 16 > > >> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction between > > >> 32-bit and 16-bit ASN?s. This proposal is to change the date on the > > >> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s to be > > >> assigned. If these changes are made then ARIN RIR ASN policy will read > > >> clearly and remove any misconceptions of 16-bit cutoff post run out and > > >> enable technology to catch up to the ASN bit change. The expiration date > > >> that requires removal of section 5.1 after zero distinction occurs is to > > >> be removed. Instead section 5.1 will be left in place in the NRPM for > > >> value added historical purposes. > > >> > > >> The revision of 5.1 would read as follows: > > >> > > >> 5.1 16-bit and 32-bit AS Numbers > > >> > > >> ? Commencing 1 January 2007, ARIN will process applications that > > >> specifically request 32-bit only AS Numbers and assign such AS numbers > > >> as requested by the applicant. In the absence of any specific request > > >> for a 32-bit only AS Number, a 16-bit only AS Number will be assigned. > > >> > > >> ? Commencing 1 January 2009, ARIN will process applications that > > >> specifically request 16-bit only AS Numbers and assign such AS Numbers > > >> as requested by the applicant. In the absence of any specific request > > >> for a 16-bit only AS Number, a 32-bit only AS Number will be assigned. > > >> > > >> ? Commencing 1 January 2011, ARIN will cease to make any distinction > > >> between 16-bit only AS Numbers and 32-bit only AS Numbers, and will > > >> operate AS number assignments from an undifferentiated 32-bit AS Number > > >> pool. > > >> > > >> Terminology > > >> > > >> ? "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 > > >> > > >> ? "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 - > > >> 4,294,967,295 > > >> > > >> ? "32-bit AS Numbers" refers to AS Numbers in the range 0 - > > >> 4,294,967,295 > > >> > > >> Timetable for implementation: Immediate > > >> > > >> > > >> _______________________________________________ > > >> PPML > > >> You are receiving this message because you are subscribed to > > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > >> Unsubscribe or manage your mailing list subscription at: > > >> http://lists.arin.net/mailman/listinfo/arin-ppml > > >> Please contact info at arin.net if you experience any issues. > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. > > -- > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing 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. > > -- > > Aaron Hughes > aaronh at bind.com > (703) 244-0427 > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 > http://www.bind.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. -- Aaron Hughes aaronh at bind.com (703) 244-0427 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From cmalayter at switchanddata.com Thu May 7 17:45:04 2009 From: cmalayter at switchanddata.com (Chris Malayter) Date: Thu, 7 May 2009 17:45:04 -0400 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <20090507213615.GF67888@trace.bind.com> References: <4A02B79E.8060807@arin.net><4A034258.3000302@gmail.com><20090507205151.GE67888@trace.bind.com> <20090507213615.GF67888@trace.bind.com> Message-ID: <6394AFBFA9558A4AACC7B19F5FD3057901AEC41D@SDCORPMAIL01.northamerica.switchanddata.org> Just to give a little background, there's a lot of information out there on this issue. It's likely that other RIR's will run out of 16bit ASN's before ARIN does if they do not create a re-allocation policy to help their 16bit pools last after their block allocations come to an end. Vendor support is VERY scattered depending on vendor and platform. Greg Henkins at F10 and I have done several presentations on this very topic at past NANOGs/GPF's/APRICOT's. The bottom line is that AS23456 is not a very scalable nor workable solution for many people. I think inevitably we are going to have to extend the 32 bit deadline to accommodate vendors integration into mainline builds for legacy equipment that is still being supported. From the data I've been looking at July of 2011 appears to be the exhaust for the first RIR. As such, I am fine with the way that this policy is written, though I think some flexibility put into the policy for the cutoff for 32bit only asns might be the best bet. -Chris -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Aaron Hughes Sent: Thursday, May 07, 2009 5:36 PM To: Scott Leibrand Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments Fellow PPML participates, Just to make sure this is 100% clear. RIPE is very likely to run out of 16bit ASNs next year as they appear to have no reclamation process (based on the 8 blocks of 1,024 ASNs recently assigned by IANA to the RIPE region). This means, operator support will happen. ARIN, on the other hand, will have 16 bit ASNs to give out until ~2013. If we simply let ARIN give out 16it until they run out and they start issuing 32bit, we will get BOTH the benefit of continuing to hand out 16bit ASNs AND push for operational support. Global proliferation of 4-byte ASNs in 2010-2011 is a foregone conclusion. More to the point, ARIN has ~3.5 years of 2-byte inventory because of their efficiency. So the proposal to stop ARIN from unifying the two pools is unnecessary. Cheers, Aaron On Thu, May 07, 2009 at 01:51:51PM -0700, Aaron Hughes wrote: > > I oppose this policy as written. > > Looking at ARIN's historical statistics, it appears as though ARIN issues 1,600 to 1,700 ASNs each year. > > Looking at IANA's stats: > 35840-36863 Assigned by ARIN 2005-02 > 39936-40959 Assigned by ARIN 2006-03-29 > 46080-47103 Assigned by ARIN 2008-03-27 > 53248-54271 Assigned by ARIN 2009-04-21 > 54272-55295 Assigned by ARIN 2009-04-21 > Excluding April 2009, ARIN has only requested 3,072 ASNs since February 2005. > > Looking again at ARIN's historical statistics, they have issued 6,550 ASNs from 2005 through 2008, but have only gotten 3,072 ASNs from the IANA. > > Where's the difference? > In San Antonio, Leslie gave a presentation that included information about returned and revoked ASNs. Slide 10 of the presentation indicates 4,357 ASNs have been returned to ARIN since January 2005. > > So it looks like ARIN is recycling unused ASNs, prolonging the lifespan of the free 16-bit ASN pool. > Projecting this forward, at current consumption rates it should take approximately 32 months for ARIN to use up the 2,048 ASNs issued on 2009-04-21 by IANA, which puts us somewhere near December 2012. > > ARIN's historical statistics: > https://www.arin.net/knowledge/statistics/historical.html > IANA's stats: > http://www.iana.org/assignments/as-numbers/ > Presentation foils: > https://www.arin.net/participate/meetings/reports/ARIN_XXIII/ppt/wednesd ay/rsd.ppt > > Cheers, > Aaron > > > On Thu, May 07, 2009 at 01:19:36PM -0700, Scott Leibrand wrote: > > I disagree. We are still waiting to get a release of the code train we > > use on the Cisco 7600 platform that supports 32-bit ASNs. It sounds > > like they're finally getting close, but I think a further extension > > probably would be helpful. > > > > We'll have a much better view of what's required by the fall meeting, > > when this is up for discussion. Since that will be our last chance to > > change policy before the current 1 Jan 2010 deadline, I definitely think > > this needs to be on the agenda. > > > > -Scott > > > > Owen DeLong wrote: > > > NIT: The revised text of 5.1 (or at least specific amendments to it) > > > should be > > > stated as part of the Policy statement. The rationale section is not a > > > binding > > > part of the policy. > > > > > > Substance: This policy simply isn't needed. Current software for most > > > routers supports 32 bit ASNs. There's been ample warning for providers > > > and other organizations to update their management systems, scripts, > > > etc. If they haven't done it by now, they are only going to do it in > > > response > > > to the change actually happening. Putting it off further does not really > > > benefit the community. > > > > > > I am opposed to this policy as written. > > > > > >> ## * ## > > >> > > >> > > >> Policy Proposal Name: Extend 16 bit ASN Assignments > > >> > > >> Proposal Originator: Marla Azinger > > >> > > >> Proposal Version: 1 > > >> > > >> Submission Date: 6 May 2009 > > >> > > >> Proposal type: Modify > > >> > > >> Policy term: Permanent > > >> > > >> Policy statement: This proposal is to modify section 5.1 in the NRPM to > > >> extend the 16-bit ASN assignment timeframe for one more year further > > >> than the current text. The expiration requiring removal of section 5.1 > > >> is also being removed. > > >> > > >> Rationale: > > >> > > >> Currently users of 32-bit ASN?s are encountering technical issues that > > >> they can?t immediately overcome and therefore require 16-bit ASN?s to > > >> operate. As a result in the ARIN region to date, 204 of the 216 32-bit > > >> ASN?s that have been assigned have been returned and exchanged for a 16 > > >> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction between > > >> 32-bit and 16-bit ASN?s. This proposal is to change the date on the > > >> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s to be > > >> assigned. If these changes are made then ARIN RIR ASN policy will read > > >> clearly and remove any misconceptions of 16-bit cutoff post run out and > > >> enable technology to catch up to the ASN bit change. The expiration date > > >> that requires removal of section 5.1 after zero distinction occurs is to > > >> be removed. Instead section 5.1 will be left in place in the NRPM for > > >> value added historical purposes. > > >> > > >> The revision of 5.1 would read as follows: > > >> > > >> 5.1 16-bit and 32-bit AS Numbers > > >> > > >> ? Commencing 1 January 2007, ARIN will process applications that > > >> specifically request 32-bit only AS Numbers and assign such AS numbers > > >> as requested by the applicant. In the absence of any specific request > > >> for a 32-bit only AS Number, a 16-bit only AS Number will be assigned. > > >> > > >> ? Commencing 1 January 2009, ARIN will process applications that > > >> specifically request 16-bit only AS Numbers and assign such AS Numbers > > >> as requested by the applicant. In the absence of any specific request > > >> for a 16-bit only AS Number, a 32-bit only AS Number will be assigned. > > >> > > >> ? Commencing 1 January 2011, ARIN will cease to make any distinction > > >> between 16-bit only AS Numbers and 32-bit only AS Numbers, and will > > >> operate AS number assignments from an undifferentiated 32-bit AS Number > > >> pool. > > >> > > >> Terminology > > >> > > >> ? "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 > > >> > > >> ? "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 - > > >> 4,294,967,295 > > >> > > >> ? "32-bit AS Numbers" refers to AS Numbers in the range 0 - > > >> 4,294,967,295 > > >> > > >> Timetable for implementation: Immediate > > >> > > >> > > >> _______________________________________________ > > >> PPML > > >> You are receiving this message because you are subscribed to > > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > >> Unsubscribe or manage your mailing list subscription at: > > >> http://lists.arin.net/mailman/listinfo/arin-ppml > > >> Please contact info at arin.net if you experience any issues. > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. > > -- > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing 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. > > -- > > Aaron Hughes > aaronh at bind.com > (703) 244-0427 > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 > http://www.bind.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. -- Aaron Hughes aaronh at bind.com (703) 244-0427 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.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 scottleibrand at gmail.com Thu May 7 17:55:47 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 7 May 2009 14:55:47 -0700 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <20090507213615.GF67888@trace.bind.com> References: <4A02B79E.8060807@arin.net> <4A034258.3000302@gmail.com> <20090507205151.GE67888@trace.bind.com> <20090507213615.GF67888@trace.bind.com> Message-ID: It's unclear to me what happens when we unify the pools. Perhaps staff could comment as to whether they plan to allocate from the bottom up or do something else at that point? -Scott On May 7, 2009, at 2:36 PM, Aaron Hughes wrote: > Fellow PPML participates, > > Just to make sure this is 100% clear. RIPE is very likely to run > out of 16bit ASNs next year as they appear to have no reclamation > process (based on the 8 blocks of 1,024 ASNs recently assigned by > IANA to the RIPE region). This means, operator support will happen. > > ARIN, on the other hand, will have 16 bit ASNs to give out until > ~2013. If we simply let ARIN give out 16it until they run out and > they start issuing 32bit, we will get BOTH the benefit of continuing > to hand out 16bit ASNs AND push for operational support. > > Global proliferation of 4-byte ASNs in 2010-2011 is a foregone > conclusion. More to the point, ARIN has ~3.5 years of 2-byte > inventory because of their efficiency. So the proposal to stop ARIN > from unifying the two pools is unnecessary. > > Cheers, > Aaron > > On Thu, May 07, 2009 at 01:51:51PM -0700, Aaron Hughes wrote: >> >> I oppose this policy as written. >> >> Looking at ARIN's historical statistics, it appears as though ARIN >> issues 1,600 to 1,700 ASNs each year. >> >> Looking at IANA's stats: >> 35840-36863 Assigned by ARIN 2005-02 >> 39936-40959 Assigned by ARIN 2006-03-29 >> 46080-47103 Assigned by ARIN 2008-03-27 >> 53248-54271 Assigned by ARIN 2009-04-21 >> 54272-55295 Assigned by ARIN 2009-04-21 >> Excluding April 2009, ARIN has only requested 3,072 ASNs since >> February 2005. >> >> Looking again at ARIN's historical statistics, they have issued >> 6,550 ASNs from 2005 through 2008, but have only gotten 3,072 ASNs >> from the IANA. >> >> Where's the difference? >> In San Antonio, Leslie gave a presentation that included >> information about returned and revoked ASNs. Slide 10 of the >> presentation indicates 4,357 ASNs have been returned to ARIN since >> January 2005. >> >> So it looks like ARIN is recycling unused ASNs, prolonging the >> lifespan of the free 16-bit ASN pool. >> Projecting this forward, at current consumption rates it should >> take approximately 32 months for ARIN to use up the 2,048 ASNs >> issued on 2009-04-21 by IANA, which puts us somewhere near December >> 2012. >> >> ARIN's historical statistics: >> https://www.arin.net/knowledge/statistics/historical.html >> IANA's stats: >> http://www.iana.org/assignments/as-numbers/ >> Presentation foils: >> https://www.arin.net/participate/meetings/reports/ARIN_XXIII/ppt/wednesday/rsd.ppt >> >> Cheers, >> Aaron >> >> >> On Thu, May 07, 2009 at 01:19:36PM -0700, Scott Leibrand wrote: >>> I disagree. We are still waiting to get a release of the code >>> train we >>> use on the Cisco 7600 platform that supports 32-bit ASNs. It sounds >>> like they're finally getting close, but I think a further extension >>> probably would be helpful. >>> >>> We'll have a much better view of what's required by the fall >>> meeting, >>> when this is up for discussion. Since that will be our last >>> chance to >>> change policy before the current 1 Jan 2010 deadline, I definitely >>> think >>> this needs to be on the agenda. >>> >>> -Scott >>> >>> Owen DeLong wrote: >>>> NIT: The revised text of 5.1 (or at least specific amendments to >>>> it) >>>> should be >>>> stated as part of the Policy statement. The rationale section is >>>> not a >>>> binding >>>> part of the policy. >>>> >>>> Substance: This policy simply isn't needed. Current software for >>>> most >>>> routers supports 32 bit ASNs. There's been ample warning for >>>> providers >>>> and other organizations to update their management systems, >>>> scripts, >>>> etc. If they haven't done it by now, they are only going to do it >>>> in >>>> response >>>> to the change actually happening. Putting it off further does >>>> not really >>>> benefit the community. >>>> >>>> I am opposed to this policy as written. >>>> >>>>> ## * ## >>>>> >>>>> >>>>> Policy Proposal Name: Extend 16 bit ASN Assignments >>>>> >>>>> Proposal Originator: Marla Azinger >>>>> >>>>> Proposal Version: 1 >>>>> >>>>> Submission Date: 6 May 2009 >>>>> >>>>> Proposal type: Modify >>>>> >>>>> Policy term: Permanent >>>>> >>>>> Policy statement: This proposal is to modify section 5.1 in the >>>>> NRPM to >>>>> extend the 16-bit ASN assignment timeframe for one more year >>>>> further >>>>> than the current text. The expiration requiring removal of >>>>> section 5.1 >>>>> is also being removed. >>>>> >>>>> Rationale: >>>>> >>>>> Currently users of 32-bit ASN?s are encountering technical >>>>> issues that >>>>> they can?t immediately overcome and therefore require 16-bit ASN? >>>>> s to >>>>> operate. As a result in the ARIN region to date, 204 of the 216 >>>>> 32-bit >>>>> ASN?s that have been assigned have been returned and exchanged >>>>> for a 16 >>>>> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction >>>>> between >>>>> 32-bit and 16-bit ASN?s. This proposal is to change the date on >>>>> the >>>>> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s >>>>> to be >>>>> assigned. If these changes are made then ARIN RIR ASN policy >>>>> will read >>>>> clearly and remove any misconceptions of 16-bit cutoff post run >>>>> out and >>>>> enable technology to catch up to the ASN bit change. The >>>>> expiration date >>>>> that requires removal of section 5.1 after zero distinction >>>>> occurs is to >>>>> be removed. Instead section 5.1 will be left in place in the >>>>> NRPM for >>>>> value added historical purposes. >>>>> >>>>> The revision of 5.1 would read as follows: >>>>> >>>>> 5.1 16-bit and 32-bit AS Numbers >>>>> >>>>> ? Commencing 1 January 2007, ARIN will process applications that >>>>> specifically request 32-bit only AS Numbers and assign such AS >>>>> numbers >>>>> as requested by the applicant. In the absence of any specific >>>>> request >>>>> for a 32-bit only AS Number, a 16-bit only AS Number will be >>>>> assigned. >>>>> >>>>> ? Commencing 1 January 2009, ARIN will process applications that >>>>> specifically request 16-bit only AS Numbers and assign such AS >>>>> Numbers >>>>> as requested by the applicant. In the absence of any specific >>>>> request >>>>> for a 16-bit only AS Number, a 32-bit only AS Number will be >>>>> assigned. >>>>> >>>>> ? Commencing 1 January 2011, ARIN will cease to make any >>>>> distinction >>>>> between 16-bit only AS Numbers and 32-bit only AS Numbers, and >>>>> will >>>>> operate AS number assignments from an undifferentiated 32-bit AS >>>>> Number >>>>> pool. >>>>> >>>>> Terminology >>>>> >>>>> ? "16-bit only AS Numbers" refers to AS numbers in the range 0 - >>>>> 65535 >>>>> >>>>> ? "32-bit only AS Numbers" refers to AS Numbers in the range >>>>> 65,536 - >>>>> 4,294,967,295 >>>>> >>>>> ? "32-bit AS Numbers" refers to AS Numbers in the range 0 - >>>>> 4,294,967,295 >>>>> >>>>> Timetable for implementation: Immediate >>>>> >>>>> >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net if you experience any issues. >>>> >>>> --- >>>> --- >>>> ------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>> -- >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing 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. >> >> -- >> >> Aaron Hughes >> aaronh at bind.com >> (703) 244-0427 >> Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 >> http://www.bind.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. > > -- > > Aaron Hughes > aaronh at bind.com > (703) 244-0427 > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 > http://www.bind.com/ From tedm at ipinc.net Thu May 7 17:59:06 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 7 May 2009 14:59:06 -0700 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0EA@mail> References: <4A02B79E.8060807@arin.net><4A034258.3000302@gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0EA@mail> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel > Sent: Thursday, May 07, 2009 1:57 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN > Assignments > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] > > On Behalf Of Scott Leibrand > > Sent: Thursday, May 07, 2009 3:20 PM > > To: Owen DeLong > > Cc: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN > > Assignments > > > > I disagree. We are still waiting to get a release of the > code train > > we use on the Cisco 7600 platform that supports 32-bit ASNs. It > > sounds like they're finally getting close, but I think a further > > extension probably would be helpful. > > > > We'll have a much better view of what's required by the > fall meeting, > > when this is up for discussion. Since that will be our > last chance to > > change policy before the current 1 Jan 2010 deadline, I definitely > > think this needs to be on the agenda. > > > > -Scott > > > My understanding of the current Cisco code we are using > {12.2(33)} ^^^^^^^^^^^^<<<------------- I take it your not going to run IPv6 on those devices, then? Ted From aaronh at bind.com Thu May 7 17:59:25 2009 From: aaronh at bind.com (Aaron Hughes) Date: Thu, 7 May 2009 14:59:25 -0700 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <6394AFBFA9558A4AACC7B19F5FD3057901AEC41D@SDCORPMAIL01.northamerica.switchanddata.org> References: <20090507213615.GF67888@trace.bind.com> <6394AFBFA9558A4AACC7B19F5FD3057901AEC41D@SDCORPMAIL01.northamerica.switchanddata.org> Message-ID: <20090507215925.GA90746@trace.bind.com> heh... One more round.. Last time I swear. :) "unifying the two pools is unnecessary" is a point that may be being overlooked. It may not be clear to everyone that ARIN issues in numerical order, and that 393,225 (the next available, lowest 4-byte ASN) is at the back of the line in a unified pool structure. Cheers, Aaron On Thu, May 07, 2009 at 05:45:04PM -0400, Chris Malayter wrote: > Just to give a little background, there's a lot of information out there > on this issue. It's likely that other RIR's will run out of 16bit ASN's > before ARIN does if they do not create a re-allocation policy to help > their 16bit pools last after their block allocations come to an end. > Vendor support is VERY scattered depending on vendor and platform. Greg > Henkins at F10 and I have done several presentations on this very topic at > past NANOGs/GPF's/APRICOT's. The bottom line is that AS23456 is not a > very scalable nor workable solution for many people. I think inevitably > we are going to have to extend the 32 bit deadline to accommodate > vendors integration into mainline builds for legacy equipment that is > still being supported. From the data I've been looking at July of 2011 > appears to be the exhaust for the first RIR. As such, I am fine with > the way that this policy is written, though I think some flexibility put > into the policy for the cutoff for 32bit only asns might be the best > bet. > > -Chris > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Aaron Hughes > Sent: Thursday, May 07, 2009 5:36 PM > To: Scott Leibrand > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments > > Fellow PPML participates, > > Just to make sure this is 100% clear. RIPE is very likely to run out of > 16bit ASNs next year as they appear to have no reclamation process > (based on the 8 blocks of 1,024 ASNs recently assigned by IANA to the > RIPE region). This means, operator support will happen. > > ARIN, on the other hand, will have 16 bit ASNs to give out until ~2013. > If we simply let ARIN give out 16it until they run out and they start > issuing 32bit, we will get BOTH the benefit of continuing to hand out > 16bit ASNs AND push for operational support. > > Global proliferation of 4-byte ASNs in 2010-2011 is a foregone > conclusion. More to the point, ARIN has ~3.5 years of 2-byte inventory > because of their efficiency. So the proposal to stop ARIN from unifying > the two pools is unnecessary. > > Cheers, > Aaron > > On Thu, May 07, 2009 at 01:51:51PM -0700, Aaron Hughes wrote: > > > > I oppose this policy as written. > > > > Looking at ARIN's historical statistics, it appears as though ARIN > issues 1,600 to 1,700 ASNs each year. > > > > Looking at IANA's stats: > > 35840-36863 Assigned by ARIN 2005-02 > > 39936-40959 Assigned by ARIN 2006-03-29 > > 46080-47103 Assigned by ARIN 2008-03-27 > > 53248-54271 Assigned by ARIN 2009-04-21 > > 54272-55295 Assigned by ARIN 2009-04-21 > > Excluding April 2009, ARIN has only requested 3,072 ASNs since > February 2005. > > > > Looking again at ARIN's historical statistics, they have issued 6,550 > ASNs from 2005 through 2008, but have only gotten 3,072 ASNs from the > IANA. > > > > Where's the difference? > > In San Antonio, Leslie gave a presentation that included information > about returned and revoked ASNs. Slide 10 of the presentation indicates > 4,357 ASNs have been returned to ARIN since January 2005. > > > > So it looks like ARIN is recycling unused ASNs, prolonging the > lifespan of the free 16-bit ASN pool. > > Projecting this forward, at current consumption rates it should take > approximately 32 months for ARIN to use up the 2,048 ASNs issued on > 2009-04-21 by IANA, which puts us somewhere near December 2012. > > > > ARIN's historical statistics: > > https://www.arin.net/knowledge/statistics/historical.html > > IANA's stats: > > http://www.iana.org/assignments/as-numbers/ > > Presentation foils: > > > https://www.arin.net/participate/meetings/reports/ARIN_XXIII/ppt/wednesd > ay/rsd.ppt > > > > Cheers, > > Aaron > > > > > > On Thu, May 07, 2009 at 01:19:36PM -0700, Scott Leibrand wrote: > > > I disagree. We are still waiting to get a release of the code train > we > > > use on the Cisco 7600 platform that supports 32-bit ASNs. It sounds > > > > like they're finally getting close, but I think a further extension > > > probably would be helpful. > > > > > > We'll have a much better view of what's required by the fall > meeting, > > > when this is up for discussion. Since that will be our last chance > to > > > change policy before the current 1 Jan 2010 deadline, I definitely > think > > > this needs to be on the agenda. > > > > > > -Scott > > > > > > Owen DeLong wrote: > > > > NIT: The revised text of 5.1 (or at least specific amendments to > it) > > > > should be > > > > stated as part of the Policy statement. The rationale section is > not a > > > > binding > > > > part of the policy. > > > > > > > > Substance: This policy simply isn't needed. Current software for > most > > > > routers supports 32 bit ASNs. There's been ample warning for > providers > > > > and other organizations to update their management systems, > scripts, > > > > etc. If they haven't done it by now, they are only going to do it > in > > > > response > > > > to the change actually happening. Putting it off further does not > really > > > > benefit the community. > > > > > > > > I am opposed to this policy as written. > > > > > > > >> ## * ## > > > >> > > > >> > > > >> Policy Proposal Name: Extend 16 bit ASN Assignments > > > >> > > > >> Proposal Originator: Marla Azinger > > > >> > > > >> Proposal Version: 1 > > > >> > > > >> Submission Date: 6 May 2009 > > > >> > > > >> Proposal type: Modify > > > >> > > > >> Policy term: Permanent > > > >> > > > >> Policy statement: This proposal is to modify section 5.1 in the > NRPM to > > > >> extend the 16-bit ASN assignment timeframe for one more year > further > > > >> than the current text. The expiration requiring removal of > section 5.1 > > > >> is also being removed. > > > >> > > > >> Rationale: > > > >> > > > >> Currently users of 32-bit ASN?s are encountering technical issues > that > > > >> they can?t immediately overcome and therefore require 16-bit > ASN?s to > > > >> operate. As a result in the ARIN region to date, 204 of the 216 > 32-bit > > > >> ASN?s that have been assigned have been returned and exchanged > for a 16 > > > >> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction > between > > > >> 32-bit and 16-bit ASN?s. This proposal is to change the date on > the > > > >> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s > to be > > > >> assigned. If these changes are made then ARIN RIR ASN policy will > read > > > >> clearly and remove any misconceptions of 16-bit cutoff post run > out and > > > >> enable technology to catch up to the ASN bit change. The > expiration date > > > >> that requires removal of section 5.1 after zero distinction > occurs is to > > > >> be removed. Instead section 5.1 will be left in place in the NRPM > for > > > >> value added historical purposes. > > > >> > > > >> The revision of 5.1 would read as follows: > > > >> > > > >> 5.1 16-bit and 32-bit AS Numbers > > > >> > > > >> ? Commencing 1 January 2007, ARIN will process applications that > > > >> specifically request 32-bit only AS Numbers and assign such AS > numbers > > > >> as requested by the applicant. In the absence of any specific > request > > > >> for a 32-bit only AS Number, a 16-bit only AS Number will be > assigned. > > > >> > > > >> ? Commencing 1 January 2009, ARIN will process applications that > > > >> specifically request 16-bit only AS Numbers and assign such AS > Numbers > > > >> as requested by the applicant. In the absence of any specific > request > > > >> for a 16-bit only AS Number, a 32-bit only AS Number will be > assigned. > > > >> > > > >> ? Commencing 1 January 2011, ARIN will cease to make any > distinction > > > >> between 16-bit only AS Numbers and 32-bit only AS Numbers, and > will > > > >> operate AS number assignments from an undifferentiated 32-bit AS > Number > > > >> pool. > > > >> > > > >> Terminology > > > >> > > > >> ? "16-bit only AS Numbers" refers to AS numbers in the range 0 - > 65535 > > > >> > > > >> ? "32-bit only AS Numbers" refers to AS Numbers in the range > 65,536 - > > > >> 4,294,967,295 > > > >> > > > >> ? "32-bit AS Numbers" refers to AS Numbers in the range 0 - > > > >> 4,294,967,295 > > > >> > > > >> Timetable for implementation: Immediate > > > >> > > > >> > > > >> _______________________________________________ > > > >> PPML > > > >> You are receiving this message because you are subscribed to > > > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > >> Unsubscribe or manage your mailing list subscription at: > > > >> http://lists.arin.net/mailman/listinfo/arin-ppml > > > >> Please contact info at arin.net if you experience any issues. > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > > > PPML > > > > You are receiving this message because you are subscribed to > > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > > Unsubscribe or manage your mailing list subscription at: > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > Please contact info at arin.net if you experience any issues. > > > -- > > > PPML > > > You are receiving this message because you are subscribed to > > > the ARIN Public Policy Mailing 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. > > > > -- > > > > Aaron Hughes > > aaronh at bind.com > > (703) 244-0427 > > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 > > http://www.bind.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. > > -- > > Aaron Hughes > aaronh at bind.com > (703) 244-0427 > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 > http://www.bind.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. -- Aaron Hughes aaronh at bind.com (703) 244-0427 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From tedm at ipinc.net Thu May 7 18:15:46 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 7 May 2009 15:15:46 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revisedandforwarded to the Board In-Reply-To: References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail><81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk><3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com><20090506185019.GA31911@ussenterprise.ufp.org><3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com><4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com><3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com><4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com><3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> Message-ID: > -----Original Message----- > From: George, Wes E [NTK] [mailto:Wesley.E.George at sprint.com] > Sent: Thursday, May 07, 2009 2:05 PM > To: Ted Mittelstaedt; 'William Herrin'; 'Martin Hannigan' > Cc: 'arin ppml' > Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy > -Revisedandforwarded to the Board > > > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Thursday, May 07, 2009 4:55 PM > To: George, Wes E [NTK]; 'William Herrin'; 'Martin Hannigan' > Cc: 'arin ppml' > Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy > -Revised andforwarded to the Board > > >> And before anyone says it, yes, IPv6 *is* the correct > answer to this > >> problem, but that's being simplistic. > > >No it is not. The project that always takes the longest is the one > >that is never started. If you want to eat an elephant you do it a > >spoonfull at a time. > > >Ted > > I think you misinterpret my intent. I'm not saying that IPv6 > isn't the answer. I would very much have liked to see my > company implement 2 years ago so that this wasn't a problem. > However, reality is reality. I'm saying that from a timing > perspective, we don't have enough spoons, not that we refuse > to pick one up. The project is underway, but will take longer > than we have based on current projections. I probably did a bit too much snipping, since you had gone on to say that retrofitting existing devices for IPv6 wasn't easy, I was more responding to that. > Therefore the > means to keep the network functional in the intervening time > will be important. But it will be, because all of those existing IPv4 devices aren't going to lose their IPv4 numbering as a result of runout. It is the NEW devices that will need to be IPv6 compliant. IPv4-runout for YOUR org will be the date that you ask ARIN for another allocation of IPv4 and they say they can't satisfy it. That may or may not be the same date of IPv4 runout for everyone else. On that day, from that point on any device you assign an IP address to SHOULD BE compliant with IPv6. Since that date is in the future, effectively what your saying is that it's really NOT the EXISTING devices that need retrofitting to IPv6. It is the devices you are going to assign IP to at some date in the future - it's future, new, devices. Unless, that is, your recycling old IPv4-only devices. And if your recycling, what about the IPv4 numbers that used to be assigned to them, where are they going? yes, this probably sounds simplistic. But, that is because it IS rather simple. We have IPv4 still available now. We know at some date in the future it will be gone. We can simply start buying palletloads of devices now, that are IPv6 compliant, and the warehouse is going to empty out of the IPv4-only wigits before we run out of IPv4. What other way would it work? Ted From kkargel at polartel.com Thu May 7 18:17:51 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 7 May 2009 17:17:51 -0500 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: References: <4A02B79E.8060807@arin.net><4A034258.3000302@gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0EA@mail> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0ED@mail> > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Thursday, May 07, 2009 4:59 PM > To: Kevin Kargel; arin-ppml at arin.net > Subject: RE: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel > > Sent: Thursday, May 07, 2009 1:57 PM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN > > Assignments > > > > > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] > > > On Behalf Of Scott Leibrand > > > Sent: Thursday, May 07, 2009 3:20 PM > > > To: Owen DeLong > > > Cc: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN > > > Assignments > > > > > > I disagree. We are still waiting to get a release of the > > code train > > > we use on the Cisco 7600 platform that supports 32-bit ASNs. It > > > sounds like they're finally getting close, but I think a further > > > extension probably would be helpful. > > > > > > We'll have a much better view of what's required by the > > fall meeting, > > > when this is up for discussion. Since that will be our > > last chance to > > > change policy before the current 1 Jan 2010 deadline, I definitely > > > think this needs to be on the agenda. > > > > > > -Scott > > > > > My understanding of the current Cisco code we are using > > {12.2(33)} > ^^^^^^^^^^^^<<<------------- > > I take it your not going to run IPv6 on those devices, then? > > Ted I am already running IPv6 and BGP IPv6 over a tunnel . IPv6 works fine with a 2 byte ASN. It lets me do ACL's and everything. The word I have is that 4 byte ASN support starts with SRE. As soon as I can get native IPv6 I will run that. 7609#sh ipv6 route IPv6 Routing Table - default - 1735 entries ... S ::/0 [1/0] via Tunnel0, directly connected B 2001::/32 [20/0] via FE80::4047:8053, Tunnel0 ... The problem comes if you want to enter a four byte ASN.. 7609(config)#router bgp ? <1-65535> Autonomous system number 7609#ping 2001:4860:c003::68 [Google] Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:4860:C003::68, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 240/244/248 ms Kevin -------------- 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 Thu May 7 19:15:52 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 7 May 2009 16:15:52 -0700 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0ED@mail> References: <4A02B79E.8060807@arin.net><4A034258.3000302@gmail.com><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0EA@mail> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0ED@mail> Message-ID: <90770EBA67EF49F88B95833F42E7A4F4@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel > Sent: Thursday, May 07, 2009 3:18 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN > Assignments > > > > -----Original Message----- > > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > > Sent: Thursday, May 07, 2009 4:59 PM > > To: Kevin Kargel; arin-ppml at arin.net > > Subject: RE: [arin-ppml] Policy Proposal: Extend 16 bit ASN > > Assignments > > > > > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel > > > Sent: Thursday, May 07, 2009 1:57 PM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN > > > Assignments > > > > > > > > > > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] > > > > On Behalf Of Scott Leibrand > > > > Sent: Thursday, May 07, 2009 3:20 PM > > > > To: Owen DeLong > > > > Cc: arin-ppml at arin.net > > > > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN > > > > Assignments > > > > > > > > I disagree. We are still waiting to get a release of the > > > code train > > > > we use on the Cisco 7600 platform that supports 32-bit > ASNs. It > > > > sounds like they're finally getting close, but I think > a further > > > > extension probably would be helpful. > > > > > > > > We'll have a much better view of what's required by the > > > fall meeting, > > > > when this is up for discussion. Since that will be our > > > last chance to > > > > change policy before the current 1 Jan 2010 deadline, I > definitely > > > > think this needs to be on the agenda. > > > > > > > > -Scott > > > > > > > My understanding of the current Cisco code we are using {12.2(33)} > > ^^^^^^^^^^^^<<<------------- > > > > I take it your not going to run IPv6 on those devices, then? > > > > Ted > > I am already running IPv6 and BGP IPv6 over a tunnel . I was just interested to see you had IPv6 running successfully on any version of 12.2 When I tried it, it reloaded my router in short order. 12.3 works, though. Ted From farmer at umn.edu Thu May 7 19:35:13 2009 From: farmer at umn.edu (David Farmer) Date: Thu, 07 May 2009 18:35:13 -0500 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <90770EBA67EF49F88B95833F42E7A4F4@tedsdesk> References: <4A02B79E.8060807@arin.net>, <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0ED@mail>, <90770EBA67EF49F88B95833F42E7A4F4@tedsdesk> Message-ID: <4A0329E1.25115.A2E5773@farmer.umn.edu> On 7 May 2009 Ted Mittelstaedt wrote: > I was just interested to see you had IPv6 running successfully > on any version of 12.2 When I tried it, it reloaded my router > in short order. 12.3 works, though. FYI, a 7600 is mostly a 6500 ethernet switch with a router paint job. Neither run 12.3 or 12.4 anything, 12.2SX for the 6500s and 12.2SR for the 7600s have many 12.3 and even a few 12.4 features back ported. FYI, 12.2SXI for the 6500s has 32 bit ASNs, and had IPv6 back to SXD or something like that like 3 or 4 years ago, even before the SR train for the 7600s forked off. =============================================== 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 tedm at ipinc.net Thu May 7 20:13:24 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 7 May 2009 17:13:24 -0700 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <4A0329E1.25115.A2E5773@farmer.umn.edu> References: <4A02B79E.8060807@arin.net>, <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0ED@mail>, <90770EBA67EF49F88B95833F42E7A4F4@tedsdesk> <4A0329E1.25115.A2E5773@farmer.umn.edu> Message-ID: <967956EDAE124AE8BAB699968DD1F206@tedsdesk> > -----Original Message----- > From: David Farmer [mailto:farmer at umn.edu] > Sent: Thursday, May 07, 2009 4:35 PM > To: Ted Mittelstaedt > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN > Assignments > > On 7 May 2009 Ted Mittelstaedt wrote: > > > I was just interested to see you had IPv6 running > successfully on any > > version of 12.2 When I tried it, it reloaded my router in short > > order. 12.3 works, though. > > FYI, a 7600 is mostly a 6500 ethernet switch with a router > paint job. I had known that but completely forgot about it. Now I remember reading about that discussion on the cisco-nsp list. It's just 7200's here, both vxr and non vxr flavors. (and lesser models, of course) Ted From rudi.daniel at gmail.com Fri May 8 00:23:44 2009 From: rudi.daniel at gmail.com (Rudi Daniel) Date: Fri, 8 May 2009 00:23:44 -0400 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments (Michael K. Smith - Adhost) Message-ID: <8aeeaff60905072123y7fe2f2b5nf725ff3112bedc28@mail.gmail.com> I oppose this policy proposal as written. There has been a steady consumption rate since 2002 or thereabouts and entire depletion suggested as middle 2011. Therefore I think this policy proposal as written would have a negative effect on the transition to 4byte ASNs. Anyway I would question that the reachability issues are so significant as to demand such a change...I also concur in general with Aaron argument also seems realistic. Rudi > > I support this policy as written. ?I think that forcing new ARIN members to use a resource that may cause them reachability issues on the > Internet is a bad idea and this policy recognizes that problem and seeks to remedy it within a specific window of time. > > Regards, > > Mike > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On >> Behalf Of Member Services >> Sent: Thursday, May 07, 2009 3:28 AM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments >> >> ARIN received the following policy proposal and is posting it to the >> Public Policy Mailing List (PPML) in accordance with Policy > Development >> Process. >> >> This proposal is in the first stage of the Policy Development Process. >> ARIN staff will perform the Clarity and Understanding step. Staff does >> not evaluate the proposal at this time, their goal is to make sure > that >> they understand the proposal and believe the community will as well. >> Staff will report their results to the ARIN Advisory Council (AC) >> within >> 10 days. >> >> The AC will review the proposal at their next regularly scheduled >> meeting (if the period before the next regularly scheduled meeting is >> less than 10 days, then the period may be extended to the subsequent >> regularly scheduled meeting). The AC will decide how to utilize the >> proposal and announce the decision to the PPML. >> >> In the meantime, the AC invites everyone to comment on the proposal on >> the PPML, particularly their support or non-support and the reasoning >> behind their opinion. Such participation contributes to a thorough >> vetting and provides important guidance to the AC in their >> deliberations. >> >> The ARIN Policy Development Process can be found at: >> https://www.arin.net/policy/pdp.html >> >> Mailing list subscription information can be found >> at:https://www.arin.net/mailing_lists/ >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Policy Proposal Name: Extend 16 bit ASN Assignments >> >> Proposal Originator: Marla Azinger >> >> Proposal Version: 1 >> >> Submission Date: 6 May 2009 >> >> Proposal type: Modify >> >> Policy term: Permanent >> >> Policy statement: This proposal is to modify section 5.1 in the NRPM > to >> extend the 16-bit ASN assignment timeframe for one more year further >> than the current text. The expiration requiring removal of section 5.1 >> is also being removed. >> >> Rationale: >> >> Currently users of 32-bit ASN's are encountering technical issues that >> they can't immediately overcome and therefore require 16-bit ASN's to >> operate. As a result in the ARIN region to date, 204 of the 216 32-bit >> ASN's that have been assigned have been returned and exchanged for a > 16 >> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction between >> 32-bit and 16-bit ASN's. This proposal is to change the date on the >> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN's to be >> assigned. If these changes are made then ARIN RIR ASN policy will read >> clearly and remove any misconceptions of 16-bit cutoff post run out > and >> enable technology to catch up to the ASN bit change. The expiration >> date >> that requires removal of section 5.1 after zero distinction occurs is >> to >> be removed. Instead section 5.1 will be left in place in the NRPM for >> value added historical purposes. >> >> The revision of 5.1 would read as follows: >> >> 5.1 16-bit and 32-bit AS Numbers >> >> * Commencing 1 January 2007, ARIN will process applications that >> specifically request 32-bit only AS Numbers and assign such AS numbers >> as requested by the applicant. In the absence of any specific request >> for a 32-bit only AS Number, a 16-bit only AS Number will be assigned. >> >> * Commencing 1 January 2009, ARIN will process applications that >> specifically request 16-bit only AS Numbers and assign such AS Numbers >> as requested by the applicant. In the absence of any specific request >> for a 16-bit only AS Number, a 32-bit only AS Number will be assigned. >> >> * Commencing 1 January 2011, ARIN will cease to make any distinction >> between 16-bit only AS Numbers and 32-bit only AS Numbers, and will >> operate AS number assignments from an undifferentiated 32-bit AS > Number >> pool. >> >> Terminology >> >> * "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 >> >> * "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 - >> 4,294,967,295 >> >> * "32-bit AS Numbers" refers to AS Numbers in the range 0 - >> 4,294,967,295 >> >> Timetable for implementation: Immediate >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > ------------------------------ > > Message: 2 > Date: Thu, 07 May 2009 21:11:26 +0000 > From: Paul Vixie > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy - > ? ? ? ?comments as ? ? requested > To: ppml at arin.net > Message-ID: > Content-Type: text/plain; charset=us-ascii > > kkargel at polartel.com ("Kevin Kargel") writes: > >>... >> I realize that ARIN is not a democracy. ?This was appropriately driven home >> by Mr. Vixie at the Public Policy meeting. ?... > > to be clear, i said that ARIN is not a *direct* democracy. ?i say this when > polling for support/opposition to make clear to those in the room that we're > not voting on a policy proposal, but rather gathering community input for use > by the ARIN Advisory Committee (who are, BTW, elected) in their deliberations. > -- > Paul Vixie > Chair, ARIN BoT > KI6YSY > > > ------------------------------ > > Message: 3 > Date: Thu, 7 May 2009 17:14:31 -0400 > From: Leo Bicknell > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN > ? ? ? ?Assignments > To: arin-ppml at arin.net > Message-ID: <20090507211431.GB80472 at ussenterprise.ufp.org> > Content-Type: text/plain; charset="us-ascii" > > In a message written on Thu, May 07, 2009 at 03:57:03PM -0500, Kevin Kargel wrote: >> My understanding of the current Cisco code we are using {12.2(33)} is that >> it will route with 32bit ASN's it gets from BGP with no issue, but that I >> can only enter a 16 bit ASN in to my config. ?I haven't quite figured out >> why this disparity exists. > > The answer is, "it's complicated." > > Google for "ASN 23456" to get some of the information. ?The short > form is that a 32 bit ASN can pass through a 16 bit ASN only network > by using ASN 23456 and some transitional magic. > > Lots of people who think they need /all/ of their devices to support > 32 bit ASN's do not, although depending on how you use these > transition mechanisms it may complicate your path to move to 32 bit > clean code. > > -- > ? ? ? 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: 825 bytes > Desc: not available > Url : http://lists.arin.net/pipermail/arin-ppml/attachments/20090507/8de16302/attachment-0001.bin > > ------------------------------ > > Message: 4 > Date: Thu, 7 May 2009 14:36:15 -0700 > From: Aaron Hughes > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN > ? ? ? ?Assignments > To: Scott Leibrand > Cc: arin-ppml at arin.net > Message-ID: <20090507213615.GF67888 at trace.bind.com> > Content-Type: text/plain; charset=us-ascii > > Fellow PPML participates, > > Just to make sure this is 100% clear. ?RIPE is very likely to run out of 16bit ASNs next year as they appear to have no reclamation process (based on the 8 blocks of 1,024 ASNs recently assigned by IANA to the RIPE region). This means, operator support will happen. > > ARIN, on the other hand, will have 16 bit ASNs to give out until ~2013. ?If we simply let ARIN give out 16it until they run out and they start issuing 32bit, we will get BOTH the benefit of continuing to hand out 16bit ASNs AND push for operational support. > > Global proliferation of 4-byte ASNs in 2010-2011 is a foregone conclusion. ?More to the point, ARIN has ~3.5 years of 2-byte inventory because of their efficiency. So the proposal to stop ARIN from unifying the two pools is unnecessary. > > Cheers, > Aaron > > On Thu, May 07, 2009 at 01:51:51PM -0700, Aaron Hughes wrote: >> >> I oppose this policy as written. >> >> Looking at ARIN's historical statistics, it appears as though ARIN issues 1,600 to 1,700 ASNs each year. >> >> Looking at IANA's stats: >> 35840-36863 Assigned by ARIN 2005-02 >> 39936-40959 Assigned by ARIN 2006-03-29 >> 46080-47103 Assigned by ARIN 2008-03-27 >> 53248-54271 Assigned by ARIN 2009-04-21 >> 54272-55295 Assigned by ARIN 2009-04-21 >> Excluding April 2009, ARIN has only requested 3,072 ASNs since February 2005. >> >> Looking again at ARIN's historical statistics, they have issued 6,550 ASNs from 2005 through 2008, but have only gotten 3,072 ASNs from the IANA. >> >> Where's the difference? >> In San Antonio, Leslie gave a presentation that included information about returned and revoked ASNs. Slide 10 of the presentation indicates 4,357 ASNs have been returned to ARIN since January 2005. >> >> So it looks like ARIN is recycling unused ASNs, prolonging the lifespan of the free 16-bit ASN pool. >> Projecting this forward, at current consumption rates it should take approximately 32 months for ARIN to use up the 2,048 ASNs issued on 2009-04-21 by IANA, which puts us somewhere near December 2012. >> >> ARIN's historical statistics: >> https://www.arin.net/knowledge/statistics/historical.html >> IANA's stats: >> http://www.iana.org/assignments/as-numbers/ >> Presentation foils: >> https://www.arin.net/participate/meetings/reports/ARIN_XXIII/ppt/wednesday/rsd.ppt >> >> Cheers, >> Aaron >> >> >> On Thu, May 07, 2009 at 01:19:36PM -0700, Scott Leibrand wrote: >> > I disagree. ?We are still waiting to get a release of the code train we >> > use on the Cisco 7600 platform that supports 32-bit ASNs. ?It sounds >> > like they're finally getting close, but I think a further extension >> > probably would be helpful. >> > >> > We'll have a much better view of what's required by the fall meeting, >> > when this is up for discussion. ?Since that will be our last chance to >> > change policy before the current 1 Jan 2010 deadline, I definitely think >> > this needs to be on the agenda. >> > >> > -Scott >> > >> > Owen DeLong wrote: >> > > NIT: ?The revised text of 5.1 (or at least specific amendments to it) >> > > should be >> > > stated as part of the Policy statement. The rationale section is not a >> > > binding >> > > part of the policy. >> > > >> > > Substance: This policy simply isn't needed. Current software for most >> > > routers supports 32 bit ASNs. There's been ample warning for providers >> > > and other organizations to update their management systems, scripts, >> > > etc. If they haven't done it by now, they are only going to do it in >> > > response >> > > to the change actually happening. ?Putting it off further does not really >> > > benefit the community. >> > > >> > > I am opposed to this policy as written. >> > > >> > >> ## * ## >> > >> >> > >> >> > >> Policy Proposal Name: Extend 16 bit ASN Assignments >> > >> >> > >> Proposal Originator: Marla Azinger >> > >> >> > >> Proposal Version: 1 >> > >> >> > >> Submission Date: 6 May 2009 >> > >> >> > >> Proposal type: Modify >> > >> >> > >> Policy term: Permanent >> > >> >> > >> Policy statement: This proposal is to modify section 5.1 in the NRPM to >> > >> extend the 16-bit ASN assignment timeframe for one more year further >> > >> than the current text. The expiration requiring removal of section 5.1 >> > >> is also being removed. >> > >> >> > >> Rationale: >> > >> >> > >> Currently users of 32-bit ASN?s are encountering technical issues that >> > >> they can?t immediately overcome and therefore require 16-bit ASN?s to >> > >> operate. As a result in the ARIN region to date, 204 of the 216 32-bit >> > >> ASN?s that have been assigned have been returned and exchanged for a 16 >> > >> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction between >> > >> 32-bit and 16-bit ASN?s. This proposal is to change the date on the >> > >> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s to be >> > >> assigned. If these changes are made then ARIN RIR ASN policy will read >> > >> clearly and remove any misconceptions of 16-bit cutoff post run out and >> > >> enable technology to catch up to the ASN bit change. The expiration date >> > >> that requires removal of section 5.1 after zero distinction occurs is to >> > >> be removed. Instead section 5.1 will be left in place in the NRPM for >> > >> value added historical purposes. >> > >> >> > >> The revision of 5.1 would read as follows: >> > >> >> > >> 5.1 16-bit and 32-bit AS Numbers >> > >> >> > >> ? Commencing 1 January 2007, ARIN will process applications that >> > >> specifically request 32-bit only AS Numbers and assign such AS numbers >> > >> as requested by the applicant. In the absence of any specific request >> > >> for a 32-bit only AS Number, a 16-bit only AS Number will be assigned. >> > >> >> > >> ? Commencing 1 January 2009, ARIN will process applications that >> > >> specifically request 16-bit only AS Numbers and assign such AS Numbers >> > >> as requested by the applicant. In the absence of any specific request >> > >> for a 16-bit only AS Number, a 32-bit only AS Number will be assigned. >> > >> >> > >> ? Commencing 1 January 2011, ARIN will cease to make any distinction >> > >> between 16-bit only AS Numbers and 32-bit only AS Numbers, and will >> > >> operate AS number assignments from an undifferentiated 32-bit AS Number >> > >> pool. >> > >> >> > >> Terminology >> > >> >> > >> ? "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 >> > >> >> > >> ? "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 - >> > >> 4,294,967,295 >> > >> >> > >> ? "32-bit AS Numbers" refers to AS Numbers in the range 0 - >> > >> 4,294,967,295 >> > >> >> > >> Timetable for implementation: Immediate >> > >> >> > >> >> > >> _______________________________________________ >> > >> PPML >> > >> You are receiving this message because you are subscribed to >> > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> > >> Unsubscribe or manage your mailing list subscription at: >> > >> http://lists.arin.net/mailman/listinfo/arin-ppml >> > >> Please contact info at arin.net if you experience any issues. >> > > >> > > ------------------------------------------------------------------------ >> > > >> > > _______________________________________________ >> > > PPML >> > > You are receiving this message because you are subscribed to >> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> > > Unsubscribe or manage your mailing list subscription at: >> > > http://lists.arin.net/mailman/listinfo/arin-ppml >> > > Please contact info at arin.net if you experience any issues. >> > -- >> > PPML >> > You are receiving this message because you are subscribed to >> > the ARIN Public Policy Mailing 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. >> >> -- >> >> Aaron Hughes >> aaronh at bind.com >> (703) 244-0427 >> Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 >> http://www.bind.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. > > -- > > Aaron Hughes > aaronh at bind.com > (703) 244-0427 > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 > http://www.bind.com/ > > > ------------------------------ > > Message: 5 > Date: Thu, 7 May 2009 17:45:04 -0400 > From: "Chris Malayter" > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN > ? ? ? ?Assignments > To: "Aaron Hughes" > Cc: arin-ppml at arin.net > Message-ID: > ? ? ? ?<6394AFBFA9558A4AACC7B19F5FD3057901AEC41D at SDCORPMAIL01.northamerica.switchanddata.org> > > Content-Type: text/plain; ? ? ? charset="us-ascii" > > Just to give a little background, there's a lot of information out there > on this issue. ?It's likely that other RIR's will run out of 16bit ASN's > before ARIN does if they do not create a re-allocation policy to help > their 16bit pools last after their block allocations come to an end. > Vendor support is VERY scattered depending on vendor and platform. ?Greg > Henkins at F10 and I have done several presentations on this very topic at > past NANOGs/GPF's/APRICOT's. ?The bottom line is that AS23456 is not a > very scalable nor workable solution for many people. ?I think inevitably > we are going to have to extend the 32 bit deadline to accommodate > vendors integration into mainline builds for legacy equipment that is > still being supported. ?From the data I've been looking at July of 2011 > appears to be the exhaust for the first RIR. ?As such, I am fine with > the way that this policy is written, though I think some flexibility put > into the policy for the cutoff for 32bit only asns might be the best > bet. > > -Chris > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Aaron Hughes > Sent: Thursday, May 07, 2009 5:36 PM > To: Scott Leibrand > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments > > Fellow PPML participates, > > Just to make sure this is 100% clear. ?RIPE is very likely to run out of > 16bit ASNs next year as they appear to have no reclamation process > (based on the 8 blocks of 1,024 ASNs recently assigned by IANA to the > RIPE region). This means, operator support will happen. > > ARIN, on the other hand, will have 16 bit ASNs to give out until ~2013. > If we simply let ARIN give out 16it until they run out and they start > issuing 32bit, we will get BOTH the benefit of continuing to hand out > 16bit ASNs AND push for operational support. > > Global proliferation of 4-byte ASNs in 2010-2011 is a foregone > conclusion. ?More to the point, ARIN has ~3.5 years of 2-byte inventory > because of their efficiency. So the proposal to stop ARIN from unifying > the two pools is unnecessary. > > Cheers, > Aaron > > On Thu, May 07, 2009 at 01:51:51PM -0700, Aaron Hughes wrote: >> >> I oppose this policy as written. >> >> Looking at ARIN's historical statistics, it appears as though ARIN > issues 1,600 to 1,700 ASNs each year. >> >> Looking at IANA's stats: >> 35840-36863 Assigned by ARIN 2005-02 >> 39936-40959 Assigned by ARIN 2006-03-29 >> 46080-47103 Assigned by ARIN 2008-03-27 >> 53248-54271 Assigned by ARIN 2009-04-21 >> 54272-55295 Assigned by ARIN 2009-04-21 >> Excluding April 2009, ARIN has only requested 3,072 ASNs since > February 2005. >> >> Looking again at ARIN's historical statistics, they have issued 6,550 > ASNs from 2005 through 2008, but have only gotten 3,072 ASNs from the > IANA. >> >> Where's the difference? >> In San Antonio, Leslie gave a presentation that included information > about returned and revoked ASNs. Slide 10 of the presentation indicates > 4,357 ASNs have been returned to ARIN since January 2005. >> >> So it looks like ARIN is recycling unused ASNs, prolonging the > lifespan of the free 16-bit ASN pool. >> Projecting this forward, at current consumption rates it should take > approximately 32 months for ARIN to use up the 2,048 ASNs issued on > 2009-04-21 by IANA, which puts us somewhere near December 2012. >> >> ARIN's historical statistics: >> https://www.arin.net/knowledge/statistics/historical.html >> IANA's stats: >> http://www.iana.org/assignments/as-numbers/ >> Presentation foils: >> > https://www.arin.net/participate/meetings/reports/ARIN_XXIII/ppt/wednesd > ay/rsd.ppt >> >> Cheers, >> Aaron >> >> >> On Thu, May 07, 2009 at 01:19:36PM -0700, Scott Leibrand wrote: >> > I disagree. ?We are still waiting to get a release of the code train > we >> > use on the Cisco 7600 platform that supports 32-bit ASNs. ?It sounds > >> > like they're finally getting close, but I think a further extension >> > probably would be helpful. >> > >> > We'll have a much better view of what's required by the fall > meeting, >> > when this is up for discussion. ?Since that will be our last chance > to >> > change policy before the current 1 Jan 2010 deadline, I definitely > think >> > this needs to be on the agenda. >> > >> > -Scott >> > >> > Owen DeLong wrote: >> > > NIT: ?The revised text of 5.1 (or at least specific amendments to > it) >> > > should be >> > > stated as part of the Policy statement. The rationale section is > not a >> > > binding >> > > part of the policy. >> > > >> > > Substance: This policy simply isn't needed. Current software for > most >> > > routers supports 32 bit ASNs. There's been ample warning for > providers >> > > and other organizations to update their management systems, > scripts, >> > > etc. If they haven't done it by now, they are only going to do it > in >> > > response >> > > to the change actually happening. ?Putting it off further does not > really >> > > benefit the community. >> > > >> > > I am opposed to this policy as written. >> > > >> > >> ## * ## >> > >> >> > >> >> > >> Policy Proposal Name: Extend 16 bit ASN Assignments >> > >> >> > >> Proposal Originator: Marla Azinger >> > >> >> > >> Proposal Version: 1 >> > >> >> > >> Submission Date: 6 May 2009 >> > >> >> > >> Proposal type: Modify >> > >> >> > >> Policy term: Permanent >> > >> >> > >> Policy statement: This proposal is to modify section 5.1 in the > NRPM to >> > >> extend the 16-bit ASN assignment timeframe for one more year > further >> > >> than the current text. The expiration requiring removal of > section 5.1 >> > >> is also being removed. >> > >> >> > >> Rationale: >> > >> >> > >> Currently users of 32-bit ASN?s are encountering technical issues > that >> > >> they can?t immediately overcome and therefore require 16-bit > ASN?s to >> > >> operate. As a result in the ARIN region to date, 204 of the 216 > 32-bit >> > >> ASN?s that have been assigned have been returned and exchanged > for a 16 >> > >> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction > between >> > >> 32-bit and 16-bit ASN?s. This proposal is to change the date on > the >> > >> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s > to be >> > >> assigned. If these changes are made then ARIN RIR ASN policy will > read >> > >> clearly and remove any misconceptions of 16-bit cutoff post run > out and >> > >> enable technology to catch up to the ASN bit change. The > expiration date >> > >> that requires removal of section 5.1 after zero distinction > occurs is to >> > >> be removed. Instead section 5.1 will be left in place in the NRPM > for >> > >> value added historical purposes. >> > >> >> > >> The revision of 5.1 would read as follows: >> > >> >> > >> 5.1 16-bit and 32-bit AS Numbers >> > >> >> > >> ? Commencing 1 January 2007, ARIN will process applications that >> > >> specifically request 32-bit only AS Numbers and assign such AS > numbers >> > >> as requested by the applicant. In the absence of any specific > request >> > >> for a 32-bit only AS Number, a 16-bit only AS Number will be > assigned. >> > >> >> > >> ? Commencing 1 January 2009, ARIN will process applications that >> > >> specifically request 16-bit only AS Numbers and assign such AS > Numbers >> > >> as requested by the applicant. In the absence of any specific > request >> > >> for a 16-bit only AS Number, a 32-bit only AS Number will be > assigned. >> > >> >> > >> ? Commencing 1 January 2011, ARIN will cease to make any > distinction >> > >> between 16-bit only AS Numbers and 32-bit only AS Numbers, and > will >> > >> operate AS number assignments from an undifferentiated 32-bit AS > Number >> > >> pool. >> > >> >> > >> Terminology >> > >> >> > >> ? "16-bit only AS Numbers" refers to AS numbers in the range 0 - > 65535 >> > >> >> > >> ? "32-bit only AS Numbers" refers to AS Numbers in the range > 65,536 - >> > >> 4,294,967,295 >> > >> >> > >> ? "32-bit AS Numbers" refers to AS Numbers in the range 0 - >> > >> 4,294,967,295 >> > >> >> > >> Timetable for implementation: Immediate >> > >> >> > >> >> > >> _______________________________________________ >> > >> PPML >> > >> You are receiving this message because you are subscribed to >> > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> > >> Unsubscribe or manage your mailing list subscription at: >> > >> http://lists.arin.net/mailman/listinfo/arin-ppml >> > >> Please contact info at arin.net if you experience any issues. >> > > >> > > > ------------------------------------------------------------------------ >> > > >> > > _______________________________________________ >> > > PPML >> > > You are receiving this message because you are subscribed to >> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> > > Unsubscribe or manage your mailing list subscription at: >> > > http://lists.arin.net/mailman/listinfo/arin-ppml >> > > Please contact info at arin.net if you experience any issues. >> > -- >> > PPML >> > You are receiving this message because you are subscribed to >> > the ARIN Public Policy Mailing 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. >> >> -- >> >> Aaron Hughes >> aaronh at bind.com >> (703) 244-0427 >> Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 >> http://www.bind.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. > > -- > > Aaron Hughes > aaronh at bind.com > (703) 244-0427 > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 > http://www.bind.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. > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 47, Issue 32 > ***************************************** > -- Rudi Daniel Independent Consultant e Business www.svgpso.org 1 784 533 7321 From craig.finseth at state.mn.us Fri May 8 06:08:42 2009 From: craig.finseth at state.mn.us (Craig Finseth) Date: Fri, 8 May 2009 05:08:42 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revisedandforwarded to the Board In-Reply-To: (tedm@ipinc.net) References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail><81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk><3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com><20090506185019.GA31911@ussenterprise.ufp.org><3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com><4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com><3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com><4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com><3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> Message-ID: <200905081008.n48A8ggY017121@inana.itg.state.mn.us> ... IPv4-runout for YOUR org will be the date that you ask ARIN for another allocation of IPv4 and they say they can't satisfy it. That may or may not be the same date of IPv4 runout for everyone else. On that day, from that point on any device you assign an IP address to SHOULD BE compliant with IPv6. ... There is another case: IPv4 runout can also be the first time one of your customers, business partners, or resources that you use can't get an IPv4 address and you need to speak IPv6 to do business (I'm assuming that you want this business). Craig From Wesley.E.George at sprint.com Fri May 8 09:57:03 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Fri, 8 May 2009 08:57:03 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revisedandforwarded to the Board In-Reply-To: References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail><81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk><3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com><20090506185019.GA31911@ussenterprise.ufp.org><3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com><4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com><3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com><4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com><3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> Message-ID: -----Original Message----- From: Ted Mittelstaedt [mailto:tedm at ipinc.net] Sent: Thursday, May 07, 2009 6:16 PM To: George, Wes E [NTK]; 'William Herrin'; 'Martin Hannigan' Cc: 'arin ppml' Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revisedandforwarded to the Board I probably did a bit too much snipping, since you had gone on to say that retrofitting existing devices for IPv6 wasn't easy, I was more responding to that. > Therefore the > means to keep the network functional in the intervening time > will be important. But it will be, because all of those existing IPv4 devices aren't going to lose their IPv4 numbering as a result of runout. It is the NEW devices that will need to be IPv6 compliant. Since that date is in the future, effectively what your saying is that it's really NOT the EXISTING devices that need retrofitting to IPv6. It is the devices you are going to assign IP to at some date in the future - it's future, new, devices. Unless, that is, your recycling old IPv4-only devices. And if your recycling, what about the IPv4 numbers that used to be assigned to them, where are they going? yes, this probably sounds simplistic. But, that is because it IS rather simple. We have IPv4 still available now. We know at some date in the future it will be gone. We can simply start buying palletloads of devices now, that are IPv6 compliant, and the warehouse is going to empty out of the IPv4-only wigits before we run out of IPv4. What other way would it work? Ted I think the fundamental (flawed) assumption you are applying is that we already have enough space for all of the existing IPv4-only devices and therefore I'm making a problem where none exists. We do not have addresses for every single device in the network simultaneously, or even a fraction of that. We are banking on the fact that some percentage of our userbase (Grandma) is going to need an IP address either infrequently or never, and that the vast majority of active devices will be periodic users (hit google for 5 minutes then shut down), meaning that we have the ability to share IPv4 addresses among a large number of devices. However, more and more wireless use is becoming data use, and it's becoming less periodic, and that means that we keep needing more IPv4 addresses despite the fact that the installed base isn't necessarily changing much. To your second point, this isn't really about widgets sitting in a warehouse. It's the phone already in your hand. I heard word that we had been asking vendors for IPv6 at least as a roadmap item in in mobile devices for probably 2 years, but not every vendor was able to necessarily deliver, and the ones that did may have had varying degrees of success in a complete and functional IPv6 implementation. The expectation is that attrition of old devices will partially solve this problem by creating an installed base that does support IPv6 and (hopefully) needs an IPv4 address less often if at all. But, depending on how often devices roll over, that may not reduce the IPv4-using population enough either. Even then, that only puts this particular application on a par with the rest of the PC-using population: IPv6 is supported, but is only useful if we ensure that either a) every possible destination our users might go to is IPv6-capable or b) that there is some sort of intermediate device that allows an IPv6-only device to reach IPv4-only websites. I fully expect that there will be classes of devices that can be IPv6-only either because they only need to reach IPv6 content or because the content that they reach can be proxied through an IPv6-to-IPv4 NAT/ALG, but not all devices will fall into that category. We're working to ensure that our internal content is v6-enabled, but the idea behind a proper IPv6 transition is that it has to be seamless to the users. If I have to explain to the average user what IPv6 is in order to explain why they can't reach a given website then I have failed. I would absolutely rather that we have IPv6 enabled and ready to roll and IPv4 runout becomes a complete non-issue. I also know the speed at which companies the size of mine move despite my best efforts, and it would be very irresponsible of me as a representative of my company to this organization to simply assume that no contingency planning should be necessary because IPv6 is the answer. Hence my support for means to ensure that IPv4 keeps being available as long as possible - IN CASE my company (or any other company) needs it for a real and justifiable reason based on the rules at the time. Wes George This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From martin.hannigan at batelnet.bs Fri May 8 11:09:30 2009 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Fri, 8 May 2009 11:09:30 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revisedandforwarded to the Board In-Reply-To: <200905081008.n48A8ggY017121@inana.itg.state.mn.us> References: <49FF15ED.4070902@arin.net> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> <4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com> <3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> <200905081008.n48A8ggY017121@inana.itg.state.mn.us> Message-ID: <4607e1d50905080809ifa0f547kf32e82ef6919c994@mail.gmail.com> On Fri, May 8, 2009 at 6:08 AM, Craig Finseth wrote: > ? ? ? ?... > ? IPv4-runout for YOUR org will be the date that you ask ARIN > ? for another allocation of IPv4 and they say they can't satisfy it. > ? That may or may not be the same date of IPv4 runout for everyone > ? else. ?On that day, from that point on any device you assign > ? an IP address to SHOULD BE compliant with IPv6. > ? ? ? ?... > > There is another case: IPv4 runout can also be the first time one of > your customers, business partners, or resources that you use can't get > an IPv4 address and you need to speak IPv6 to do business (I'm > assuming that you want this business). > The root case is likely when you can no longer justify additional resources from your RIR regardless of their inventory. That is probably the trigger condition for the above. There's probably some consideration of an IPv4 market relative to this as well. Best Regards, Martin From john.sweeting at twcable.com Fri May 8 13:37:43 2009 From: john.sweeting at twcable.com (John Sweeting) Date: Fri, 08 May 2009 13:37:43 -0400 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <20090507205151.GE67888@trace.bind.com> Message-ID: Hi Aaron, What changes would you propose to the policy? Or do you just see it as totally unnecessary? Thanks. On 5/7/09 4:51 PM, "Aaron Hughes" wrote: > > > I oppose this policy as written. > > Looking at ARIN's historical statistics, it appears as though ARIN issues > 1,600 to 1,700 ASNs each year. > > Looking at IANA's stats: > 35840-36863 Assigned by ARIN 2005-02 > 39936-40959 Assigned by ARIN 2006-03-29 > 46080-47103 Assigned by ARIN 2008-03-27 > 53248-54271 Assigned by ARIN 2009-04-21 > 54272-55295 Assigned by ARIN 2009-04-21 > Excluding April 2009, ARIN has only requested 3,072 ASNs since February 2005. > > Looking again at ARIN's historical statistics, they have issued 6,550 ASNs > from 2005 through 2008, but have only gotten 3,072 ASNs from the IANA. > > Where's the difference? > In San Antonio, Leslie gave a presentation that included information about > returned and revoked ASNs. Slide 10 of the presentation indicates 4,357 ASNs > have been returned to ARIN since January 2005. > > So it looks like ARIN is recycling unused ASNs, prolonging the lifespan of the > free 16-bit ASN pool. > Projecting this forward, at current consumption rates it should take > approximately 32 months for ARIN to use up the 2,048 ASNs issued on 2009-04-21 > by IANA, which puts us somewhere near December 2012. > > ARIN's historical statistics: > https://www.arin.net/knowledge/statistics/historical.html > IANA's stats: > http://www.iana.org/assignments/as-numbers/ > Presentation foils: > https://www.arin.net/participate/meetings/reports/ARIN_XXIII/ppt/wednesday/rsd > .ppt > > Cheers, > Aaron > > > On Thu, May 07, 2009 at 01:19:36PM -0700, Scott Leibrand wrote: >> > I disagree. We are still waiting to get a release of the code train we >> > use on the Cisco 7600 platform that supports 32-bit ASNs. It sounds >> > like they're finally getting close, but I think a further extension >> > probably would be helpful. >> > >> > We'll have a much better view of what's required by the fall meeting, >> > when this is up for discussion. Since that will be our last chance to >> > change policy before the current 1 Jan 2010 deadline, I definitely think >> > this needs to be on the agenda. >> > >> > -Scott >> > >> > Owen DeLong wrote: >>> > > NIT: The revised text of 5.1 (or at least specific amendments to it) >>> > > should be >>> > > stated as part of the Policy statement. The rationale section is not a >>> > > binding >>> > > part of the policy. >>> > > >>> > > Substance: This policy simply isn't needed. Current software for most >>> > > routers supports 32 bit ASNs. There's been ample warning for providers >>> > > and other organizations to update their management systems, scripts, >>> > > etc. If they haven't done it by now, they are only going to do it in >>> > > response >>> > > to the change actually happening. Putting it off further does not >>> really >>> > > benefit the community. >>> > > >>> > > I am opposed to this policy as written. >>> > > >>>> > >> ## * ## >>>> > >> >>>> > >> >>>> > >> Policy Proposal Name: Extend 16 bit ASN Assignments >>>> > >> >>>> > >> Proposal Originator: Marla Azinger >>>> > >> >>>> > >> Proposal Version: 1 >>>> > >> >>>> > >> Submission Date: 6 May 2009 >>>> > >> >>>> > >> Proposal type: Modify >>>> > >> >>>> > >> Policy term: Permanent >>>> > >> >>>> > >> Policy statement: This proposal is to modify section 5.1 in the NRPM to >>>> > >> extend the 16-bit ASN assignment timeframe for one more year further >>>> > >> than the current text. The expiration requiring removal of section 5.1 >>>> > >> is also being removed. >>>> > >> >>>> > >> Rationale: >>>> > >> >>>> > >> Currently users of 32-bit ASN?s are encountering technical issues that >>>> > >> they can?t immediately overcome and therefore require 16-bit ASN?s to >>>> > >> operate. As a result in the ARIN region to date, 204 of the 216 32-bit >>>> > >> ASN?s that have been assigned have been returned and exchanged for a 16 >>>> > >> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction between >>>> > >> 32-bit and 16-bit ASN?s. This proposal is to change the date on the >>>> > >> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s to be >>>> > >> assigned. If these changes are made then ARIN RIR ASN policy will read >>>> > >> clearly and remove any misconceptions of 16-bit cutoff post run out and >>>> > >> enable technology to catch up to the ASN bit change. The expiration date >>>> > >> that requires removal of section 5.1 after zero distinction occurs is to >>>> > >> be removed. Instead section 5.1 will be left in place in the NRPM for >>>> > >> value added historical purposes. >>>> > >> >>>> > >> The revision of 5.1 would read as follows: >>>> > >> >>>> > >> 5.1 16-bit and 32-bit AS Numbers >>>> > >> >>>> > >> ? Commencing 1 January 2007, ARIN will process applications that >>>> > >> specifically request 32-bit only AS Numbers and assign such AS numbers >>>> > >> as requested by the applicant. In the absence of any specific request >>>> > >> for a 32-bit only AS Number, a 16-bit only AS Number will be assigned. >>>> > >> >>>> > >> ? Commencing 1 January 2009, ARIN will process applications that >>>> > >> specifically request 16-bit only AS Numbers and assign such AS Numbers >>>> > >> as requested by the applicant. In the absence of any specific request >>>> > >> for a 16-bit only AS Number, a 32-bit only AS Number will be assigned. >>>> > >> >>>> > >> ? Commencing 1 January 2011, ARIN will cease to make any distinction >>>> > >> between 16-bit only AS Numbers and 32-bit only AS Numbers, and will >>>> > >> operate AS number assignments from an undifferentiated 32-bit AS >>>> Number >>>> > >> pool. >>>> > >> >>>> > >> Terminology >>>> > >> >>>> > >> ? "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 >>>> > >> >>>> > >> ? "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 - >>>> > >> 4,294,967,295 >>>> > >> >>>> > >> ? "32-bit AS Numbers" refers to AS Numbers in the range 0 - >>>> > >> 4,294,967,295 >>>> > >> >>>> > >> Timetable for implementation: Immediate >>>> > >> >>>> > >> >>>> > >> _______________________________________________ >>>> > >> PPML >>>> > >> You are receiving this message because you are subscribed to >>>> > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> > >> Unsubscribe or manage your mailing list subscription at: >>>> > >> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> > >> Please contact info at arin.net if you experience any issues. >>> > > >>> > > ------------------------------------------------------------------------ >>> > > >>> > > _______________________________________________ >>> > > PPML >>> > > You are receiving this message because you are subscribed to >>> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> > > Unsubscribe or manage your mailing list subscription at: >>> > > http://lists.arin.net/mailman/listinfo/arin-ppml >>> > > Please contact info at arin.net if you experience any issues. >> > -- >> > PPML >> > You are receiving this message because you are subscribed to >> > the ARIN Public Policy Mailing 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. > > -- > > Aaron Hughes > aaronh at bind.com > (703) 244-0427 > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 > http://www.bind.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. > P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at sprunk.org Fri May 8 14:10:34 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 08 May 2009 13:10:34 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C2@mail> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C2@mail> Message-ID: <4A04759A.1050503@sprunk.org> Kevin Kargel wrote: > I believe the proof of what I am talking about is all of the unused IPv4 space that is not being returned so that it can be held as a speculative > commodity. Inaction in itself is a proof. > You are assigning a motive without proof. Yes, there is a lot of space out there that could be returned and hasn't been. I believe that in the vast majority of cases it is abandoned, forgotten, or is being used inefficiently and there is insufficient motivation to renumber. I have seen all of these cases in the wild many, many times; I have _never_ been told "we won't return that space because we're hoping to sell it one day." My motivation for supporting liberalized transfers is to apply a financial incentive to correct all of the problems above that I _have_ seen. If companies hear that they can get money for giving up space, many (but not all) of them are going to do an inventory and find out what they have but don't actually need so that they can cash in. Would I prefer altruistic motivation? Certainly. We've been trying that for a couple of decades now, and it has resulted in a few returns, but nowhere near as many as I'd hoped -- or as many as the community will need in a few years. It's time to quit pretending that altruism is sufficient. 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 tedm at ipinc.net Fri May 8 14:11:16 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 8 May 2009 11:11:16 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revisedandforwarded to the Board In-Reply-To: References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail><81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk><3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com><20090506185019.GA31911@ussenterprise.ufp.org><3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com><4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com><3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com><4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com><3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> Message-ID: <7804282E4E414FBC96FC25D5E4DCB6E8@tedsdesk> > -----Original Message----- > From: George, Wes E [NTK] [mailto:Wesley.E.George at sprint.com] > Sent: Friday, May 08, 2009 6:57 AM > To: Ted Mittelstaedt; 'William Herrin'; 'Martin Hannigan' > Cc: 'arin ppml' > Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy > -Revisedandforwarded to the Board > > > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Thursday, May 07, 2009 6:16 PM > To: George, Wes E [NTK]; 'William Herrin'; 'Martin Hannigan' > Cc: 'arin ppml' > Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy > -Revisedandforwarded to the Board > > I probably did a bit too much snipping, since you had gone on > to say that retrofitting existing devices for IPv6 wasn't > easy, I was more responding to that. > > > Therefore the > > means to keep the network functional in the intervening > time will be > > important. > > But it will be, because all of those existing IPv4 devices > aren't going to lose their IPv4 numbering as a result of > runout. It is the NEW devices that will need to be IPv6 compliant. > > > Since that date is in the future, effectively what your > saying is that it's really NOT the EXISTING devices that need > retrofitting to IPv6. It is the devices you are going to > assign IP to at some date in the future - it's future, new, > devices. Unless, that is, your recycling old IPv4-only > devices. And if your recycling, what about the IPv4 numbers > that used to be assigned to them, where are they going? > > yes, this probably sounds simplistic. But, that is because > it IS rather simple. We have IPv4 still available now. We > know at some date in the future it will be gone. We can > simply start buying palletloads of devices now, that are IPv6 > compliant, and the warehouse is going to empty out of the > IPv4-only wigits before we run out of IPv4. > > What other way would it work? > > Ted > > I think the fundamental (flawed) assumption you are applying > is that we already have enough space for all of the existing > IPv4-only devices and therefore I'm making a problem where > none exists. We do not have addresses for every single device > in the network simultaneously, or even a fraction of that. We > are banking on the fact that some percentage of our userbase > (Grandma) is going to need an IP address either infrequently > or never, and that the vast majority of active devices will > be periodic users (hit google for 5 minutes then shut down), > meaning that we have the ability to share IPv4 addresses > among a large number of devices. However, more and more > wireless use is becoming data use, and it's becoming less > periodic, and that means that we keep needing more IPv4 > addresses despite the fact that the installed base isn't > necessarily changing much. > > To your second point, this isn't really about widgets sitting > in a warehouse. It's the phone already in your hand. I heard > word that we had been asking vendors for IPv6 at least as a > roadmap item in in mobile devices for probably 2 years, but > not every vendor was able to necessarily deliver, and the > ones that did may have had varying degrees of success in a > complete and functional IPv6 implementation. My Sprint Motorola Q that's a few years old is IPv6 > The expectation > is that attrition of old devices will partially solve this > problem by creating an installed base that does support IPv6 > and (hopefully) needs an IPv4 address less often if at all. > But, depending on how often devices roll over, that may not > reduce the IPv4-using population enough either. Even then, > that only puts this particular application on a par with the > rest of the PC-using population: IPv6 is supported, but is > only useful if we ensure that either a) every possible > destination our users might go to is IPv6-capable or b) that > there is some sort of intermediate device that allows an > IPv6-only device to reach IPv4-only websites. I believe that is how Sprint does it with my phone. > I fully expect that there will be classes of devices that can > be IPv6-only either because they only need to reach IPv6 > content or because the content that they reach can be proxied > through an IPv6-to-IPv4 NAT/ALG, but not all devices will > fall into that category. On my phone I have a web browser, e-mail client, SSH client, FTP client, RSS reader. What else do I need? My phone does NOT have an IPv4 number on it, this I know from digging into it. > We're working to ensure that our internal content is > v6-enabled, but the idea behind a proper IPv6 transition is > that it has to be seamless to the users. If I have to explain > to the average user what IPv6 is in order to explain why they > can't reach a given website then I have failed. > I would absolutely rather that we have IPv6 enabled and ready > to roll and IPv4 runout becomes a complete non-issue. I also > know the speed at which companies the size of mine move > despite my best efforts, and it would be very irresponsible > of me as a representative of my company to this organization > to simply assume that no contingency planning should be > necessary because IPv6 is the answer. Hence my support for > means to ensure that IPv4 keeps being available as long as > possible - IN CASE my company (or any other company) needs it > for a real and justifiable reason based on the rules at the time. > I'm not arguing that there won't be need for IPv4 in the future. I am just cautioning against making it seem like the transition is more difficult than it is. Ted From aaronh at bind.com Fri May 8 14:16:10 2009 From: aaronh at bind.com (Aaron Hughes) Date: Fri, 8 May 2009 11:16:10 -0700 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: References: <20090507205151.GE67888@trace.bind.com> Message-ID: <20090508181610.GF99433@trace.bind.com> On Fri, May 08, 2009 at 01:37:43PM -0400, John Sweeting wrote: > Hi Aaron, > > What changes would you propose to the policy? Or do you just see it as > totally unnecessary? Thanks. John, It is entirely unnecessary. The only change that should be made IMHO is to revert to default 16bit assignments until Jan 1 2010 or 11 to prevent the 90% return of 32bit ASNs. That should be enough time to get better vendor support. Cheers, Aaron > > > On 5/7/09 4:51 PM, "Aaron Hughes" wrote: > > > > > > > I oppose this policy as written. > > > > Looking at ARIN's historical statistics, it appears as though ARIN issues > > 1,600 to 1,700 ASNs each year. > > > > Looking at IANA's stats: > > 35840-36863 Assigned by ARIN 2005-02 > > 39936-40959 Assigned by ARIN 2006-03-29 > > 46080-47103 Assigned by ARIN 2008-03-27 > > 53248-54271 Assigned by ARIN 2009-04-21 > > 54272-55295 Assigned by ARIN 2009-04-21 > > Excluding April 2009, ARIN has only requested 3,072 ASNs since February 2005. > > > > Looking again at ARIN's historical statistics, they have issued 6,550 ASNs > > from 2005 through 2008, but have only gotten 3,072 ASNs from the IANA. > > > > Where's the difference? > > In San Antonio, Leslie gave a presentation that included information about > > returned and revoked ASNs. Slide 10 of the presentation indicates 4,357 ASNs > > have been returned to ARIN since January 2005. > > > > So it looks like ARIN is recycling unused ASNs, prolonging the lifespan of the > > free 16-bit ASN pool. > > Projecting this forward, at current consumption rates it should take > > approximately 32 months for ARIN to use up the 2,048 ASNs issued on 2009-04-21 > > by IANA, which puts us somewhere near December 2012. > > > > ARIN's historical statistics: > > https://www.arin.net/knowledge/statistics/historical.html > > IANA's stats: > > http://www.iana.org/assignments/as-numbers/ > > Presentation foils: > > https://www.arin.net/participate/meetings/reports/ARIN_XXIII/ppt/wednesday/rsd > > .ppt > > > > Cheers, > > Aaron > > > > > > On Thu, May 07, 2009 at 01:19:36PM -0700, Scott Leibrand wrote: > >> > I disagree. We are still waiting to get a release of the code train we > >> > use on the Cisco 7600 platform that supports 32-bit ASNs. It sounds > >> > like they're finally getting close, but I think a further extension > >> > probably would be helpful. > >> > > >> > We'll have a much better view of what's required by the fall meeting, > >> > when this is up for discussion. Since that will be our last chance to > >> > change policy before the current 1 Jan 2010 deadline, I definitely think > >> > this needs to be on the agenda. > >> > > >> > -Scott > >> > > >> > Owen DeLong wrote: > >>> > > NIT: The revised text of 5.1 (or at least specific amendments to it) > >>> > > should be > >>> > > stated as part of the Policy statement. The rationale section is not a > >>> > > binding > >>> > > part of the policy. > >>> > > > >>> > > Substance: This policy simply isn't needed. Current software for most > >>> > > routers supports 32 bit ASNs. There's been ample warning for providers > >>> > > and other organizations to update their management systems, scripts, > >>> > > etc. If they haven't done it by now, they are only going to do it in > >>> > > response > >>> > > to the change actually happening. Putting it off further does not > >>> really > >>> > > benefit the community. > >>> > > > >>> > > I am opposed to this policy as written. > >>> > > > >>>> > >> ## * ## > >>>> > >> > >>>> > >> > >>>> > >> Policy Proposal Name: Extend 16 bit ASN Assignments > >>>> > >> > >>>> > >> Proposal Originator: Marla Azinger > >>>> > >> > >>>> > >> Proposal Version: 1 > >>>> > >> > >>>> > >> Submission Date: 6 May 2009 > >>>> > >> > >>>> > >> Proposal type: Modify > >>>> > >> > >>>> > >> Policy term: Permanent > >>>> > >> > >>>> > >> Policy statement: This proposal is to modify section 5.1 in the NRPM > to > >>>> > >> extend the 16-bit ASN assignment timeframe for one more year further > >>>> > >> than the current text. The expiration requiring removal of section 5.1 > >>>> > >> is also being removed. > >>>> > >> > >>>> > >> Rationale: > >>>> > >> > >>>> > >> Currently users of 32-bit ASN?s are encountering technical issues that > >>>> > >> they can?t immediately overcome and therefore require 16-bit ASN?s to > >>>> > >> operate. As a result in the ARIN region to date, 204 of the 216 32-bit > >>>> > >> ASN?s that have been assigned have been returned and exchanged for a > 16 > >>>> > >> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction between > >>>> > >> 32-bit and 16-bit ASN?s. This proposal is to change the date on the > >>>> > >> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s to be > >>>> > >> assigned. If these changes are made then ARIN RIR ASN policy will read > >>>> > >> clearly and remove any misconceptions of 16-bit cutoff post run out > and > >>>> > >> enable technology to catch up to the ASN bit change. The expiration > date > >>>> > >> that requires removal of section 5.1 after zero distinction occurs is > to > >>>> > >> be removed. Instead section 5.1 will be left in place in the NRPM for > >>>> > >> value added historical purposes. > >>>> > >> > >>>> > >> The revision of 5.1 would read as follows: > >>>> > >> > >>>> > >> 5.1 16-bit and 32-bit AS Numbers > >>>> > >> > >>>> > >> ? Commencing 1 January 2007, ARIN will process applications that > >>>> > >> specifically request 32-bit only AS Numbers and assign such AS numbers > >>>> > >> as requested by the applicant. In the absence of any specific request > >>>> > >> for a 32-bit only AS Number, a 16-bit only AS Number will be assigned. > >>>> > >> > >>>> > >> ? Commencing 1 January 2009, ARIN will process applications that > >>>> > >> specifically request 16-bit only AS Numbers and assign such AS Numbers > >>>> > >> as requested by the applicant. In the absence of any specific request > >>>> > >> for a 16-bit only AS Number, a 32-bit only AS Number will be assigned. > >>>> > >> > >>>> > >> ? Commencing 1 January 2011, ARIN will cease to make any distinction > >>>> > >> between 16-bit only AS Numbers and 32-bit only AS Numbers, and will > >>>> > >> operate AS number assignments from an undifferentiated 32-bit AS >>>> > Number > >>>> > >> pool. > >>>> > >> > >>>> > >> Terminology > >>>> > >> > >>>> > >> ? "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 > >>>> > >> > >>>> > >> ? "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 - > >>>> > >> 4,294,967,295 > >>>> > >> > >>>> > >> ? "32-bit AS Numbers" refers to AS Numbers in the range 0 - > >>>> > >> 4,294,967,295 > >>>> > >> > >>>> > >> Timetable for implementation: Immediate > >>>> > >> > >>>> > >> > >>>> > >> _______________________________________________ > >>>> > >> PPML > >>>> > >> You are receiving this message because you are subscribed to > >>>> > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >>>> > >> Unsubscribe or manage your mailing list subscription at: > >>>> > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >>>> > >> Please contact info at arin.net if you experience any issues. > >>> > > > >>> > > ------------------------------------------------------------------------ > >>> > > > >>> > > _______________________________________________ > >>> > > PPML > >>> > > You are receiving this message because you are subscribed to > >>> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >>> > > Unsubscribe or manage your mailing list subscription at: > >>> > > http://lists.arin.net/mailman/listinfo/arin-ppml > >>> > > Please contact info at arin.net if you experience any issues. > >> > -- > >> > PPML > >> > You are receiving this message because you are subscribed to > >> > the ARIN Public Policy Mailing 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. > > > > -- > > > > Aaron Hughes > > aaronh at bind.com > > (703) 244-0427 > > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 > > http://www.bind.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. > > > > > P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible. > > > 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. -- Aaron Hughes aaronh at bind.com (703) 244-0427 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From stephen at sprunk.org Fri May 8 14:18:22 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 08 May 2009 13:18:22 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <4A02F722.5070607@chl.com> References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> <4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com> <3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> <4A02F722.5070607@chl.com> Message-ID: <4A04776E.7000701@sprunk.org> Joe Maimon wrote: > William Herrin wrote: > >> No. I'm saying that the ones who deliver stateful firewalled service to a large base of customers using global IPs instead of private IPs, and who deliberately built it that way just in the last couple of years did so knowing the score. >> > > I suppose in this definition, hoarding would be exposed by assigning a non trivial dollar value to each address. > > Then you would see where it was really necessary and justified and where > it would be engineered out. > > In other words inefficiency is only relevant in a cost versus benefit > scenario. > Indeed. Right now, the cost of inefficiency is zero and the benefit to fixing it is zero, while the cost of fixing it is usually nonzero. It's not surprising that we've seen the results we have. Attach a monetary value to the resource, though, and the entire picture changes. >> and then move the addresses to more valuable >> uses within the company. I'll be able to say, "I told you so," but I >> won't be able to prove that the six-figures-paid address administrator >> over at my favorite vendor added two plus two several years ahead of >> the deadline. >> > > If we can figure out justifiable within-the-norm behavior right now that can reap large benefits later, so can they. In fact they would be remiss to not do so. > > Just to be helpful to all these large companies, I will try to clarify some modes of this behavior. > > * ignoring dead and underutilized customer space > * taking customer space request at near face value > * no verification of customer space utilization > * /30 on serials instead of /31, unnumbered, rfc1918 > * all other underutilization and dont say they dont exist. > Much of the blame for underutilization and "waste" is placed on end-user orgs with legacy space, and for them I'll add another category: * Excess space that was justified at the time issued but would not be today, due to policy changes That is a _huge_ consumer of space -- several /8s and thousands of /16s. 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 kkargel at polartel.com Fri May 8 14:29:14 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 8 May 2009 13:29:14 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <4A04759A.1050503@sprunk.org> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C2@mail> <4A04759A.1050503@sprunk.org> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0F3@mail> > -----Original Message----- > From: Stephen Sprunk [mailto:stephen at sprunk.org] > Sent: Friday, May 08, 2009 1:11 PM > To: Kevin Kargel > Cc: ARIN PPML > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised > andforwarded to the Board > > Kevin Kargel wrote: > > I believe the proof of what I am talking about is all of the unused IPv4 > space that is not being returned so that it can be held as a speculative > > commodity. Inaction in itself is a proof. > > > > You are assigning a motive without proof. Yes, there is a lot of space > out there that could be returned and hasn't been. I believe that in the > vast majority of cases it is abandoned, forgotten, or is being used > inefficiently and there is insufficient motivation to renumber. I have > seen all of these cases in the wild many, many times; I have _never_ > been told "we won't return that space because we're hoping to sell it > one day." > > My motivation for supporting liberalized transfers is to apply a > financial incentive to correct all of the problems above that I _have_ > seen. If companies hear that they can get money for giving up space, > many (but not all) of them are going to do an inventory and find out > what they have but don't actually need so that they can cash in. Would > I prefer altruistic motivation? Certainly. We've been trying that for > a couple of decades now, and it has resulted in a few returns, but > nowhere near as many as I'd hoped -- or as many as the community will > need in a few years. It's time to quit pretending that altruism is > sufficient. > > 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 I appreciate your motivations for a liberalized transfer policy (which is a nice sounding euphemism for an IP commodities market). If that were as far as it went I would be all for it. The problem is that there is a bigger picture that includes inviting government control and taxation of what will now be a market valued commodity. Placing a monetary value on IP addresses invites (several independent governments) to regulate them. When that happens (several independent governments) will tax their value. Soon after that (several independent governments) will administrate them. The liberalized transfer policy will actually hasten what we are hoping to avoid. Neither is it good to join the criminals because they are doing things you can't. The system we have been running for a couple of decades now is actually working. Use this very email as a proof if you will. If it ain't broke don't fix it. -------------- 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 May 8 14:30:21 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 08 May 2009 13:30:21 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <20090507024147.A228E2B21FC@mx5.roble.com> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <20090507024147.A228E2B21FC@mx5.roble.com> Message-ID: <4A047A3D.5010205@sprunk.org> Roger Marquis wrote: > Ted Mittelstaedt wrote: > >>> Rather than helping the problem the fact that this market is being discussed is exactly what is causing the hoarding. >>> >> I have to cry foul with this. There's been implications of hoarding on this list and in the last meeting but I have only seen a single allegation posted on this list of an illigitimate IPv4 holding, and that was a year ago. (and it wasn't a hoarding situation) >> More importantly, the so-called hoarding problem has existed for at least a decade, maybe two. It _cannot_ have been caused by this discussion because it happened _first_. In fact, if you want to play cause and effect, the only logical conclusion is that this discussion was caused by the "hoarding"! > If hoarding includes large netblocks (mainly /16s) that are not used and/or not needed I can name several, and even a cursory audit will show dozens. > I could name dozens myself, if it weren't for NDAs. ARIN staff could find most of them easily enough by comparing their list of legacy registrations vs. what's seen in the DFZ. >> Since true hoarding implies false data submitted for an IPv4 >> > > This may be a source of confusion. Hoarding does not imply false data submitted for an IPv4. > Hoarding does imply intent, though, and I believe that such implication is not correct in most cases. As usual, Hanlon's Razor applies. 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 kkargel at polartel.com Fri May 8 14:34:10 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 8 May 2009 13:34:10 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <4A047A3D.5010205@sprunk.org> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk><20090507024147.A228E2B21FC@mx5.roble.com> <4A047A3D.5010205@sprunk.org> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0F4@mail> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Stephen Sprunk > Sent: Friday, May 08, 2009 1:30 PM > To: Roger Marquis > Cc: ARIN PPML > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised > andforwarded to the Board > More importantly, the so-called hoarding problem has existed for at > least a decade, maybe two. It _cannot_ have been caused by this > discussion because it happened _first_. In fact, if you want to play > cause and effect, the only logical conclusion is that this discussion > was caused by the "hoarding"! > I didn't say it "caused" the hoarding (speculating?), I said it promoted and exacerbated it. -------------- 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 Fri May 8 14:53:24 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 8 May 2009 11:53:24 -0700 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <4A02B79E.8060807@arin.net> References: <4A02B79E.8060807@arin.net> Message-ID: <1F9EF7F2967B47B99AAA8CAD2B9A624C@tedsdesk> Internet Partners, Inc. is opposed to this proposal as it is currently worded. We are not opposed to extending the cut-off to 2011. But we are opposed to clutter in the NRPM and we feel that sections of the NRPM dealing with past deadlines of 2007 and Jan 1 2009 should be deleted from NRPM. We would support a proposal that replaces 5.1 with a simplified section that deals with how things are now and how they are going to be going forward. Ted > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > Sent: Thursday, May 07, 2009 3:28 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments > > ARIN received the following policy proposal and is posting it > to the Public Policy Mailing List (PPML) in accordance with > Policy Development Process. > > This proposal is in the first stage of the Policy Development Process. > ARIN staff will perform the Clarity and Understanding step. > Staff does not evaluate the proposal at this time, their goal > is to make sure that they understand the proposal and believe > the community will as well. > Staff will report their results to the ARIN Advisory Council > (AC) within 10 days. > > The AC will review the proposal at their next regularly > scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may > be extended to the subsequent regularly scheduled meeting). > The AC will decide how to utilize the proposal and announce > the decision to the PPML. > > In the meantime, the AC invites everyone to comment on the > proposal on the PPML, particularly their support or > non-support and the reasoning behind their opinion. Such > participation contributes to a thorough vetting and provides > important guidance to the AC in their deliberations. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at:https://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Extend 16 bit ASN Assignments > > Proposal Originator: Marla Azinger > > Proposal Version: 1 > > Submission Date: 6 May 2009 > > Proposal type: Modify > > Policy term: Permanent > > Policy statement: This proposal is to modify section 5.1 in > the NRPM to extend the 16-bit ASN assignment timeframe for > one more year further than the current text. The expiration > requiring removal of section 5.1 is also being removed. > > Rationale: > > Currently users of 32-bit ASN's are encountering technical > issues that they can't immediately overcome and therefore > require 16-bit ASN's to operate. As a result in the ARIN > region to date, 204 of the 216 32-bit ASN's that have been > assigned have been returned and exchanged for a 16 bit ASN. > On 1 JAN 2010 ARIN policy declares zero distinction between > 32-bit and 16-bit ASN's. This proposal is to change the date > on the third line of NRPM 5.1 and extend the timeframe for 16 > bit ASN's to be assigned. If these changes are made then ARIN > RIR ASN policy will read clearly and remove any > misconceptions of 16-bit cutoff post run out and enable > technology to catch up to the ASN bit change. The expiration > date that requires removal of section 5.1 after zero > distinction occurs is to be removed. Instead section 5.1 will > be left in place in the NRPM for value added historical purposes. > > The revision of 5.1 would read as follows: > > 5.1 16-bit and 32-bit AS Numbers > > . Commencing 1 January 2007, ARIN will process applications > that specifically request 32-bit only AS Numbers and assign > such AS numbers as requested by the applicant. In the absence > of any specific request for a 32-bit only AS Number, a 16-bit > only AS Number will be assigned. > > . Commencing 1 January 2009, ARIN will process applications > that specifically request 16-bit only AS Numbers and assign > such AS Numbers as requested by the applicant. In the absence > of any specific request for a 16-bit only AS Number, a 32-bit > only AS Number will be assigned. > > . Commencing 1 January 2011, ARIN will cease to make any > distinction between 16-bit only AS Numbers and 32-bit only AS > Numbers, and will operate AS number assignments from an > undifferentiated 32-bit AS Number pool. > > Terminology > > . "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 > > . "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 - > 4,294,967,295 > > . "32-bit AS Numbers" refers to AS Numbers in the range 0 - > 4,294,967,295 > > Timetable for implementation: Immediate > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > From owen at delong.com Fri May 8 14:46:46 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 8 May 2009 11:46:46 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <4A04776E.7000701@sprunk.org> References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> <4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com> <3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> <4A02F722.5070607@chl.com> <4A04776E.7000701@sprunk.org> Message-ID: <131B6742-0AA3-4302-B019-0D3CED4ACA4D@delong.com> On May 8, 2009, at 11:18 AM, Stephen Sprunk wrote: > Joe Maimon wrote: >> William Herrin wrote: >> >>> No. I'm saying that the ones who deliver stateful firewalled >>> service to a large base of customers using global IPs instead of >>> private IPs, and who deliberately built it that way just in the >>> last couple of years did so knowing the score. >>> >> >> I suppose in this definition, hoarding would be exposed by >> assigning a non trivial dollar value to each address. >> >> Then you would see where it was really necessary and justified and >> where it would be engineered out. >> >> In other words inefficiency is only relevant in a cost versus >> benefit scenario. >> > > Indeed. Right now, the cost of inefficiency is zero and the benefit > to fixing it is zero, while the cost of fixing it is usually > nonzero. It's not surprising that we've seen the results we have. > Attach a monetary value to the resource, though, and the entire > picture changes. > Perhaps, but, there may be unintended consequences of pricing perfectly valid and efficient usage out of existence in the process. Owen From bill at herrin.us Fri May 8 15:01:29 2009 From: bill at herrin.us (William Herrin) Date: Fri, 8 May 2009 15:01:29 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <395570.6547.qm@web63304.mail.re1.yahoo.com> References: <49FF15ED.4070902@arin.net> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> <4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com> <3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> <395570.6547.qm@web63304.mail.re1.yahoo.com> Message-ID: <3c3e3fca0905081201x652dc908wc94b4e153cc80299@mail.gmail.com> On Thu, May 7, 2009 at 10:37 AM, Lee Howard wrote: > Which of these statements better reflects your position? > If an organization can use NAT44, they SHOULD. > If an organization can use NAT44, they MUST. Hi Lee, I'd say: none of the above. I think wading into a redefinition of "need" prior to actual free pool exhaustion would be begging for trouble if it was doable at all. Doubly so without the other RIRs on board. But let's be eyes-wide-open about it and not pretend that the orgs abusing this and similar loopholes aren't actually hoarding. And let's start thinking about how we're going to redress this in a practical, moving-forward manner once the free pool is gone. On Thu, May 7, 2009 at 12:50 PM, Milton L Mueller wrote: > Hoarding, no. You are misusing the term for emotional purposes. Milton, Hoarding is when, upon observing the scarcity of a desired resource, you acquire and store a quantity of the resource against a future need, thereby depriving others. It's a form of waste. Let me put it another way: scarcity + waste + retention = hoarding. If you waste a scarce resource in a way that allows you to keep the scarce resource, that's hoarding. Still another way to define hoarding: knowing a resource is scarce, you choose to acquire far more of it than what you could have gotten by with. What my favorite vendor has done is akin to emptying the local stores of flashlighs before a hurricane and then saying, "well, it's not really hoarding because every flashlight we bought we actually used, turning it on and off at least once." Actually, that last paragraph isn't really fair. My favorite vendor hasn't stepped forward and defended its choice; the defense comes primarily from 3rd-party apologists. On Thu, May 7, 2009 at 3:30 PM, George, Wes E [NTK] wrote: > This is not about profit, it's about breaking even on what > would otherwise be expensive, but *optional* work for > many organizations to reclaim IP space for the good of > the Internet community. Hi Wes, With respect to folks who got their IP addresses before scarcity was a looming emergency, I wholeheartedly agree. And I've said so serveral times. For the IPs that went out in the last year or two, well, not to put too fine a point on it but they should have known better. If you're trying to get a /22, well okay. That's our fault for not allowing /24 assignments for multihomers. But a /9 that didn't need to be? > So...using all of the available private space, I get a grand total of 17.1M addresses. > > VZW subscriber count = 86.6M > Adding, so that we don't keep singling out VZ: > ATT subscriber count = 78.2M (6M of which are iPhones) > Sprint subscriber count = 49.3M > > At best, we're talking about nearly 3:1 oversub on addresses, at worst, 5:1. Oversubscription is the wrong model here. A reasonable network architecture at the current time wouldn't put the 1M addresses available just in 172.16/12 through a single stateful firewall, NAT or otherwise. The technology to make that practical is still a ways off. That means that in order to support a stateful firewall, you're going to segment the network into smaller groupings, each of which could reasonably resuse the same RFC1918 IPs. Yes, there are non-trivial architectural differences between a network that is generally segmented and one which must be completely segmented. You don't need to run down the list. Nevertheless, the step between modest packet filtering and a stateful firewall is a whole lot larger than the step between a stateful firewall and a stateful NAT firewall. And for the record, I support releasing the class-E space as additional private-IP space in order to make large-scale NAT easier. Legacy system issues make class-E just about worthless for use on the public Internet but they could well be valuable inside the controlled environment of a NAT interior. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From JOHN at egh.com Fri May 8 15:04:24 2009 From: JOHN at egh.com (John Santos) Date: Fri, 8 May 2009 15:04:24 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board Message-ID: <1090508145149.425B-100000@Ives.egh.com> On 8 May 2009 stephen at sprunk.org wrote: > Kevin Kargel wrote: > > I believe the proof of what I am talking about is all of the unused IPv4 space that is not being returned so that it can be held as a speculative > > commodity. Inaction in itself is a proof. > > > > You are assigning a motive without proof. Yes, there is a lot of space > out there that could be returned and hasn't been. I believe that in the > vast majority of cases it is abandoned, forgotten, or is being used > inefficiently and there is insufficient motivation to renumber. I have > seen all of these cases in the wild many, many times; I have _never_ > been told "we won't return that space because we're hoping to sell it > one day." > > My motivation for supporting liberalized transfers is to apply a > financial incentive to correct all of the problems above that I _have_ > seen. If companies hear that they can get money for giving up space, > many (but not all) of them are going to do an inventory and find out > what they have but don't actually need so that they can cash in. Would > I prefer altruistic motivation? Certainly. We've been trying that for > a couple of decades now, and it has resulted in a few returns, but > nowhere near as many as I'd hoped -- or as many as the community will > need in a few years. It's time to quit pretending that altruism is > sufficient. > > S > Random thought of the day -- What about an IP deposit, like a returnable bottle deposit? Make a deposit with ARIN when you get your IP, get it back (plus interest?) when you return it. This money would not go to ARIN; it would be more like an escrow account, but it would be motivation for people with unused space to return it and get there nickels back. I don't think it would be possible to make this retroactive, though. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From Wesley.E.George at sprint.com Fri May 8 15:05:36 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Fri, 8 May 2009 14:05:36 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revisedandforwarded to the Board In-Reply-To: <7804282E4E414FBC96FC25D5E4DCB6E8@tedsdesk> References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail><81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk><3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com><20090506185019.GA31911@ussenterprise.ufp.org><3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com><4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com><3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com><4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com><3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> <7804282E4E414FBC96FC25D5E4DCB6E8@tedsdesk> Message-ID: Ted, If "my phone" = the aforementioned Moto Q on the Sprint network, I can say with 100% certainty that you are *not* doing exclusively IPv6 on your phone today. WinMo6 does support 6to4 (2002:), and since we're assigning externally routable IPv4 addresses to our customer devices, it *should* be able to reach IPv6 addresses via 6to4 even though the underlying network doesn't support IPv6. It likely even prefers IPv6 addresses when they're available, but there is not a standard IPv6 address (2001: or 2600:) being assigned (yet), and certainly no IPv6-speaking device on Sprint's network that could seamlessly translate between IPv6 and IPv4, especially for things like SSH. I *wish* we were that far along already and that it was working that well. Wes George -----Original Message----- From: Ted Mittelstaedt [mailto:tedm at ipinc.net] Sent: Friday, May 08, 2009 2:11 PM To: George, Wes E [NTK]; 'William Herrin'; 'Martin Hannigan' Cc: 'arin ppml' Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revisedandforwarded to the Board > To your second point, this isn't really about widgets sitting > in a warehouse. It's the phone already in your hand. I heard > word that we had been asking vendors for IPv6 at least as a > roadmap item in in mobile devices for probably 2 years, but > not every vendor was able to necessarily deliver, and the > ones that did may have had varying degrees of success in a > complete and functional IPv6 implementation. My Sprint Motorola Q that's a few years old is IPv6 > The expectation > is that attrition of old devices will partially solve this > problem by creating an installed base that does support IPv6 > and (hopefully) needs an IPv4 address less often if at all. > But, depending on how often devices roll over, that may not > reduce the IPv4-using population enough either. Even then, > that only puts this particular application on a par with the > rest of the PC-using population: IPv6 is supported, but is > only useful if we ensure that either a) every possible > destination our users might go to is IPv6-capable or b) that > there is some sort of intermediate device that allows an > IPv6-only device to reach IPv4-only websites. I believe that is how Sprint does it with my phone. > I fully expect that there will be classes of devices that can > be IPv6-only either because they only need to reach IPv6 > content or because the content that they reach can be proxied > through an IPv6-to-IPv4 NAT/ALG, but not all devices will > fall into that category. On my phone I have a web browser, e-mail client, SSH client, FTP client, RSS reader. What else do I need? My phone does NOT have an IPv4 number on it, this I know from digging into it. Ted This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From tedm at ipinc.net Fri May 8 15:08:04 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 8 May 2009 12:08:04 -0700 Subject: [arin-ppml] Will the price per IP really be affected by the transfer market introduced in 2009-1? Message-ID: Hi All, I have a question for everyone's consideration. If a transfer market goes into effect, after 5 years, what would a reasonable estimate be for the amount of IPv4 in production, that was in production as a result of a costly org-to-org directed transfer? And, is it realistic to assume that cost of all other IPv4 to the customer will be affected? If for example, after 5 years only .005% of all IPv4 in service on the Internet was in service as a result of a transfer, then even if /8's are going for 50 million dollars, wouldn't competition pretty much mandate that the ISP paying transfer fees be utterly unable to pass that cost along to their customers as a surcharge on IPv4? Ted From scottleibrand at gmail.com Fri May 8 15:21:36 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 08 May 2009 12:21:36 -0700 Subject: [arin-ppml] Will the price per IP really be affected by the transfer market introduced in 2009-1? In-Reply-To: References: Message-ID: <4A048640.1080302@gmail.com> As a matter of economic theory, I think we can assume that the amount of IPv4 in service as a result of a transfer is actually a function of the price, rather than an independent variable. Put in microeconomic jargon, the amount of IPv4 in service as a result of a transfer is the supply, which is a function of the price and the supply curve. The price, in turn, is a function of the supply curve and the demand curve. Both such curves represent the amount of IPv4 space that everyone (cumulatively) is willing to provide/request at any given price. If you think about the incentives of an individual ISP, with some quantity of IPv4 space, they could be in one of three states: they might be willing to pay for IPv4 addresses, if the price is low enough, to meet their internal demand for growth. They might be willing to provide IPv4 addresses, at a price, if that price is sufficiently high to compensate them for the trouble and opportunity cost of giving them up (and switching to a substitute like IPv6, or abandoning marginally profitable customers). Or, they may be in the middle, where they don't engage in the market, because the current price isn't low enough to make it worth getting addresses, but also isn't high enough to overcome all the trouble of releasing IPs. To get back to your question, the marginal cost to an ISP of providing an IPv4 address to a customer should be approximately equal to the market price of that IPv4 address on the transfer market, plus or minus the transaction costs of freeing up enough addresses to transfer (or finding someone else willing to do the same). So, depending on their own particular circumstances, some ISP will pass on an IPv4 address cost of approximately the market price, some will pass on less (or none at all), and others might be able to pass along a higher price (especially if the market price stays low). -Scott Ted Mittelstaedt wrote: > Hi All, > > I have a question for everyone's consideration. > > If a transfer market goes into effect, after 5 years, what would a > reasonable > estimate be for the amount of IPv4 in production, that was in production as > a > result of a costly org-to-org directed transfer? And, is it realistic to > assume that cost of all other IPv4 to the customer will be affected? > > If for example, after 5 years only .005% of all IPv4 in service > on the Internet was in service as a result of a transfer, then even if > /8's are going for 50 million dollars, wouldn't competition pretty > much mandate that the ISP paying transfer fees be utterly > unable to pass that cost along to their customers as a surcharge on > IPv4? > > Ted > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From michael.dillon at bt.com Fri May 8 15:47:08 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 8 May 2009 20:47:08 +0100 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <4A04759A.1050503@sprunk.org> Message-ID: <28E139F46D45AF49A31950F88C497458FFD24E@E03MVZ2-UKDY.domain1.systemhost.net> > If companies hear that they can > get money for giving up space, many (but not all) of them are > going to do an inventory and find out what they have but > don't actually need so that they can cash in. Sorry, but the business world does not work like that. In order to do any recovery work, you have to make a business case which involves balancing the costs of the work, versus the returns from selling the IP addresses and also factor in the risk that the price will be rather lower than expected, plus the risks related to potential disruption caused by the cleanup. Earlier you described seeing many cases of sloppiness and your motive is to provide an incentive to clean up. But did't you notice that this kind of sloppiness is accepted within the businesses that you looked at? They've looked at the full spectrum of activity that they could do, and decided that some things, although ugly, just don't cause negative impacts to customers, so it is better to leave well enough alone. This isn't going to change unless it really starts to hit the bottom line, and that will happen when IANA runs out of IPv4 addresses and companies have to face up to the fact that they are unlikely to ever get more addresses from ARIN, or if they do get more, it will be less than they need. At that point, something which could cause a simple T1 install to fail becomes a big risk to the bottom line because the customer ordering that T1 has a hundred or two other circuits, plus colo, plus other value-add services, and the company risks losing all of it for the want of an address. That is what will motivate businesses, not a few paltry thousands of dollars gained by selling IP address blocks. --Michael Dillon P.S. I don't doubt that a few businesses will spend some big cash to buy up addresses and avert catastrophe, but they will pay big bucks because the supply will be extremely limited. That will be the end of the IP address market as people realise that it is not stable, can't be relied on, and that there may not really be enough available addresses anywhere in the world. IPv6 will be like an oasis in the desert. End of story. From jmaimon at chl.com Fri May 8 15:47:15 2009 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 08 May 2009 15:47:15 -0400 Subject: [arin-ppml] Will the price per IP really be affected by the transfer market introduced in 2009-1? In-Reply-To: References: Message-ID: <4A048C43.3010900@chl.com> Ted Mittelstaedt wrote: > Hi All, > > I have a question for everyone's consideration. > > If a transfer market goes into effect, after 5 years, what would a > reasonable > estimate be for the amount of IPv4 in production, that was in production as > a > result of a costly org-to-org directed transfer? And, is it realistic to > assume that cost of all other IPv4 to the customer will be affected? > > If for example, after 5 years only .005% of all IPv4 in service > on the Internet was in service as a result of a transfer, then even if > /8's are going for 50 million dollars, wouldn't competition pretty > much mandate that the ISP paying transfer fees be utterly > unable to pass that cost along to their customers as a surcharge on > IPv4? > > Ted > Economically speaking, this is (theoretically) self-correcting. From stephen at sprunk.org Fri May 8 15:48:24 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 08 May 2009 14:48:24 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <131B6742-0AA3-4302-B019-0D3CED4ACA4D@delong.com> References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> <4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com> <3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> <4A02F722.5070607@chl.com> <4A04776E.7000701@sprunk.org> <131B6742-0AA3-4302-B019-0D3CED4ACA4D@delong.com> Message-ID: <4A048C88.7050705@sprunk.org> Owen DeLong wrote: > On May 8, 2009, at 11:18 AM, Stephen Sprunk wrote: >> Indeed. Right now, the cost of inefficiency is zero and the benefit >> to fixing it is zero, while the cost of fixing it is usually >> nonzero. It's not surprising that we've seen the results we have. >> Attach a monetary value to the resource, though, and the entire >> picture changes. >> > Perhaps, but, there may be unintended consequences of pricing perfectly > valid and efficient usage out of existence in the process. There are only two choices in front of us once IPv4 exhaustion hits: 1. New entrants can't enter the IPv4 market at all, because there is no supply left. 2. New entrants have to pay someone else for enough supply to enter the IPv4 market. Yes, #2 means that some new entrants won't be able to afford the cost of entry, and that's bad -- but IMHO it's not as bad as blocking _all_ new entrants. In fact, some existing players may decide to exit the market because that's more profitable than what they're currently doing with their supply, and that's probably bad too -- but IMHO that's the lesser of the various evils we are forced to choose between. 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 michael.dillon at bt.com Fri May 8 15:58:00 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 8 May 2009 20:58:00 +0100 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <4A04776E.7000701@sprunk.org> Message-ID: <28E139F46D45AF49A31950F88C497458FFD252@E03MVZ2-UKDY.domain1.systemhost.net> > Indeed. Right now, the cost of inefficiency is zero and the > benefit to fixing it is zero, while the cost of fixing it is > usually nonzero. It's not surprising that we've seen the > results we have. Attach a monetary value to the resource, > though, and the entire picture changes. Not unless the monetary value is above some threshold. For instance, I've been working at companies paying ARIN's highest fee level for some time. To us, it is effectively zero. We know addresses are needed to make sales, and the number is so low that nobody blinks an eye at it. What threshold needs to be passed before the big companies, with the largest stocks of IPv4 are likely to take notice. If these companies don't put addresses up for sale, there will be nothing to buy. And if you don't get some million dollar transactions to actually prove the monetary value, then there is zero motive to act. IPv4 runout raises a whole bunch of other issues that require attention, such as IPv6 testing, systems support for IPv6, migration off of some old devices that should have been gone long ago, auditing IP addresses so that corporate officers can attest to ARIN, chasing recalcitrant vendors who do not yet have IPv6 roadmaps, arguments about whether NAT really could mitigate any problems, and so on. With all of this happening, I really think that it will be very hard to get any attention for a plan to sell off some IPv4 address blocks. Talk to Leo Vegoda about all the signoffs that he needed to get to recover 14/8, digging through multiple layers of mergers, acquisitions, spinoffs and demergers to find anyone who considered themselves to be a stakeholder. I think that roughly 100% of big ISPs will be in the same complex position with regard to getting signoff for selling an IPv4 block. This is just not a feasible direction to go in. --Michael Dillon From owen at delong.com Fri May 8 15:58:37 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 8 May 2009 12:58:37 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <4A048C88.7050705@sprunk.org> References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> <4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com> <3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> <4A02F722.5070607@chl.com> <4A04776E.7000701@sprunk.org> <131B6742-0AA3-4302-B019-0D3CED4ACA4D@delong.com> <4A048C88.7050705@sprunk.org> Message-ID: <08595F27-45BF-4522-9C47-153F3170AA3E@delong.com> On May 8, 2009, at 12:48 PM, Stephen Sprunk wrote: > Owen DeLong wrote: >> On May 8, 2009, at 11:18 AM, Stephen Sprunk wrote: >>> Indeed. Right now, the cost of inefficiency is zero and the >>> benefit to fixing it is zero, while the cost of fixing it is >>> usually nonzero. It's not surprising that we've seen the results >>> we have. Attach a monetary value to the resource, though, and the >>> entire picture changes. >>> >> Perhaps, but, there may be unintended consequences of pricing >> perfectly >> valid and efficient usage out of existence in the process. > > There are only two choices in front of us once IPv4 exhaustion hits: > > 1. New entrants can't enter the IPv4 market at all, because there is > no supply left. > 2. New entrants have to pay someone else for enough supply to enter > the IPv4 market. > > Yes, #2 means that some new entrants won't be able to afford the > cost of entry, and that's bad -- but IMHO it's not as bad as > blocking _all_ new entrants. In fact, some existing players may > decide to exit the market because that's more profitable than what > they're currently doing with their supply, and that's probably bad > too -- but IMHO that's the lesser of the various evils we are forced > to choose between. > Perhaps I misunderstood your suggestion. I thought you were suggesting that ARIN go to an annual cost per IP model which would in some way increase the cost of holding on to existing resources. Owen From sethm at rollernet.us Fri May 8 16:09:04 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 08 May 2009 13:09:04 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <4A048C88.7050705@sprunk.org> References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> <4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com> <3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> <4A02F722.5070607@chl.com> <4A04776E.7000701@sprunk.org> <131B6742-0AA3-4302-B019-0D3CED4ACA4D@delong.com> <4A048C88.7050705@sprunk.org> Message-ID: <4A049160.5080102@rollernet.us> Stephen Sprunk wrote: > Owen DeLong wrote: >> On May 8, 2009, at 11:18 AM, Stephen Sprunk wrote: >>> Indeed. Right now, the cost of inefficiency is zero and the benefit >>> to fixing it is zero, while the cost of fixing it is usually >>> nonzero. It's not surprising that we've seen the results we have. >>> Attach a monetary value to the resource, though, and the entire >>> picture changes. >>> >> Perhaps, but, there may be unintended consequences of pricing perfectly >> valid and efficient usage out of existence in the process. > > There are only two choices in front of us once IPv4 exhaustion hits: > > 1. New entrants can't enter the IPv4 market at all, because there is no > supply left. > 2. New entrants have to pay someone else for enough supply to enter the > IPv4 market. > > Yes, #2 means that some new entrants won't be able to afford the cost of > entry, and that's bad -- but IMHO it's not as bad as blocking _all_ new > entrants. In fact, some existing players may decide to exit the market > because that's more profitable than what they're currently doing with > their supply, and that's probably bad too -- but IMHO that's the lesser > of the various evils we are forced to choose between. > I will need more IP addresses eventually. Maybe this year, maybe next, but here's the process I see myself taking: First I will apply for space from ARIN. I suspect I'll be denied, or maybe I'll get lucky if they're able to fulfill small requests easier than large ones. Who knows. If I get approved, hooray, all is well and the task ends here. I'd also expect this is the last IPv4 I'll ever again get and plan accordingly. If I get denied I'll go to each of my upstreams and say, hey, I need more space. How can you help me? I'd hope for a contiguous block. If not, I'd settle for a bunch of /24's and be forced to contribute to the routing table bloat by announcing all of them individually. I'd hope they don't tell me "go ask ARIN, even though they're out." As a last resort I'd have to find someone who would provide addresses to me through whatever method gets the job done. Or maybe someone out there will be desperate enough for my space that I can "sell" it and retire early. ;) ~Seth From info at arin.net Fri May 8 16:32:53 2009 From: info at arin.net (Member Services) Date: Fri, 08 May 2009 16:32:53 -0400 Subject: [arin-ppml] ARIN XXIII Meeting Report Now Available Message-ID: <4A0496F5.5020801@arin.net> From 26-29 April, the ARIN community took part in the ARIN XXIII Public Policy and Members Meeting, held in San Antonio. The report of that meeting, which includes presentations, summary notes, and transcripts of the entire meeting, is now available on the ARIN website at: http://www.arin.net/participate/meetings/reports/ARIN_XXIII/ Please check back next week when an archive of the meeting's webcast will be available. We thank everyone in the community who participated in person or remotely and those who responded to the surveys. We look forward to seeing you 21-23 October 2009 for ARIN XXIV in Dearborn, Michigan. Regards, Member Services American Registry for Internet Numbers (ARIN) From tedm at ipinc.net Fri May 8 17:44:33 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 8 May 2009 14:44:33 -0700 Subject: [arin-ppml] Will the price per IP really be affected by the transfer market introduced in 2009-1? In-Reply-To: <4A048640.1080302@gmail.com> References: <4A048640.1080302@gmail.com> Message-ID: <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> Ah, but your point is dependent on how an ISP views it's market. In my employers target markets, Internet connectivity is a commodity. We cannot raise our prices beyond more than a few percent of competition or we will lose all our customers. There is no room for us to pass along a price increase for transfer IPv4, or a price increase for shifting to IPv6 - we have to absorb those costs. And let me tell you, there ain't a lot of room there to absorb much. With commodity markets, any business operating in them must tie everything to the cost of the product, the product won't sell at all if your more than a few percent higher than competition. If you have a supplier increase pricing somewhere then you have to cut expenses somewhere else. If, as you assume, the amount of transfer IPv4 in service is a function of the price, then if Internet Service is a commodity market, transfer pricing is going to be severely limited in how far it can rise. If transfer pricing does not rise high enough to make it worthwhile for orgs to spend the money to renumber out of it, then the orgs won't, and the transfer market will never come into existence. Thus, let me put my original question a bit differently. How much of an increase for IPv4 can YOU absorb? How much do you think your competitors can absorb? How much do you think the industry can absorb? If it's not a large amount, then how exactly will a transfer market in IPv4 reach critical mass to enable it to get started? Ted > -----Original Message----- > From: Scott Leibrand [mailto:scottleibrand at gmail.com] > Sent: Friday, May 08, 2009 12:22 PM > To: Ted Mittelstaedt > Cc: 'ARIN PPML' > Subject: Re: [arin-ppml] Will the price per IP really be > affected by the transfer market introduced in 2009-1? > > As a matter of economic theory, I think we can assume that > the amount of > IPv4 in service as a result of a transfer is actually a > function of the price, rather than an independent variable. > Put in microeconomic jargon, the amount of IPv4 in service as > a result of a transfer is the supply, which is a function of > the price and the supply curve. The price, in turn, is a > function of the supply curve and the demand curve. > Both such curves represent the amount of IPv4 space that everyone > (cumulatively) is willing to provide/request at any given price. > > If you think about the incentives of an individual ISP, with > some quantity of IPv4 space, they could be in one of three > states: they might be willing to pay for IPv4 addresses, if > the price is low enough, to meet their internal demand for > growth. They might be willing to provide > IPv4 addresses, at a price, if that price is sufficiently > high to compensate them for the trouble and opportunity cost > of giving them up (and switching to a substitute like IPv6, > or abandoning marginally profitable customers). Or, they may > be in the middle, where they don't engage in the market, > because the current price isn't low enough to make it worth > getting addresses, but also isn't high enough to overcome all > the trouble of releasing IPs. > > To get back to your question, the marginal cost to an ISP of > providing an IPv4 address to a customer should be > approximately equal to the market price of that IPv4 address > on the transfer market, plus or minus the transaction costs > of freeing up enough addresses to transfer (or finding > someone else willing to do the same). So, depending on their > own particular circumstances, some ISP will pass on an IPv4 > address cost of approximately the market price, some will > pass on less (or none at all), and others might be able to > pass along a higher price (especially if the market price stays low). > > -Scott > > Ted Mittelstaedt wrote: > > Hi All, > > > > I have a question for everyone's consideration. > > > > If a transfer market goes into effect, after 5 years, > what would a > > reasonable estimate be for the amount of IPv4 in > production, that was > > in production as a > > result of a costly org-to-org directed transfer? And, is > it realistic to > > assume that cost of all other IPv4 to the customer will be affected? > > > > If for example, after 5 years only .005% of all IPv4 in > service on > > the Internet was in service as a result of a transfer, then even if > > /8's are going for 50 million dollars, wouldn't competition pretty > > much mandate that the ISP paying transfer fees be utterly unable to > > pass that cost along to their customers as a surcharge on IPv4? > > > > Ted > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed > to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > From tedm at ipinc.net Fri May 8 17:51:49 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 8 May 2009 14:51:49 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revised andforwarded to the Board In-Reply-To: <28E139F46D45AF49A31950F88C497458FFD24E@E03MVZ2-UKDY.domain1.systemhost.net> References: <4A04759A.1050503@sprunk.org> <28E139F46D45AF49A31950F88C497458FFD24E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4F9723132A934DFAAF14305F2D6D857D@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com > Sent: Friday, May 08, 2009 12:47 PM > To: ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy > -Revised andforwarded to the Board > > This isn't going to change unless it really starts to hit the > bottom line, and that will happen when IANA runs out of IPv4 > addresses and companies have to face up to the fact that they > are unlikely to ever get more addresses from ARIN, or if they > do get more, it will be less than they need. At that point, > something which could cause a simple T1 install to fail > becomes a big risk to the bottom line because the customer > ordering that T1 has a hundred or two other circuits, plus > colo, plus other value-add services, and the company risks > losing all of it for the want of an address. > > > That is what will motivate businesses, That will motivate them to BUY IPv4. It WON'T motivate ANYONE ELSE to SELL the IPv4 they have. Thus if they can't find a seller, they will lose that T1, and the hundred or two other circuits of that customer. On the positive side, when that customer takes all their hundred circuits elsewhere, the company will then have lots of IPv4 freed up! ;-) Ted From ppml at rs.seastrom.com Fri May 8 18:38:56 2009 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Fri, 08 May 2009 18:38:56 -0400 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <20090508181610.GF99433@trace.bind.com> (Aaron Hughes's message of "Fri, 8 May 2009 11:16:10 -0700") References: <20090507205151.GE67888@trace.bind.com> <20090508181610.GF99433@trace.bind.com> Message-ID: <86tz3vgqyn.fsf@seastrom.com> Aaron Hughes writes: > It is entirely unnecessary. The only change that should be made > IMHO is to revert to default 16bit assignments until Jan 1 2010 or > 11 to prevent the 90% return of 32bit ASNs. That should be enough > time to get better vendor support. How about better education *now*? Might get that return rate down substantially if there were some information out there about common platforms and their support for 4-byte ASNs. I asked at the meeting if anyone knew of any "bgp for dummies" style books that talk about 4-byte ASNs and there was not a peep from the audience. Let's FIX that information gap. Concrete steps: 1) ARIN to register fourbyteasn.info or something similar ASAP. 2) Set up mediawiki on same, just like getipv6.info 3) I will contribute my experiences, you can too 4) Make sure that this is referenced prominently in the AS templates or wherever else you go to sign up for an ASN these days. 5) profit I believe a month is a reasonable timeline to have this up and running. -r From tedm at ipinc.net Fri May 8 18:40:23 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 8 May 2009 15:40:23 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revisedandforwarded to the Board In-Reply-To: References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail><81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk><3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com><20090506185019.GA31911@ussenterprise.ufp.org><3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com><4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com><3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com><4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com><3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> <7804282E4E414FBC96FC25D5E4DCB6E8@tedsdesk> Message-ID: <633F32A90B6E41B3A395B1256453FA73@tedsdesk> My phone is the original Moto Q running Windows Mobile 5. Incidentally, I really prefer it over the new Q's because the new Q's don't have a headphone jack anymore, although that's neither here nor there. Anyway, I checked again and your right - but, the phone does get IPv4 dynamically assigned (out of the 99.200.0.0/13 range). Normally, there is no IP address on it. Ted > -----Original Message----- > From: George, Wes E [NTK] [mailto:Wesley.E.George at sprint.com] > Sent: Friday, May 08, 2009 12:06 PM > To: Ted Mittelstaedt > Cc: 'arin ppml' > Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy > -Revisedandforwarded to the Board > > Ted, > > If "my phone" = the aforementioned Moto Q on the Sprint > network, I can say with 100% certainty that you are *not* > doing exclusively IPv6 on your phone today. WinMo6 does > support 6to4 (2002:), and since we're assigning externally > routable IPv4 addresses to our customer devices, it *should* > be able to reach IPv6 addresses via 6to4 even though the > underlying network doesn't support IPv6. It likely even > prefers IPv6 addresses when they're available, but there is > not a standard IPv6 address (2001: or 2600:) being assigned > (yet), and certainly no IPv6-speaking device on Sprint's > network that could seamlessly translate between IPv6 and > IPv4, especially for things like SSH. > I *wish* we were that far along already and that it was > working that well. > > Wes George > > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Friday, May 08, 2009 2:11 PM > To: George, Wes E [NTK]; 'William Herrin'; 'Martin Hannigan' > Cc: 'arin ppml' > Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy > -Revisedandforwarded to the Board > > > To your second point, this isn't really about widgets sitting > > in a warehouse. It's the phone already in your hand. I > heard word that > > we had been asking vendors for IPv6 at least as a roadmap > item in in > > mobile devices for probably 2 years, but not every vendor > was able to > > necessarily deliver, and the ones that did may have had varying > > degrees of success in a complete and functional IPv6 implementation. > > My Sprint Motorola Q that's a few years old is IPv6 > > > The expectation > > is that attrition of old devices will partially solve this > problem by > > creating an installed base that does support IPv6 and (hopefully) > > needs an IPv4 address less often if at all. > > But, depending on how often devices roll over, that may not > reduce the > > IPv4-using population enough either. Even then, that only puts this > > particular application on a par with the rest of the PC-using > > population: IPv6 is supported, but is only useful if we ensure that > > either a) every possible destination our users might go to is > > IPv6-capable or b) that there is some sort of intermediate > device that > > allows an IPv6-only device to reach IPv4-only websites. > > I believe that is how Sprint does it with my phone. > > > I fully expect that there will be classes of devices that can be > > IPv6-only either because they only need to reach IPv6 content or > > because the content that they reach can be proxied through an > > IPv6-to-IPv4 NAT/ALG, but not all devices will fall into that > > category. > > On my phone I have a web browser, e-mail client, SSH client, > FTP client, RSS reader. What else do I need? My phone does > NOT have an IPv4 number on it, this I know from digging into it. > > Ted > > > > This e-mail may contain Sprint Nextel Company proprietary > information intended for the sole use of the recipient(s). > Any use by others is prohibited. If you are not the intended > recipient, please contact the sender and delete all copies of > the message. > > > From tedm at ipinc.net Fri May 8 19:42:06 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 8 May 2009 16:42:06 -0700 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <86tz3vgqyn.fsf@seastrom.com> References: <20090507205151.GE67888@trace.bind.com><20090508181610.GF99433@trace.bind.com> <86tz3vgqyn.fsf@seastrom.com> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Robert E. Seastrom > Sent: Friday, May 08, 2009 3:39 PM > To: Aaron Hughes > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN > Assignments > > > Aaron Hughes writes: > > > It is entirely unnecessary. The only change that should be > made IMHO > > is to revert to default 16bit assignments until Jan 1 2010 or > > 11 to prevent the 90% return of 32bit ASNs. That should be enough > > time to get better vendor support. > > How about better education *now*? Might get that return rate > down substantially if there were some information out there > about common platforms and their support for 4-byte ASNs. I > asked at the meeting if anyone knew of any "bgp for dummies" > style books that talk about 4-byte ASNs and there was not a > peep from the audience. Let's FIX that information gap. > The audience doesn't need to know. At this point all the major router vendors have corrected their ASN handling code so that 4 byte AS numbers are not a problem unless you want to use one yourself. The very last one to get caught was Quagga, which happened a week ago, here's the writeup: http://www.renesys.com/blog/2009/05/byte-me.shtml they patched it in hours and things got back to normal. So, it's understandable that 4 byte ASNs are going to draw blanks, because most people don't NEED to know - they aren't affected by it. If I asked the audience at the meeting if they knew what a downstream O2 sensor in a car did I'd get the same sea of blank faces. The people who need to know are the people requesting ASNs And the problem is that if ARIN asks everyone requesting an AS if they really, really, really, really!!! are sure they can use a 4 byte ASN, because it MIGHT NOT WORK with their gear, why then requestors are simply going to say "fine, then gimmie a 2 byte ASN" and they won't even bother learning anything more about it. Most AS requestors still are not going to be able to use a 32 bit AS number right off the bat. Either they are going to have to update firmware, or they are going to have to replace equipment. If they have a 32 bit AS number in hand from ARIN, and they discover that they have to update firmware to use it, they will have the choice of either having to return the ASN and go through the work again to re-request it, or updating firmware. Most likely they will update firmware because that will be less work. If ARIN tells them in advance that a 16 bit AS will work with everything and a 32 bit AS won't, and all they need to do to get a 16 bit AS is to check the box on the form, well then what do you think they are going to do? Most people will check the box and get the 16 bit AS. Only a few will bother to check and see if they can update firmware to support 32-bit ASNs. The folks who get the 32 bit AS and find out after the fact that they have to replace hardware to use it, will hopefully be mad enough to call their router vendor and scream at them for not releasing a firmware update for their gear. Which, is really what we want - since the router vendors have all had plenty of time to add in support for these, now. Ted From randy at psg.com Sat May 9 02:56:12 2009 From: randy at psg.com (Randy Bush) Date: Sat, 09 May 2009 08:56:12 +0200 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <395570.6547.qm@web63304.mail.re1.yahoo.com> References: <49FF15ED.4070902@arin.net> <49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <3c3e3fca0905061114gc47c897sdf5aa5b9649d3a5f@mail.gmail.com> <20090506185019.GA31911@ussenterprise.ufp.org> <3c3e3fca0905061658g63e79b40m85cf7671aa175dd0@mail.gmail.com> <4607e1d50905062127v67ed6d9fte70d62c12dc54ace@mail.gmail.com> <3c3e3fca0905062141t178d2b82v99dc96a2a455e983@mail.gmail.com> <4607e1d50905062154s458b1695rc1a725613dce4bd9@mail.gmail.com> <3c3e3fca0905062229g42fd0141q95b54690692755c7@mail.gmail.com> <395570.6547.qm@web63304.mail.re1.yahoo.com> Message-ID: > If an organization can use NAT44, they SHOULD. > If an organization can use NAT44, they MUST. if an organization can do anything else, they should avoid nat44 randy From lear at cisco.com Sat May 9 03:22:27 2009 From: lear at cisco.com (Eliot Lear) Date: Sat, 09 May 2009 09:22:27 +0200 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <28E139F46D45AF49A31950F88C497458FFD24E@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458FFD24E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4A052F33.5060107@cisco.com> Michael, The case you describe below will be true in when the addresses are allocated within the enterprise, and when the price is low. When the addresses are unallocated and the price is high, the business case is that there is money that could be used to invest in core business rather than sit in what I presume would be classed a perishable commodity (under the assumption that IPv6 would happen). In the case where the addresses are allocated and the price is high, if you are considering moving to IPv6 and you have such a perishable commodity, if it's a choice of which quarter to make the move, having it be cash neutral or better would be preferred, and so price will have an impact there as well. Bill, Tom, and I described this case as some of the potential positives of a transfer market. Eliot On 5/8/09 9:47 PM, michael.dillon at bt.com wrote: >> If companies hear that they can >> get money for giving up space, many (but not all) of them are >> going to do an inventory and find out what they have but >> don't actually need so that they can cash in. >> > Sorry, but the business world does not work like that. In > order to do any recovery work, you have to make a business > case which involves balancing the costs of the work, versus > the returns from selling the IP addresses and also factor in > the risk that the price will be rather lower than expected, > plus the risks related to potential disruption caused by the > cleanup. > > Earlier you described seeing many cases of sloppiness and > your motive is to provide an incentive to clean up. But did't > you notice that this kind of sloppiness is accepted within > the businesses that you looked at? They've looked at the > full spectrum of activity that they could do, and decided > that some things, although ugly, just don't cause negative > impacts to customers, so it is better to leave well enough > alone. > > This isn't going to change unless it really starts to hit > the bottom line, and that will happen when IANA runs > out of IPv4 addresses and companies have to face up to > the fact that they are unlikely to ever get more addresses > from ARIN, or if they do get more, it will be less than > they need. At that point, something which could cause a > simple T1 install to fail becomes a big risk to the bottom > line because the customer ordering that T1 has a hundred > or two other circuits, plus colo, plus other value-add > services, and the company risks losing all of it for the > want of an address. > > That is what will motivate businesses, not a few paltry > thousands of dollars gained by selling IP address blocks. > > --Michael Dillon > > P.S. I don't doubt that a few businesses will spend some big > cash to buy up addresses and avert catastrophe, but they will > pay big bucks because the supply will be extremely limited. > That will be the end of the IP address market as people realise > that it is not stable, can't be relied on, and that there may > not really be enough available addresses anywhere in the world. > IPv6 will be like an oasis in the desert. End of story. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > From michael.dillon at bt.com Sat May 9 07:20:47 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 9 May 2009 12:20:47 +0100 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revised andforwarded to the Board In-Reply-To: <4F9723132A934DFAAF14305F2D6D857D@tedsdesk> Message-ID: <28E139F46D45AF49A31950F88C497458FFD285@E03MVZ2-UKDY.domain1.systemhost.net> > > This isn't going to change unless it really starts to hit the > > bottom line, and that will happen when IANA runs out of IPv4 > > addresses and companies have to face up to the fact that they > > are unlikely to ever get more addresses from ARIN, or if they > > do get more, it will be less than they need. At that point, > > something which could cause a simple T1 install to fail > > becomes a big risk to the bottom line because the customer > > ordering that T1 has a hundred or two other circuits, plus > > colo, plus other value-add services, and the company risks > > losing all of it for the want of an address. > > > > > > That is what will motivate businesses, > > That will motivate them to BUY IPv4. It WON'T motivate > ANYONE ELSE to SELL the IPv4 they have. That is exactly my point, except that you are to specific when you say "buy IPv4". It will also motivate them to find IPv4 elsewhere in their business, perhaps by cancelling the contract of a customer who is not so profitable. And it will motivate them to get IPv6 out sooner so that low margin customers can go on IPv6 and the IPv4 can be saved for high margin customers who can't use IPv6 services yet. I realise that small businesses often don't have the mix of services to do some of these things, but that just means they are in a more fragile position. If their business can survive without growing the customer base, then that might work for many small businesses. For the rest it is bankruptcy or sell out at fire sale prices. It wouldn't surprise me to see an increase in rollup activity in the next couple of years as ISPs who don't think they can handle the IPv6 transition scramble to sell out. > On the positive side, when that customer takes all their hundred > circuits elsewhere, the company will then have lots of IPv4 > freed up! ;-) That's not positive. Losing a customer to free up IPv4 is only positive when it is a low profit customer that is lost and you do it to save a high profit customer. --Michael Dillon From michael.dillon at bt.com Sat May 9 08:42:24 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 9 May 2009 13:42:24 +0100 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458FFD290@E03MVZ2-UKDY.domain1.systemhost.net> > At this point all the major router vendors have corrected their > ASN handling code so that 4 byte AS numbers are not a problem > unless you want to use one yourself. And they magically updated the software of all their devices deployed out there? I thought not. > If I asked the audience at the meeting if they knew what a > downstream O2 sensor in a car did I'd get the same sea of blank > faces. > > The people who need to know are the people requesting ASNs Sorry, but the world of IP network engineering is far bigger than the in-crowd that hangs out on NANOG or ARIN lists. The fact is that many IP network engineering folks maybe only read Light Reading once a month, or look through the Networkers program once a year when their budget request to attend the conference is denied. And a lot of them don't speak English very well, if at all. > And the problem is that if ARIN asks everyone requesting an > AS if they really, really, really, really!!! are sure they > can use a 4 byte ASN, because it MIGHT NOT WORK with their > gear, why then requestors are simply going to say "fine, > then gimmie a 2 byte ASN" and they won't even bother learning > anything more about it. It would help ARIN if they had a wiki page, even one on the IPv6 wiki, that documented the first software release supporting 4-byte ASNs for every known hardware platform including stuff like Alcatel 7750, Huwaei, etc. > The folks who get the 32 bit AS and find out after the fact that > they have to replace hardware to use it, will hopefully be mad enough > to call their router vendor and scream at them for not releasing > a firmware update for their gear. History shows that instead, they go back to ARIN and say that these chocolate ASNs don't work, please give me a vanilla one. --Michael Dillon From leo.vegoda at icann.org Sat May 9 12:34:00 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Sat, 9 May 2009 09:34:00 -0700 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: Message-ID: On 08/05/2009 4:42, "Ted Mittelstaedt" wrote: [...] > At this point all the major router vendors have corrected their > ASN handling code so that 4 byte AS numbers are not a problem > unless you want to use one yourself. At last week's RIPE meeting, Daniel Karrenberg presented a statistical breakdown of the reasons given when 32-bit ASNs are returned to the RIPE NCC. It was interesting to see that in over 40% of cases the reason(s) given related to the ability of a 3rd party network to cope with big AS Numbers. See slide 4: http://www.ripe.net/ripe/meetings/ripe-58/presentations/uploads//presentatio ns/Wednesday/Address%20Policy%20WG/Karrenberg-ASN32-take-up-report.FFBG.pdf Using the number yourself seems not to be as simple as we had hoped. Regards, Leo Vegoda From lear at cisco.com Mon May 11 11:44:52 2009 From: lear at cisco.com (Eliot Lear) Date: Mon, 11 May 2009 17:44:52 +0200 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revisedandforwarded to the Board In-Reply-To: References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail><81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk><20090507024147.A228E2B21FC@mx5.roble.com><17838240D9A5544AAA5FF95F8D5203160605CC47@ad-exh01.adhost.lan> Message-ID: <4A0847F4.5000307@cisco.com> On 5/7/09 6:31 AM, Ted Mittelstaedt wrote: > Perhaps we need a policy change that states that additional > IPv4 allocation requests from ISP's cannot equal or be smaller > than the amount of unallocated space they already have, > regardless of the 80 percentile rule? > This would, at best, cause a routing table problem, and at worst encourage more lying. Eliot From stephen at sprunk.org Mon May 11 13:27:52 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 11 May 2009 12:27:52 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <28E139F46D45AF49A31950F88C497458FFD24E@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458FFD24E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4A086018.9000106@sprunk.org> michael.dillon at bt.com wrote: >> If companies hear that they can get money for giving up space, many (but not all) of them are going to do an inventory and find out what they have but don't actually need so that they can cash in. >> > > Sorry, but the business world does not work like that. In order to do any recovery work, you have to make a business case which involves balancing the costs of the work, versus the returns from selling the IP addresses and also factor in the risk that the price will be rather lower than expected, plus the risks related to potential disruption caused by the cleanup. > We're actually in agreement here. Obviously, the first step is to determine how much space one could free up and what the cost would be to do so. Then you decide how much money you want for it, and put in your ask in the listing system. If someone buys, you do the work and take the profit; if not, you either keep doing what you've been doing or lower your price. > Earlier you described seeing many cases of sloppiness and your motive is to provide an incentive to clean up. But did't you notice that this kind of sloppiness is accepted within the businesses that you looked at? They've looked at the full spectrum of activity that they could do, and decided that some things, although ugly, just don't cause negative impacts to customers, so it is better to leave well enough alone. > Of course; there will always be a cost/benefit analysis applied. In a free market, though, the price will rise to the point that sufficient supply is available to meet the demand. > P.S. I don't doubt that a few businesses will spend some big cash to buy up addresses and avert catastrophe, but they will pay big bucks because the supply will be extremely limited. That will be the end of the IP address market as people realise that it is not stable, can't be relied on, and that there may not really be enough available addresses anywhere in the world. IPv6 will be like an oasis in the desert. End of story I don't think that there is sufficient data at this time to support (or refute) that theory. I can come up with arguments that there will be a very few but high-dollar sales and others that there will be a lot of low-dollar sales, and I have no clue if they're right -- or if what we'll actually see is the complete failure of the market due to instability or other external factors (e.g. IPv6). _Anyone_ who is sure of what is going to happen is probably wrong, regardless of what they believe. If you have such a great crystal ball, I suggest getting out of tech and investing in lottery tickets instead. 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 kkargel at polartel.com Mon May 11 13:43:14 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 11 May 2009 12:43:14 -0500 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <4A086018.9000106@sprunk.org> References: <28E139F46D45AF49A31950F88C497458FFD24E@E03MVZ2-UKDY.domain1.systemhost.net> <4A086018.9000106@sprunk.org> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B104@mail> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Stephen Sprunk > Sent: Monday, May 11, 2009 12:28 PM > To: michael.dillon at bt.com > Cc: ARIN PPML > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised > andforwarded to the Board > > michael.dillon at bt.com wrote: {SNIP} > _Anyone_ who is sure > of what is going to happen is probably wrong, regardless of what they > believe. If you have such a great crystal ball, I suggest getting out > of tech and investing in lottery tickets instead. > > 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 It doesn't take a crystal ball to see that if you add cost to a product that cost is going to the end user. It also doesn't take a crystal ball to see that if you create a global commodities market that governments are going to take over and govern it. It requires only trivial fortune-telling powers to see that once a (or multiple) government organization(s) take(s) over management of the market that they will tax it to fund the organization(s). With ARIN we (who are ARIN) have some input in steering what the rules are and how things are managed. Governments are smarter than we are and will not need to ask our advice. They know what is best for you even if you don't agree. Governments have committees to figure this stuff out. {smarmy sarcasm here for those of you that didn't notice} Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From tedm at ipinc.net Mon May 11 14:45:05 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 11 May 2009 11:45:05 -0700 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy-Revised andforwarded to the Board In-Reply-To: <28E139F46D45AF49A31950F88C497458FFD285@E03MVZ2-UKDY.domain1.systemhost.net> References: <4F9723132A934DFAAF14305F2D6D857D@tedsdesk> <28E139F46D45AF49A31950F88C497458FFD285@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com > Sent: Saturday, May 09, 2009 4:21 AM > To: ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer > Policy-Revised andforwarded to the Board > > It wouldn't surprise me to see an increase in rollup activity > in the next couple of years as ISPs who don't think they can > handle the IPv6 transition scramble to sell out. > Obtaining more IP numbers from one of your upstreams is always going to be an option. Yes it will be more costly. But if a small ISP that is out of IPv4 and can't get more of it cannot afford to "buy" IPv4 from a transfer market, (likely because the minimum block of IPv4 will be too large for them) they can go to their upstream who can likely afford to buy that large block then split it up. One of the biggest reasons small ISP's get portable numbers is to untie the non-portable numbers handcuffs to allow them to comparison shop from among larger networks. It is perfectly reasonable post-IPv4 runout for an ISP to tell all NEW IPv4 customers that they can still get IPv4 but the ISP can require them to renumber at any time. (such as if they change upstreams) Ted From tedm at ipinc.net Mon May 11 14:59:28 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 11 May 2009 11:59:28 -0700 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: <28E139F46D45AF49A31950F88C497458FFD290@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458FFD290@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com > Sent: Saturday, May 09, 2009 5:42 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN > Assignments > > > Sorry, but the world of IP network engineering is far bigger > than the in-crowd that hangs out on NANOG or ARIN lists. > The fact is that many IP network engineering folks maybe only > read Light Reading once a month, or look through the > Networkers program once a year when their budget request to > attend the conference is denied. And this is a Good Thing? > > And the problem is that if ARIN asks everyone requesting an > AS if they > > really, really, really, really!!! are sure they can use a 4 > byte ASN, > > because it MIGHT NOT WORK with their gear, why then requestors are > > simply going to say "fine, then gimmie a 2 byte ASN" and they won't > > even bother learning anything more about it. > > It would help ARIN if they had a wiki page, even one on the > IPv6 wiki, that documented the first software release > supporting 4-byte ASNs for every known hardware platform > including stuff like Alcatel 7750, Huwaei, etc. > I'd agree with that as long as at the very top of it was a large red warning that anyone running BGP and their own AS number, whether 2 byte or 4 byte, MUST be running current firmware, since there are other bugs besides the lack of 4-byte AS support that have been closed by many router vendors. Ted From tedm at ipinc.net Mon May 11 15:13:16 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 11 May 2009 12:13:16 -0700 Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments In-Reply-To: References: Message-ID: <909552C16A984AE4BC9EB458E8566D9B@tedsdesk> > -----Original Message----- > From: Leo Vegoda [mailto:leo.vegoda at icann.org] > Sent: Saturday, May 09, 2009 9:34 AM > To: Ted Mittelstaedt; Robert E. Seastrom; Aaron Hughes > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN > Assignments > > On 08/05/2009 4:42, "Ted Mittelstaedt" wrote: > > [...] > > > At this point all the major router vendors have corrected their ASN > > handling code so that 4 byte AS numbers are not a problem > unless you > > want to use one yourself. > > At last week's RIPE meeting, Daniel Karrenberg presented a > statistical breakdown of the reasons given when 32-bit ASNs > are returned to the RIPE NCC. It was interesting to see that > in over 40% of cases the reason(s) given related to the > ability of a 3rd party network to cope with big AS Numbers. > See slide 4: > > http://www.ripe.net/ripe/meetings/ripe-58/presentations/upload > s//presentatio > ns/Wednesday/Address%20Policy%20WG/Karrenberg-ASN32-take-up-re > port.FFBG.pdf > > Using the number yourself seems not to be as simple as we had hoped. > I guess what I think is if your paying an upstream provider for connectivity that if your going to use a 32-bit ASN that they damn well better support it, there's plenty of other upstream providers out there. That 22% figure is surprising. What is good to read, though, is that 73% of the requests were for 2-byte ASNs from the start, which means that the majority of admins requesting them ARE cognisant of the differences, and are simply making the economically smart choice of selecting a 2 byte ASN because it's available, rather than replacing/updating hardware. So I don't think more education here is going to help, much. This is just one of those things that is going to happen exactly like what happens when a community rations gasoline because it's in short supply. The people with a lot of money buy fuel-sipping cars and the fuel shortage is a mere inconvenience to them. The poor people end up doing a lot less driving of their gas-hogs and suffer a lot of disruption in their lives as a result. Ted From martin.hannigan at batelnet.bs Thu May 14 08:33:46 2009 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Thu, 14 May 2009 08:33:46 -0400 Subject: [arin-ppml] Will the price per IP really be affected by the transfer market introduced in 2009-1? In-Reply-To: <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> Message-ID: <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> On Fri, May 8, 2009 at 5:44 PM, Ted Mittelstaedt wrote: > > Ah, but your point is dependent on how an ISP views it's market. > [ snip ] > If transfer pricing does not rise high enough to make it worthwhile > for orgs to spend the money to renumber out of it, then the > orgs won't, and the transfer market will never come into > existence. The transfer market already exists. > Thus, let me put my original question a bit differently. ?How much > of an increase for IPv4 can YOU absorb? ?How much do you think > your competitors can absorb? ?How much do you think the industry > can absorb? ?If it's not a large amount, then how exactly will > a transfer market in IPv4 reach critical mass to enable it to > get started? You wouldn't "absorb" anything. If you spent(cost) $10K per month leasing IPv4 address space and that could be correlated to a return on the expense (growth, revenue), where is the problem? Best, Martin From kkargel at polartel.com Thu May 14 11:09:30 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 14 May 2009 10:09:30 -0500 Subject: [arin-ppml] Will the price per IP really be affected by thetransfer market introduced in 2009-1? In-Reply-To: <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> References: <4A048640.1080302@gmail.com><58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B218@mail> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Martin Hannigan > Sent: Thursday, May 14, 2009 7:34 AM > To: ARIN PPML > Subject: Re: [arin-ppml] Will the price per IP really be affected by > thetransfer market introduced in 2009-1? > > On Fri, May 8, 2009 at 5:44 PM, Ted Mittelstaedt wrote: > > > > Ah, but your point is dependent on how an ISP views it's market. > > > > [ snip ] > > > If transfer pricing does not rise high enough to make it worthwhile > > for orgs to spend the money to renumber out of it, then the > > orgs won't, and the transfer market will never come into > > existence. > > The transfer market already exists. The sanctioned transfer market does not exist. How many IP's did you buy in a "transfer market" this year? How many eBay auctions for netblocks have you seen? > > > Thus, let me put my original question a bit differently. ?How much > > of an increase for IPv4 can YOU absorb? ?How much do you think > > your competitors can absorb? ?How much do you think the industry > > can absorb? ?If it's not a large amount, then how exactly will > > a transfer market in IPv4 reach critical mass to enable it to > > get started? > > > You wouldn't "absorb" anything. If you spent(cost) $10K per month > leasing IPv4 address space and that could be correlated to a return on > the expense (growth, revenue), where is the problem? Of course you won't "absorb" anything.. the cost will be passed to the end user. That doesn't make it right. > > Best, > > Martin > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 martin.hannigan at batelnet.bs Thu May 14 13:10:44 2009 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Thu, 14 May 2009 13:10:44 -0400 Subject: [arin-ppml] Will the price per IP really be affected by thetransfer market introduced in 2009-1? In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B218@mail> References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B218@mail> Message-ID: <4607e1d50905141010x770b51e7ibec433a226081a99@mail.gmail.com> On Thu, May 14, 2009 at 11:09 AM, Kevin Kargel wrote: > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Martin Hannigan >> Sent: Thursday, May 14, 2009 7:34 AM >> To: ARIN PPML >> Subject: Re: [arin-ppml] Will the price per IP really be affected by >> thetransfer market introduced in 2009-1? >> >> On Fri, May 8, 2009 at 5:44 PM, Ted Mittelstaedt wrote: >> > >> > Ah, but your point is dependent on how an ISP views it's market. >> > >> >> [ snip ] >> >> > If transfer pricing does not rise high enough to make it worthwhile >> > for orgs to spend the money to renumber out of it, then the >> > orgs won't, and the transfer market will never come into >> > existence. >> >> The transfer market already exists. > > The sanctioned transfer market does not exist. ?How many IP's did you buy in > a "transfer market" this year? ?How many eBay auctions for netblocks have > you seen? We didn't all choose the blue pill, Kevin. >> > Thus, let me put my original question a bit differently. ?How much >> > of an increase for IPv4 can YOU absorb? ?How much do you think >> > your competitors can absorb? ?How much do you think the industry >> > can absorb? ?If it's not a large amount, then how exactly will >> > a transfer market in IPv4 reach critical mass to enable it to >> > get started? >> >> >> You wouldn't ?"absorb" anything. If you spent(cost) $10K per month >> leasing IPv4 address space and that could be correlated to a return on >> the expense (growth, revenue), where is the problem? > > Of course you won't "absorb" anything.. ?the cost will be passed to the end > user. ?That doesn't make it right. You should explain how that works to Ted. Best, Martin From tedm at ipinc.net Thu May 14 13:14:28 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 14 May 2009 10:14:28 -0700 Subject: [arin-ppml] Will the price per IP really be affected by thetransfer market introduced in 2009-1? In-Reply-To: <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> References: <4A048640.1080302@gmail.com><58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan > Sent: Thursday, May 14, 2009 5:34 AM > To: ARIN PPML > Subject: Re: [arin-ppml] Will the price per IP really be > affected by thetransfer market introduced in 2009-1? > > On Fri, May 8, 2009 at 5:44 PM, Ted Mittelstaedt > wrote: > > > > Ah, but your point is dependent on how an ISP views it's market. > > > > [ snip ] > > > If transfer pricing does not rise high enough to make it worthwhile > > for orgs to spend the money to renumber out of it, then the orgs > > won't, and the transfer market will never come into existence. > > The transfer market already exists. > That statement exhibits the fallacy of petitio principii and doesn't even justify a response. > > Thus, let me put my original question a bit differently. ? > How much of > > an increase for IPv4 can YOU absorb? ?How much do you think your > > competitors can absorb? ?How much do you think the industry can > > absorb? ?If it's not a large amount, then how exactly will > a transfer > > market in IPv4 reach critical mass to enable it to get started? > > > You wouldn't "absorb" anything. If you spent(cost) $10K per > month leasing IPv4 address space and that could be correlated > to a return on the expense (growth, revenue), A transfer market, as we have been discussing here, isn't "monthly leasing" I am not sure where your getting this idea from. What 2009-1 states is essentially that after ARIN cannot assign IPv4 from it's pool anymore, that if you want IPv4 you can pay a "directed donation" cost. This cost is ON TOP OF what you pay ARIN. The transfer market is a fantastic thing for ARIN, as a matter of fact, from a financial standpoint. The reason why is you will have Legacy holders who aren't currently paying a yearly renewal fee for their numbers "selling" some of their holdings to recipients. These recipients will have to pay a yearly renewal fee to ARIN to retain the blocks. Thus, moving IPv4 space that currently ISN'T paying ARIN ANYTHING, into IPv4 space that IS paying ARIN a renewal. This is probably why the Board is pushing it. And on top of that, the recipient ISP of the transfer, has to pay a "transfer fee" that is over and above the ARIN registration and renewal fees. > where is the problem? > Let me illustrate with an example. Suppose it is 2014 and ARIN ran out of IPv4 2 years ago. You now need more IPv4. You pay a million dollars to a legacy holder for a /20 of IPv4 AND ON TOP OF THAT you start paying ARIN the one-time registration fee as well as the yearly renewal. That one-time transfer payment of a million dollars must be paid off somehow. So you have to spread it over the cost of all the new customers your going to bring on to it, for as long a your going to be using that block. The problem is IPv4 is rapidly disappearing and being replaced by IPv6. You are positive that by 5 years later, that IPv6 will be far enough along that you yourself won't need a lot of your IPv4 holdings. Of course by then since there will be a surplus, you won't be able to re-sell that IPv4 block you bought. So your basically now going to have to pay $200K a year for 5 years to make up that million dollars you paid for the IPv4 block. How are you going to pay it? Well you can raise rates - but as long as your competing against other ISPs who aren't out of IPv4, you won't get customers to fill that block up that you bought. To put it another way, if I "invest" today in 10 pounds of gold for $10,000, I am not going to make money by cutting the gold into 1 pound blocks and selling 1 block of gold every year for the next decade for $800 per block. My question to you is NOT from a theoretical standpoint, but from your own experiences with your company. From the ISP's perspective I work for, a transfer fee of any significance would not pencil out UNLESS the expected future usable lifetime of the IPv4 was literally decades. The only networks I can see where it would are captive networks. For example, a college university network where they make a central command-and-control decision to make IPv4 available to students in the dorm, and the costs are put into the student housing, so the students pay for the IPv4 whether they need IPv4 or not. Ted From tedm at ipinc.net Thu May 14 13:25:16 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 14 May 2009 10:25:16 -0700 Subject: [arin-ppml] Will the price per IP really be affected bythetransfer market introduced in 2009-1? In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B218@mail> References: <4A048640.1080302@gmail.com><58327061AE7A42B5A8058DC3BF3A309F@tedsdesk><4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B218@mail> Message-ID: <0ABC4DC32E31405BAE79D2B72BD059FC@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel > Sent: Thursday, May 14, 2009 8:10 AM > To: Martin Hannigan; ARIN PPML > Subject: Re: [arin-ppml] Will the price per IP really be > affected bythetransfer market introduced in 2009-1? > > > Of course you won't "absorb" anything.. the cost will be > passed to the end user. That is NOT AUTOMATICALLY TRUE. Can you raise your prices today by a dollar a month per customer? Don't you think you would suffer increased customer loss to a competitor who DIDN'T raise their prices? It is sheer mental laziness to assume that just because we jack up costs at the head of the pipeline that costs will rise at all the spigots. Unfortunately, it appears that a lot of people are just automatically ASS-YOU-Meing this to be true, and using that as a justification for pushing a transfer market. The fact is that if a transfer market ever really did pick up, that it could have the potential to greatly extend the production lifespan of IPv4. If that happened, in markets with a lot of competition, some ISP's would be driven out of business, who hadn't planned ahead. Worse, ISP's who did see this coming would be under tremendous pressure to game the system RIGHT NOW so as to bulk up their IPv4 holdings. A transfer market is a very dangerous tool. If we implement it well, it will assist in smoothing the IPv6 transition and assist the small fry who have no leverage to pressure IPv6 uptake. If we screw it up, it will greatly prolong and draw-out IPv6 uptake, and severely damage those ISP's who have no ability to corner their markets or pressure IPv6 adoption. Ted From kkargel at polartel.com Thu May 14 13:37:48 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 14 May 2009 12:37:48 -0500 Subject: [arin-ppml] Will the price per IP really be affected by thetransfer market introduced in 2009-1? In-Reply-To: <4607e1d50905141010x770b51e7ibec433a226081a99@mail.gmail.com> References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B218@mail> <4607e1d50905141010x770b51e7ibec433a226081a99@mail.gmail.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B21D@mail> > -----Original Message----- > From: Martin Hannigan [mailto:martin.hannigan at batelnet.bs] > Sent: Thursday, May 14, 2009 12:11 PM > To: Kevin Kargel > Cc: ARIN PPML > Subject: Re: [arin-ppml] Will the price per IP really be affected by > thetransfer market introduced in 2009-1? > > On Thu, May 14, 2009 at 11:09 AM, Kevin Kargel > wrote: > > {snip} > >> > >> The transfer market already exists. > > > > The sanctioned transfer market does not exist. ?How many IP's did you > buy in > > a "transfer market" this year? ?How many eBay auctions for netblocks > have > > you seen? > > > We didn't all choose the blue pill, Kevin. Blue pill schmue pill.. There is no sanctioned IP market today. > > {snip} > > Of course you won't "absorb" anything.. ?the cost will be passed to the > end > > user. ?That doesn't make it right. > > > You should explain how that works to Ted. > > Best, > > Martin I think Ted understands it. He also understands that if you are in competition with a company that doesn't carry the added burden then you need to find a way to cover the cost. So if you and ISP"B" are in competition, and you are both selling DSL to 100,000 subs at $19.95/month, and you run out of IP space and pay $1mill for more IPv4 and ISP"B" doesn't, how are you going to compete with ISP"B"? Is the extra $10/sub going to cause you to raise your rates? If you amortize the increase over 5 years and raise your DSL rates to $21.95 (gross oversimplification) do you think you are going to lose business to your competition who is still offering DSL at $19.95? Or are you going to choose to make $2/sub less profit than ISP"B"? If you do that are you going to be able to keep up with ISP"B" technologically and offer the same or better services than they do? Are your customers going to notice? Is ISP"B" going to notice and mount an advertising campaign? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From martin.hannigan at batelnet.bs Thu May 14 13:38:43 2009 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Thu, 14 May 2009 13:38:43 -0400 Subject: [arin-ppml] Will the price per IP really be affected by thetransfer market introduced in 2009-1? In-Reply-To: References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> Message-ID: <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com> On Thu, May 14, 2009 at 1:14 PM, Ted Mittelstaedt wrote: > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan >> Sent: Thursday, May 14, 2009 5:34 AM >> To: ARIN PPML >> Subject: Re: [arin-ppml] Will the price per IP really be >> affected by thetransfer market introduced in 2009-1? >> >> On Fri, May 8, 2009 at 5:44 PM, Ted Mittelstaedt >> wrote: >> > >> > Ah, but your point is dependent on how an ISP views it's market. >> > >> >> [ snip ] >> >> > If transfer pricing does not rise high enough to make it worthwhile >> > for orgs to spend the money to renumber out of it, then the orgs >> > won't, and the transfer market will never come into existence. >> >> The transfer market already exists. >> > > That statement exhibits the fallacy of petitio principii and doesn't even > justify a response. > And that one exhibits a clear lack of knowledge as to what's actually occurring outside of ARIN today. There is documented proof of a 'transfer' market. There are not many people denying it these days. >> > Thus, let me put my original question a bit differently. >> How much of >> > an increase for IPv4 can YOU absorb? ?How much do you think your >> > competitors can absorb? ?How much do you think the industry can >> > absorb? ?If it's not a large amount, then how exactly will >> a transfer >> > market in IPv4 reach critical mass to enable it to get started? >> >> >> You wouldn't ?"absorb" anything. If you spent(cost) $10K per >> month leasing IPv4 address space and that could be correlated >> to a return on the expense (growth, revenue), > > A transfer market, as we have been discussing here, isn't "monthly leasing" > I am not sure where your getting this idea from. The PPML discussion (by some) demonstrates how broken that "transfer" process is and leasing is one of many methods to exploit that process. I take my /8, I carve it up into /16's to be a good net.citizen, I allocate (lease) them myself passing LOA Are you actually saying that there are no markets operating and that the circumventions being described won't/don't, or are you simply playing word games with me to elongate the thread? Best, Martin From DPinkard at accessline.com Thu May 14 13:34:28 2009 From: DPinkard at accessline.com (Dan Pinkard) Date: Thu, 14 May 2009 10:34:28 -0700 Subject: [arin-ppml] Will the price per IP really be affected bythetransfer market introduced in 2009-1? In-Reply-To: <0ABC4DC32E31405BAE79D2B72BD059FC@tedsdesk> References: <4A048640.1080302@gmail.com><58327061AE7A42B5A8058DC3BF3A309F@tedsdesk><4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B218@mail> <0ABC4DC32E31405BAE79D2B72BD059FC@tedsdesk> Message-ID: Like "we'll help you transfer space only if you've implemented IPv6?" -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Thursday, May 14, 2009 10:25 AM To: 'Kevin Kargel'; 'Martin Hannigan'; 'ARIN PPML' Subject: Re: [arin-ppml] Will the price per IP really be affected bythetransfer market introduced in 2009-1? <....> A transfer market is a very dangerous tool. If we implement it well, it will assist in smoothing the IPv6 transition and assist the small fry who have no leverage to pressure IPv6 uptake. If we screw it up, it will greatly prolong and draw-out IPv6 uptake, and severely damage those ISP's who have no ability to corner their markets or pressure IPv6 adoption. Ted _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From spiffnolee at yahoo.com Thu May 14 13:55:14 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Thu, 14 May 2009 10:55:14 -0700 (PDT) Subject: [arin-ppml] Will the price per IP really be affected bythetransfer market introduced in 2009-1? In-Reply-To: <0ABC4DC32E31405BAE79D2B72BD059FC@tedsdesk> References: <4A048640.1080302@gmail.com><58327061AE7A42B5A8058DC3BF3A309F@tedsdesk><4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B218@mail> <0ABC4DC32E31405BAE79D2B72BD059FC@tedsdesk> Message-ID: <235889.30639.qm@web63301.mail.re1.yahoo.com> > > Of course you won't "absorb" anything.. the cost will be > > passed to the end user. > > That is NOT AUTOMATICALLY TRUE. Can you raise your prices today by > a dollar a month per customer? Don't you think you would suffer > increased customer loss to a competitor who DIDN'T raise their prices? Can someone remind me of the point of this thread? We each have to make our own decisions about how (and whether) to prepare for IANA to allocate its last address blocks. We might make different decisions. And it also turns out that agreeing ahead of time how we'll all set pricing is against the law. IANAL, YMMV, past performance is no indicator of future returns, operator not responsible for lost articles, liber sum, semper ubi sub ubi, and to the fairest: petitio principia discordia. Lee From tedm at ipinc.net Thu May 14 14:55:51 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 14 May 2009 11:55:51 -0700 Subject: [arin-ppml] Will the price per IP really be affected bythetransfer market introduced in 2009-1? In-Reply-To: <235889.30639.qm@web63301.mail.re1.yahoo.com> References: <4A048640.1080302@gmail.com><58327061AE7A42B5A8058DC3BF3A309F@tedsdesk><4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B218@mail> <0ABC4DC32E31405BAE79D2B72BD059FC@tedsdesk> <235889.30639.qm@web63301.mail.re1.yahoo.com> Message-ID: > -----Original Message----- > From: Lee Howard [mailto:spiffnolee at yahoo.com] > Sent: Thursday, May 14, 2009 10:55 AM > To: Ted Mittelstaedt; Kevin Kargel; Martin Hannigan; ARIN PPML > Subject: Re: [arin-ppml] Will the price per IP really be > affected bythetransfer market introduced in 2009-1? > > > > > > Of course you won't "absorb" anything.. the cost will be > passed to > > > the end user. > > > > That is NOT AUTOMATICALLY TRUE. Can you raise your prices > today by a > > dollar a month per customer? Don't you think you would suffer > > increased customer loss to a competitor who DIDN'T raise > their prices? > > Can someone remind me of the point of this thread? Lee, your going to have to accept the fact that ANYTHING that is posted on this mailing list that is even remotely related to a transfer market is going to be hijacked for the ongoing argument over HAVING a transfer market. 2009-1 was shoved down our throats it was not arrived at by consensus, the issue is BY NO MEANS solved. > We each have to make our own decisions about how (and > whether) to prepare for IANA to allocate its last address > blocks. We might make different decisions. However, ARIN has only 1 response. We can all have different opinions yet still work together to create a compromise response. That DID NOT HAPPEN with 2009-1. Until the rupture that was created over the "emergency provision" use is addressed during the next round of NRPM policy proposals, some people are going to be a bit raw about this - and they are going to vent. You need to allow them to do it and if that bothers you then go bitch to the Board for creating the problem. Frankly, I think most people are deleting the posts on this thread by now, so really, isn't it more convenient for the rest of the list to have all the radicals confined to a few threads? ;-) > And it also > turns out that agreeing ahead of time how we'll all set > pricing is against the law. I know that. I don't claim everyone else does, but certainly a lot of people do. I also know that the rules that a transfer market operates by will affect pricing. Not set, but definitely affect. Ted From tedm at ipinc.net Thu May 14 15:01:12 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 14 May 2009 12:01:12 -0700 Subject: [arin-ppml] Will the price per IP really be affected by thetransfer market introduced in 2009-1? In-Reply-To: <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com> References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com> Message-ID: <75947E4ED9DB4123883FE407C515BC79@tedsdesk> > -----Original Message----- > From: Martin Hannigan [mailto:martin.hannigan at batelnet.bs] > Sent: Thursday, May 14, 2009 10:39 AM > To: Ted Mittelstaedt > Cc: ARIN PPML > Subject: Re: [arin-ppml] Will the price per IP really be > affected by thetransfer market introduced in 2009-1? > > > > > > A transfer market, as we have been discussing here, isn't > "monthly leasing" > > I am not sure where your getting this idea from. > > The PPML discussion (by some) demonstrates how broken that "transfer" > process is and leasing is one of many methods to exploit that process. > I take my /8, I carve it up into /16's to be a good > net.citizen, I allocate (lease) them myself passing LOA > Why is this "broken" It is stated several times in the NRPM that if you are small and cannot justify a large block that you need to go to an upstram ISP and obtain your IP addresses from them, NOT ARIN! The only difference between your ISP A "leasing" of it's /16's and some other ISP B "leasing" of it's /16's, is that your ISP A is too stupid to require it's "lessors" to buy Internet connectivity from it, as a condition of obtaining their /16 so your ISP A is cutting itself out of most of the profits it could make. But hey, if ISP's want to be stupid, why should ARIN make policy to prevent it? > Are you actually saying that there are no markets operating > and that the circumventions being described won't/don't, or > are you simply playing word games with me to elongate the thread? > Martin, there is ONLY ONE justification for supporting a transfer market in ARIN policy. That is, to pull UNUSED IPv4 out of storage and have someone use it. It is NOT so that someone can make a pile of money. That may or may not happen, it may or may not have bad side effects. It is to get the unused IPv4 in use. If that unused IPv4 is ALREADY being used by people who to use your terminology "lease" out (ie: give away most of the potential profit they can make off having those numbers) then there is NO need for a transfer market in the first place, because the IPv4 IS BEING USED. The important thing is usage. This is why if prices go out of sight in a transfer market, it fundamentally undercuts the entire reason for allowing transfers in the first place. Since what happens is now few people can afford it so the "sellers" just end up sitting on what they have, waiting for that once-in-a-blue-moon spectacular sale they can make a killing on. That ties up the IPv4 and we are right back where we started. Ted From schnizlein at isoc.org Thu May 14 15:33:24 2009 From: schnizlein at isoc.org (John Schnizlein) Date: Thu, 14 May 2009 15:33:24 -0400 Subject: [arin-ppml] Will the price per IP really be affected by thetransfer market introduced in 2009-1? In-Reply-To: <75947E4ED9DB4123883FE407C515BC79@tedsdesk> References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com> <75947E4ED9DB4123883FE407C515BC79@tedsdesk> Message-ID: Some of us think the primary issue is the registration of transfers, not the market. Any market should be separate from the registration function. Phrases that glom these distinct operations together, such as "supporting a transfer market", are not helpful, but provocative. On 2009May14, at 3:01 PM, Ted Mittelstaedt wrote: > Martin, there is ONLY ONE justification for supporting a transfer > market in > ARIN policy. That is, to pull UNUSED IPv4 out of storage and have > someone > use it. > > It is NOT so that someone can make a pile of money. That may or may > not > happen, it may or may not have bad side effects. It is to get the > unused > IPv4 in use. An advantage of markets for scarce IPv4 address space is that it makes tangible and explicit the financial advantage of converting networks to IPv6. Incentives to deploy IPv6 are needed because it has not happened and needs to because we really are running out of IPv4 addresses. If an operator can convert to IPv6 early enough to get a good price for IPv4 addresses, that encourages early adoption because once IPv6 is commonplace IPv4 addresses will have no value. John From jmaimon at chl.com Thu May 14 15:43:22 2009 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 14 May 2009 15:43:22 -0400 Subject: [arin-ppml] Will the price per IP really be affected by thetransfer market introduced in 2009-1? In-Reply-To: <75947E4ED9DB4123883FE407C515BC79@tedsdesk> References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com> <75947E4ED9DB4123883FE407C515BC79@tedsdesk> Message-ID: <4A0C745A.8000600@chl.com> Ted Mittelstaedt wrote: > That is, to pull UNUSED IPv4 out of storage and have someone > use it. Agreed. To address inefficiency. > This is why if prices go out of sight > in a transfer market, it fundamentally undercuts the entire reason > for allowing transfers in the first place. Economics invisible hand solves this problem (and more) all the time. > Since what happens is > now few people can afford it so the "sellers" just end up sitting on How does this work in any competition based market system? Sellers must sell just as buyers must buy, and a seller who wants to sell will need to do so at a price both can agree on. Otherwise they arent making any money, and they will lose sales to the first person who will lower prices to make the sale. > what they have, waiting for that once-in-a-blue-moon spectacular sale > they can make a killing on. When it comes to ipv4, there is an inherent correction to spiraling prices of ipv4 due to any activity, including speculation, aside from all market theories and mechanisms. IPv6 migration and the resulting over-abundance of ipv4. If ipv4 costs too much, for any reason, than ipv6 looks very attractive in comparison. From an economic perspective, thats a win-win situation. ipv4 is more efficiently utilized and/or migration to ipv6 now has financial incentive and reward. The only concern regarding transfer systems that has resonated with me to date is government may seize the opportunity to exert control over this arena, a risk increased by any appearance of similarity to currently regulated markets. However, this same risk would only grow if or when ipv4 shortage becomes a world wide front page issue, full of op-eds that there should be a market (or worse), perhaps government controlled. Damned if you do, damned more if you dont. The only way out is if one can state with a certainty that runout and ipv6 migration will be seamless and painless and almost no-one who can will notice or care enough to try to do anything about it. I am not ready to lay good odds on that. Joe From tedm at ipinc.net Thu May 14 16:05:39 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 14 May 2009 13:05:39 -0700 Subject: [arin-ppml] Will the price per IP really be affected by thetransfer market introduced in 2009-1? In-Reply-To: <4A0C745A.8000600@chl.com> References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com> <75947E4ED9DB4123883FE407C515BC79@tedsdesk> <4A0C745A.8000600@chl.com> Message-ID: <59A3F92E3755441DB4320EF6B8BE0AB4@tedsdesk> > -----Original Message----- > From: Joe Maimon [mailto:jmaimon at chl.com] > Sent: Thursday, May 14, 2009 12:43 PM > To: Ted Mittelstaedt > Cc: 'Martin Hannigan'; 'ARIN PPML' > Subject: Re: [arin-ppml] Will the price per IP really be > affected by thetransfer market introduced in 2009-1? > > > > How does this work in any competition based market system? > > Sellers must sell just as buyers must buy, and a seller who > wants to sell will need to do so at a price both can agree on. > > Otherwise they arent making any money, and they will lose > sales to the first person who will lower prices to make the sale. > That only works in a commodity market. Many markets do not work this way. For example, housing. Many many people right now are sitting on homes and NOT selling even though they are still having to pay mortgages on them on loans that they are underwater on, because they HOPE that prices will rise. You can argue that home markets are not competitive - well that's not true since home values are lowered by lowering values on nearby homes. But even though they are competitive, they still do not act like the Adam Smith ideal of capitalism. There are many many examples of people who could have short-sold a second home and walked away with a minor capital gains penalty, but due to a refusal to countenence taking a loss, gambled and ended up in foreclosure and bankruptcy and lost their primary home too. > > what they have, waiting for that once-in-a-blue-moon > spectacular sale > > they can make a killing on. > > When it comes to ipv4, there is an inherent correction to > spiraling prices of ipv4 due to any activity, including > speculation, aside from all market theories and mechanisms. > > IPv6 migration and the resulting over-abundance of ipv4. > > If ipv4 costs too much, for any reason, than ipv6 looks very > attractive in comparison. > > From an economic perspective, thats a win-win situation. > ipv4 is more efficiently utilized and/or migration to ipv6 > now has financial incentive and reward. > It is way too early to know if the IPv4 market will act like, for example, the market for milk, which does meet your ideal, or it will act like the market for housing (which right now meets nobody's ideal) > The only concern regarding transfer systems that has > resonated with me to date is government may seize the > opportunity to exert control over this arena, a risk > increased by any appearance of similarity to currently > regulated markets. > > However, this same risk would only grow if or when ipv4 > shortage becomes a world wide front page issue, full of > op-eds that there should be a market (or worse), perhaps > government controlled. > > Damned if you do, damned more if you dont. > > The only way out is if one can state with a certainty that runout and > ipv6 migration will be seamless and painless and almost > no-one who can will notice or care enough to try to do > anything about it. I am not ready to lay good odds on that. > No migration is painless. The 64-bit question is whether allowing a transfer market makes a bad situation worse. Ted From jmaimon at chl.com Thu May 14 16:54:08 2009 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 14 May 2009 16:54:08 -0400 Subject: [arin-ppml] Will the price per IP really be affected by thetransfer market introduced in 2009-1? In-Reply-To: <59A3F92E3755441DB4320EF6B8BE0AB4@tedsdesk> References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com> <75947E4ED9DB4123883FE407C515BC79@tedsdesk> <4A0C745A.8000600@chl.com> <59A3F92E3755441DB4320EF6B8BE0AB4@tedsdesk> Message-ID: <4A0C84F0.9030202@chl.com> Ted Mittelstaedt wrote: > That only works in a commodity market. All markets have an affinity to work that way. > Many markets do not work this > way. Many markets have externalities that attempt to prevent them from working this way. > For example, housing. Many many people right now are sitting on > homes and NOT selling even though they are still having to pay mortgages > on them on loans that they are underwater on, because they HOPE that > prices will rise. > Market forces tend to prevail in the short term. In the long term, market forces inevitably win. Home prices go down, people sell, people buy, home prices go up. In fact the longer you interfere with the market, the worse your comeuppance is at correction time. That is my interpretation of the events in the U.S housing market. > You can argue that home markets are not competitive - well that's not > true since home values are lowered by lowering values on nearby homes. > But even though they are competitive, they still do not act like the > Adam Smith ideal of capitalism. > Sure they do, but nobody ever says the road to pareto efficiency isnt bumpy. > There are many many examples of people who could have short-sold > a second home and walked away with a minor capital gains penalty, > but due to a refusal to countenence taking a loss, gambled and ended > up in foreclosure and bankruptcy and lost their primary home too. > And that is good news to buyers. And your example disproves your own thesis namely, that price can be held artificially high for extended periods of time. Joe From tedm at ipinc.net Thu May 14 17:04:09 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 14 May 2009 14:04:09 -0700 Subject: [arin-ppml] Will the price per IP really be affected by thetransfer market introduced in 2009-1? In-Reply-To: <4A0C84F0.9030202@chl.com> References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com> <75947E4ED9DB4123883FE407C515BC79@tedsdesk> <4A0C745A.8000600@chl.com> <59A3F92E3755441DB4320EF6B8BE0AB4@tedsdesk> <4A0C84F0.9030202@chl.com> Message-ID: > -----Original Message----- > From: Joe Maimon [mailto:jmaimon at chl.com] > Sent: Thursday, May 14, 2009 1:54 PM > To: Ted Mittelstaedt > Cc: 'Martin Hannigan'; 'ARIN PPML' > Subject: Re: [arin-ppml] Will the price per IP really be > affected by thetransfer market introduced in 2009-1? > > > > > Sure they do, but nobody ever says the road to pareto > efficiency isnt bumpy. > > There are many many examples of people who could have short-sold a > > second home and walked away with a minor capital gains penalty, but > > due to a refusal to countenence taking a loss, gambled and > ended up in > > foreclosure and bankruptcy and lost their primary home too. > > > And that is good news to buyers. And your example disproves > your own thesis namely, that price can be held artificially > high for extended periods of time. > Come again? I'd call sitting on a home for 2 years instead of selling it 6 months later a prime example of holding a price artifically high for an extended period of time. Hopefully that doen't happen with IPv4. I don't say though that I believe the idea that the more you interefere the worse the comeuppance is at correction time. The US financial sector is a prime example of an industry with very little interference and terrible comeuppances at correction time, just ask Benie Madoff Ted From michael.dillon at bt.com Fri May 15 04:51:45 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 15 May 2009 09:51:45 +0100 Subject: [arin-ppml] Will the price per IP really be affected bythetransfer market introduced in 2009-1? In-Reply-To: <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C497458012140AE@E03MVZ2-UKDY.domain1.systemhost.net> > And that one exhibits a clear lack of knowledge as to what's > actually occurring outside of ARIN today. There is documented > proof of a 'transfer' market. There are not many people > denying it these days. Occasional sales of a block of IP addresses do not constitute a market. I remember this happening back in 1997 and I don't see any evidence that the volume of transfers has gone up since then. To call it a market, you need to have a certain amount of openness/availability and you need reasonably frequent transactions or liquidity. > The PPML discussion (by some) demonstrates how broken that "transfer" > process is and leasing is one of many methods to exploit that process. > I take my /8, I carve it up into /16's to be a good > net.citizen, I allocate (lease) them myself passing LOA Leasing is a gamble, because if you sell a block, you get your money up front and if IPv6 deploys quickly, your buyer is the loser. But if you lease the block, then you lose when IPv6 jumps into the scene. The smart money is going to avoid this whole wild west scene and beaver away on their IPv6 deployments, clean up their IP address records, and prepare for the financial hit that may occur when they wade through the chaos of the early days of widespread IPv6 deployment. --Michael Dillon From kkargel at polartel.com Fri May 15 11:28:55 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 15 May 2009 10:28:55 -0500 Subject: [arin-ppml] Will the price per IP really be affected bythetransfer market introduced in 2009-1? In-Reply-To: <235889.30639.qm@web63301.mail.re1.yahoo.com> References: <4A048640.1080302@gmail.com><58327061AE7A42B5A8058DC3BF3A309F@tedsdesk><4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B218@mail> <0ABC4DC32E31405BAE79D2B72BD059FC@tedsdesk> <235889.30639.qm@web63301.mail.re1.yahoo.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B221@mail> > -----Original Message----- > From: Lee Howard [mailto:spiffnolee at yahoo.com] > Sent: Thursday, May 14, 2009 12:55 PM > To: Ted Mittelstaedt; Kevin Kargel; Martin Hannigan; ARIN PPML > Subject: Re: [arin-ppml] Will the price per IP really be affected > bythetransfer market introduced in 2009-1? > {snip} And it also turns out that agreeing ahead of time how we'll > all set > pricing is against the law. Yep, and that's why every gas station in town changes their price at the same hour of the same day to the same tenth of a cent. But wait, that would be against the law.. {snip} > Lee > > > > -------------- 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 May 15 11:40:31 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 15 May 2009 10:40:31 -0500 Subject: [arin-ppml] Will the price per IP really be affectedby thetransfer market introduced in 2009-1? In-Reply-To: References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com><75947E4ED9DB4123883FE407C515BC79@tedsdesk><4A0C745A.8000600@chl.com><59A3F92E3755441DB4320EF6B8BE0AB4@tedsdesk><4A0C84F0.9030202@chl.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B222@mail> > > > > -----Original Message----- > > From: Joe Maimon [mailto:jmaimon at chl.com] > > Sent: Thursday, May 14, 2009 1:54 PM > > To: Ted Mittelstaedt > > Cc: 'Martin Hannigan'; 'ARIN PPML' > > Subject: Re: [arin-ppml] Will the price per IP really be > > affected by thetransfer market introduced in 2009-1? > > > > > > > > > > Sure they do, but nobody ever says the road to pareto > > efficiency isnt bumpy. > > > There are many many examples of people who could have short-sold a > > > second home and walked away with a minor capital gains penalty, but > > > due to a refusal to countenence taking a loss, gambled and > > ended up in > > > foreclosure and bankruptcy and lost their primary home too. > > > > > And that is good news to buyers. And your example disproves > > your own thesis namely, that price can be held artificially > > high for extended periods of time. > > > > Come again? > > I'd call sitting on a home for 2 years instead of selling it 6 months > later a prime example of holding a price artifically high for an > extended period of time. Hopefully that doen't happen with IPv4. Sitting on a house and not selling it is just not selling it. A price is only established when there is a sale. If I want to ask $2million for my 2 year old chevy I can do that, I won't sell it, and it does not establish the price for two year old chevy's at 2 million. > > I don't say though that I believe the idea that the more you > interefere the worse the comeuppance is at correction time. The > US financial sector is a prime example of an industry with very > little interference and terrible comeuppances at correction time, > just ask Benie Madoff > > Ted . -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From scottleibrand at gmail.com Fri May 15 11:41:39 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 15 May 2009 08:41:39 -0700 Subject: [arin-ppml] Will the price per IP really be affected bythetransfer market introduced in 2009-1? In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B221@mail> References: <4A048640.1080302@gmail.com><58327061AE7A42B5A8058DC3BF3A309F@tedsdesk><4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B218@mail> <0ABC4DC32E31405BAE79D2B72BD059FC@tedsdesk> <235889.30639.qm@web63301.mail.re1.yahoo.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B221@mail> Message-ID: *Ahead of time* Price matching is not illegal. -Scott On May 15, 2009, at 8:28 AM, "Kevin Kargel" wrote: > >> -----Original Message----- >> From: Lee Howard [mailto:spiffnolee at yahoo.com] >> Sent: Thursday, May 14, 2009 12:55 PM >> To: Ted Mittelstaedt; Kevin Kargel; Martin Hannigan; ARIN PPML >> Subject: Re: [arin-ppml] Will the price per IP really be affected >> bythetransfer market introduced in 2009-1? >> > {snip} > And it also turns out that agreeing ahead of time how we'll >> all set >> pricing is against the law. > > Yep, and that's why every gas station in town changes their price at > the > same hour of the same day to the same tenth of a cent. But wait, > that would > be against the law.. > > {snip} >> Lee >> >> >> >> > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From stephen at sprunk.org Fri May 15 11:53:36 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 15 May 2009 10:53:36 -0500 Subject: [arin-ppml] Will the price per IP really be affected bythetransfer market introduced in 2009-1? In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B221@mail> References: <4A048640.1080302@gmail.com><58327061AE7A42B5A8058DC3BF3A309F@tedsdesk><4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B218@mail> <0ABC4DC32E31405BAE79D2B72BD059FC@tedsdesk> <235889.30639.qm@web63301.mail.re1.yahoo.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B221@mail> Message-ID: <4A0D9000.4090302@sprunk.org> Kevin Kargel wrote: >> And it also turns out that agreeing ahead of time how we'll all set pricing is against the law. >> > > Yep, and that's why every gas station in town changes their price at the same hour of the same day to the same tenth of a cent. But wait, that would be against the law.. > Price matching is legal; what is illegal is colluding in advance to set prices at a particular level. In many states, it is illegal for gas stations to change their prices more than once per day. So, what happens is that each morning in any given locale (here, it's at each major intersection where there will be 2-4 gas stations on the corners) one manager will go out and put up his price for the day, and the other manager(s) will immediately respond by setting their price the same or one cent less. That is perfectly legal; it may _look_ like collusion to an uninformed observer, but it isn't collusion if they don't meet ahead of time to discuss what they're going to do, only respond to each others' public actions. 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 kkargel at polartel.com Fri May 15 11:58:41 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 15 May 2009 10:58:41 -0500 Subject: [arin-ppml] Will the price per IP really be affected bythetransfer market introduced in 2009-1? In-Reply-To: <4A0D9000.4090302@sprunk.org> References: <4A048640.1080302@gmail.com><58327061AE7A42B5A8058DC3BF3A309F@tedsdesk><4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B218@mail> <0ABC4DC32E31405BAE79D2B72BD059FC@tedsdesk> <235889.30639.qm@web63301.mail.re1.yahoo.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B221@mail> <4A0D9000.4090302@sprunk.org> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B224@mail> > -----Original Message----- > From: Stephen Sprunk [mailto:stephen at sprunk.org] > Sent: Friday, May 15, 2009 10:54 AM > To: Kevin Kargel; ARIN PPML > Subject: Re: [arin-ppml] Will the price per IP really be affected > bythetransfer market introduced in 2009-1? > > Kevin Kargel wrote: > >> And it also turns out that agreeing ahead of time how we'll all set > pricing is against the law. > >> > > > > Yep, and that's why every gas station in town changes their price at the > same hour of the same day to the same tenth of a cent. But wait, that > would be against the law.. > > > > Price matching is legal; what is illegal is colluding in advance to set > prices at a particular level. > > In many states, it is illegal for gas stations to change their prices > more than once per day. So, what happens is that each morning in any > given locale (here, it's at each major intersection where there will be > 2-4 gas stations on the corners) one manager will go out and put up his > price for the day, and the other manager(s) will immediately respond by > setting their price the same or one cent less. That is perfectly legal; > it may _look_ like collusion to an uninformed observer, but it isn't > collusion if they don't meet ahead of time to discuss what they're going > to do, only respond to each others' public actions. Ah, but if you watch they all change their prices at the same time. How does that happen if they don't discuss it "ahead of time". I find it hard to believe that at 2AM there are 200 managers driving around town to check 200 gas stations so they can set their prices. The price changes don't ripple out, they toggle at the same time. Besides, if everyone picks one station to set the standard and they all agree "ahead of time" to match that station, isn't that the same collusion? > > 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: 3224 bytes Desc: not available URL: From stephen at sprunk.org Fri May 15 12:01:54 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 15 May 2009 11:01:54 -0500 Subject: [arin-ppml] Will the price per IP really be affected by thetransfer market introduced in 2009-1? In-Reply-To: References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com> <75947E4ED9DB4123883FE407C515BC79@tedsdesk> <4A0C745A.8000600@chl.com> <59A3F92E3755441DB4320EF6B8BE0AB4@tedsdesk> <4A0C84F0.9030202@chl.com> Message-ID: <4A0D91F2.50300@sprunk.org> Ted Mittelstaedt wrote: > I don't say though that I believe the idea that the more you interefere the worse the comeuppance is at correction time. The US financial sector is a prime example of an industry with very little interference and terrible comeuppances at correction time, just ask Benie Madoff > The real estate market arguably has the most government interference of any market in the US, and that is the root cause of our current financial problems. The FHA, FNMA, FDMC, and VA were originally chartered to "stabilize" the market, and they did an excellent job at that "interference" with the market's previously wild swings. However, in the 90s, they were rechartered to get _everyone_ a house, and banks were forced by law to give mortgages to people who couldn't afford them. The result was widespread marketing of ARMs and "subprime" loans, and that huge increase in artificial demand directly created the real estate bubble. When all those ARMs reset at higher rates (due to the bubble), we saw record levels of foreclosures and prices dropped back towards where they would have been all along if it weren't for the government's interference. The financial sector simply took advantage of the government's interference, and when that finally fell apart, they did too -- and took the entire economy down with them, giving the "terrible comeuppance" we see today. 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 Fri May 15 12:24:59 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 15 May 2009 11:24:59 -0500 Subject: [arin-ppml] Will the price per IP really be affected bythetransfer market introduced in 2009-1? In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B224@mail> References: <4A048640.1080302@gmail.com><58327061AE7A42B5A8058DC3BF3A309F@tedsdesk><4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B218@mail> <0ABC4DC32E31405BAE79D2B72BD059FC@tedsdesk> <235889.30639.qm@web63301.mail.re1.yahoo.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B221@mail> <4A0D9000.4090302@sprunk.org> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B224@mail> Message-ID: <4A0D975B.7080705@sprunk.org> Kevin Kargel wrote: >> -----Original Message----- >> From: Stephen Sprunk [mailto:stephen at sprunk.org] >> Sent: Friday, May 15, 2009 10:54 AM >> To: Kevin Kargel; ARIN PPML >> Subject: Re: [arin-ppml] Will the price per IP really be affected >> bythetransfer market introduced in 2009-1? >> >> Kevin Kargel wrote: >> >>>> And it also turns out that agreeing ahead of time how we'll all set pricing is against the law. >>>> >>> Yep, and that's why every gas station in town changes their price at the same hour of the same day to the same tenth of a cent. But wait, that would be against the law.. >>> >> Price matching is legal; what is illegal is colluding in advance to set prices at a particular level. >> >> In many states, it is illegal for gas stations to change their prices more than once per day. So, what happens is that each morning in any given locale (here, it's at each major intersection where there will be 2-4 gas stations on the corners) one manager will go out and put up his price for the day, and the other manager(s) will immediately respond by setting their price the same or one cent less. That is perfectly legal; it may _look_ like collusion to an uninformed observer, but it isn't collusion if they don't meet ahead of time to discuss what they're going to do, only respond to each others' public actions. >> > > Ah, but if you watch they all change their prices at the same time. It's not at _exactly_ the same time. Even a few minutes is enough for one manager to see what the other manager has done and respond accordingly. > How does that happen if they don't discuss it "ahead of time". Manager A knows that manager B puts up his price at a particular time, so he looks over at that time, watches what price goes up, and walks out to put up his own new price (either the same or a penny less). > I find it hard to believe that at 2AM there are 200 managers driving around town to check 200 gas stations so they can set their prices. The price changes don't ripple out, they toggle at the same time. > I seriously doubt that all 200 gas stations in your town have exactly the same price every single day. However, they're all getting similar pricing information from their upstream suppliers, so it's not surprising that they tend to move in tandem most of the time. Here, there are thousands of gas stations, but each intersection appears to operate as a mostly-independent market; one manager puts up his price, and the others change theirs a few minutes later. What happens at one intersection is only very loosely correlated with other intersections, but that's undoubtedly an effect of having 2-4 gas stations at each intersection, as opposed to having them distributed evenly all over town where it'd be much harder to determine who's responding to whom. > Besides, if everyone picks one station to set the standard and they all > agree "ahead of time" to match that station, isn't that the same collusion? > That would be collusion, but that isn't what they're doing. Each manager makes an independent decision to match or undercut the other stations, and who makes the first move each day usually varies in practice. However, even if it's always the same guy who moves first, as long as the various managers haven't _met_ ahead of time and _agreed_ to match his price, it's still legal. That might be a frequent result, but absent a meeting and an agreement, it's not price-fixing. This is why proving price-fixing cases is so difficult: rational independent behavior looks pretty much the same as collusion in a highly competitive, commodity market. What matters is whether the behavior is independent, not whether it happens to be uniform, and to disprove independence, you have to prove a meeting was held and an agreement was made. Getting back on topic, if we all agreed that we'd raise our rates $1/mo to cover the cost of buying IPv4 addresses on the market, that'd be illegal. However, if one provider is forced to raise their rates $1/mo, and the next day all the others decide that means they can raise their rate as well, that's legal. 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 tedm at ipinc.net Fri May 15 15:37:29 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 15 May 2009 12:37:29 -0700 Subject: [arin-ppml] Will the price per IP really be affected by thetransfer market introduced in 2009-1? In-Reply-To: <4A0D91F2.50300@sprunk.org> References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com> <75947E4ED9DB4123883FE407C515BC79@tedsdesk> <4A0C745A.8000600@chl.com> <59A3F92E3755441DB4320EF6B8BE0AB4@tedsdesk> <4A0C84F0.9030202@chl.com> <4A0D91F2.50300@sprunk.org> Message-ID: > -----Original Message----- > From: Stephen Sprunk [mailto:stephen at sprunk.org] > Sent: Friday, May 15, 2009 9:02 AM > To: Ted Mittelstaedt > Cc: 'Joe Maimon'; 'ARIN PPML' > Subject: Re: [arin-ppml] Will the price per IP really be > affected by thetransfer market introduced in 2009-1? > > Ted Mittelstaedt wrote: > > I don't say though that I believe the idea that the more you > > interefere the worse the comeuppance is at correction time. The US > > financial sector is a prime example of an industry with very little > > interference and terrible comeuppances at correction time, just ask > > Benie Madoff > > > > The real estate market arguably has the most government > interference of any market in the US, and that is the root > cause of our current financial problems. The FHA, FNMA, > FDMC, and VA were originally chartered to "stabilize" the > market, and they did an excellent job at that "interference" > with the market's previously wild swings. However, in the > 90s, they were rechartered to get _everyone_ a house, and > banks were forced by law to give mortgages to people who > couldn't afford them. I've heard that fairy tale before. The problem is that people who have actually looked at this theory have disproven it by comparing the foreclosure rates on CRA (Community Revitalization Act) loans against the standard loans, they are an order of magnitude lower. Plus the CRA (ie: "forced loan") stuff initally sold for a lot less and resale under foreclosure is a lot quicker and much less of a loss for the bank. And this is as you would expect because poor people with bad credit who got an opportuity to get a loan typically bought a much cheaper house. The real culprits were the army of home flippers out there who were (and are) typically mid to upper middle class people buying second homes for $300K and putting 100K into them and expecting to get $600K a year later. When the market tanked they all walked away from their loans (or short-sold them) and the banks had to eat it, initiating the subsequent bailout. This is why the current government programs to help out foreclosures aren't working - because all of them prohibit assistance if the foreclosed property is a second home bought for speculation, and it is precisely those homes that are driving the foreclosure rates. The home flippers were mostly using ARMS (why would you pay principle on a home your expecting to sell in a year) and it is the bundling of those ARMS and subsequent resale as unregulated securities that caused a bubble in the stock and bond market, when that bubble burst the stock speculators paniced and shoved money into commodities speculation, which pushed gasoline to $4 a gallon last year, contracted consumer spending, and that contraction caused a shortage of buyers for flip homes which triggered the collapse of the housing prices. > The result was widespread marketing of > ARMs and "subprime" loans, and that huge increase in > artificial demand directly created the real estate bubble. The artificial demand was from home-flippers buying more properties to flip, and using ARMS to do it. > When all those ARMs reset at higher rates (due to the > bubble), we saw record levels of foreclosures and prices > dropped back towards where they would have been all along if > it weren't for the government's interference. > Most ARMS reset at the 3 year mark and the collapse was underway long before. Before the crash back in 2005/2006 it was very common for home flippers to complete a sale BEFORE their ARM reset. The resetting of the ARM rates was just a byproduct of the crash, and it happened because nobody was buying for so long that the home flippers were sitting on property. It was the trading of unregulated securities that were FUNDING the arms that started it. Google up "Enron loophole" for a better understanding of the problem. What your doing is simply repeating a line the US Republican Party has dreamed up in their constant war against governmental regulation, a line that is absent many critical things. > The financial sector simply took advantage of the > government's interference, No, the financial sector in conjunction with the land speculators took advantage of the UNREGULATED market. This is why last year the feds forced all of the trading houses to either collapse or recharter as banks - because that was the quickest way to bring them under regulation. Ted From tedm at ipinc.net Fri May 15 15:45:58 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 15 May 2009 12:45:58 -0700 Subject: [arin-ppml] Will the price per IP really be affectedby thetransfer market introduced in 2009-1? In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B222@mail> References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com><75947E4ED9DB4123883FE407C515BC79@tedsdesk><4A0C745A.8000600@chl.com><59A3F92E3755441DB4320EF6B8BE0AB4@tedsdesk><4A0C84F0.9030202@chl.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B222@mail> Message-ID: <4584680A7E074CBA9C2F857234A6629B@tedsdesk> > -----Original Message----- > From: Kevin Kargel [mailto:kkargel at polartel.com] > Sent: Friday, May 15, 2009 8:41 AM > To: Ted Mittelstaedt; Joe Maimon > Cc: ARIN PPML > Subject: RE: [arin-ppml] Will the price per IP really be > affectedby thetransfer market introduced in 2009-1? > > > > > > Sitting on a house and not selling it is just not selling it. > A price is only established when there is a sale. Not true. Home listing prices affect prices that home sellers set. If a lot of homes in an area are fetching 1 million, even though it may take a year on the market to do it, most sellers are not going to list their property at $800K even though doing so would result in an immediate sale. There are actually a handful of housing markets - like Detroit - that DO follow standard market demand. In those markets it's not uncommon for homes to sell at a dollar. Yes, ONE US dollar. > If I want > to ask $2million for my 2 year old chevy I can do that, I > won't sell it, and it does not establish the price for two > year old chevy's at 2 million. > That's because many 2 year old chevys exactly like your chevy are available. Homes are different, in one respect every one of them is unique, even in developments where all of them have the same floor plan, some face east, others west, some are closer to the main road, etc. However in another respect they are not, because their prices are loosly related to each other in a given area. It remains to be seen how much a "special" market that IPv4 sales will be. Ted From kkargel at polartel.com Fri May 15 15:51:00 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 15 May 2009 14:51:00 -0500 Subject: [arin-ppml] Will the price per IP really be affectedby thetransfer market introduced in 2009-1? In-Reply-To: <4584680A7E074CBA9C2F857234A6629B@tedsdesk> References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com><75947E4ED9DB4123883FE407C515BC79@tedsdesk><4A0C745A.8000600@chl.com><59A3F92E3755441DB4320EF6B8BE0AB4@tedsdesk><4A0C84F0.9030202@chl.com> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B222@mail> <4584680A7E074CBA9C2F857234A6629B@tedsdesk> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B228@mail> > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Friday, May 15, 2009 2:46 PM > To: Kevin Kargel; 'Joe Maimon' > Cc: 'ARIN PPML' > Subject: RE: [arin-ppml] Will the price per IP really be affectedby > thetransfer market introduced in 2009-1? > > > > > -----Original Message----- > > From: Kevin Kargel [mailto:kkargel at polartel.com] > > Sent: Friday, May 15, 2009 8:41 AM > > To: Ted Mittelstaedt; Joe Maimon > > Cc: ARIN PPML > > Subject: RE: [arin-ppml] Will the price per IP really be > > affectedby thetransfer market introduced in 2009-1? > > > > > > > > > > Sitting on a house and not selling it is just not selling it. > > A price is only established when there is a sale. > > Not true. Home listing prices affect prices that home sellers set. > If a lot of homes in an area are fetching 1 million, even though > it may take a year on the market to do it, most sellers are not going > to list their property at $800K even though doing so would result > in an immediate sale. The key word here is fetching. What affects the market price is what people are paying, not what people are asking. Your taxes for example are not going to go up because your neighbor advertises his home at an inflated price. They may go up if he actually sells it for that price. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From tvest at pch.net Fri May 15 16:08:22 2009 From: tvest at pch.net (Tom Vest) Date: Fri, 15 May 2009 16:08:22 -0400 Subject: [arin-ppml] Will the price per IP really be affected by thetransfer market introduced in 2009-1? In-Reply-To: References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com> <75947E4ED9DB4123883FE407C515BC79@tedsdesk> <4A0C745A.8000600@chl.com> <59A3F92E3755441DB4320EF6B8BE0AB4@tedsdesk> <4A0C84F0.9030202@chl.com> <4A0D91F2.50300@sprunk.org> Message-ID: <83583FB9-F6C3-4A90-9F7B-85750B25BF01@pch.net> The real Real problem was the enthusiastic embrace by the financial industry members of commercial practices that allowed them to achieve their own objectives (e.g., satisfying ever-growing international demand for $US denominated securities), and enabled them to help out with other people's problems (e.g., clearing an ever-expanding supply of stuff that the largely stagnant US wage base could not by itself support), but in ways that absolutely destroyed whatever level of visibility that each industry member had into the others. Progressively less external regulation over the last decade or so, leading to ever-diminishing transparency for non-insiders, finally capped by the knowing/willful abandonment by the insiders themselves of any surviving, effective mechanisms for "counter-party scrutiny" that might have helped protect them (or the rest of us) from each other in the past. Not really all that different from the story of how our last bubble ended. Batter up... TV On May 15, 2009, at 3:37 PM, Ted Mittelstaedt wrote: >> -----Original Message----- >> From: Stephen Sprunk [mailto:stephen at sprunk.org] >> Sent: Friday, May 15, 2009 9:02 AM >> To: Ted Mittelstaedt >> Cc: 'Joe Maimon'; 'ARIN PPML' >> Subject: Re: [arin-ppml] Will the price per IP really be >> affected by thetransfer market introduced in 2009-1? >> >> Ted Mittelstaedt wrote: >>> I don't say though that I believe the idea that the more you >>> interefere the worse the comeuppance is at correction time. The US >>> financial sector is a prime example of an industry with very little >>> interference and terrible comeuppances at correction time, just ask >>> Benie Madoff >>> >> >> The real estate market arguably has the most government >> interference of any market in the US, and that is the root >> cause of our current financial problems. The FHA, FNMA, >> FDMC, and VA were originally chartered to "stabilize" the >> market, and they did an excellent job at that "interference" >> with the market's previously wild swings. However, in the >> 90s, they were rechartered to get _everyone_ a house, and >> banks were forced by law to give mortgages to people who >> couldn't afford them. > > I've heard that fairy tale before. The problem is that people > who have actually looked at this theory have disproven it by > comparing the foreclosure rates on CRA (Community Revitalization > Act) loans against the standard loans, they are an order of > magnitude lower. Plus the CRA (ie: "forced loan") stuff > initally sold for a lot less and resale under foreclosure is > a lot quicker and much less of a loss for the bank. And > this is as you would expect because poor people with bad > credit who got an opportuity to get a loan typically bought > a much cheaper house. > > The real culprits were the army of home flippers out there who > were (and are) typically mid to upper middle class people buying > second homes for $300K and putting 100K into them and expecting > to get $600K a year later. When the market tanked they all walked > away from their loans (or short-sold them) and the banks had to > eat it, initiating the subsequent bailout. > > This is why the current government programs to help out foreclosures > aren't working - because all of them prohibit assistance if the > foreclosed property is a second home bought for speculation, and > it is precisely those homes that are driving the foreclosure rates. > > The home flippers were mostly using ARMS (why would you pay principle > on a home your expecting to sell in a year) and it is the bundling > of those ARMS and subsequent resale as unregulated securities that > caused a bubble in the stock and bond market, when that bubble > burst the stock speculators paniced and shoved money into commodities > speculation, which pushed gasoline to $4 a gallon last year, > contracted consumer spending, and that contraction caused a shortage > of buyers for flip homes which triggered the collapse of the housing > prices. > >> The result was widespread marketing of >> ARMs and "subprime" loans, and that huge increase in >> artificial demand directly created the real estate bubble. > > The artificial demand was from home-flippers buying more > properties to flip, and using ARMS to do it. > >> When all those ARMs reset at higher rates (due to the >> bubble), we saw record levels of foreclosures and prices >> dropped back towards where they would have been all along if >> it weren't for the government's interference. >> > > Most ARMS reset at the 3 year mark and the collapse was underway > long before. Before the crash back in 2005/2006 it was very common > for home flippers to complete a sale BEFORE their ARM reset. > > The resetting of the ARM rates was just a byproduct > of the crash, and it happened because nobody was buying for so > long that the home flippers were sitting on property. It was the > trading of unregulated securities that were FUNDING the arms that > started it. > > Google up "Enron loophole" for a better understanding of the > problem. What your doing is simply repeating a line the US > Republican Party has dreamed up in their constant war against > governmental regulation, a line that is absent many critical > things. > >> The financial sector simply took advantage of the >> government's interference, > > No, the financial sector in conjunction with the land speculators > took advantage of the UNREGULATED market. > > This is why last year the feds forced all of the trading houses > to either collapse or recharter as banks - because that was the > quickest way to bring them under regulation. > > Ted > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Fri May 15 16:11:48 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 15 May 2009 13:11:48 -0700 Subject: [arin-ppml] Will the price per IP really be affected by thetransfer market introduced in 2009-1? In-Reply-To: <83583FB9-F6C3-4A90-9F7B-85750B25BF01@pch.net> References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com> <75947E4ED9DB4123883FE407C515BC79@tedsdesk> <4A0C745A.8000600@chl.com> <59A3F92E3755441DB4320EF6B8BE0AB4@tedsdesk> <4A0C84F0.9030202@chl.com> <4A0D91F2.50300@sprunk.org> <83583FB9-F6C3-4A90-9F7B-85750B25BF01@pch.net> Message-ID: <4578BC60F0C5460D816205F7E5D4F499@tedsdesk> Gee Tom, it almost sounds like your saying that some players in the biz secretly precipitated the crash after concluding that would be the only way to stop the spiral. Ted > -----Original Message----- > From: Tom Vest [mailto:tvest at pch.net] > Sent: Friday, May 15, 2009 1:08 PM > To: Ted Mittelstaedt > Cc: 'Stephen Sprunk'; 'ARIN PPML' > Subject: Re: [arin-ppml] Will the price per IP really be > affected by thetransfer market introduced in 2009-1? > > The real Real problem was the enthusiastic embrace by the > financial industry members of commercial practices that > allowed them to achieve their own objectives (e.g., > satisfying ever-growing international demand for $US > denominated securities), and enabled them to help out with > other people's problems (e.g., clearing an ever-expanding > supply of stuff that the largely stagnant US wage base could > not by itself support), but in ways that absolutely destroyed > whatever level of visibility that each industry member had > into the others. > Progressively less external regulation over the last decade > or so, leading to ever-diminishing transparency for > non-insiders, finally capped by the knowing/willful > abandonment by the insiders themselves of any surviving, > effective mechanisms for "counter-party scrutiny" > that might have helped protect them (or the rest of us) from > each other in the past. > > Not really all that different from the story of how our last > bubble ended. > > Batter up... > > TV > > On May 15, 2009, at 3:37 PM, Ted Mittelstaedt wrote: > > >> -----Original Message----- > >> From: Stephen Sprunk [mailto:stephen at sprunk.org] > >> Sent: Friday, May 15, 2009 9:02 AM > >> To: Ted Mittelstaedt > >> Cc: 'Joe Maimon'; 'ARIN PPML' > >> Subject: Re: [arin-ppml] Will the price per IP really be > affected by > >> thetransfer market introduced in 2009-1? > >> > >> Ted Mittelstaedt wrote: > >>> I don't say though that I believe the idea that the more you > >>> interefere the worse the comeuppance is at correction > time. The US > >>> financial sector is a prime example of an industry with > very little > >>> interference and terrible comeuppances at correction > time, just ask > >>> Benie Madoff > >>> > >> > >> The real estate market arguably has the most government > interference > >> of any market in the US, and that is the root cause of our current > >> financial problems. The FHA, FNMA, FDMC, and VA were originally > >> chartered to "stabilize" the market, and they did an > excellent job at > >> that "interference" > >> with the market's previously wild swings. However, in the > 90s, they > >> were rechartered to get _everyone_ a house, and banks were > forced by > >> law to give mortgages to people who couldn't afford them. > > > > I've heard that fairy tale before. The problem is that people who > > have actually looked at this theory have disproven it by > comparing the > > foreclosure rates on CRA (Community Revitalization > > Act) loans against the standard loans, they are an order of > magnitude > > lower. Plus the CRA (ie: "forced loan") stuff initally > sold for a lot > > less and resale under foreclosure is a lot quicker and much > less of a > > loss for the bank. And this is as you would expect because poor > > people with bad credit who got an opportuity to get a loan > typically > > bought a much cheaper house. > > > > The real culprits were the army of home flippers out there who were > > (and are) typically mid to upper middle class people buying second > > homes for $300K and putting 100K into them and expecting to > get $600K > > a year later. When the market tanked they all walked away > from their > > loans (or short-sold them) and the banks had to eat it, > initiating the > > subsequent bailout. > > > > This is why the current government programs to help out > foreclosures > > aren't working - because all of them prohibit assistance if the > > foreclosed property is a second home bought for > speculation, and it is > > precisely those homes that are driving the foreclosure rates. > > > > The home flippers were mostly using ARMS (why would you pay > principle > > on a home your expecting to sell in a year) and it is the > bundling of > > those ARMS and subsequent resale as unregulated securities > that caused > > a bubble in the stock and bond market, when that bubble burst the > > stock speculators paniced and shoved money into commodities > > speculation, which pushed gasoline to $4 a gallon last year, > > contracted consumer spending, and that contraction caused a > shortage > > of buyers for flip homes which triggered the collapse of > the housing > > prices. > > > >> The result was widespread marketing of ARMs and "subprime" > loans, and > >> that huge increase in artificial demand directly created the real > >> estate bubble. > > > > The artificial demand was from home-flippers buying more > properties to > > flip, and using ARMS to do it. > > > >> When all those ARMs reset at higher rates (due to the > bubble), we saw > >> record levels of foreclosures and prices dropped back > towards where > >> they would have been all along if it weren't for the government's > >> interference. > >> > > > > Most ARMS reset at the 3 year mark and the collapse was > underway long > > before. Before the crash back in 2005/2006 it was very common for > > home flippers to complete a sale BEFORE their ARM reset. > > > > The resetting of the ARM rates was just a byproduct of the > crash, and > > it happened because nobody was buying for so long that the home > > flippers were sitting on property. It was the trading of > unregulated > > securities that were FUNDING the arms that started it. > > > > Google up "Enron loophole" for a better understanding of > the problem. > > What your doing is simply repeating a line the US > Republican Party has > > dreamed up in their constant war against governmental regulation, a > > line that is absent many critical things. > > > >> The financial sector simply took advantage of the government's > >> interference, > > > > No, the financial sector in conjunction with the land > speculators took > > advantage of the UNREGULATED market. > > > > This is why last year the feds forced all of the trading houses to > > either collapse or recharter as banks - because that was > the quickest > > way to bring them under regulation. > > > > Ted > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed > to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > From tvest at pch.net Fri May 15 20:42:45 2009 From: tvest at pch.net (Tom Vest) Date: Fri, 15 May 2009 20:42:45 -0400 Subject: [arin-ppml] Will the price per IP really be affected by thetransfer market introduced in 2009-1? In-Reply-To: <4578BC60F0C5460D816205F7E5D4F499@tedsdesk> References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com> <75947E4ED9DB4123883FE407C515BC79@tedsdesk> <4A0C745A.8000600@chl.com> <59A3F92E3755441DB4320EF6B8BE0AB4@tedsdesk> <4A0C84F0.9030202@chl.com> <4A0D91F2.50300@sprunk.org> <83583FB9-F6C3-4A90-9F7B-85750B25BF01@pch.net> <4578BC60F0C5460D816205F7E5D4F499@tedsdesk> Message-ID: <9468A78D-F5A3-44DC-86A9-193222B0BC14@pch.net> On May 15, 2009, at 4:11 PM, Ted Mittelstaedt wrote: > Gee Tom, it almost sounds like your saying that some players in the > biz secretly precipitated the crash after concluding that would be the > only way to stop the spiral. > > Ted I'm not sure how one could interpret what I said in that way, for either industry. Thanks to (1), foreign demand for $US securities, individual banks could truly say that they were satisfying a "real market demand" -- i.e., that one way or another it would have been serviced by someone, so why not them? (aka the "it's just business" argument) Because of (2), they could credibly claim that they were fulfilling their essential function of "facilitating liquidity" -- never mind for the moment the reasons why the mechanism of credit creation (= somebody else's debt formation) was so much *more* necessary to sustain this function than it has ever been in the past. The near universal embrace of self-destructive, can't-see-no-evil-no- more commercial practices are really the only truly (or most) undeniably damning factor. In an industry full of people who are/were fabulously compensated for their allegedly unique domain expertise and judgment, a collective failure as epic as this is actually more far- fetched that some conspiracy theories. Ultimately the causes doesn't matter however; the harm is done, and the industry must be recognized for what it is: unfit for continued self-governance. In any case, if some players in the biz really had intentionally "precipitated a crash" as you suggest, then their timing sure sucked; a couple of $US trillions earlier, and it might have actually been constructive. Chatting about the financial sector can be illuminating in its own right, but as others have rightly noted, whatever relevance it has for address policy has probably been fully plumbed at this point. I'll keep my own thoughts on the subject off PPML hereafter... Cheers, TV >> -----Original Message----- >> From: Tom Vest [mailto:tvest at pch.net] >> Sent: Friday, May 15, 2009 1:08 PM >> To: Ted Mittelstaedt >> Cc: 'Stephen Sprunk'; 'ARIN PPML' >> Subject: Re: [arin-ppml] Will the price per IP really be >> affected by thetransfer market introduced in 2009-1? >> >> The real Real problem was the enthusiastic embrace by the >> financial industry members of commercial practices that >> allowed them to achieve their own objectives (e.g., >> satisfying ever-growing international demand for $US >> denominated securities), and enabled them to help out with >> other people's problems (e.g., clearing an ever-expanding >> supply of stuff that the largely stagnant US wage base could >> not by itself support), but in ways that absolutely destroyed >> whatever level of visibility that each industry member had >> into the others. >> Progressively less external regulation over the last decade >> or so, leading to ever-diminishing transparency for >> non-insiders, finally capped by the knowing/willful >> abandonment by the insiders themselves of any surviving, >> effective mechanisms for "counter-party scrutiny" >> that might have helped protect them (or the rest of us) from >> each other in the past. >> >> Not really all that different from the story of how our last >> bubble ended. >> >> Batter up... >> >> TV >> >> On May 15, 2009, at 3:37 PM, Ted Mittelstaedt wrote: >> >>>> -----Original Message----- >>>> From: Stephen Sprunk [mailto:stephen at sprunk.org] >>>> Sent: Friday, May 15, 2009 9:02 AM >>>> To: Ted Mittelstaedt >>>> Cc: 'Joe Maimon'; 'ARIN PPML' >>>> Subject: Re: [arin-ppml] Will the price per IP really be >> affected by >>>> thetransfer market introduced in 2009-1? >>>> >>>> Ted Mittelstaedt wrote: >>>>> I don't say though that I believe the idea that the more you >>>>> interefere the worse the comeuppance is at correction >> time. The US >>>>> financial sector is a prime example of an industry with >> very little >>>>> interference and terrible comeuppances at correction >> time, just ask >>>>> Benie Madoff >>>>> >>>> >>>> The real estate market arguably has the most government >> interference >>>> of any market in the US, and that is the root cause of our current >>>> financial problems. The FHA, FNMA, FDMC, and VA were originally >>>> chartered to "stabilize" the market, and they did an >> excellent job at >>>> that "interference" >>>> with the market's previously wild swings. However, in the >> 90s, they >>>> were rechartered to get _everyone_ a house, and banks were >> forced by >>>> law to give mortgages to people who couldn't afford them. >>> >>> I've heard that fairy tale before. The problem is that people who >>> have actually looked at this theory have disproven it by >> comparing the >>> foreclosure rates on CRA (Community Revitalization >>> Act) loans against the standard loans, they are an order of >> magnitude >>> lower. Plus the CRA (ie: "forced loan") stuff initally >> sold for a lot >>> less and resale under foreclosure is a lot quicker and much >> less of a >>> loss for the bank. And this is as you would expect because poor >>> people with bad credit who got an opportuity to get a loan >> typically >>> bought a much cheaper house. >>> >>> The real culprits were the army of home flippers out there who were >>> (and are) typically mid to upper middle class people buying second >>> homes for $300K and putting 100K into them and expecting to >> get $600K >>> a year later. When the market tanked they all walked away >> from their >>> loans (or short-sold them) and the banks had to eat it, >> initiating the >>> subsequent bailout. >>> >>> This is why the current government programs to help out >> foreclosures >>> aren't working - because all of them prohibit assistance if the >>> foreclosed property is a second home bought for >> speculation, and it is >>> precisely those homes that are driving the foreclosure rates. >>> >>> The home flippers were mostly using ARMS (why would you pay >> principle >>> on a home your expecting to sell in a year) and it is the >> bundling of >>> those ARMS and subsequent resale as unregulated securities >> that caused >>> a bubble in the stock and bond market, when that bubble burst the >>> stock speculators paniced and shoved money into commodities >>> speculation, which pushed gasoline to $4 a gallon last year, >>> contracted consumer spending, and that contraction caused a >> shortage >>> of buyers for flip homes which triggered the collapse of >> the housing >>> prices. >>> >>>> The result was widespread marketing of ARMs and "subprime" >> loans, and >>>> that huge increase in artificial demand directly created the real >>>> estate bubble. >>> >>> The artificial demand was from home-flippers buying more >> properties to >>> flip, and using ARMS to do it. >>> >>>> When all those ARMs reset at higher rates (due to the >> bubble), we saw >>>> record levels of foreclosures and prices dropped back >> towards where >>>> they would have been all along if it weren't for the government's >>>> interference. >>>> >>> >>> Most ARMS reset at the 3 year mark and the collapse was >> underway long >>> before. Before the crash back in 2005/2006 it was very common for >>> home flippers to complete a sale BEFORE their ARM reset. >>> >>> The resetting of the ARM rates was just a byproduct of the >> crash, and >>> it happened because nobody was buying for so long that the home >>> flippers were sitting on property. It was the trading of >> unregulated >>> securities that were FUNDING the arms that started it. >>> >>> Google up "Enron loophole" for a better understanding of >> the problem. >>> What your doing is simply repeating a line the US >> Republican Party has >>> dreamed up in their constant war against governmental regulation, a >>> line that is absent many critical things. >>> >>>> The financial sector simply took advantage of the government's >>>> interference, >>> >>> No, the financial sector in conjunction with the land >> speculators took >>> advantage of the UNREGULATED market. >>> >>> This is why last year the feds forced all of the trading houses to >>> either collapse or recharter as banks - because that was >> the quickest >>> way to bring them under regulation. >>> >>> Ted >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed >> to the ARIN >>> Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> > From scottleibrand at gmail.com Fri May 15 20:49:42 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 15 May 2009 17:49:42 -0700 Subject: [arin-ppml] Avoiding industry self-destruction through better policy In-Reply-To: <9468A78D-F5A3-44DC-86A9-193222B0BC14@pch.net> References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com> <75947E4ED9DB4123883FE407C515BC79@tedsdesk> <4A0C745A.8000600@chl.com> <59A3F92E3755441DB4320EF6B8BE0AB4@tedsdesk> <4A0C84F0.9030202@chl.com> <4A0D91F2.50300@sprunk.org> <83583FB9-F6C3-4A90-9F7B-85750B25BF01@pch.net> <4578BC60F0C5460D816205F7E5D4F499@tedsdesk> <9468A78D-F5A3-44DC-86A9-193222B0BC14@pch.net> Message-ID: <4A0E0DA6.3070208@gmail.com> In an attempt to bring this back on-topic: Tom Vest wrote: > The near universal embrace of self-destructive, can't-see-no-evil-no- > more commercial practices are really the only truly (or most) > undeniably damning factor. In an industry full of people who are/were > fabulously compensated for their allegedly unique domain expertise and > judgment, a collective failure as epic as this is actually more far- > fetched that some conspiracy theories. Ultimately the causes doesn't > matter however; the harm is done, and the industry must be recognized > for what it is: unfit for continued self-governance. > In a fit of what hopefully wasn't clairvoyance, I just started imagining the possibility that similar language might be used about our industry if we do a poor job of dealing with the upcoming IPv4 free pool exhaustion. So a couple questions to ponder: - Are any of ARIN's current policies contributing to potential industry self-destruction? - Is there anything else we can/should be doing to create policy that will prove our self-governance model workable through this transition? -Scott From lear at cisco.com Sun May 17 14:46:12 2009 From: lear at cisco.com (Eliot Lear) Date: Sun, 17 May 2009 20:46:12 +0200 Subject: [arin-ppml] Avoiding industry self-destruction through better policy In-Reply-To: <4A0E0DA6.3070208@gmail.com> References: <4A048640.1080302@gmail.com> <58327061AE7A42B5A8058DC3BF3A309F@tedsdesk> <4607e1d50905140533v68c7ac53g7360bdc4c0b23f8e@mail.gmail.com> <4607e1d50905141038s2cd0a92dy829d1ec9c191a2fc@mail.gmail.com> <75947E4ED9DB4123883FE407C515BC79@tedsdesk> <4A0C745A.8000600@chl.com> <59A3F92E3755441DB4320EF6B8BE0AB4@tedsdesk> <4A0C84F0.9030202@chl.com> <4A0D91F2.50300@sprunk.org> <83583FB9-F6C3-4A90-9F7B-85750B25BF01@pch.net> <4578BC60F0C5460D816205F7E5D4F499@tedsdesk> <9468A78D-F5A3-44DC-86A9-193222B0BC14@pch.net> <4A0E0DA6.3070208@gmail.com> Message-ID: <4A105B74.40300@cisco.com> On 5/16/09 2:49 AM, Scott Leibrand wrote: > In a fit of what hopefully wasn't clairvoyance, I just started imagining > the possibility that similar language might be used about our industry > if we do a poor job of dealing with the upcoming IPv4 free pool > exhaustion. So a couple questions to ponder: > > - Are any of ARIN's current policies contributing to potential industry > self-destruction? > > - Is there anything else we can/should be doing to create policy that > will prove our self-governance model workable through this transition? > These are great questions with no easy answers, Scott. It's clear that many people have a lot of passion around them. Of my time I've paid attention to this list, I've seen the following policy goals (amongst others) either stated or implied: 1. Stretch IPv4's life out as long as possible 2. Encourage a speedy migration to IPv6 3. Distribute remaining IPv4 addresses fairly (for some value of "fair") 4. Maintain the registry in as accurate manner as possible. I believe these four goals are extremely difficult to reconcile. I think it would be helpful for the community leadership to hold an open discussion here about these and other goals. Eliot From martin.hannigan at batelnet.bs Tue May 19 09:10:04 2009 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Tue, 19 May 2009 09:10:04 -0400 Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy - Revised andforwarded to the Board In-Reply-To: <1090508145149.425B-100000@Ives.egh.com> References: <1090508145149.425B-100000@Ives.egh.com> Message-ID: <4607e1d50905190610k703c3d6aw76403cbc1d13d0b3@mail.gmail.com> On Fri, May 8, 2009 at 3:04 PM, John Santos wrote: > On 8 May 2009 stephen at sprunk.org wrote: > >> Kevin Kargel wrote: >> > I believe the proof of what I am talking about is all of the unused IPv4 space that is not being returned so that it can be held as a speculative >> > commodity. ?Inaction in itself is a proof. >> > >> >> You are assigning a motive without proof. ?Yes, there is a lot of space >> out there that could be returned and hasn't been. ?I believe that in the >> vast majority of cases it is abandoned, forgotten, or is being used >> inefficiently and there is insufficient motivation to renumber. ?I have >> seen all of these cases in the wild many, many times; I have _never_ >> been told "we won't return that space because we're hoping to sell it >> one day." >> >> My motivation for supporting liberalized transfers is to apply a >> financial incentive to correct all of the problems above that I _have_ >> seen. ?If companies hear that they can get money for giving up space, >> many (but not all) of them are going to do an inventory and find out >> what they have but don't actually need so that they can cash in. ?Would >> I prefer altruistic motivation? ?Certainly. ?We've been trying that for >> a couple of decades now, and it has resulted in a few returns, but >> nowhere near as many as I'd hoped -- or as many as the community will >> need in a few years. ?It's time to quit pretending that altruism is >> sufficient. >> >> S >> > > Random thought of the day -- ?What about an IP deposit, like a returnable > bottle deposit? ?Make a deposit with ARIN when you get your IP, get it > back (plus interest?) when you return it. ?This money would not go to > ARIN; it would be more like an escrow account, but it would be motivation > for people with unused space to return it and get there nickels back. > > I don't think it would be possible to make this retroactive, though. Putting capital in ARIN's trust removes any leverage with that capital that I may have. It would have to be signficant to matter, and likely unfair since smaller allocations would pay smaller fees and members with much larger allocations would be required to deposit larger sums. I think that there is an air of discouragement with regards to raising fees, in my personal opinion, even fees that would be paid interest in escrow accounts. It would definitely be a fee. Best Regards, Martin From info at arin.net Wed May 20 10:06:27 2009 From: info at arin.net (Member Services) Date: Wed, 20 May 2009 10:06:27 -0400 Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages Message-ID: <4A140E63.6090007@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at:https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv4 Example Shortages Proposal Originator:Martin J. Levy Proposal Version: 1.0 Date: 20 May 2009 Proposal type: new Policy term: permanent Policy statement: Add section 4.1.8 to the NRPM to state: 4.1.8 IPv4 Example Shortages Beginning on January 1, 2010, and on the first of each January and July thereafter, for a period of 7 calendar days, ARIN will not process requests from existing IPv4 holders for additional IPv4 space. Rationale: The IANA is expected to issue the last of the available IPv4 address space to RIRs some time in 2011. RIRs are expected to run out approximately one year later. These brief delays should be minimal (no) impact to organizations with existing space wanting more, but, can provide a brief but visible glimpse into the future that awaits after runout. Organizations which fail to plan for these delays will have the option of waiting for ARIN to issue their space, or, can avail themselves of the transfer policy contained in section 8.3 of the NRPM (resulting from policy proposals 2008-6 and 2009-1). The cost of these delays will be minimal compared to what will happen when space simply is no longer available. This policy has no impact on IPv6 assignments or allocations and has no impact on new organizations making their first IPv4 request. Timetable for implementation: 1 January 2010 From kkargel at polartel.com Wed May 20 11:24:07 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 20 May 2009 10:24:07 -0500 Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages In-Reply-To: <4A140E63.6090007@arin.net> References: <4A140E63.6090007@arin.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B23B@mail> This just sounds like 'in your face' muscle flexing to me. If we start acting like a bully we will be regarded and treated as a bully. I oppose this proposal. Artificial shortages and artificial price increases are a bad idea all around. We need to act to strengthen our reputation for veracity and fair dealing. This proposal would weaken that reputation. Kevin Kargel > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Member Services > Sent: Wednesday, May 20, 2009 9:06 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages {snippage} > > > ## * ## > > > Policy Proposal Name: IPv4 Example Shortages > > Proposal Originator:Martin J. Levy > > Proposal Version: 1.0 > > Date: 20 May 2009 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add section 4.1.8 to the NRPM to state: > > 4.1.8 IPv4 Example Shortages > > Beginning on January 1, 2010, and on the first of each January and July > thereafter, for a period of 7 calendar days, ARIN will not process > requests from existing IPv4 holders for additional IPv4 space. > > Rationale: > > The IANA is expected to issue the last of the available IPv4 address > space to RIRs some time in 2011. RIRs are expected to run out > approximately one year later. These brief delays should be minimal (no) > impact to organizations with existing space wanting more, but, can > provide a brief but visible glimpse into the future that awaits after > runout. > > Organizations which fail to plan for these delays will have the option > of waiting for ARIN to issue their space, or, can avail themselves of > the transfer policy contained in section 8.3 of the NRPM (resulting from > policy proposals 2008-6 and 2009-1). The cost of these delays will be > minimal compared to what will happen when space simply is no longer > available. > > This policy has no impact on IPv6 assignments or allocations and has no > impact on new organizations making their first IPv4 request. > > Timetable for implementation: 1 January 2010 > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 dsd at servervault.com Wed May 20 11:37:50 2009 From: dsd at servervault.com (Divins, David) Date: Wed, 20 May 2009 11:37:50 -0400 Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages In-Reply-To: <4A140E63.6090007@arin.net> References: <4A140E63.6090007@arin.net> Message-ID: I oppose this policy. -dsd David Divins Principal Engineer ServerVault Corp. (703) 652-5955 -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services Sent: Wednesday, May 20, 2009 10:06 AM To: arin-ppml at arin.net Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at:https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv4 Example Shortages Proposal Originator:Martin J. Levy Proposal Version: 1.0 Date: 20 May 2009 Proposal type: new Policy term: permanent Policy statement: Add section 4.1.8 to the NRPM to state: 4.1.8 IPv4 Example Shortages Beginning on January 1, 2010, and on the first of each January and July thereafter, for a period of 7 calendar days, ARIN will not process requests from existing IPv4 holders for additional IPv4 space. Rationale: The IANA is expected to issue the last of the available IPv4 address space to RIRs some time in 2011. RIRs are expected to run out approximately one year later. These brief delays should be minimal (no) impact to organizations with existing space wanting more, but, can provide a brief but visible glimpse into the future that awaits after runout. Organizations which fail to plan for these delays will have the option of waiting for ARIN to issue their space, or, can avail themselves of the transfer policy contained in section 8.3 of the NRPM (resulting from policy proposals 2008-6 and 2009-1). The cost of these delays will be minimal compared to what will happen when space simply is no longer available. This policy has no impact on IPv6 assignments or allocations and has no impact on new organizations making their first IPv4 request. Timetable for implementation: 1 January 2010 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing 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 jradel at vantage.com Wed May 20 11:57:09 2009 From: jradel at vantage.com (Jon Radel) Date: Wed, 20 May 2009 11:57:09 -0400 Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages In-Reply-To: <4A140E63.6090007@arin.net> References: <4A140E63.6090007@arin.net> Message-ID: <4A142855.4040300@vantage.com> Member Services wrote: > > Policy Proposal Name: IPv4 Example Shortages > > Proposal Originator:Martin J. Levy > > Proposal Version: 1.0 > > Date: 20 May 2009 > > Some of us already budget well over 7 days for the address request process, any lesson would be lost on us. Actually, I'm dubious that the learning experience for anyone would be sufficient to make the disruption to the process and staff workloads worthwhile. -- Jon Radel Senior Director of Engineering Vantage Communications p: 267-756-1014 f: 202-742-5661 e: jradel at vantage.com "When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the state of science, whatever the matter may be." ~Lord Kelvin -------------- 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 bjohnson at drtel.com Wed May 20 11:52:53 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Wed, 20 May 2009 10:52:53 -0500 Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages In-Reply-To: <4A140E63.6090007@arin.net> References: <4A140E63.6090007@arin.net> Message-ID: <29A54911243620478FF59F00EBB12F47017E2F23@ex01.drtel.lan> Opposed! This sounds like someone has been paying too much attention to the Digital TV conversion process. - Brian > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Member Services > Sent: Wednesday, May 20, 2009 9:06 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with Policy Development > Process. > > This proposal is in the first stage of the Policy Development Process. > ARIN staff will perform the Clarity and Understanding step. Staff does > not evaluate the proposal at this time, their goal is to make sure that > they understand the proposal and believe the community will as well. > Staff will report their results to the ARIN Advisory Council (AC) > within > 10 days. > > The AC will review the proposal at their next regularly scheduled > meeting (if the period before the next regularly scheduled meeting is > less than 10 days, then the period may be extended to the subsequent > regularly scheduled meeting). The AC will decide how to utilize the > proposal and announce the decision to the PPML. > > In the meantime, the AC invites everyone to comment on the proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their > deliberations. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at:https://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: IPv4 Example Shortages > > Proposal Originator:Martin J. Levy > > Proposal Version: 1.0 > > Date: 20 May 2009 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add section 4.1.8 to the NRPM to state: > > 4.1.8 IPv4 Example Shortages > > Beginning on January 1, 2010, and on the first of each January and July > thereafter, for a period of 7 calendar days, ARIN will not process > requests from existing IPv4 holders for additional IPv4 space. > > Rationale: > > The IANA is expected to issue the last of the available IPv4 address > space to RIRs some time in 2011. RIRs are expected to run out > approximately one year later. These brief delays should be minimal > (no) > impact to organizations with existing space wanting more, but, can > provide a brief but visible glimpse into the future that awaits after > runout. > > Organizations which fail to plan for these delays will have the option > of waiting for ARIN to issue their space, or, can avail themselves of > the transfer policy contained in section 8.3 of the NRPM (resulting > from > policy proposals 2008-6 and 2009-1). The cost of these delays will be > minimal compared to what will happen when space simply is no longer > available. > > This policy has no impact on IPv6 assignments or allocations and has no > impact on new organizations making their first IPv4 request. > > Timetable for implementation: 1 January 2010 > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From Wesley.E.George at sprint.com Wed May 20 12:17:46 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Wed, 20 May 2009 11:17:46 -0500 Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages In-Reply-To: <4A140E63.6090007@arin.net> References: <4A140E63.6090007@arin.net> Message-ID: I oppose this policy. As has been stated, 7 days doesn't make enough of a difference to get anyone's attention, and it's certainly not enough of a delay to drive people to look to alternatives like a transfer under the transfer policy, which would likely take months. Thanks, Wes -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services Sent: Wednesday, May 20, 2009 10:06 AM To: arin-ppml at arin.net Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at:https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv4 Example Shortages Proposal Originator:Martin J. Levy Proposal Version: 1.0 Date: 20 May 2009 Proposal type: new Policy term: permanent Policy statement: Add section 4.1.8 to the NRPM to state: 4.1.8 IPv4 Example Shortages Beginning on January 1, 2010, and on the first of each January and July thereafter, for a period of 7 calendar days, ARIN will not process requests from existing IPv4 holders for additional IPv4 space. Rationale: The IANA is expected to issue the last of the available IPv4 address space to RIRs some time in 2011. RIRs are expected to run out approximately one year later. These brief delays should be minimal (no) impact to organizations with existing space wanting more, but, can provide a brief but visible glimpse into the future that awaits after runout. Organizations which fail to plan for these delays will have the option of waiting for ARIN to issue their space, or, can avail themselves of the transfer policy contained in section 8.3 of the NRPM (resulting from policy proposals 2008-6 and 2009-1). The cost of these delays will be minimal compared to what will happen when space simply is no longer available. This policy has no impact on IPv6 assignments or allocations and has no impact on new organizations making their first IPv4 request. Timetable for implementation: 1 January 2010 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From cboyd at gizmopartners.com Wed May 20 12:21:34 2009 From: cboyd at gizmopartners.com (Chris Boyd) Date: Wed, 20 May 2009 11:21:34 -0500 Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages In-Reply-To: <29A54911243620478FF59F00EBB12F47017E2F23@ex01.drtel.lan> References: <4A140E63.6090007@arin.net> <29A54911243620478FF59F00EBB12F47017E2F23@ex01.drtel.lan> Message-ID: Interesting idea, but I doubt that it will help much. Organizations that plan and participate in ARIN will know what's going on and just make their requests earlier or later as their needs dictate. Organizations that don't participate (or even read the easy to find documents) will just see this as another way that ARIN is being difficult to work with, obtuse, obscure, and probably several other things that should not be said on a public list. We're a service organization, and should provide those services even to groups that don't understand how things (should) work. --Chris From tedm at ipinc.net Wed May 20 13:12:47 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 20 May 2009 10:12:47 -0700 Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages In-Reply-To: <4A140E63.6090007@arin.net> References: <4A140E63.6090007@arin.net> Message-ID: We (my org) opposes this proposal. May I recommend the following, Instead of this policy, submit an operational suggestion to the ARIN suggestion box that would have ARIN staff supply educational information regarding what IPv4 runout is, when the current projection of runout will occur, etc. to every organization that submits an IPv4 allocation request. This would be in addition to the normal processing of IPv4 allocation requests. There has been some discussion already about sending this info to all e-mail addresses in the whois database. Ted > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > Sent: Wednesday, May 20, 2009 7:06 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages > > ARIN received the following policy proposal and is posting it > to the Public Policy Mailing List (PPML) in accordance with > Policy Development Process. > > This proposal is in the first stage of the Policy Development Process. > ARIN staff will perform the Clarity and Understanding step. > Staff does not evaluate the proposal at this time, their goal > is to make sure that they understand the proposal and believe > the community will as well. > Staff will report their results to the ARIN Advisory Council > (AC) within 10 days. > > The AC will review the proposal at their next regularly > scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may > be extended to the subsequent regularly scheduled meeting). > The AC will decide how to utilize the proposal and announce > the decision to the PPML. > > In the meantime, the AC invites everyone to comment on the > proposal on the PPML, particularly their support or > non-support and the reasoning behind their opinion. Such > participation contributes to a thorough vetting and provides > important guidance to the AC in their deliberations. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at:https://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: IPv4 Example Shortages > > Proposal Originator:Martin J. Levy > > Proposal Version: 1.0 > > Date: 20 May 2009 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add section 4.1.8 to the NRPM to state: > > 4.1.8 IPv4 Example Shortages > > Beginning on January 1, 2010, and on the first of each > January and July thereafter, for a period of 7 calendar days, > ARIN will not process requests from existing IPv4 holders for > additional IPv4 space. > > Rationale: > > The IANA is expected to issue the last of the available IPv4 > address space to RIRs some time in 2011. RIRs are expected > to run out approximately one year later. These brief delays > should be minimal (no) impact to organizations with existing > space wanting more, but, can provide a brief but visible > glimpse into the future that awaits after runout. > > Organizations which fail to plan for these delays will have > the option of waiting for ARIN to issue their space, or, can > avail themselves of the transfer policy contained in section > 8.3 of the NRPM (resulting from policy proposals 2008-6 and > 2009-1). The cost of these delays will be minimal compared to > what will happen when space simply is no longer available. > > This policy has no impact on IPv6 assignments or allocations > and has no impact on new organizations making their first > IPv4 request. > > Timetable for implementation: 1 January 2010 > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 cboyd at gizmopartners.com Wed May 20 13:19:54 2009 From: cboyd at gizmopartners.com (Chris Boyd) Date: Wed, 20 May 2009 12:19:54 -0500 Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages In-Reply-To: References: <4A140E63.6090007@arin.net> Message-ID: <808A2308-9458-4256-80ED-8D5EDA786C89@gizmopartners.com> On May 20, 2009, at 12:12 PM, Ted Mittelstaedt wrote: > Instead of this policy, submit an operational suggestion to the > ARIN suggestion box that would have ARIN staff supply educational > information regarding what IPv4 runout is, when the current projection > of runout will occur, etc. to every organization that submits an > IPv4 allocation request. This would be in addition to the normal > processing of IPv4 allocation requests. Good idea. From alex.ryu at kdlinc.com Wed May 20 13:23:39 2009 From: alex.ryu at kdlinc.com (Alex H. Ryu) Date: Wed, 20 May 2009 12:23:39 -0500 Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages In-Reply-To: <808A2308-9458-4256-80ED-8D5EDA786C89@gizmopartners.com> References: <4A140E63.6090007@arin.net> <808A2308-9458-4256-80ED-8D5EDA786C89@gizmopartners.com> Message-ID: <278B5E4BCD5E654385A9F83C7CA6D51799B91709D9@MAILBOX-01.qcommcorp.ad> Yes, instead of this proposal, ARIN staff can add "warning for IPv4 address depletion" and "IPv6 info" into top of message for every IPv4 address approval notice. That doesn't require any policy writing, and it can be done within ARIN staff's ability. I don't think one-week freeze for IPv4 address processing do much for the purpose. Alex -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Boyd Sent: Wednesday, May 20, 2009 12:20 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: IPv4 Example Shortages On May 20, 2009, at 12:12 PM, Ted Mittelstaedt wrote: > Instead of this policy, submit an operational suggestion to the > ARIN suggestion box that would have ARIN staff supply educational > information regarding what IPv4 runout is, when the current projection > of runout will occur, etc. to every organization that submits an > IPv4 allocation request. This would be in addition to the normal > processing of IPv4 allocation requests. Good idea. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing 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 steve at ibctech.ca Wed May 20 19:57:44 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 20 May 2009 19:57:44 -0400 Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages In-Reply-To: <278B5E4BCD5E654385A9F83C7CA6D51799B91709D9@MAILBOX-01.qcommcorp.ad> References: <4A140E63.6090007@arin.net> <808A2308-9458-4256-80ED-8D5EDA786C89@gizmopartners.com> <278B5E4BCD5E654385A9F83C7CA6D51799B91709D9@MAILBOX-01.qcommcorp.ad> Message-ID: <4A1498F8.2060007@ibctech.ca> Alex H. Ryu wrote: > Yes, instead of this proposal, ARIN staff can add "warning for IPv4 address depletion" and "IPv6 info" into top of message for every IPv4 address approval notice. > That doesn't require any policy writing, and it can be done within ARIN staff's ability. I oppose this policy. As far as the "warning", I have discussed this with numerous people off-list. There are two sides to that coin: - tell everyone via email or a warning with new allocation requests about the IPv4 runout - there are always going to be other pressing issues, so which ones do we pick-and-choose to warn people about Granted, this is quite the pickle of an issue, but to some, there may be larger issues that warrant warnings, and if ARIN decides to warn about runout and not another, someone is bound to get upset. With that said, I'm still going to post the request to the suggestion box (notification included in email upon 2008-7 ratification). Just because *I'm* not worried about it and am pretty much prepared, doesn't mean that other ops/businesses aren't...particularly new ones that may enter the playing field at or near the breaking point of the critical path. > I don't think one-week freeze for IPv4 address processing do much for the purpose. Of course it won't. If anything, it will cause a panic-type surge for requests just prior, or just after that week. Besides, I'm on holidays for those weeks ;) Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From rudi.daniel at gmail.com Wed May 20 21:25:44 2009 From: rudi.daniel at gmail.com (RudOlph Daniel) Date: Wed, 20 May 2009 21:25:44 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 47, Issue 57 In-Reply-To: References: Message-ID: <8aeeaff60905201825r3a494e7fk3c678c8fc9f8c669@mail.gmail.com> > I Opposed A more positive approach would be a Arin cartoon animation on the demise of IPv4 and the resulting rescue by super hero ipv6 screened on CNN. :) 7 days as already mentioned is lost in the blink of an eye. RD > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On > > Behalf Of Member Services > > Sent: Wednesday, May 20, 2009 9:06 AM > > To: arin-ppml at arin.net > > Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages > > > > ARIN received the following policy proposal and is posting it to the > > Public Policy Mailing List (PPML) in accordance with Policy > Development > > Process. > > > > This proposal is in the first stage of the Policy Development Process. > > ARIN staff will perform the Clarity and Understanding step. Staff does > > not evaluate the proposal at this time, their goal is to make sure > that > > they understand the proposal and believe the community will as well. > > Staff will report their results to the ARIN Advisory Council (AC) > > within > > 10 days. > > > > The AC will review the proposal at their next regularly scheduled > > meeting (if the period before the next regularly scheduled meeting is > > less than 10 days, then the period may be extended to the subsequent > > regularly scheduled meeting). The AC will decide how to utilize the > > proposal and announce the decision to the PPML. > > > > In the meantime, the AC invites everyone to comment on the proposal on > > the PPML, particularly their support or non-support and the reasoning > > behind their opinion. Such participation contributes to a thorough > > vetting and provides important guidance to the AC in their > > deliberations. > > > > The ARIN Policy Development Process can be found at: > > https://www.arin.net/policy/pdp.html > > > > Mailing list subscription information can be found > > at:https://www.arin.net/mailing_lists/ > > > > Regards, > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > > > Policy Proposal Name: IPv4 Example Shortages > > > > Proposal Originator:Martin J. Levy > > > > Proposal Version: 1.0 > > > > Date: 20 May 2009 > > > > Proposal type: new > > > > Policy term: permanent > > > > Policy statement: > > > > Add section 4.1.8 to the NRPM to state: > > > > 4.1.8 IPv4 Example Shortages > > > > Beginning on January 1, 2010, and on the first of each January and > July > > thereafter, for a period of 7 calendar days, ARIN will not process > > requests from existing IPv4 holders for additional IPv4 space. > > > > Rationale: > > > > The IANA is expected to issue the last of the available IPv4 address > > space to RIRs some time in 2011. RIRs are expected to run out > > approximately one year later. These brief delays should be minimal > > (no) > > impact to organizations with existing space wanting more, but, can > > provide a brief but visible glimpse into the future that awaits after > > runout. > > > > Organizations which fail to plan for these delays will have the option > > of waiting for ARIN to issue their space, or, can avail themselves of > > the transfer policy contained in section 8.3 of the NRPM (resulting > > from > > policy proposals 2008-6 and 2009-1). The cost of these delays will be > > minimal compared to what will happen when space simply is no longer > > available. > > > > This policy has no impact on IPv6 assignments or allocations and has > no > > impact on new organizations making their first IPv4 request. > > > > Timetable for implementation: 1 January 2010 > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing 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. > > > ------------------------------ > > Message: 2 > Date: Wed, 20 May 2009 11:17:46 -0500 > From: "George, Wes E [NTK]" > To: Member Services , "arin-ppml at arin.net" > > Subject: Re: [arin-ppml] Policy Proposal: IPv4 Example Shortages > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > I oppose this policy. As has been stated, 7 days doesn't make enough of a > difference to get anyone's attention, and it's certainly not enough of a > delay to drive people to look to alternatives like a transfer under the > transfer policy, which would likely take months. > > Thanks, > Wes > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Member Services > Sent: Wednesday, May 20, 2009 10:06 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with Policy Development > Process. > > This proposal is in the first stage of the Policy Development Process. > ARIN staff will perform the Clarity and Understanding step. Staff does > not evaluate the proposal at this time, their goal is to make sure that > they understand the proposal and believe the community will as well. > Staff will report their results to the ARIN Advisory Council (AC) within > 10 days. > > The AC will review the proposal at their next regularly scheduled > meeting (if the period before the next regularly scheduled meeting is > less than 10 days, then the period may be extended to the subsequent > regularly scheduled meeting). The AC will decide how to utilize the > proposal and announce the decision to the PPML. > > In the meantime, the AC invites everyone to comment on the proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at:https://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: IPv4 Example Shortages > > Proposal Originator:Martin J. Levy > > Proposal Version: 1.0 > > Date: 20 May 2009 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add section 4.1.8 to the NRPM to state: > > 4.1.8 IPv4 Example Shortages > > Beginning on January 1, 2010, and on the first of each January and July > thereafter, for a period of 7 calendar days, ARIN will not process > requests from existing IPv4 holders for additional IPv4 space. > > Rationale: > > The IANA is expected to issue the last of the available IPv4 address > space to RIRs some time in 2011. RIRs are expected to run out > approximately one year later. These brief delays should be minimal (no) > impact to organizations with existing space wanting more, but, can > provide a brief but visible glimpse into the future that awaits after > runout. > > Organizations which fail to plan for these delays will have the option > of waiting for ARIN to issue their space, or, can avail themselves of > the transfer policy contained in section 8.3 of the NRPM (resulting from > policy proposals 2008-6 and 2009-1). The cost of these delays will be > minimal compared to what will happen when space simply is no longer > available. > > This policy has no impact on IPv6 assignments or allocations and has no > impact on new organizations making their first IPv4 request. > > Timetable for implementation: 1 January 2010 > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > This e-mail may contain Sprint Nextel Company proprietary information > intended for the sole use of the recipient(s). Any use by others is > prohibited. If you are not the intended recipient, please contact the sender > and delete all copies of the message. > > > > ------------------------------ > > Message: 3 > Date: Wed, 20 May 2009 11:21:34 -0500 > From: Chris Boyd > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: IPv4 Example Shortages > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > Interesting idea, but I doubt that it will help much. > > Organizations that plan and participate in ARIN will know what's going > on and just make their requests earlier or later as their needs dictate. > > Organizations that don't participate (or even read the easy to find > documents) will just see this as another way that ARIN is being > difficult to work with, obtuse, obscure, and probably several other > things that should not be said on a public list. > > We're a service organization, and should provide those services even > to groups that don't understand how things (should) work. > > --Chris > > > ------------------------------ > > Message: 4 > Date: Wed, 20 May 2009 10:12:47 -0700 > From: "Ted Mittelstaedt" > To: "'Member Services'" , > Subject: Re: [arin-ppml] Policy Proposal: IPv4 Example Shortages > Message-ID: > Content-Type: text/plain; charset="US-ASCII" > > > We (my org) opposes this proposal. > > May I recommend the following, > > Instead of this policy, submit an operational suggestion to the > ARIN suggestion box that would have ARIN staff supply educational > information regarding what IPv4 runout is, when the current projection > of runout will occur, etc. to every organization that submits an > IPv4 allocation request. This would be in addition to the normal > processing of IPv4 allocation requests. > > There has been some discussion already about sending this info > to all e-mail addresses in the whois database. > > Ted > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > Sent: Wednesday, May 20, 2009 7:06 AM > > To: arin-ppml at arin.net > > Subject: [arin-ppml] Policy Proposal: IPv4 Example Shortages > > > > ARIN received the following policy proposal and is posting it > > to the Public Policy Mailing List (PPML) in accordance with > > Policy Development Process. > > > > This proposal is in the first stage of the Policy Development Process. > > ARIN staff will perform the Clarity and Understanding step. > > Staff does not evaluate the proposal at this time, their goal > > is to make sure that they understand the proposal and believe > > the community will as well. > > Staff will report their results to the ARIN Advisory Council > > (AC) within 10 days. > > > > The AC will review the proposal at their next regularly > > scheduled meeting (if the period before the next regularly > > scheduled meeting is less than 10 days, then the period may > > be extended to the subsequent regularly scheduled meeting). > > The AC will decide how to utilize the proposal and announce > > the decision to the PPML. > > > > In the meantime, the AC invites everyone to comment on the > > proposal on the PPML, particularly their support or > > non-support and the reasoning behind their opinion. Such > > participation contributes to a thorough vetting and provides > > important guidance to the AC in their deliberations. > > > > The ARIN Policy Development Process can be found at: > > https://www.arin.net/policy/pdp.html > > > > Mailing list subscription information can be found > > at:https://www.arin.net/mailing_lists/ > > > > Regards, > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > > > Policy Proposal Name: IPv4 Example Shortages > > > > Proposal Originator:Martin J. Levy > > > > Proposal Version: 1.0 > > > > Date: 20 May 2009 > > > > Proposal type: new > > > > Policy term: permanent > > > > Policy statement: > > > > Add section 4.1.8 to the NRPM to state: > > > > 4.1.8 IPv4 Example Shortages > > > > Beginning on January 1, 2010, and on the first of each > > January and July thereafter, for a period of 7 calendar days, > > ARIN will not process requests from existing IPv4 holders for > > additional IPv4 space. > > > > Rationale: > > > > The IANA is expected to issue the last of the available IPv4 > > address space to RIRs some time in 2011. RIRs are expected > > to run out approximately one year later. These brief delays > > should be minimal (no) impact to organizations with existing > > space wanting more, but, can provide a brief but visible > > glimpse into the future that awaits after runout. > > > > Organizations which fail to plan for these delays will have > > the option of waiting for ARIN to issue their space, or, can > > avail themselves of the transfer policy contained in section > > 8.3 of the NRPM (resulting from policy proposals 2008-6 and > > 2009-1). The cost of these delays will be minimal compared to > > what will happen when space simply is no longer available. > > > > This policy has no impact on IPv6 assignments or allocations > > and has no impact on new organizations making their first > > IPv4 request. > > > > Timetable for implementation: 1 January 2010 > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing 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. > > > > > > ------------------------------ > > Message: 5 > Date: Wed, 20 May 2009 12:19:54 -0500 > From: Chris Boyd > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: IPv4 Example Shortages > Message-ID: <808A2308-9458-4256-80ED-8D5EDA786C89 at gizmopartners.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > > On May 20, 2009, at 12:12 PM, Ted Mittelstaedt wrote: > > > Instead of this policy, submit an operational suggestion to the > > ARIN suggestion box that would have ARIN staff supply educational > > information regarding what IPv4 runout is, when the current projection > > of runout will occur, etc. to every organization that submits an > > IPv4 allocation request. This would be in addition to the normal > > processing of IPv4 allocation requests. > > Good idea. > > > ------------------------------ > > Message: 6 > Date: Wed, 20 May 2009 12:23:39 -0500 > From: "Alex H. Ryu" > To: Chris Boyd , "arin-ppml at arin.net" > > Subject: Re: [arin-ppml] Policy Proposal: IPv4 Example Shortages > Message-ID: > <278B5E4BCD5E654385A9F83C7CA6D51799B91709D9 at MAILBOX-01.qcommcorp.ad > > > Content-Type: text/plain; charset="us-ascii" > > Yes, instead of this proposal, ARIN staff can add "warning for IPv4 address > depletion" and "IPv6 info" into top of message for every IPv4 address > approval notice. > That doesn't require any policy writing, and it can be done within ARIN > staff's ability. > > I don't think one-week freeze for IPv4 address processing do much for the > purpose. > > Alex > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Chris Boyd > Sent: Wednesday, May 20, 2009 12:20 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: IPv4 Example Shortages > > > On May 20, 2009, at 12:12 PM, Ted Mittelstaedt wrote: > > > Instead of this policy, submit an operational suggestion to the > > ARIN suggestion box that would have ARIN staff supply educational > > information regarding what IPv4 runout is, when the current projection > > of runout will occur, etc. to every organization that submits an > > IPv4 allocation request. This would be in addition to the normal > > processing of IPv4 allocation requests. > > Good idea. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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. > > > ------------------------------ > > Message: 7 > Date: Wed, 20 May 2009 19:57:44 -0400 > From: Steve Bertrand > To: "Alex H. Ryu" > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Policy Proposal: IPv4 Example Shortages > Message-ID: <4A1498F8.2060007 at ibctech.ca> > Content-Type: text/plain; charset="iso-8859-1" > > Alex H. Ryu wrote: > > Yes, instead of this proposal, ARIN staff can add "warning for IPv4 > address depletion" and "IPv6 info" into top of message for every IPv4 > address approval notice. > > That doesn't require any policy writing, and it can be done within ARIN > staff's ability. > > I oppose this policy. > > As far as the "warning", I have discussed this with numerous people > off-list. There are two sides to that coin: > > - tell everyone via email or a warning with new allocation requests > about the IPv4 runout > > - there are always going to be other pressing issues, so which ones do > we pick-and-choose to warn people about > > Granted, this is quite the pickle of an issue, but to some, there may be > larger issues that warrant warnings, and if ARIN decides to warn about > runout and not another, someone is bound to get upset. > > With that said, I'm still going to post the request to the suggestion > box (notification included in email upon 2008-7 ratification). Just > because *I'm* not worried about it and am pretty much prepared, doesn't > mean that other ops/businesses aren't...particularly new ones that may > enter the playing field at or near the breaking point of the critical path. > > > I don't think one-week freeze for IPv4 address processing do much for the > purpose. > > Of course it won't. If anything, it will cause a panic-type surge for > requests just prior, or just after that week. Besides, I'm on holidays > for those weeks ;) > > Steve > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/x-pkcs7-signature > Size: 3233 bytes > Desc: S/MIME Cryptographic Signature > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20090520/d42ceb3c/attachment.bin > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 47, Issue 57 > ***************************************** > -- Rudi Daniel Independent Consultant e Business www.svgpso.org 1 784 533 7321 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bmanning at vacation.karoshi.com Fri May 22 08:22:54 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 22 May 2009 12:22:54 +0000 Subject: [arin-ppml] Snork... Yawn... S'up? Message-ID: <20090522122254.GC7597@vacation.karoshi.com.> morning folks, lazy as i am, i'm toying w/ reviewing the list archives for the past seven months, but thought i'd toss in my query first and -then- do my homework. a bit of background: https://www.arin.net/about_us/bot/bot2009_0206.html has this little gem: . Ratification of Draft Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses At their meeting on January 24, 2009, the ARIN Advisory Council recommended that the ARIN Board of Trustees adopt this Draft Policy. Scott Bradner moved: "The ARIN Board of Trustees, based on the recommendation of the ARIN Advisory Council, and noting that the Policy Development Process has been followed, adopts Draft Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses." [discussion elided] The motion carried, via roll call, with 4 in favor and 1 abstention (Lee Howard). [discssion about what an "Emergency" is elided] Paul Vixie joined the call at this time (1.47 p.m. EST). The Chair briefed him on the discussion. The Chair then suggested a friendly amendment to Scott's motion, and moved: "The ARIN Board of Trustees declares a State of Emergency. Due to the need for a more flexible Transfer Policy, the ARIN Board of Trustees has adopted Draft Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses, further making the following edits provided by Bill Woodcock. The Board also adds Section 2.8, replacing it in whole with Mr. Woodcock's rewrites." Scott Bradner accepted this friendly amendment. The Chair called for further discussion. There were no further comments. The motion carried unanimously via roll call. ----------------------------------------------------------------------------------------- So my query. When will this accepted/adpoted policy be implemented? --bill From farmer at umn.edu Fri May 22 09:17:00 2009 From: farmer at umn.edu (David Farmer) Date: Fri, 22 May 2009 08:17:00 -0500 Subject: [arin-ppml] Snork... Yawn... S'up? In-Reply-To: <20090522122254.GC7597@vacation.karoshi.com.> References: <20090522122254.GC7597@vacation.karoshi.com.> Message-ID: <4A165F7C.9313.2E1F154@farmer.umn.edu> Bill, See the following; https://www.arin.net/participate/meetings/reports/ARIN_XXIII/p df/tuesday/2009-1_update.pdf see the following alternate text proposed by the AC http://lists.arin.net/pipermail/arin-ppml/2009-May/013860.html Hope that helps; On 22 May 2009 bmanning at vacation.karoshi.com wrote: > > morning folks, > > lazy as i am, i'm toying w/ reviewing the list archives for the past seven months, but > thought i'd toss in my query first and -then- do my homework. > > a bit of background: https://www.arin.net/about_us/bot/bot2009_0206.html has this little > gem: > > . Ratification of Draft Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses > > At their meeting on January 24, 2009, the ARIN Advisory Council recommended that the ARIN Board of Trustees adopt this Draft Policy. > > Scott Bradner moved: > > "The ARIN Board of Trustees, based on the recommendation of the ARIN Advisory Council, and noting that the Policy Development Process has been followed, adopts Draft Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses." > > [discussion elided] > > The motion carried, via roll call, with 4 in favor and 1 abstention (Lee Howard). > > [discssion about what an "Emergency" is elided] > > Paul Vixie joined the call at this time (1.47 p.m. EST). The Chair briefed him on the discussion. > > The Chair then suggested a friendly amendment to Scott's motion, and moved: > > "The ARIN Board of Trustees declares a State of Emergency. Due to the need for a more flexible Transfer Policy, the ARIN Board of Trustees has adopted Draft Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses, further making the following edits provided by Bill Woodcock. The Board also adds Section 2.8, replacing it in whole with Mr. Woodcock's rewrites." > > Scott Bradner accepted this friendly amendment. The Chair called for further discussion. There were no further comments. > > The motion carried unanimously via roll call. > ----------------------------------------------------------------------------------------- > > So my query. When will this accepted/adpoted policy be implemented? > > --bill > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. =============================================== 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 BillD at cait.wustl.edu Fri May 22 09:25:22 2009 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 22 May 2009 08:25:22 -0500 Subject: [arin-ppml] Snork... Yawn... S'up? In-Reply-To: <20090522122254.GC7597@vacation.karoshi.com.> References: <20090522122254.GC7597@vacation.karoshi.com.> Message-ID: Hi Bill, Yep, you should go to ppml and read the archives as there is a significant and tortuous path of correspondence and new policy proposal record to review. In short, the board proposed the 2009-1 proposal with Woody's words which dismissed the sunset clause, incorporated more than IPv4 into the bargain and implemented immediately, etc. There was firestorm of dissent and inquiry about it. bd > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of > bmanning at vacation.karoshi.com > Sent: Friday, May 22, 2009 7:23 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Snork... Yawn... S'up? > > > morning folks, > > lazy as i am, i'm toying w/ reviewing the list archives > for the past seven months, but thought i'd toss in my query > first and -then- do my homework. > > a bit of background: > https://www.arin.net/about_us/bot/bot2009_0206.html has this little > gem: > > . Ratification of Draft Policy 2008-6: Emergency > Transfer Policy for IPv4 Addresses > > At their meeting on January 24, 2009, the ARIN Advisory > Council recommended that the ARIN Board of Trustees adopt > this Draft Policy. > > Scott Bradner moved: > > "The ARIN Board of Trustees, based on the recommendation > of the ARIN Advisory Council, and noting that the Policy > Development Process has been followed, adopts Draft Policy > 2008-6: Emergency Transfer Policy for IPv4 Addresses." > > [discussion elided] > > The motion carried, via roll call, with 4 in favor and 1 > abstention (Lee Howard). > > [discssion about what an "Emergency" is elided] > > Paul Vixie joined the call at this time (1.47 p.m. EST). The > Chair briefed him on the discussion. > > The Chair then suggested a friendly amendment to Scott's > motion, and moved: > > "The ARIN Board of Trustees declares a State of > Emergency. Due to the need for a more flexible Transfer > Policy, the ARIN Board of Trustees has adopted Draft Policy > 2008-6: Emergency Transfer Policy for IPv4 Addresses, further > making the following edits provided by Bill Woodcock. The > Board also adds Section 2.8, replacing it in whole with Mr. > Woodcock's rewrites." > > Scott Bradner accepted this friendly amendment. The Chair > called for further discussion. There were no further comments. > > The motion carried unanimously via roll call. > -------------------------------------------------------------- > --------------------------- > > So my query. When will this accepted/adpoted policy be implemented? > > --bill > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From bmanning at vacation.karoshi.com Fri May 22 09:42:10 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 22 May 2009 13:42:10 +0000 Subject: [arin-ppml] Snork... Yawn... S'up? In-Reply-To: <4A165F7C.9313.2E1F154@farmer.umn.edu> References: <20090522122254.GC7597@vacation.karoshi.com.> <4A165F7C.9313.2E1F154@farmer.umn.edu> Message-ID: <20090522134210.GA8227@vacation.karoshi.com.> ah.. thank you. --bill On Fri, May 22, 2009 at 08:17:00AM -0500, David Farmer wrote: > Bill, > > See the following; > > https://www.arin.net/participate/meetings/reports/ARIN_XXIII/p > df/tuesday/2009-1_update.pdf > > see the following alternate text proposed by the AC > > http://lists.arin.net/pipermail/arin-ppml/2009-May/013860.html > > Hope that helps; > > On 22 May 2009 bmanning at vacation.karoshi.com wrote: > > > > > morning folks, > > > > lazy as i am, i'm toying w/ reviewing the list archives for the past seven months, but > > thought i'd toss in my query first and -then- do my homework. > > > > a bit of background: https://www.arin.net/about_us/bot/bot2009_0206.html has this little > > gem: > > > > . Ratification of Draft Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses > > > > At their meeting on January 24, 2009, the ARIN Advisory Council recommended that the ARIN Board of Trustees adopt this Draft Policy. > > > > Scott Bradner moved: > > > > "The ARIN Board of Trustees, based on the recommendation of the ARIN Advisory Council, and noting that the Policy Development Process has been followed, adopts Draft Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses." > > > > [discussion elided] > > > > The motion carried, via roll call, with 4 in favor and 1 abstention (Lee Howard). > > > > [discssion about what an "Emergency" is elided] > > > > Paul Vixie joined the call at this time (1.47 p.m. EST). The Chair briefed him on the discussion. > > > > The Chair then suggested a friendly amendment to Scott's motion, and moved: > > > > "The ARIN Board of Trustees declares a State of Emergency. Due to the need for a more flexible Transfer Policy, the ARIN Board of Trustees has adopted Draft Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses, further making the following edits provided by Bill Woodcock. The Board also adds Section 2.8, replacing it in whole with Mr. Woodcock's rewrites." > > > > Scott Bradner accepted this friendly amendment. The Chair called for further discussion. There were no further comments. > > > > The motion carried unanimously via roll call. > > ----------------------------------------------------------------------------------------- > > > > So my query. When will this accepted/adpoted policy be implemented? > > > > --bill > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > =============================================== > 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 bmanning at vacation.karoshi.com Fri May 22 09:46:25 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 22 May 2009 13:46:25 +0000 Subject: [arin-ppml] Snork... Yawn... S'up? In-Reply-To: References: <20090522122254.GC7597@vacation.karoshi.com.> Message-ID: <20090522134625.GB8227@vacation.karoshi.com.> indeed. well then... (reading the march board minutes is also instructive....) this issue does not appear closer to resolution than 18 months ago. interesting dynamic btwn the members and the staff/board here. where is my popcorn and lemonaide? this promises to be a good show. --bill On Fri, May 22, 2009 at 08:25:22AM -0500, Bill Darte wrote: > Hi Bill, > > Yep, you should go to ppml and read the archives as there is a > significant and tortuous path of correspondence and new policy proposal > record to review. > > In short, the board proposed the 2009-1 proposal with Woody's words > which dismissed the sunset clause, incorporated more than IPv4 into the > bargain and implemented immediately, etc. There was firestorm of > dissent and inquiry about it. > > bd > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of > > bmanning at vacation.karoshi.com > > Sent: Friday, May 22, 2009 7:23 AM > > To: arin-ppml at arin.net > > Subject: [arin-ppml] Snork... Yawn... S'up? > > > > > > morning folks, > > > > lazy as i am, i'm toying w/ reviewing the list archives > > for the past seven months, but thought i'd toss in my query > > first and -then- do my homework. > > > > a bit of background: > > https://www.arin.net/about_us/bot/bot2009_0206.html has this little > > gem: > > > > . Ratification of Draft Policy 2008-6: Emergency > > Transfer Policy for IPv4 Addresses > > > > At their meeting on January 24, 2009, the ARIN Advisory > > Council recommended that the ARIN Board of Trustees adopt > > this Draft Policy. > > > > Scott Bradner moved: > > > > "The ARIN Board of Trustees, based on the recommendation > > of the ARIN Advisory Council, and noting that the Policy > > Development Process has been followed, adopts Draft Policy > > 2008-6: Emergency Transfer Policy for IPv4 Addresses." > > > > [discussion elided] > > > > The motion carried, via roll call, with 4 in favor and 1 > > abstention (Lee Howard). > > > > [discssion about what an "Emergency" is elided] > > > > Paul Vixie joined the call at this time (1.47 p.m. EST). The > > Chair briefed him on the discussion. > > > > The Chair then suggested a friendly amendment to Scott's > > motion, and moved: > > > > "The ARIN Board of Trustees declares a State of > > Emergency. Due to the need for a more flexible Transfer > > Policy, the ARIN Board of Trustees has adopted Draft Policy > > 2008-6: Emergency Transfer Policy for IPv4 Addresses, further > > making the following edits provided by Bill Woodcock. The > > Board also adds Section 2.8, replacing it in whole with Mr. > > Woodcock's rewrites." > > > > Scott Bradner accepted this friendly amendment. The Chair > > called for further discussion. There were no further comments. > > > > The motion carried unanimously via roll call. > > -------------------------------------------------------------- > > --------------------------- > > > > So my query. When will this accepted/adpoted policy be implemented? > > > > --bill > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > From michael.dillon at bt.com Fri May 22 10:09:14 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 22 May 2009 15:09:14 +0100 Subject: [arin-ppml] Snork... Yawn... S'up? In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458014B5978@E03MVZ2-UKDY.domain1.systemhost.net> > In short, the board proposed the 2009-1 proposal with Woody's > words which dismissed the sunset clause, incorporated more > than IPv4 into the bargain and implemented immediately, etc. Implemented immediately... So, have any IP blocks been transferred yet? When will we hear some stats on how many blocks and how big they are? --Michael Dillon From bicknell at ufp.org Fri May 22 10:33:03 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 22 May 2009 10:33:03 -0400 Subject: [arin-ppml] Snork... Yawn... S'up? In-Reply-To: <20090522122254.GC7597@vacation.karoshi.com.> References: <20090522122254.GC7597@vacation.karoshi.com.> Message-ID: <20090522143303.GA79307@ussenterprise.ufp.org> In a message written on Fri, May 22, 2009 at 12:22:54PM +0000, bmanning at vacation.karoshi.com wrote: > So my query. When will this accepted/adpoted policy be implemented? Let me see if I can put the high points all in one place. January, AC meeting: https://www.arin.net/about_us/ac/ac2009_0124.html AC sends 2008-6 to the Board recomending adoption. Februrary, Board meeting: https://www.arin.net/about_us/bot/bot2009_0206.html Board declares an emergency, edits the proposal, and adopts it. March, Board meeting: https://www.arin.net/about_us/bot/bot2009_0318.html Board realizes what they did in February wasn't the right way forward, and rescinding that effort. Board introduces a new policy, 2009-1, via the emergency policy process. http://lists.arin.net/pipermail/arin-ppml/2009-April/013483.html Board extends the discussion period through ARIN XXIII http://lists.arin.net/pipermail/arin-ppml/2009-April/013615.html Board issues a statement on the policy. https://www.arin.net/participate/meetings/reports/ARIN_XXIII/ppm1_transcript.html#anchor_4 Discussed at ARIN XXIII. On the second day, the Board made a further public statement: https://www.arin.net/participate/meetings/reports/ARIN_XXIII/pdf/tuesday/2009-1_update.pdf In this statement they said they would direct staff to implement 2008-6 or 2009-1, per the outcome of the meeting, on June 1st. The AC's meeting minutes from San Antonio are not yet reviewed and posted, however part of the results are already public. The AC put forth slightly revised language to PPML and recommended the Board use that: http://lists.arin.net/pipermail/arin-ppml/2009-May/013860.html Hope that helps. -- 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: 825 bytes Desc: not available URL: From BillD at cait.wustl.edu Fri May 22 11:45:56 2009 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 22 May 2009 10:45:56 -0500 Subject: [arin-ppml] Snork... Yawn... S'up? In-Reply-To: <28E139F46D45AF49A31950F88C497458014B5978@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458014B5978@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: Michael.... The 'proposal' was intended to be implemented immediately under the emergency powers of the Board...rather than as in 2008-6 where the implementation indicated a future, un-specified date. I was merely pointing out the essential differences from 2008-6 and the 'proposed' 2009-1 for Bill's edification. You were along for the ride during all the earlier discussion and subsequents meetings, etc. So, I'm surprised that you are still confused by this. Bill Darte ARIN AC > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com > Sent: Friday, May 22, 2009 9:09 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Snork... Yawn... S'up? > > > In short, the board proposed the 2009-1 proposal with Woody's words > > which dismissed the sunset clause, incorporated more than IPv4 into > > the bargain and implemented immediately, etc. > > Implemented immediately... > > So, have any IP blocks been transferred yet? When will we > hear some stats on how many blocks and how big they are? > > --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 michael.dillon at bt.com Fri May 22 11:55:40 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 22 May 2009 16:55:40 +0100 Subject: [arin-ppml] Snork... Yawn... S'up? In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458014B5BB5@E03MVZ2-UKDY.domain1.systemhost.net> > The 'proposal' was intended to be implemented immediately > under the emergency powers of the Board...rather than as in > 2008-6 where the implementation indicated a future, un-specified date. > > I was merely pointing out the essential differences from > 2008-6 and the 'proposed' 2009-1 for Bill's edification. > > You were along for the ride during all the earlier discussion > and subsequents meetings, etc. So, I'm surprised that you are > still confused by this. I'm not confused. I just wanna know if the emergency was justified by events after the policy had been implemented. The questions stand... > > So, have any IP blocks been transferred yet? When will we hear some > > stats on how many blocks and how big they are? --Michael Dillon P.S. Not all questions are rhetorical. From BillD at cait.wustl.edu Fri May 22 12:36:16 2009 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 22 May 2009 11:36:16 -0500 Subject: [arin-ppml] Snork... Yawn... S'up? In-Reply-To: <28E139F46D45AF49A31950F88C497458014B5BB5@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458014B5BB5@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: And, let me be more clear.... Neither 2008-6, nor the proposed 2009-1 have been 'implemented'. And, there are no operations organized to support it, if/when the final extended transfer policy IS implemented. So in answer to your question, there have been none..... bd > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com > Sent: Friday, May 22, 2009 10:56 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Snork... Yawn... S'up? > > > The 'proposal' was intended to be implemented immediately under the > > emergency powers of the Board...rather than as in > > 2008-6 where the implementation indicated a future, > un-specified date. > > > > I was merely pointing out the essential differences from > > 2008-6 and the 'proposed' 2009-1 for Bill's edification. > > > > You were along for the ride during all the earlier discussion and > > subsequents meetings, etc. So, I'm surprised that you are still > > confused by this. > > I'm not confused. I just wanna know if the emergency was > justified by events after the policy had been implemented. > The questions stand... > > > > So, have any IP blocks been transferred yet? When will we > hear some > > > stats on how many blocks and how big they are? > > --Michael Dillon > > P.S. Not all questions are rhetorical. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 bmanning at vacation.karoshi.com Fri May 22 13:51:43 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 22 May 2009 17:51:43 +0000 Subject: [arin-ppml] Snork... Yawn... S'up? In-Reply-To: <28E139F46D45AF49A31950F88C497458014B5BB5@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458014B5BB5@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <20090522175143.GA10257@vacation.karoshi.com.> On Fri, May 22, 2009 at 04:55:40PM +0100, michael.dillon at bt.com wrote: > > The 'proposal' was intended to be implemented immediately > > under the emergency powers of the Board...rather than as in > > 2008-6 where the implementation indicated a future, un-specified date. > > > > I was merely pointing out the essential differences from > > 2008-6 and the 'proposed' 2009-1 for Bill's edification. > > > > You were along for the ride during all the earlier discussion > > and subsequents meetings, etc. So, I'm surprised that you are > > still confused by this. > > I'm not confused. I just wanna know if the emergency > was justified by events after the policy had been > implemented. The questions stand... it never appears that either policy has been implemented -YET-. looks like both have been adopted by the board - hence (some) of the confusion and consternation ... > --Michael Dillon --bill From jcurran at arin.net Tue May 26 08:38:14 2009 From: jcurran at arin.net (John Curran) Date: Tue, 26 May 2009 08:38:14 -0400 Subject: [arin-ppml] 2008-6/2009-1 Implementation question In-Reply-To: <20090522175143.GA10257@vacation.karoshi.com> References: <28E139F46D45AF49A31950F88C497458014B5BB5@E03MVZ2-UKDY.domain1.systemhost.net> <20090522175143.GA10257@vacation.karoshi.com> Message-ID: <5BBE91E8-431C-470E-82F9-2C0A9E7A51EE@arin.net> On May 22, 2009, at 1:51 PM, bmanning at vacation.karoshi.com wrote: > > it never appears that either policy has been implemented -YET-. > looks like both have been adopted by the board - hence (some) > of the confusion and consternation ... Bill, The AC sent revised 2009-1 text back to the ARIN Board which will be considered shortly. Once that is completed, then its implementation will occur. As 2800-6 is already adopted, we indicated that implementation of that policy will proceed on June 1st, either as-is or as-revised by 2009-1. /John John Curran Acting President and CEO ARIN From bmanning at vacation.karoshi.com Tue May 26 08:41:08 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 26 May 2009 12:41:08 +0000 Subject: [arin-ppml] 2008-6/2009-1 Implementation question In-Reply-To: <5BBE91E8-431C-470E-82F9-2C0A9E7A51EE@arin.net> References: <28E139F46D45AF49A31950F88C497458014B5BB5@E03MVZ2-UKDY.domain1.systemhost.net> <20090522175143.GA10257@vacation.karoshi.com> <5BBE91E8-431C-470E-82F9-2C0A9E7A51EE@arin.net> Message-ID: <20090526124108.GA8536@vacation.karoshi.com.> On Tue, May 26, 2009 at 08:38:14AM -0400, John Curran wrote: > On May 22, 2009, at 1:51 PM, bmanning at vacation.karoshi.com wrote: > > > > it never appears that either policy has been implemented -YET-. > > looks like both have been adopted by the board - hence (some) > > of the confusion and consternation ... > > Bill, > > The AC sent revised 2009-1 text back to the ARIN Board which > will be considered shortly. Once that is completed, then its > implementation will occur. As 2800-6 is already adopted, we > indicated that implementation of that policy will proceed on > June 1st, either as-is or as-revised by 2009-1. > > /John > > John Curran > Acting President and CEO > ARIN > thanks John... I've got my wrist band and am queued up. --bill From info at arin.net Tue May 26 14:26:52 2009 From: info at arin.net (Member Services) Date: Tue, 26 May 2009 14:26:52 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - May 2009 Message-ID: <4A1C346C.3000509@arin.net> On 21 May 2009 the ARIN Advisory Council (AC) reviewed ?Policy Proposal 87: Extend 16 bit ASN Assignments? and accepted it onto the AC's docket for development and evaluation. In addition, the AC conducted their last call review of ?Draft Policy 2008-7: Identify Invalid WHOIS POC?s?. The AC found support for the draft policy and recommended it to the ARIN Board of Trustees for adoption. Draft Policy and Policy Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) From kkargel at polartel.com Tue May 26 17:17:16 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 26 May 2009 16:17:16 -0500 Subject: [arin-ppml] 2009-1 comment Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> Being that 2009-1 is listed as under discussion on ppml on https://www.arin.net/policy/proposals/index.html, I want to make another comment. Section 8-2 is make completely superfluous as any transfers for the purpose of mergers and acquisitions could just as easily be handled under the sell it to anyone you want clauses in section 8-3. If you can sell IP addresses (transfer for monetary consideration if you don't like the word sell) to anyone for any reason, adding criteria to transfer address space for specific purposes already covered by the general clause is unnecessary. Either section 8-2 or 8-3 should be stricken from the proposal, as the inclusion of both is excessive and redundant verbiage. I find it contradictory that section 8-1 avers that "It should be understood that number resources are not "sold" under ARIN administration." Yet there is verbiage to specifically allow number resources to be sold in section 8-3. If we include language that facilitates the sale of IP address space then we should remove the verbiage stating that IP addresses are not sold. Leaving both in place shows the world that we talk out of both sides of our face. Continuing my past statements, I oppose this policy so long as section 8-3 exists. I would support this policy as written without section 8-3. Best regards, 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 woody at pch.net Tue May 26 17:32:23 2009 From: woody at pch.net (Bill Woodcock) Date: Tue, 26 May 2009 14:32:23 -0700 (PDT) Subject: [arin-ppml] 2009-1 comment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> Message-ID: On Tue, 26 May 2009, Kevin Kargel wrote: > Section 8-2 is make completely superfluous... > I find it contradictory that section 8-1 avers that "It should be understood > that number resources are not "sold" under ARIN administration." Those two problems were addressed and resolved in the February 6 board meeting, but then subsequently reintroduced when people complained. I'd _love_ to see a policy proposal fixing them again. -Bill From scottleibrand at gmail.com Tue May 26 17:47:09 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 26 May 2009 16:47:09 -0500 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> Message-ID: <4A1C635D.3030809@gmail.com> Kevin Kargel wrote: > Being that 2009-1 is listed as under discussion on ppml on > https://www.arin.net/policy/proposals/index.html, I want to make another > comment. Section 8-2 is make completely superfluous as any transfers for > the purpose of mergers and acquisitions could just as easily be handled > under the sell it to anyone you want clauses in section 8-3. > Bear in mind that 8.3 only applies to IPv4, whereas 8.2 also applies to IPv6 addresses and ASNs. As Bill mentioned, I think this is one of many places in the NRPM that could use some cleanup. Unfortunately, trying to do cleanup in the same proposal as a substantive change causes even more confusion and controversy, so I've tried to hold off on doing the cleanup until we get finished with the substantive changes. (Particularly as a member of the AC) I would love to see proposals from the community indicating which areas of the policy manual, like this one, are most in need of cleanup. -Scott > If you can sell IP addresses (transfer for monetary consideration if you > don't like the word sell) to anyone for any reason, adding criteria to > transfer address space for specific purposes already covered by the general > clause is unnecessary. > Either section 8-2 or 8-3 should be stricken from the proposal, as the > inclusion of both is excessive and redundant verbiage. > > I find it contradictory that section 8-1 avers that "It should be understood > that number resources are not "sold" under ARIN administration." Yet there > is verbiage to specifically allow number resources to be sold in section > 8-3. If we include language that facilitates the sale of IP address space > then we should remove the verbiage stating that IP addresses are not sold. > Leaving both in place shows the world that we talk out of both sides of our > face. > > Continuing my past statements, I oppose this policy so long as section 8-3 > exists. I would support this policy as written without section 8-3. > > Best regards, > Kevin Kargel > > > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From farmer at umn.edu Tue May 26 18:25:06 2009 From: farmer at umn.edu (David Farmer) Date: Tue, 26 May 2009 17:25:06 -0500 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> Message-ID: <4A1C25F2.11900.145A2B77@farmer.umn.edu> Kevin, Section 8.3 is supose to apply only to IPv4, Section 8.2, applies to IPv6, and ASNs, as well as IPv4. So do you want 8.3 to apply to IPv6 and ASNs too? If we made that change then you would be correct that Section 8.2 would superfluous. But as written in the text recommended by the AC, 8.2 is not superfluous, and is very much needed in order to transact transfers for IPv6 and ASNs in the case of change of ownership. On 26 May 2009 Kevin Kargel wrote: > Being that 2009-1 is listed as under discussion on ppml on > https://www.arin.net/policy/proposals/index.html, I want to make > another comment. Section 8-2 is make completely superfluous as any > transfers for the purpose of mergers and acquisitions could just as > easily be handled under the sell it to anyone you want clauses in > section 8-3. > > If you can sell IP addresses (transfer for monetary consideration if > you don't like the word sell) to anyone for any reason, adding > criteria to transfer address space for specific purposes already > covered by the general clause is unnecessary. Either section 8-2 or > 8-3 should be stricken from the proposal, as the inclusion of both is > excessive and redundant verbiage. =============================================== 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 kkargel at polartel.com Tue May 26 18:41:04 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 26 May 2009 17:41:04 -0500 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <4A1C25F2.11900.145A2B77@farmer.umn.edu> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> <4A1C25F2.11900.145A2B77@farmer.umn.edu> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B255@mail> > -----Original Message----- > From: David Farmer [mailto:farmer at umn.edu] > Sent: Tuesday, May 26, 2009 5:25 PM > To: arin ppml; Kevin Kargel > Subject: Re: [arin-ppml] 2009-1 comment > > Kevin, > > Section 8.3 is supose to apply only to IPv4, Section 8.2, applies to IPv6, > and > ASNs, as well as IPv4. So do you want 8.3 to apply to IPv6 and ASNs too? > If we made that change then you would be correct that Section 8.2 would > superfluous. But as written in the text recommended by the AC, 8.2 is not > superfluous, and is very much needed in order to transact transfers for > IPv6 > and ASNs in the case of change of ownership. Reading through the text of 2009-1 I don't find the references that say section 8.2 is for IP and 8.3 is for IPv4 .. Without the delimiting wording saying "This is for IP and that is for IPv4" then both sections technically apply to IPvX, regardless of what the intention was or what it was "supposed" to be. As written in the text published at https://www.arin.net/policy/proposals/2009_1.html both sections will apply equally to IPv4 and IPv6, making 8.2 superfluous. If we rely on the intention then we will all be surprised when in the future someone says "But it doesn't say that in the NRPM and so as long as I follow the words in the NRPM I can do what I want.." We need to be specific and if we are writing sections to apply to specific protocols then that needs to be spelled out in the words that are written in those sections. If I am wrong please point out to me the text that says that 8.3 applies to IPv4 but not IPv6 or ASN's and 8.2 applies to all IP and ASN's. I have been wrong before once or twice, I could be again, but I do not see it in the text of the proposal. I want 8.3 to go away. The rest of the proposal is great. If we strike 8.3 I will become a staunch supporter of 2009-1. > > On 26 May 2009 Kevin Kargel wrote: > > > Being that 2009-1 is listed as under discussion on ppml on > > https://www.arin.net/policy/proposals/index.html, I want to make > > another comment. Section 8-2 is make completely superfluous as any > > transfers for the purpose of mergers and acquisitions could just as > > easily be handled under the sell it to anyone you want clauses in > > section 8-3. > > > > If you can sell IP addresses (transfer for monetary consideration if > > you don't like the word sell) to anyone for any reason, adding > > criteria to transfer address space for specific purposes already > > covered by the general clause is unnecessary. Either section 8-2 or > > 8-3 should be stricken from the proposal, as the inclusion of both is > > excessive and redundant verbiage. > > > =============================================== > 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 > =============================================== -------------- 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 Tue May 26 18:52:37 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 26 May 2009 18:52:37 -0400 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B255@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> <4A1C25F2.11900.145A2B77@farmer.umn.edu> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B255@mail> Message-ID: <20090526225237.GA69144@ussenterprise.ufp.org> In a message written on Tue, May 26, 2009 at 05:41:04PM -0500, Kevin Kargel wrote: > Reading through the text of 2009-1 I don't find the references that say > section 8.2 is for IP and 8.3 is for IPv4 .. https://www.arin.net/policy/proposals/2009_1.html "Alternative Text Proposed by AC - 4 May 2009" in the bottom of the discussion tracking takes you to http://lists.arin.net/pipermail/arin-ppml/2009-May/013860.html, the text proposed by the AC. I believe the clarifications being referenced are only in the AC recommended text. -- 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: 825 bytes Desc: not available URL: From rudi.daniel at gmail.com Tue May 26 20:41:17 2009 From: rudi.daniel at gmail.com (RudOlph Daniel) Date: Tue, 26 May 2009 20:41:17 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 47, Issue 63 In-Reply-To: References: Message-ID: <8aeeaff60905261741m6e47fdbbuc0ad173c15221ee0@mail.gmail.com> >>Re Kevin's (transfer for monetary consideration if > > you don't like the word sell) 2009-1 Section 8.3 starts: "IPv4 number resources...." and Section 8.2 refers to all number resources ...or so I read it. ...8.2 also states that ARIN will "Consider" requests and evaluate...So what happens when I am refused a transfer request? Do I get my lawyers out ? Reading 8.3 over and over again, I am beginning to ask myself if this clause gives the all clear to profit from transfers...all be it ..under the table. RD > > > > -----Original Message----- > > From: David Farmer [mailto:farmer at umn.edu] > > Sent: Tuesday, May 26, 2009 5:25 PM > > To: arin ppml; Kevin Kargel > > Subject: Re: [arin-ppml] 2009-1 comment > > > > Kevin, > > > > Section 8.3 is supose to apply only to IPv4, Section 8.2, applies to > IPv6, > > and > > ASNs, as well as IPv4. So do you want 8.3 to apply to IPv6 and ASNs too? > > If we made that change then you would be correct that Section 8.2 would > > superfluous. But as written in the text recommended by the AC, 8.2 is > not > > superfluous, and is very much needed in order to transact transfers for > > IPv6 > > and ASNs in the case of change of ownership. > > Reading through the text of 2009-1 I don't find the references that say > section 8.2 is for IP and 8.3 is for IPv4 .. > > Without the delimiting wording saying "This is for IP and that is for IPv4" > then both sections technically apply to IPvX, regardless of what the > intention was or what it was "supposed" to be. As written in the text > published at https://www.arin.net/policy/proposals/2009_1.html both > sections > will apply equally to IPv4 and IPv6, making 8.2 superfluous. > > If we rely on the intention then we will all be surprised when in the > future > someone says "But it doesn't say that in the NRPM and so as long as I > follow > the words in the NRPM I can do what I want.." We need to be specific and > if > we are writing sections to apply to specific protocols then that needs to > be > spelled out in the words that are written in those sections. > > If I am wrong please point out to me the text that says that 8.3 applies to > IPv4 but not IPv6 or ASN's and 8.2 applies to all IP and ASN's. I have > been > wrong before once or twice, I could be again, but I do not see it in the > text of the proposal. > > I want 8.3 to go away. The rest of the proposal is great. If we strike > 8.3 > I will become a staunch supporter of 2009-1. > > > > > > On 26 May 2009 Kevin Kargel wrote: > > > > > Being that 2009-1 is listed as under discussion on ppml on > > > https://www.arin.net/policy/proposals/index.html, I want to make > > > another comment. Section 8-2 is make completely superfluous as any > > > transfers for the purpose of mergers and acquisitions could just as > > > easily be handled under the sell it to anyone you want clauses in > > > section 8-3. > > > > > > If you can sell IP addresses (transfer for monetary consideration if > > > you don't like the word sell) to anyone for any reason, adding > > > criteria to transfer address space for specific purposes already > > > covered by the general clause is unnecessary. Either section 8-2 or > > > 8-3 should be stricken from the proposal, as the inclusion of both is > > > excessive and redundant verbiage. > > > > > > =============================================== > > 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 > > =============================================== > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/x-pkcs7-signature > Size: 3224 bytes > Desc: not available > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20090526/97cb4469/attachment.bin > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 47, Issue 63 > ***************************************** > -- Rudi Daniel Independent Consultant e Business Implementation www.svgpso.org 1 784 533 7321 -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue May 26 20:40:23 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 26 May 2009 17:40:23 -0700 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <4A1C25F2.11900.145A2B77@farmer.umn.edu> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> <4A1C25F2.11900.145A2B77@farmer.umn.edu> Message-ID: <14AC7CC4-A19B-450E-B002-DF9583F9D59B@delong.com> It also makes it much easier to repeal 2008-6/2009-1 if the community subsequently chooses to do so by simply deleting section 8.3. Owen On May 26, 2009, at 3:25 PM, David Farmer wrote: > Kevin, > > Section 8.3 is supose to apply only to IPv4, Section 8.2, applies to > IPv6, and > ASNs, as well as IPv4. So do you want 8.3 to apply to IPv6 and ASNs > too? > If we made that change then you would be correct that Section 8.2 > would > superfluous. But as written in the text recommended by the AC, 8.2 > is not > superfluous, and is very much needed in order to transact transfers > for IPv6 > and ASNs in the case of change of ownership. > > On 26 May 2009 Kevin Kargel wrote: > >> Being that 2009-1 is listed as under discussion on ppml on >> https://www.arin.net/policy/proposals/index.html, I want to make >> another comment. Section 8-2 is make completely superfluous as any >> transfers for the purpose of mergers and acquisitions could just as >> easily be handled under the sell it to anyone you want clauses in >> section 8-3. >> >> If you can sell IP addresses (transfer for monetary consideration if >> you don't like the word sell) to anyone for any reason, adding >> criteria to transfer address space for specific purposes already >> covered by the general clause is unnecessary. Either section 8-2 or >> 8-3 should be stricken from the proposal, as the inclusion of both is >> excessive and redundant verbiage. > > > =============================================== > 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 kkargel at polartel.com Wed May 27 11:10:49 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 27 May 2009 10:10:49 -0500 Subject: [arin-ppml] ARIN-PPML Digest, Vol 47, Issue 63 In-Reply-To: <8aeeaff60905261741m6e47fdbbuc0ad173c15221ee0@mail.gmail.com> References: <8aeeaff60905261741m6e47fdbbuc0ad173c15221ee0@mail.gmail.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B258@mail> >>Re Kevin's (transfer for monetary consideration if > > you don't like the word sell) 2009-1 Section 8.3 starts: "IPv4 number resources...."? and Section 8.2 refers to all number resources ...or so I read it. ...8.2 also states that ARIN will "Consider" requests and evaluate...So what happens when I am refused a transfer request? Do I get my lawyers out ? Reading 8.3 over and over again, I am beginning to ask myself if this clause gives the all clear to profit from transfers...all be it ..under the table. RD 8.3 does just that, and not even under the table. What 8.3 will do is put the price of IPv4 at blue sky.. so I hope you have all you will ever possibly need right now. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From jcurran at arin.net Wed May 27 16:13:12 2009 From: jcurran at arin.net (John Curran) Date: Wed, 27 May 2009 16:13:12 -0400 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> Message-ID: <6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net> On May 26, 2009, at 5:17 PM, Kevin Kargel wrote: > > Being that 2009-1 is listed as under discussion on ppml on > https://www.arin.net/policy/proposals/index.html, I want to make > another > comment. Section 8-2 is make completely superfluous as any > transfers for > the purpose of mergers and acquisitions could just as easily be > handled > under the sell it to anyone you want clauses in section 8-3. One nuance that I'd like to bring out for clarity's sake: Transfers as a result of mergers and acquisitions go through a confirmation step to insure that the actual operational resources (i.e. equipment, routers, hosts) are moving along to the new entity. This is to insure that we don't have the number resources go one direction and the actual network go another. However, this is not, per se, a completion justification of all of the transferred number resources and their need. As long as substantially all of the assets are transferred, then transfer of associated number resources is allowed. One can imagine various multi-billion dollar firms acquiring one another another; a complete rejustification of all number resource usage would be very prohibitive, much like asking the firm to reapply for all of its building permits, operating licenses, etc. on the day of close. As such, a transfer due to NRPM 8.2 is significantly different that that proposed under 8.3 (where the acquiring entity must fully qualify for the resources to be received, just as any other application for additional resources). I provide this information to help the community in its discussion, and not to suggest what the appropriate outcome should be. We can obviously have both 8.2 and 8.3, or harmonize them to one approach or other if the community so desires. /John John Curran Acting President and CEO ARIN From kkargel at polartel.com Wed May 27 16:26:43 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 27 May 2009 15:26:43 -0500 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> <6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> Thank you for your clarification John. I completely agree with section 8.2. We definitely need to facilitate acquisitions. Even though the combined resources may be more than the receiving company needs, renumbering a large network is not going to happen overnight and they will need some unknown quantity of time to merge the networks. Hopefully the companies will see fit to do so, and if not they will likely grow into the excess space and just not need more allocation so soon. My problem is the outright sale of space to a designated party without transfer of network assets and without making the space available to the community at large as is allowed in 8.3. This creates an enormous potential for unfair practice giving the large players a huge advantage. > -----Original Message----- > From: John Curran [mailto:jcurran at arin.net] > Sent: Wednesday, May 27, 2009 3:13 PM > To: Kevin Kargel > Cc: arin ppml > Subject: Re: [arin-ppml] 2009-1 comment > > On May 26, 2009, at 5:17 PM, Kevin Kargel wrote: > > > > Being that 2009-1 is listed as under discussion on ppml on > > https://www.arin.net/policy/proposals/index.html, I want to make > > another > > comment. Section 8-2 is make completely superfluous as any > > transfers for > > the purpose of mergers and acquisitions could just as easily be > > handled > > under the sell it to anyone you want clauses in section 8-3. > > One nuance that I'd like to bring out for clarity's sake: > > Transfers as a result of mergers and acquisitions go through a > confirmation step to insure that the actual operational resources > (i.e. equipment, routers, hosts) are moving along to the new entity. > This is to insure that we don't have the number resources go one > direction and the actual network go another. However, this is > not, per se, a completion justification of all of the transferred > number resources and their need. As long as substantially all > of the assets are transferred, then transfer of associated number > resources is allowed. One can imagine various multi-billion dollar > firms acquiring one another another; a complete rejustification of > all number resource usage would be very prohibitive, much like > asking the firm to reapply for all of its building permits, > operating licenses, etc. on the day of close. > > As such, a transfer due to NRPM 8.2 is significantly different > that that proposed under 8.3 (where the acquiring entity must > fully qualify for the resources to be received, just as any > other application for additional resources). > > I provide this information to help the community in its discussion, > and not to suggest what the appropriate outcome should be. We can > obviously have both 8.2 and 8.3, or harmonize them to one approach > or other if the community so desires. > > /John > > John Curran > Acting President and CEO > ARIN -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From jay at impulse.net Wed May 27 16:20:04 2009 From: jay at impulse.net (Jay Hennigan) Date: Wed, 27 May 2009 13:20:04 -0700 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> <6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net> Message-ID: <4A1DA074.3090309@impulse.net> I am opposed to this proposal as written. I would support it if section 8.3 were stricken in its entirety. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From vixie at isc.org Wed May 27 16:49:23 2009 From: vixie at isc.org (Paul Vixie) Date: Wed, 27 May 2009 20:49:23 +0000 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> (Kevin Kargel's message of "Wed\, 27 May 2009 15\:26\:43 -0500") References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> <6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> Message-ID: these two messages bring up an important question. kkargel at polartel.com ("Kevin Kargel") writes: > My problem is the outright sale of space to a designated party without > transfer of network assets and without making the space available to the > community at large as is allowed in 8.3. This creates an enormous > potential for unfair practice giving the large players a huge advantage. jay at impulse.net (Jay Hennigan) writes: > I am opposed to this proposal as written. I would support it if section > 8.3 were stricken in its entirety. is everyone fully aware that a version of this same policy has already been approved (2008-6) and stands to go into effect on june 1, and that what's being discussed here is a cleaned up version (2009-1)? that means, opposition to 2009-1's proposed 8.3 in ignorance of 2008-6's effective 8.3 won't help any cause. to stop address space transfers from taking place apart from acquisitions, would require a new transfer policy that undid the effect of 2008-6. 2009-1 will not be *that* policy. -- Paul Vixie KI6YSY From bjohnson at drtel.com Wed May 27 17:35:01 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Wed, 27 May 2009 16:35:01 -0500 Subject: [arin-ppml] 2009-1 comment In-Reply-To: References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail><6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> Message-ID: <29A54911243620478FF59F00EBB12F47017E31BD@ex01.drtel.lan> Paul, Is 2008-6 receiving wide approval by the community? Does this policy coincide with the ARIN charter and the goals of the organization? Perhaps this is the issue? Just my .02 - Brian > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Paul Vixie > Sent: Wednesday, May 27, 2009 3:49 PM > To: ppml at arin.net > Subject: Re: [arin-ppml] 2009-1 comment > > these two messages bring up an important question. > > kkargel at polartel.com ("Kevin Kargel") writes: > > > My problem is the outright sale of space to a designated party > without > > transfer of network assets and without making the space available to > the > > community at large as is allowed in 8.3. This creates an enormous > > potential for unfair practice giving the large players a huge > advantage. > > jay at impulse.net (Jay Hennigan) writes: > > > I am opposed to this proposal as written. I would support it if > section > > 8.3 were stricken in its entirety. > > is everyone fully aware that a version of this same policy has already > been > approved (2008-6) and stands to go into effect on june 1, and that > what's > being discussed here is a cleaned up version (2009-1)? > > that means, opposition to 2009-1's proposed 8.3 in ignorance of 2008- > 6's > effective 8.3 won't help any cause. to stop address space transfers > from > taking place apart from acquisitions, would require a new transfer > policy > that undid the effect of 2008-6. 2009-1 will not be *that* policy. > -- > Paul Vixie > KI6YSY > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 Wed May 27 17:57:58 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 27 May 2009 16:57:58 -0500 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <29A54911243620478FF59F00EBB12F47017E31BD@ex01.drtel.lan> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail><6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> <29A54911243620478FF59F00EBB12F47017E31BD@ex01.drtel.lan> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B268@mail> Brian, I think what Paul was saying is that 2008-6 is a done deal, and without a new policy to supercede it then community consensus et.al. no longer applies. It is what it is. Paul, I apologise if I paraphrased you badly or out of context. If I did please do not let it stand. What I understood may not have been what you said. Kevin > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Brian Johnson > Sent: Wednesday, May 27, 2009 4:35 PM > To: ppml at arin.net > Subject: Re: [arin-ppml] 2009-1 comment > > Paul, > > Is 2008-6 receiving wide approval by the community? Does this policy > coincide with the ARIN charter and the goals of the organization? > > Perhaps this is the issue? > > Just my .02 > > - Brian > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On > > Behalf Of Paul Vixie > > Sent: Wednesday, May 27, 2009 3:49 PM > > To: ppml at arin.net > > Subject: Re: [arin-ppml] 2009-1 comment > > > > these two messages bring up an important question. > > > > kkargel at polartel.com ("Kevin Kargel") writes: > > > > > My problem is the outright sale of space to a designated party > > without > > > transfer of network assets and without making the space available to > > the > > > community at large as is allowed in 8.3. This creates an enormous > > > potential for unfair practice giving the large players a huge > > advantage. > > > > jay at impulse.net (Jay Hennigan) writes: > > > > > I am opposed to this proposal as written. I would support it if > > section > > > 8.3 were stricken in its entirety. > > > > is everyone fully aware that a version of this same policy has already > > been > > approved (2008-6) and stands to go into effect on june 1, and that > > what's > > being discussed here is a cleaned up version (2009-1)? > > > > that means, opposition to 2009-1's proposed 8.3 in ignorance of 2008- > > 6's > > effective 8.3 won't help any cause. to stop address space transfers > > from > > taking place apart from acquisitions, would require a new transfer > > policy > > that undid the effect of 2008-6. 2009-1 will not be *that* policy. > > -- > > Paul Vixie > > KI6YSY > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing 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 scottleibrand at gmail.com Wed May 27 18:05:06 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 27 May 2009 17:05:06 -0500 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B268@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail><6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> <29A54911243620478FF59F00EBB12F47017E31BD@ex01.drtel.lan> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B268@mail> Message-ID: <4A1DB912.3090505@gmail.com> Kevin Kargel wrote: > Brian, > I think what Paul was saying is that 2008-6 is a done deal, and without a > new policy to supercede it then community consensus et.al. no longer > applies. It is what it is. > I don't speak for Paul, but yes, I think that is an accurate statement of the current situation. 2008-6 got consensus last year, and now we're working on cleaning up the detailed language through 2009-1. -Scott > Paul, > I apologise if I paraphrased you badly or out of context. If I did please > do not let it stand. What I understood may not have been what you said. > > Kevin > > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Brian Johnson >> Sent: Wednesday, May 27, 2009 4:35 PM >> To: ppml at arin.net >> Subject: Re: [arin-ppml] 2009-1 comment >> >> Paul, >> >> Is 2008-6 receiving wide approval by the community? Does this policy >> coincide with the ARIN charter and the goals of the organization? >> >> Perhaps this is the issue? >> >> Just my .02 >> >> - Brian >> >> >> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >>> >> On >> >>> Behalf Of Paul Vixie >>> Sent: Wednesday, May 27, 2009 3:49 PM >>> To: ppml at arin.net >>> Subject: Re: [arin-ppml] 2009-1 comment >>> >>> these two messages bring up an important question. >>> >>> kkargel at polartel.com ("Kevin Kargel") writes: >>> >>> >>>> My problem is the outright sale of space to a designated party >>>> >>> without >>> >>>> transfer of network assets and without making the space available to >>>> >>> the >>> >>>> community at large as is allowed in 8.3. This creates an enormous >>>> potential for unfair practice giving the large players a huge >>>> >>> advantage. >>> >>> jay at impulse.net (Jay Hennigan) writes: >>> >>> >>>> I am opposed to this proposal as written. I would support it if >>>> >>> section >>> >>>> 8.3 were stricken in its entirety. >>>> >>> is everyone fully aware that a version of this same policy has already >>> been >>> approved (2008-6) and stands to go into effect on june 1, and that >>> what's >>> being discussed here is a cleaned up version (2009-1)? >>> >>> that means, opposition to 2009-1's proposed 8.3 in ignorance of 2008- >>> 6's >>> effective 8.3 won't help any cause. to stop address space transfers >>> from >>> taking place apart from acquisitions, would require a new transfer >>> policy >>> that undid the effect of 2008-6. 2009-1 will not be *that* policy. >>> -- >>> Paul Vixie >>> KI6YSY >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing 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 jcurran at istaff.org Wed May 27 19:30:42 2009 From: jcurran at istaff.org (John Curran) Date: Wed, 27 May 2009 19:30:42 -0400 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B268@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> <6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> <29A54911243620478FF59F00EBB12F47017E31BD@ex01.drtel.lan> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B268@mail> Message-ID: <6ED1B5B8-CCB0-47F5-8DFE-85AFB9D01696@istaff.org> On May 27, 2009, at 5:57 PM, Kevin Kargel wrote: > > ... > I think what Paul was saying is that 2008-6 is a done deal, and > without a > new policy to supercede it then community consensus et.al. no longer > applies. It is what it is. I don't know if that's how I'd phrase it, but I'll leave it to Paul to say what he means one way or the other. I will note that 2008-6 has been adopted, and to the extent that one doesn't want an open transfer policy, it's incumbent on the community to suggest new policy proposals to the contrary. The question that's presently being discussed is whether people prefer the open transfer policy adopted as-is, or as-revised by 2009-1. The AC revised 2009-1 and sent it to the ARIN Board for adoption, so feedback on amending the existing open transfer policy in this manner would be quite useful. /John John Curran Acting President and CEO ARIN From vixie at isc.org Wed May 27 19:32:15 2009 From: vixie at isc.org (Paul Vixie) Date: Wed, 27 May 2009 23:32:15 +0000 Subject: [arin-ppml] 2009-1 comment In-Reply-To: Your message of "Wed, 27 May 2009 16:35:01 EST." <29A54911243620478FF59F00EBB12F47017E31BD@ex01.drtel.lan> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail><6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> <29A54911243620478FF59F00EBB12F47017E31BD@ex01.drtel.lan> Message-ID: <79861.1243467135@nsa.vix.com> brian johnson wrote: > From: bjohnson at drtel.com ("Brian Johnson") > Date: Wed, 27 May 2009 16:35:01 -0500 > > Paul, > > Is 2008-6 receiving wide approval by the community? Does this policy > coincide with the ARIN charter and the goals of the organization? > > Perhaps this is the issue? > > Just my .02 > > - Brian from what i can see here, some members of the community were unaware of 2008-6 when it was being developed, and some remain unaware that it was passed. i don't know what that means with respect to wide approval by the community. however, the board ratified 2008-6 on february 6 2009 based on our belief that the policy development process had been followed. i've learned nothing since then to indicate otherwise. so, 2008-6 will go into effect june 1 unless amended (for example, by 2009-1.) for anyone caught unaware by the passage of 2008-6, i suggest two things. first, help us improve community participation in the policy development process. that could mean becoming more engaged yourselves, but it could also mean getting people you know who ought to be here, to subscribe to the PPML also and if possible attend ARIN public policy meetings. it may also mean suggesting improvements to streamline the policy development process so as to encourage even greater community participation therein. second, consider authoring new policies to amend or redact any part of the NRPM that you think are incomplete or wrongheaded. (for example, some here think that 2008-6 added text to the NRPM that is incomplete, and some think that 2008-6 added text to the NRPM that is wrongheaded.) the NRPM is supposed to reflect the community's consensus on "the right policy." if that's not happening, then what we need is: more policy proposals. paul vixie chairman ARIN BoT From kkargel at polartel.com Thu May 28 11:16:37 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 28 May 2009 10:16:37 -0500 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <6ED1B5B8-CCB0-47F5-8DFE-85AFB9D01696@istaff.org> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> <6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> <29A54911243620478FF59F00EBB12F47017E31BD@ex01.drtel.lan> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B268@mail> <6ED1B5B8-CCB0-47F5-8DFE-85AFB9D01696@istaff.org> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B26C@mail> > -----Original Message----- > From: John Curran [mailto:jcurran at istaff.org] > Sent: Wednesday, May 27, 2009 6:31 PM > To: Kevin Kargel > Cc: arin ppml > Subject: Re: [arin-ppml] 2009-1 comment > > On May 27, 2009, at 5:57 PM, Kevin Kargel wrote: > > > > ... > > I think what Paul was saying is that 2008-6 is a done deal, and > > without a > > new policy to supercede it then community consensus et.al. no longer > > applies. It is what it is. > > I don't know if that's how I'd phrase it, but I'll leave it to Paul to > say what he means one way or the other. > > I will note that 2008-6 has been adopted, and to the extent that one > doesn't want an open transfer policy, it's incumbent on the community > to suggest new policy proposals to the contrary. > > The question that's presently being discussed is whether people prefer > the open transfer policy adopted as-is, or as-revised by 2009-1. The AC > revised 2009-1 and sent it to the ARIN Board for adoption, so feedback > on amending the existing open transfer policy in this manner would be > quite useful. > > /John > > John Curran > Acting President and CEO > ARIN > I would suggest the following codicils be added to make the transfer policy palatable.. A) Limit transfers from or to any party to no more than two in a one year period, or the rate limit in place for general transfers, whichever is less. B) Require an RSA or LRSA be in place and active for all blocks currently allocated to the receiving org and the releasing org. Require RSA for transferred space. C) Require reachability of all POC contacts associated with existing blocks that were /24 or larger for BOTH the "buyer" and the "seller". Verify email, telephone and mailing addresses. D) Releasing party is a member in good standing with ARIN. All dues and fees are paid. Accepting party either has or commits to obtain and maintain membership in good standing with ARIN. E) Space to be transferred to be released to ARIN and the IP space be placed in a holding pool (quarantine?) for 14 days. Effect transfer only if there are no general requests that would need to draw from that space in the holding pool in order to be fulfilled. When needed to satisfy general requests then space in the holding pool should be allocated in a first-in first-out date order. General allocations from the holding pool are not subject to the 14 day quarantine. Both releasing and receiving party POCs to be notified of a general allocation of the resource in question. The last amendment (E) is especially important to insure fair competition for dwindling resources by the community. What I tried to do with this was to say that general requests take priority over directed transfers. This way everyone will have a chance to compete for the resources. With this added I would tend to support 2009-1 . -------------- 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 May 28 11:28:35 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 28 May 2009 11:28:35 -0400 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <79861.1243467135@nsa.vix.com> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail><6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> <29A54911243620478FF59F00EBB12F47017E31BD@ex01.drtel.lan> <79861.1243467135@nsa.vix.com> Message-ID: <75822E125BCB994F8446858C4B19F0D77B2209BB@SUEX07-MBX-04.ad.syr.edu> > however, the board ratified 2008-6 on february 6 > 2009 based on our belief that the policy development process had been > followed. i've learned nothing since then to indicate otherwise. so, 2008-6 > will go into effect june 1 unless amended (for example, by 2009-1.) After re-reviewing 2009-1 and 2008-6, it's pretty clear that there's nothing wrong with 2008-6 and that 2009-1 was far more controversial and non-consensual. 2008-6 opens the door for the kind of transfers that adhere to the traditional "need" criteria while giving those with unneeded resources an incentive to release them. that's all that needs to be done at this point. RIPE has already done it, and the sky hasn't fallen. I support moving on with it, and would oppose any effort to reopen the issue until and unless the passed policy has actually been implemented long enough to assess its results. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org From jcurran at istaff.org Thu May 28 12:01:07 2009 From: jcurran at istaff.org (John Curran) Date: Thu, 28 May 2009 12:01:07 -0400 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B2209BB@SUEX07-MBX-04.ad.syr.edu> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> <6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> <29A54911243620478FF59F00EBB12F47017E31BD@ex01.drtel.lan> <79861.1243467135@nsa.vix.com> <75822E125BCB994F8446858C4B19F0D77B2209BB@SUEX07-MBX-04.ad.syr.edu> Message-ID: <7F3AC16F-6ACE-4B7C-BA2E-108FBD41EFE8@istaff.org> On May 28, 2009, at 11:28 AM, Milton L Mueller wrote: > > After re-reviewing 2009-1 and 2008-6, it's pretty clear that there's > nothing wrong with 2008-6 and that 2009-1 was far more controversial > and non-consensual. 2008-6 opens the door for the kind of transfers > that adhere to the traditional "need" criteria while giving those > with unneeded resources an incentive to release them. that's all > that needs to be done at this point. RIPE has already done it, and > the sky hasn't fallen. I support moving on with it, and would oppose > any effort to reopen the issue until and unless the passed policy > has actually been implemented long enough to assess its results. Milton - Could you express those aspects of 2009-1 that you object to? /John From michel at arneill-py.sacramento.ca.us Thu May 28 12:11:44 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 28 May 2009 09:11:44 -0700 Subject: [arin-ppml] 2009-1 comment Message-ID: 3:5026 An HTML attachment was scrubbed... URL: From michel at arneill-py.sacramento.ca.us Thu May 28 12:11:30 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 28 May 2009 09:11:30 -0700 Subject: [arin-ppml] 2009-1 comment Message-ID: 3:5028 An HTML attachment was scrubbed... URL: From Wesley.E.George at sprint.com Thu May 28 12:27:15 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Thu, 28 May 2009 11:27:15 -0500 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B26C@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> <6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> <29A54911243620478FF59F00EBB12F47017E31BD@ex01.drtel.lan> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B268@mail> <6ED1B5B8-CCB0-47F5-8DFE-85AFB9D01696@istaff.org> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B26C@mail> Message-ID: I have a minor issue with A, in that it's overbroad. I can understand limiting transfers between the same two parties to reduce abuses of the policy, but I don't see the value in limiting one party from receiving transfers from several different parties if they have justifiable need for the space and the resources to get it, or limiting one party from transferring blocks to several different parties if that's how they end up becoming available. It's quite possible that some parts of a block can be freed much more easily than others, and will lead to phased transfers. Rate-limiting them simply puts an artificial delay in making more blocks available for use. Also, while I don't have a problem with a holding period, I completely oppose the language giving general requests precedence over directed transfers in E. It's simply not going to make things any more fair. The idea behind the directed transfers is to offset the costs incurred by freeing those blocks to be reused. I understand that you're trying to prevent a speculation market and sale of/profiting from IP assets, or this becoming a market for haves vs have nots, but this would essentially eliminate any incentive to complete any but the most basic (i.e. cheap or no cost to complete) efforts to free up unused space in the first place. The standard "good internet citizens don't hoard IPv4 space they're not using" argument isn't going to cause companies to spend real time and money freeing up space instead of simply sitting on it and letting the chips fall where they may. Therefore the result will be less space available for reallocation for the whole community, not more space available for which "the little guy" can now compete fairly (bankrolled by those companies with deeper pockets). Thanks, Wes -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel Sent: Thursday, May 28, 2009 11:17 AM To: John Curran Cc: arin ppml Subject: Re: [arin-ppml] 2009-1 comment I would suggest the following codicils be added to make the transfer policy palatable.. A) Limit transfers from or to any party to no more than two in a one year period, or the rate limit in place for general transfers, whichever is less. B) Require an RSA or LRSA be in place and active for all blocks currently allocated to the receiving org and the releasing org. Require RSA for transferred space. C) Require reachability of all POC contacts associated with existing blocks that were /24 or larger for BOTH the "buyer" and the "seller". Verify email, telephone and mailing addresses. D) Releasing party is a member in good standing with ARIN. All dues and fees are paid. Accepting party either has or commits to obtain and maintain membership in good standing with ARIN. E) Space to be transferred to be released to ARIN and the IP space be placed in a holding pool (quarantine?) for 14 days. Effect transfer only if there are no general requests that would need to draw from that space in the holding pool in order to be fulfilled. When needed to satisfy general requests then space in the holding pool should be allocated in a first-in first-out date order. General allocations from the holding pool are not subject to the 14 day quarantine. Both releasing and receiving party POCs to be notified of a general allocation of the resource in question. The last amendment (E) is especially important to insure fair competition for dwindling resources by the community. What I tried to do with this was to say that general requests take priority over directed transfers. This way everyone will have a chance to compete for the resources. With this added I would tend to support 2009-1 . This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From mueller at syr.edu Thu May 28 12:14:43 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 28 May 2009 12:14:43 -0400 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <7F3AC16F-6ACE-4B7C-BA2E-108FBD41EFE8@istaff.org> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> <6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> <29A54911243620478FF59F00EBB12F47017E31BD@ex01.drtel.lan> <79861.1243467135@nsa.vix.com> <75822E125BCB994F8446858C4B19F0D77B2209BB@SUEX07-MBX-04.ad.syr.edu> <7F3AC16F-6ACE-4B7C-BA2E-108FBD41EFE8@istaff.org> Message-ID: <75822E125BCB994F8446858C4B19F0D77B2209C0@SUEX07-MBX-04.ad.syr.edu> Sorry, John, I see that my message left the impression that I thought there was something wrong with the language in 2009-1 authorizing transfers. There isn't. It's a bit more precise than 2008-6. My concern is with reopening the issue, when it seems that some folks clearly have the intent of re-opening the whole transfers issue. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org > -----Original Message----- > From: John Curran [mailto:jcurran at istaff.org] > Sent: Thursday, May 28, 2009 12:01 PM > To: Milton L Mueller > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] 2009-1 comment > > On May 28, 2009, at 11:28 AM, Milton L Mueller wrote: > > > > After re-reviewing 2009-1 and 2008-6, it's pretty clear > that there's > > nothing wrong with 2008-6 and that 2009-1 was far more > controversial > > and non-consensual. 2008-6 opens the door for the kind of > transfers > > that adhere to the traditional "need" criteria while giving those > > with unneeded resources an incentive to release them. that's all > > that needs to be done at this point. RIPE has already done it, and > > the sky hasn't fallen. I support moving on with it, and > would oppose > > any effort to reopen the issue until and unless the passed policy > > has actually been implemented long enough to assess its results. > > Milton - > > Could you express those aspects of 2009-1 that you object to? > > /John > > > From kkargel at polartel.com Thu May 28 13:27:21 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 28 May 2009 12:27:21 -0500 Subject: [arin-ppml] 2009-1 comment In-Reply-To: References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail><6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> <29A54911243620478FF59F00EBB12F47017E31BD@ex01.drtel.lan><70DE64CEFD6E9A4EB7FAF3A06314106601B4B268@mail><6ED1B5B8-CCB0-47F5-8DFE-85AFB9D01696@istaff.org> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B26C@mail> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B272@mail> > -----Original Message----- > From: George, Wes E [NTK] [mailto:Wesley.E.George at sprint.com] > Sent: Thursday, May 28, 2009 11:27 AM > To: Kevin Kargel; John Curran > Cc: arin ppml > Subject: RE: [arin-ppml] 2009-1 comment > > I have a minor issue with A, in that it's overbroad. I can understand > limiting transfers between the same two parties to reduce abuses of the > policy, but I don't see the value in limiting one party from receiving > transfers from several different parties if they have justifiable need for > the space and the resources to get it, or limiting one party from > transferring blocks to several different parties if that's how they end up > becoming available. It's quite possible that some parts of a block can be > freed much more easily than others, and will lead to phased transfers. > Rate-limiting them simply puts an artificial delay in making more blocks > available for use. > > Also, while I don't have a problem with a holding period, I completely > oppose the language giving general requests precedence over directed > transfers in E. It's simply not going to make things any more fair. > The idea behind the directed transfers is to offset the costs incurred by > freeing those blocks to be reused. I understand that you're trying to > prevent a speculation market and sale of/profiting from IP assets, or this > becoming a market for haves vs have nots, but this would essentially > eliminate any incentive to complete any but the most basic (i.e. cheap or > no cost to complete) efforts to free up unused space in the first place. > The standard "good internet citizens don't hoard IPv4 space they're not > using" argument isn't going to cause companies to spend real time and > money freeing up space instead of simply sitting on it and letting the > chips fall where they may. Therefore the result will be less space > available for reallocation for the whole community, not more space > available for which "the little guy" can now compete fairly (bankrolled by > those companies with deeper pockets). So long as there is free space available in the general pool then the transfer applicants would be unaffected. They would still be able to buy and sell their IP's Making the transfer pool available to the general pool would only come in to play post-runout. What this would do is that post runout organizations that do not have big bucks in their budgets will still have a shot at the space. If the only solution is to edge the small organizations out of competition then that is no solution at all. I would rather see ARIN drop out and resource registration revert to government. That is most likely what will happen anyway when the market problems start cropping up. There would be much more red tape and rigamarole but it would be an even playing field. Perhaps it is time for ARIN to be more aggressive in reclaiming swamp space. > > Thanks, > Wes -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From scottleibrand at gmail.com Thu May 28 13:54:58 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 28 May 2009 12:54:58 -0500 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B272@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail><6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> <29A54911243620478FF59F00EBB12F47017E31BD@ex01.drtel.lan><70DE64CEFD6E9A4EB7FAF3A06314106601B4B268@mail><6ED1B5B8-CCB0-47F5-8DFE-85AFB9D01696@istaff.org> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B26C@mail> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B272@mail> Message-ID: <4A1ECFF2.9090002@gmail.com> Kevin Kargel wrote: > > So long as there is free space available in the general pool then the > transfer applicants would be unaffected. They would still be able to buy > and sell their IP's Making the transfer pool available to the general pool > would only come in to play post-runout. What this would do is that post > runout organizations that do not have big bucks in their budgets will still > have a shot at the space. > > If the only solution is to edge the small organizations out of competition > then that is no solution at all. I would rather see ARIN drop out and > resource registration revert to government. That is most likely what will > happen anyway when the market problems start cropping up. There would be > much more red tape and rigamarole but it would be an even playing field. > You seem to be focusing entirely on the demand for IPv4 addresses, and ignoring the effect of price on the post-runout supply. If the supply of addresses freed up were somehow fixed (a certain number of addresses would be returned regardless), then the dynamics you describe would result in that tradeoff. However, the other side of it is this: Consider an organization with a large assignment that they've been using for a number of years. Over that time, it has been subnetted and allocated across their network in a manner that made sense at the time, but today would be considered inefficient. The organization could renumber their internal infrastructure to consolidate their addresses into a smaller portion of their original assignment, and free up the rest. However, doing so would require significant work, and therefore would not be justified if there is no benefit to the organization of returning the space. On the other hand, if the organization can make an arrangement with someone who needs the space, and get paid to transfer it to them once it's freed up, then there could be a business case to justify releasing the space. > Perhaps it is time for ARIN to be more aggressive in reclaiming swamp space. > Agreed. We have recently passed a few policies to give ARIN authority to do so (such as 2007-17: Legacy Outreach and Partial Reclamation, 2007-14: Resource Review Process). In addition, ARIN staff has been reaching out to verify the POCs in the database, which will put us in a better position to identify and start reclaiming blocks assigned to organizations that no longer exist. There's also Draft Policy 2008-7: Identify Invalid WHOIS POC's, which just went through last call, and it appears will be adopted shortly. There's still quite a bit of hard work to be done in this space, though. Additional suggestions are always welcome. -Scott From owen at delong.com Thu May 28 14:10:32 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 28 May 2009 11:10:32 -0700 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B26C@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> <6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> <29A54911243620478FF59F00EBB12F47017E31BD@ex01.drtel.lan> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B268@mail> <6ED1B5B8-CCB0-47F5-8DFE-85AFB9D01696@istaff.org> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B26C@mail> Message-ID: <582619E8-9AEE-4BB5-9AB1-6BB00671B232@delong.com> > I would suggest the following codicils be added to make the transfer > policy > palatable.. > > A) Limit transfers from or to any party to no more than two in a one > year > period, or the rate limit in place for general transfers, whichever > is less. > This would require new policy, which, you could propose by submitting a policy template available from the ARIN web site. If you need help with this process, let me know off list and I will be happy to help you. > B) Require an RSA or LRSA be in place and active for all blocks > currently > allocated to the receiving org and the releasing org. Require RSA for > transferred space. > The existing policy requires that the holder of the block prior to transfer have the block being transfered covered under RSA or LRSA. Further, an RSA is required of the receiving organization. The difference in what you propose would be the additional requirement for ALL blocks held by both organizations to be covered by (L)RSA, which, again, would require additional policy. > C) Require reachability of all POC contacts associated with existing > blocks > that were /24 or larger for BOTH the "buyer" and the "seller". Verify > email, telephone and mailing addresses. > This, too, would require policy. I am not sure what it would really accomplish beyond the intent of the WHOIS policy that was recently in last call. > D) Releasing party is a member in good standing with ARIN. All dues > and > fees are paid. Accepting party either has or commits to obtain and > maintain > > membership in good standing with ARIN. > This makes little sense. Most end user organizations that have IP space from ARIN are not currently members, and, there is no requirement for them to be members if they get space from ARIN. Why should they be required to be members in order to receive or give space in a transfer? > E) Space to be transferred to be released to ARIN and the IP space > be placed > > in a holding pool (quarantine?) for 14 days. Effect transfer only > if there > are no general requests that would need to draw from that space in the > holding pool in order to be fulfilled. When needed to satisfy general > requests then space in the holding pool should be allocated in a > first-in > first-out date order. General allocations from the holding pool are > not > subject to the 14 day quarantine. Both releasing and receiving > party POCs > to > be notified of a general allocation of the resource in question. > There is no way ARIN could implement this without new policy to support it. I strongly encourage you to submit this as a policy proposal if you feel it is needed. > The last amendment (E) is especially important to insure fair > competition > for > dwindling resources by the community. What I tried to do with this > was to > say > that general requests take priority over directed transfers. This way > everyone will have a chance to compete for the resources. With this > added I > > would tend to support 2009-1 . > Kevin, I am not sure you fully understand what, exactly, 2009-1 does. The policy proposal 2008-6 has been ratified by the board and will be implemented on June 1, 2009. Either as originally written with the clarified interpretation stated by the board, or, as modified by 2009-1 as updated by the Advisory Council at the San Antonio meeting. The question on the table with respect to transfer policy at this point is whether you prefer the 2009-1 modifications and clarifications to the process over the boards interpretation of 2008-6 or not. Frankly, other than the fact that 2009-1 removes the sunset clause and 2008-6 as interpreted by the board does not, I think the primary difference is clarity and explicit statement (2009-1) vs. interpretation (2008-6). Before you make too many assumptions about my opinion on the above subject, however, I suggest you review the minutes from the AC Meeting in San Antonio, which should be published shortly. 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 vixie at isc.org Thu May 28 16:24:32 2009 From: vixie at isc.org (Paul Vixie) Date: Thu, 28 May 2009 20:24:32 +0000 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B26C@mail> (Kevin Kargel's message of "Thu\, 28 May 2009 10\:16\:37 -0500") References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B254@mail> <6F93561B-5970-4BF6-9FC4-C2EF99233003@arin.net> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B263@mail> <29A54911243620478FF59F00EBB12F47017E31BD@ex01.drtel.lan> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B268@mail> <6ED1B5B8-CCB0-47F5-8DFE-85AFB9D01696@istaff.org> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B26C@mail> Message-ID: kkargel at polartel.com ("Kevin Kargel") writes: > I would suggest the following codicils be added to make the transfer > policy palatable.. > ... 2009-1 has been forwarded by the AC to the BoT in the form shown at and further community input to 2009-1 is therefore nonsequitur. if you wish to object to 2009-1 on the basis that the policy development process was not followed, please do so. if you wish to object to the policy development process on the basis that it does not properly gather community input or that it produces results that do not represent community consensus, please do so. if you wish to argue that 2009-1 as forwarded by the AC to the BoT on May 4 is wrongheaded or incomplete, then please submit a new policy proposal. -- Paul Vixie Chairman ARIN BoT From michael.dillon at bt.com Fri May 29 03:52:51 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 29 May 2009 08:52:51 +0100 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <4A1ECFF2.9090002@gmail.com> Message-ID: <28E139F46D45AF49A31950F88C4974580161E503@E03MVZ2-UKDY.domain1.systemhost.net> > Consider an organization with a large assignment that they've > been using for a number of years. Over that time, it has > been subnetted and allocated across their network in a manner > that made sense at the time, but today would be considered > inefficient. The organization could renumber their internal > infrastructure to consolidate their addresses into a smaller > portion of their original assignment, and free up the rest. I'd be surprised if an organisation with such a large assignment could achieve this renumbering in much less than 2 years. The transfer market won't be in existence long enough for them to actually sell these addresses unless they take a risk and start renumbering today. But when you balance the risks/rewards of renumbering to free up and sell an address block, versus deploying IPv6, it seems to me that the IPv6 effort wins out. In an era where every ISP has taken on the extra work involved in preparing for the IPv6 internet, and where budget is tight due to the overall economy, I don't see how anyone could justify a business case to sell IP addresses. Fact is that the IPv6 Internet will be upon us in about two years, and we expect the economy to be improving in about the same timescale. If a company is ready with IPv6 services in two years time, they could ride the wave, but if they have wasted that time in freeing up IP addresses, then they can only make one sale, and that's the end of it. Bad decision. -- Michael Dillon From mueller at syr.edu Fri May 29 10:45:42 2009 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 29 May 2009 10:45:42 -0400 Subject: [arin-ppml] 2009-1 comment In-Reply-To: <28E139F46D45AF49A31950F88C4974580161E503@E03MVZ2-UKDY.domain1.systemhost.net> References: <4A1ECFF2.9090002@gmail.com> <28E139F46D45AF49A31950F88C4974580161E503@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <75822E125BCB994F8446858C4B19F0D77B2209CD@SUEX07-MBX-04.ad.syr.edu> > I'd be surprised if an organisation with such a large > assignment could achieve this renumbering in much less > than 2 years. The transfer market won't be in existence > long enough for them to actually sell these addresses > unless they take a risk and start renumbering today. > > But when you balance the risks/rewards of renumbering > to free up and sell an address block, versus deploying > IPv6, it seems to me that the IPv6 effort wins out. > > In an era where every ISP has taken on the extra work > involved in preparing for the IPv6 internet, and where > budget is tight due to the overall economy, I don't see > how anyone could justify a business case to sell IP addresses. > Fact is that the IPv6 Internet will be upon us in about > two years, and we expect the economy to be improving in > about the same timescale. If a company is ready with > IPv6 services in two years time, they could ride the wave, > but if they have wasted that time in freeing up IP > addresses, then they can only make one sale, and that's > the end of it. Bad decision. Michael: You could be right. You could be wrong. A transfer market allows for both possibilities. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org From info at arin.net Fri May 29 11:11:13 2009 From: info at arin.net (Member Services) Date: Fri, 29 May 2009 11:11:13 -0400 Subject: [arin-ppml] Policy Proposal: Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries Message-ID: <4A1FFB11.9080101@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at:https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal: Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries Proposal Originator: Stacy Hughes and Andrew de la Haye Proposal Version: 1.0 Date: 29 May 2009 Proposal type: modify Policy term: permanent Policy statement: Modification of NRPM section 10.3 extending the deadline for an undifferentiated ASN pool by 1 year to read: 1. Allocation Principles IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010, allocations of 16-bit and 32-bit only ASN blocks will be made separately and independent of each other [1]. This means until 31 December 2010, RIRs can receive two separate ASN blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 16-bit and 32-bit only ASNs, and will operate ASN allocations from an undifferentiated 32-bit ASN allocation pool. Rationale: a. Arguments supporting the proposal Due to operational issues external to the IANA/RIR policy process, 32-bit only ASNs are not being issued by the RIRs at the anticipated rate. As it stands, RIRs will likely not be able to justify a new block of ASNs from the IANA after 31 December 2009 due to a glut of free 32 bit only ASNs in the RIR?s pool. This leaves available, essential 16-bit ASNs stranded in the IANA free pool. This proposal seeks to remedy the potential problem by extending the deadline for differentiation by one year. With this proposal the policy will be aligned with the actual reality in regards to 32-bit ASN deployment and usage. The subject was raised during RIPE 58 and a presentation was made: http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf The feedback in this session suggested that a global policy proposal should be developed and should be discussed. b. Arguments opposing the proposal Some may think that extending the previously set timeline can be perceived as some discouragement for the deployment of 32-bit ASNs. One counter argument to this is that RIRs and Internet community have some other mechanisms and activities to raise awareness for 32-bit ASN pool (via public presentations and trainings). These activities will continue while 16-bit ASN blocks are still allocated to RIRs by the IANA as they are available and they are needed. Timetable for implementation: Immediately upon ratification by ICANN Board From info at arin.net Fri May 29 11:14:45 2009 From: info at arin.net (Member Services) Date: Fri, 29 May 2009 11:14:45 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 Message-ID: <4A1FFBE5.20807@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at:https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Open Access To IPv6 Proposal Originator: Stacy Hughes and Cathy Aronson Proposal Version: 1.0 Date: 29 May 2009 Proposal type: modify Policy term: permanent Policy statement: 1) Remove ?by advertising that connectivity through its single aggregated address allocation? from article 3 of section 6.5.1.1 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years? in its entirety. Rationale: It is acknowledged that these concepts have been put before the community in the past. However, with the wisdom of actual operational experience, the necessity of promoting IPv6 adoption throughout our region, and emerging native v6 only network models, it becomes obvious that these modifications to the NRPM are necessary. Removing the 200 end site requirement enables smaller, but no less important and viable, networks access to IPv6. Removing the ?known ISP? requirement enfranchises new, native v6 businesses that can drive innovation and expansion in the Internet industry, as well as other industries. Removing the requirement for a single aggregate announcement benefits the NRPM itself, as it has been decided by the community that it should not contain routing advice. Timetable for implementation: immediately upon BoT ratification From michael.dillon at bt.com Fri May 29 11:42:30 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 29 May 2009 16:42:30 +0100 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A1FFE0E.7060805@arin.net> Message-ID: <28E139F46D45AF49A31950F88C4974580161EF03@E03MVZ2-UKDY.domain1.systemhost.net> > 2) Remove article 4 of section 6.5.1.1, "be an existing, > known ISP in the ARIN region or have a plan for making at > least 200 end-site assignments to other organizations within > 5 years" in its entirety. I'd rather see this restructured than removed because I think this bit is important: have a plan for making at least 200 end-site assignments to other organizations within 5 years This phrase tries to distill down the meaning of ISP in such a way that it is more inclusive than just those businesses who have ISP on their letterhead. I would favor something like: 4) have a plan for connecting their network to two or more network service providers, and making at least 40 end-site assignments per year on average over the next 5 years 5) existing, known ISPs in the ARIN region will be assumed to already meet the requirement in clause 4 above. -- Michael Dillon From sethm at rollernet.us Fri May 29 11:58:49 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 29 May 2009 08:58:49 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A1FFBE5.20807@arin.net> References: <4A1FFBE5.20807@arin.net> Message-ID: <4A200639.4030209@rollernet.us> Member Services wrote: > > > ## * ## > > > Policy Proposal Name: Open Access To IPv6 > > Proposal Originator: Stacy Hughes and Cathy Aronson > > Proposal Version: 1.0 > > Date: 29 May 2009 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > 1) Remove ?by advertising that connectivity through its single > aggregated address allocation? from article 3 of section 6.5.1.1 What's the rationale for this proposed change? ~Seth From sethm at rollernet.us Fri May 29 12:02:12 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 29 May 2009 09:02:12 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A200639.4030209@rollernet.us> References: <4A1FFBE5.20807@arin.net> <4A200639.4030209@rollernet.us> Message-ID: <4A200704.9050909@rollernet.us> Seth Mattinen wrote: > Member Services wrote: > >> >> ## * ## >> >> >> Policy Proposal Name: Open Access To IPv6 >> >> Proposal Originator: Stacy Hughes and Cathy Aronson >> >> Proposal Version: 1.0 >> >> Date: 29 May 2009 >> >> Proposal type: modify >> >> Policy term: permanent >> >> Policy statement: >> >> 1) Remove ?by advertising that connectivity through its single >> aggregated address allocation? from article 3 of section 6.5.1.1 > > What's the rationale for this proposed change? > Nevermind, I somehow missed it. In either case, it's probably a bad idea to encourage mass deaggregation for "traffic engineering" purposes in IPv6 land since the space is so much bigger. ~Seth From ipgoddess.arin at gmail.com Fri May 29 12:02:32 2009 From: ipgoddess.arin at gmail.com (Stacy Hughes) Date: Fri, 29 May 2009 09:02:32 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A200639.4030209@rollernet.us> References: <4A1FFBE5.20807@arin.net> <4A200639.4030209@rollernet.us> Message-ID: <24c86a5f0905290902w1eeb3188i6ca4f7961edbbf92@mail.gmail.com> Hi Seth,I removed the single aggregate requirement primarily because it has been decided the NRPM should not contain routing or operational advice. Cheers, Stacy On Fri, May 29, 2009 at 8:58 AM, Seth Mattinen wrote: > Member Services wrote: > > > > > > > ## * ## > > > > > > Policy Proposal Name: Open Access To IPv6 > > > > Proposal Originator: Stacy Hughes and Cathy Aronson > > > > Proposal Version: 1.0 > > > > Date: 29 May 2009 > > > > Proposal type: modify > > > > Policy term: permanent > > > > Policy statement: > > > > 1) Remove ?by advertising that connectivity through its single > > aggregated address allocation? from article 3 of section 6.5.1.1 > > What's the rationale for this proposed change? > > ~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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppml at rsuc.gweep.net Fri May 29 12:02:46 2009 From: ppml at rsuc.gweep.net (Joe Provo) Date: Fri, 29 May 2009 12:02:46 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A200639.4030209@rollernet.us> References: <4A1FFBE5.20807@arin.net> <4A200639.4030209@rollernet.us> Message-ID: <20090529160246.GA23729@gweep.net> On Fri, May 29, 2009 at 08:58:49AM -0700, Seth Mattinen wrote: > Member Services wrote: [snip] > > 1) Remove ???by advertising that connectivity through its single > > aggregated address allocation??? from article 3 of section 6.5.1.1 > > What's the rationale for this proposed change? It better reflects the reality of the meshy global Internet where aggregated trunk, backbone-only providers are a rare and dying breed. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From michael.dillon at bt.com Fri May 29 12:15:33 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 29 May 2009 17:15:33 +0100 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A200704.9050909@rollernet.us> Message-ID: <28E139F46D45AF49A31950F88C4974580161EF87@E03MVZ2-UKDY.domain1.systemhost.net> > In either case, it's probably a bad idea to encourage mass > deaggregation for "traffic engineering" purposes in IPv6 land > since the space is so much bigger. Removing an unenforceable clause is NOT encouraging mass deaggregation. It seems to me that the network operator community already has the levers that it needs to keep deaggregation to a reasonable level. --Michael Dillon From ipgoddess.arin at gmail.com Fri May 29 12:25:08 2009 From: ipgoddess.arin at gmail.com (Stacy Hughes) Date: Fri, 29 May 2009 09:25:08 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A1FFBE5.20807@arin.net> References: <4A1FFBE5.20807@arin.net> Message-ID: <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> Hello Everyone,Before we really get started on this policy proposal, I must give credit where credit is due. Jordi Palet Martinez brought this topic to the table 3 years ago, and it got shot down. I myself, in my small IPv4-centric mind, thought it impossible that an IPv6 only organization could exist. Operations and innovation have shown me the error of our thinking. To quote myself from a different list: IPv6 is a new paradigm we are supposed to be doing our best to encourage. As it stands, those community guys can't get it, the Caribbean guys can't get it, and basically anyone trying to do anything vanguard can't get it either. (I hear the ULA objections here, even when they're nascent). We can be afraid of what IPv6 might do to the routing table, or we can embrace what IPv6 can and will do for the Internet. I choose the latter and support this proposal. Stacy On Fri, May 29, 2009 at 8:14 AM, Member Services wrote: > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with Policy Development > Process. > > This proposal is in the first stage of the Policy Development Process. > ARIN staff will perform the Clarity and Understanding step. Staff does > not evaluate the proposal at this time, their goal is to make sure that > they understand the proposal and believe the community will as well. > Staff will report their results to the ARIN Advisory Council (AC) within > 10 days. > > The AC will review the proposal at their next regularly scheduled > meeting (if the period before the next regularly scheduled meeting is > less than 10 days, then the period may be extended to the subsequent > regularly scheduled meeting). The AC will decide how to utilize the > proposal and announce the decision to the PPML. > > In the meantime, the AC invites everyone to comment on the proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at:https://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Open Access To IPv6 > > Proposal Originator: Stacy Hughes and Cathy Aronson > > Proposal Version: 1.0 > > Date: 29 May 2009 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > 1) Remove ?by advertising that connectivity through its single > aggregated address allocation? from article 3 of section 6.5.1.1 > > 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in > the ARIN region or have a plan for making at least 200 end-site > assignments to other organizations within 5 years? in its entirety. > > Rationale: It is acknowledged that these concepts have been put before > the community in the past. However, with the wisdom of actual > operational experience, the necessity of promoting IPv6 adoption > throughout our region, and emerging native v6 only network models, it > becomes obvious that these modifications to the NRPM are necessary. > Removing the 200 end site requirement enables smaller, but no less > important and viable, networks access to IPv6. Removing the ?known ISP? > requirement enfranchises new, native v6 businesses that can drive > innovation and expansion in the Internet industry, as well as other > industries. Removing the requirement for a single aggregate announcement > benefits the NRPM itself, as it has been decided by the community that > it should not contain routing advice. > > Timetable for implementation: immediately upon BoT ratification > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmalayter at switchanddata.com Fri May 29 12:27:57 2009 From: cmalayter at switchanddata.com (Chris Malayter) Date: Fri, 29 May 2009 11:27:57 -0500 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> Message-ID: I support this proposal. -Chris On 5/29/09 11:25 AM, "Stacy Hughes" wrote: > Hello Everyone, > Before we really get started on this policy proposal, I must give credit where > credit is due. > Jordi Palet Martinez brought this topic to the table 3 years ago, and it got > shot down. ?I myself, in my small IPv4-centric mind, thought it impossible > that an IPv6 only organization could exist. ?Operations and innovation have > shown me the error of our thinking. > To quote myself from a different list: > IPv6 is a new paradigm we are supposed to be doing our best to encourage. ?As > it stands, those community guys can't get it, the Caribbean guys can't get it, > and basically anyone trying to do anything vanguard can't get it either. ?(I > hear the ULA objections here, even when they're?nascent).? > > We can be afraid of what IPv6 might do to the routing table, or we can embrace > what IPv6 can and will do for the Internet. > I choose the latter and support this proposal. > Stacy? > > > On Fri, May 29, 2009 at 8:14 AM, Member Services wrote: >> ARIN received the following policy proposal and is posting it to the >> Public Policy Mailing List (PPML) in accordance with Policy Development >> Process. >> >> This proposal is in the first stage of the Policy Development Process. >> ARIN staff will perform the Clarity and Understanding step. Staff does >> not evaluate the proposal at this time, their goal is to make sure that >> they understand the proposal and believe the community will as well. >> Staff will report their results to the ARIN Advisory Council (AC) within >> 10 days. >> >> The AC will review the proposal at their next regularly scheduled >> meeting (if the period before the next regularly scheduled meeting is >> less than 10 days, then the period may be extended to the subsequent >> regularly scheduled meeting). The AC will decide how to utilize the >> proposal and announce the decision to the PPML. >> >> In the meantime, the AC invites everyone to comment on the proposal on >> the PPML, particularly their support or non-support and the reasoning >> behind their opinion. Such participation contributes to a thorough >> vetting and provides important guidance to the AC in their deliberations. >> >> The ARIN Policy Development Process can be found at: >> https://www.arin.net/policy/pdp.html >> >> Mailing list subscription information can be found >> at:https://www.arin.net/mailing_lists/ >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Policy Proposal Name: Open Access To IPv6 >> >> Proposal Originator: Stacy Hughes and Cathy Aronson >> >> Proposal Version: 1.0 >> >> Date: 29 May 2009 >> >> Proposal type: modify >> >> Policy term: permanent >> >> Policy statement: >> >> 1) Remove ?by advertising that connectivity through its single >> aggregated address allocation? from article 3 of section 6.5.1.1 >> >> 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in >> the ARIN region or have a plan for making at least 200 end-site >> assignments to other organizations within 5 years? in its entirety. >> >> Rationale: It is acknowledged that these concepts have been put before >> the community in the past. However, with the wisdom of actual >> operational experience, the necessity of promoting IPv6 adoption >> throughout our region, and emerging native v6 only network models, it >> becomes obvious that these modifications to the NRPM are necessary. >> Removing the 200 end site requirement enables smaller, but no less >> important and viable, networks access to IPv6. Removing the ?known ISP? >> requirement enfranchises new, native v6 businesses that can drive >> innovation and expansion in the Internet industry, as well as other >> industries. Removing the requirement for a single aggregate announcement >> benefits the NRPM itself, as it has been decided by the community that >> it should not contain routing advice. >> >> Timetable for implementation: immediately upon BoT ratification >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Fri May 29 12:45:56 2009 From: farmer at umn.edu (David Farmer) Date: Fri, 29 May 2009 11:45:56 -0500 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529160246.GA23729@gweep.net> References: <4A1FFBE5.20807@arin.net>, <4A200639.4030209@rollernet.us>, <20090529160246.GA23729@gweep.net> Message-ID: <4A1FCAF4.17167.3844C41@farmer.umn.edu> On 29 May 2009 Joe Provo wrote: > On Fri, May 29, 2009 at 08:58:49AM -0700, Seth Mattinen wrote: > > Member Services wrote: > [snip] > > > 1) Remove ???by advertising that connectivity through its single > > > aggregated address allocation??? from article 3 of section 6.5.1.1 > > > > What's the rationale for this proposed change? > > It better reflects the reality of the meshy global Internet where > aggregated trunk, backbone-only providers are a rare and dying breed. Additionally, I believe it may remove the need for for proposal 84. IPv6 Multiple Discrete Networks. What to those that support that proposal think? Honestly, I would prefer people deaggregate their /32 rather then getting multiple /32s. It might be possible in some cases to reaggregate the /32 in the future or in other network that want/can manage there route table more than others. But it wouldn't be very likely that you could ever aggregate separate /32s once they were assigned. So I believe we should eliminate the requirement, but honestly I'd like something like the following to remain "If technically possible an overall aggregate should be announced in addition to any shorter routes". I'd still like the general expectation to be that you announce an aggregate if you can. Overall I support this proposal. =============================================== 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 sethm at rollernet.us Fri May 29 12:56:53 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 29 May 2009 09:56:53 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> References: <4A1FFBE5.20807@arin.net> <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> Message-ID: <4A2013D5.1070902@rollernet.us> Stacy Hughes wrote: > Hello Everyone, > Before we really get started on this policy proposal, I must give credit > where credit is due. > Jordi Palet Martinez brought this topic to the table 3 years ago, and it > got shot down. I myself, in my small IPv4-centric mind, thought it > impossible that an IPv6 only organization could exist. Operations and > innovation have shown me the error of our thinking. > To quote myself from a different list: > IPv6 is a new paradigm we are supposed to be doing our best to > encourage. As it stands, those community guys can't get it, the > Caribbean guys can't get it, and basically anyone trying to do anything > vanguard can't get it either. (I hear the ULA objections here, even > when they're nascent). > > We can be afraid of what IPv6 might do to the routing table, or we can > embrace what IPv6 can and will do for the Internet. > I choose the latter and support this proposal. I'm not talking about the weird-ass "everything goes into an aggregate of your upstream and the global table only has 100 routes in it ever" thing. I'm referring to the actual practice of multihoming and default-free routing. I'm of two minds on these kind of issues: I think one should advertise the prefix as given, not make something up because it makes your routes look more better good. I also understand that large networks with multiple sites may have a /32 and split it across their sites. At the same time, I use DRAM-based border routers so it won't affect me personally because I know there are enough of people who don't care. I planned ahead for IPv6 because I knew hardware platforms available at the time would be insufficient for future IPv6 use. Others may have listed to a sales person, or not originally planned for IPv6, see they should have IPv6 now, but find their $500k equipment they can't afford to replace for 5 years isn't good enough because of dumb routing policies. I don't have any real numbers, but it feels counterproductive to potentially shut people out of IPv6 adoption. ~Seth From jordi.palet at consulintel.es Fri May 29 12:51:23 2009 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 29 May 2009 11:51:23 -0500 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> Message-ID: Hi Stacy, Thanks for the credit :-) I guess is important to realize that, unless I?m wrong, right now this requirement (200 networks), is no longer there in the rest of the RIRs, at least I tried my best to get it removed ! Regards, Jordi From: Stacy Hughes Reply-To: Date: Fri, 29 May 2009 09:25:08 -0700 To: Member Services Cc: Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6 Hello Everyone, Before we really get started on this policy proposal, I must give credit where credit is due. Jordi Palet Martinez brought this topic to the table 3 years ago, and it got shot down. ?I myself, in my small IPv4-centric mind, thought it impossible that an IPv6 only organization could exist. ?Operations and innovation have shown me the error of our thinking. To quote myself from a different list: IPv6 is a new paradigm we are supposed to be doing our best to encourage. ?As it stands, those community guys can't get it, the Caribbean guys can't get it, and basically anyone trying to do anything vanguard can't get it either. ?(I hear the ULA objections here, even when they're?nascent).? We can be afraid of what IPv6 might do to the routing table, or we can embrace what IPv6 can and will do for the Internet. I choose the latter and support this proposal. Stacy? On Fri, May 29, 2009 at 8:14 AM, Member Services wrote: > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with Policy Development > Process. > > This proposal is in the first stage of the Policy Development Process. > ARIN staff will perform the Clarity and Understanding step. Staff does > not evaluate the proposal at this time, their goal is to make sure that > they understand the proposal and believe the community will as well. > Staff will report their results to the ARIN Advisory Council (AC) within > 10 days. > > The AC will review the proposal at their next regularly scheduled > meeting (if the period before the next regularly scheduled meeting is > less than 10 days, then the period may be extended to the subsequent > regularly scheduled meeting). The AC will decide how to utilize the > proposal and announce the decision to the PPML. > > In the meantime, the AC invites everyone to comment on the proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at:https://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Open Access To IPv6 > > Proposal Originator: Stacy Hughes and Cathy Aronson > > Proposal Version: 1.0 > > Date: 29 May 2009 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > 1) Remove ?by advertising that connectivity through its single > aggregated address allocation? from article 3 of section 6.5.1.1 > > 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in > the ARIN region or have a plan for making at least 200 end-site > assignments to other organizations within 5 years? in its entirety. > > Rationale: It is acknowledged that these concepts have been put before > the community in the past. However, with the wisdom of actual > operational experience, the necessity of promoting IPv6 adoption > throughout our region, and emerging native v6 only network models, it > becomes obvious that these modifications to the NRPM are necessary. > Removing the 200 end site requirement enables smaller, but no less > important and viable, networks access to IPv6. Removing the ?known ISP? > requirement enfranchises new, native v6 businesses that can drive > innovation and expansion in the Internet industry, as well as other > industries. Removing the requirement for a single aggregate announcement > benefits the NRPM itself, as it has been decided by the community that > it should not contain routing advice. > > Timetable for implementation: immediately upon BoT ratification > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From terry.l.davis at boeing.com Fri May 29 12:48:35 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Fri, 29 May 2009 09:48:35 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> References: <4A1FFBE5.20807@arin.net> <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> Message-ID: <2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com> Stacy I fully support this proposal. I think we can look at the current almost total lack of IPv6 implementation anywhere (not even significantly in universities and not at all in startups) and realize that our current policies are not supporting/encouraging v6 implementations. Take care Terry ________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Stacy Hughes Sent: Friday, May 29, 2009 9:25 AM To: Member Services Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6 Hello Everyone, Before we really get started on this policy proposal, I must give credit where credit is due. Jordi Palet Martinez brought this topic to the table 3 years ago, and it got shot down. I myself, in my small IPv4-centric mind, thought it impossible that an IPv6 only organization could exist. Operations and innovation have shown me the error of our thinking. To quote myself from a different list: IPv6 is a new paradigm we are supposed to be doing our best to encourage. As it stands, those community guys can't get it, the Caribbean guys can't get it, and basically anyone trying to do anything vanguard can't get it either. (I hear the ULA objections here, even when they're nascent). We can be afraid of what IPv6 might do to the routing table, or we can embrace what IPv6 can and will do for the Internet. I choose the latter and support this proposal. Stacy On Fri, May 29, 2009 at 8:14 AM, Member Services > wrote: ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at:https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Open Access To IPv6 Proposal Originator: Stacy Hughes and Cathy Aronson Proposal Version: 1.0 Date: 29 May 2009 Proposal type: modify Policy term: permanent Policy statement: 1) Remove "by advertising that connectivity through its single aggregated address allocation" from article 3 of section 6.5.1.1 2) Remove article 4 of section 6.5.1.1, "be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years" in its entirety. Rationale: It is acknowledged that these concepts have been put before the community in the past. However, with the wisdom of actual operational experience, the necessity of promoting IPv6 adoption throughout our region, and emerging native v6 only network models, it becomes obvious that these modifications to the NRPM are necessary. Removing the 200 end site requirement enables smaller, but no less important and viable, networks access to IPv6. Removing the 'known ISP' requirement enfranchises new, native v6 businesses that can drive innovation and expansion in the Internet industry, as well as other industries. Removing the requirement for a single aggregate announcement benefits the NRPM itself, as it has been decided by the community that it should not contain routing advice. Timetable for implementation: immediately upon BoT ratification _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bicknell at ufp.org Fri May 29 13:42:53 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 29 May 2009 13:42:53 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A1FFBE5.20807@arin.net> References: <4A1FFBE5.20807@arin.net> Message-ID: <20090529174253.GB94380@ussenterprise.ufp.org> In a message written on Fri, May 29, 2009 at 11:14:45AM -0400, Member Services wrote: > 1) Remove ?by advertising that connectivity through its single > aggregated address allocation? from article 3 of section 6.5.1.1 > > 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in > the ARIN region or have a plan for making at least 200 end-site > assignments to other organizations within 5 years? in its entirety. I fear the way this is written may be confusing. Section 6.5.1.1 is at https://www.arin.net/policy/nrpm.html#six511 If these changes were made, I believe the section would then read: 6.5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: 1. be an LIR; 2. not be an end site; 3. plan to provide IPv6 connectivity to organizations to which it will assign IPv6 address space. I would like to make two comments as a result. Criteria #1 doesn't make a lot of sense. If you were a new participant (no IPv4 or IPv6 resources at all) and going only for IPv6 then you aren't an LIR yet, indeed, you are trying to become one. I think, but cannot be sure, that the LIR reference has to do with fee/membership structures of other RIR's. The result of this policy is basically you get an allocation if you want one and can show you will provide IPv6 to another entity and are willing to pay the fees. This is too loose of a standard. While I believe we should be giving out IPv6 relatively easily and there is no danger in running out of the numbers that does not mean we don't still have the issue of routing slots, staff to deal with the number of requests, and other issues. To that end, I would like to suggest a new criteria: - Plan to announce the IPv6 address space provided to at least two other autonomous systems. Basically, setting the bar at being multi-homed to BGP speaking networks. No number of sites requirement, you only need 1 customer to meet the customer requirement. -- 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: 825 bytes Desc: not available URL: From ipgoddess.arin at gmail.com Fri May 29 13:49:02 2009 From: ipgoddess.arin at gmail.com (Stacy Hughes) Date: Fri, 29 May 2009 10:49:02 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529174253.GB94380@ussenterprise.ufp.org> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> Message-ID: <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> A multihoming requirement discriminates against networks that either cannot or do not want to multihome.I oppose this modification. Stacy On Fri, May 29, 2009 at 10:42 AM, Leo Bicknell wrote: > In a message written on Fri, May 29, 2009 at 11:14:45AM -0400, Member > Services wrote: > > 1) Remove ?by advertising that connectivity through its single > > aggregated address allocation? from article 3 of section 6.5.1.1 > > > > 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in > > the ARIN region or have a plan for making at least 200 end-site > > assignments to other organizations within 5 years? in its entirety. > > I fear the way this is written may be confusing. Section 6.5.1.1 is at > https://www.arin.net/policy/nrpm.html#six511 > > If these changes were made, I believe the section would then read: > > 6.5.1.1. Initial allocation criteria > > To qualify for an initial allocation of IPv6 address space, an > organization must: > > 1. be an LIR; > 2. not be an end site; > 3. plan to provide IPv6 connectivity to organizations to which it > will assign IPv6 address space. > > I would like to make two comments as a result. > > Criteria #1 doesn't make a lot of sense. If you were a new participant > (no IPv4 or IPv6 resources at all) and going only for IPv6 then you > aren't an LIR yet, indeed, you are trying to become one. I think, > but cannot be sure, that the LIR reference has to do with fee/membership > structures of other RIR's. > > The result of this policy is basically you get an allocation if you > want one and can show you will provide IPv6 to another entity and > are willing to pay the fees. This is too loose of a standard. > While I believe we should be giving out IPv6 relatively easily and > there is no danger in running out of the numbers that does not mean > we don't still have the issue of routing slots, staff to deal with > the number of requests, and other issues. > > To that end, I would like to suggest a new criteria: > > - Plan to announce the IPv6 address space provided to at least > two other autonomous systems. > > Basically, setting the bar at being multi-homed to BGP speaking > networks. No number of sites requirement, you only need 1 customer > to meet the customer requirement. > > -- > 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 bjohnson at drtel.com Fri May 29 14:31:23 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Fri, 29 May 2009 13:31:23 -0500 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529174253.GB94380@ussenterprise.ufp.org> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> Message-ID: <29A54911243620478FF59F00EBB12F47017E32AA@ex01.drtel.lan> > To that end, I would like to suggest a new criteria: > > - Plan to announce the IPv6 address space provided to at least > two other autonomous systems. > Wouldn't this criteria exclude providers who have no current, or immediately pending, customers for IPv6, have no customers who are multi-homed to another provider (no need for their own IPv6 space from ARIN), or are not transit networks? If so, it would exclude many regional ISPs. - Brian? From michael.dillon at bt.com Fri May 29 14:36:26 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 29 May 2009 19:36:26 +0100 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C4974580161F064@E03MVZ2-UKDY.domain1.systemhost.net> > A multihoming requirement discriminates against networks > that either cannot or do not want to multihome. Not if you use something like the wording I suggested where you explicitly say that all ISPs are assumed to qualify. The point is that we don't want to give /32 to just anyone. There must be some barrier and by design, the /32 allocation with /48 assignment architecture was created so that service providers get a /32. Now using the term ISP or LIR is far too restrictive because there are other types of service providers ranging from universities to freenets to corporate subsidiaries that run a global WAN for their corporate sites. Any of these is a service provider and should get a /32. A small ISP with one upstream should also get one but if we say "either an ISP or meet specific tests" then we cover both bases. Just deleting some bits from the policy is not sufficient. The whole section needs to be rewritten to fairly state the intent. I did suggest requiring a plan for 40 assignments per year, on average, over 5 years, which is a way of leaving the number 200 in place but hiding it so that it isn't so scary to people who don't read carefully. I would also support a number lower than 200, but suggest that we also use the structure that I used. It would be interesting to see the substantive comments that were made about the number 200 when we discussed this before but I'm not sure when that was or how much "too big" the 200 number was being interpreted by people. --Michael Dillon From cmalayter at switchanddata.com Fri May 29 14:18:20 2009 From: cmalayter at switchanddata.com (Chris Malayter) Date: Fri, 29 May 2009 13:18:20 -0500 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> Message-ID: Agree with Stacy here, I don?t think putting strings on v6 is going help drive it?s implementation. -Chris On 5/29/09 12:49 PM, "Stacy Hughes" wrote: > ?A multihoming requirement discriminates against networks that either cannot > or do not want to multihome. > I oppose this modification. > Stacy? > > On Fri, May 29, 2009 at 10:42 AM, Leo Bicknell wrote: >> In a message written on Fri, May 29, 2009 at 11:14:45AM -0400, Member >> Services wrote: >>> > 1) Remove ?by advertising that connectivity through its single >>> > aggregated address allocation? from article 3 of section 6.5.1.1 >>> > >>> > 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in >>> > the ARIN region or have a plan for making at least 200 end-site >>> > assignments to other organizations within 5 years? in its entirety. >> >> I fear the way this is written may be confusing. ?Section 6.5.1.1 is at >> https://www.arin.net/policy/nrpm.html#six511 >> >> If these changes were made, I believe the section would then read: >> >> ?6.5.1.1. Initial allocation criteria >> >> ?To qualify for an initial allocation of IPv6 address space, an >> ?organization must: >> >> ? 1. be an LIR; >> ? 2. not be an end site; >> ? 3. plan to provide IPv6 connectivity to organizations to which it >> ? ? ?will assign IPv6 address space. >> >> I would like to make two comments as a result. >> >> Criteria #1 doesn't make a lot of sense. ?If you were a new participant >> (no IPv4 or IPv6 resources at all) and going only for IPv6 then you >> aren't an LIR yet, indeed, you are trying to become one. ?I think, >> but cannot be sure, that the LIR reference has to do with fee/membership >> structures of other RIR's. >> >> The result of this policy is basically you get an allocation if you >> want one and can show you will provide IPv6 to another entity and >> are willing to pay the fees. ?This is too loose of a standard. >> While I believe we should be giving out IPv6 relatively easily and >> there is no danger in running out of the numbers that does not mean >> we don't still have the issue of routing slots, staff to deal with >> the number of requests, and other issues. >> >> To that end, I would like to suggest a new criteria: >> >> ?- Plan to announce the IPv6 address space provided to at least >> ? ?two other autonomous systems. >> >> Basically, setting the bar at being multi-homed to BGP speaking >> networks. ?No number of sites requirement, you only need 1 customer >> to meet the customer requirement. >> >> -- >> ? ? ? 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. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 ppml at rsuc.gweep.net Fri May 29 14:58:41 2009 From: ppml at rsuc.gweep.net (Joe Provo) Date: Fri, 29 May 2009 14:58:41 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529174253.GB94380@ussenterprise.ufp.org> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> Message-ID: <20090529185841.GA87992@gweep.net> On Fri, May 29, 2009 at 01:42:53PM -0400, Leo Bicknell wrote: [snip] > To that end, I would like to suggest a new criteria: > > - Plan to announce the IPv6 address space provided to at least > two other autonomous systems. > > Basically, setting the bar at being multi-homed to BGP speaking > networks. No number of sites requirement, you only need 1 customer > to meet the customer requirement. Leo, I appreciate the intent, but what's the point of yet another unenforcable clause? Enterprises with multiple private BGP relationships would qualifiy under this and be invisible. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From matthew at matthew.at Fri May 29 15:02:27 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 29 May 2009 12:02:27 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <28E139F46D45AF49A31950F88C4974580161F064@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C4974580161F064@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4A203143.5010908@matthew.at> michael.dillon at bt.com wrote: >> A multihoming requirement discriminates against networks >> that either cannot or do not want to multihome. >> > > Not if you use something like the wording I suggested > where you explicitly say that all ISPs are assumed > to qualify. > > The point is that we don't want to give /32 to just > anyone. Why? Either there's enough that doing that has no risk of ever running out, or there aren't enough, in which case *all* the existing policies are too liberal. If your argument is routing table size, that's a separate problem that isn't ARIN's problem. Back in the (actually not so) early IPv4 days, I got an IPv4 /24 for my house. My friends and I learned a whole lot about setting up IP networks using our real-world address. Didn't cost us a cent, and many of us have gone on to do more interesting things in the Internet world. Today, if my kids wanted to get a real IPv6 /32 to play with, they'd have to pay a bunch of money and fill out a bunch of paperwork. So they won't be doing that. Even though there's plenty of IPv6 space for everyone on the planet to play. Either we want to encourage adoption or we want to keep this as tightly controlled as IPv4 has become. The former seems like a better idea, given how IPv4 is going. Matthew Kaufman From owen at delong.com Fri May 29 15:07:41 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 29 May 2009 12:07:41 -0700 Subject: [arin-ppml] Policy Proposal: Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries In-Reply-To: <4A1FFB11.9080101@arin.net> References: <4A1FFB11.9080101@arin.net> Message-ID: <12535BF9-2693-4480-88E1-ED7139A88B58@delong.com> While I do not support changing the RIR policy on the issuance of ASNs, I do support this policy proposal. I think that modifying the IANA->RIR distribution rules to accommodate the needs of RIRs to better serve their constituents makes sense. Further, having 16-bit ASNs trapped in the IANA free pool because 32-bit ASNs are not being accepted by recipients is absurd and poor stewardship. We should go ahead and issue 16-bit ASNs until they run out. I would suggest that this proposal, rather than removing the distinction in 2010 should be modified to extend the IANA->RIR duality until such time as there are no more 16-bit ASN blocks in the IANA pool. Owen On May 29, 2009, at 8:11 AM, Member Services wrote: > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with Policy > Development > Process. > > This proposal is in the first stage of the Policy Development Process. > ARIN staff will perform the Clarity and Understanding step. Staff does > not evaluate the proposal at this time, their goal is to make sure > that > they understand the proposal and believe the community will as well. > Staff will report their results to the ARIN Advisory Council (AC) > within > 10 days. > > The AC will review the proposal at their next regularly scheduled > meeting (if the period before the next regularly scheduled meeting is > less than 10 days, then the period may be extended to the subsequent > regularly scheduled meeting). The AC will decide how to utilize the > proposal and announce the decision to the PPML. > > In the meantime, the AC invites everyone to comment on the proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their > deliberations. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at:https://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal: Internet Assigned Numbers Authority (IANA) Policy for > Allocation of ASN Blocks (ASNs) to Regional Internet Registries > > Proposal Originator: Stacy Hughes and Andrew de la Haye > > Proposal Version: 1.0 > > Date: 29 May 2009 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Modification of NRPM section 10.3 extending the deadline for an > undifferentiated ASN pool by 1 year to read: > > 1. Allocation Principles > > IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document > the > term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010, > allocations of 16-bit and 32-bit only ASN blocks will be made > separately > and independent of each other [1]. > > This means until 31 December 2010, RIRs can receive two separate ASN > blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA > under this policy. After this date, IANA and the RIRs will cease to > make > any distinction between 16-bit and 32-bit only ASNs, and will operate > ASN allocations from an undifferentiated 32-bit ASN allocation pool. > > Rationale: > > a. Arguments supporting the proposal > > Due to operational issues external to the IANA/RIR policy process, > 32-bit only ASNs are not being issued by the RIRs at the anticipated > rate. As it stands, RIRs will likely not be able to justify a new > block > of ASNs from the IANA after 31 December 2009 due to a glut of free 32 > bit only ASNs in the RIR?s pool. This leaves available, essential 16- > bit > ASNs stranded in the IANA free pool. This proposal seeks to remedy the > potential problem by extending the deadline for differentiation by one > year. > > With this proposal the policy will be aligned with the actual > reality in > regards to 32-bit ASN deployment and usage. > > The subject was raised during RIPE 58 and a presentation was made: > http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf > > The feedback in this session suggested that a global policy proposal > should be developed and should be discussed. > > b. Arguments opposing the proposal > > Some may think that extending the previously set timeline can be > perceived as some discouragement for the deployment of 32-bit ASNs. > One > counter argument to this is that RIRs and Internet community have some > other mechanisms and activities to raise awareness for 32-bit ASN pool > (via public presentations and trainings). These activities will > continue > while 16-bit ASN blocks are still allocated to RIRs by the IANA as > they > are available and they are needed. > > Timetable for implementation: Immediately upon ratification by ICANN > Board > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 matthew at matthew.at Fri May 29 14:54:24 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 29 May 2009 11:54:24 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com> References: <4A1FFBE5.20807@arin.net> <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> <2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com> Message-ID: <4A202F60.8000408@matthew.at> Davis, Terry L wrote: > > Stacy > > > > I fully support this proposal. > > > > I think we can look at the current almost total lack of IPv6 > implementation anywhere (not even significantly in universities and > not at all in startups) and realize that our current policies are not > supporting/encouraging v6 implementations. > I agree. I also believe that the popular press accounts of there being so many IPv6 addresses that they're essentially free conflict strongly with the current ARIN fee structure, which is another impediment to people who might otherwise experiment with IPv6 and build new business models around it. If there's really so many that that's true, anyone ought to be able to get some for approximately nothing. And if the counter-argument is that the administrative overhead is too high for that, then maybe more automation would be easier with a less-restrictive policy (such as this one). Matthew Kaufman From owen at delong.com Fri May 29 15:18:37 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 29 May 2009 12:18:37 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A1FCAF4.17167.3844C41@farmer.umn.edu> References: <4A1FFBE5.20807@arin.net>, <4A200639.4030209@rollernet.us>, <20090529160246.GA23729@gweep.net> <4A1FCAF4.17167.3844C41@farmer.umn.edu> Message-ID: On May 29, 2009, at 9:45 AM, David Farmer wrote: > On 29 May 2009 Joe Provo wrote: > >> On Fri, May 29, 2009 at 08:58:49AM -0700, Seth Mattinen wrote: >>> Member Services wrote: >> [snip] >>>> 1) Remove ???by advertising that connectivity through its single >>>> aggregated address allocation??? from article 3 of section 6.5.1.1 >>> >>> What's the rationale for this proposed change? >> >> It better reflects the reality of the meshy global Internet where >> aggregated trunk, backbone-only providers are a rare and dying breed. > > Additionally, I believe it may remove the need for for proposal > 84. IPv6 Multiple Discrete Networks. What to those that > support that proposal think? > I don't think it will. I can see several scenarios where you would want your HD ration calculated independently for independent sites vs. a conjoint determination. Owen From sethm at rollernet.us Fri May 29 15:37:21 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 29 May 2009 12:37:21 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <29A54911243620478FF59F00EBB12F47017E32AA@ex01.drtel.lan> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <29A54911243620478FF59F00EBB12F47017E32AA@ex01.drtel.lan> Message-ID: <4A203971.4090809@rollernet.us> Brian Johnson wrote: > >> To that end, I would like to suggest a new criteria: >> >> - Plan to announce the IPv6 address space provided to at least >> two other autonomous systems. >> > > > Wouldn't this criteria exclude providers who have no current, or > immediately pending, customers for IPv6, have no customers who are > multi-homed to another provider (no need for their own IPv6 space from > ARIN), or are not transit networks? If so, it would exclude many > regional ISPs. > I'm not an ISP and I announce IPv6 to multiple autonomous systems right now. Customers are irrelevant. ~Seth From michael.dillon at bt.com Fri May 29 15:43:47 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 29 May 2009 20:43:47 +0100 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A203143.5010908@matthew.at> Message-ID: <28E139F46D45AF49A31950F88C4974580161F072@E03MVZ2-UKDY.domain1.systemhost.net> > Back in the (actually not so) early IPv4 days, I got an IPv4 > /24 for my house. My friends and I learned a whole lot about > setting up IP networks using our real-world address. Didn't > cost us a cent, and many of us have gone on to do more > interesting things in the Internet world. > > Today, if my kids wanted to get a real IPv6 /32 to play with, > they'd have to pay a bunch of money and fill out a bunch of > paperwork. So they won't be doing that. Even though there's > plenty of IPv6 space for everyone on the planet to play. Your kids could get all the fun of IPv6 including BGP routing by using a /48. There is no need to give out /32s to kids who want to learn since a /48 is very subnettable. IPv6 is not IPv4. > Either we want to encourage adoption or we want to keep this > as tightly controlled as IPv4 has become. The former seems > like a better idea, given how IPv4 is going. We can't encourage adoption through policies because very few people even know what ARIN is, let alone what its policies are. The only way to encourage adoption is through marketing and promotion, which ARIN does do, but which are not part of policymaking. If the policy is an actual barrier, real or percieved, to IPv6 adoption, then it does make sense to adjust the policy, but I strongly disagree with discarding the policy entirely. --Michael Dillon P.S. tell your kids to apply for a PI /48 allocation and enjoy the fun. From bjohnson at drtel.com Fri May 29 15:57:03 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Fri, 29 May 2009 14:57:03 -0500 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A203971.4090809@rollernet.us> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org><29A54911243620478FF59F00EBB12F47017E32AA@ex01.drtel.lan> <4A203971.4090809@rollernet.us> Message-ID: <29A54911243620478FF59F00EBB12F47017E32B9@ex01.drtel.lan> Oops... I misread the statement. Please disregard my post. Thanks for the reply Seth. - Brian > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Seth Mattinen > Sent: Friday, May 29, 2009 2:37 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6 > > Brian Johnson wrote: > > > >> To that end, I would like to suggest a new criteria: > >> > >> - Plan to announce the IPv6 address space provided to at least > >> two other autonomous systems. > >> > > > > > > Wouldn't this criteria exclude providers who have no current, or > > immediately pending, customers for IPv6, have no customers who are > > multi-homed to another provider (no need for their own IPv6 space > from > > ARIN), or are not transit networks? If so, it would exclude many > > regional ISPs. > > > > I'm not an ISP and I announce IPv6 to multiple autonomous systems right > now. Customers are irrelevant. > > ~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 scottleibrand at gmail.com Fri May 29 16:01:35 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 29 May 2009 15:01:35 -0500 Subject: [arin-ppml] Policy Proposal: Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries In-Reply-To: <12535BF9-2693-4480-88E1-ED7139A88B58@delong.com> References: <4A1FFB11.9080101@arin.net> <12535BF9-2693-4480-88E1-ED7139A88B58@delong.com> Message-ID: <4A203F1F.8090002@gmail.com> One thing to keep in mind here is that, because this is a Global Policy, and because of the extremely tight timeframe, we need to agree on the text of the proposal right away, and make sure the same text gets put forward in each region. Even if everyone approves it their first time around, and LACNIC approves it through their fast-track process (since it'll be exactly a year until their next meeting), we're still looking at sometime in 2010 before the policy can be ratified by the ASO-AC and ICANN. That will mean we will have several months (at least) of RIRs being unable to get more 16-bit ASNs from the IANA before this policy could go through and make it possible again. I've heard some very good arguments in the last week that the simpler we make the change, the less likely we are to run into problems that cause delays in getting this approved in time for it to be useful... How important do you think it is to preserve the 16bit/32bit ASN distinction past 1 Jan 2011? Is it worth the increased risk of delay in passing such a revised global policy? (As you probably figured out from my comments above, I personally support this policy.) -Scott Owen DeLong wrote: > While I do not support changing the RIR policy on the issuance of ASNs, > I do support this policy proposal. I think that modifying the IANA->RIR > distribution rules to accommodate the needs of RIRs to better serve their > constituents makes sense. Further, having 16-bit ASNs trapped in the > IANA free pool because 32-bit ASNs are not being accepted by recipients > is absurd and poor stewardship. We should go ahead and issue 16-bit > ASNs until they run out. > > I would suggest that this proposal, rather than removing the distinction > in 2010 should be modified to extend the IANA->RIR duality until such > time as there are no more 16-bit ASN blocks in the IANA pool. > > Owen > > On May 29, 2009, at 8:11 AM, Member Services wrote: > >> ARIN received the following policy proposal and is posting it to the >> Public Policy Mailing List (PPML) in accordance with Policy Development >> Process. >> >> This proposal is in the first stage of the Policy Development Process. >> ARIN staff will perform the Clarity and Understanding step. Staff does >> not evaluate the proposal at this time, their goal is to make sure that >> they understand the proposal and believe the community will as well. >> Staff will report their results to the ARIN Advisory Council (AC) within >> 10 days. >> >> The AC will review the proposal at their next regularly scheduled >> meeting (if the period before the next regularly scheduled meeting is >> less than 10 days, then the period may be extended to the subsequent >> regularly scheduled meeting). The AC will decide how to utilize the >> proposal and announce the decision to the PPML. >> >> In the meantime, the AC invites everyone to comment on the proposal on >> the PPML, particularly their support or non-support and the reasoning >> behind their opinion. Such participation contributes to a thorough >> vetting and provides important guidance to the AC in their >> deliberations. >> >> The ARIN Policy Development Process can be found at: >> https://www.arin.net/policy/pdp.html >> >> Mailing list subscription information can be found >> at:https://www.arin.net/mailing_lists/ >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Policy Proposal: Internet Assigned Numbers Authority (IANA) Policy for >> Allocation of ASN Blocks (ASNs) to Regional Internet Registries >> >> Proposal Originator: Stacy Hughes and Andrew de la Haye >> >> Proposal Version: 1.0 >> >> Date: 29 May 2009 >> >> Proposal type: modify >> >> Policy term: permanent >> >> Policy statement: >> >> Modification of NRPM section 10.3 extending the deadline for an >> undifferentiated ASN pool by 1 year to read: >> >> 1. Allocation Principles >> >> IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the >> term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010, >> allocations of 16-bit and 32-bit only ASN blocks will be made separately >> and independent of each other [1]. >> >> This means until 31 December 2010, RIRs can receive two separate ASN >> blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA >> under this policy. After this date, IANA and the RIRs will cease to make >> any distinction between 16-bit and 32-bit only ASNs, and will operate >> ASN allocations from an undifferentiated 32-bit ASN allocation pool. >> >> Rationale: >> >> a. Arguments supporting the proposal >> >> Due to operational issues external to the IANA/RIR policy process, >> 32-bit only ASNs are not being issued by the RIRs at the anticipated >> rate. As it stands, RIRs will likely not be able to justify a new block >> of ASNs from the IANA after 31 December 2009 due to a glut of free 32 >> bit only ASNs in the RIR?s pool. This leaves available, essential 16-bit >> ASNs stranded in the IANA free pool. This proposal seeks to remedy the >> potential problem by extending the deadline for differentiation by one >> year. >> >> With this proposal the policy will be aligned with the actual reality in >> regards to 32-bit ASN deployment and usage. >> >> The subject was raised during RIPE 58 and a presentation was made: >> http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf >> >> >> The feedback in this session suggested that a global policy proposal >> should be developed and should be discussed. >> >> b. Arguments opposing the proposal >> >> Some may think that extending the previously set timeline can be >> perceived as some discouragement for the deployment of 32-bit ASNs. One >> counter argument to this is that RIRs and Internet community have some >> other mechanisms and activities to raise awareness for 32-bit ASN pool >> (via public presentations and trainings). These activities will continue >> while 16-bit ASN blocks are still allocated to RIRs by the IANA as they >> are available and they are needed. >> >> Timetable for implementation: Immediately upon ratification by ICANN >> Board >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bicknell at ufp.org Fri May 29 16:15:02 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 29 May 2009 16:15:02 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529185841.GA87992@gweep.net> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <20090529185841.GA87992@gweep.net> Message-ID: <20090529201502.GA6398@ussenterprise.ufp.org> In a message written on Fri, May 29, 2009 at 02:58:41PM -0400, Joe Provo wrote: > I appreciate the intent, but what's the point of yet another > unenforcable clause? Enterprises with multiple private BGP > relationships would qualifiy under this and be invisible. ARIN actually has a long history of "enforcing" this, the current IPv4 criteria has a provision for multi-homed networks to get a allocation when single homed networks do not qualify. I will leave staff to comment on how they enforce the criteria. With IPv6 we will run out of routing slots before we run out of numbers. Using the sign at the Chinese Buffet as an example: Take all you want, eat all you take. Like it or not, the network can't take every residential user having their own PI block and routing it. We don't have routers that can support 500 million routes. We can make a big mess by handing things out willy nilly, but just like the dark days of the Internet passed the operators will fix it with draconian filtering policies that will do no one any good. Making a mess the operators have to fix will create no good will, nor internet stability. To that end, I can't support the proposal as written. As one commenter asked, "what if my kids want an IPv6 network to play with in their garage?" Well, we should find some way to accomodate that which doesn't require service providers worldwide to spend tens of thousands of dollars upgrading routers to hold the routes. I realize ARIN does not dictate routing behavior. However, I can tell you how this ends if we get it wrong. If the table grows too fast operators will make their own decisions about "who is worthy". I suspect those decisions will be made along the lines of who has money to pay to route the prefixes. If you're worried about your kids getting free IP's to play with the you should really worry about the $1,000 per month per prefix charge that will come to route it to limit table sale. I offer up multi-homing as a bar that keeps the number of routes manageable. I'm completely open to other proposals. I think the 200 site requirement as it stands now just doesn't work, there are lots of large ISP's, who can use a lot of addresses with far fewer than 200 sites. But to simply remove it and leave nothing doesn't do anyone any favors in the long term. -- 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: 825 bytes Desc: not available URL: From Wesley.E.George at sprint.com Fri May 29 16:26:08 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Fri, 29 May 2009 15:26:08 -0500 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> Message-ID: I agree with Leo's comments regarding the risks to deaggregation and routing table size with no sizable benefit. The comment was made in San Antonio when we were discussing relaxing standards for community networks, and I'll echo/paraphrase it here... I need to see some level of justification as to why provider independent space is a requirement and provider-allocated space will not work for a non-multihomed network. Otherwise I'm not convinced that there's sufficient reason to loosen the requirements for direct allocations simply on the basis that it discriminates against those who can't/won't multihome or don't have a network of a specific size. While I can see how innovation might be chilled by overly stringent allocation policies, I don't see how innovation or adoption is chilled by having to use PD allocations, and I echo the statement that if policy was the only reason why IPv6 wasn't widely deployed, we'd be in FAR better shape right now. Yes, in the short term while there are ISPs that don't have their collective "stuff" together on an IPv6 deployment and it is not possible to *get* IPv6 service (and therefore also an allocation) from one's upstream, this would be a problem. However, that is going to be self-correcting for a lot of reasons, and if it's a deal-breaker, the entity in question will find another ISP that is able to meet their needs. If it's a block size issue, I would expect that this will go similarly to the way that it does in IPv4, either an ISP has enough space to allocate the requested block size to their customer, or they go to Arin to get more space using this as the justification. That said, as IPv4 space is getting harder to come by, ISPs have tightened up their justification requirements. It would be good to ensure that ISPs are being more open in their allocations of IPv6 by comparison in order to ensure that we aren't preventing people who want IPv6 space from getting it. If that falls beyond ARIN's purview and this is an attempt to solve that, I'm not sure that it's the best solution. Thanks, Wes ________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Stacy Hughes Sent: Friday, May 29, 2009 1:49 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6 A multihoming requirement discriminates against networks that either cannot or do not want to multihome. I oppose this modification. Stacy On Fri, May 29, 2009 at 10:42 AM, Leo Bicknell > wrote: In a message written on Fri, May 29, 2009 at 11:14:45AM -0400, Member Services wrote: > 1) Remove ?by advertising that connectivity through its single > aggregated address allocation? from article 3 of section 6.5.1.1 > > 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in > the ARIN region or have a plan for making at least 200 end-site > assignments to other organizations within 5 years? in its entirety. I fear the way this is written may be confusing. Section 6.5.1.1 is at https://www.arin.net/policy/nrpm.html#six511 If these changes were made, I believe the section would then read: 6.5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: 1. be an LIR; 2. not be an end site; 3. plan to provide IPv6 connectivity to organizations to which it will assign IPv6 address space. I would like to make two comments as a result. Criteria #1 doesn't make a lot of sense. If you were a new participant (no IPv4 or IPv6 resources at all) and going only for IPv6 then you aren't an LIR yet, indeed, you are trying to become one. I think, but cannot be sure, that the LIR reference has to do with fee/membership structures of other RIR's. The result of this policy is basically you get an allocation if you want one and can show you will provide IPv6 to another entity and are willing to pay the fees. This is too loose of a standard. While I believe we should be giving out IPv6 relatively easily and there is no danger in running out of the numbers that does not mean we don't still have the issue of routing slots, staff to deal with the number of requests, and other issues. To that end, I would like to suggest a new criteria: - Plan to announce the IPv6 address space provided to at least two other autonomous systems. Basically, setting the bar at being multi-homed to BGP speaking networks. No number of sites requirement, you only need 1 customer to meet the customer requirement. -- 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. ________________________________ This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From terry.l.davis at boeing.com Fri May 29 16:49:10 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Fri, 29 May 2009 13:49:10 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <28E139F46D45AF49A31950F88C4974580161F072@E03MVZ2-UKDY.domain1.systemhost.net> References: <4A203143.5010908@matthew.at> <28E139F46D45AF49A31950F88C4974580161F072@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <2557049CDBC35B4EBD79CFACFEC045841B9F5488@XCH-NW-CCR1V.nw.nos.boeing.com> Michael Back in the mid-80's, I was starting to setup our labs to try IP and I discovered that my cohorts were using Sun's IP addresses (because they were shown in the example installation in our Sparcs) in our initial tests. Like Matthew, I then sent off a simple email and asked for 50 class C's and we began implementation with them. At the present time, startups and small business cannot even actually get IPv6 addresses unless their ISP/s support IPv6. This is seriously broken. And yes I acknowledge that BGP can't tolerate the strain of individual allocations below a /32 (but that is another technical problem that we were going to fix 15 or so years ago). A small business or startup does not even need a /48 (A Class B in v4 terms) but we have no way to tackle that yet. Simply we need a way to get IPv6 addresses into the hands of developers somehow. Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of michael.dillon at bt.com > Sent: Friday, May 29, 2009 12:44 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6 > > > Back in the (actually not so) early IPv4 days, I got an IPv4 > > /24 for my house. My friends and I learned a whole lot about > > setting up IP networks using our real-world address. Didn't > > cost us a cent, and many of us have gone on to do more > > interesting things in the Internet world. > > > > Today, if my kids wanted to get a real IPv6 /32 to play with, > > they'd have to pay a bunch of money and fill out a bunch of > > paperwork. So they won't be doing that. Even though there's > > plenty of IPv6 space for everyone on the planet to play. > > Your kids could get all the fun of IPv6 including BGP routing > by using a /48. There is no need to give out /32s to kids who > want to learn since a /48 is very subnettable. IPv6 is not IPv4. > > > Either we want to encourage adoption or we want to keep this > > as tightly controlled as IPv4 has become. The former seems > > like a better idea, given how IPv4 is going. > > We can't encourage adoption through policies because very few > people even know what ARIN is, let alone what its policies are. > The only way to encourage adoption is through marketing and > promotion, which ARIN does do, but which are not part of > policymaking. > > If the policy is an actual barrier, real or percieved, to > IPv6 adoption, then it does make sense to adjust the policy, > but I strongly disagree with discarding the policy entirely. > > --Michael Dillon > > P.S. tell your kids to apply for a PI /48 allocation and > enjoy the fun. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 bmanning at vacation.karoshi.com Fri May 29 17:01:13 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 29 May 2009 21:01:13 +0000 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045841B9F5488@XCH-NW-CCR1V.nw.nos.boeing.com> References: <4A203143.5010908@matthew.at> <28E139F46D45AF49A31950F88C4974580161F072@E03MVZ2-UKDY.domain1.systemhost.net> <2557049CDBC35B4EBD79CFACFEC045841B9F5488@XCH-NW-CCR1V.nw.nos.boeing.com> Message-ID: <20090529210113.GA12174@vacation.karoshi.com.> Terry, you hint at, but never bring out the fact that in the 1980's there was less emphasis on connectivity and much more interest in ensuring global uniqueness. Back in that timeframe, there was no expectation on connectivity to some mythic core as a precondition to get resources. the current IPv6 polices make and re-inforce that expectation - with the results you see/docuement below. i'd be much happier to see a policy structure that was more concerned w/ getting globally unique resources into the hands of people who can present a credible story than trying to reign in growth due to the problematic dragon at the door - e.g. the expectation of global connectivity. e.g. I favor uniqueness over reachability any day of the week or in modren parlence... +1 --bill On Fri, May 29, 2009 at 01:49:10PM -0700, Davis, Terry L wrote: > Michael > > Back in the mid-80's, I was starting to setup our labs to try IP and I discovered that my cohorts were using Sun's IP addresses (because they were shown in the example installation in our Sparcs) in our initial tests. Like Matthew, I then sent off a simple email and asked for 50 class C's and we began implementation with them. > > At the present time, startups and small business cannot even actually get IPv6 addresses unless their ISP/s support IPv6. This is seriously broken. > > And yes I acknowledge that BGP can't tolerate the strain of individual allocations below a /32 (but that is another technical problem that we were going to fix 15 or so years ago). A small business or startup does not even need a /48 (A Class B in v4 terms) but we have no way to tackle that yet. > > Simply we need a way to get IPv6 addresses into the hands of developers somehow. > > Take care > Terry > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > > Behalf Of michael.dillon at bt.com > > Sent: Friday, May 29, 2009 12:44 PM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6 > > > > > Back in the (actually not so) early IPv4 days, I got an IPv4 > > > /24 for my house. My friends and I learned a whole lot about > > > setting up IP networks using our real-world address. Didn't > > > cost us a cent, and many of us have gone on to do more > > > interesting things in the Internet world. > > > > > > Today, if my kids wanted to get a real IPv6 /32 to play with, > > > they'd have to pay a bunch of money and fill out a bunch of > > > paperwork. So they won't be doing that. Even though there's > > > plenty of IPv6 space for everyone on the planet to play. > > > > Your kids could get all the fun of IPv6 including BGP routing > > by using a /48. There is no need to give out /32s to kids who > > want to learn since a /48 is very subnettable. IPv6 is not IPv4. > > > > > Either we want to encourage adoption or we want to keep this > > > as tightly controlled as IPv4 has become. The former seems > > > like a better idea, given how IPv4 is going. > > > > We can't encourage adoption through policies because very few > > people even know what ARIN is, let alone what its policies are. > > The only way to encourage adoption is through marketing and > > promotion, which ARIN does do, but which are not part of > > policymaking. > > > > If the policy is an actual barrier, real or percieved, to > > IPv6 adoption, then it does make sense to adjust the policy, > > but I strongly disagree with discarding the policy entirely. > > > > --Michael Dillon > > > > P.S. tell your kids to apply for a PI /48 allocation and > > enjoy the fun. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing 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 tedm at ipinc.net Fri May 29 17:04:31 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 May 2009 14:04:31 -0700 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A1FFE0E.7060805@arin.net> References: <4A1FFE0E.7060805@arin.net> Message-ID: <4A204DDF.1020106@ipinc.net> Member Services wrote: > Please be advised that the following policy proposal has been > posted to the ARIN Public Policy Mailing List. All discussion of the > proposal must take place on the PPML. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Open Access To IPv6 > > Proposal Originator: Stacy Hughes and Cathy Aronson > We (my org) does not support this proposal as written. Speaking as the admin of an ISP who just obtained a /32 from ARIN a week ago, it is poppycock that the existing requirements are at all onerous. Take the 200 end site assignments. Granted, we are an existing ISP so we can qual under the "known ISP" clause. But, IMHO we ALSO qualed under the "plan for making 200 assignments" simply by virtue that WE HAVE MORE THAN 200 CUSTOMERS. The reason I could answer the 200 assignment requirement with a perfectly straight face is that as soon as we complete the config changes to our network to fully support IPv6, from that point on EVERY CUSTOMER will get BOTH an IPv4 AND an IPv6 assignment. Period! If their equipment ignores IPv6 right now, SO WHAT!! Eventually, the day is going to come when it will not- and at that time, I want them to plug in their new router or whatever it is on the end of their circuit and see it automatically get it's IPv6 number - and not even THINK that they would have to call us and get it turned on!! I really think that a lot of people out there STILL don't fully grasp the sheer size of the IPv6 scheme. If customers have to request IPv6 to get it from their ISP then their ISP IS ALREADY UNCLEAR ON THE CONCEPT. I fully grasp that IPv6 deployment is a chicken-and-egg issue. But, consider things from a content providers perspective. I am Google. I make money by eyeballs out in Internet-land on my website. If I know that every ISP in the world is only giving their customers IPv6 if their customers ASK for it, then I am pretty confident that I DON'T HAVE TO GET OFF MY ASS TO BOTHER SUPPLYING CONTENT OVER IPv6. By contrast, if every ISP out there is AUTOMATICALLY supplying dual-stacked IPv4 and IPv6 to EVERY customer - well then things are MUCH LESS clear. I am now VERY UNCERTAIN that any given eyeball out there may at the moment be hitting me via IPv6. Maybe some of those eyeballs might be IPv6 only - after all, if everyone in Internet-land HAS AN IPv6 NUMBER then I just don't know. That FEAR of losing a customer is what is going to drive me to offer my content via both IPv6 and IPv4. NOTHING ELSE. I think it's IMPERATIVE that EVERY ISP running IPv6 natively proceed to assign IPv6 to their customers JUST DO IT. What do you have to lose? Do you really think that you will run out of IPv6 numbers? So, please explain in any logical fashion why any network with more than 200 customers (or a plan for 200 customers in the next 5 years) thinks it cannot meet that 200 customer IPv6 assignment requirement. Ted From sethm at rollernet.us Fri May 29 17:05:49 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 29 May 2009 14:05:49 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529201502.GA6398@ussenterprise.ufp.org> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <20090529185841.GA87992@gweep.net> <20090529201502.GA6398@ussenterprise.ufp.org> Message-ID: <4A204E2D.4010109@rollernet.us> Leo Bicknell wrote: > In a message written on Fri, May 29, 2009 at 02:58:41PM -0400, Joe Provo wrote: >> I appreciate the intent, but what's the point of yet another >> unenforcable clause? Enterprises with multiple private BGP >> relationships would qualifiy under this and be invisible. > > ARIN actually has a long history of "enforcing" this, the current > IPv4 criteria has a provision for multi-homed networks to get a > allocation when single homed networks do not qualify. I will leave > staff to comment on how they enforce the criteria. > > With IPv6 we will run out of routing slots before we run out of > numbers. Using the sign at the Chinese Buffet as an example: > > Take all you want, eat all you take. > > Like it or not, the network can't take every residential user having > their own PI block and routing it. We don't have routers that can > support 500 million routes. We can make a big mess by handing > things out willy nilly, but just like the dark days of the Internet > passed the operators will fix it with draconian filtering policies > that will do no one any good. Making a mess the operators have to > fix will create no good will, nor internet stability. > Wait! Routing resources are infinite and we can't restrict them. Everyone already agreed. ~Seth From farmer at umn.edu Fri May 29 17:08:07 2009 From: farmer at umn.edu (David Farmer) Date: Fri, 29 May 2009 16:08:07 -0500 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: References: <4A1FFBE5.20807@arin.net>, <4A1FCAF4.17167.3844C41@farmer.umn.edu>, Message-ID: <4A200867.24457.47456A2@farmer.umn.edu> On 29 May 2009 Owen DeLong wrote: > > On May 29, 2009, at 9:45 AM, David Farmer wrote: > > > Additionally, I believe it may remove the need for for proposal 84. > > IPv6 Multiple Discrete Networks. What to those that support that > > proposal think? > > > I don't think it will. I can see several scenarios where you would > want your HD ration calculated independently for independent sites vs. > a conjoint determination. > Owen Ok after reading proposal #84 again, I think I agree that at least some of the use cases for that proposal would not get much help from this. However, I might want to add criteria to proposal #84 that a justification of why multiple sub parts of a larger aggregate are not suitable for the organization's purpose. Because at least some of the potential use cases for #84 could be served my not requiring the announcement of the aggregate. And in those cases I would rather such needs be meet by not announcing an aggregate. =============================================== 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 tedm at ipinc.net Fri May 29 17:08:17 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 May 2009 14:08:17 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045841B9F5488@XCH-NW-CCR1V.nw.nos.boeing.com> References: <4A203143.5010908@matthew.at> <28E139F46D45AF49A31950F88C4974580161F072@E03MVZ2-UKDY.domain1.systemhost.net> <2557049CDBC35B4EBD79CFACFEC045841B9F5488@XCH-NW-CCR1V.nw.nos.boeing.com> Message-ID: <4A204EC1.5050905@ipinc.net> Davis, Terry L wrote: > Michael > > At the present time, startups and small business cannot even actually get IPv6 addresses unless their ISP/s support IPv6. This is seriously broken. > No, it is not. > And yes I acknowledge that BGP can't tolerate the strain of individual allocations below a /32 (but that is another technical problem that we were going to fix 15 or so years ago). A small business or startup does not even need a /48 (A Class B in v4 terms) but we have no way to tackle that yet. > > Simply we need a way to get IPv6 addresses into the hands of developers somehow. > Simple. Developer calls ISP and asks for IPv6. ISP says not right now. Developer gives ISP reasonable amount of time to get IPv6. ISP does not. Developer calls ISP and cancels service and tells them they are cancelling because they are going down the street to a different ISP that IS supplying IPv6. Ted From kloch at kl.net Fri May 29 16:57:14 2009 From: kloch at kl.net (Kevin Loch) Date: Fri, 29 May 2009 16:57:14 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529201502.GA6398@ussenterprise.ufp.org> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <20090529185841.GA87992@gweep.net> <20090529201502.GA6398@ussenterprise.ufp.org> Message-ID: <4A204C2A.5040501@kl.net> Leo Bicknell wrote: > To that end, I can't support the proposal as written. As one > commenter asked, "what if my kids want an IPv6 network to play with > in their garage?" Well, we should find some way to accomodate that > which doesn't require service providers worldwide to spend tens of > thousands of dollars upgrading routers to hold the routes. This reminds me of the acrimonious "basement multihomer" discussions on nanog in the mid '90s. The irony at the time was that many (most?) of the then contemporary ISP's literally started out in basements and garages. They had grown up and were then complaining about newer startups who were trying to do the same thing. The annual fees ($2,250/yr currently prorated to $562.5) are more than enough to discourage people from being too casual about taking a routing slot. If someone is willing to pay that much to "play" with IPv6 when you can't even give it away for free to the vast majority of IPv4 users... we should encourage them as much as possible. - Kevin From terry.l.davis at boeing.com Fri May 29 17:22:58 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Fri, 29 May 2009 14:22:58 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: References: <4A1FFBE5.20807@arin.net><20090529174253.GB94380@ussenterprise.u fp.org><24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> Message-ID: <2557049CDBC35B4EBD79CFACFEC045841B9F548B@XCH-NW-CCR1V.nw.nos.boeing.com> Wes The simple answer is that regardless of how we try to prevent it; our computing environment gets built into our applications. In short, although IPv6 makes re-addressing easy, it cannot fix the parts of an entity's infrastructure that get built into code, scripts, or configs. Thus re-addressing after even a year or two present huge potential issues for the entity contemplating changing ISPs and thus getting new addresses. Outages of any magnitude scare even the CIO's of small businesses. It is the same thing we are seeing trying to migrate entities into "cloud computing"; they still have to take the risk that some number of your apps will fail in the transition because the apps have "the current computing environment" embedded in their code. Take care Terry PS: And for larger enterprises, Sarbanes-Oxley may even come into play as to whether they can accept PA space. ________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of George, Wes E [NTK] Sent: Friday, May 29, 2009 1:26 PM To: Stacy Hughes; arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6 I agree with Leo's comments regarding the risks to deaggregation and routing table size with no sizable benefit. The comment was made in San Antonio when we were discussing relaxing standards for community networks, and I'll echo/paraphrase it here... I need to see some level of justification as to why provider independent space is a requirement and provider-allocated space will not work for a non-multihomed network. Otherwise I'm not convinced that there's sufficient reason to loosen the requirements for direct allocations simply on the basis that it discriminates against those who can't/won't multihome or don't have a network of a specific size. While I can see how innovation might be chilled by overly stringent allocation policies, I don't see how innovation or adoption is chilled by having to use PD allocations, and I echo the statement that if policy was the only reason why IPv6 wasn't widely deployed, we'd be in FAR better shape right now. Yes, in the short term while there are ISPs that don't have their collective "stuff" together on an IPv6 deployment and it is not possible to *get* IPv6 service (and therefore also an allocation) from one's upstream, this would be a problem. However, that is going to be self-correcting for a lot of reasons, and if it's a deal-breaker, the entity in question will find another ISP that is able to meet their needs. If it's a block size issue, I would expect that this will go similarly to the way that it does in IPv4, either an ISP has enough space to allocate the requested block size to their customer, or they go to Arin to get more space using this as the justification. That said, as IPv4 space is getting harder to come by, ISPs have tightened up their justification requirements. It would be good to ensure that ISPs are being more open in their allocations of IPv6 by comparison in order to ensure that we aren't preventing people who want IPv6 space from getting it. If that falls beyond ARIN's purview and this is an attempt to solve that, I'm not sure that it's the best solution. Thanks, Wes ________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Stacy Hughes Sent: Friday, May 29, 2009 1:49 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6 A multihoming requirement discriminates against networks that either cannot or do not want to multihome. I oppose this modification. Stacy On Fri, May 29, 2009 at 10:42 AM, Leo Bicknell > wrote: In a message written on Fri, May 29, 2009 at 11:14:45AM -0400, Member Services wrote: > 1) Remove ?by advertising that connectivity through its single > aggregated address allocation? from article 3 of section 6.5.1.1 > > 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in > the ARIN region or have a plan for making at least 200 end-site > assignments to other organizations within 5 years? in its entirety. I fear the way this is written may be confusing. Section 6.5.1.1 is at https://www.arin.net/policy/nrpm.html#six511 If these changes were made, I believe the section would then read: 6.5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: 1. be an LIR; 2. not be an end site; 3. plan to provide IPv6 connectivity to organizations to which it will assign IPv6 address space. I would like to make two comments as a result. Criteria #1 doesn't make a lot of sense. If you were a new participant (no IPv4 or IPv6 resources at all) and going only for IPv6 then you aren't an LIR yet, indeed, you are trying to become one. I think, but cannot be sure, that the LIR reference has to do with fee/membership structures of other RIR's. The result of this policy is basically you get an allocation if you want one and can show you will provide IPv6 to another entity and are willing to pay the fees. This is too loose of a standard. While I believe we should be giving out IPv6 relatively easily and there is no danger in running out of the numbers that does not mean we don't still have the issue of routing slots, staff to deal with the number of requests, and other issues. To that end, I would like to suggest a new criteria: - Plan to announce the IPv6 address space provided to at least two other autonomous systems. Basically, setting the bar at being multi-homed to BGP speaking networks. No number of sites requirement, you only need 1 customer to meet the customer requirement. -- 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. ________________________________ This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From terry.l.davis at boeing.com Fri May 29 17:07:22 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Fri, 29 May 2009 14:07:22 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529210113.GA12174@vacation.karoshi.com.> References: <4A203143.5010908@matthew.at> <28E139F46D45AF49A31950F88C4974580161F072@E03MVZ2-UKDY.domain1.systemhost.n et> <2557049CDBC35B4EBD79CFACFEC045841B9F5488@XCH-NW-CCR1V.nw.nos.boeing.com> <20090529210113.GA12174@vacation.karoshi.com.> Message-ID: <2557049CDBC35B4EBD79CFACFEC045841B9F5489@XCH-NW-CCR1V.nw.nos.boeing.com> Bill I would agree with that. We could actually work the global reachability issue separately but I think that view runs strongly against the grain. Take care Terry > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Friday, May 29, 2009 2:01 PM > To: Davis, Terry L > Cc: 'michael.dillon at bt.com'; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6 > > > Terry, > you hint at, but never bring out the fact that in the 1980's there > was less emphasis on connectivity > and much more interest in ensuring global uniqueness. Back in that > timeframe, there was no expectation on connectivity > to some mythic core as a precondition to get resources. > > the current IPv6 polices make and re-inforce that expectation - with > the results you see/docuement below. > i'd be much happier to see a policy structure that was more concerned w/ > getting globally unique resources into the > hands of people who can present a credible story than trying to reign in > growth due to the problematic dragon at the > door - e.g. the expectation of global connectivity. > > e.g. I favor uniqueness over reachability any day of the week > > or in modren parlence... > > +1 > > --bill > > > On Fri, May 29, 2009 at 01:49:10PM -0700, Davis, Terry L wrote: > > Michael > > > > Back in the mid-80's, I was starting to setup our labs to try IP and I > discovered that my cohorts were using Sun's IP addresses (because they > were shown in the example installation in our Sparcs) in our initial > tests. Like Matthew, I then sent off a simple email and asked for 50 > class C's and we began implementation with them. > > > > At the present time, startups and small business cannot even actually > get IPv6 addresses unless their ISP/s support IPv6. This is seriously > broken. > > > > And yes I acknowledge that BGP can't tolerate the strain of individual > allocations below a /32 (but that is another technical problem that we > were going to fix 15 or so years ago). A small business or startup does > not even need a /48 (A Class B in v4 terms) but we have no way to tackle > that yet. > > > > Simply we need a way to get IPv6 addresses into the hands of developers > somehow. > > > > Take care > > Terry > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On > > > Behalf Of michael.dillon at bt.com > > > Sent: Friday, May 29, 2009 12:44 PM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6 > > > > > > > Back in the (actually not so) early IPv4 days, I got an IPv4 > > > > /24 for my house. My friends and I learned a whole lot about > > > > setting up IP networks using our real-world address. Didn't > > > > cost us a cent, and many of us have gone on to do more > > > > interesting things in the Internet world. > > > > > > > > Today, if my kids wanted to get a real IPv6 /32 to play with, > > > > they'd have to pay a bunch of money and fill out a bunch of > > > > paperwork. So they won't be doing that. Even though there's > > > > plenty of IPv6 space for everyone on the planet to play. > > > > > > Your kids could get all the fun of IPv6 including BGP routing > > > by using a /48. There is no need to give out /32s to kids who > > > want to learn since a /48 is very subnettable. IPv6 is not IPv4. > > > > > > > Either we want to encourage adoption or we want to keep this > > > > as tightly controlled as IPv4 has become. The former seems > > > > like a better idea, given how IPv4 is going. > > > > > > We can't encourage adoption through policies because very few > > > people even know what ARIN is, let alone what its policies are. > > > The only way to encourage adoption is through marketing and > > > promotion, which ARIN does do, but which are not part of > > > policymaking. > > > > > > If the policy is an actual barrier, real or percieved, to > > > IPv6 adoption, then it does make sense to adjust the policy, > > > but I strongly disagree with discarding the policy entirely. > > > > > > --Michael Dillon > > > > > > P.S. tell your kids to apply for a PI /48 allocation and > > > enjoy the fun. > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to > > > the ARIN Public Policy Mailing 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 matthew at matthew.at Fri May 29 17:28:24 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 29 May 2009 14:28:24 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529210113.GA12174@vacation.karoshi.com.> References: <4A203143.5010908@matthew.at> <28E139F46D45AF49A31950F88C4974580161F072@E03MVZ2-UKDY.domain1.systemhost.net> <2557049CDBC35B4EBD79CFACFEC045841B9F5488@XCH-NW-CCR1V.nw.nos.boeing.com> <20090529210113.GA12174@vacation.karoshi.com.> Message-ID: <4A205378.4020602@matthew.at> bmanning at vacation.karoshi.com wrote: > Terry, > you hint at, but never bring out the fact that in the 1980's there was less emphasis on connectivity > and much more interest in ensuring global uniqueness. Back in that timeframe, there was no expectation on connectivity > to some mythic core as a precondition to get resources. > > the current IPv6 polices make and re-inforce that expectation - with the results you see/docuement below. > i'd be much happier to see a policy structure that was more concerned w/ getting globally unique resources into the > hands of people who can present a credible story than trying to reign in growth due to the problematic dragon at the > door - e.g. the expectation of global connectivity. > > e.g. I favor uniqueness over reachability any day of the week > > or in modren parlence... > > +1 > Exactly my point. ARIN should make it as easy and cheap as possible for anyone to get as much unique IPv6 address space as they might need. Which, since there's a whole lot of it, shouldn't be that hard a task to accomplish. Certainly the level of justification required and the price charged should be significantly more attractive than IPv4, of which there is a shortage. Whether or not those addresses are or are not globally routeable now or at some future time is really beside the point. Matthew Kaufman From cra at WPI.EDU Fri May 29 17:11:24 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 29 May 2009 17:11:24 -0400 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A204DDF.1020106@ipinc.net> References: <4A1FFE0E.7060805@arin.net> <4A204DDF.1020106@ipinc.net> Message-ID: <20090529211124.GO30913@angus.ind.WPI.EDU> On Fri, May 29, 2009 at 02:04:31PM -0700, Ted Mittelstaedt wrote: > We (my org) does not support this proposal as written. ... > Take the 200 end site assignments. Granted, we are an existing > ISP so we can qual under the "known ISP" clause. But, IMHO we > ALSO qualed under the "plan for making 200 assignments" simply > by virtue that WE HAVE MORE THAN 200 CUSTOMERS. ... > So, please explain in any logical fashion why any network with more > than 200 customers (or a plan for 200 customers in the next > 5 years) thinks it cannot meet that 200 customer IPv6 > assignment requirement. Not every startup company or educational network is going to have 200 customers, not necessarily even after several years. Even NoX, the Boston/New England area Internet2 PoP, only has ~25 participants. Should they not be allowed to get a /32? [1] http://www.nox.org/participants/ From bicknell at ufp.org Fri May 29 17:29:38 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 29 May 2009 17:29:38 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045841B9F548B@XCH-NW-CCR1V.nw.nos.boeing.com> References: <2557049CDBC35B4EBD79CFACFEC045841B9F548B@XCH-NW-CCR1V.nw.nos.boeing.com> Message-ID: <20090529212938.GA11989@ussenterprise.ufp.org> In a message written on Fri, May 29, 2009 at 02:22:58PM -0700, Davis, Terry L wrote: > The simple answer is that regardless of how we try to prevent it; our > computing environment gets built into our applications. In short, > although IPv6 makes re-addressing easy, it cannot fix the parts of an > entity's infrastructure that get built into code, scripts, or > configs. I've noticed several people blurring a line here, but Terry had the easiest post to reply to and hit the relevant point. This policy addresses the IPv6 allocation policy for ISP's. There is a separate, different policy for End Users. Most Enterprises that are building addresses into code (a big no no, but yes, it happens) would get space under the End User policy for any number of reasons. But, here in lies the rub. This policy makes it easier for an enterprise to receive a ISP allocation (and get hit with SWIP requirements, ISP fees, and other associated items) than it does for them to get an End User assignment in many cases. The end user policy gives out /48's. If we want folks to get a network they can play with in their garage, let's do it under the end user policy. This policy proposal affects the ISP section, giving out /32's for the express purpose of assigning /48's to other entities. Let's leave it for folks who are really ISP's, and really providing services to others. -- 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: 825 bytes Desc: not available URL: From matthew at matthew.at Fri May 29 17:33:08 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 29 May 2009 14:33:08 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A204EC1.5050905@ipinc.net> References: <4A203143.5010908@matthew.at> <28E139F46D45AF49A31950F88C4974580161F072@E03MVZ2-UKDY.domain1.systemhost.net> <2557049CDBC35B4EBD79CFACFEC045841B9F5488@XCH-NW-CCR1V.nw.nos.boeing.com> <4A204EC1.5050905@ipinc.net> Message-ID: <4A205494.40507@matthew.at> Ted Mittelstaedt wrote: > > Simple. Developer calls ISP and asks for IPv6. ISP says not right now. > Developer gives ISP reasonable amount of time to get IPv6. ISP does > not. Developer calls ISP and cancels service and tells them they are > cancelling because they are going down the street to a different ISP > that IS supplying IPv6. You're mixing up unique IPv6 address space and IPv6 connectivity to the global IPv6 Internet. Lets say, for instance, that Developer is working on a neat application that could have millions of connected nodes, and they want some unique address space assigned so they can start building that in their lab... In 1990, the IPv4 answer was "you send some email explaining what you're doing, and you get at least that much address space uniquely allocated to you at no charge". Here it is, almost 20 years later, and the IPv6 answer isn't nearly as attractive. And we wonder why people aren't building neat new things with it. Matthew Kaufman From cmalayter at switchanddata.com Fri May 29 17:14:56 2009 From: cmalayter at switchanddata.com (Chris Malayter) Date: Fri, 29 May 2009 16:14:56 -0500 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A204EC1.5050905@ipinc.net> Message-ID: This mentality will only serve to slow ipv6 adoption in application and content. The easier we make it for non-isps to get portable space, the more development will occur. Basic supply and demand theory in action here.... -Chris > > > Simple. Developer calls ISP and asks for IPv6. ISP says not right now. > Developer gives ISP reasonable amount of time to get IPv6. ISP does > not. Developer calls ISP and cancels service and tells them they are > cancelling because they are going down the street to a different ISP > that IS supplying IPv6. From terry.l.davis at boeing.com Fri May 29 17:42:57 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Fri, 29 May 2009 14:42:57 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529212938.GA11989@ussenterprise.ufp.org> References: <2557049CDBC35B4EBD79CFACFEC045841B9F548B@XCH-NW-CCR1V.nw.nos.boeing.com> <20090529212938.GA11989@ussenterprise.ufp.org> Message-ID: <2557049CDBC35B4EBD79CFACFEC045841B9F5490@XCH-NW-CCR1V.nw.nos.boeing.com> Leo We've had our /32 for something like five years now and yes for enterprises it is certainly doable. But to get IPv6 implementations under way in the needed scale, we need to find a way to make it easily obtainable for at least education and small/startup businesses. Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Leo Bicknell > Sent: Friday, May 29, 2009 2:30 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6 > > In a message written on Fri, May 29, 2009 at 02:22:58PM -0700, Davis, > Terry L wrote: > > The simple answer is that regardless of how we try to prevent it; our > > computing environment gets built into our applications. In short, > > although IPv6 makes re-addressing easy, it cannot fix the parts of an > > entity's infrastructure that get built into code, scripts, or > > configs. > > I've noticed several people blurring a line here, but Terry had the > easiest post to reply to and hit the relevant point. > > This policy addresses the IPv6 allocation policy for ISP's. There > is a separate, different policy for End Users. Most Enterprises > that are building addresses into code (a big no no, but yes, it > happens) would get space under the End User policy for any number > of reasons. > > But, here in lies the rub. This policy makes it easier for an > enterprise to receive a ISP allocation (and get hit with SWIP > requirements, ISP fees, and other associated items) than it does > for them to get an End User assignment in many cases. > > The end user policy gives out /48's. If we want folks to get a > network they can play with in their garage, let's do it under the > end user policy. This policy proposal affects the ISP section, > giving out /32's for the express purpose of assigning /48's to other > entities. Let's leave it for folks who are really ISP's, and really > providing services to others. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ From leo.vegoda at icann.org Fri May 29 17:45:45 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 29 May 2009 14:45:45 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A205494.40507@matthew.at> Message-ID: On 29/05/2009 2:33, "Matthew Kaufman" wrote: [...] > Lets say, for instance, that Developer is working on a neat application > that could have millions of connected nodes, and they want some unique > address space assigned so they can start building that in their lab... If you want to do benchmarking tests in your lab network then you can use 2001:0002::/48, which has been assigned specifically for this purpose. If you just want to do some private development work then you can randomly assign yourself a /48 from FD00::/7 as per RFC 4193. If you wanted to do some connectivity tests but didn't want to pay money for IPv6 transit then you can get a free tunnel from plenty of tunnel brokers. Tunnels are not perfect or native but they work. None of these methods even require you to sign a contract. That is how easy it is to get IPv6 address space to run some tests from. Regards, Leo From matthew at matthew.at Fri May 29 17:58:13 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 29 May 2009 14:58:13 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529212938.GA11989@ussenterprise.ufp.org> References: <2557049CDBC35B4EBD79CFACFEC045841B9F548B@XCH-NW-CCR1V.nw.nos.boeing.com> <20090529212938.GA11989@ussenterprise.ufp.org> Message-ID: <4A205A75.10107@matthew.at> Leo Bicknell wrote: > > The end user policy gives out /48's. If we want folks to get a > network they can play with in their garage, let's do it under the > end user policy. This policy proposal affects the ISP section, > giving out /32's for the express purpose of assigning /48's to other > entities. Let's leave it for folks who are really ISP's, and really > providing services to others. > Ah. "Folks who are really ISPs". This is as bad as the com-priv list in 1992... We *don't know* who is/will be "an ISP". A school district providing service to all its schools? A corporation with a dozen subsidiaries around the world? A guy in his garage who gives away free wireless to his neighborhood? Really there shouldn't even *be* a distinction. If you need a /whatever of IPv6 and can write a convincing letter to that effect, you should be able to get at least that much unique IPv6 space. Whether it can be routed now or in the future is really between you and whichever transit provider you choose *should you even need external connectivity*. Matthew Kaufman From ipgoddess.arin at gmail.com Fri May 29 18:01:47 2009 From: ipgoddess.arin at gmail.com (Stacy Hughes) Date: Fri, 29 May 2009 15:01:47 -0700 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529211124.GO30913@angus.ind.WPI.EDU> References: <4A1FFE0E.7060805@arin.net> <4A204DDF.1020106@ipinc.net> <20090529211124.GO30913@angus.ind.WPI.EDU> Message-ID: <24c86a5f0905291501l43b66da5x9bba14eabdbd9535@mail.gmail.com> Hi Everyone, Chuck precisely makes one of my points here. When I voted against this concept last time around, I felt just like Ted. Like, you're not a real ISP or player if you don't have 200 customers. But there are real ISPs that are small that deserve the minimum allocation of IPv6 just as much as the 200+ers. If we want everyone participating in IPv6, we must make sure they can get it - especially ISPs, large and small. Stacy On Fri, May 29, 2009 at 2:11 PM, Chuck Anderson wrote: > On Fri, May 29, 2009 at 02:04:31PM -0700, Ted Mittelstaedt wrote: > > We (my org) does not support this proposal as written. > ... > > Take the 200 end site assignments. Granted, we are an existing > > ISP so we can qual under the "known ISP" clause. But, IMHO we > > ALSO qualed under the "plan for making 200 assignments" simply > > by virtue that WE HAVE MORE THAN 200 CUSTOMERS. > ... > > So, please explain in any logical fashion why any network with more > > than 200 customers (or a plan for 200 customers in the next > > 5 years) thinks it cannot meet that 200 customer IPv6 > > assignment requirement. > > Not every startup company or educational network is going to have 200 > customers, not necessarily even after several years. Even NoX, the > Boston/New England area Internet2 PoP, only has ~25 participants. > Should they not be allowed to get a /32? > > [1] http://www.nox.org/participants/ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 tedm at ipinc.net Fri May 29 18:03:35 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 May 2009 15:03:35 -0700 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529211124.GO30913@angus.ind.WPI.EDU> References: <4A1FFE0E.7060805@arin.net> <4A204DDF.1020106@ipinc.net> <20090529211124.GO30913@angus.ind.WPI.EDU> Message-ID: <4A205BB7.8050506@ipinc.net> Chuck Anderson wrote: > On Fri, May 29, 2009 at 02:04:31PM -0700, Ted Mittelstaedt wrote: >> We (my org) does not support this proposal as written. > ... >> Take the 200 end site assignments. Granted, we are an existing >> ISP so we can qual under the "known ISP" clause. But, IMHO we >> ALSO qualed under the "plan for making 200 assignments" simply >> by virtue that WE HAVE MORE THAN 200 CUSTOMERS. > ... >> So, please explain in any logical fashion why any network with more >> than 200 customers (or a plan for 200 customers in the next >> 5 years) thinks it cannot meet that 200 customer IPv6 >> assignment requirement. > > Not every startup company or educational network is going to have 200 > customers, not necessarily even after several years. Even NoX, the > Boston/New England area Internet2 PoP, only has ~25 participants. > Should they not be allowed to get a /32? > Their literature seems to indicate they are nothing more than a kid of club and have no network infrastructure at all, so if that is the case then quite obviously they should not get a /32 However if they are acting as an exchange point for those participants then they should be obtaining IPv6 under the 6.10.1 section for micro allocations. Ted From bill at herrin.us Fri May 29 18:03:22 2009 From: bill at herrin.us (William Herrin) Date: Fri, 29 May 2009 18:03:22 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A1FFBE5.20807@arin.net> References: <4A1FFBE5.20807@arin.net> Message-ID: <3c3e3fca0905291503u1eb658d2l815f7377bccc5777@mail.gmail.com> On Fri, May 29, 2009 at 11:14 AM, Member Services wrote: > Policy Proposal Name: Open Access To IPv6 > > 1) Remove ?by advertising that connectivity through its single > aggregated address allocation? from article 3 of section 6.5.1.1 > > 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in > the ARIN region or have a plan for making at least 200 end-site > assignments to other organizations within 5 years? in its entirety. Stacy, Cathy: Although I generally favor these changes, I'd like to see them tied to a statement which restricts section 6.5.1 allocations to entities which are multihomed with BGP or a comparable protocol. Routing slot cost is a significant problem. Each entry in the IPv6 DFZ table adds more than $10k per year to the cost of the global BGP system and we've found no mechanism which allows that cost to be directly recovered from the folks announcing each route. I would also observe that article 3 of 6.5.1.1 would be less of a problem if 6.5.8.1 was amended to permit /48 assignments to multihomed entites regardless of size. For better or for worse, BGP advertisements are presently the only multihoming mechanisms that work in 100% of the use cases. No technology deployed or currently in the pipeline has any prayer of changing that. Forcing small multihomed entities to use a subset of one of their ISP's space creates a mess with the filters: it makes it impossible to tell the difference between a TE advertisement and a small multihomed customer which, if your game is quality of service, makes it impractical to filter TE advertisements. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From farmer at umn.edu Fri May 29 18:07:33 2009 From: farmer at umn.edu (David Farmer) Date: Fri, 29 May 2009 17:07:33 -0500 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: References: <4A204EC1.5050905@ipinc.net>, Message-ID: <4A201655.14865.4AAC266@farmer.umn.edu> I want to reinforce Leo's point this policy effects the LIR/ISP allocations within the NRPM. The title of this proposal is slightly unfortunate as it doesn't include that bit of information. Within the Advisory Council, I am working on the companion part of this that would deal with direct End User assignments from ARIN, and dis-associate the dependence of having an IPv4 assignment from ARIN with the IPv6 assignment policy. We need a new stewardship model for IPv6. In IPv4 we have had a manage limited resources version of stewardship. Only give out a little bit at a time, and make you justify more. We should use the IPv4 stewardship model for IPv6, So I want to the ask a more general question; "What is the right stewardship model for IPv6?" Does the same model work for ISP/LIRs and End Users? I will redouble my efforts this weekend and get a proposal out for the IPv6 End User section of the NRPM early next week. But, I must have some time to play with the new MacBook Pro my desktop/laptop support guy just dropped off in my cube 10 minutes ago. GOODY, GOODY, GOODY NEW TOYS! WOO HOO! :-) On 29 May 2009 Chris Malayter wrote: > This mentality will only serve to slow ipv6 adoption in application > and content. The easier we make it for non-isps to get portable > space, the more development will occur. Basic supply and demand > theory in action here.... > > -Chris > > > > > > > > > Simple. Developer calls ISP and asks for IPv6. ISP says not right > > now. Developer gives ISP reasonable amount of time to get IPv6. ISP > > does not. Developer calls ISP and cancels service and tells them > > they are cancelling because they are going down the street to a > > different ISP that IS supplying IPv6. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. =============================================== David Farmer Email:farmer at umn.edu 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 leo.vegoda at icann.org Fri May 29 18:12:18 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 29 May 2009 15:12:18 -0700 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: <24c86a5f0905291501l43b66da5x9bba14eabdbd9535@mail.gmail.com> Message-ID: Hi Stacy, On 29/05/2009 3:01, "Stacy Hughes" wrote: > Hi Everyone,? > Chuck precisely makes one of my points here. ? > When I voted against this concept last time around, I felt just like Ted. > ?Like, you're not a real ISP or player if you don't have 200 customers. ? > But there are real ISPs that are small that deserve the minimum allocation of > IPv6 just as much as the 200+ers. ? I suspect that one problem we have is that there is such a huge gap between the size of the standard direct assignment to an end user and the standard allocation to an ISP. Matthew Kaufman makes a good point when he says that "Really there shouldn't even *be* a distinction". In a needs based system, perhaps what is needed is a distribution process that doesn't distinguish based on the network operator's business type but on the size of the network they will operate. If the scale didn't jump from /48(ish) -> /32(ish) we could focus on distributing address space based on documented need rather than try and find a form of words that describes ISPs but doesn't give a /32 to everyone. Regards, Leo Vegoda From tedm at ipinc.net Fri May 29 18:34:45 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 May 2009 15:34:45 -0700 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: <24c86a5f0905291501l43b66da5x9bba14eabdbd9535@mail.gmail.com> References: <4A1FFE0E.7060805@arin.net> <4A204DDF.1020106@ipinc.net> <20090529211124.GO30913@angus.ind.WPI.EDU> <24c86a5f0905291501l43b66da5x9bba14eabdbd9535@mail.gmail.com> Message-ID: <4A206305.40607@ipinc.net> Stacy Hughes wrote: > Hi Everyone, > Chuck precisely makes one of my points here. > When I voted against this concept last time around, I felt just like > Ted. Like, you're not a real ISP or player if you don't have 200 > customers. I never said that. As I mentioned in the response to the NoX question, there is already a micro allocation policy that applies to them. > But there are real ISPs that are small that deserve the minimum > allocation of IPv6 just as much as the 200+ers. > If we want everyone participating in IPv6, we must make sure they can > get it - especially ISPs, large and small. If they are real ISPs that are small then it is not that much of a burden for them to get their IPv6 from an upstream and reassigning it to their customers. If they are multihomed then nothing is stopping them from advertising that block. Granted, there will be a larger advertisement for the block their smaller block is part of out there but that shouldn't matter. It certainly doesn't matter for IPv4 since before we got our IPv4 space in 2004 we used non-portable IPv4 space in this fashion with no problems. By contrast, the problem of table bloat in routers is very real. You are essentially asking thousands of orgs out there to put money into tens of thousands of routers out there to replace them with new gear that will hold and manage a fantastically gigantic IPv6 table, just to make it a slight bit easier for small orgs to advertise a /32, who have absolutely no use for a /32 and would be happy with a /48, and who are getting the /32 because they are still scared to death about the old renumbering bugaboo - which doesn't even exist with IPv6 anyway. You speak of a disincentive to adopting IPv6. Well let me say that for us, right now the additional ram consumed in our routers by the small IPv6 table is NOT a disincentive. But if 5 years from now that table has balloned and is maxing our routers ram out, and I still don't have customers asking for IPv6, then your going to put me into a position where I have the choice of tossing a lot of money into buying new hardware for a numbering scheme that none of my customers wants or is paying for, on the idea that -someday- it will be important, or just abandoning the scheme alltogether and going back to IPv4 and waiting until eventually there's demand for IPv6. Seems to me your ignoring the disincentive that gigantic routers with enormous amounts of memory will cost. Ted From farmer at umn.edu Fri May 29 18:39:49 2009 From: farmer at umn.edu (David Farmer) Date: Fri, 29 May 2009 17:39:49 -0500 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A205BB7.8050506@ipinc.net> References: <4A1FFE0E.7060805@arin.net>, <20090529211124.GO30913@angus.ind.WPI.EDU>, <4A205BB7.8050506@ipinc.net> Message-ID: <4A201DE5.28702.4C84EAB@farmer.umn.edu> On 29 May 2009 Ted Mittelstaedt wrote: > > Not every startup company or educational network is going to have > > 200 customers, not necessarily even after several years. Even NoX, > > the Boston/New England area Internet2 PoP, only has ~25 > > participants. Should they not be allowed to get a /32? > > > > Their literature seems to indicate they are nothing more than a > kid of club and have no network infrastructure at all, so if that is > the case then quite obviously they should not get a /32 > > However if they are acting as an exchange point for those participants > then they should be obtaining IPv6 under the 6.10.1 section for micro > allocations. Can we agree not to cast stones at each other's "clubs". GigaPOPs are the current club house for the people that created the Internet in the first place, long before Al Gore or most of the people on this list ever heard of the Internet. And while their may only be a small number of "participants" many times those participants represent 10,000 to 100,000 desktop connections. Further the 20+ Internet2 GigaPOPs quietly purchase over 75G committed bandwidth from a number of Internet transport providers. Besides the community operating two separate national foot print backbones with over 200G of capacity nationally and regionally Let's try not to call out specific organizations, be they providers, end users, or bizarre combinations of the two. Clubs have and always will exist, but we should try not to build them into policy. =============================================== 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 schnizlein at isoc.org Fri May 29 18:37:17 2009 From: schnizlein at isoc.org (John Schnizlein) Date: Fri, 29 May 2009 17:37:17 -0500 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: References: Message-ID: This situation does seem remarkably like deciding whether a request deserves a class-A or a class-B. The 16 bits of a /48 matches the class-B of olden days. But there is a whole (IPv4-scale) Internet's worth of class-A addresses to hand out. Conserving addresses really matters MUCH less than default-free route-table size. Thinking about need really has to shift when there really is no scarcity. John On 2009May29, at 5:12 PM, Leo Vegoda wrote: > > If the scale didn't jump from /48(ish) -> /32(ish) we could focus on > distributing address space based on documented need rather than try > and find > a form of words that describes ISPs but doesn't give a /32 to > everyone. From bmanning at vacation.karoshi.com Fri May 29 19:05:03 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 29 May 2009 23:05:03 +0000 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: References: <24c86a5f0905291501l43b66da5x9bba14eabdbd9535@mail.gmail.com> Message-ID: <20090529230503.GA12439@vacation.karoshi.com.> On Fri, May 29, 2009 at 03:12:18PM -0700, Leo Vegoda wrote: > Hi Stacy, > > On 29/05/2009 3:01, "Stacy Hughes" wrote: > > > Hi Everyone, > > Chuck precisely makes one of my points here. > > When I voted against this concept last time around, I felt just like Ted. > > Like, you're not a real ISP or player if you don't have 200 customers. > > But there are real ISPs that are small that deserve the minimum allocation of > > IPv6 just as much as the 200+ers. > > I suspect that one problem we have is that there is such a huge gap between > the size of the standard direct assignment to an end user and the standard > allocation to an ISP. > > Matthew Kaufman makes a good point when he says that "Really there shouldn't > even *be* a distinction". In a needs based system, perhaps what is needed is > a distribution process that doesn't distinguish based on the network > operator's business type but on the size of the network they will operate. > > If the scale didn't jump from /48(ish) -> /32(ish) we could focus on > distributing address space based on documented need rather than try and find > a form of words that describes ISPs but doesn't give a /32 to everyone. > > Regards, > > Leo Vegoda > which begs the question Leo, why does the scale make that jump? is there a real operational reason for it? or is it an artifact of previous century thinking? --bill From leo.vegoda at icann.org Fri May 29 19:30:51 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 29 May 2009 16:30:51 -0700 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: Message-ID: On 29/05/2009 3:37, "John Schnizlein" wrote: [...] > But there is a whole (IPv4-scale) Internet's worth of class-A > addresses to hand out. Conserving addresses really matters MUCH less > than default-free route-table size. Thinking about need really has to > shift when there really is no scarcity. I wasn't trying to argue for more focus on conservation. I was trying to point out that it is very difficult to maintain two separate policies for two separate classes of organisations. Sometimes the edges get blurred and it's hard to work out where someone fits and whether that is fair. Does the provider/end user distinction make things easier or does it make things harder? I suspect the latter. Regards, Leo From sethm at rollernet.us Fri May 29 19:33:43 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 29 May 2009 16:33:43 -0700 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A206305.40607@ipinc.net> References: <4A1FFE0E.7060805@arin.net> <4A204DDF.1020106@ipinc.net> <20090529211124.GO30913@angus.ind.WPI.EDU> <24c86a5f0905291501l43b66da5x9bba14eabdbd9535@mail.gmail.com> <4A206305.40607@ipinc.net> Message-ID: <4A2070D7.8080402@rollernet.us> Ted Mittelstaedt wrote: > Stacy Hughes wrote: >> Hi Everyone, Chuck precisely makes one of my points here. When I >> voted against this concept last time around, I felt just like Ted. >> Like, you're not a real ISP or player if you don't have 200 customers. > > I never said that. As I mentioned in the response to the NoX question, > there is already a micro allocation policy that applies to them. > >> But there are real ISPs that are small that deserve the minimum >> allocation of IPv6 just as much as the 200+ers. If we want everyone >> participating in IPv6, we must make sure they can get it - especially >> ISPs, large and small. > > If they are real ISPs that are small then it is not that much of a > burden for them to get their IPv6 from an upstream and reassigning > it to their customers. If they are > multihomed then nothing is stopping them from advertising that block. > Granted, there will be a larger advertisement for the block their > smaller block is part of out there but that shouldn't matter. It > certainly doesn't matter for IPv4 since before we got our IPv4 space > in 2004 we used non-portable IPv4 space in this fashion with no problems. In IPv4 land it's a huge problem (to me) because you have to give PA space back and renumber into PI space in order to ever qualify for more PI space. As much as everyone things renumbering is a big deal, it is. I *still* have customers asking why PA space from an upstream I dropped over three years ago doesn't work. Even further back, people are still hitting my test bed I set up while I was still in college; talk about out of date. I have no idea where they find those old addresses. Renumbering is a headache that never ends. > By contrast, the problem of table bloat in routers is very real. You > are essentially asking thousands of orgs out there to put money into > tens of thousands of routers out there to replace them with new gear > that will hold and manage a fantastically gigantic IPv6 table, just to > make it a slight bit easier for small orgs to advertise a /32, who > have absolutely no use for a /32 and would be happy with a /48, and > who are getting the /32 because they are still scared to death about the > old renumbering bugaboo - which doesn't even exist with IPv6 anyway. I tried to make the same point. Routers with a lot of TCAM space are horribly expensive. Many people have already bought equipment expected to last for the next X years (where X is greater than 1) and it's already inadequate. Bleh. Besides, there's no reason a small org can't just get a /48 and apply for more space later. No renumbering required. > You speak of a disincentive to adopting IPv6. Well let me say that for > us, right now the additional ram consumed in our routers by the small > IPv6 table is NOT a disincentive. I'm using several ISR series routers that hold routes in cheap DRAM in front of my TCAM-based switches because those can't even handle a fraction of the IPv4 table. > But if 5 years from now that table has balloned and is maxing our > routers ram out, and I still don't have customers asking for IPv6, > then your going to put me into a position where I have the choice of > tossing a lot of money into buying new hardware for a numbering scheme > that none of my customers wants or is paying for, on the idea > that -someday- it will be important, or just abandoning > the scheme alltogether and going back to IPv4 and waiting until > eventually there's demand for IPv6. > > Seems to me your ignoring the disincentive that gigantic routers with > enormous amounts of memory will cost. > You, me, and everyone else is supposed to just bend over and eat the cost because it somehow makes it easier to adopt. Didn't you get the memo? There seems to be a failure to recognize that the cost to entry for IPv6 will become very non-trivial if the routing table gets horrendously large and requires equally expensive hardware to deal with it, even hurting some of us early adopters if we can't keep up hardware-wise. ~Seth From matthew at matthew.at Fri May 29 19:39:02 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 29 May 2009 16:39:02 -0700 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A206305.40607@ipinc.net> References: <4A1FFE0E.7060805@arin.net> <4A204DDF.1020106@ipinc.net> <20090529211124.GO30913@angus.ind.WPI.EDU> <24c86a5f0905291501l43b66da5x9bba14eabdbd9535@mail.gmail.com> <4A206305.40607@ipinc.net> Message-ID: <4A207216.60202@matthew.at> Ted Mittelstaedt wrote: > > By contrast, the problem of table bloat in routers is very real. Absolutely, but should not be ARIN's problem. ARIN should make it possible for organizations (be they ISPs or not) to obtain unique allocations from ARIN's portion of the IPv6 address space. It should be easy to get allocations which are aggregated in such a way that they are less expensive to route, but that shouldn't drive policy. > You > are essentially asking thousands of orgs out there to put money into > tens of thousands of routers out there to replace them with new gear > that will hold and manage a fantastically gigantic IPv6 table, No. We are asking ARIN to fairly allocate reasonably-sized parts of IPv6 to entities that ask, in return for no more than reasonable compensation. > just to > make it a slight bit easier for small orgs to advertise a /32, who > have absolutely no use for a /32 and would be happy with a /48, and > who are getting the /32 because they are still scared to death about the > old renumbering bugaboo - which doesn't even exist with IPv6 anyway. That is between an org that wishes to *advertise their address space to the global Internet routing infrastructure* and the transit provider who is doing that for them (and entering into peering and/or transit relationships with other providers in order to make that work) There's even better solutions to routing table bloat if you want ARIN to be even more heavy-handed. For instance, ARIN could hold a lottery to determine the one and only provider who is allowed to get address space within the ARIN region and then everyone else would need to be customers of the winner. Then the inter-provider table would be tiny. Matthew Kaufman From tedm at ipinc.net Fri May 29 19:39:50 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 May 2009 16:39:50 -0700 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A201DE5.28702.4C84EAB@farmer.umn.edu> References: <4A1FFE0E.7060805@arin.net>, <20090529211124.GO30913@angus.ind.WPI.EDU>, <4A205BB7.8050506@ipinc.net> <4A201DE5.28702.4C84EAB@farmer.umn.edu> Message-ID: <4A207246.8000000@ipinc.net> David Farmer wrote: > On 29 May 2009 Ted Mittelstaedt wrote: > >>> Not every startup company or educational network is going to have >>> 200 customers, not necessarily even after several years. Even NoX, >>> the Boston/New England area Internet2 PoP, only has ~25 >>> participants. Should they not be allowed to get a /32? >>> >> Their literature seems to indicate they are nothing more than a >> kid of club and have no network infrastructure at all, so if that is >> the case then quite obviously they should not get a /32 >> >> However if they are acting as an exchange point for those participants >> then they should be obtaining IPv6 under the 6.10.1 section for micro >> allocations. > > Can we agree not to cast stones at each other's "clubs". > Since when did the term club become a dirty word? I can't help that their website has less info about what they ARE than Obama's economic plan has about fixing regulation on banks. > GigaPOPs are the current club house for the people that > created the Internet in the first place, long before Al Gore or > most of the people on this list ever heard of the Internet. > OK then they have been in business a while and therefore are subject to the "preexisting ISP" clause and thus have nothing whatsover to do with this discussion. > And while their may only be a small number of "participants" > many times those participants represent 10,000 to 100,000 > desktop connections. Further the 20+ Internet2 GigaPOPs > quietly purchase over 75G committed bandwidth from a > number of Internet transport providers. Besides the > community operating two separate national foot print > backbones with over 200G of capacity nationally and regionally > Why is a sales pitch necessary? What are they? An existing ISP - good, served by current policy An exchange point - good, served by existing IPv6 microallocation policy NEXT!!!! > Let's try not to call out specific organizations, be they > providers, end users, or bizarre combinations of the two. > OK we can then have a battle of straw men! Great, let me sit back and try to create a really good straw man that has a Hollywood-ready movie story - how about the struggling small ISP who is trying to scrape together the money to keep the orphanage of sick orphans open and is being denied IPv6 by those big bad ogre telephone company ISP's who want to keep all the IPv6 for themselves. Yeah, that's the ticket!!!! Just like the straw man that was used to create this policy proposal!!! I bet we can really make some great policy based on nonexistence!! Team ARIN, eat your heat out! Comics, schomics! > Clubs have and always will exist, but we should try not to build > them into policy. > Agreed! Which is why this entire line of discussion is getting more and more silly. I posted a real-life example of router table bloat reducing incentive to go to IPv6 a while back and nobody wants to address it. Instead they would rather try to claim that IPv6 deployment is being blocked because of the bogyman, then scrap the current restrictions on giving everyone and their dog a direct assignment - restrictions that have some good, logical founding in real life experiences of dealing with actual hardware that moves packets on the Internet - in favor of a specious claim, unsupported by ANY real-life example of ANY real org who cannot get IPv6, that tossing all of this out is going to magically get everyone to jump on the IPv6 bandwagon. Ted From tedm at ipinc.net Fri May 29 20:30:32 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 May 2009 17:30:32 -0700 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A207216.60202@matthew.at> References: <4A1FFE0E.7060805@arin.net> <4A204DDF.1020106@ipinc.net> <20090529211124.GO30913@angus.ind.WPI.EDU> <24c86a5f0905291501l43b66da5x9bba14eabdbd9535@mail.gmail.com> <4A206305.40607@ipinc.net> <4A207216.60202@matthew.at> Message-ID: <4A207E28.7010200@ipinc.net> Matthew Kaufman wrote: > Ted Mittelstaedt wrote: >> >> By contrast, the problem of table bloat in routers is very real. > Absolutely, but should not be ARIN's problem. ARIN should make it > possible for organizations (be they ISPs or not) to obtain unique > allocations from ARIN's portion of the IPv6 address space. It should be > easy to get allocations which are aggregated in such a way that they are > less expensive to route, but that shouldn't drive policy. OK then taking that argument to it's logical conclusion then let's just assign every last man and woman on the face of the earth an IPv6 number drawn out of a random lottery pool and let them plug in and have at it! >> You >> are essentially asking thousands of orgs out there to put money into >> tens of thousands of routers out there to replace them with new gear >> that will hold and manage a fantastically gigantic IPv6 table, > No. We are asking ARIN to fairly allocate reasonably-sized parts of IPv6 > to entities that ask, in return for no more than reasonable compensation. A single snowflake by itself harms no one. A trillion snowflakes creates an avalanche that kills people. >> just to >> make it a slight bit easier for small orgs to advertise a /32, who >> have absolutely no use for a /32 and would be happy with a /48, and >> who are getting the /32 because they are still scared to death about the >> old renumbering bugaboo - which doesn't even exist with IPv6 anyway. > That is between an org that wishes to *advertise their address space to > the global Internet routing infrastructure* and the transit provider who > is doing that for them (and entering into peering and/or transit > relationships with other providers in order to make that work) > > There's even better solutions to routing table bloat if you want ARIN to > be even more heavy-handed. For instance, ARIN could hold a lottery to > determine the one and only provider who is allowed to get address space > within the ARIN region and then everyone else would need to be customers > of the winner. Then the inter-provider table would be tiny. > Either extreme - having a single provider or having every user on the Internet get a random IPv6 number - is bad. Ted From mysidia at gmail.com Fri May 29 22:41:09 2009 From: mysidia at gmail.com (James Hess) Date: Fri, 29 May 2009 21:41:09 -0500 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A203143.5010908@matthew.at> References: <28E139F46D45AF49A31950F88C4974580161F064@E03MVZ2-UKDY.domain1.systemhost.net> <4A203143.5010908@matthew.at> Message-ID: <6eb799ab0905291941i68a78d11p2d84ff08eb2ea9b1@mail.gmail.com> > If your argument is routing table size, that's a separate problem that isn't >ARIN's problem. > > Back in the (actually not so) early IPv4 days, I got an IPv4 /24 for my > house. My friends and I learned a whole lot about setting up IP networks > using our real-world address. Didn't cost us a cent, and many of us have > gone on to do more interesting things in the Internet world. [snip] And it was that liberal allocation of /24s partly to blame for why IPv4 exhaustion is coming sooner than otherwise.... There simply aren't enough /32s in existence for _everyone_ to get one to play with. IPv6 /32s are just as limited in number as the number of IPv4 /32s.... The policies are liberal, but the line has to be drawn somewhere, otherwise exhaustion is inevitable. It's really only adequately justifiable for ISPs to get a /32 allocation.. or large organizations with many sites to get a /32 assignment. I oppose the policy as written. 200 sites may be too many, but there should be a qualification of number of sites, before such a large block is assigned. And also: the statement ?by advertising that connectivity through its single aggregated address allocation? Should not be removed, just because it has operational significance. It also has address numbering significance. Given the relative unfamiliarity of organizations operating IPv6 networks, and even of the basic ground rules, such as: make sure to advertise through the single aggregated allocation (instead of or in addition to any other smaller advertisements) Such reminders and applying that particular basic rule as policy should do more good than harm. -- -J From mksmith at adhost.com Fri May 29 23:57:03 2009 From: mksmith at adhost.com (Michael K. Smith) Date: Fri, 29 May 2009 20:57:03 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A1FFBE5.20807@arin.net> Message-ID: Hello All: I am in favor of this. I've been following the comments in the various threads and subthreads, and would add only this: - There is at least one major transit provider that will accept nothing more specific than a /32. - If we continue to inhibit providers' ability to get a /32, they may have reachability issues. - The v6 space is incredibly large. Really. What do we really gain from limiting some people to a /48? Mike On 5/29/09 8:14 AM, "Member Services" wrote: > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with Policy Development > Process. > > This proposal is in the first stage of the Policy Development Process. > ARIN staff will perform the Clarity and Understanding step. Staff does > not evaluate the proposal at this time, their goal is to make sure that > they understand the proposal and believe the community will as well. > Staff will report their results to the ARIN Advisory Council (AC) within > 10 days. > > The AC will review the proposal at their next regularly scheduled > meeting (if the period before the next regularly scheduled meeting is > less than 10 days, then the period may be extended to the subsequent > regularly scheduled meeting). The AC will decide how to utilize the > proposal and announce the decision to the PPML. > > In the meantime, the AC invites everyone to comment on the proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at:https://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Open Access To IPv6 > > Proposal Originator: Stacy Hughes and Cathy Aronson > > Proposal Version: 1.0 > > Date: 29 May 2009 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > 1) Remove ?by advertising that connectivity through its single > aggregated address allocation? from article 3 of section 6.5.1.1 > > 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in > the ARIN region or have a plan for making at least 200 end-site > assignments to other organizations within 5 years? in its entirety. > > Rationale: It is acknowledged that these concepts have been put before > the community in the past. However, with the wisdom of actual > operational experience, the necessity of promoting IPv6 adoption > throughout our region, and emerging native v6 only network models, it > becomes obvious that these modifications to the NRPM are necessary. > Removing the 200 end site requirement enables smaller, but no less > important and viable, networks access to IPv6. Removing the ?known ISP? > requirement enfranchises new, native v6 businesses that can drive > innovation and expansion in the Internet industry, as well as other > industries. Removing the requirement for a single aggregate announcement > benefits the NRPM itself, as it has been decided by the community that > it should not contain routing advice. > > Timetable for implementation: immediately upon BoT ratification > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From matthew at matthew.at Sat May 30 00:00:38 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 29 May 2009 21:00:38 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <6eb799ab0905291941i68a78d11p2d84ff08eb2ea9b1@mail.gmail.com> References: <28E139F46D45AF49A31950F88C4974580161F064@E03MVZ2-UKDY.domain1.systemhost.net> <4A203143.5010908@matthew.at> <6eb799ab0905291941i68a78d11p2d84ff08eb2ea9b1@mail.gmail.com> Message-ID: <4A20AF66.6050402@matthew.at> James Hess wrote: >> If your argument is routing table size, that's a separate problem that isn't >> ARIN's problem. >> >> Back in the (actually not so) early IPv4 days, I got an IPv4 /24 for my >> house. My friends and I learned a whole lot about setting up IP networks >> using our real-world address. Didn't cost us a cent, and many of us have >> gone on to do more interesting things in the Internet world. >> > [snip] > > And it was that liberal allocation of /24s partly to blame for why > IPv4 exhaustion is coming sooner than otherwise.... > You're right, but not for the reason you think. That liberal allocation meant that a whole lot of people who were playing with IP decided to try to hook up to the global Internet, and the commercial Internet happened. Without them, it might still be a research-and-education playground. > There simply aren't enough /32s in existence for _everyone_ > to get one to play with. > See my earlier comments about reasonably-sized allocations for anyone who asks... I didn't suggest that *everyone* would need or get a /32. Matthew Kaufman From matthew at matthew.at Sat May 30 00:02:57 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 29 May 2009 21:02:57 -0700 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A207E28.7010200@ipinc.net> References: <4A1FFE0E.7060805@arin.net> <4A204DDF.1020106@ipinc.net> <20090529211124.GO30913@angus.ind.WPI.EDU> <24c86a5f0905291501l43b66da5x9bba14eabdbd9535@mail.gmail.com> <4A206305.40607@ipinc.net> <4A207216.60202@matthew.at> <4A207E28.7010200@ipinc.net> Message-ID: <4A20AFF1.5090800@matthew.at> Ted Mittelstaedt wrote: > Matthew Kaufman wrote: >> Ted Mittelstaedt wrote: >>> >>> By contrast, the problem of table bloat in routers is very real. >> Absolutely, but should not be ARIN's problem. ARIN should make it >> possible for organizations (be they ISPs or not) to obtain unique >> allocations from ARIN's portion of the IPv6 address space. It should >> be easy to get allocations which are aggregated in such a way that >> they are less expensive to route, but that shouldn't drive policy. > > OK then taking that argument to it's logical conclusion then let's just > assign every last man and woman on the face of the earth an IPv6 number > drawn out of a random lottery pool and let them plug in and have at it! Well, you could do exactly that. And they could have their own chunk of IPv6 space *and* a separate, routeable PA address as well. And we *still* wouldn't run out. > >>> You >>> are essentially asking thousands of orgs out there to put money into >>> tens of thousands of routers out there to replace them with new gear >>> that will hold and manage a fantastically gigantic IPv6 table, >> No. We are asking ARIN to fairly allocate reasonably-sized parts of >> IPv6 to entities that ask, in return for no more than reasonable >> compensation. > > A single snowflake by itself harms no one. > > A trillion snowflakes creates an avalanche that kills people. Lots of people having non-routeable or non-routed addresses isn't going to kill anyone. Heck, even a big explosion in routing table size won't kill anyone. Maybe someone will take the time to solve the problem more elegantly than it has been so far, and it won't even matter. > > Either extreme - having a single provider or having every user on > the Internet get a random IPv6 number - is bad. And any system other than "anyone can get any size they can justify" will be unfair to someone. Matthew Kaufman From tvest at pch.net Sat May 30 12:15:44 2009 From: tvest at pch.net (Tom Vest) Date: Sat, 30 May 2009 12:15:44 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A205A75.10107@matthew.at> References: <2557049CDBC35B4EBD79CFACFEC045841B9F548B@XCH-NW-CCR1V.nw.nos.boeing.com> <20090529212938.GA11989@ussenterprise.ufp.org> <4A205A75.10107@matthew.at> Message-ID: On May 29, 2009, at 5:58 PM, Matthew Kaufman wrote: > Leo Bicknell wrote: >> >> The end user policy gives out /48's. If we want folks to get a >> network they can play with in their garage, let's do it under the >> end user policy. This policy proposal affects the ISP section, >> giving out /32's for the express purpose of assigning /48's to other >> entities. Let's leave it for folks who are really ISP's, and really >> providing services to others. >> > Ah. "Folks who are really ISPs". This is as bad as the com-priv list > in 1992... We *don't know* who is/will be "an ISP". A school > district providing service to all its schools? A corporation with a > dozen subsidiaries around the world? A guy in his garage who gives > away free wireless to his neighborhood? > > Really there shouldn't even *be* a distinction. If you need a / > whatever of IPv6 and can write a convincing letter to that effect, > you should be able to get at least that much unique IPv6 space. > Whether it can be routed now or in the future is really between you > and whichever transit provider you choose *should you even need > external connectivity*. Unfortunately, distinctions of some kind are unavoidable as long as the carry capacity of the routing system is finite, and jointly produced by independent routing services providers. If IPv6 allocation policies cause, or simply facilitate/accelerate the unsustainable growth of routing system requirements, then some other mechanism will have to emerge to mitigate that risk. IPv4 allocation policies have provided a flexible, transparent, limiting effect on the growth rate for routing requirements by making aggregation not only possible, but commonplace. In order to make aggregation *possible*, there must be some kind of eligibility test for justifying an institution's claim to a "top-level" role in the routing system, i.e., as an aggregator or an independent. In order to make aggregation *likely*, it's prudent to define those eligibility criteria in a way that aligns the aspiring top-level routing system participant's incentives with the continued sustained growth of the routing table -- e.g., with "needs" related criteria that demonstrate that the entity has invested real money in real factors (hardware, network capacity, etc.) that can generate value only as long as routing works, and that would be at risk of becoming worthless if the routing system becomes unmanageable or fails altogether. Since independents are by definition non-aggregatable, there needs to be some other (probably arbitrary) criterion to limit their absolute numbers, e.g., a steep up-front fee. And in order for the whole arrangement to be sustainable over time, there must be a clear, fair, and widely accepted mobility path for customers to become providers, or "independents", and vice versa. To be sustainable, everybody must have a clear "out" -- one that is clear both to insiders and outsiders. You don't want to be aggregated, fine, go make some investments that demonstrate that you've got chips in the same routing services game that the rest of us are playing, and you can get address resources of your own under community-defined policies. You just need to be independent? Fine, then pay this sizable, community-defined fee that demonstrates that your need is of roughly the same magnitude as the burden that "just need to be independents" like you impose on those who are playing by the rules of routing system sustainability. Don't want to pay that fee either? Okay, here are some operators that can provide you with aggregatable address resources bundled with routing services... Even if the quantity of usable IP addresses were literally infinite, it would prudent to think hard before dumping needs-related allocation criteria. Because if/when this arrangement is abandoned at the point of IP address distribution, something similar will just have to be recreated at the level of routing service provision. Unfortunately, at that level there won't be an "out" for anybody -- there's no credible way to tell an aspiring new entrant "fine, just go build your own global-scale IP transit system." We like to remind ourselves that routing decisions are the absolute sole prerogative of individual operators, but there are some circumstances in which that would likely be more of a problem than a point of honor. To date, the inter-domain routing system has been a global scale "cooperative undertaking" -- but the only material difference between a "cooperative undertaking" and a "collusive cartel" is the non-discriminatory, non-adversarial, openness of that system to new players. Absolute sovereignty over routing decisions has no downside as long as somebody else (e.g., the address allocator) guarantees market openness. But if/when that ceases to be true, you're on the hook. You don't like "distinctions" applied at the level of address allocation, fine -- what kind of distinctions are you going to impose on aspiring customers who want you to announce their PI prefixes? What kind of distinctions do you expect will be imposed on your announcements by upstream providers? How are you going to justify your own routing service rationing criteria to critics, because there are always critics...? TV From mueller at syr.edu Sat May 30 14:36:36 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 30 May 2009 14:36:36 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com> References: <4A1FFBE5.20807@arin.net> <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> <2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com> Message-ID: <75822E125BCB994F8446858C4B19F0D77B2209E4@SUEX07-MBX-04.ad.syr.edu> I support the principle of this proposal, but am somewhat taken aback by the idea that /32s would be the basic unit for smaller, innovative v6 entities. Aren't /48s, which still constitute a huge number of addresses, enough? Or am I missing something here? Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org ________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Stacy Hughes Sent: Friday, May 29, 2009 9:25 AM To: Member Services Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6 Hello Everyone, Before we really get started on this policy proposal, I must give credit where credit is due. Jordi Palet Martinez brought this topic to the table 3 years ago, and it got shot down. I myself, in my small IPv4-centric mind, thought it impossible that an IPv6 only organization could exist. Operations and innovation have shown me the error of our thinking. To quote myself from a different list: IPv6 is a new paradigm we are supposed to be doing our best to encourage. As it stands, those community guys can't get it, the Caribbean guys can't get it, and basically anyone trying to do anything vanguard can't get it either. (I hear the ULA objections here, even when they're nascent). We can be afraid of what IPv6 might do to the routing table, or we can embrace what IPv6 can and will do for the Internet. I choose the latter and support this proposal. Stacy On Fri, May 29, 2009 at 8:14 AM, Member Services > wrote: ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at:https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Open Access To IPv6 Proposal Originator: Stacy Hughes and Cathy Aronson Proposal Version: 1.0 Date: 29 May 2009 Proposal type: modify Policy term: permanent Policy statement: 1) Remove "by advertising that connectivity through its single aggregated address allocation" from article 3 of section 6.5.1.1 2) Remove article 4 of section 6.5.1.1, "be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years" in its entirety. Rationale: It is acknowledged that these concepts have been put before the community in the past. However, with the wisdom of actual operational experience, the necessity of promoting IPv6 adoption throughout our region, and emerging native v6 only network models, it becomes obvious that these modifications to the NRPM are necessary. Removing the 200 end site requirement enables smaller, but no less important and viable, networks access to IPv6. Removing the 'known ISP' requirement enfranchises new, native v6 businesses that can drive innovation and expansion in the Internet industry, as well as other industries. Removing the requirement for a single aggregate announcement benefits the NRPM itself, as it has been decided by the community that it should not contain routing advice. Timetable for implementation: immediately upon BoT ratification _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Sat May 30 14:42:52 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 30 May 2009 14:42:52 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A202F60.8000408@matthew.at> References: <4A1FFBE5.20807@arin.net> <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> <2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com> <4A202F60.8000408@matthew.at> Message-ID: <75822E125BCB994F8446858C4B19F0D77B2209E5@SUEX07-MBX-04.ad.syr.edu> > I also believe that the popular press accounts of > there being so many IPv6 addresses that they're essentially free conflict > strongly with the current ARIN fee structure, which is another impediment to > people who might otherwise experiment with IPv6 and build new business > models around it. > > If there's really so many that that's true, anyone ought to > be able to get some for approximately nothing. And if the > counter-argument is that the administrative overhead is too high for > that, then maybe more automation would be easier with a less-restrictive policy > (such as this one). I have become increasingly skeptical of the "atoms in the universe" understandings of IPv6 address availability. If you haven't already read it, here's a good corrective: http://www.ietf.org/proceedings/05aug/IDs/draft-narten-iana-rir-ipv6-considerations-00.txt Still, that issue (the size of initial allocations) is independent of the issue of whether they ought to be restricted to providers. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org From cra at WPI.EDU Sat May 30 14:53:39 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 30 May 2009 14:53:39 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B2209E4@SUEX07-MBX-04.ad.syr.edu> References: <4A1FFBE5.20807@arin.net> <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> <2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com> <75822E125BCB994F8446858C4B19F0D77B2209E4@SUEX07-MBX-04.ad.syr.edu> Message-ID: <20090530185339.GA17721@angus.ind.WPI.EDU> On Sat, May 30, 2009 at 02:36:36PM -0400, Milton L Mueller wrote: > I support the principle of this proposal, but am somewhat taken > aback by the idea that /32s would be the basic unit for smaller, > innovative v6 entities. Aren't /48s, which still constitute a huge > number of addresses, enough? Or am I missing something here? The problem is /48s are the basic unit of each site. So said smaller innovative IPv6 entities would need to assign /48s out of something larger. From mysidia at gmail.com Sat May 30 14:54:41 2009 From: mysidia at gmail.com (James Hess) Date: Sat, 30 May 2009 13:54:41 -0500 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B2209E4@SUEX07-MBX-04.ad.syr.edu> References: <4A1FFBE5.20807@arin.net> <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> <2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com> <75822E125BCB994F8446858C4B19F0D77B2209E4@SUEX07-MBX-04.ad.syr.edu> Message-ID: <6eb799ab0905301154v77d8fc34t89edb8fd452a3c71@mail.gmail.com> On Sat, May 30, 2009 at 1:36 PM, Milton L Mueller wrote: > I support the principle of this proposal, but am somewhat taken aback by the > idea that /32s would be the basic unit for smaller, innovative v6 entities. > Aren't /48s, which still constitute a huge number of addresses, enough? Or > am I missing?something here? Yes, a /48 or /56 should be more than adequate for innovative entities that aren't actual ISPs.. And it should generally be the entity's upstream/bacbkone provider that assigns this, not ARIN.. If ARIN is to take on the expense of assigning anything to entities with a smaller address space need, there should be a good reason; maybe encouraging V6 adoption and unavailability of V6 space from V4 upstreams is a good reason, at least for some time... Receiving a /32 to play with at your house, is as if the IPv4 registry had given you a /16 to play with back in the 1980s.... The fact that some major providers won't propagate something smaller than a /32 is not a good reason to mismanage the address space and assign /32s when it's not called for. Interestingly, that's also an operational rationale... and yet the same policy proposal proposes removing (1) because it's an operationally-related policy. IPv6 is not an educational / research playground, it's already much more significant, and more likely than not will be more so when V4 gets closer to actually running out..... ARIN policies don't prevent or discourage V6 adoption.. In fact, they appear to be fairly liberal.. -- -J From bill at herrin.us Sat May 30 15:05:58 2009 From: bill at herrin.us (William Herrin) Date: Sat, 30 May 2009 15:05:58 -0400 Subject: [arin-ppml] A modest proposal for IPv6 address allocations Message-ID: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> So here's a crazy plan: A. The first IPv6 allocation from ARIN is always a /48. To justify it, you need to be multihomed. There are no other qualifications. The /48 will be allocated from a pool from which only /48's are allocated. B. The second IPv6 allocation from ARIN is always a /32. To justify it you need to demonstrate that you've efficiently used the /48 for some reasonable definition of efficient, that you've implemented SWIP or RWHOIS for your downstream assignments and that you will run out of space in the /48 within one year. The /32 will be allocated from a pool reserved for allocating /32's. C. The third IPv6 allocation from ARIN is always a /24. To justify it you need to demonstrate that you've efficiently used the /32, that you will run out of space in the /32 within five years, and you have to first return the original /48 you were assigned. The /24 will be allocated from a pool reserved for allocating /24's. D. There is no fourth IPv6 allocation at this time. It is not presently possible to consume an entire /24 without atrocious waste. What are the consequences of this plan? 1. Efficient allocation of IP addresses. Orgs get what they need when they need it and not before without a great deal of guesswork about actual need. 2. Efficient utilization of BGP routing slots. No single multihomed org will ever announce more than 2 necessary routes. 3. Traffic engineering routes are trivially filterable since any route longer than the published allocation size can be presumed to be traffic engineering, not a downstream multihomed customer, thus you can filter distant small routes with confidence and ease. 4. No need to define the difference between ISP and not ISP. Everybody plays by the same rules. 5. No complicated analysis for the first allocation. You're either multihomed or you're not. If you're multihomed, you qualify. 6. For those who can live within the /48 there are distinct advantages: no swip or rwhois reporting and the generic end-user annual fee instead of the ISP annual fee. Once you're up to a /32, you pay the ISP annual fee. As a result, ARIN doesn't have to scrutinize the /32 requests too closely either. Thoughts? Criticisms? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From gdolley at arpnetworks.com Sat May 30 15:06:23 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 12:06:23 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> Message-ID: <20090530190622.GC27636@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 10:49:02AM -0700, Stacy Hughes wrote: > A multihoming requirement discriminates against networks that either cannot > or do not want to multihome.I oppose this modification. > Stacy If you aren't multi-homed, you should get an allocation from your upstream, IMO. The block provided by the upstream will be aggregated, most likely, to *their* upstream / peers, so an extra routing table slot would not be needed, thereby saving resources. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 15:11:33 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 12:11:33 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529212938.GA11989@ussenterprise.ufp.org> References: <2557049CDBC35B4EBD79CFACFEC045841B9F548B@XCH-NW-CCR1V.nw.nos.boeing.com> <20090529212938.GA11989@ussenterprise.ufp.org> Message-ID: <20090530191133.GD27636@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 05:29:38PM -0400, Leo Bicknell wrote: > In a message written on Fri, May 29, 2009 at 02:22:58PM -0700, Davis, Terry L wrote: > > The simple answer is that regardless of how we try to prevent it; our > > computing environment gets built into our applications. In short, > > although IPv6 makes re-addressing easy, it cannot fix the parts of an > > entity's infrastructure that get built into code, scripts, or > > configs. > > I've noticed several people blurring a line here, but Terry had the > easiest post to reply to and hit the relevant point. > > This policy addresses the IPv6 allocation policy for ISP's. There > is a separate, different policy for End Users. Most Enterprises > that are building addresses into code (a big no no, but yes, it > happens) would get space under the End User policy for any number > of reasons. > > But, here in lies the rub. This policy makes it easier for an > enterprise to receive a ISP allocation (and get hit with SWIP > requirements, ISP fees, and other associated items) than it does > for them to get an End User assignment in many cases. > > The end user policy gives out /48's. If we want folks to get a > network they can play with in their garage, let's do it under the > end user policy. This policy proposal affects the ISP section, > giving out /32's for the express purpose of assigning /48's to other > entities. Let's leave it for folks who are really ISP's, and really > providing services to others. I second this. Allocation policy for an ISP, where they can get a /32 for the purpose of assigning /48's to other entities and providing service to them, should really be for real ISPs. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From scottleibrand at gmail.com Sat May 30 15:11:38 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sat, 30 May 2009 14:11:38 -0500 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> Message-ID: <4A2184EA.7020708@gmail.com> I think this could be a good framework for a serious simplification of our IPv6 policy. Not sure about all the details, but I like the fact that we'd be able to do away with the ISP/end-user distinction, make it easy to get a /48, and provide a simple growth path for the most common cases... -Scott William Herrin wrote: > So here's a crazy plan: > > A. The first IPv6 allocation from ARIN is always a /48. To justify it, > you need to be multihomed. There are no other qualifications. The /48 > will be allocated from a pool from which only /48's are allocated. > > B. The second IPv6 allocation from ARIN is always a /32. To justify it > you need to demonstrate that you've efficiently used the /48 for some > reasonable definition of efficient, that you've implemented SWIP or > RWHOIS for your downstream assignments and that you will run out of > space in the /48 within one year. The /32 will be allocated from a > pool reserved for allocating /32's. > > C. The third IPv6 allocation from ARIN is always a /24. To justify it > you need to demonstrate that you've efficiently used the /32, that you > will run out of space in the /32 within five years, and you have to > first return the original /48 you were assigned. The /24 will be > allocated from a pool reserved for allocating /24's. > > D. There is no fourth IPv6 allocation at this time. It is not > presently possible to consume an entire /24 without atrocious waste. > > What are the consequences of this plan? > > 1. Efficient allocation of IP addresses. Orgs get what they need when > they need it and not before without a great deal of guesswork about > actual need. > > 2. Efficient utilization of BGP routing slots. No single multihomed > org will ever announce more than 2 necessary routes. > > 3. Traffic engineering routes are trivially filterable since any route > longer than the published allocation size can be presumed to be > traffic engineering, not a downstream multihomed customer, thus you > can filter distant small routes with confidence and ease. > > 4. No need to define the difference between ISP and not ISP. Everybody > plays by the same rules. > > 5. No complicated analysis for the first allocation. You're either > multihomed or you're not. If you're multihomed, you qualify. > > 6. For those who can live within the /48 there are distinct > advantages: no swip or rwhois reporting and the generic end-user > annual fee instead of the ISP annual fee. Once you're up to a /32, you > pay the ISP annual fee. As a result, ARIN doesn't have to scrutinize > the /32 requests too closely either. > > Thoughts? Criticisms? > > Regards, > Bill Herrin > > From gdolley at arpnetworks.com Sat May 30 15:20:29 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 12:20:29 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A205A75.10107@matthew.at> References: <2557049CDBC35B4EBD79CFACFEC045841B9F548B@XCH-NW-CCR1V.nw.nos.boeing.com> <20090529212938.GA11989@ussenterprise.ufp.org> <4A205A75.10107@matthew.at> Message-ID: <20090530192029.GE27636@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 02:58:13PM -0700, Matthew Kaufman wrote: > Leo Bicknell wrote: >> >> The end user policy gives out /48's. If we want folks to get a >> network they can play with in their garage, let's do it under the >> end user policy. This policy proposal affects the ISP section, >> giving out /32's for the express purpose of assigning /48's to other >> entities. Let's leave it for folks who are really ISP's, and really >> providing services to others. >> > Ah. "Folks who are really ISPs". This is as bad as the com-priv list in > 1992... We *don't know* who is/will be "an ISP". A school district > providing service to all its schools? A corporation with a dozen > subsidiaries around the world? A guy in his garage who gives away free > wireless to his neighborhood? > > Really there shouldn't even *be* a distinction. If you need a /whatever of > IPv6 and can write a convincing letter to that effect, you should be able > to get at least that much unique IPv6 space. Whether it can be routed now > or in the future is really between you and whichever transit provider you > choose *should you even need external connectivity*. It is not only between you and the transit provider. It is also between you and all the networks / network operators that collectively make up the Internet. If I'm going to carry your prefix in my routing table and the resources of my routing table are finite, and more routing table resources often costs me a appreciable amount of additional money (money out of my pocket, not yours), then I have a say in whether you get a "/whatever" allocation just b/c you wrote a convincing letter. This is why we are discussing the policy proposal ;) For the record, I oppose this policy proposal. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 15:27:11 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 12:27:11 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045841B9F5490@XCH-NW-CCR1V.nw.nos.boeing.com> References: <2557049CDBC35B4EBD79CFACFEC045841B9F548B@XCH-NW-CCR1V.nw.nos.boeing.com> <20090529212938.GA11989@ussenterprise.ufp.org> <2557049CDBC35B4EBD79CFACFEC045841B9F5490@XCH-NW-CCR1V.nw.nos.boeing.com> Message-ID: <20090530192711.GF27636@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 02:42:57PM -0700, Davis, Terry L wrote: > Leo > > We've had our /32 for something like five years now and yes for enterprises it is certainly doable. > > But to get IPv6 implementations under way in the needed scale, we need to find a way to make it easily obtainable for at least education and small/startup businesses. As with IPv4, the "easily obtainable" way for an organization to get IPv6 address space that doesn't currently qualify for an ISP allocation, is to get the address space from their upstream. Once the organization grows and can qualify for their own allocation from ARIN, they can apply for one and renumber their network. There is also the IPv6 End-User allocation, which is a viable option as well (and we didn't really have this in IPv4, AFAIK, except for the micro / experimental allocations, which I did not see used much in practice) -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 15:47:54 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 12:47:54 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A203143.5010908@matthew.at> References: <28E139F46D45AF49A31950F88C4974580161F064@E03MVZ2-UKDY.domain1.systemhost.net> <4A203143.5010908@matthew.at> Message-ID: <20090530194754.GG27636@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 12:02:27PM -0700, Matthew Kaufman wrote: > michael.dillon at bt.com wrote: >>> A multihoming requirement discriminates against networks that either >>> cannot or do not want to multihome. >>> >> >> Not if you use something like the wording I suggested where you explicitly >> say that all ISPs are assumed >> to qualify. >> >> The point is that we don't want to give /32 to just anyone. > > Why? Either there's enough that doing that has no risk of ever running out, > or there aren't enough, in which case *all* the existing policies are too > liberal. > > If your argument is routing table size, that's a separate problem that > isn't ARIN's problem. > > Back in the (actually not so) early IPv4 days, I got an IPv4 /24 for my > house. My friends and I learned a whole lot about setting up IP networks > using our real-world address. Didn't cost us a cent, and many of us have > gone on to do more interesting things in the Internet world. > > Today, if my kids wanted to get a real IPv6 /32 to play with, they'd have > to pay a bunch of money and fill out a bunch of paperwork. So they won't be > doing that. Even though there's plenty of IPv6 space for everyone on the > planet to play. > > Either we want to encourage adoption or we want to keep this as tightly > controlled as IPv4 has become. The former seems like a better idea, given > how IPv4 is going. The reason is, with IPv6, we're trying to come up with a more predictable way of allocating blocks to different organizations [1] [2]. In IPv4, it was roughly "as much space as you could justify". This caused a lot of networks to get several dis-continuguous blocks, first some small ones, then bigger ones. This causes problems with aggregation / summarization. Currently, it is generally accepted that /32's are for organizations that will assign /48's to further downstream organizations. Those that don't do this can be satisfied by just one /48. There are plenty of subnets available in a /48 to "play with" and learn all kinds of things. 1. RFC 5375, "IPv6 Unicast Address Assignment Considerations" 2. RFC 3177, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites" -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From bmanning at vacation.karoshi.com Sat May 30 15:50:50 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 30 May 2009 19:50:50 +0000 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530190622.GC27636@garry-thinkpad.arpnetworks.com> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> <20090530190622.GC27636@garry-thinkpad.arpnetworks.com> Message-ID: <20090530195050.GA21698@vacation.karoshi.com.> On Sat, May 30, 2009 at 12:06:23PM -0700, Garry Dolley wrote: > On Fri, May 29, 2009 at 10:49:02AM -0700, Stacy Hughes wrote: > > A multihoming requirement discriminates against networks that either cannot > > or do not want to multihome.I oppose this modification. > > Stacy > > If you aren't multi-homed, you should get an allocation from your > upstream, IMO. The block provided by the upstream will be > aggregated, most likely, to *their* upstream / peers, so an extra > routing table slot would not be needed, thereby saving resources. > > -- > Garry Dolley > ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 what upstream is that? once again, the limiting notion that there connectedness to "someone else" is a prerequiste for using IP. uniqueness i can understand (someday you might want to be connected, but now...) --bill From bmanning at vacation.karoshi.com Sat May 30 15:51:37 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 30 May 2009 19:51:37 +0000 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: <4A2184EA.7020708@gmail.com> References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> <4A2184EA.7020708@gmail.com> Message-ID: <20090530195137.GB21698@vacation.karoshi.com.> can you say,,, A. B. C.... --bill On Sat, May 30, 2009 at 02:11:38PM -0500, Scott Leibrand wrote: > I think this could be a good framework for a serious simplification of > our IPv6 policy. Not sure about all the details, but I like the fact > that we'd be able to do away with the ISP/end-user distinction, make it > easy to get a /48, and provide a simple growth path for the most common > cases... > > -Scott > > William Herrin wrote: > >So here's a crazy plan: > > > >A. The first IPv6 allocation from ARIN is always a /48. To justify it, > >you need to be multihomed. There are no other qualifications. The /48 > >will be allocated from a pool from which only /48's are allocated. > > > >B. The second IPv6 allocation from ARIN is always a /32. To justify it > >you need to demonstrate that you've efficiently used the /48 for some > >reasonable definition of efficient, that you've implemented SWIP or > >RWHOIS for your downstream assignments and that you will run out of > >space in the /48 within one year. The /32 will be allocated from a > >pool reserved for allocating /32's. > > > >C. The third IPv6 allocation from ARIN is always a /24. To justify it > >you need to demonstrate that you've efficiently used the /32, that you > >will run out of space in the /32 within five years, and you have to > >first return the original /48 you were assigned. The /24 will be > >allocated from a pool reserved for allocating /24's. > > > >D. There is no fourth IPv6 allocation at this time. It is not > >presently possible to consume an entire /24 without atrocious waste. > > > >What are the consequences of this plan? > > > >1. Efficient allocation of IP addresses. Orgs get what they need when > >they need it and not before without a great deal of guesswork about > >actual need. > > > >2. Efficient utilization of BGP routing slots. No single multihomed > >org will ever announce more than 2 necessary routes. > > > >3. Traffic engineering routes are trivially filterable since any route > >longer than the published allocation size can be presumed to be > >traffic engineering, not a downstream multihomed customer, thus you > >can filter distant small routes with confidence and ease. > > > >4. No need to define the difference between ISP and not ISP. Everybody > >plays by the same rules. > > > >5. No complicated analysis for the first allocation. You're either > >multihomed or you're not. If you're multihomed, you qualify. > > > >6. For those who can live within the /48 there are distinct > >advantages: no swip or rwhois reporting and the generic end-user > >annual fee instead of the ISP annual fee. Once you're up to a /32, you > >pay the ISP annual fee. As a result, ARIN doesn't have to scrutinize > >the /32 requests too closely either. > > > >Thoughts? Criticisms? > > > >Regards, > >Bill Herrin > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing 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 gdolley at arpnetworks.com Sat May 30 15:56:29 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 12:56:29 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: References: <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> Message-ID: <20090530195629.GH27636@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 01:18:20PM -0500, Chris Malayter wrote: > Agree with Stacy here, > > I don?t think putting strings on v6 is going help drive it?s implementation.. There are no string on IPv6. If your ISP/NSP supports IPv6, you can get a /48 *right now*. Some providers will have *already* allocated it for you (as mentioned by someone previously in this thread who gives IPv6 to all his customers by default). My company has a /32. Should I say my IPv6 efforts are hindered just because I can't get a /16? No, because for my needs a /32 is sufficient. And a /48 for end-sites / non-ISPs, with 65K subnets and all their glory, is _sufficient_ also. To say IPv6 adoption is hindered b/c everyone can't qualify for a /32 is simply non-sense, IMO. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 16:07:11 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 13:07:11 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: References: <4A204EC1.5050905@ipinc.net> Message-ID: <20090530200711.GI27636@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 04:14:56PM -0500, Chris Malayter wrote: > This mentality will only serve to slow ipv6 adoption in application and > content. The easier we make it for non-isps to get portable space, the more > development will occur. Basic supply and demand theory in action here.... Can't non-ISPs simply apply for a /48 end-user allocation? [1] I don't get this argument I'm seeing in this thread that without the proposed policy modification, IPv6 adoption will be hindered. 1. https://www.arin.net/resources/request/ipv6_initial_assign.html -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 16:13:55 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 13:13:55 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A205494.40507@matthew.at> References: <4A203143.5010908@matthew.at> <28E139F46D45AF49A31950F88C4974580161F072@E03MVZ2-UKDY.domain1.systemhost.net> <2557049CDBC35B4EBD79CFACFEC045841B9F5488@XCH-NW-CCR1V.nw.nos.boeing.com> <4A204EC1.5050905@ipinc.net> <4A205494.40507@matthew.at> Message-ID: <20090530201355.GJ27636@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 02:33:08PM -0700, Matthew Kaufman wrote: > Ted Mittelstaedt wrote: >> >> Simple. Developer calls ISP and asks for IPv6. ISP says not right now. >> Developer gives ISP reasonable amount of time to get IPv6. ISP does not. >> Developer calls ISP and cancels service and tells them they are >> cancelling because they are going down the street to a different ISP >> that IS supplying IPv6. > You're mixing up unique IPv6 address space and IPv6 connectivity to the > global IPv6 Internet. > > Lets say, for instance, that Developer is working on a neat application > that could have millions of connected nodes, and they want some unique > address space assigned so they can start building that in their lab... > > In 1990, the IPv4 answer was "you send some email explaining what you're > doing, and you get at least that much address space uniquely allocated to > you at no charge". > > Here it is, almost 20 years later, and the IPv6 answer isn't nearly as > attractive. And we wonder why people aren't building neat new things with > it. IPv6 is not IPv4. For your lab scenario, the developer can use ULAs (Unique Local IPv6 Addresses) [1]. Right now, ULAs is a proposed standard. 1. RFC 4193, "Unique Local IPv6 Unicast Addresses" -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 16:21:28 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 13:21:28 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A205378.4020602@matthew.at> References: <4A203143.5010908@matthew.at> <28E139F46D45AF49A31950F88C4974580161F072@E03MVZ2-UKDY.domain1.systemhost.net> <2557049CDBC35B4EBD79CFACFEC045841B9F5488@XCH-NW-CCR1V.nw.nos.boeing.com> <20090529210113.GA12174@vacation.karoshi.com.> <4A205378.4020602@matthew.at> Message-ID: <20090530202128.GK27636@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 02:28:24PM -0700, Matthew Kaufman wrote: > bmanning at vacation.karoshi.com wrote: >> Terry, >> you hint at, but never bring out the fact that in the 1980's there was >> less emphasis on connectivity >> and much more interest in ensuring global uniqueness. Back in that >> timeframe, there was no expectation on connectivity >> to some mythic core as a precondition to get resources. >> >> the current IPv6 polices make and re-inforce that expectation - with the >> results you see/docuement below. >> i'd be much happier to see a policy structure that was more concerned w/ >> getting globally unique resources into the >> hands of people who can present a credible story than trying to reign in >> growth due to the problematic dragon at the >> door - e.g. the expectation of global connectivity. >> >> e.g. I favor uniqueness over reachability any day of the week >> >> or in modren parlence... >> >> +1 >> > Exactly my point. ARIN should make it as easy and cheap as possible for > anyone to get as much unique IPv6 address space as they might need. Which, > since there's a whole lot of it, shouldn't be that hard a task to > accomplish. Certainly the level of justification required and the price > charged should be significantly more attractive than IPv4, of which there > is a shortage. > > Whether or not those addresses are or are not globally routeable now or at > some future time is really beside the point. If uniqueness and not routeability is your main concern, there is already a solution for this [1]. Once again, IPv6 is not IPv4. :) 1. RFC 4193, "Unique Local IPv6 Unicast Addresses" -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 16:33:21 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 13:33:21 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com> References: <4A1FFBE5.20807@arin.net> <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> <2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com> Message-ID: <20090530203321.GL27636@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 09:48:35AM -0700, Davis, Terry L wrote: > Stacy > > I fully support this proposal. > > I think we can look at the current almost total lack of IPv6 implementation anywhere (not even significantly in universities and not at all in startups) and realize that our current policies are not supporting/encouraging v6 implementations. > The lack of IPv6 support is not because orgs can't get addresses. For most networks, it is because there isn't enough reason to justify the cost of rolling out a full IPv6 implementation. I run my own multi-homed network and have worked in the past and present running other networks. No network but my own has IPv6, and I only have IPv6 because I tend to think about the future, and I like learning new things. It certainly wasn't a cost or demand issue. My customers rarely ask me for IPv6 addresses. Currently, I'm in the process of giving every customer a /48, whether they like it or not :) Maybe this will encourage them to use IPv6. Adoption is slow because the demand isn't there. Saying anyone can get an IPv6 /32 block is not going to magically make the demand rise. There is a large barrier to entry just to get a /21 in IPv4, but is IPv4 "adoption" hindered? No. You *have* to have IPv4 to get your stuff on the Internet. There is demand for it. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 16:34:08 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 13:34:08 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B2209E4@SUEX07-MBX-04.ad.syr.edu> References: <4A1FFBE5.20807@arin.net> <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> <2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com> <75822E125BCB994F8446858C4B19F0D77B2209E4@SUEX07-MBX-04.ad.syr.edu> Message-ID: <20090530203408.GM27636@garry-thinkpad.arpnetworks.com> On Sat, May 30, 2009 at 02:36:36PM -0400, Milton L Mueller wrote: > I support the principle of this proposal, but am somewhat taken aback by the idea that /32s would be the basic unit for smaller, innovative v6 entities. > Aren't /48s, which still constitute a huge number of addresses, enough? Or am I missing something here? Yes, IMO, /48's are plenty -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 16:40:53 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 13:40:53 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A202F60.8000408@matthew.at> References: <4A1FFBE5.20807@arin.net> <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> <2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com> <4A202F60.8000408@matthew.at> Message-ID: <20090530204053.GN27636@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 11:54:24AM -0700, Matthew Kaufman wrote: > Davis, Terry L wrote: >> >> Stacy >> >> >> I fully support this proposal. >> >> I think we can look at the current almost total lack of IPv6 >> implementation anywhere (not even significantly in universities and not at >> all in startups) and realize that our current policies are not >> supporting/encouraging v6 implementations. >> > I agree. I also believe that the popular press accounts of there being so > many IPv6 addresses that they're essentially free conflict strongly with > the current ARIN fee structure, which is another impediment to people who > might otherwise experiment with IPv6 and build new business models around > it. > > If there's really so many that that's true, anyone ought to be able to get > some for approximately nothing. And if the counter-argument is that the > administrative overhead is too high for that, then maybe more automation > would be easier with a less-restrictive policy (such as this one). In terms of addresses, yes, there are more addresses in IPv6 that it is hard to imagine. But not in terms of subnets. This is why number of addresses is rarely talked about in IPv6 now, but rather the number of subnets. There are not enough /32 subnets to give away to everyone. There are as many /32 subnets in IPv6 as there are in IPv4. Just in IPv4, the /32 subnet just held 1 address. We are running out of IPv4, so by the same token, if we liberally give away /32's in IPv6, we'll face the same exhaustion. Even faster since people are proposing to loosen up the policies that would not have ever been thought of in IPv4. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 16:47:42 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 13:47:42 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: References: <4A1FFBE5.20807@arin.net> Message-ID: <20090530204741.GO27636@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 08:57:03PM -0700, Michael K. Smith wrote: > Hello All: > > I am in favor of this. I've been following the comments in the various > threads and subthreads, and would add only this: > > - There is at least one major transit provider that will accept nothing more > specific than a /32. And why do you think that is? If we give a /32 to anyone who asks for it, I *guarantee* you that major ISPs will stop accepting /32's. There will be too many of them. They'll take it down to /30s or /24s or something like that. > - If we continue to inhibit providers' ability to get a /32, they may have > reachability issues. > - The v6 space is incredibly large. Really. What do we really gain from > limiting some people to a /48? The number of addresses in IPv6 is incredibly large, but not the number of /32 subnets. Guys, do the math. There are the same number of /32 subnets in IPv6 as in IPv4. We are running out of IPv4. We'll run out of IPv6 if there is no barrier to entry on a /32. 2^32 = 4,294,967,296 -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 17:04:22 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 14:04:22 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529201502.GA6398@ussenterprise.ufp.org> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <20090529185841.GA87992@gweep.net> <20090529201502.GA6398@ussenterprise.ufp.org> Message-ID: <20090530210421.GP27636@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 04:15:02PM -0400, Leo Bicknell wrote: > In a message written on Fri, May 29, 2009 at 02:58:41PM -0400, Joe Provo wrote: > > I appreciate the intent, but what's the point of yet another > > unenforcable clause? Enterprises with multiple private BGP > > relationships would qualifiy under this and be invisible. > > ARIN actually has a long history of "enforcing" this, the current > IPv4 criteria has a provision for multi-homed networks to get a > allocation when single homed networks do not qualify. I will leave > staff to comment on how they enforce the criteria. > > With IPv6 we will run out of routing slots before we run out of > numbers. Using the sign at the Chinese Buffet as an example: > > Take all you want, eat all you take. > > Like it or not, the network can't take every residential user having > their own PI block and routing it. We don't have routers that can > support 500 million routes. We can make a big mess by handing > things out willy nilly, but just like the dark days of the Internet > passed the operators will fix it with draconian filtering policies > that will do no one any good. Making a mess the operators have to > fix will create no good will, nor internet stability. > > To that end, I can't support the proposal as written. As one > commenter asked, "what if my kids want an IPv6 network to play with > in their garage?" Well, we should find some way to accomodate that > which doesn't require service providers worldwide to spend tens of > thousands of dollars upgrading routers to hold the routes. Exactly. There's really no reason I should bear the cost of carrying your route because your kids want to learn about IPv6. I wholeheartedly want to support learning about IPv6, esp. for the next generation of network operators, but doing so in a way that taxes third party network hardware, for no reason, is not the way to do it. Might I suggest ULAs? [1] > I realize ARIN does not dictate routing behavior. However, I can > tell you how this ends if we get it wrong. If the table grows too > fast operators will make their own decisions about "who is worthy". > I suspect those decisions will be made along the lines of who has > money to pay to route the prefixes. If you're worried about your > kids getting free IP's to play with the you should really worry > about the $1,000 per month per prefix charge that will come to route > it to limit table sale. Once again, spot on. ARIN is acting as a regulatory body. If ARIN doesn't do this, then regulation falls on the private corporations to "police themselves" and make their own rules. And if the situation with the banking industry in the United States is any indication, leave it up to the corporations to police themselves, and it'll end up where the highest bidder is the winner, "best practices" are thrown out the window in favor "they are willing to pay $XXXX, make it work", and other "for profit" / "profit first" non-sense. I want ARIN to put up the barrier to entry on /32 prefixes, because if they don't, the multi-million dollar ISPs will start making their own rules. 1. RFC 4193, "Unique Local IPv6 Unicast Addresses" http://tools.ietf.org/html/rfc4193 -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 17:11:25 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 14:11:25 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529160246.GA23729@gweep.net> References: <4A1FFBE5.20807@arin.net> <4A200639.4030209@rollernet.us> <20090529160246.GA23729@gweep.net> Message-ID: <20090530211125.GQ27636@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 12:02:46PM -0400, Joe Provo wrote: > On Fri, May 29, 2009 at 08:58:49AM -0700, Seth Mattinen wrote: > > Member Services wrote: > [snip] > > > 1) Remove ???by advertising that connectivity through its single > > > aggregated address allocation??? from article 3 of section 6.5.1.1 > > > > What's the rationale for this proposed change? > > It better reflects the reality of the meshy global Internet where > aggregated trunk, backbone-only providers are a rare and dying breed. In what reality is this true? Regional ISPs aggregate. Content provider ISPs/NSPs aggregate. Come to think of it, every network I can think of aggregates and sends traffic to a higher speed uplink / trunk. The cell phone network and ad-hoc mesh networking supported by laptops like the OLPC, are the only examples that come to mind that support the "meshy" global Internet. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 17:22:53 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 14:22:53 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530195050.GA21698@vacation.karoshi.com.> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> <20090530190622.GC27636@garry-thinkpad.arpnetworks.com> <20090530195050.GA21698@vacation.karoshi.com.> Message-ID: <20090530212253.GA2827@garry-thinkpad.arpnetworks.com> On Sat, May 30, 2009 at 07:50:50PM +0000, bmanning at vacation.karoshi.com wrote: > On Sat, May 30, 2009 at 12:06:23PM -0700, Garry Dolley wrote: > > On Fri, May 29, 2009 at 10:49:02AM -0700, Stacy Hughes wrote: > > > A multihoming requirement discriminates against networks that either cannot > > > or do not want to multihome.I oppose this modification. > > > Stacy > > > > If you aren't multi-homed, you should get an allocation from your > > upstream, IMO. The block provided by the upstream will be > > aggregated, most likely, to *their* upstream / peers, so an extra > > routing table slot would not be needed, thereby saving resources. > > > > -- > > Garry Dolley > > ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 > > what upstream is that? once again, the limiting notion that > there connectedness to "someone else" is a prerequiste for using IP. > uniqueness i can understand (someday you might want to be connected, > but now...) If uniqueness, and not connectivity, is the concern, look into ULAs [1]. You can use them now, without ever contacting ARIN, or any IRR. 1. RFC 4193, "Unique Local IPv6 Unicast Addresses" http://tools.ietf.org/html/rfc4193 -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From bmanning at vacation.karoshi.com Sat May 30 17:28:19 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 30 May 2009 21:28:19 +0000 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530210421.GP27636@garry-thinkpad.arpnetworks.com> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <20090529185841.GA87992@gweep.net> <20090529201502.GA6398@ussenterprise.ufp.org> <20090530210421.GP27636@garry-thinkpad.arpnetworks.com> Message-ID: <20090530212819.GA22371@vacation.karoshi.com.> On Sat, May 30, 2009 at 02:04:22PM -0700, Garry Dolley wrote: > On Fri, May 29, 2009 at 04:15:02PM -0400, Leo Bicknell wrote: > > To that end, I can't support the proposal as written. As one > > commenter asked, "what if my kids want an IPv6 network to play with > > in their garage?" Well, we should find some way to accomodate that > > which doesn't require service providers worldwide to spend tens of > > thousands of dollars upgrading routers to hold the routes. > > Exactly. There's really no reason I should bear the cost of > carrying your route because your kids want to learn about IPv6. I > wholeheartedly want to support learning about IPv6, esp. for the next > generation of network operators, but doing so in a way that taxes > third party network hardware, for no reason, is not the way to do it. > > -- > Garry Dolley i'm sorry - this smacks of shear laziness. trying to get ARIN to manage your routing table is kind of like asking your mom to still do your laundry. no one is -forcing- you to accept any route whatsoever. your router, your choice. do the thought experiment... how many /32s are there in the IPv6 universe? Got a router for that? Didn't think so. Folk are going to have to face the fact that they can't depend on their benevolent RIR to manage the potential size of the routing table anymore... So ISPS and others who run routers, a bit of advice from my friend Bailey White; "Pull up your big girl panties and deal." --bill From kloch at kl.net Sat May 30 17:28:03 2009 From: kloch at kl.net (Kevin Loch) Date: Sat, 30 May 2009 17:28:03 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530210421.GP27636@garry-thinkpad.arpnetworks.com> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <20090529185841.GA87992@gweep.net> <20090529201502.GA6398@ussenterprise.ufp.org> <20090530210421.GP27636@garry-thinkpad.arpnetworks.com> Message-ID: <4A21A4E3.2090200@kl.net> Garry Dolley wrote: > If we give a /32 to anyone who asks for it, I *guarantee* you that > major ISPs will stop accepting /32's. There will be too many of > them. > >They'll take it down to /30s or /24s or something like that. Can we get real here? One of the problems of this one size fits all is the rather concentrated distribution of prefix sizes makes that strategy impractical in the extreme. There very well may be widespread filtering based on some other metric but exclusion of all /32's is as good as turning the (IPv6) Internet off. > I want ARIN to put up the barrier to entry on /32 prefixes, because > if they don't, the multi-million dollar ISPs will start making their > own rules. Do you have a proposed policy for how to establish that barrier? Today there is no barrier aside from the annual fee. Anyone who can configure a router to announce a /32 should be able to come up with a plan for how to assign 200 end site prefixes, so that is certainly not a barrier. Removing that farcical "requirement" from the policy document might encourage network operators who do not already have a /32 to get one. I am not worried about a flood of "kids" willing to pay $2250/yr for a /32. At some point in the future maybe, but not today. Also, if you self-moderate your posting to about once per day you will find that more people read what you have to say :) - Kevin From bmanning at vacation.karoshi.com Sat May 30 17:30:08 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 30 May 2009 21:30:08 +0000 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530212253.GA2827@garry-thinkpad.arpnetworks.com> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> <20090530190622.GC27636@garry-thinkpad.arpnetworks.com> <20090530195050.GA21698@vacation.karoshi.com.> <20090530212253.GA2827@garry-thinkpad.arpnetworks.com> Message-ID: <20090530213008.GB22371@vacation.karoshi.com.> On Sat, May 30, 2009 at 02:22:53PM -0700, Garry Dolley wrote: > On Sat, May 30, 2009 at 07:50:50PM +0000, bmanning at vacation.karoshi.com wrote: > > On Sat, May 30, 2009 at 12:06:23PM -0700, Garry Dolley wrote: > > > On Fri, May 29, 2009 at 10:49:02AM -0700, Stacy Hughes wrote: > > > > A multihoming requirement discriminates against networks that either cannot > > > > or do not want to multihome.I oppose this modification. > > > > Stacy > > > > > > If you aren't multi-homed, you should get an allocation from your > > > upstream, IMO. The block provided by the upstream will be > > > aggregated, most likely, to *their* upstream / peers, so an extra > > > routing table slot would not be needed, thereby saving resources. > > > > > > -- > > > Garry Dolley > > > ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 > > > > what upstream is that? once again, the limiting notion that > > there connectedness to "someone else" is a prerequiste for using IP. > > uniqueness i can understand (someday you might want to be connected, > > but now...) > > If uniqueness, and not connectivity, is the concern, look into ULAs > [1]. > > You can use them now, without ever contacting ARIN, or any IRR. > > > 1. RFC 4193, "Unique Local IPv6 Unicast Addresses" > http://tools.ietf.org/html/rfc4193 > > -- > Garry Dolley sorry - ULA does not assure uniqueness. only that statistical probability. --bill From sethm at rollernet.us Sat May 30 17:34:24 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 30 May 2009 14:34:24 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530200711.GI27636@garry-thinkpad.arpnetworks.com> References: <4A204EC1.5050905@ipinc.net> <20090530200711.GI27636@garry-thinkpad.arpnetworks.com> Message-ID: <4A21A660.2050804@rollernet.us> Garry Dolley wrote: > On Fri, May 29, 2009 at 04:14:56PM -0500, Chris Malayter wrote: >> This mentality will only serve to slow ipv6 adoption in application and >> content. The easier we make it for non-isps to get portable space, the more >> development will occur. Basic supply and demand theory in action here.... > > Can't non-ISPs simply apply for a /48 end-user allocation? [1] > > I don't get this argument I'm seeing in this thread that without the > proposed policy modification, IPv6 adoption will be hindered. > Yes. I did - and I currently have - a /48 under that policy. I'm announcing it right now over BGP and actively using it, actually. The only problem would be if people started placing filter boundaries at /32 for all portable IPv6 space and ignored /48's. ~Seth From sethm at rollernet.us Sat May 30 17:44:54 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 30 May 2009 14:44:54 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A1FFBE5.20807@arin.net> References: <4A1FFBE5.20807@arin.net> Message-ID: <4A21A8D6.6080909@rollernet.us> Member Services wrote: > > Policy Proposal Name: Open Access To IPv6 > > Proposal Originator: Stacy Hughes and Cathy Aronson > > Proposal Version: 1.0 > > Date: 29 May 2009 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > 1) Remove ?by advertising that connectivity through its single > aggregated address allocation? from article 3 of section 6.5.1.1 I have mixed feelings on this. A large org that gets a /32 will likely have multiple sites and may announce site aggregates carved from their /32. On the other hand, I strongly feel that you should only announce what your swip record says. There are already micro allocation policies for critical infrastructure if you need to deaggregate. I OPPOSE this change as written. I would support a change that adds "per site" or some variation thereof. > 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in > the ARIN region or have a plan for making at least 200 end-site > assignments to other organizations within 5 years? in its entirety. > > Rationale: It is acknowledged that these concepts have been put before > the community in the past. However, with the wisdom of actual > operational experience, the necessity of promoting IPv6 adoption > throughout our region, and emerging native v6 only network models, it > becomes obvious that these modifications to the NRPM are necessary. > Removing the 200 end site requirement enables smaller, but no less > important and viable, networks access to IPv6. Removing the ?known ISP? > requirement enfranchises new, native v6 businesses that can drive > innovation and expansion in the Internet industry, as well as other > industries. Removing the requirement for a single aggregate announcement > benefits the NRPM itself, as it has been decided by the community that > it should not contain routing advice. > I OPPOSE this change because "smaller, but no less important and viable, networks" can already apply for and obtain a /48 under existing policies. ~Seth From mksmith at adhost.com Sat May 30 17:48:21 2009 From: mksmith at adhost.com (Michael K. Smith) Date: Sat, 30 May 2009 14:48:21 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530204741.GO27636@garry-thinkpad.arpnetworks.com> Message-ID: On 5/30/09 1:47 PM, "Garry Dolley" wrote: > On Fri, May 29, 2009 at 08:57:03PM -0700, Michael K. Smith wrote: >> Hello All: >> >> I am in favor of this. I've been following the comments in the various >> threads and subthreads, and would add only this: >> >> - There is at least one major transit provider that will accept nothing more >> specific than a /32. > > And why do you think that is? > > If we give a /32 to anyone who asks for it, I *guarantee* you that > major ISPs will stop accepting /32's. There will be too many of > them. > > They'll take it down to /30s or /24s or something like that. Impossible to say what will happen later. Right now, /48's are not globally routable over the same paths as /32's. > >> - If we continue to inhibit providers' ability to get a /32, they may have >> reachability issues. >> - The v6 space is incredibly large. Really. What do we really gain from >> limiting some people to a /48? > > The number of addresses in IPv6 is incredibly large, but not the > number of /32 subnets. > > Guys, do the math. There are the same number of /32 subnets in IPv6 > as in IPv4. We are running out of IPv4. > > We'll run out of IPv6 if there is no barrier to entry on a /32. > > 2^32 = 4,294,967,296 Straw man. 4 billion /32's means 4 billion assignments to providers from the RIR's. This does not equate to the 4 billion addresses in the v4 pool because they're not assigned as hosts. Mike From mueller at syr.edu Sat May 30 17:48:41 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 30 May 2009 17:48:41 -0400 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: <4A2184EA.7020708@gmail.com> References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> <4A2184EA.7020708@gmail.com> Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > Not sure about all the details, but I like the fact > that we'd be able to do away with the ISP/end-user distinction, make it > easy to get a /48, and provide a simple growth path for the most common > cases... > > -Scott Ditto. But, let me express (uncharacteristically) some concern about overly liberal initial allocations. (e.g., why not a /56?) From the standpoint of developing countries, there is some legitimate concern about reproducing the land rush phase of IPv4 address allocations (oops, there goes 1/3 of the space....) From tvest at pch.net Sat May 30 17:49:41 2009 From: tvest at pch.net (Tom Vest) Date: Sat, 30 May 2009 17:49:41 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530212819.GA22371@vacation.karoshi.com.> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <20090529185841.GA87992@gweep.net> <20090529201502.GA6398@ussenterprise.ufp.org> <20090530210421.GP27636@garry-thinkpad.arpnetworks.com> <20090530212819.GA22371@vacation.karoshi.com.> Message-ID: <2C0DAA6D-E7ED-4B1A-A937-84D5BB57E88C@pch.net> On May 30, 2009, at 5:28 PM, bmanning at vacation.karoshi.com wrote: > On Sat, May 30, 2009 at 02:04:22PM -0700, Garry Dolley wrote: >> On Fri, May 29, 2009 at 04:15:02PM -0400, Leo Bicknell wrote: >>> To that end, I can't support the proposal as written. As one >>> commenter asked, "what if my kids want an IPv6 network to play with >>> in their garage?" Well, we should find some way to accomodate that >>> which doesn't require service providers worldwide to spend tens of >>> thousands of dollars upgrading routers to hold the routes. >> >> Exactly. There's really no reason I should bear the cost of >> carrying your route because your kids want to learn about IPv6. I >> wholeheartedly want to support learning about IPv6, esp. for the next >> generation of network operators, but doing so in a way that taxes >> third party network hardware, for no reason, is not the way to do it. >> >> -- >> Garry Dolley > > > i'm sorry - this smacks of shear laziness. > trying to get ARIN to manage your routing table > is kind of like asking your mom to still do your > laundry. > > no one is -forcing- you to accept any route whatsoever. > your router, your choice. > > do the thought experiment... how many /32s are there in > the IPv6 universe? Got a router for that? Didn't think so. > > Folk are going to have to face the fact that they can't > depend on their benevolent RIR to manage the potential size > of the routing table anymore... > > So ISPS and others who run routers, a bit of advice from my > friend Bailey White; "Pull up your big girl panties and deal." If only big girl panties were enough, but it won't be. If you want to play it that way, fine -- just polish up your saddle oxford shoes, adjust your bowtie, and make sure that your oral arguments are well rehearsed. TV From mueller at syr.edu Sat May 30 17:52:41 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 30 May 2009 17:52:41 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530194754.GG27636@garry-thinkpad.arpnetworks.com> References: <28E139F46D45AF49A31950F88C4974580161F064@E03MVZ2-UKDY.domain1.systemhost.net> <4A203143.5010908@matthew.at> <20090530194754.GG27636@garry-thinkpad.arpnetworks.com> Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A7CE6@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > Currently, it is generally accepted that /32's are for organizations > that will assign /48's to further downstream organizations. That presumes that you can understand and predict the structure of the industry and the applications of the technology for the next, oh, 50 years. If you can do away with that distinction without causing any problems, you should. From mueller at syr.edu Sat May 30 18:03:22 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 30 May 2009 18:03:22 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A21A4E3.2090200@kl.net> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <20090529185841.GA87992@gweep.net> <20090529201502.GA6398@ussenterprise.ufp.org> <20090530210421.GP27636@garry-thinkpad.arpnetworks.com> <4A21A4E3.2090200@kl.net> Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A7CE7@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > > Also, if you self-moderate your posting to about once per day you will > find that more people read what you have to say :) > I don't agree with this advice. Gary Dolley's comments were generally useful and well-informed, and I suspect he went through the traffic message by message. Yes, reduce 20 messages to 5 - 10 at most, and, uh, aggregate replies a bit, but one a day is a bit too restrictive. From gdolley at arpnetworks.com Sat May 30 17:42:44 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 14:42:44 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530213008.GB22371@vacation.karoshi.com.> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> <20090530190622.GC27636@garry-thinkpad.arpnetworks.com> <20090530195050.GA21698@vacation.karoshi.com.> <20090530212253.GA2827@garry-thinkpad.arpnetworks.com> <20090530213008.GB22371@vacation.karoshi.com.> Message-ID: <9E2B2273-4394-424B-99CE-1C01AE984F5F@arpnetworks.com> On May 30, 2009, at 2:30 PM, bmanning at vacation.karoshi.com wrote: > On Sat, May 30, 2009 at 02:22:53PM -0700, Garry Dolley wrote: >> On Sat, May 30, 2009 at 07:50:50PM +0000, bmanning at vacation.karoshi.com >> wrote: >>> On Sat, May 30, 2009 at 12:06:23PM -0700, Garry Dolley wrote: >>>> On Fri, May 29, 2009 at 10:49:02AM -0700, Stacy Hughes wrote: >>>>> A multihoming requirement discriminates against networks that >>>>> either cannot >>>>> or do not want to multihome.I oppose this modification. >>>>> Stacy >>>> >>>> If you aren't multi-homed, you should get an allocation from your >>>> upstream, IMO. The block provided by the upstream will be >>>> aggregated, most likely, to *their* upstream / peers, so an extra >>>> routing table slot would not be needed, thereby saving resources. >>>> >>>> -- >>>> Garry Dolley >>>> ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 >>> >>> what upstream is that? once again, the limiting notion that >>> there connectedness to "someone else" is a prerequiste for >>> using IP. >>> uniqueness i can understand (someday you might want to be >>> connected, >>> but now...) >> >> If uniqueness, and not connectivity, is the concern, look into ULAs >> [1]. >> >> You can use them now, without ever contacting ARIN, or any IRR. >> >> >> 1. RFC 4193, "Unique Local IPv6 Unicast Addresses" >> http://tools.ietf.org/html/rfc4193 >> >> -- >> Garry Dolley > > sorry - ULA does not assure uniqueness. only that > statistical probability. Correct, but given the use cases mentioned, statistically probable uniqueness is sufficient. -- Garry From gdolley at arpnetworks.com Sat May 30 18:55:01 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 15:55:01 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: References: <20090530204741.GO27636@garry-thinkpad.arpnetworks.com> Message-ID: <20090530225500.GA6380@garry-thinkpad.arpnetworks.com> On Sat, May 30, 2009 at 02:48:21PM -0700, Michael K. Smith wrote: > > > > On 5/30/09 1:47 PM, "Garry Dolley" wrote: > > > On Fri, May 29, 2009 at 08:57:03PM -0700, Michael K. Smith wrote: > >> Hello All: > >> > >> I am in favor of this. I've been following the comments in the various > >> threads and subthreads, and would add only this: > >> > >> - There is at least one major transit provider that will accept nothing more > >> specific than a /32. > > > > And why do you think that is? > > > > If we give a /32 to anyone who asks for it, I *guarantee* you that > > major ISPs will stop accepting /32's. There will be too many of > > them. > > > > They'll take it down to /30s or /24s or something like that. > > Impossible to say what will happen later. Right now, /48's are not globally > routable over the same paths as /32's. > > > >> - If we continue to inhibit providers' ability to get a /32, they may have > >> reachability issues. > >> - The v6 space is incredibly large. Really. What do we really gain from > >> limiting some people to a /48? > > > > The number of addresses in IPv6 is incredibly large, but not the > > number of /32 subnets. > > > > Guys, do the math. There are the same number of /32 subnets in IPv6 > > as in IPv4. We are running out of IPv4. > > > > We'll run out of IPv6 if there is no barrier to entry on a /32. > > > > 2^32 = 4,294,967,296 > > Straw man. 4 billion /32's means 4 billion assignments to providers from > the RIR's. This does not equate to the 4 billion addresses in the v4 pool > because they're not assigned as hosts. I never said it equated to 4 billion addresses in IPv6. 4 billion assigned subnets, if that is all that is available (in case of /32, yes), is equivalent to exhausting all the addresses within those subnets. There aren't any subnets left for anyone else. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From bmanning at vacation.karoshi.com Sat May 30 18:59:27 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 30 May 2009 22:59:27 +0000 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <9E2B2273-4394-424B-99CE-1C01AE984F5F@arpnetworks.com> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> <20090530190622.GC27636@garry-thinkpad.arpnetworks.com> <20090530195050.GA21698@vacation.karoshi.com.> <20090530212253.GA2827@garry-thinkpad.arpnetworks.com> <20090530213008.GB22371@vacation.karoshi.com.> <9E2B2273-4394-424B-99CE-1C01AE984F5F@arpnetworks.com> Message-ID: <20090530225927.GC22982@vacation.karoshi.com.> On Sat, May 30, 2009 at 02:42:44PM -0700, Garry Dolley wrote: > > On May 30, 2009, at 2:30 PM, bmanning at vacation.karoshi.com wrote: > > >On Sat, May 30, 2009 at 02:22:53PM -0700, Garry Dolley wrote: > >>On Sat, May 30, 2009 at 07:50:50PM +0000, bmanning at vacation.karoshi.com > >> wrote: > >>>On Sat, May 30, 2009 at 12:06:23PM -0700, Garry Dolley wrote: > >>>>On Fri, May 29, 2009 at 10:49:02AM -0700, Stacy Hughes wrote: > >>>>>A multihoming requirement discriminates against networks that > >>>>>either cannot > >>>>>or do not want to multihome.I oppose this modification. > >>>>>Stacy > >>>> > >>>>If you aren't multi-homed, you should get an allocation from your > >>>>upstream, IMO. The block provided by the upstream will be > >>>>aggregated, most likely, to *their* upstream / peers, so an extra > >>>>routing table slot would not be needed, thereby saving resources. > >>>> > >>>>-- > >>>>Garry Dolley > >>>>ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 > >>> > >>> what upstream is that? once again, the limiting notion that > >>> there connectedness to "someone else" is a prerequiste for > >>>using IP. > >>> uniqueness i can understand (someday you might want to be > >>>connected, > >>> but now...) > >> > >>If uniqueness, and not connectivity, is the concern, look into ULAs > >>[1]. > >> > >>You can use them now, without ever contacting ARIN, or any IRR. > >> > >> > >>1. RFC 4193, "Unique Local IPv6 Unicast Addresses" > >> http://tools.ietf.org/html/rfc4193 > >> > >>-- > >>Garry Dolley > > > > sorry - ULA does not assure uniqueness. only that > > statistical probability. > > Correct, but given the use cases mentioned, statistically probable > uniqueness is sufficient. > > -- > Garry Not for me. --bill From gdolley at arpnetworks.com Sat May 30 19:50:05 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 16:50:05 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A21A4E3.2090200@kl.net> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <20090529185841.GA87992@gweep.net> <20090529201502.GA6398@ussenterprise.ufp.org> <20090530210421.GP27636@garry-thinkpad.arpnetworks.com> <4A21A4E3.2090200@kl.net> Message-ID: <20090530235005.GB6380@garry-thinkpad.arpnetworks.com> On Sat, May 30, 2009 at 05:28:03PM -0400, Kevin Loch wrote: > Garry Dolley wrote: > > > If we give a /32 to anyone who asks for it, I *guarantee* you that > > major ISPs will stop accepting /32's. There will be too many of > > them. > > > >They'll take it down to /30s or /24s or something like that. > > Can we get real here? One of the problems of this one size > fits all is the rather concentrated distribution of prefix > sizes makes that strategy impractical in the extreme. There > very well may be widespread filtering based on some other > metric but exclusion of all /32's is as good as turning the > (IPv6) Internet off. Exclusion of /32 is as good as turning the IPv6 Internet off *at present time*, but that may not be the case in the future. If /32's become in large enough number that current hardware accelerated routers cannot hold them all, then something will give. Just imagine all the /32 holders now growing and starting to acquire larger blocks, and the /48 holders get /32's because policy changes make them easy to get; what will happen is the /32 will be regarded as what the /48 once was. It was mentioned previously that one major ISP stopped accepting /48's (to whoever posted that, can you tell us who it was?) There's no reason to believe the /32 is immune to this or "special" in some way. BGP makes no discrimination, it is up to the network operator. The network community as a whole, through NANOG, many mailing lists (such as this one), RFCs, and general operating knowledge, have come to the general consensus that prefixes of a certain size are "acceptable" within a BGP routing table. Right now that consensus falls around /48, /32 and larger blocks. But who's to say that won't change as the IPv6 Internet grows, and we are faced with external constraints beyond our control? >> I want ARIN to put up the barrier to entry on /32 prefixes, because >> if they don't, the multi-million dollar ISPs will start making their >> own rules. > > Do you have a proposed policy for how to establish that barrier? Today > there is no barrier aside from the annual fee. Anyone who can configure > a router to announce a /32 should be able to come up with a plan for > how to assign 200 end site prefixes, so that is certainly not a barrier. The current policy. The only thing I would change is the "be an existing, known ISP in the ARIN region" [1] because this doesn't work for brand new LIRs/ISPs. This could be deleted; yet I do see that there is an "*or* have a plan for making at least 200 end-site assignments..." [1], in which case perhaps it doesn't matter. If you plan on making those end-site assignments, go ahead and apply for a /32. A multi-homing requirement may work too (isn't there already one? or is it only for IPv4?). I don't see why a block from your upstream (unless none of your upstreams support IPv6, in which case you should find one that has a clue) is somehow undesirable in this discussion. I know that renumbering when you switch providers is a pain, but if it is that much of an issue, you can get an end-user /48 all to yourself. And if you have no upstream, use a ULA. [2] > Removing that farcical "requirement" from the policy document might > encourage network operators who do not already have a /32 to get one. But you just said the 200 end site prefixes plan is not a barrier for someone who can already configure a router to announce a /32, so why would removing this requirement encourage more network ops to get a /32? > I am not worried about a flood of "kids" willing to pay $2250/yr for a > /32. At some point in the future maybe, but not today. > > Also, if you self-moderate your posting to about once per day you will > find that more people read what you have to say :) This thread grew throughout last week (and is still growing), while I was on vacation, and I said to myself I'll read it post-by-post and reply on the weekend. So there you have it. 1. https://www.arin.net/policy/nrpm.html#six511 2. RFC 4193, "Unique Local IPv6 Unicast Addresses" http://tools.ietf.org/html/rfc4193 -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From owen at delong.com Sat May 30 19:49:26 2009 From: owen at delong.com (Owen DeLong) Date: Sat, 30 May 2009 16:49:26 -0700 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> Message-ID: <633952A8-D276-4FC8-B778-2D8B5C71EECD@delong.com> On May 30, 2009, at 12:05 PM, William Herrin wrote: > So here's a crazy plan: > > A. The first IPv6 allocation from ARIN is always a /48. To justify it, > you need to be multihomed. There are no other qualifications. The /48 > will be allocated from a pool from which only /48's are allocated. > > B. The second IPv6 allocation from ARIN is always a /32. To justify it > you need to demonstrate that you've efficiently used the /48 for some > reasonable definition of efficient, that you've implemented SWIP or > RWHOIS for your downstream assignments and that you will run out of > space in the /48 within one year. The /32 will be allocated from a > pool reserved for allocating /32's. > Uh, since the first assignment from an ISP to a customer could well be a /48, how exactly are they supposed to accomplish that and number their own infrastructure for even a single POP out of that first /48? > Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Sat May 30 19:46:24 2009 From: owen at delong.com (Owen DeLong) Date: Sat, 30 May 2009 16:46:24 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B2209E4@SUEX07-MBX-04.ad.syr.edu> References: <4A1FFBE5.20807@arin.net> <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> <2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com> <75822E125BCB994F8446858C4B19F0D77B2209E4@SUEX07-MBX-04.ad.syr.edu> Message-ID: These would be for entities providing connectivity (and hence /48 assignments) to other organizations. A /32 only supports 65,536 such customers, so, it's really not an unreasonable chunk for a minimum size to an ISP. Owen On May 30, 2009, at 11:36 AM, Milton L Mueller wrote: > I support the principle of this proposal, but am somewhat taken > aback by the idea that /32s would be the basic unit for smaller, > innovative v6 entities. > Aren't /48s, which still constitute a huge number of addresses, > enough? Or am I missing something here? > > Milton Mueller > Professor, Syracuse University School of Information Studies > XS4All Professor, Delft University of Technology > ------------------------------ > Internet Governance Project: > http://internetgovernance.org > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of Stacy Hughes > Sent: Friday, May 29, 2009 9:25 AM > To: Member Services > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6 > > Hello Everyone, > Before we really get started on this policy proposal, I must give > credit where credit is due. > Jordi Palet Martinez brought this topic to the table 3 years ago, > and it got shot down. I myself, in my small IPv4-centric mind, > thought it impossible that an IPv6 only organization could exist. > Operations and innovation have shown me the error of our thinking. > To quote myself from a different list: > IPv6 is a new paradigm we are supposed to be doing our best to > encourage. As it stands, those community guys can't get it, the > Caribbean guys can't get it, and basically anyone trying to do > anything vanguard can't get it either. (I hear the ULA objections > here, even when they're nascent). > > We can be afraid of what IPv6 might do to the routing table, or we > can embrace what IPv6 can and will do for the Internet. > I choose the latter and support this proposal. > Stacy > > > On Fri, May 29, 2009 at 8:14 AM, Member Services > wrote: > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with Policy > Development > Process. > > This proposal is in the first stage of the Policy Development Process. > ARIN staff will perform the Clarity and Understanding step. Staff does > not evaluate the proposal at this time, their goal is to make sure > that > they understand the proposal and believe the community will as well. > Staff will report their results to the ARIN Advisory Council (AC) > within > 10 days. > > The AC will review the proposal at their next regularly scheduled > meeting (if the period before the next regularly scheduled meeting is > less than 10 days, then the period may be extended to the subsequent > regularly scheduled meeting). The AC will decide how to utilize the > proposal and announce the decision to the PPML. > > In the meantime, the AC invites everyone to comment on the proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their > deliberations. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at:https://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Open Access To IPv6 > > Proposal Originator: Stacy Hughes and Cathy Aronson > > Proposal Version: 1.0 > > Date: 29 May 2009 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > 1) Remove ?by advertising that connectivity through its single > aggregated address allocation? from article 3 of section 6.5.1.1 > > 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in > the ARIN region or have a plan for making at least 200 end-site > assignments to other organizations within 5 years? in its entirety. > > Rationale: It is acknowledged that these concepts have been put before > the community in the past. However, with the wisdom of actual > operational experience, the necessity of promoting IPv6 adoption > throughout our region, and emerging native v6 only network models, it > becomes obvious that these modifications to the NRPM are necessary. > Removing the 200 end site requirement enables smaller, but no less > important and viable, networks access to IPv6. Removing the ?known > ISP? > requirement enfranchises new, native v6 businesses that can drive > innovation and expansion in the Internet industry, as well as other > industries. Removing the requirement for a single aggregate > announcement > benefits the NRPM itself, as it has been decided by the community that > it should not contain routing advice. > > Timetable for implementation: immediately upon BoT ratification > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From gdolley at arpnetworks.com Sat May 30 20:00:38 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 17:00:38 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530212819.GA22371@vacation.karoshi.com.> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <20090529185841.GA87992@gweep.net> <20090529201502.GA6398@ussenterprise.ufp.org> <20090530210421.GP27636@garry-thinkpad.arpnetworks.com> <20090530212819.GA22371@vacation.karoshi.com.> Message-ID: <20090531000037.GC6380@garry-thinkpad.arpnetworks.com> On Sat, May 30, 2009 at 09:28:19PM +0000, bmanning at vacation.karoshi.com wrote: > On Sat, May 30, 2009 at 02:04:22PM -0700, Garry Dolley wrote: > > On Fri, May 29, 2009 at 04:15:02PM -0400, Leo Bicknell wrote: > > > To that end, I can't support the proposal as written. As one > > > commenter asked, "what if my kids want an IPv6 network to play with > > > in their garage?" Well, we should find some way to accomodate that > > > which doesn't require service providers worldwide to spend tens of > > > thousands of dollars upgrading routers to hold the routes. > > > > Exactly. There's really no reason I should bear the cost of > > carrying your route because your kids want to learn about IPv6. I > > wholeheartedly want to support learning about IPv6, esp. for the next > > generation of network operators, but doing so in a way that taxes > > third party network hardware, for no reason, is not the way to do it. > > > > -- > > Garry Dolley > > > i'm sorry - this smacks of shear laziness. > trying to get ARIN to manage your routing table > is kind of like asking your mom to still do your > laundry. Researching every /32 to see if it is worthy of being in your routing table is not practical. It is not a laziness issue. > no one is -forcing- you to accept any route whatsoever. > your router, your choice. Yes, but practically speaking, I can accept all /32's or none of them, with a little wiggle room with filters. I can set up filters, sure, but anyone running a multi-homed network with real customers, peers, and traffic knows that maintaining filters that actually work well is almost a lesson in futility. > do the thought experiment... how many /32s are there in > the IPv6 universe? Got a router for that? Didn't think so. > > Folk are going to have to face the fact that they can't > depend on their benevolent RIR to manage the potential size > of the routing table anymore... But what we can do is try to promote policy that doesn't give out prefixes like they are going out of style. Every /32 prefix assigned and announced takes up one more RIB slot for me and every other ISP on the planet. So, I'm going to do what I can to save that resource. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From owen at delong.com Sat May 30 19:58:16 2009 From: owen at delong.com (Owen DeLong) Date: Sat, 30 May 2009 16:58:16 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A21A8D6.6080909@rollernet.us> References: <4A1FFBE5.20807@arin.net> <4A21A8D6.6080909@rollernet.us> Message-ID: > >> 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in >> the ARIN region or have a plan for making at least 200 end-site >> assignments to other organizations within 5 years? in its entirety. >> Rationale: It is acknowledged that these concepts have been put >> before >> the community in the past. However, with the wisdom of actual >> operational experience, the necessity of promoting IPv6 adoption >> throughout our region, and emerging native v6 only network models, it >> becomes obvious that these modifications to the NRPM are necessary. >> Removing the 200 end site requirement enables smaller, but no less >> important and viable, networks access to IPv6. Removing the ?known >> ISP? >> requirement enfranchises new, native v6 businesses that can drive >> innovation and expansion in the Internet industry, as well as other >> industries. Removing the requirement for a single aggregate >> announcement >> benefits the NRPM itself, as it has been decided by the community >> that >> it should not contain routing advice. > > I OPPOSE this change because "smaller, but no less important and > viable, networks" can already apply for and obtain a /48 under > existing policies. > Not as ISPs assigning /48s to end users, they cannot. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From gdolley at arpnetworks.com Sat May 30 20:04:08 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 17:04:08 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530225927.GC22982@vacation.karoshi.com.> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> <20090530190622.GC27636@garry-thinkpad.arpnetworks.com> <20090530195050.GA21698@vacation.karoshi.com.> <20090530212253.GA2827@garry-thinkpad.arpnetworks.com> <20090530213008.GB22371@vacation.karoshi.com.> <9E2B2273-4394-424B-99CE-1C01AE984F5F@arpnetworks.com> <20090530225927.GC22982@vacation.karoshi.com.> Message-ID: <20090531000408.GD6380@garry-thinkpad.arpnetworks.com> On Sat, May 30, 2009 at 10:59:27PM +0000, bmanning at vacation.karoshi.com wrote: > On Sat, May 30, 2009 at 02:42:44PM -0700, Garry Dolley wrote: > > > > On May 30, 2009, at 2:30 PM, bmanning at vacation.karoshi.com wrote: > > > > >On Sat, May 30, 2009 at 02:22:53PM -0700, Garry Dolley wrote: > > >>On Sat, May 30, 2009 at 07:50:50PM +0000, bmanning at vacation.karoshi.com > > >> wrote: > > >>>On Sat, May 30, 2009 at 12:06:23PM -0700, Garry Dolley wrote: > > >>>>On Fri, May 29, 2009 at 10:49:02AM -0700, Stacy Hughes wrote: > > >>>>>A multihoming requirement discriminates against networks that > > >>>>>either cannot > > >>>>>or do not want to multihome.I oppose this modification. > > >>>>>Stacy > > >>>> > > >>>>If you aren't multi-homed, you should get an allocation from your > > >>>>upstream, IMO. The block provided by the upstream will be > > >>>>aggregated, most likely, to *their* upstream / peers, so an extra > > >>>>routing table slot would not be needed, thereby saving resources. > > >>>> > > >>>>-- > > >>>>Garry Dolley > > >>>>ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 > > >>> > > >>> what upstream is that? once again, the limiting notion that > > >>> there connectedness to "someone else" is a prerequiste for > > >>>using IP. > > >>> uniqueness i can understand (someday you might want to be > > >>>connected, > > >>> but now...) > > >> > > >>If uniqueness, and not connectivity, is the concern, look into ULAs > > >>[1]. > > >> > > >>You can use them now, without ever contacting ARIN, or any IRR. > > >> > > >> > > >>1. RFC 4193, "Unique Local IPv6 Unicast Addresses" > > >> http://tools.ietf.org/html/rfc4193 > > >> > > >>-- > > >>Garry Dolley > > > > > > sorry - ULA does not assure uniqueness. only that > > > statistical probability. > > > > Correct, but given the use cases mentioned, statistically probable > > uniqueness is sufficient. > > > > -- > > Garry > > Not for me. Care to elaborate? I'm willing to accept any valid reason as to why a ULA will not work for someone developing in a lab environment, or does not need routeability, or an upstream. But from what I've read so far, no one has provided one. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 20:17:00 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 17:17:00 -0700 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> Message-ID: <20090531001700.GE6380@garry-thinkpad.arpnetworks.com> On Sat, May 30, 2009 at 03:05:58PM -0400, William Herrin wrote: > So here's a crazy plan: > > A. The first IPv6 allocation from ARIN is always a /48. To justify it, > you need to be multihomed. There are no other qualifications. The /48 > will be allocated from a pool from which only /48's are allocated. > > B. The second IPv6 allocation from ARIN is always a /32. To justify it > you need to demonstrate that you've efficiently used the /48 for some > reasonable definition of efficient, that you've implemented SWIP or > RWHOIS for your downstream assignments and that you will run out of > space in the /48 within one year. The /32 will be allocated from a > pool reserved for allocating /32's. > > C. The third IPv6 allocation from ARIN is always a /24. To justify it > you need to demonstrate that you've efficiently used the /32, that you > will run out of space in the /32 within five years, and you have to > first return the original /48 you were assigned. The /24 will be > allocated from a pool reserved for allocating /24's. > > D. There is no fourth IPv6 allocation at this time. It is not > presently possible to consume an entire /24 without atrocious waste. > > What are the consequences of this plan? > > 1. Efficient allocation of IP addresses. Orgs get what they need when > they need it and not before without a great deal of guesswork about > actual need. > > 2. Efficient utilization of BGP routing slots. No single multihomed > org will ever announce more than 2 necessary routes. > > 3. Traffic engineering routes are trivially filterable since any route > longer than the published allocation size can be presumed to be > traffic engineering, not a downstream multihomed customer, thus you > can filter distant small routes with confidence and ease. > > 4. No need to define the difference between ISP and not ISP. Everybody > plays by the same rules. > > 5. No complicated analysis for the first allocation. You're either > multihomed or you're not. If you're multihomed, you qualify. > > 6. For those who can live within the /48 there are distinct > advantages: no swip or rwhois reporting and the generic end-user > annual fee instead of the ISP annual fee. Once you're up to a /32, you > pay the ISP annual fee. As a result, ARIN doesn't have to scrutinize > the /32 requests too closely either. > > Thoughts? Criticisms? While I like the effort to simplify the current policy, I don't think this would actually work in practice. To see why, I'd like to point out the following: 1. RFC 3177, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites" http://tools.ietf.org/html/rfc3177 2. RFC 5375, "IPv6 Unicast Address Assignment Considerations" http://tools.ietf.org/html/rfc5375 Everyone who is participating in these policy debates should read these. Basically, for organizations who are assigning IPv6 space to other organizations, and aggregating that space to their upstreams, really do need a /32 to begin with. This is because all their downstream assignments will be /48's (RFC 3177). If they were only allowed to get a /48 to begin with, they couldn't assign any further /48's. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 20:21:26 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 17:21:26 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A21A660.2050804@rollernet.us> References: <4A204EC1.5050905@ipinc.net> <20090530200711.GI27636@garry-thinkpad.arpnetworks.com> <4A21A660.2050804@rollernet.us> Message-ID: <20090531002126.GF6380@garry-thinkpad.arpnetworks.com> On Sat, May 30, 2009 at 02:34:24PM -0700, Seth Mattinen wrote: > Garry Dolley wrote: >> On Fri, May 29, 2009 at 04:14:56PM -0500, Chris Malayter wrote: >>> This mentality will only serve to slow ipv6 adoption in application and >>> content. The easier we make it for non-isps to get portable space, the >>> more >>> development will occur. Basic supply and demand theory in action >>> here.... >> Can't non-ISPs simply apply for a /48 end-user allocation? [1] >> I don't get this argument I'm seeing in this thread that without the >> proposed policy modification, IPv6 adoption will be hindered. > > Yes. I did - and I currently have - a /48 under that policy. I'm announcing > it right now over BGP and actively using it, actually. > > The only problem would be if people started placing filter boundaries at > /32 for all portable IPv6 space and ignored /48's. Indeed, that would present a problem to you if /48's were ignored. If every end-site gets a globally routable address (of any size, who cares if it is a /56, or /48 or /40 or /32), where do we aggregate? Do we just stop aggregating? Do we find ways to hold a very large number of routes in hardware? I really don't know.. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 20:25:19 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 17:25:19 -0700 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A207216.60202@matthew.at> References: <4A1FFE0E.7060805@arin.net> <4A204DDF.1020106@ipinc.net> <20090529211124.GO30913@angus.ind.WPI.EDU> <24c86a5f0905291501l43b66da5x9bba14eabdbd9535@mail.gmail.com> <4A206305.40607@ipinc.net> <4A207216.60202@matthew.at> Message-ID: <20090531002519.GG6380@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 04:39:02PM -0700, Matthew Kaufman wrote: > Ted Mittelstaedt wrote: >> >> By contrast, the problem of table bloat in routers is very real. > Absolutely, but should not be ARIN's problem. ARIN should make it possible > for organizations (be they ISPs or not) to obtain unique allocations from > ARIN's portion of the IPv6 address space. It should be easy to get > allocations which are aggregated in such a way that they are less expensive > to route, but that shouldn't drive policy. They already do: /48 end-user assignment -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 20:34:02 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 17:34:02 -0700 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A20AFF1.5090800@matthew.at> References: <4A1FFE0E.7060805@arin.net> <4A204DDF.1020106@ipinc.net> <20090529211124.GO30913@angus.ind.WPI.EDU> <24c86a5f0905291501l43b66da5x9bba14eabdbd9535@mail.gmail.com> <4A206305.40607@ipinc.net> <4A207216.60202@matthew.at> <4A207E28.7010200@ipinc.net> <4A20AFF1.5090800@matthew.at> Message-ID: <20090531003402.GH6380@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 09:02:57PM -0700, Matthew Kaufman wrote: > Ted Mittelstaedt wrote: >> Matthew Kaufman wrote: >>> Ted Mittelstaedt wrote: >>>> >>>> By contrast, the problem of table bloat in routers is very real. >>> Absolutely, but should not be ARIN's problem. ARIN should make it >>> possible for organizations (be they ISPs or not) to obtain unique >>> allocations from ARIN's portion of the IPv6 address space. It should be >>> easy to get allocations which are aggregated in such a way that they are >>> less expensive to route, but that shouldn't drive policy. >> >> OK then taking that argument to it's logical conclusion then let's just >> assign every last man and woman on the face of the earth an IPv6 number >> drawn out of a random lottery pool and let them plug in and have at it! > Well, you could do exactly that. And they could have their own chunk of > IPv6 space *and* a separate, routeable PA address as well. And we *still* > wouldn't run out. Sure, you could make the assignment; but it would just be a dumb number. Current infrastructure wouldn't route it. >>>> You >>>> are essentially asking thousands of orgs out there to put money into >>>> tens of thousands of routers out there to replace them with new gear >>>> that will hold and manage a fantastically gigantic IPv6 table, >>> No. We are asking ARIN to fairly allocate reasonably-sized parts of IPv6 >>> to entities that ask, in return for no more than reasonable compensation. >> >> A single snowflake by itself harms no one. >> >> A trillion snowflakes creates an avalanche that kills people. > Lots of people having non-routeable or non-routed addresses isn't going to > kill anyone. The people who don't care about the routeability of their addresses can just use ULAs [1]. I really don't see what the practical issue is. > Heck, even a big explosion in routing table size won't kill anyone. Maybe > someone will take the time to solve the problem more elegantly than it has > been so far, and it won't even matter. Then send me the cash to get SUP720-3BXL so I can hold up to a million IPv6 routes in hardware. Sure it won't kill anyone, but I'm not going to pay for your desire for a /32; and why should anyone else? 1. RFC 4139, "Unique Local IPv6 Unicast Addresses" http://tools.ietf.org/html/rfc4193 -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 20:41:50 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 17:41:50 -0700 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A2070D7.8080402@rollernet.us> References: <4A1FFE0E.7060805@arin.net> <4A204DDF.1020106@ipinc.net> <20090529211124.GO30913@angus.ind.WPI.EDU> <24c86a5f0905291501l43b66da5x9bba14eabdbd9535@mail.gmail.com> <4A206305.40607@ipinc.net> <4A2070D7.8080402@rollernet.us> Message-ID: <20090531004150.GI6380@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 04:33:43PM -0700, Seth Mattinen wrote: > Ted Mittelstaedt wrote: > > Stacy Hughes wrote: > >> Hi Everyone, Chuck precisely makes one of my points here. When I > >> voted against this concept last time around, I felt just like Ted. > >> Like, you're not a real ISP or player if you don't have 200 customers. > > > > I never said that. As I mentioned in the response to the NoX question, > > there is already a micro allocation policy that applies to them. > > > >> But there are real ISPs that are small that deserve the minimum > >> allocation of IPv6 just as much as the 200+ers. If we want everyone > >> participating in IPv6, we must make sure they can get it - especially > >> ISPs, large and small. > > > > If they are real ISPs that are small then it is not that much of a > > burden for them to get their IPv6 from an upstream and reassigning > > it to their customers. If they are > > multihomed then nothing is stopping them from advertising that block. > > Granted, there will be a larger advertisement for the block their > > smaller block is part of out there but that shouldn't matter. It > > certainly doesn't matter for IPv4 since before we got our IPv4 space > > in 2004 we used non-portable IPv4 space in this fashion with no problems. > > In IPv4 land it's a huge problem (to me) because you have to give PA > space back and renumber into PI space in order to ever qualify for more > PI space. As much as everyone things renumbering is a big deal, it is. I > *still* have customers asking why PA space from an upstream I dropped > over three years ago doesn't work. Even further back, people are still > hitting my test bed I set up while I was still in college; talk about > out of date. I have no idea where they find those old addresses. > Renumbering is a headache that never ends. Yeah, renumbering sucks. I've gone through that dance time and time again. But ya know what, it is a cost that the org renumbering has to bear. It is certainly more fair than everyone else having to bear the cost of more expensive hardware because people want this panacea of getting an initial PI space and "never having to renumber" If you get an end-user /48, you may never need to renumber anyway. Renumbering is a growing pain, but once completed, you're in a better spot. > > By contrast, the problem of table bloat in routers is very real. You > > are essentially asking thousands of orgs out there to put money into > > tens of thousands of routers out there to replace them with new gear > > that will hold and manage a fantastically gigantic IPv6 table, just to > > make it a slight bit easier for small orgs to advertise a /32, who > > have absolutely no use for a /32 and would be happy with a /48, and > > who are getting the /32 because they are still scared to death about the > > old renumbering bugaboo - which doesn't even exist with IPv6 anyway. > > I tried to make the same point. Routers with a lot of TCAM space are > horribly expensive. Many people have already bought equipment expected > to last for the next X years (where X is greater than 1) and it's > already inadequate. Bleh. Besides, there's no reason a small org can't > just get a /48 and apply for more space later. No renumbering required. Yep -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From bmanning at vacation.karoshi.com Sat May 30 20:45:57 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 31 May 2009 00:45:57 +0000 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090531000037.GC6380@garry-thinkpad.arpnetworks.com> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <20090529185841.GA87992@gweep.net> <20090529201502.GA6398@ussenterprise.ufp.org> <20090530210421.GP27636@garry-thinkpad.arpnetworks.com> <20090530212819.GA22371@vacation.karoshi.com.> <20090531000037.GC6380@garry-thinkpad.arpnetworks.com> Message-ID: <20090531004557.GB23664@vacation.karoshi.com.> On Sat, May 30, 2009 at 05:00:38PM -0700, Garry Dolley wrote: > On Sat, May 30, 2009 at 09:28:19PM +0000, bmanning at vacation.karoshi.com wrote: > > On Sat, May 30, 2009 at 02:04:22PM -0700, Garry Dolley wrote: > > > On Fri, May 29, 2009 at 04:15:02PM -0400, Leo Bicknell wrote: > > > > To that end, I can't support the proposal as written. As one > > > > commenter asked, "what if my kids want an IPv6 network to play with > > > > in their garage?" Well, we should find some way to accomodate that > > > > which doesn't require service providers worldwide to spend tens of > > > > thousands of dollars upgrading routers to hold the routes. > > > > > > Exactly. There's really no reason I should bear the cost of > > > carrying your route because your kids want to learn about IPv6. I > > > wholeheartedly want to support learning about IPv6, esp. for the next > > > generation of network operators, but doing so in a way that taxes > > > third party network hardware, for no reason, is not the way to do it. > > > > > > -- > > > Garry Dolley > > > > > > i'm sorry - this smacks of shear laziness. > > trying to get ARIN to manage your routing table > > is kind of like asking your mom to still do your > > laundry. > > Researching every /32 to see if it is worthy of being in your > routing table is not practical. It is not a laziness issue. your telling me what is practical for me to do? very kind of you indeed. however i beg to disagree - i ensure that i have the specifics i know i want and then proxy aggregate most everything else. there are even a few prefixes for which i -never- want to see traffic from and I block them. i'd posit that most folks do something very similar. > > no one is -forcing- you to accept any route whatsoever. > > your router, your choice. > > Yes, but practically speaking, I can accept all /32's or none of > them, with a little wiggle room with filters. i can't tell you what is practical for you. > I can set up filters, sure, but anyone running a multi-homed network > with real customers, peers, and traffic knows that maintaining > filters that actually work well is almost a lesson in futility. routing has not been "fire and forget" for many years. if you don't pay attention, your going to get burned. > > do the thought experiment... how many /32s are there in > > the IPv6 universe? Got a router for that? Didn't think so. > > > > Folk are going to have to face the fact that they can't > > depend on their benevolent RIR to manage the potential size > > of the routing table anymore... > > But what we can do is try to promote policy that doesn't give out > prefixes like they are going out of style. Every /32 prefix > assigned and announced takes up one more RIB slot for me and every > other ISP on the planet. So, I'm going to do what I can to save > that resource. borrowing your metaphor, I'd like to see one family of prefixes come into style... and if that means treating them like loss-leaders for a bit, then I guess that is what needs to happen. Then, we can start worrying about them going out of style. I'll reiterate again. Just becauase I get a /32 and announce it to my peers, is zero reason for you to hold it (at all, or for any length of time, or in perpetutity). Folks really need to wean themsleves of the dependency on an RIR to craft their routing policies. --bill > > -- > Garry Dolley > ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 > Data center, VPS, and IP Transit solutions > Member Los Angeles County REACT, Unit 336 | WQGK336 > Blog http://scie.nti.st From vixie at isc.org Sat May 30 20:46:25 2009 From: vixie at isc.org (Paul Vixie) Date: Sun, 31 May 2009 00:46:25 +0000 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: <20090531001700.GE6380@garry-thinkpad.arpnetworks.com> (Garry Dolley's message of "Sat\, 30 May 2009 17\:17\:00 -0700") References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> <20090531001700.GE6380@garry-thinkpad.arpnetworks.com> Message-ID: gdolley at arpnetworks.com (Garry Dolley) writes: > While I like the effort to simplify the current policy, I don't > think this would actually work in practice. To see why, I'd like to > point out the following: > > 1. RFC 3177, "IAB/IESG Recommendations on IPv6 Address Allocations to > Sites" http://tools.ietf.org/html/rfc3177 > > 2. RFC 5375, "IPv6 Unicast Address Assignment Considerations" > http://tools.ietf.org/html/rfc5375 > > Everyone who is participating in these policy debates should read these. Agreed. > Basically, for organizations who are assigning IPv6 space to other > organizations, and aggregating that space to their upstreams, really > do need a /32 to begin with. This is because all their downstream > assignments will be /48's (RFC 3177). Not so fast. > If they were only allowed to get a /48 to begin with, they couldn't > assign any further /48's. Not everything that IETF has written about address allocation has worked out in practice. (For example, classful addressing, or experimental or multicast addressing.) It's reasonable for the RIR's to evaluate the "ground truth" when composing our allocation policies, even though it's also quite important to read everything the IETF has to say on the topic. -- Paul Vixie Chairman ARIN BoT From gdolley at arpnetworks.com Sat May 30 20:53:11 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 17:53:11 -0700 Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6 In-Reply-To: References: Message-ID: <20090531005311.GJ6380@garry-thinkpad.arpnetworks.com> On Fri, May 29, 2009 at 04:30:51PM -0700, Leo Vegoda wrote: > On 29/05/2009 3:37, "John Schnizlein" wrote: > > [...] > > > But there is a whole (IPv4-scale) Internet's worth of class-A > > addresses to hand out. Conserving addresses really matters MUCH less > > than default-free route-table size. Thinking about need really has to > > shift when there really is no scarcity. > > I wasn't trying to argue for more focus on conservation. I was trying to > point out that it is very difficult to maintain two separate policies for > two separate classes of organisations. Sometimes the edges get blurred and > it's hard to work out where someone fits and whether that is fair. > > Does the provider/end user distinction make things easier or does it make > things harder? I suspect the latter. I think it makes it easier. Because it doesn't make a distinction based on "need" but rather on subsequent assignments 1. End user gets a /48 initial allocation 2. An organization planning to assign /48's to end users get a /32 initial allocation I didn't use the word ISP anywhere or suggest what the organization does. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From owen at delong.com Sat May 30 20:59:41 2009 From: owen at delong.com (Owen DeLong) Date: Sat, 30 May 2009 17:59:41 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090531002126.GF6380@garry-thinkpad.arpnetworks.com> References: <4A204EC1.5050905@ipinc.net> <20090530200711.GI27636@garry-thinkpad.arpnetworks.com> <4A21A660.2050804@rollernet.us> <20090531002126.GF6380@garry-thinkpad.arpnetworks.com> Message-ID: <0B9E9A28-D0F4-4CCA-A71D-7497A4BABF4D@delong.com> On May 30, 2009, at 5:21 PM, Garry Dolley wrote: > On Sat, May 30, 2009 at 02:34:24PM -0700, Seth Mattinen wrote: >> Garry Dolley wrote: >>> On Fri, May 29, 2009 at 04:14:56PM -0500, Chris Malayter wrote: >>>> This mentality will only serve to slow ipv6 adoption in >>>> application and >>>> content. The easier we make it for non-isps to get portable >>>> space, the >>>> more >>>> development will occur. Basic supply and demand theory in action >>>> here.... >>> Can't non-ISPs simply apply for a /48 end-user allocation? [1] >>> I don't get this argument I'm seeing in this thread that without the >>> proposed policy modification, IPv6 adoption will be hindered. >> >> Yes. I did - and I currently have - a /48 under that policy. I'm >> announcing >> it right now over BGP and actively using it, actually. >> >> The only problem would be if people started placing filter >> boundaries at >> /32 for all portable IPv6 space and ignored /48's. > > Indeed, that would present a problem to you if /48's were ignored. > > If every end-site gets a globally routable address (of any size, who > cares if it is a /56, or /48 or /40 or /32), where do we aggregate? > Do we just stop aggregating? Do we find ways to hold a very large > number of routes in hardware? > If every current connected org on the planet that has routable IPv4 space and an ASN in the active routing table were to obtain their own portable IPv6 space and announce as many as 10 routes, we would still have a smaller IPv6 routing table than the current IPv4 routing table. Owen > I really don't know.. > > -- > Garry Dolley > ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 > Data center, VPS, and IP Transit solutions > Member Los Angeles County REACT, Unit 336 | WQGK336 > Blog http://scie.nti.st > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From gdolley at arpnetworks.com Sat May 30 21:03:15 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 18:03:15 -0700 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> <20090531001700.GE6380@garry-thinkpad.arpnetworks.com> Message-ID: <20090531010315.GA31529@garry-thinkpad.arpnetworks.com> On Sun, May 31, 2009 at 12:46:25AM +0000, Paul Vixie wrote: > gdolley at arpnetworks.com (Garry Dolley) writes: > > > While I like the effort to simplify the current policy, I don't > > think this would actually work in practice. To see why, I'd like to > > point out the following: > > > > 1. RFC 3177, "IAB/IESG Recommendations on IPv6 Address Allocations to > > Sites" http://tools.ietf.org/html/rfc3177 > > > > 2. RFC 5375, "IPv6 Unicast Address Assignment Considerations" > > http://tools.ietf.org/html/rfc5375 > > > > Everyone who is participating in these policy debates should read these. > > Agreed. > > > Basically, for organizations who are assigning IPv6 space to other > > organizations, and aggregating that space to their upstreams, really > > do need a /32 to begin with. This is because all their downstream > > assignments will be /48's (RFC 3177). > > Not so fast. What do you think the downstream assignment would be? Perhaps we'll see /56's also, we currently already are with some residential ISPs. But I think the smallest we'll see is /64 since many sites will have more than 1 subnet. > > If they were only allowed to get a /48 to begin with, they couldn't > > assign any further /48's. > > Not everything that IETF has written about address allocation has worked > out in practice. (For example, classful addressing, or experimental or > multicast addressing.) It's reasonable for the RIR's to evaluate the > "ground truth" when composing our allocation policies, even though it's > also quite important to read everything the IETF has to say on the topic. Right, I can agree with that. But with having read many of the RFCs pertaining to IPv6, reading posts in nanog and ipv6-ops list, as well as here, and running my own IPv6 network, I tend to *agree* with a lot of what RFC 3177 and 5375 have to say. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 21:09:36 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 18:09:36 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090531004557.GB23664@vacation.karoshi.com.> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <20090529185841.GA87992@gweep.net> <20090529201502.GA6398@ussenterprise.ufp.org> <20090530210421.GP27636@garry-thinkpad.arpnetworks.com> <20090530212819.GA22371@vacation.karoshi.com.> <20090531000037.GC6380@garry-thinkpad.arpnetworks.com> <20090531004557.GB23664@vacation.karoshi.com.> Message-ID: <20090531010936.GB31529@garry-thinkpad.arpnetworks.com> On Sun, May 31, 2009 at 12:45:57AM +0000, bmanning at vacation.karoshi.com wrote: > On Sat, May 30, 2009 at 05:00:38PM -0700, Garry Dolley wrote: > > On Sat, May 30, 2009 at 09:28:19PM +0000, bmanning at vacation.karoshi.com wrote: > > > On Sat, May 30, 2009 at 02:04:22PM -0700, Garry Dolley wrote: > > > > On Fri, May 29, 2009 at 04:15:02PM -0400, Leo Bicknell wrote: > > > > > To that end, I can't support the proposal as written. As one > > > > > commenter asked, "what if my kids want an IPv6 network to play with > > > > > in their garage?" Well, we should find some way to accomodate that > > > > > which doesn't require service providers worldwide to spend tens of > > > > > thousands of dollars upgrading routers to hold the routes. > > > > > > > > Exactly. There's really no reason I should bear the cost of > > > > carrying your route because your kids want to learn about IPv6. I > > > > wholeheartedly want to support learning about IPv6, esp. for the next > > > > generation of network operators, but doing so in a way that taxes > > > > third party network hardware, for no reason, is not the way to do it. > > > > > > > > -- > > > > Garry Dolley > > > > > > > > > i'm sorry - this smacks of shear laziness. > > > trying to get ARIN to manage your routing table > > > is kind of like asking your mom to still do your > > > laundry. > > > > Researching every /32 to see if it is worthy of being in your > > routing table is not practical. It is not a laziness issue. > > your telling me what is practical for me to do? > very kind of you indeed. I did not mean you personally. > however i beg to disagree - i ensure that i have the > specifics i know i want and then proxy aggregate most > everything else. there are even a few prefixes for which > i -never- want to see traffic from and I block them. > > i'd posit that most folks do something very similar. This model doesn't work for me, and I would imagine most ISPs. > > > no one is -forcing- you to accept any route whatsoever. > > > your router, your choice. > > > > Yes, but practically speaking, I can accept all /32's or none of > > them, with a little wiggle room with filters. > > i can't tell you what is practical for you. > > > I can set up filters, sure, but anyone running a multi-homed network > > with real customers, peers, and traffic knows that maintaining > > filters that actually work well is almost a lesson in futility. > > routing has not been "fire and forget" for many years. > if you don't pay attention, your going to get burned. > > > > do the thought experiment... how many /32s are there in > > > the IPv6 universe? Got a router for that? Didn't think so. > > > > > > Folk are going to have to face the fact that they can't > > > depend on their benevolent RIR to manage the potential size > > > of the routing table anymore... > > > > But what we can do is try to promote policy that doesn't give out > > prefixes like they are going out of style. Every /32 prefix > > assigned and announced takes up one more RIB slot for me and every > > other ISP on the planet. So, I'm going to do what I can to save > > that resource. > > borrowing your metaphor, I'd like to see one family of > prefixes come into style... and if that means treating them > like loss-leaders for a bit, then I guess that is what needs > to happen. Then, we can start worrying about them going > out of style. > > I'll reiterate again. Just becauase I get a /32 and announce > it to my peers, is zero reason for you to hold it (at all, > or for any length of time, or in perpetutity). Folks > really need to wean themsleves of the dependency on an RIR > to craft their routing policies. I'm not asking for the RIR to craft routing policies, even if the policy does help / hurt routing. I'm asking for a /32 not to be a default assignment without any restrictions. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 21:31:57 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 18:31:57 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <0B9E9A28-D0F4-4CCA-A71D-7497A4BABF4D@delong.com> References: <4A204EC1.5050905@ipinc.net> <20090530200711.GI27636@garry-thinkpad.arpnetworks.com> <4A21A660.2050804@rollernet.us> <20090531002126.GF6380@garry-thinkpad.arpnetworks.com> <0B9E9A28-D0F4-4CCA-A71D-7497A4BABF4D@delong.com> Message-ID: <20090531013157.GB5707@garry-thinkpad.arpnetworks.com> On Sat, May 30, 2009 at 05:59:41PM -0700, Owen DeLong wrote: > > On May 30, 2009, at 5:21 PM, Garry Dolley wrote: > >> On Sat, May 30, 2009 at 02:34:24PM -0700, Seth Mattinen wrote: >>> Garry Dolley wrote: >>>> On Fri, May 29, 2009 at 04:14:56PM -0500, Chris Malayter wrote: >>>>> This mentality will only serve to slow ipv6 adoption in application and >>>>> content. The easier we make it for non-isps to get portable space, the >>>>> more >>>>> development will occur. Basic supply and demand theory in action >>>>> here.... >>>> Can't non-ISPs simply apply for a /48 end-user allocation? [1] >>>> I don't get this argument I'm seeing in this thread that without the >>>> proposed policy modification, IPv6 adoption will be hindered. >>> >>> Yes. I did - and I currently have - a /48 under that policy. I'm >>> announcing >>> it right now over BGP and actively using it, actually. >>> >>> The only problem would be if people started placing filter boundaries at >>> /32 for all portable IPv6 space and ignored /48's. >> >> Indeed, that would present a problem to you if /48's were ignored. >> >> If every end-site gets a globally routable address (of any size, who >> cares if it is a /56, or /48 or /40 or /32), where do we aggregate? >> Do we just stop aggregating? Do we find ways to hold a very large >> number of routes in hardware? >> > If every current connected org on the planet that has routable IPv4 > space and an ASN in the active routing table were to obtain their > own portable IPv6 space and announce as many as 10 routes, we > would still have a smaller IPv6 routing table than the current IPv4 > routing table. Care to share your math on this? I'm not saying you're wrong, I just wasn't able to come to the same conclusion. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From matthew at matthew.at Sat May 30 22:43:40 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 30 May 2009 19:43:40 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530192029.GE27636@garry-thinkpad.arpnetworks.com> References: <2557049CDBC35B4EBD79CFACFEC045841B9F548B@XCH-NW-CCR1V.nw.nos.boeing.com> <20090529212938.GA11989@ussenterprise.ufp.org> <4A205A75.10107@matthew.at> <20090530192029.GE27636@garry-thinkpad.arpnetworks.com> Message-ID: <4A21EEDC.9070001@matthew.at> Garry Dolley wrote: > On Fri, May 29, 2009 at 02:58:13PM -0700, Matthew Kaufman wrote: > >> >> Really there shouldn't even *be* a distinction. If you need a /whatever of >> IPv6 and can write a convincing letter to that effect, you should be able >> to get at least that much unique IPv6 space. Whether it can be routed now >> or in the future is really between you and whichever transit provider you >> choose *should you even need external connectivity*. >> > > It is not only between you and the transit provider. It is also > between you and all the networks / network operators that > collectively make up the Internet. No. There may be issues between my transit provider and their transit provider and/or peers, but that's one of the things I pay them for. > If I'm going to carry your > prefix in my routing table and the resources of my routing table are > finite, and more routing table resources often costs me a > appreciable amount of additional money (money out of my pocket, not > yours), then I have a say in whether you get a "/whatever" > allocation just b/c you wrote a convincing letter. > You can carry whatever routes you want in your own routers, subject of course to any agreements you might have with peers. > This is why we are discussing the policy proposal ;) > This is also where we get into the part where you're asking ARIN to act not just as a registrar of unique addresses, but instead to also enforce your idea of who should have routeable addresses on the global Internet you are part of. Which really shouldn't be any of ARIN's business, any more than the folks who hand out MAC addresses get to decide what color box the ethernet cards come in. Matthew Kaufman From matthew at matthew.at Sat May 30 22:45:29 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 30 May 2009 19:45:29 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530195050.GA21698@vacation.karoshi.com.> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> <20090530190622.GC27636@garry-thinkpad.arpnetworks.com> <20090530195050.GA21698@vacation.karoshi.com.> Message-ID: <4A21EF49.1080900@matthew.at> bmanning at vacation.karoshi.com wrote: > > what upstream is that? once again, the limiting notion that > there connectedness to "someone else" is a prerequiste for using IP. > uniqueness i can understand (someday you might want to be connected, > but now...) > > Not only might there not be an "upstream" at this time, the address might be in use on a different global Internet than the one we're all thinking of, at least for now. Still, no reason someone shouldn't be able to get a unique address of the size they need to do what they plan to do. After all *there's a whole lot of them with IPv6*. Matthew Kaufman From matthew at matthew.at Sat May 30 22:49:05 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 30 May 2009 19:49:05 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530201355.GJ27636@garry-thinkpad.arpnetworks.com> References: <4A203143.5010908@matthew.at> <28E139F46D45AF49A31950F88C4974580161F072@E03MVZ2-UKDY.domain1.systemhost.net> <2557049CDBC35B4EBD79CFACFEC045841B9F5488@XCH-NW-CCR1V.nw.nos.boeing.com> <4A204EC1.5050905@ipinc.net> <4A205494.40507@matthew.at> <20090530201355.GJ27636@garry-thinkpad.arpnetworks.com> Message-ID: <4A21F021.4000408@matthew.at> Garry Dolley wrote: > > For your lab scenario, the developer can use ULAs (Unique Local IPv6 > Addresses) [1]. Right now, ULAs is a proposed standard. > Those are guaranteed to be and stay globally unique, nor will they be routeable at any future time. In my scenario the former is a requirement and the latter is highly suggested. (Why? Well, it is my scenario, so I get to set the rules. But seriously, I was doing IT work at a company that wanted to give IPv6 addresses to every disk drive in a huge network storage testbed, and wanted those to be globally unique, but the cost of getting an end-user /48 was high enough that instead they just picked some random prefix and used that. Some day they'll connect to the global IPv6 Internet and we'll see how lucky their choice was.) Matthew Kaufman From bill at herrin.us Sat May 30 22:50:11 2009 From: bill at herrin.us (William Herrin) Date: Sat, 30 May 2009 22:50:11 -0400 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: <633952A8-D276-4FC8-B778-2D8B5C71EECD@delong.com> References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> <633952A8-D276-4FC8-B778-2D8B5C71EECD@delong.com> Message-ID: <3c3e3fca0905301950u7c36eb63xc4b56f5439d9a452@mail.gmail.com> On Sat, May 30, 2009 at 7:49 PM, Owen DeLong wrote: > Uh, since the first assignment from an ISP to a customer could well > be a /48, how exactly are they supposed to accomplish that and number > their own infrastructure for even a single POP out of that first /48? Hi Owen, Maybe we should discourage that behavior. A /48 is 16 /52's or 256 /56's or 4096 /60's. If we assume, as I do in this plan, that any multihomed entity will get its IP addresses directly from ARIN then only single-homed entities will be downstream from you. A /52 is 4000 subnets. Can you identify many single-homed entities who use or would use more than 4000 subnets? Neither can I. In fact, I'd be willing to bet that only a fraction of a percent of single-homed customers would ever use more than the 16 subnets provided in a /60. Let me put it another way: an IPv6 /48 contains more subnets than all but the largest dozen ISPs have ever used in IPv4. Surely they can find a way to make do with their very first /48 long enough to justify the upgrade to a /32. That having been said, I wouldn't be morally opposed to allowing entities which hold at least a /16 of IPv4 space to skip the /48 step and go straight to /32 if they want to and have been doing a responsible job with SWIP or RWHOIS. On Sat, May 30, 2009 at 3:51 PM, wrote: > can you say,,, A. B. C.... Bill, Would classful addressing have led to the same problems if there were 16 million A's in the pool so that we didn't have to give anybody multiple C's or B's? The fellas at the IETF have told us that our best shot at restraining the DFZ BGP table size is to standardize the prefixes that go into the table in a way that limits single-entity control of disaggregated address space and discourages the propagation of disaggregated routes. The particular way they suggested for limiting disaggregation doesn't look very promising, but they're not entirely wrong. On Sat, May 30, 2009 at 8:17 PM, Garry Dolley wrote: > 1. RFC 3177, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites" > http://tools.ietf.org/html/rfc3177 > > 2. RFC 5375, "IPv6 Unicast Address Assignment Considerations" > http://tools.ietf.org/html/rfc5375 > > Everyone who is participating in these policy debates should read > these. Garry, Agreed, however... > This is because all their downstream > assignments will be /48's (RFC 3177). The RFCs provide useful knowledge but we would be mistaken to treat their guidance on addressing dogmatically. I have participated in and attended meetings for both ARIN and the IETF. In particular, I've been a participant of the IRTF Routing Research Group for years. I'll tell you straight up: the center of expertise on the address assignment process is here on the PPML and in the similar forums at the other RIRs. In other words, /48 as the standard downstream assignment is not the gospel truth. It was based in part on the proposition that we should try to allocate all the addresses an organization will ever need up front the first time. Should we find that doesn't work as well as, say, assigning a small block first and then assigning a second much larger one when you run out, then the advice on /48's downstream no longer holds. A better idea might be a /60 for single-homed downstreams, add a /56 when needed and add a /52 after that. Increments, mirroring my crazy notion for the RIR process. But I'd expect service providers to treat that notion with all the reverence I'm giving to RFC 3177. And that's okay too. 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 Sat May 30 22:51:25 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 30 May 2009 19:51:25 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530204053.GN27636@garry-thinkpad.arpnetworks.com> References: <4A1FFBE5.20807@arin.net> <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> <2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com> <4A202F60.8000408@matthew.at> <20090530204053.GN27636@garry-thinkpad.arpnetworks.com> Message-ID: <4A21F0AD.1010809@matthew.at> Garry Dolley wrote: > > There are not enough /32 subnets to give away to everyone. There > are as many /32 subnets in IPv6 as there are in IPv4. Just in IPv4, > the /32 subnet just held 1 address. We are running out of IPv4, so > by the same token, if we liberally give away /32's in IPv6, we'll > face the same exhaustion. That doesn't follow. We're talking about /48s and single /32s, not giving out 256-65535 /32s to the typical early entrant entities as was done with IPv4. Matthew Kaufman From bill at herrin.us Sat May 30 23:00:14 2009 From: bill at herrin.us (William Herrin) Date: Sat, 30 May 2009 23:00:14 -0400 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> Message-ID: <3c3e3fca0905302000i6e278029t175de83a9cea986b@mail.gmail.com> On Sat, May 30, 2009 at 3:05 PM, William Herrin wrote: > So here's a crazy plan: > > A. The first IPv6 allocation from ARIN is always a /48. To justify it, > you need to be multihomed. There are no other qualifications. The /48 > will be allocated from a pool from which only /48's are allocated. > > B. The second IPv6 allocation from ARIN is always a /32. To justify it > you need to demonstrate that you've efficiently used the /48 for some > reasonable definition of efficient, that you've implemented SWIP or > RWHOIS for your downstream assignments and that you will run out of > space in the /48 within one year. The /32 will be allocated from a > pool reserved for allocating /32's. > > C. The third IPv6 allocation from ARIN is always a /24. To justify it > you need to demonstrate that you've efficiently used the /32, that you > will run out of space in the /32 within five years, and you have to > first return the original /48 you were assigned. The /24 will be > allocated from a pool reserved for allocating /24's. > > D. There is no fourth IPv6 allocation at this time. It is not > presently possible to consume an entire /24 without atrocious waste. Two issues with the plan which need more consideration: 1. What happens when entities merge? 2. What happens when entities split? If two entities holding /32's merge, you now have one entity with two /32's. Do they have to give up one of the /32's within some period of time? Give up one of them before they can upgrade to /24? Never give up the second /32? What makes sense here? When entities split its even harder. The /32 in this plan is indivisible. It can only travel with one of the two new entities. Is that going to be acceptable? Or does it scuttle the idea? 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 Sat May 30 23:02:58 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 30 May 2009 20:02:58 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <9E2B2273-4394-424B-99CE-1C01AE984F5F@arpnetworks.com> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> <20090530190622.GC27636@garry-thinkpad.arpnetworks.com> <20090530195050.GA21698@vacation.karoshi.com.> <20090530212253.GA2827@garry-thinkpad.arpnetworks.com> <20090530213008.GB22371@vacation.karoshi.com.> <9E2B2273-4394-424B-99CE-1C01AE984F5F@arpnetworks.com> Message-ID: <4A21F362.7020802@matthew.at> Garry Dolley wrote: > > Correct, but given the use cases mentioned, statistically probable > uniqueness is sufficient. > If RIRs don't have reasonable policies, we might find that statistically probable uniqueness (within an address space as big as IPv6 is) is also sufficient for assigning addresses to onesself for the global routing table. Matthew Kaufman From matthew at matthew.at Sat May 30 23:06:34 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 30 May 2009 20:06:34 -0700 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: <3c3e3fca0905301950u7c36eb63xc4b56f5439d9a452@mail.gmail.com> References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> <633952A8-D276-4FC8-B778-2D8B5C71EECD@delong.com> <3c3e3fca0905301950u7c36eb63xc4b56f5439d9a452@mail.gmail.com> Message-ID: <4A21F43A.8020504@matthew.at> William Herrin wrote: > > That having been said, I wouldn't be morally opposed to allowing > entities which hold at least a /16 of IPv4 space to skip the /48 step > and go straight to /32 if they want to and have been doing a > responsible job with SWIP or RWHOIS. > Why do we believe that the past performance of users of IPv4 space is a good predictor of future performance of users of IPv6 space?* For all we know, the widest IPv6 deployment that ever happens may be by someone nobody has ever heard of today. Matthew Kaufman *I can tell you that one of MY IPv4 transit providers was, a year ago, unable to even tell me if they had an IPv6 plan and a few weeks ago was able to tell me that they're thinking about IPv6 but have no idea when it might be available. From gdolley at arpnetworks.com Sat May 30 23:50:19 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 20:50:19 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A21EEDC.9070001@matthew.at> References: <2557049CDBC35B4EBD79CFACFEC045841B9F548B@XCH-NW-CCR1V.nw.nos.boeing.com> <20090529212938.GA11989@ussenterprise.ufp.org> <4A205A75.10107@matthew.at> <20090530192029.GE27636@garry-thinkpad.arpnetworks.com> <4A21EEDC.9070001@matthew.at> Message-ID: <20090531035019.GB22975@garry-thinkpad.arpnetworks.com> On Sat, May 30, 2009 at 07:43:40PM -0700, Matthew Kaufman wrote: > Garry Dolley wrote: >> On Fri, May 29, 2009 at 02:58:13PM -0700, Matthew Kaufman wrote: >> >>> >>> Really there shouldn't even *be* a distinction. If you need a /whatever >>> of IPv6 and can write a convincing letter to that effect, you should be >>> able to get at least that much unique IPv6 space. Whether it can be >>> routed now or in the future is really between you and whichever transit >>> provider you choose *should you even need external connectivity*. >>> >> >> It is not only between you and the transit provider. It is also >> between you and all the networks / network operators that >> collectively make up the Internet. > No. There may be issues between my transit provider and their transit > provider and/or peers, but that's one of the things I pay them for. The route that you pay your transit provider to advertise will propagate to my network. We are all connected, it is not as segregated as you think. >> If I'm going to carry your >> prefix in my routing table and the resources of my routing table are >> finite, and more routing table resources often costs me a >> appreciable amount of additional money (money out of my pocket, not >> yours), then I have a say in whether you get a "/whatever" >> allocation just b/c you wrote a convincing letter. >> > You can carry whatever routes you want in your own routers, subject of > course to any agreements you might have with peers. Correct, I can filter as I please. >> This is why we are discussing the policy proposal ;) >> > This is also where we get into the part where you're asking ARIN to act not > just as a registrar of unique addresses, but instead to also enforce your > idea of who should have routeable addresses on the global Internet you are > part of. Not really. ARIN even states that assigned addresses are not guaranteed to be routable [1]. Network operators decide what is routable. I'm not asking ARIN to decide this. Nevertheless, saying that "ARIN shouldn't dictate routing policy" is not equivalent to "ARIN should reduce the barrier to entry for a /32" or "ARIN should have an open policy for /32 assignments" I oppose the current policy proposal. My reasoning has already been discussed, and relates to routing table size. That's my opinion, others may have different reasons to oppose or promote. 1. https://www.arin.net/policy/nrpm.html#six42 -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sat May 30 23:56:41 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sat, 30 May 2009 20:56:41 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <4A21F0AD.1010809@matthew.at> References: <4A1FFBE5.20807@arin.net> <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> <2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com> <4A202F60.8000408@matthew.at> <20090530204053.GN27636@garry-thinkpad.arpnetworks.com> <4A21F0AD.1010809@matthew.at> Message-ID: <20090531035641.GC22975@garry-thinkpad.arpnetworks.com> On Sat, May 30, 2009 at 07:51:25PM -0700, Matthew Kaufman wrote: > Garry Dolley wrote: >> >> There are not enough /32 subnets to give away to everyone. There >> are as many /32 subnets in IPv6 as there are in IPv4. Just in IPv4, >> the /32 subnet just held 1 address. We are running out of IPv4, so >> by the same token, if we liberally give away /32's in IPv6, we'll >> face the same exhaustion. > > That doesn't follow. We're talking about /48s and single /32s, not giving > out 256-65535 /32s to the typical early entrant entities as was done with > IPv4. What part doesn't follow? There are 4G IPv4 addresses (/32) and there are 4G IPv6 subnets of /32 in size. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From matthew at matthew.at Sun May 31 00:18:19 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 30 May 2009 21:18:19 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090531035641.GC22975@garry-thinkpad.arpnetworks.com> References: <4A1FFBE5.20807@arin.net> <24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com> <2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com> <4A202F60.8000408@matthew.at> <20090530204053.GN27636@garry-thinkpad.arpnetworks.com> <4A21F0AD.1010809@matthew.at> <20090531035641.GC22975@garry-thinkpad.arpnetworks.com> Message-ID: <4A22050B.8090405@matthew.at> Garry Dolley wrote: > On Sat, May 30, 2009 at 07:51:25PM -0700, Matthew Kaufman wrote: > >> Garry Dolley wrote: >> >>> There are not enough /32 subnets to give away to everyone. There >>> are as many /32 subnets in IPv6 as there are in IPv4. Just in IPv4, >>> the /32 subnet just held 1 address. We are running out of IPv4, so >>> by the same token, if we liberally give away /32's in IPv6, we'll >>> face the same exhaustion. >>> >> That doesn't follow. We're talking about /48s and single /32s, not giving >> out 256-65535 /32s to the typical early entrant entities as was done with >> IPv4. >> > > What part doesn't follow? There are 4G IPv4 addresses (/32) and > there are 4G IPv6 subnets of /32 in size. > > Almost all of the 4G IPv4 addresses (and it isn't even that big, just like there aren't 4G IPv6 subnets) that are assigned are not actually in use. We're only "running out" because there's networks all over the world that have fewer hosts connected than the subnet has room for. *Especially* if you talk about the (relatively large) networks that were handed out early on. Show me a "swamp" /24 and I'll show you a network that doesn't have 254+ hosts attached and powered on. I'm not the first to ask you to please not confuse network assignment density with host assignment density, either. Matthew Kaufman From mysidia at gmail.com Sun May 31 01:19:38 2009 From: mysidia at gmail.com (James Hess) Date: Sun, 31 May 2009 00:19:38 -0500 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> Message-ID: <6eb799ab0905302219x5b88055m7e17855b935eec3c@mail.gmail.com> Why allocate /32s from a pool reserved for /32s? It would perhaps make more sense, as a matter of policy, that a special allocation strategy be utilized, that the /48s, /32s, and /24s are allocated from just one pool. And that they be allocated in a manner that maximizes the duration during which the 2nd/3rd allocation request would be contiguous with the earlier allocation. e.g. A /48 may be allocated, but the entire /24 could be left "internally" reserved for as long as possible. So if/when a recipient of a /48 allocation requests their next allocation, it would be preferred that the /32 will be a block that begins with, and contains the same address space as their /48, in addition to the added space. And if a third allocation is requested, the /24 also, would be chosen so as to overlap with and contain the /32. This has the benefit that they don't need a second advertisement, and never have a need to return addresses. If/when ARIN's allocations of V6 space ever becomes so dense that reserving the entire /24 in advance for recipients of /48s is no longer feasible, it should be the oldest-assigned /48 that are first "blocked" from expanding contiguously to a /24, followed by the oldest /32 allocations. With preference of the "blocking" assignments preventing contiguous expansions to /24 over contiguous expansions to /32. -- -J From sethm at rollernet.us Sun May 31 01:36:04 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 30 May 2009 22:36:04 -0700 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: References: <4A1FFBE5.20807@arin.net> <4A21A8D6.6080909@rollernet.us> Message-ID: <4A221744.40902@rollernet.us> Owen DeLong wrote: >> >>> 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in >>> the ARIN region or have a plan for making at least 200 end-site >>> assignments to other organizations within 5 years? in its entirety. >>> Rationale: It is acknowledged that these concepts have been put before >>> the community in the past. However, with the wisdom of actual >>> operational experience, the necessity of promoting IPv6 adoption >>> throughout our region, and emerging native v6 only network models, it >>> becomes obvious that these modifications to the NRPM are necessary. >>> Removing the 200 end site requirement enables smaller, but no less >>> important and viable, networks access to IPv6. Removing the ?known ISP? >>> requirement enfranchises new, native v6 businesses that can drive >>> innovation and expansion in the Internet industry, as well as other >>> industries. Removing the requirement for a single aggregate announcement >>> benefits the NRPM itself, as it has been decided by the community that >>> it should not contain routing advice. >> >> I OPPOSE this change because "smaller, but no less important and >> viable, networks" can already apply for and obtain a /48 under >> existing policies. >> > Not as ISPs assigning /48s to end users, they cannot. > Then they should be able to qualify for a /32 with some kind of plan. If 200 is a problem, maybe we reduce the requirement to 100 or something, not strike it out completely. If we're going to keep the distinction between ISP and end-user then we need to do so; we shouldn't randomly strike portions of the ISP policy to make it the same as the end-user policy while keeping them both. I would support removing the distinction between ISP and end-user, as one's internet hobby has the possibility to be come something bigger. However, a proposal to remove a pair of phrases is not it. ~Seth From gdolley at arpnetworks.com Sun May 31 08:45:47 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sun, 31 May 2009 05:45:47 -0700 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: <6eb799ab0905302219x5b88055m7e17855b935eec3c@mail.gmail.com> References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> <6eb799ab0905302219x5b88055m7e17855b935eec3c@mail.gmail.com> Message-ID: <20090531124546.GA5400@garry-thinkpad.arpnetworks.com> On Sun, May 31, 2009 at 12:19:38AM -0500, James Hess wrote: > Why allocate /32s from a pool reserved for /32s? > It would perhaps make more sense, as a matter of policy, that a > special allocation strategy be utilized, that the /48s, /32s, and > /24s are allocated from just one pool. > > And that they be allocated in a manner that maximizes the duration > during which the 2nd/3rd allocation request would be contiguous with > the earlier allocation. > > > e.g. A /48 may be allocated, but the entire /24 could be left > "internally" reserved for as long as possible. > > So if/when a recipient of a /48 allocation requests their next > allocation, it would be preferred that the /32 will be a block that > begins with, and contains the same address space as their /48, in > addition to the added space. > > And if a third allocation is requested, the /24 also, would be chosen > so as to overlap with and contain the /32. > > > This has the benefit that they don't need a second advertisement, and > never have a need to return addresses. > > > > If/when ARIN's allocations of V6 space ever becomes so dense that > reserving the entire /24 in advance for recipients of /48s is no > longer feasible, it should be the oldest-assigned /48 that are > first "blocked" from expanding contiguously to a /24, followed by the > oldest /32 allocations. > > With preference of the "blocking" assignments preventing contiguous > expansions to /24 over contiguous expansions to /32. James makes a good point. Since the v6 space is so large, ARIN can, for example, allocate an org a /32, but leave the neighboring /32 unallocated for as long as possible, so if/when you need another /32, they just change your subnet mask to a /31. No renumbering required. I once was lucky to have this happen w/ v4. I had a /20 from ARIN, then at some point requested another. The neighboring /20 was available, so they just made it a /19. Any org in the position to allocate IP space can do this [1]. For example, if I give a /56 to a customer, I'll pretend as if it were a /48, so if that customer ever needed more subnets than a /56 has to offer, I'll just change their subnet mask to a /48. They don't need to renumber or deal with two discontiguous /56's. Therefore, having ARIN use separate "pools" for different allocation sizes would not be a good idea. 1. RFC 3531, "A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block" http://tools.ietf.org/html/rfc3531 -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From rbf+arin-ppml at panix.com Sun May 31 08:50:44 2009 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Sun, 31 May 2009 07:50:44 -0500 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090531013157.GB5707@garry-thinkpad.arpnetworks.com> References: <4A204EC1.5050905@ipinc.net> <20090530200711.GI27636@garry-thinkpad.arpnetworks.com> <4A21A660.2050804@rollernet.us> <20090531002126.GF6380@garry-thinkpad.arpnetworks.com> <0B9E9A28-D0F4-4CCA-A71D-7497A4BABF4D@delong.com> <20090531013157.GB5707@garry-thinkpad.arpnetworks.com> Message-ID: <20090531125044.GA29343@panix.com> On Sat, May 30, 2009 at 06:31:57PM -0700, Garry Dolley wrote: > On Sat, May 30, 2009 at 05:59:41PM -0700, Owen DeLong wrote: > > > > If every current connected org on the planet that has routable IPv4 > > space and an ASN in the active routing table were to obtain their > > own portable IPv6 space and announce as many as 10 routes, we > > would still have a smaller IPv6 routing table than the current IPv4 > > routing table. > > Care to share your math on this? http://www.cidr-report.org/ About 30K origin AS's. About 300K prefixes. -- brett From bicknell at ufp.org Sun May 31 12:11:52 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 31 May 2009 12:11:52 -0400 Subject: [arin-ppml] Number of routes, IPv6 vrs IPv4. Message-ID: <20090531161152.GB51278@ussenterprise.ufp.org> In all the talk about how liberal we want to be with giving out IPv6 number resources there seems to be little concern for the technology involved. I want to go down that road a little bit. I want to get off the table the notion that these addresses are not going to be used on the Internet. While I agree there are applications where folks need globally unique addresses for non-Internet connected networks the fact of the matter is virtually all (I'm sure well over 99%) of ARIN allocated space appears on the Internet at some point. While I think there are good reasons to look at policy in these areas and have better mechanisms for non-Internet usages, the core of what ARIN does is provide addresses to the Internet, so I think that is where we should focus. Now, to the bit of technology. IPv6 addresses are larger than IPv4 addresses. Specifically, they are four times larger. Routers have to hold the routing information in memory, and so this means an equivalent number of IPv6 routes will take four times the memory. You might say, so what, memory is cheap these days. That can be true, but in many cases we're not talking about PC DRAM. Routers and switches uses many sorts of specialized memory in order to make lookups happen fast enough to route packets at wire speed. This specialized memory is much more expensive. Every platform is different. I can't provide some general rule, and indeed finding documentation on some of the inner workings is difficult unless you are a major purchaser of said equipment and get the behind the scenes tour from a vendor. I will point out one available example that I think is fairly "middle of the road" in terms of the issue. There as recently been a lot of press about the Cisco 6500 "Sup720-3B" platform. This platform uses TCAM (http://en.wikipedia.org/wiki/Content-addressable_memory#Ternary_CAMs) to hold routing information so that switching decisions can be made at high speed. This is fairly expensive memory. The reason this made press is there is only enough TCAM to hold 256,000 IPv4 routes, and the IPv4 routing table is now up in the 290,000 range. You can find lots of articles about how folks are choosing to throw away prefixes to fit in the TCAM limit. The result though is there is a lot of documentation available about this platform. Here's a presentation from NANOG: http://www.nanog.org/meetings/nanog39/presentations/fib-desilva.pdf (Page 10) You'll find that the original Sup720-3B defaulted to 192k IPv4 routes, and 32k IPv6 routes. This could be user-configured, allowing 256k IPv4 routes with 0 IPv6 routes, or 64K IPv6 routes with 0 IPv4 routes. This all falls out of the IPv6 routes are 4x as large. In the upgraded hardware the vendors came up with some tricks ("double lookup"). The Sup720-3BXL can hold 512k IPv4 routes and 256k IPv6 routes. Using these software tricks they are able to get the multiple down to 2x. The really scary thing here is that, in the short to medium term giving out the same number of IPv6 routes as we have IPv4 routes in the past is likely to exhaust the available memory on many devices. This is both because IPv6 routes are larger, and in the short and medium term providers will have to hold both an IPv4 and IPv6 routing table. Some folks have taken a "so what, routing isn't ARIN's problem" position. That's true, and to a degree I respect the position. However, it turns out the problem here is worse than many realize. If you look back to the dark days of the Internet when the routing table grew to where AGS+'s couldn't hold the table anymore and we implemented CIDR you'll find lots of companies implemented prefix length filtering. The reason you can't route smaller than a /24 today is largely rooted in history. Indeed, for many years particular backbone providers wouldn't route smaller than a /19, so if you had a /20 well, you just didn't get access to a portion of the Internet. It was all quite messy. The 6500 situation is causing a sort of mini-repeat. The box is so popular in edge applications that folks are having to figure out how to deal with a box that can't hold all the routes. It's easy to find suggestions on google, and once again they typically involve filtering at a /19 or /20 border, default routing to an upstream router or provider and dealing with the lack of routing. So folks know how to deal with this, why would IPv6 be worse? Well, notice the solutions in the past have been prefix length filtering. If ARIN provides all /32's then there is no way to filter based on prefix length. A filter of /32 is nothing, of /33 is everything. We will have inadvertently removed the primary tool providers use to deal with this issue. How will providers filter? I don't know. Really the only information left in BGP at that point is AS-PATH, so that's the only filtering providers could implement. There's a real danger that providers look at "Humm, this is the ASN for Facebook, and this is the ASN for Lolcats. More people want facebook, filter the Lolcats." Providers could implement fees to get a routing table slot, fully settled across peering connections. The fees would rise to keep folks from injecting routes that could not be paid for. Now, there is some good news here, from the Weekly Routing Table report posted to Nanog: ] ARIN Region Analysis Summary ] ---------------------------- ] ] Prefixes being announced by ARIN Region ASes: 124963 ] Total ARIN prefixes after maximum aggregation: 65735 ] ARIN Deaggregation factor: 1.90 ] Prefixes being announced from the ARIN address blocks: 125685 ] Unique aggregates announced from the ARIN address blocks: 51667 ] ARIN Region origin ASes present in the Internet Routing Table: 13003 ] ARIN Prefixes per ASN: 9.67 If we can give everyone with an ASN an appropriate sized block so they only need 1 block we likely can reduce the size of the roting table by up to 9.67 times. Folks are announcing multiple blocks in part because that's how the system works, you get a new block every year. 10 prefixes per ASN, and ARIN has been around 11 years.....interesting. My personal feeling is both extremes are bad. Current IPv6 policy is too conservative, still reflecting both an IPv4 mind set and also some failed notions of addressing heirarchy. However the idea that we can give a block to everyone who walks up, circa the allocation policy of 1989 is equally foolish, and will lead to widespread industry issues. We need to chart a reasonable middle ground, perhaps one more liberal than we have now but not wide open. Personally I think the focus should be on getting everyone with an ASN an appropriately sized block. If we do that, we can make the IPv6 routing table 7-10 times smaller than the IPv4 routing table. That makes the transition possible, as remember both tables have to fit in memory for the time we are dual stacked. Given that IPv6 addresses are 4x as big, achieving an 8x reduction is really only saving half the memory. Once we've gotten this aspect right we can focus on opening up space to more players. Lastly, there seems to be a notion floating around that lack of IPv6 address space is the problem. The majority of the large players have IPv6 address space. I think if you looked at the top 10 ISP's in the US, all of them now have IPv6 address space from ARIN; and yet only 2 or 3 are offering IPv6 services to their customers. The idea that address space is preventing deployment fails right out of the gate. Many of these folks have space and are still not offering services. It is easy to think the solution is a new entrant. Clearly if the incumbents don't want to provide a service then a new entrant will. This logic doesn't hold though, as the primary reason the existing operators aren't offering Ipv6 is lack of a business cases. If there is no business case there is no way for a new entrant to make a go. So the critical items going forward to me are: - Remove the totally arbitrary 200 site requirement. There are plenty of thriving ISP's with less than 200 customers. Colo based companies come to mind, your 100,000 sq ft data center may have 10, 10,000 sq ft customers, and 500,000 machines in the building. - Make sure everyone with an ASN can easily get a right sized IPv6 allocation. Let's make good on the idea of "one route per ASN". Let's insure everyone in the game can get space easily on that basis. - Come up with sensible requirements for new entrants. "200 customers" is not a sensible requirement. Starting someone off with a /32 and then not talking to them is not a sensible way of doing business. RFC 2050, and IPv4 both had the notion of "slow start", which fit with the idea of needs based allocations. New entrants came back at 3, 6, and 12 months, and then yearly. If they were allocating "wrong" it was caught quickly, and fixed. We need some mechanism to talk to new entrants more often than every 10 years, make sure they are following the community rules, and clean up messes before they have collected for 10 years. I don't think we have proposal(s) that get this right on the table yet. -- 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: 825 bytes Desc: not available URL: From josmon at rigozsaurus.com Sun May 31 12:06:53 2009 From: josmon at rigozsaurus.com (John Osmon) Date: Sun, 31 May 2009 10:06:53 -0600 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090529160246.GA23729@gweep.net> References: <4A1FFBE5.20807@arin.net> <4A200639.4030209@rollernet.us> <20090529160246.GA23729@gweep.net> Message-ID: <20090531160653.GA1226@jeeves.rigozsaurus.com> On Fri, May 29, 2009 at 12:02:46PM -0400, Joe Provo wrote: > On Fri, May 29, 2009 at 08:58:49AM -0700, Seth Mattinen wrote: [...] > > What's the rationale for this proposed change? > > It better reflects the reality of the meshy global Internet where > aggregated trunk, backbone-only providers are a rare and dying breed. Indeed, times are a'changing... I'm leaning towards full support of this proposal. Perhaps we *need* a swamp of some type to illustrate the importance of a solid foundation elsewhere? From tvest at pch.net Sun May 31 13:15:54 2009 From: tvest at pch.net (Tom Vest) Date: Sun, 31 May 2009 13:15:54 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090531160653.GA1226@jeeves.rigozsaurus.com> References: <4A1FFBE5.20807@arin.net> <4A200639.4030209@rollernet.us> <20090529160246.GA23729@gweep.net> <20090531160653.GA1226@jeeves.rigozsaurus.com> Message-ID: On May 31, 2009, at 12:06 PM, John Osmon wrote: > On Fri, May 29, 2009 at 12:02:46PM -0400, Joe Provo wrote: >> On Fri, May 29, 2009 at 08:58:49AM -0700, Seth Mattinen wrote: > [...] >>> What's the rationale for this proposed change? >> >> It better reflects the reality of the meshy global Internet where >> aggregated trunk, backbone-only providers are a rare and dying breed. > > Indeed, times are a'changing... I'm leaning towards full support of > this proposal. > > Perhaps we *need* a swamp of some type to illustrate the importance of > a solid foundation elsewhere? If I remember correctly, creating a swamp only serves to constantly remind those who are stuck with it afterward that swamp creation was/ is a very bad idea. Besides, if you have an idea of where/how one might build a more "solid foundation", persuading us now, up front might be a more effective way of bringing people around than intentionally degrading the only "ground" that's currently apparent. You don't want to be remembered like this: http://www.youtube.com/watch?v=NJEgqhzwz0o TV From kloch at kl.net Sun May 31 14:42:14 2009 From: kloch at kl.net (Kevin Loch) Date: Sun, 31 May 2009 14:42:14 -0400 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: <6eb799ab0905302219x5b88055m7e17855b935eec3c@mail.gmail.com> References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> <6eb799ab0905302219x5b88055m7e17855b935eec3c@mail.gmail.com> Message-ID: <4A22CF86.4040304@kl.net> James Hess wrote: > Why allocate /32s from a pool reserved for /32s? > It would perhaps make more sense, as a matter of policy, that a > special allocation strategy be utilized, that the /48s, /32s, and > /24s are allocated from just one pool. > > And that they be allocated in a manner that maximizes the duration > during which the 2nd/3rd allocation request would be contiguous with > the earlier allocation. This is called "sparse allocation" method and is what APNIC uses today. It was one of the the justifications for giving each RIR blocks of /12 instead of /23. I would like to know why ARIN is not using this method. - Kevin From vixie at isc.org Sun May 31 15:29:14 2009 From: vixie at isc.org (Paul Vixie) Date: Sun, 31 May 2009 19:29:14 +0000 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: (Tom Vest's message of "Sun\, 31 May 2009 13\:15\:54 -0400") References: <4A1FFBE5.20807@arin.net> <4A200639.4030209@rollernet.us> <20090529160246.GA23729@gweep.net> <20090531160653.GA1226@jeeves.rigozsaurus.com> Message-ID: tvest at pch.net (Tom Vest) writes: > If I remember correctly, creating a swamp only serves to constantly > remind those who are stuck with it afterward that swamp creation was / is > a very bad idea. Besides, if you have an idea of where/how one might > build a more "solid foundation", persuading us now, up front might be a > more effective way of bringing people around than intentionally degrading > the only "ground" that's currently apparent. there are more than two visions (pure hierarchy and pure swamp). for example: neighborhood or metro-area mesh networking where local cheap highspeed ISO-L2 is used to glue geographies together in a way that no telco or backbone net is involved... would make better use of available glass and silicon than the pure hierarchical model IETF CIDR gave us. this sounds like a bad idea since it would either mean a global swamp (everybody's /56 in the core) or monopoly status for incumbants (everybody's /56 came from the same /32) or mass route pollution (everybody's /56 becomes a metro-area cutout). but what if multihoming was automatic and universal and robust? could a metro or neighborhood get unrouteable / non-global IPv6 space for an ISO-L2 overlay made up of a hairball of private wireless, private wire, private fiber, and automatically use those addresses when talking to reachable endpoints? (this would require something better than RIPv2, so don't try it at home today!) or what if a metropolitan connectivity authority wanted to get an IPv6 block for all of its FTTH and mobile/wireless endpoints, and rather than buying transit for this block, they set up a market of cooperating backbone operators and consumers, doing IP-in-IP to deliver global reachability? (this is like what some 802 networks do today but wide area bridging does not scale well.) i'm not proposing either of these, not exactly. i'm saying there ought to be room in the RIR allocation policy framework for addressing models that are not dreamt of by those who love swamps and those who fear swamps. -- Paul Vixie KI6YSY From bmanning at vacation.karoshi.com Sun May 31 16:28:11 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 31 May 2009 20:28:11 +0000 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: References: <4A1FFBE5.20807@arin.net> <4A200639.4030209@rollernet.us> <20090529160246.GA23729@gweep.net> <20090531160653.GA1226@jeeves.rigozsaurus.com> Message-ID: <20090531202811.GA4943@vacation.karoshi.com.> On Sun, May 31, 2009 at 07:29:14PM +0000, Paul Vixie wrote: > tvest at pch.net (Tom Vest) writes: > > > If I remember correctly, creating a swamp only serves to constantly > > remind those who are stuck with it afterward that swamp creation was / is > > a very bad idea. Besides, if you have an idea of where/how one might > > build a more "solid foundation", persuading us now, up front might be a > > more effective way of bringing people around than intentionally degrading > > the only "ground" that's currently apparent. > > there are more than two visions (pure hierarchy and pure swamp). for example: > > neighborhood or metro-area mesh networking where local cheap highspeed ISO-L2 > is used to glue geographies together in a way that no telco or backbone net > is involved... would make better use of available glass and silicon than the > pure hierarchical model IETF CIDR gave us. this sounds like a bad idea since > it would either mean a global swamp (everybody's /56 in the core) or monopoly > status for incumbants (everybody's /56 came from the same /32) or mass route > pollution (everybody's /56 becomes a metro-area cutout). > > but what if multihoming was automatic and universal and robust? could a metro > or neighborhood get unrouteable / non-global IPv6 space for an ISO-L2 overlay > made up of a hairball of private wireless, private wire, private fiber, and > automatically use those addresses when talking to reachable endpoints? (this > would require something better than RIPv2, so don't try it at home today!) > > or what if a metropolitan connectivity authority wanted to get an IPv6 block > for all of its FTTH and mobile/wireless endpoints, and rather than buying > transit for this block, they set up a market of cooperating backbone operators > and consumers, doing IP-in-IP to deliver global reachability? (this is like > what some 802 networks do today but wide area bridging does not scale well.) > > i'm not proposing either of these, not exactly. i'm saying there ought to > be room in the RIR allocation policy framework for addressing models that > are not dreamt of by those who love swamps and those who fear swamps. > -- > Paul Vixie > KI6YSY indeed there should be. --bill From tvest at pch.net Sun May 31 17:40:20 2009 From: tvest at pch.net (Tom Vest) Date: Sun, 31 May 2009 17:40:20 -0400 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: References: <4A1FFBE5.20807@arin.net> <4A200639.4030209@rollernet.us> <20090529160246.GA23729@gweep.net> <20090531160653.GA1226@jeeves.rigozsaurus.com> Message-ID: <96AE907F-8704-42F1-A9A6-19A142AE3AC8@pch.net> On May 31, 2009, at 3:29 PM, Paul Vixie wrote: > tvest at pch.net (Tom Vest) writes: > >> If I remember correctly, creating a swamp only serves to constantly >> remind those who are stuck with it afterward that swamp creation >> was / is >> a very bad idea. Besides, if you have an idea of where/how one might >> build a more "solid foundation", persuading us now, up front might >> be a >> more effective way of bringing people around than intentionally >> degrading >> the only "ground" that's currently apparent. > > there are more than two visions (pure hierarchy and pure swamp). > for example: > > neighborhood or metro-area mesh networking where local cheap > highspeed ISO-L2 > is used to glue geographies together in a way that no telco or > backbone net > is involved... would make better use of available glass and silicon > than the > pure hierarchical model IETF CIDR gave us. this sounds like a bad > idea since > it would either mean a global swamp (everybody's /56 in the core) or > monopoly > status for incumbants (everybody's /56 came from the same /32) or > mass route > pollution (everybody's /56 becomes a metro-area cutout). > > but what if multihoming was automatic and universal and robust? > could a metro > or neighborhood get unrouteable / non-global IPv6 space for an ISO- > L2 overlay > made up of a hairball of private wireless, private wire, private > fiber, and > automatically use those addresses when talking to reachable > endpoints? (this > would require something better than RIPv2, so don't try it at home > today!) > > or what if a metropolitan connectivity authority wanted to get an > IPv6 block > for all of its FTTH and mobile/wireless endpoints, and rather than > buying > transit for this block, they set up a market of cooperating backbone > operators > and consumers, doing IP-in-IP to deliver global reachability? (this > is like > what some 802 networks do today but wide area bridging does not > scale well.) > > i'm not proposing either of these, not exactly. i'm saying there > ought to > be room in the RIR allocation policy framework for addressing models > that > are not dreamt of by those who love swamps and those who fear swamps. > -- > Paul Vixie > KI6YSY > __________ Hi Paul, I think all of these ideas sound great -- esp. the automatic/universal/ robust multihoming. Certainly the two scenarios sound like they might provide solid "justification" for the allocation of unique IP address resources, given the previous condition (and assuming that the aspiring metro/neighborhood operator is capable of providing some other evidence of their capability to use the IPv6 addresses in pursuit of the stated goals). I am all for creating the conditions necessary to enable future innovation -- including esp. the condition of open, non-discriminatory, non-adversarial access to "useful" IP addresses for those who can put them to (potentially) good use. However, I also feel strongly that the duty of "stewardship" requires that any relaxation of current allocation policies to accommodate hypothetical future innovations should be bounded, at least, by some consideration of the most obvious hypothetical future risks. I'm not 100% on IETF history, but I have a sense that the abandonment of backwards compatibility as a requirement for what became IPv6 was justified in part by similar arguments, i.e., that encumbering NGN addressing with the requirement of consistency/interoperability with the known limitations of addressing and routing c. 1992 would entail giving up too many lines of anticipated/hypothetical future innovation. In hindsight, I think it's probably safe to say that that was a net unfortunate choice. FWIW, I thought that Bill's "mostly open" counter-proposal was interesting, enough at least to send him some clarifying questions off- list. Bottom line: I think that allocation policies should add zero additional barrier to any credible, aspiring IPv6-based service implementer. Future scalability risks should be given all due consideration, but they should not impede credible efforts to deploy now. However, in my mind "needs based" allocation (eligibility + quantity) rules fully satisfy this test: for anyone who actually possesses the other requisite inputs and plan to deploy service, merely demonstrating that fact represents no real additional impediment. TV From randy at psg.com Sun May 31 18:10:02 2009 From: randy at psg.com (Randy Bush) Date: Mon, 01 Jun 2009 07:10:02 +0900 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090531160653.GA1226@jeeves.rigozsaurus.com> References: <4A1FFBE5.20807@arin.net> <4A200639.4030209@rollernet.us> <20090529160246.GA23729@gweep.net> <20090531160653.GA1226@jeeves.rigozsaurus.com> Message-ID: > It better reflects the reality of the meshy global Internet where > aggregated trunk, backbone-only providers are a rare and dying breed. what are we smoking here? they are rare because they own the bleeding internet and there are not a lot of them. randy From jmaimon at chl.com Sun May 31 20:49:21 2009 From: jmaimon at chl.com (Joe Maimon) Date: Sun, 31 May 2009 20:49:21 -0400 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> Message-ID: <4A232591.1070907@chl.com> William Herrin wrote: > So here's a crazy plan: > > A. The first IPv6 allocation from ARIN is always a /48. To justify it, > you need to be multihomed. There are no other qualifications. The /48 > will be allocated from a pool from which only /48's are allocated. > > B. The second IPv6 allocation from ARIN is always a /32. To justify it > you need to demonstrate that you've efficiently used the /48 for some > reasonable definition of efficient, that you've implemented SWIP or > RWHOIS for your downstream assignments and that you will run out of > space in the /48 within one year. The /32 will be allocated from a > pool reserved for allocating /32's. > > C. The third IPv6 allocation from ARIN is always a /24. To justify it Renumbering is something everyone should desire to avoid, regardless of how easy it is, and I would oppose any policy promoting that activity, so please clarify whether you were intending for renumbering to occur or not. The only sane method for general prefix filtering is per prefix size per identifiable pool. And there should be only a few of these pools. So please put a nail into the mantra of registries not being involved in routing. It becomes rocket science and/or mind numbing effort to the point of impossibility to try to prefix filter the internet without some sort of clear guidelines and easy to follow heuristics. And they need to stop changing with the seasons. I suppose secured bgp will fix all that. I bet registries will have even more to do with routing under that system. Put it to bed. Its good philosophy but bad practice. All effort should be made to limit the prefixes an ASN has to advertise for all its needs. That means to me erring on the side of large and sparse allocation techniques. Joe From jmaimon at chl.com Sun May 31 20:49:25 2009 From: jmaimon at chl.com (Joe Maimon) Date: Sun, 31 May 2009 20:49:25 -0400 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> <20090531001700.GE6380@garry-thinkpad.arpnetworks.com> Message-ID: <4A232595.3050905@chl.com> Paul Vixie wrote: >> If they were only allowed to get a /48 to begin with, they couldn't >> assign any further /48's. > > Not everything that IETF has written about address allocation has worked > out in practice. (For example, classful addressing, or experimental or > multicast addressing.) It's reasonable for the RIR's to evaluate the > "ground truth" when composing our allocation policies, even though it's > also quite important to read everything the IETF has to say on the topic. As far as I can see internal assignation policy hinges on utilization density justification. If it is per /64, then you should only assign that. If it is /48, assigning less is just going to make it harder than it would otherwise be to get your /32 expanded to /(32-x) In other words, if saying that I have 30k customers in my /32 and I am at 50% utilization passes the smell test, then it is in my best interests to do so modulo block fees. Speaking of fees, according to current fee schedule, /48 per customer is $0.034 for the small guy (at %100 utilization of /32), $0.0005 for the XXlarge assuming /22. 68x between /32 and /22, which is about the same for ipv4 between /21 and /11. Of course, right now it seems that v6 cant be given away fast enough, except to people who really want to use it. The latter needs to be fixed. Joe From stephen at sprunk.org Sun May 31 21:06:04 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 31 May 2009 20:06:04 -0500 Subject: [arin-ppml] Policy Proposal: Open Access To IPv6 In-Reply-To: <20090530225927.GC22982@vacation.karoshi.com.> References: <4A1FFBE5.20807@arin.net> <20090529174253.GB94380@ussenterprise.ufp.org> <24c86a5f0905291049x11f281ebw270d04d55e751da6@mail.gmail.com> <20090530190622.GC27636@garry-thinkpad.arpnetworks.com> <20090530195050.GA21698@vacation.karoshi.com.> <20090530212253.GA2827@garry-thinkpad.arpnetworks.com> <20090530213008.GB22371@vacation.karoshi.com.> <9E2B2273-4394-424B-99CE-1C01AE984F5F@arpnetworks.com> <20090530225927.GC22982@vacation.karoshi.com.> Message-ID: <4A23297C.9040706@sprunk.org> bmanning at vacation.karoshi.com wrote: > On Sat, May 30, 2009 at 02:42:44PM -0700, Garry Dolley wrote: > >> On May 30, 2009, at 2:30 PM, bmanning at vacation.karoshi.com wrote: >> >>> On Sat, May 30, 2009 at 02:22:53PM -0700, Garry Dolley wrote: >>> >>>> If uniqueness, and not connectivity, is the concern, look into ULAs >>>> [1]. >>>> You can use them now, without ever contacting ARIN, or any IRR. >>>> >>>> >>>> 1. RFC 4193, "Unique Local IPv6 Unicast Addresses" >>>> http://tools.ietf.org/html/rfc4193 >>>> >>> sorry - ULA does not assure uniqueness. only that >>> statistical probability. >>> >> Correct, but given the use cases mentioned, statistically probable >> uniqueness is sufficient. >> > > Not for me. > If RFC 4193 does not provide sufficient uniqueness for your needs, you should be able to get a /48 from ARIN under NRPM 6.5.8, passed several years ago. There is no requirement for connectedness per NRPM 4.3.5. If the org doesn't qualify for a /48 per NRPM 4.3.2 (as required by 6.5.8.1.2), I have a serious problem with letting them call themselves an ISP/LIR and getting 65,536 times the address space. 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 gdolley at arpnetworks.com Sun May 31 21:17:33 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sun, 31 May 2009 18:17:33 -0700 Subject: [arin-ppml] Number of routes, IPv6 vrs IPv4. In-Reply-To: <20090531161152.GB51278@ussenterprise.ufp.org> References: <20090531161152.GB51278@ussenterprise.ufp.org> Message-ID: <20090601011733.GB13710@garry-thinkpad.arpnetworks.com> On Sun, May 31, 2009 at 12:11:52PM -0400, Leo Bicknell wrote: > > [snip] > So the critical items going forward to me are: > > - Remove the totally arbitrary 200 site requirement. There are plenty > of thriving ISP's with less than 200 customers. Colo based > companies come to mind, your 100,000 sq ft data center may have 10, > 10,000 sq ft customers, and 500,000 machines in the building. > > - Make sure everyone with an ASN can easily get a right sized IPv6 > allocation. Let's make good on the idea of "one route per ASN". > Let's insure everyone in the game can get space easily on that > basis. > > - Come up with sensible requirements for new entrants. "200 > customers" is not a sensible requirement. Starting someone off > with a /32 and then not talking to them is not a sensible way > of doing business. RFC 2050, and IPv4 both had the notion of > "slow start", which fit with the idea of needs based allocations. > New entrants came back at 3, 6, and 12 months, and then yearly. > If they were allocating "wrong" it was caught quickly, and fixed. > We need some mechanism to talk to new entrants more often than > every 10 years, make sure they are following the community > rules, and clean up messes before they have collected for 10 years. > > I don't think we have proposal(s) that get this right on the table yet. Agreed. Very well written post. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sun May 31 21:54:31 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sun, 31 May 2009 18:54:31 -0700 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: <4A22CF86.4040304@kl.net> References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> <6eb799ab0905302219x5b88055m7e17855b935eec3c@mail.gmail.com> <4A22CF86.4040304@kl.net> Message-ID: <20090601015431.GC13710@garry-thinkpad.arpnetworks.com> On Sun, May 31, 2009 at 02:42:14PM -0400, Kevin Loch wrote: > James Hess wrote: >> Why allocate /32s from a pool reserved for /32s? >> It would perhaps make more sense, as a matter of policy, that a >> special allocation strategy be utilized, that the /48s, /32s, and >> /24s are allocated from just one pool. >> And that they be allocated in a manner that maximizes the duration >> during which the 2nd/3rd allocation request would be contiguous with >> the earlier allocation. > > This is called "sparse allocation" method and is what APNIC uses today. It > was one of the the justifications for giving each RIR blocks of /12 > instead of /23. I would like to know why ARIN is not using this method. I thought ARIN *was* using this method. Or at least keeping surrounding upper blocks free when allocating /32's. I believe this is the "leftmost" method per RFC 3531 [1], but I could be wrong on that, RFC 3531 goes over my head a lot. I did WHOIS lookups on some /32's surrounding my own and found the following: 2607:f2e0::/32 - allocated 2607:f2e1::/32 2607:f2e2::/32 2607:f2e3::/32 2607:f2e4::/32 2607:f2e5::/32 2607:f2e6::/32 2607:f2e7::/32 2607:f2e8::/32 - allocated 2607:f2e9::/32 2607:f2ea::/32 2607:f2eb::/32 2607:f2ec::/32 2607:f2ed::/32 2607:f2ee::/32 2607:f2ef::/32 2607:f2f0::/32 - allocated 2607:f2f1::/32 2607:f2f2::/32 2607:f2f3::/32 2607:f2f4::/32 2607:f2f5::/32 2607:f2f6::/32 2607:f2f7::/32 2607:f2f8::/32 - allocated 2607:f2f9::/32 2607:f2fa::/32 2607:f2fb::/32 2607:f2fc::/32 2607:f2fd::/32 2607:f2fe::/32 2607:f2ff::/32 2607:f300::/32 - allocated 2607:f301::/32 2607:f302::/32 2607:f303::/32 2607:f304::/32 2607:f305::/32 2607:f306::/32 2607:f307::/32 2607:f307::/32 - allocated 2607:f308::/32 2607:f309::/32 2607:f30a::/32 2607:f30b::/32 2607:f30c::/32 2607:f30d::/32 2607:f30e::/32 2607:f30f::/32 The /32's not marked "allocated" don't have a WHOIS entry, so I assume they are available. Therefore, each /32 can potentially grow into a /29 (I *think* my math is right on that, 3 more bits gives 7 additional /32's beyond the initial allocation, for a total of 8 /32's). Is this what is meant by "sparse allocation"? Additionally, This gives room for each /32 holder to grow by simply a subnet mask change, thereby allowing (although not requiring) their route announcement(s) to not necessarily grow linearly with the addition of IP space. I know this isn't news to anyone, but seeing how allocation practices can have such an immediate effect on the number of route announcements, I don't see how discussions about allocation policies can be completely separated from routing. As Joe Mainmon recently put it, "please put a nail into the mantra of registries not being involved in routing." 1. RFC 3531, "A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block" http://tools.ietf.org/html/rfc3531 -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Sun May 31 21:56:59 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sun, 31 May 2009 18:56:59 -0700 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: <4A232591.1070907@chl.com> References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> <4A232591.1070907@chl.com> Message-ID: <20090601015659.GD13710@garry-thinkpad.arpnetworks.com> On Sun, May 31, 2009 at 08:49:21PM -0400, Joe Maimon wrote: > So please put a nail into the mantra of registries not being involved in > routing. It becomes rocket science and/or mind numbing effort to the point > of impossibility to try to prefix filter the internet without some sort of > clear guidelines and easy to follow heuristics. And they need to stop > changing with the seasons. I second this. While some may argue, "no one is making you accept my route", it is really impractical to try to police all routes and find which are 'worthy' We need clear guidelines and easy to follow heuristics, exactly. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From stephen at sprunk.org Sun May 31 22:48:47 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 31 May 2009 21:48:47 -0500 Subject: [arin-ppml] A modest proposal for IPv6 address allocations In-Reply-To: <20090601015431.GC13710@garry-thinkpad.arpnetworks.com> References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com> <6eb799ab0905302219x5b88055m7e17855b935eec3c@mail.gmail.com> <4A22CF86.4040304@kl.net> <20090601015431.GC13710@garry-thinkpad.arpnetworks.com> Message-ID: <4A23418F.2040704@sprunk.org> Garry Dolley wrote: > On Sun, May 31, 2009 at 02:42:14PM -0400, Kevin Loch wrote: > >> This is called "sparse allocation" method and is what APNIC uses today. It was one of the the justifications for giving each RIR blocks of /12 instead of /23. I would like to know why ARIN is not using this method. >> > > I thought ARIN *was* using this method. Or at least keeping surrounding upper blocks free when allocating /32's. I believe this is the "leftmost" method per RFC 3531 [1], but I could be wrong on that, RFC 3531 goes over my head a lot. > > I did WHOIS lookups on some /32's surrounding my own and found the following: > > 2607:f2e0::/32 - allocated > 2607:f2e1::/32 > 2607:f2e2::/32 > 2607:f2e3::/32 > 2607:f2e4::/32 > 2607:f2e5::/32 > 2607:f2e6::/32 > 2607:f2e7::/32 > > 2607:f2e8::/32 - allocated > ... > Therefore, each /32 can potentially grow into a /29 (I *think* my math is right on that, 3 more bits gives 7 additional /32's beyond the initial allocation, for a total of 8 /32's). > > Is this what is meant by "sparse allocation"? > That is somewhat sparse since it reserves space for limited future growth, but the "bisection method" is what folks are usually referring to. If that's what ARIN were doing, allocations would have gone like this: G # | | 0 0 |X | 1 1 |X X | 2 2 |X X X X | 3 4 |X X X X X X X X | 4 8 |X X X X X X X X X X X X X X X X | 5 16 |X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X | 6 32 |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX| 7 64 ... and so on through 21 generations (/12 -> /32). Bisecting each reservation, as above, allows the maximum potential for future growth instead of reserving a fixed-size block. The bisection method doesn't reach a reservation of /29 until the 18th generation, which can accommodate up to 131,072 /29 reservations in a /12 -- though some folks in the earlier generations will have grown past /29 and thus have stolen slots from later generations. Using ARIN's current method, nobody getting a /32* can grow past /29 without getting a second block. Bisection allows anyone to grow their block up to the reservation size of the current generation. Effectively, ARIN is _starting_ in the 18th generation. (* IIRC, folks requesting an initial allocation shorter than /32 get them from a different block with different reservation rules.) 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 -------------- An HTML attachment was scrubbed... URL: -------------- 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: