From marla.azinger at frontiercorp.com Mon Apr 2 10:47:20 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Mon, 2 Apr 2007 10:47:20 -0400 Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4AddressCountdown Message-ID: <454810F09B5AA04E9D78D13A5C39028A023EF6E3@nyrofcs2ke2k01.corp.pvt> I strongly disagree -----Original Message----- From: Ted Mittelstaedt [mailto:tedm at ipinc.net] Sent: Friday, March 30, 2007 8:23 PM To: Azinger, Marla; Jim Weyand; ppml at arin.net Subject: RE: [ppml] Summary of Trial Balloons for Dealing with IPv4AddressCountdown Marla, the evolution thing is already listed, it is item #2 As for reserve space, that would only be relevant if the Internet were to not ever switch over to IPv6. Once we hit the 80-90th percentile of sites on the Internet reachable via IPv6, your going to see a lot of people beginning to block out ALL IPv4 route advertisements merely to save space in their routing tables. I do not see how on an Internet that is IPv6, that you could have any support for a legacy block of routed IPv4. It would become a ghetto that would be used by spammers and all manner of criminals to launch network attacks. No, the sites that feel they cannot switch over to IPv6 will simply have to disconnect once most of the rest of the world is IPv6. Personally I might not mind drivng a car in the US that has a 150 inch width but the rest of the world isn't going to widen it's roads for me. Thus it will be for the sites that want to stay IPv4 forever. Ted -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Azinger, Marla Sent: Friday, March 30, 2007 3:22 PM To: Jim Weyand; ppml at arin.net Subject: Re: [ppml] Summary of Trial Balloons for Dealing with IPv4AddressCountdown Jim- Thank you for taking time on this issue and trying to organize the thoughts a bit. Right now I view alot of the sujbect matter that makes up this issue as being resolved by evolution. That said there is one thing on your list below that we could write policy for and one thing that is not on your list that needs to be discussed and possibly policy written for. The one thing that you dont have below that I think does need to be answered by our community is...should we have a reserve of IPv4 space? If yes, who/what would qualify for the reserved address space? Are there truely entities that will never be able to transition to IPv4? Who can do the research to create a list of valid qualifications? The item on your list below that could use policy is Recycling IPv4 addresses after we have ran out. How is the RIR to handle this? Do they put them on a wait list? Is the wait list first come first serve? Is it prioritized somehow? Or if we voted to have a reserve are the returned IPv4 addresses added to the reserve and all that dont qualify under reserve standards are told switch to IPv6? Ok. That is my two cents. Thank you for your time Marla Azinger Frontier Communications [Azinger, Marla] -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Jim Weyand Sent: Friday, March 30, 2007 2:35 PM To: ppml at arin.net Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4 AddressCountdown It seems like it is time to start the relatively hard work of actually developing alternative policy proposals to deal with the IPv4 Address Exhaustion Issue. It is too late to prepare proposals for the April meeting but we have about 5 months before the cutoff for the October meeting. I have never written a proposal to any of the governing bodies but my guess it will take at least that long to: gather a group of like-minded individuals; negotiate the details of what to propose; write the proposal; seek feedback; rewrite the proposal; etc, etc until the proposal is either accepted or made irrelevant by another proposal. I find myself struggling with how to convert the suggestions and comments on this list into actual policy proposals. I think it is useful at this point to list the different trial balloons and proposals that have been suggested and discussed regarding IPv4 address exhaustion. If you have a favorite that I have missed, send it to me privately and I will send out a revised summary in a week or so. 1) Policy Proposal 2007-12: IPv4 Countdown Policy Proposal - I believe this is the only proposal that can be voted on at the upcoming meeting in April. The full text can be found at: http://www.arin.net/policy/proposals/2007_12.html. This proposal will, "Set the date for termination of (IPv4) allocations and the date of announcement". This proposal specifically does not address IP address recycling except to say that, "Recovery of unused address space should be discussed separately." 2) An informal proposal to not make any changes to current policy until absolutely necessary 3) An informal proposal to encourage address recycling by increasing ARIN dues 4) Several similar informal proposals to encourage recycling by empowering ARIN to more actively police the use of IPv4 addresses by various means 5) An informal proposal to change the nature of assigned IPv4 addresses to something similar to real property 6) An informal proposal to ask holders of unused address IPv4 addresses to voluntarily return the addresses 7) Several variants of informal proposals to start assigning IPv6 space with IPv4 8) An informal proposal to get endusers to demand access to IPv6 networks by creating a media storm similar to Y2K. It is time to make up your mind, roll up your sleeves and get to work. The current policies for dealing with IPv4 Addresses are not causing a crisis... yet. It is however an urgent issue and extremely important. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlw+arin at tellme.com Mon Apr 2 10:57:42 2007 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 2 Apr 2007 07:57:42 -0700 Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4AddressCountdown In-Reply-To: References: <454810F09B5AA04E9D78D13A5C39028A023EF6DD@nyrofcs2ke2k01.corp.pvt> Message-ID: <20070402145742.GY24197@shell01.corp.tellme.com> Assuming there's a decent 6-to-4 infrastructure in place, why would anyone ever want to leave v4? I don't see it turning into a ghetto for a very long time. The installed base is very large, and it will definitely be a long time before even half of the fortune 500 are off of IPv4. Sorry, but the crystal ball I have gets *really* fuzzy at 20-30 years out, and there's no way to convince me that yours works any better. -David On Fri, Mar 30, 2007 at 08:23:06PM -0700, Ted Mittelstaedt wrote: > As for reserve space, that would only be relevant if the Internet were to > not ever switch > over to IPv6. Once we hit the 80-90th percentile of sites on the Internet > reachable via > IPv6, your going to see a lot of people beginning to block out ALL IPv4 > route advertisements > merely to save space in their routing tables. > > I do not see how on an Internet that is IPv6, that you could have any > support for > a legacy block of routed IPv4. It would become a ghetto that would be used > by spammers and all manner of criminals to launch network attacks. No, the > sites that feel they cannot switch over to IPv6 will simply have to > disconnect > once most of the rest of the world is IPv6. > > Personally I might not mind drivng a car in the US that has a 150 inch width > but > the rest of the world isn't going to widen it's roads for me. Thus it will > be for the > sites that want to stay IPv4 forever. > > Ted > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Azinger, Marla > Sent: Friday, March 30, 2007 3:22 PM > To: Jim Weyand; ppml at arin.net > Subject: Re: [ppml] Summary of Trial Balloons for Dealing with > IPv4AddressCountdown > > > Jim- Thank you for taking time on this issue and trying to organize the > thoughts a bit. > > Right now I view alot of the sujbect matter that makes up this issue as > being resolved by evolution. That said there is one thing on your list > below that we could write policy for and one thing that is not on your list > that needs to be discussed and possibly policy written for. > > The one thing that you dont have below that I think does need to be > answered by our community is...should we have a reserve of IPv4 space? If > yes, who/what would qualify for the reserved address space? Are there > truely entities that will never be able to transition to IPv4? Who can do > the research to create a list of valid qualifications? > > The item on your list below that could use policy is Recycling IPv4 > addresses after we have ran out. How is the RIR to handle this? Do they > put them on a wait list? Is the wait list first come first serve? Is it > prioritized somehow? Or if we voted to have a reserve are the returned IPv4 > addresses added to the reserve and all that dont qualify under reserve > standards are told switch to IPv6? > > Ok. That is my two cents. > Thank you for your time > Marla Azinger > Frontier Communications > > [Azinger, Marla] > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Jim > Weyand > Sent: Friday, March 30, 2007 2:35 PM > To: ppml at arin.net > Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4 > AddressCountdown > > > It seems like it is time to start the relatively hard work of actually > developing alternative policy proposals to deal with the IPv4 Address > Exhaustion Issue. It is too late to prepare proposals for the April meeting > but we have about 5 months before the cutoff for the October meeting. I > have never written a proposal to any of the governing bodies but my guess it > will take at least that long to: gather a group of like-minded individuals; > negotiate the details of what to propose; write the proposal; seek feedback; > rewrite the proposal; etc, etc until the proposal is either accepted or made > irrelevant by another proposal. > > > > I find myself struggling with how to convert the suggestions and > comments on this list into actual policy proposals. > > > > I think it is useful at this point to list the different trial balloons > and proposals that have been suggested and discussed regarding IPv4 address > exhaustion. If you have a favorite that I have missed, send it to me > privately and I will send out a revised summary in a week or so. > > > > 1) Policy Proposal 2007-12: IPv4 Countdown Policy Proposal ? I > believe this is the only proposal that can be voted on at the upcoming > meeting in April. The full text can be found at: > http://www.arin.net/policy/proposals/2007_12.html. This proposal will, ?Set > the date for termination of (IPv4) allocations and the date of announcement? > . This proposal specifically does not address IP address recycling except > to say that, ?Recovery of unused address space should be discussed > separately.? > > 2) An informal proposal to not make any changes to current policy > until absolutely necessary > > 3) An informal proposal to encourage address recycling by > increasing ARIN dues > > 4) Several similar informal proposals to encourage recycling by > empowering ARIN to more actively police the use of IPv4 addresses by various > means > > 5) An informal proposal to change the nature of assigned IPv4 > addresses to something similar to real property > > 6) An informal proposal to ask holders of unused address IPv4 > addresses to voluntarily return the addresses > > 7) Several variants of informal proposals to start assigning IPv6 > space with IPv4 > > 8) An informal proposal to get endusers to demand access to IPv6 > networks by creating a media storm similar to Y2K. > > > > It is time to make up your mind, roll up your sleeves and get to work. > The current policies for dealing with IPv4 Addresses are not causing a > crisis? yet. It is however an urgent issue and extremely important. > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From Yves.Poppe at vsnlinternational.com Mon Apr 2 11:38:01 2007 From: Yves.Poppe at vsnlinternational.com (Yves Poppe) Date: Mon, 2 Apr 2007 11:38:01 -0400 Subject: [ppml] Summary of Trial Balloons for Dealing withIPv4AddressCountdown In-Reply-To: <20070402145742.GY24197@shell01.corp.tellme.com> Message-ID: I would suggest we try to think outside the v4 vs v6 plane; practically nobody on the user side cares about IP versions; only applications count. The tipping point for IPv6 will will be a critical mass of end devices and applications turning on IPv6 by default. As part of the product replacement cycle IPv4 will suddenly start to fade away at an accelerating rate and few outside our little community will have noticed or even care. My guess for the tipping point? 2010 And while we philosophize, the countdown to the last routable IPv4 address continues. IPv6-phobics and diehard legacy product affionados will always be able to take refuge in the interNAT. Maybe they deserve a reserve space. Yves Poppe Director Business Development IP Services VSNL International -----Message d'origine----- De : ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]De la part de David Williamson Envoy? : Monday, April 02, 2007 10:58 AM ? : Ted Mittelstaedt Cc : ppml at arin.net Objet : Re: [ppml] Summary of Trial Balloons for Dealing withIPv4AddressCountdown Assuming there's a decent 6-to-4 infrastructure in place, why would anyone ever want to leave v4? I don't see it turning into a ghetto for a very long time. The installed base is very large, and it will definitely be a long time before even half of the fortune 500 are off of IPv4. Sorry, but the crystal ball I have gets *really* fuzzy at 20-30 years out, and there's no way to convince me that yours works any better. -David On Fri, Mar 30, 2007 at 08:23:06PM -0700, Ted Mittelstaedt wrote: > As for reserve space, that would only be relevant if the Internet were to > not ever switch > over to IPv6. Once we hit the 80-90th percentile of sites on the Internet > reachable via > IPv6, your going to see a lot of people beginning to block out ALL IPv4 > route advertisements > merely to save space in their routing tables. > > I do not see how on an Internet that is IPv6, that you could have any > support for > a legacy block of routed IPv4. It would become a ghetto that would be used > by spammers and all manner of criminals to launch network attacks. No, the > sites that feel they cannot switch over to IPv6 will simply have to > disconnect > once most of the rest of the world is IPv6. > > Personally I might not mind drivng a car in the US that has a 150 inch width > but > the rest of the world isn't going to widen it's roads for me. Thus it will > be for the > sites that want to stay IPv4 forever. > > Ted > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Azinger, Marla > Sent: Friday, March 30, 2007 3:22 PM > To: Jim Weyand; ppml at arin.net > Subject: Re: [ppml] Summary of Trial Balloons for Dealing with > IPv4AddressCountdown > > > Jim- Thank you for taking time on this issue and trying to organize the > thoughts a bit. > > Right now I view alot of the sujbect matter that makes up this issue as > being resolved by evolution. That said there is one thing on your list > below that we could write policy for and one thing that is not on your list > that needs to be discussed and possibly policy written for. > > The one thing that you dont have below that I think does need to be > answered by our community is...should we have a reserve of IPv4 space? If > yes, who/what would qualify for the reserved address space? Are there > truely entities that will never be able to transition to IPv4? Who can do > the research to create a list of valid qualifications? > > The item on your list below that could use policy is Recycling IPv4 > addresses after we have ran out. How is the RIR to handle this? Do they > put them on a wait list? Is the wait list first come first serve? Is it > prioritized somehow? Or if we voted to have a reserve are the returned IPv4 > addresses added to the reserve and all that dont qualify under reserve > standards are told switch to IPv6? > > Ok. That is my two cents. > Thank you for your time > Marla Azinger > Frontier Communications > > [Azinger, Marla] > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Jim > Weyand > Sent: Friday, March 30, 2007 2:35 PM > To: ppml at arin.net > Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4 > AddressCountdown > > > It seems like it is time to start the relatively hard work of actually > developing alternative policy proposals to deal with the IPv4 Address > Exhaustion Issue. It is too late to prepare proposals for the April meeting > but we have about 5 months before the cutoff for the October meeting. I > have never written a proposal to any of the governing bodies but my guess it > will take at least that long to: gather a group of like-minded individuals; > negotiate the details of what to propose; write the proposal; seek feedback; > rewrite the proposal; etc, etc until the proposal is either accepted or made > irrelevant by another proposal. > > > > I find myself struggling with how to convert the suggestions and > comments on this list into actual policy proposals. > > > > I think it is useful at this point to list the different trial balloons > and proposals that have been suggested and discussed regarding IPv4 address > exhaustion. If you have a favorite that I have missed, send it to me > privately and I will send out a revised summary in a week or so. > > > > 1) Policy Proposal 2007-12: IPv4 Countdown Policy Proposal - I > believe this is the only proposal that can be voted on at the upcoming > meeting in April. The full text can be found at: > http://www.arin.net/policy/proposals/2007_12.html. This proposal will, "Set > the date for termination of (IPv4) allocations and the date of announcement" > . This proposal specifically does not address IP address recycling except > to say that, "Recovery of unused address space should be discussed > separately." > > 2) An informal proposal to not make any changes to current policy > until absolutely necessary > > 3) An informal proposal to encourage address recycling by > increasing ARIN dues > > 4) Several similar informal proposals to encourage recycling by > empowering ARIN to more actively police the use of IPv4 addresses by various > means > > 5) An informal proposal to change the nature of assigned IPv4 > addresses to something similar to real property > > 6) An informal proposal to ask holders of unused address IPv4 > addresses to voluntarily return the addresses > > 7) Several variants of informal proposals to start assigning IPv6 > space with IPv4 > > 8) An informal proposal to get endusers to demand access to IPv6 > networks by creating a media storm similar to Y2K. > > > > It is time to make up your mind, roll up your sleeves and get to work. > The current policies for dealing with IPv4 Addresses are not causing a > crisis... yet. It is however an urgent issue and extremely important. > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From stephen at sprunk.org Mon Apr 2 12:30:10 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 2 Apr 2007 11:30:10 -0500 Subject: [ppml] Summary of Trial Balloons for Dealing withIPv4AddressCountdown References: <454810F09B5AA04E9D78D13A5C39028A023EF6DD@nyrofcs2ke2k01.corp.pvt> <20070402145742.GY24197@shell01.corp.tellme.com> Message-ID: <00dc01c77544$d8bc8d50$473816ac@atlanta.polycom.com> Thus spake "David Williamson" > Assuming there's a decent 6-to-4 infrastructure in place, ... That's a big assumption. The IETF has failed (some might say deliberately) to provide any mechanism for v6-only hosts to talk to v4-only hosts. Everything assumes v6-capable hosts stuck on a v4 network, with various bits of hackery to make dual-stacking work; there's nothing in place to handle v4-only hosts on a v6-capable network. Eventually vendors will figure this out and provide a solution, but I don't have much hope that vendor enlightenment is imminent based on their (lack of) progress over the last decade. Until customers start refusing to buy gear that isn't v6-capable (and that includes not falling for the old "it'll be in a future software upgrade" line), it's not going to happen. > The installed base is very large, and it will definitely be a long > time before even half of the fortune 500 are off of IPv4. The day they turn off IPv4 isn't as interesting to me as the day they turn on IPv6. I'll probably be dead before the former happens, but there's a fair chance the latter may occur before I retire. > Sorry, but the crystal ball I have gets *really* fuzzy at 20-30 years > out, and there's no way to convince me that yours works any better. Ditto. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From michael.dillon at bt.com Mon Apr 2 13:43:43 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 2 Apr 2007 18:43:43 +0100 Subject: [ppml] Summary of Trial Balloons for DealingwithIPv4AddressCountdown In-Reply-To: <00dc01c77544$d8bc8d50$473816ac@atlanta.polycom.com> Message-ID: > there's nothing in > place to handle > v4-only hosts on a v6-capable network. > > Eventually vendors will figure this out and provide a > solution, but I don't > have much hope that vendor enlightenment is imminent based on > their (lack > of) progress over the last decade. Uhm, did you miss my posting with all the URLs? One was for a company that makes an IPv6 gateway for the edge of an IPv4 network provider. http://www.hexago.com Given that this is where the current market is and will remain until the large providers consider shutting down their IPv4 backbones, why should the vendors offer a box that does the reverse? If you are building a network in compliance with DOD or USG directives on IPv6 and want to leverage IPv4 Internet access instead of fixed WAN links, then the Hexago boxes do the trick. At some point these tricks may well move inside the network provider. In fact, for providers who run an MPLS core, the IETF has a trick called 6MPE that allows them to implement IPv6 services by just configuring a few PE (edge) routers with pure V6. No doubt others will implement v6 tunnels across a v4 core or v4 tunnels across a v6 core or simply use ATM. Like the MAE-East days of the Internet when I sent traffic across the continent in order to get across town, the paths taken by traffic between the v4 and v6 nets will often be strange. But it can be made to work. In fact there are so many ways to make it work that it is a bit of a job just going through them all and figuring out which one to use. If you ask me, the best route is to go to MPLS, then add 6MPE and a few Teredo servers. > The day they turn off IPv4 isn't as interesting to me as the > day they turn > on IPv6. I'll probably be dead before the former happens, > but there's a > fair chance the latter may occur before I retire. IPv6 was turned on years ago. It is in an early exponential growth phase which is why it is almost unnoticeable. But that slow exponential curve will suddenly kick upwards when people least expect it, rather like the IPv4 Internet back in 93, 94, 95... -- Michael Dillon From schiller at uu.net Mon Apr 2 14:48:17 2007 From: schiller at uu.net (Jason Schiller) Date: Mon, 02 Apr 2007 14:48:17 -0400 (EDT) Subject: [ppml] IPv4 wind-down In-Reply-To: <4602e06b.d2.399c.1471@batelnet.bs> Message-ID: On Wed, 21 Mar 2007, Martin Hannigan wrote: > An above ground v4 trade would be helpful. Allowing V4 to be > treated as property, at least for legacy space, would be > required. The economics of that are interesting, and the > outcome predictable. Seems like a smoother transition > than tossing a bomb into the problem like the aforementioned > policy seems > to do, IMHO. > > -M< On Thu, 22 Mar 2007, Geoff Huston wrote: > "interesting" in that "all markets are interesting" or "intersting in > that "this market would be unique in a number of ways, only some of > which are predictable"? > Again its not clear to me what you mean by 'predictable." Yes, in > effect a market for a good prices itself against the cost of > alternatives, and a market in IPv4 may well perceivce NATs and IPv6 > as alternatives and prices within such an IPv4 market may well > reflect the perceived cost (and benefit) of such alternatives. My > question to you is whether this is what you mean by a predictable > outcome, or are you hinting at some other view of the behaviour of > such a market? I have a couple of specific questions about this above ground v4 trade. Lets assume for the moment that the property thing is worked out and also asusme that you can definitively state that a given person has the authority to sell/rent/what ever a partacular block of IP addresses. Lets also assume their is a fair market for IPv4 adresses. 1. Could that person sell/rent/what ever a portion of that network. Say I am offically representing IBM, could I sell 9.9.9.0/24 but keep the rest of the /8 to use for myself... or maybe sell off other /24s at a later date or to a different org? Or would I be required to sell the entire /8? 2. If that person put 9.9.9.0/24 up for auction, could they sell it to the highest bidder? Or would the highest bidder also need to show justified need of that space? In other words does money become the only measure of if the space is justified? On Thu, 22 Mar 2007, Kevin Kargel wrote: > I see a lot of people discussing what each person thinks the rest of the > world should do. How about some discussion about what we each ARE doing > so we can provide some ideas and pro-active community. I know that I > could use some knowledge and help tuning my strategy. [snip] > I have made sure that all hardware is IPv6 capable as I replace it. I > am doing this in a attritious mode and not expending special budget in > the name of IPv6. As most business models amortize network hardware on > a 2-4 year schedule it is still early enough to plan IPv6 in to a > networks future without undue budget strain. If I waited two or three > years to start this hardware transition I am afraid I might find myself > in a crisis situation which would be much more costly. In 2003 we built a separate IPv6 network (AS12702) in Europe. In 2004 we built a seperate IPv6 network (AS284) in North America. To keep costs down both were deployed as a GRE overlay network over the existing IPv4 network (AS702 in Europe and AS701 in NA). IPv6 nodes were co-located with the IPv4 nodes that transported the GRE back-bone links. Customers accessed the network through GRE. After much experience and certification we have recently field tested dual stack IPv4/IPv6 on AS701 in select locations in a 6PE configuration. In the next few weeks we will begin a migration away from AS284. After more certification we expect to migrate to dual-stack IPv4/IPv6 in the core... possibly next year. Normal equipment refresh, and other projects driving edge upgrades will drive growth of IPv6 locations. The problem is that IPv6 is not generating new revenue so you can not justify new investments to support IPv6. As a large ISP there are a couple of factors that affect an IPv6 roll out. First is the requirement that IP forwarding be done in hardware. Software switching 6Mpps is problematic. Thus upgrading the network to support IPv6 is not as simple as a software upgrade on some cisco 7200s. Often we are talking about replacing hardware. Secondly, due to the size of the network, the number of devices, the amount of coordnation, amount of remote hands available, maintence policies, and size of our maintence team, it could take 2-3 years to upgade every node in the network. We like to amortize network hardware on a 5 year cycle. So my time line is a bit different than yours. As for the "crisis situation" at the moment it doesn't look like there is a significatnt amount of new functionality in IPv6 for people to demand it. Likely IPv4 exhaustion will drive IPv6 adoption. Currently people are concerned about IPv4 exhaustion, and are looking for an upstream ISP that is IPv6 capable, has IPv6 experience, and will be there to hold their hand when they migrate. Some people are begining to experiment with IPv6 to make sure their eqipment is capable, to gain experence, and develop their migration plan. Beyond that there are a few IPv6 application developers, and gov't site that require IPv6 transport. So the big question is when will IPv4 exhaustion occur. Geoff's projection is 06/2012, Tony's projection is the end of 2009. Both assume no run on the bank. If you expect all new networks after the IPv4 exhaustion date to be IPv6-only, at some point existing IPv4-only sites may want to talk to some of these IPv6-only sites (rather than lose customers to their competitors) and will be forced into dual stack (or requiring some sort of IPv4/IPv6 proxy). Lets call this IPv6 critical mass. It is hoped at the time of IPv6 critical mass, that all hardware upgrades will be complete, and all elements will be running dual stack. Since this is likely at least 5 years away, and I am at the begining of a refesh cycle this should not be an issue. On the other hand is the concern about the routing table size. If one projects out the size of the current IPv4 Internet table, adds to the the projected size of you internal routes, and derive the expeced number of IPv6 Internet routes (if everyone does dual stack and advertises the same number of more specifics for TE, but discount the extra routes from the assigments of dis-aggregates) and project the number of internal IPv6 routes you end up with a scary number... My projection for 03/2014 if wide spread IPv6 adoption occurs by then is 1.3M IPv4 + IPv6 routes. That is larger than the current FIB limitations of routers I can buy today, so likely my refresh cycle will be artificially shortened. Sorry I am a little late to the thread, but I wanted to read the whole thread before posting. __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. From michael.dillon at bt.com Mon Apr 2 17:03:19 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 2 Apr 2007 22:03:19 +0100 Subject: [ppml] IPv4 wind-down In-Reply-To: Message-ID: > IPv6 Internet routes (if everyone does dual stack and > advertises the same > number of more specifics for TE, but discount the extra > routes from the > assigments of dis-aggregates) and project the number of internal IPv6 > routes you end up with a scary number... My projection for 03/2014 if > wide spread IPv6 adoption occurs by then is 1.3M IPv4 + IPv6 > routes. On the other hand, if ISP X has 30 IPv4 routes and one IPv6 /32, and ISP X also has some magic inside their network to let IPv6 customers get IPv4 traffic, and IPv4 customers get IPv6 traffic, then you can drop all their IPv4 routes, gain 30 routing table slots and still have connectivity to their IPv4 customers. Consider a 6/4 version of hot-potato routing, i.e. send them the traffic on IPv6 and let them sort it out. Multiply this by many ISPs and the routing table numbers don't look so scary. Of course its not quite as simple as that. You have to decide how to route v4 traffic. Maybe maintain a v4 over v6 mesh of tunnels with v4-only BGP mesh? This is where it helps for ISPs to actually start building IPv6 networks in their labs and also build-out some experimental WAN links with v6. --Michael Dillon From iljitsch at muada.com Mon Apr 2 17:52:13 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 2 Apr 2007 23:52:13 +0200 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: <20070322080415.GA24667@tummy.com> References: <20070320233652.GC37431@ussenterprise.ufp.org> <20070322080415.GA24667@tummy.com> Message-ID: <89E1E711-05A4-4D25-B5EC-4390D4EBCE26@muada.com> On 22-mrt-2007, at 9:04, Sean Reifschneider wrote: > I've never tried to reach a service that I couldn't reach because > it only > had a v6 address. My network can handle v6 no problem, but there's > 100% v4 > coverage, as far as I can see, and so there's absolutely no reason > for me > to go through the pain of setting up and maintaining v6. Setting > up v6 > right now would, literally, gain me nothing. (Except future-proofing.) This is very true, and will largely remain true as IPv4 space runs out. People who have IPv4 space today won't have a problem, it's the people who need more address space when there no longer is any who will be in a bind, because at that point, the vast majority of all internet users will still only be reachable over IPv4. This means massive amounts of NAT. This is not the nice, friendly NAT where you have three PCs behind your Linksys DSL router and you get to forward ports so fussy applications like VoIP still work. It will be the kind of NAT where a service provider puts 10, 100 or even 1000 customers behind a single IP address, and the number of usable TCP ports starts being a problem. Forget about port mappings and hence any applications that are more complex than client-server. At that point, those users may want to add IPv6 to their heavily NATed IPv4 so they can run peer-to-peer and server-to-client applications in addition to client-to-server applications. Only at THAT point, it will become interesting for people with enough IPv4 space to also support IPv6 so they can talk to those of us who are behind several layers of NAT. In other words: the running out of IPv4 space is a necessary requisite for wide scale IPv6 adoption. Without it, nothing is going to change. Therefore, any policy that seeks to artifically avoid running out is harmful because it perpetuates an address starvation model. We need the water to boil at some point so the frog jumps out. A few data points: 90% of the IPv4 address space is used up by 10% of the requests, which are done by large ISPs. The last two years we used 170 million addresses per year, but this year so far 57 million addresses, with 1244 million still available, or 5 - 7 years worth (without considering additional increases in the numbers of addresses used per year). > What I need are *USERS* who are on v6 who are trying to reach these > sites. I've been running IPv6 at home for several years. When I vist one of your sites, how do you know that I would prefer to get at them over IPv6? > These are the places we need to be providing incentives to to > switch to v6. > We need to reach a tipping point. There are two ways of going > about that: > One is to try to convert tens of thousands of entities who have > smaller > allocations (like /24s), the other is to go after dozens of > entities that > have larger allocations (like /8s). There are 43 /8s given out to end-users. Reclaiming all of those gives us 3 years extra at the rate we've been burning IPv4 addresses the past quarter. Although that could be useful, it doesn't change the fundamental issue, just the date at which the pain will make itself felt. > I don't think that treating v4 like land, and giving people the > ability to > sell it, is a good way to go. I disagree, for the following reasons, in no particular order: - the selling off of small blocks of IP space will further fragment the routing table and make our routing problems more urgent - demand without supply leads to increasing prices, increasing prices lead to hoarding, we could very well see the number of available addresses go _down_ rather than up - being able to sell addresses for money (or even the possibility of that in the future) will be a strong disincentive for returning address space for current /8 holders - it's unfair that more than 50% of all IPv4 address space is held by US entities which then get to make a lot of money from them, while the developing world holds next to no address space and would have to buy it from richer countries - markets are unpredictable, but a smooth IPv6 transition can only happen in a predictable environment. Without this, people will either transition too slow and run into reachability gaps when they're not on IPv6 fast enough, or too fast and spend more money than necessary From michael.dillon at bt.com Mon Apr 2 18:48:47 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 2 Apr 2007 23:48:47 +0100 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: <89E1E711-05A4-4D25-B5EC-4390D4EBCE26@muada.com> Message-ID: > - it's unfair that more than 50% of all IPv4 address space is > held by > US entities which then get to make a lot of money from them, while > the developing world holds next to no address space and would > have to > buy it from richer countries They don't *HAVE* *TO* buy it. They only have to go to ARIN's whois directory, find a nice block with a US address, and start using it. It will work fine everywhere that people accept their route announcements. Of course that might be limited to one country, or perhaps a handful of neighbors as well, but it will work. That's why a market in IPv4 space will never develop. Once the addresses get scarce enough to be valuable, people will just start using what they need without asking. --Michael Dillon From gih at apnic.net Mon Apr 2 19:08:13 2007 From: gih at apnic.net (Geoff Huston) Date: Tue, 03 Apr 2007 09:08:13 +1000 Subject: [ppml] IPv4 wind-down In-Reply-To: References: <4602e06b.d2.399c.1471@batelnet.bs> Message-ID: <7.0.0.16.2.20070403085355.041b8a88@apnic.net> >I have a couple of specific questions about this above ground v4 >trade. > >Lets assume for the moment that the property thing is worked out and also >asusme that you can definitively state that a given person has the >authority to sell/rent/what ever a partacular block of IP addresses. Lets >also assume their is a fair market for IPv4 adresses. > >1. Could that person sell/rent/what ever a portion of that network. Say I >am offically representing IBM, could I sell 9.9.9.0/24 but keep the rest >of the /8 to use for myself... or maybe sell off other /24s at a later >date or to a different org? Or would I be required to sell the entire /8? When you use terms such as "require" you are assume some artifact of control in such a market. Its difficult to picture where and how such control or regulation may be expressed and under what form of authority, if one looks at this as purely as a monetized international market. On the other hand its likely that some form of regulation will exist in this space, but the who and the how remains pretty open, as well as the authority and enforcement models that are conventionally associated with control structures. Given that level of uncertainty, its tough to then start guessing about the forms of such imposed controls. >2. If that person put 9.9.9.0/24 up for auction, could they sell it to the >highest bidder? Or would the highest bidder also need to show justified >need of that space? In other words does money become the only measure of >if the space is justified? Here the "need to show" becomes questions of "show to whom?" and the consequences to both parties (seller and buyer) of the failure to do so, and the judgement of "need". This appears to lead straight back to the questions of market control raised above. regards, Geoff From lsc at prgmr.com Mon Apr 2 19:09:50 2007 From: lsc at prgmr.com (Luke S. Crawford) Date: Mon, 2 Apr 2007 16:09:50 -0700 (PDT) Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: References: Message-ID: On Mon, 2 Apr 2007, michael.dillon at bt.com wrote: > They don't *HAVE* *TO* buy it. They only have to go to ARIN's whois > directory, find a nice block with a US address, and start using it. It > will work fine everywhere that people accept their route announcements. > Of course that might be limited to one country, or perhaps a handful of > neighbors as well, but it will work. I think the US is the only country where a large number of people would consider a "Internet" that only works within their country to "work" - Even then, we are largely talking about the MySpace demographic. Anyone that uses any but the most popular open-source software is heavily dependent on global connectivity. From michael.dillon at bt.com Mon Apr 2 19:29:47 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 3 Apr 2007 00:29:47 +0100 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: Message-ID: > I think the US is the only country where a large number of > people would > consider a "Internet" that only works within their country to > "work" - Even then, we are largely talking about the MySpace > demographic. Anyone that uses any but the most popular open-source > software is heavily dependent on global connectivity. I disagree. For instance Russia, a country which I am familiar with having travelled there three times. Outside Moscow and St Petersburg, few people speak a foreign language well enough to use it. For those people, if a site isn't in Russian, then it practically does not exist. Of course, there are some business interests that need international connectivity, but please notice, I did NOT suggest that people would give up their existing registered addresses. What you are likely to see in countries like Russia is a two-tier Internet, where businesses and government agencies that need global connectivity continue to use registered addresses, but consumer services, and small business services, expand by borrowing addresses from ARIN's whois. And the same is likely in many countries, like China. Since IP addressing and other "Internet" issues like domain naming, are not government regulated ( or only lightly) it is easy for governments to look the other way when local business start using your address space. In today's world, that kind of action is seen as antisocial, but in a world of IPv4 exhaustion, the view changes. --Michael Dillon From terry.l.davis at boeing.com Mon Apr 2 22:56:01 2007 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Mon, 2 Apr 2007 19:56:01 -0700 Subject: [ppml] Summary of Trial Balloons for Dealing withIPv4AddressCountdown In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A023EF6E3@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A023EF6E3@nyrofcs2ke2k01.corp.pvt> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A0368521E@XCH-NW-8V1.nw.nos.boeing.com> Marla I agree with you. There has to be a policy for at least critical infrastructure if nothing else. The aviation industry especially is going to be stuck dealing with both aircraft and ground infrastructures (you can't force nations or business to change their stack to suite someone else) that are mixed; existing OSI based ATC, just entering IPv4 Airbus 380 and Boeing 787, and our future aircraft that will be IPv6; we probably have somewhere between 20 and 30 years of living in this mixed environment. The ISP's may want to stop handling legacy v4 traffic at some point; but I think government may weigh in here at some point (sure it may cost us..) too. Take care Terry ________________________________ From: Azinger, Marla [mailto:marla.azinger at frontiercorp.com] Sent: Monday, April 02, 2007 7:47 AM To: Ted Mittelstaedt; Jim Weyand; ppml at arin.net Subject: Re: [ppml] Summary of Trial Balloons for Dealing withIPv4AddressCountdown I strongly disagree -----Original Message----- From: Ted Mittelstaedt [mailto:tedm at ipinc.net] Sent: Friday, March 30, 2007 8:23 PM To: Azinger, Marla; Jim Weyand; ppml at arin.net Subject: RE: [ppml] Summary of Trial Balloons for Dealing with IPv4AddressCountdown Marla, the evolution thing is already listed, it is item #2 As for reserve space, that would only be relevant if the Internet were to not ever switch over to IPv6. Once we hit the 80-90th percentile of sites on the Internet reachable via IPv6, your going to see a lot of people beginning to block out ALL IPv4 route advertisements merely to save space in their routing tables. I do not see how on an Internet that is IPv6, that you could have any support for a legacy block of routed IPv4. It would become a ghetto that would be used by spammers and all manner of criminals to launch network attacks. No, the sites that feel they cannot switch over to IPv6 will simply have to disconnect once most of the rest of the world is IPv6. Personally I might not mind drivng a car in the US that has a 150 inch width but the rest of the world isn't going to widen it's roads for me. Thus it will be for the sites that want to stay IPv4 forever. Ted -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Azinger, Marla Sent: Friday, March 30, 2007 3:22 PM To: Jim Weyand; ppml at arin.net Subject: Re: [ppml] Summary of Trial Balloons for Dealing with IPv4AddressCountdown Jim- Thank you for taking time on this issue and trying to organize the thoughts a bit. Right now I view alot of the sujbect matter that makes up this issue as being resolved by evolution. That said there is one thing on your list below that we could write policy for and one thing that is not on your list that needs to be discussed and possibly policy written for. The one thing that you dont have below that I think does need to be answered by our community is...should we have a reserve of IPv4 space? If yes, who/what would qualify for the reserved address space? Are there truely entities that will never be able to transition to IPv4? Who can do the research to create a list of valid qualifications? The item on your list below that could use policy is Recycling IPv4 addresses after we have ran out. How is the RIR to handle this? Do they put them on a wait list? Is the wait list first come first serve? Is it prioritized somehow? Or if we voted to have a reserve are the returned IPv4 addresses added to the reserve and all that dont qualify under reserve standards are told switch to IPv6? Ok. That is my two cents. Thank you for your time Marla Azinger Frontier Communications [Azinger, Marla] -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Jim Weyand Sent: Friday, March 30, 2007 2:35 PM To: ppml at arin.net Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4 AddressCountdown It seems like it is time to start the relatively hard work of actually developing alternative policy proposals to deal with the IPv4 Address Exhaustion Issue. It is too late to prepare proposals for the April meeting but we have about 5 months before the cutoff for the October meeting. I have never written a proposal to any of the governing bodies but my guess it will take at least that long to: gather a group of like-minded individuals; negotiate the details of what to propose; write the proposal; seek feedback; rewrite the proposal; etc, etc until the proposal is either accepted or made irrelevant by another proposal. I find myself struggling with how to convert the suggestions and comments on this list into actual policy proposals. I think it is useful at this point to list the different trial balloons and proposals that have been suggested and discussed regarding IPv4 address exhaustion. If you have a favorite that I have missed, send it to me privately and I will send out a revised summary in a week or so. 1) Policy Proposal 2007-12: IPv4 Countdown Policy Proposal - I believe this is the only proposal that can be voted on at the upcoming meeting in April. The full text can be found at: http://www.arin.net/policy/proposals/2007_12.html. This proposal will, "Set the date for termination of (IPv4) allocations and the date of announcement". This proposal specifically does not address IP address recycling except to say that, "Recovery of unused address space should be discussed separately." 2) An informal proposal to not make any changes to current policy until absolutely necessary 3) An informal proposal to encourage address recycling by increasing ARIN dues 4) Several similar informal proposals to encourage recycling by empowering ARIN to more actively police the use of IPv4 addresses by various means 5) An informal proposal to change the nature of assigned IPv4 addresses to something similar to real property 6) An informal proposal to ask holders of unused address IPv4 addresses to voluntarily return the addresses 7) Several variants of informal proposals to start assigning IPv6 space with IPv4 8) An informal proposal to get endusers to demand access to IPv6 networks by creating a media storm similar to Y2K. It is time to make up your mind, roll up your sleeves and get to work. The current policies for dealing with IPv4 Addresses are not causing a crisis... yet. It is however an urgent issue and extremely important. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel at arneill-py.sacramento.ca.us Mon Apr 2 23:54:48 2007 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 2 Apr 2007 20:54:48 -0700 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: <89E1E711-05A4-4D25-B5EC-4390D4EBCE26@muada.com> References: <20070320233652.GC37431@ussenterprise.ufp.org><20070322080415.GA24667@tummy.com> <89E1E711-05A4-4D25-B5EC-4390D4EBCE26@muada.com> Message-ID: Hi Iljitsch, > Iljitsch van Beijnum wrote: > It will be the kind of NAT where a service provider puts 10, > 100 or even 1000 customers behind a single IP address, and > the number of usable TCP ports starts being a problem. This is not as bad as it appears. I have some customers with 100 to 300 PCs out of a single IP and I never saw the number of simultaneous ports above 1K out of a possible 64K. > Forget about port mappings There are easy solutions: you are customer #3245, ports 32450 to 32459 are NATted to your IP, configure your P2P apps to use these ports. > and hence any applications that are more complex than client-server. As long as 95% of the users are ok with that, there is no problem. What does Joe User care? Email, surfing, P2P, and Skype. The same way applications have been made NAT friendly, they will be made 2xNAT friendly. Specifically, applications that open 50 ports at a time will be pointed out and will either adapt or die, just like apps that can't cross NAT have become confidential. > We need the water to boil at some point so the frog jumps out. I agree, but I project that 10K hosts behind a /28 and possibly /29 NAT pool will cause no major issues, therefore the water is not going to get hot any time soon. Emerging markets in countries that don't have enough IPv4 will not be made of geeks who want their own IP address, and double NAT will remain the solution in a world where not having v4 is not an option. > In other words: the running out of IPv4 space is a > necessary requisite for wide scale IPv6 adoption. > Without it, nothing is going to change. If your goal is IPv6 deployment, I agree. I would point out though that most businesses and users are not IPv6 evangelists, they don't care if IPv6 is adopted, and they will continue to do what they have done so far: go the cheap route, which is heavily NATted v4. > Therefore, any policy that seeks to artifically avoid running out > is harmful because it perpetuates an address starvation model. And any policy that seeks to artificially accelerate the running out is suicide, because it will take all the people that rely on v4 out of their lethargy to oppose it. > - it's unfair that more than 50% of all IPv4 address space > is held by US entities which then get to make a lot of money > from them, while the developing world holds next to no address > space and would have to buy it from richer countries. Making money has never been about being fair. Michel. From iljitsch at muada.com Tue Apr 3 06:42:50 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 3 Apr 2007 12:42:50 +0200 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: References: <20070320233652.GC37431@ussenterprise.ufp.org><20070322080415.GA24667@tummy.com> <89E1E711-05A4-4D25-B5EC-4390D4EBCE26@muada.com> Message-ID: <80918C9D-5099-42AF-9CEF-8A205210C490@muada.com> On 3-apr-2007, at 5:54, Michel Py wrote: > Hi Iljitsch, Hey Michel! IETF meetings aren't the same without you. :-) >> It will be the kind of NAT where a service provider puts 10, >> 100 or even 1000 customers behind a single IP address, and >> the number of usable TCP ports starts being a problem. > This is not as bad as it appears. I have some customers with 100 to > 300 > PCs out of a single IP and I never saw the number of simultaneous > ports > above 1K out of a possible 64K. Isn't TCP TIME_WAIT 240 seconds? That means that you get to set up 64k / 240 = 273 new TCP sessions per second. When browsing the web, you can easily create several new sessions per second for short periods. Depending on the activity of the users, I'm expecting problems to occur somewhere between 100 and 1000 users behind a single IP address. >> and hence any applications that are more complex than client-server. > As long as 95% of the users are ok with that, there is no problem. > What > does Joe User care? Email, surfing, P2P, and Skype. The same way > applications have been made NAT friendly, they will be made 2xNAT > friendly. And then 3x, 4x? At some point, IPv6 will start looking attractive. The simplest way to overcome NAT problems is to get IPv6 through it and have the applications use IPv6. Microsoft is already doing this for some peer-to-peer stuff. >> We need the water to boil at some point so the frog jumps out. > I agree, but I project that 10K hosts behind a /28 and possibly /29 > NAT > pool will cause no major issues, therefore the water is not going > to get > hot any time soon. Emerging markets in countries that don't have > enough > IPv4 will not be made of geeks who want their own IP address, and > double > NAT will remain the solution in a world where not having v4 is not an > option. Double NAT will happen for exactly that reason, but my point is that even though that addresses important needs, it's not enough to address ALL needs. Currently, the cost of adding IPv6 to a network is relatively high because IPv6 is not as well-supported as IPv4 in hardware, software, supporting tools and by people, and the benefit is very limited because few others use IPv6. The cost of adding NAT is low because it's extremely common already and workarounds are in place to make it work reasonably well, while the benefit is large because you get to talk to nearly the entire IPv4 world. When the remaining number of IPv4 addresses isn't large enough to honor the requests for 250k+ address blocks that larger ISPs make, the cost of IPv6 will be lower and keep decreasing because IPv6 will have much better support than it has now, while the benefits increase as more and more people adopt IPv6. For NAT, it's the other way around. Multiple layers of NAT need more and more complex workarounds, and the benefits decrease as more and more users/ applications fail to work through increasing levels of NAT. So at some point, the cost/benefit ratios that now favor NAT over IPv6 will reverse and IPv6 will become more attractive than adding more NAT on top of what's already there by then. Additionally, as the IPv4 stash depletes and the cost/benefit trends become clear, people will plan ahead and will be more inclined to bite the IPv6 bullet a bit sooner rather than wait until the bitter end because they come to realize that IPv6 is inevitable. Note though, that we're not at that point yet. Although I think it's rather unlikely, it's still _possible_ that the IPv4 address usage will break the current trend and we can make IPv4 last for much longer than we anticipate today. If we manage to reduce the number of IPv4 addresses given out per year by 11% every year, we can make the remaining IPv4 address pool last indefinitely. I think the psychological point of no return will be reached when the number of addresses left in the IPv4 pool is equal to or lower than three times what was used in the previous year. If we stabilize at 170 million addresses/year we'll reach that point in late 2011. If 57 million per quarter (228M/yr), like 2007 so far, is the new trend, we'll reach the "three years left" point in late 2009. (However, if the number of addresses per year keeps going up, the time between "three years left" and "all out" will be less than the expected three years.) >> In other words: the running out of IPv4 space is a >> necessary requisite for wide scale IPv6 adoption. >> Without it, nothing is going to change. > If your goal is IPv6 deployment, I agree. I would point out though > that > most businesses and users are not IPv6 evangelists, My goal isn't IPv6 deployment (although I'm not dead set against seeing a thriving market for IPv6 consultancy...) but having the internet work as well as it can for years to come. This means adopting IPv6 at exactly the right time: too soon, and it's too hard and too expensive, too late, and lack of IPv4 address will get in the way of communication over the internet. >> Therefore, any policy that seeks to artifically avoid running out >> is harmful because it perpetuates an address starvation model. > And any policy that seeks to artificially accelerate the running > out is > suicide, Which is certainly not something I favor. Two considerations. First, an IPv4 address sitting unused in a RIR or IANA database isn't of any use, so we should continue to make them available to end-users while supplies last. Second, the most important thing is predictability. If people can see that the number of available IPv4 addresses goes down consistently, they can plan around that and be ready in time. If it happens sooner than expected, many people will be in trouble, and restricting the flow of IPv4 addresses makes life in IPv4 harder without providing a push to move to IPv6, maximizing the pain. >> - it's unfair that more than 50% of all IPv4 address space >> is held by US entities which then get to make a lot of money >> from them, while the developing world holds next to no address >> space and would have to buy it from richer countries. > Making money has never been about being fair. Since when is this a discussion about making money? If that's what we want, let the RIRs increase their fees by a factor 10 or so. From michel at arneill-py.sacramento.ca.us Tue Apr 3 12:04:25 2007 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 3 Apr 2007 09:04:25 -0700 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: <80918C9D-5099-42AF-9CEF-8A205210C490@muada.com> References: <20070320233652.GC37431@ussenterprise.ufp.org><20070322080415.GA24667@tummy.com> <89E1E711-05A4-4D25-B5EC-4390D4EBCE26@muada.com> <80918C9D-5099-42AF-9CEF-8A205210C490@muada.com> Message-ID: Hi Iljitsch, >>> Iljitsch van Beijnum wrote: >>> It will be the kind of NAT where a service provider puts 10, >>> 100 or even 1000 customers behind a single IP address, and >>> the number of usable TCP ports starts being a problem. >> Michel Py wrote: >> This is not as bad as it appears. I have some customers with >> 100 to 300 PCs out of a single IP and I never saw the number >> of simultaneous ports above 1K out of a possible 64K. > Isn't TCP TIME_WAIT 240 seconds? That means that you get to > set up 64k / 240 = 273 new TCP sessions per second. When > browsing the web, you can easily create several new sessions > per second for short periods. Depending on the activity of > the users, I'm expecting problems to occur somewhere between > 100 and 1000 users behind a single IP address. The way I understand it, the TCP TIME_WAIT situation you describe is not relevant to a NAT box, and here's why: it was designed to prevent ghost packets in the network to pollute a newly open TCP session with irrelevant data on the same port number from an older connection. Therefore, the NAT box should indeed keep track of the sessions in TIME_WAIT state, but it does not mean it can't re-use the port for another inside/outside NAT translation from another inside host to another outside host, because then the ghost packets will not have the correct pair and will be discarded at the NAT box, which is why TIME_WAIT was designed to begin with. To cause a problem, the situation you describe requires that all inside hosts try to access the same outside server at the same time. Also, keep in mind that putting 16 times more users on a pool of 16 IP addresses considerably increases the pool of IP/ports pairs available for NAT translation. In a large NAT pool, the number of IP/ports pairs in use tends to join the average number of established sessions per host times the number of hosts (plus some overhead). I maintain that a 1000:1 overload still is a rather conservative target. > The simplest way to overcome NAT problems is to get IPv6 > through it and have the applications use IPv6. Microsoft > is already doing this for some peer-to-peer stuff. With no success. Although I have been accused many times of being an M$ zealot, frankly I can understand why some would prefer developing their own NAT traversal mechanism instead of relying on MSN messenger servers. It still is simpler to make an app x2NAT capable than to rewrite it for IPv6 and deal with the uncertainties of Teredo. I have seen Vista PCs from several OEMs coming out of the factory with the IPv6 stack loaded, and in almost every case the factory Vista load has been wiped out to get rid of all the annoying pieces of software gunk (such as toolbars, useless utilities and so on) that PC makers like to install. I regret to report that Teredo and the v6 stack are part of this gunk, and that no corporate-installed Vista PC I have seen so far has the IPv6 stack (when they don't wipe out Vista altogether and install XP instead that is). > [large snip of stuff I generally agree with] > I think the psychological point of no return will be reached > when the number of addresses left in the IPv4 pool is equal > to or lower than three times what was used in the previous year. That is the one argument I don't buy and here's why: some have been spreading serious FUD about the world coming to an end when the v4 space is depleted, resulting in everyone stockpiling IPv4 addresses at all levels in the food chain. End sites have requested more IPs than they really need, and ISPs have allocated /28s and /27s without question to small businesses who use only one IP just because they requested a static one. There is a lot of IPv4 fat out there and unfortunately the people to be convinced of migrating to v6 are v4-fat, partly because they binged on v4 addresses before the supply ends. For the time being, getting a little leaner still is way cheaper than deploying v6; as long as the big players can live for a while on their fat reserves, nothing's happening. > My goal isn't IPv6 deployment (although I'm not dead set > against seeing a thriving market for IPv6 consultancy...) Hehehe I would never have guessed that ;-) >>> Therefore, any policy that seeks to artifically avoid running out >>> is harmful because it perpetuates an address starvation model. >> And any policy that seeks to artificially accelerate the running >> out is suicide, > Which is certainly not something I favor. There have been some discussions about discreetly killing IPv4 in order to deploy IPv6. Michel. From Kavalec at BSWA.com Tue Apr 3 13:56:00 2007 From: Kavalec at BSWA.com (G. Waleed Kavalec) Date: Tue, 3 Apr 2007 11:56:00 -0600 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) Message-ID: -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of michael.dillon at bt.com I disagree. For instance Russia, a country which I am familiar with having travelled there three times. Outside Moscow and St Petersburg, few people speak a foreign language well enough to use it. For those people, if a site isn't in Russian, then it practically does not exist. -------------------- Mike Have you ever used googles "translate this page" option? Or http://babelfish.altavista.com/ ?????????? connectivity ???????? ??????, ?? ?? ??????? ???? ?????. (Global connectivity is slowed by language, but those barriers are going away.) From jweyand at computerdata.com Tue Apr 3 13:37:47 2007 From: jweyand at computerdata.com (Jim Weyand) Date: Tue, 3 Apr 2007 13:37:47 -0400 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) Message-ID: <1582DCBFF968F044A9A910C0AB177C9012FFB3@cliff.cdi.local> - it's unfair that more than 50% of all IPv4 address space is held by US entities which then get to make a lot of money from them, while the developing world holds next to no address space and would have to buy it from richer countries Can anybody document the 50% figure? When I go to: http://www.arin.net/statistics/jointstats.pdf It looks to me like ARIN has only assigned about 30% of the allocated IPv4 space. From tony at lava.net Tue Apr 3 13:47:37 2007 From: tony at lava.net (Antonio Querubin) Date: Tue, 3 Apr 2007 07:47:37 -1000 (HST) Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: <1582DCBFF968F044A9A910C0AB177C9012FFB3@cliff.cdi.local> References: <1582DCBFF968F044A9A910C0AB177C9012FFB3@cliff.cdi.local> Message-ID: On Tue, 3 Apr 2007, Jim Weyand wrote: > - it's unfair that more than 50% of all IPv4 address space is held by > US entities which then get to make a lot of money from them, while > the developing world holds next to no address space and would have to > buy it from richer countries Spending time and energy complaining about unfairness, hordeing, FUD over the end of days, etc. isn't very productive. Nobody's gonna buy anything at scalper prices which can be gotten for much less through normal means. An IP address provides you presence on the net. It doesn't have to be an IPv4 address. Some countries have already figured this out... Antonio Querubin whois: AQ7-ARIN From iljitsch at muada.com Tue Apr 3 13:50:38 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 3 Apr 2007 19:50:38 +0200 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: <1582DCBFF968F044A9A910C0AB177C9012FFB3@cliff.cdi.local> References: <1582DCBFF968F044A9A910C0AB177C9012FFB3@cliff.cdi.local> Message-ID: On 3-apr-2007, at 19:37, Jim Weyand wrote: > - it's unfair that more than 50% of all IPv4 address space is held by > US entities which then get to make a lot of money from them, while > the developing world holds next to no address space and would have to > buy it from richer countries > Can anybody document the 50% figure? When I go to: > http://www.arin.net/statistics/jointstats.pdf > It looks to me like ARIN has only assigned about 30% of the allocated > IPv4 space. That's between 1999 and 2006. I regularly download the files the RIRs publish on their FTP sites and generate statistics from them at http://www.bgpexpert.com/ addrspace.php If you go to that page it will tell you the number of addresses currently given out by IANA or the RIRs to end-users or ISPs: 2465.82 M Fill in "US" under "Country" and it will say: 1379.23 M This means that 55.93% of the address space currently in use is held by the US according to the RIRs. From Lee at Dilkie.com Tue Apr 3 14:11:20 2007 From: Lee at Dilkie.com (Lee Dilkie) Date: Tue, 03 Apr 2007 14:11:20 -0400 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: <1582DCBFF968F044A9A910C0AB177C9012FFB3@cliff.cdi.local> References: <1582DCBFF968F044A9A910C0AB177C9012FFB3@cliff.cdi.local> Message-ID: <461298C8.1080408@Dilkie.com> > - it's unfair that more than 50% of all IPv4 address space is held by > US entities which then get to make a lot of money from them, while > the developing world holds next to no address space and would have to > buy it from richer countries > > What's unfair is that the western world have spent trillions of their own money developing everything from steam power to air travel to space travel, advanced medicines and, yes, even the internet. And the developing nations benefit from all that work by being able to take advantage of the finished product without having had to foot the bill. Now you think that somehow that's not enough, that the western nations "owe" you even more than that? I think when western nations can tax developing nations to support these projects, just like they taxed me, then you can have a "fair" leg to stand on. -lee From iljitsch at muada.com Tue Apr 3 14:22:12 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 3 Apr 2007 20:22:12 +0200 Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4 Address Countdown In-Reply-To: <1582DCBFF968F044A9A910C0AB177C9012FF96@cliff.cdi.local> References: <1582DCBFF968F044A9A910C0AB177C9012FF96@cliff.cdi.local> Message-ID: <3D08044E-7626-4254-8988-672E59A055B6@muada.com> On 30-mrt-2007, at 23:34, Jim Weyand wrote: > I find myself struggling with how to convert the suggestions and > comments on this list into actual policy proposals. Perhaps it would be a good idea to see if we can agree on what our goals and assumptions are. An important question is whether it's a good idea to try and postpone the moment when the RIRs have to turn down requests for lack of free address space. Assuming we still have around five years, and that a great deal can be accomplished in that time, is it worth going through a lot of trouble to buy us a limited number of additional years? > 4) Several similar informal proposals to encourage recycling by > empowering ARIN to more actively police the use of IPv4 addresses by > various means > 6) An informal proposal to ask holders of unused address IPv4 > addresses to voluntarily return the addresses A "use it or lose it" policy would make sense. Large amounts of address space aren't visible on the global internet, so either people aren't using it at all, or they're only using it internally. If we set a deadline by which address space must be "in use" (hard to define) or it will be put at the end of the free list, this gives people who are using it for internal purposes a reasonable amount of time to move to something else. > 7) Several variants of informal proposals to start assigning > IPv6 > space with IPv4 > 8) An informal proposal to get endusers to demand access to IPv6 > networks by creating a media storm similar to Y2K. The depletion of IPv4 and the adoption of IPv6 are largely orthogonal in the short term. Having IPv6 doesn't mean you don't need IPv4 any more, not having IPv4 doesn't make IPv6 more useful. This is what I suggest: In my opinion, it's a problem that the RIRs are giving out extremely large blocks of address space to the world's largest ISPs. For instance, Softbank has a /8, Comcast got a /8 in two installments and French, Deutsche and British Telecom all have multi-million sized blocks. Even very large ISPs need some time to put these amounts of address space to use, so what happens is that at various intervals, new large blocks are requested, so the number of addresses given out in any particular year varies widely because one request can be as much as 5 to 10 % of the yearly world-wide use. So giving out large blocks makes making predictions harder. Another problem is that if and when business stalls, a good part of a large block will go unused. For both of these reasons, it's a good idea to limit the maximum block size that is given out *today*. When we start to run out of address space for real, this only gets worse, and we run the risk that a large request clears out the remaining address space in one go. To avoid this, we should adopt a policy where there is a maximum block size, and a minimum interval between obtaining address blocks. As the number of addresses left gets smaller, the maximum block size is reduced. For instance, we could make the maximum block size 2 million and the minimum interval 2 months. So if an ISP thinks they need 16 million addresses in a year, they'll have request 2 million, wait 2 months, request another 2 million and so on. In 3 or 4 years, the limit could be half a million, so someone needing 16 million addresses would only be able to get 6 x 1/2 million = 3 million. (Note that people who need smaller blocks still get what they need.) The effect is that an ISP who signs up 16 million new users each year will then have to share an IPv4 address over several users, where the number of users per address increases every year, rather than that in year X every user can get their own address and in year Y there's nothing left. The maximum block size could each year be set to (for instance) the next higher CIDR boundary of 0.1% of the remaining IPv4 address space. This policy has the important property of being predictable so people can plan rolling out new technologies to deal with the IPv4 address shortage in ways that fit their business. A problem would be that this works per-organization, so it favors smaller organizations over larger ones. From michael.dillon at bt.com Tue Apr 3 16:54:04 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 3 Apr 2007 21:54:04 +0100 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: Message-ID: > Have you ever used googles "translate this page" option? > > Or http://babelfish.altavista.com/ Yes. They are both difficult to use unless you actually have a basic to intermediate level of proficiency with the foreign language. I used http://translation1.paralink.com a lot when I was learning Russian, but it was most effective when I read the Russian text a SECOND time, after reading the confused machine translation. In other words the machine translation which was incomprehensible to a unilingual English speaker, gave me enough verb and noun translations to help my mind sort out the original sentence. > ?????????? connectivity ???????? ??????, ?? ?? ??????? ???? ?????. > > (Global connectivity is slowed by language, but those > barriers are going away.) Not quite. Somewhere along the path, your UNICODE (or other codeset) got translated to ASCII question marks. I would guess that you wrote in Russian because I see the same problem in a lot of MP3 tags. Here is an interesting experiment for most of you. Go to http://www.satka.ru and have a look around the site. How many of you would have a problem if this whole town was inaccessible from the USA if they decided to "borrow" some Earthlink IP addresses? --Michael Dillon From tedm at ipinc.net Tue Apr 3 16:52:25 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 3 Apr 2007 13:52:25 -0700 Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4AddressCountdown In-Reply-To: <20070402145742.GY24197@shell01.corp.tellme.com> Message-ID: >-----Original Message----- >From: David Williamson [mailto:dlw+arin at tellme.com] >Sent: Monday, April 02, 2007 7:58 AM >To: Ted Mittelstaedt >Cc: ppml at arin.net >Subject: Re: [ppml] Summary of Trial Balloons for Dealing with >IPv4AddressCountdown > > >Assuming there's a decent 6-to-4 infrastructure in place, why would >anyone ever want to leave v4? If you look at the history of technical change, once improvements have been adopted by the majority, it is almost frightening how quickly the rest of the world follows along. Sure, there's going to be pockets of IPv4 for many years. Just like there are pockets of 10Base2 ethernet installations still in existence today. But, you have to look at the numbers, at least in the United States. Here's some recent ones: http://www.pewinternet.org/pdfs/PIP_Internet_Impact.pdf By the time the major ISPs in the country - the cable companies, (Comcast, etc.) and the phone companies (SBC, Cingular, etc) decide to switch their subscribers over to IPv6 we probably will have 80% penetration into home Internet connectivity. When you have a couple hundred million adults who are running applications and software in their homes that is IPv6 then the corporations won't stand a chance. I have seen this dozens of times on the corporate arena. Consider for example the adoption of Microsoft Office 2003. For a 100 employee your looking easily at $40K in licensing fees not to mention all the hardware your going to have to upgrade to run it. When that package came out lots of companies fought like mad to delay the rollout. I know of several 150-200 person companies for example that had the licensing for it but still fought against deploying it simply because of all the money it would require to be spent on hardware upgrades. But time and time again they lost that battle because users would go out and buy the latest thing from the store and load it on their home systems then clamor for it on their business systems. Your quite wrong if you think businesses these days are technology drivers. For the most part they are not. It is the home users that their spending dwarfs businesses on new technology, and are usually dragging the businesses along. Consider how many brick and mortar businesses resisted online sales, yet it happened anyway. Amazon was selling books online long before any of the brick and mortar booksellers. The large corporations with lots of IPv4 deployed internally do not have the control over what apps are fielded on the Internet. It is the home users that have that control, and if the national ISPs in the US decide the home users are going to be changed over to IPv6, then once that happens, the home users will make everyone else switchover. Remember, for businesses it's all about ROI. Home users don't care about ROI and will happily take a financial loss by throwing away last years technology that works fine and getting the newest and latest if they think it's sexier. Ted From lchiorazzi at glowpoint.com Tue Apr 3 17:07:26 2007 From: lchiorazzi at glowpoint.com (Lou Chiorazzi) Date: Tue, 3 Apr 2007 17:07:26 -0400 Subject: [ppml] PPML Digest, Vol 22, Issue 7 Message-ID: <00c401c77634$13d36ea4$1b06a8c0@hillside.glowpoint.com> I have updated data that I don't think you have. The spike in 05 is from Ive. Look for free busy in a meet request for tomorrow -----Original Message----- From: "ppml-request at arin.net" To: "ppml at arin.net" Sent: 4/3/07 4:52 PM Subject: PPML Digest, Vol 22, Issue 7 Send PPML mailing list submissions to ppml at arin.net To subscribe or unsubscribe via the World Wide Web, visit http://lists.arin.net/mailman/listinfo/ppml or, via email, send a message with subject or body 'help' to ppml-request at arin.net You can reach the person managing the list at ppml-owner at arin.net When replying, please edit your Subject line so it is more specific than "Re: Contents of PPML digest..." Today's Topics: 1. Re: My view on IPv4 (was: Re: IPv4 wind-down) (Michel Py) 2. Re: My view on IPv4 (was: Re: IPv4 wind-down) (G. Waleed Kavalec) 3. Re: My view on IPv4 (was: Re: IPv4 wind-down) (Jim Weyand) 4. Re: My view on IPv4 (was: Re: IPv4 wind-down) (Antonio Querubin) 5. Re: My view on IPv4 (was: Re: IPv4 wind-down) (Iljitsch van Beijnum) 6. Re: My view on IPv4 (was: Re: IPv4 wind-down) (Lee Dilkie) 7. Re: Summary of Trial Balloons for Dealing with IPv4 Address Countdown (Iljitsch van Beijnum) 8. Re: My view on IPv4 (was: Re: IPv4 wind-down) (michael.dillon at bt.com) ---------------------------------------------------------------------- Message: 1 Date: Tue, 3 Apr 2007 09:04:25 -0700 From: "Michel Py" Subject: Re: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) To: "Iljitsch van Beijnum" Cc: ppml at arin.net Message-ID: Content-Type: text/plain; charset="us-ascii" Hi Iljitsch, >>> Iljitsch van Beijnum wrote: >>> It will be the kind of NAT where a service provider puts 10, >>> 100 or even 1000 customers behind a single IP address, and >>> the number of usable TCP ports starts being a problem. >> Michel Py wrote: >> This is not as bad as it appears. I have some customers with >> 100 to 300 PCs out of a single IP and I never saw the number >> of simultaneous ports above 1K out of a possible 64K. > Isn't TCP TIME_WAIT 240 seconds? That means that you get to > set up 64k / 240 = 273 new TCP sessions per second. When > browsing the web, you can easily create several new sessions > per second for short periods. Depending on the activity of > the users, I'm expecting problems to occur somewhere between > 100 and 1000 users behind a single IP address. The way I understand it, the TCP TIME_WAIT situation you describe is not relevant to a NAT box, and here's why: it was designed to prevent ghost packets in the network to pollute a newly open TCP session with irrelevant data on the same port number from an older connection. Therefore, the NAT box should indeed keep track of the sessions in TIME_WAIT state, but it does not mean it can't re-use the port for another inside/outside NAT translation from another inside host to another outside host, because then the ghost packets will not have the correct pair and will be discarded at the NAT box, which is why TIME_WAIT was designed to begin with. To cause a problem, the situation you describe requires that all inside hosts try to access the same outside server at the same time. Also, keep in mind that putting 16 times more users on a pool of 16 IP addresses considerably increases the pool of IP/ports pairs available for NAT translation. In a large NAT pool, the number of IP/ports pairs in use tends to join the average number of established sessions per host times the number of hosts (plus some overhead). I maintain that a 1000:1 overload still is a rather conservative target. > The simplest way to overcome NAT problems is to get IPv6 > through it and have the applications use IPv6. Microsoft > is already doing this for some peer-to-peer stuff. With no success. Although I have been accused many times of being an M$ zealot, frankly I can understand why some would prefer developing their own NAT traversal mechanism instead of relying on MSN messenger servers. It still is simpler to make an app x2NAT capable than to rewrite it for IPv6 and deal with the uncertainties of Teredo. I have seen Vista PCs from several OEMs coming out of the factory with the IPv6 stack loaded, and in almost every case the factory Vista load has been wiped out to get rid of all the annoying pieces of software gunk (such as toolbars, useless utilities and so on) that PC makers like to install. I regret to report that Teredo and the v6 stack are part of this gunk, and that no corporate-installed Vista PC I have seen so far has the IPv6 stack (when they don't wipe out Vista altogether and install XP instead that is). > [large snip of stuff I generally agree with] > I think the psychological point of no return will be reached > when the number of addresses left in the IPv4 pool is equal > to or lower than three times what was used in the previous year. That is the one argument I don't buy and here's why: some have been spreading serious FUD about the world coming to an end when the v4 space is depleted, resulting in everyone stockpiling IPv4 addresses at all levels in the food chain. End sites have requested more IPs than they really need, and ISPs have allocated /28s and /27s without question to small businesses who use only one IP just because they requested a static one. There is a lot of IPv4 fat out there and unfortunately the people to be convinced of migrating to v6 are v4-fat, partly because they binged on v4 addresses before the supply ends. For the time being, getting a little leaner still is way cheaper than deploying v6; as long as the big players can live for a while on their fat reserves, nothing's happening. > My goal isn't IPv6 deployment (although I'm not dead set > against seeing a thriving market for IPv6 consultancy...) Hehehe I would never have guessed that ;-) >>> Therefore, any policy that seeks to artifically avoid running out >>> is harmful because it perpetuates an address starvation model. >> And any policy that seeks to artificially accelerate the running >> out is suicide, > Which is certainly not something I favor. There have been some discussions about discreetly killing IPv4 in order to deploy IPv6. Michel. ------------------------------ Message: 2 Date: Tue, 3 Apr 2007 11:56:00 -0600 From: "G. Waleed Kavalec" Subject: Re: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) To: Message-ID: Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of michael.dillon at bt.com I disagree. For instance Russia, a country which I am familiar with having travelled there three times. Outside Moscow and St Petersburg, few people speak a foreign language well enough to use it. For those people, if a site isn't in Russian, then it practically does not exist. -------------------- Mike Have you ever used googles "translate this page" option? Or http://babelfish.altavista.com/ ?????????? connectivity ???????? ??????, ?? ?? ??????? ???? ?????. (Global connectivity is slowed by language, but those barriers are going away.) ------------------------------ Message: 3 Date: Tue, 3 Apr 2007 13:37:47 -0400 From: "Jim Weyand" Subject: Re: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) To: Message-ID: <1582DCBFF968F044A9A910C0AB177C9012FFB3 at cliff.cdi.local> Content-Type: text/plain; charset="us-ascii" - it's unfair that more than 50% of all IPv4 address space is held by US entities which then get to make a lot of money from them, while the developing world holds next to no address space and would have to buy it from richer countries Can anybody document the 50% figure? When I go to: http://www.arin.net/statistics/jointstats.pdf It looks to me like ARIN has only assigned about 30% of the allocated IPv4 space. ------------------------------ Message: 4 Date: Tue, 3 Apr 2007 07:47:37 -1000 (HST) From: Antonio Querubin Subject: Re: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) To: Jim Weyand Cc: ppml at arin.net Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Tue, 3 Apr 2007, Jim Weyand wrote: > - it's unfair that more than 50% of all IPv4 address space is held by > US entities which then get to make a lot of money from them, while > the developing world holds next to no address space and would have to > buy it from richer countries Spending time and energy complaining about unfairness, hordeing, FUD over the end of days, etc. isn't very productive. Nobody's gonna buy anything at scalper prices which can be gotten for much less through normal means. An IP address provides you presence on the net. It doesn't have to be an IPv4 address. Some countries have already figured this out... Antonio Querubin whois: AQ7-ARIN ------------------------------ Message: 5 Date: Tue, 3 Apr 2007 19:50:38 +0200 From: Iljitsch van Beijnum Subject: Re: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) To: Jim Weyand Cc: ppml at arin.net Message-ID: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 3-apr-2007, at 19:37, Jim Weyand wrote: > - it's unfair that more than 50% of all IPv4 address space is held by > US entities which then get to make a lot of money from them, while > the developing world holds next to no address space and would have to > buy it from richer countries > Can anybody document the 50% figure? When I go to: > http://www.arin.net/statistics/jointstats.pdf > It looks to me like ARIN has only assigned about 30% of the allocated > IPv4 space. That's between 1999 and 2006. I regularly download the files the RIRs publish on their FTP sites and generate statistics from them at http://www.bgpexpert.com/ addrspace.php If you go to that page it will tell you the number of addresses currently given out by IANA or the RIRs to end-users or ISPs: 2465.82 M Fill in "US" under "Country" and it will say: 1379.23 M This means that 55.93% of the address space currently in use is held by the US according to the RIRs. ------------------------------ Message: 6 Date: Tue, 03 Apr 2007 14:11:20 -0400 From: Lee Dilkie Subject: Re: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) To: ppml at arin.net Message-ID: <461298C8.1080408 at Dilkie.com> Content-Type: text/plain; charset=ISO-8859-1 > - it's unfair that more than 50% of all IPv4 address space is held by > US entities which then get to make a lot of money from them, while > the developing world holds next to no address space and would have to > buy it from richer countries > > What's unfair is that the western world have spent trillions of their own money developing everything from steam power to air travel to space travel, advanced medicines and, yes, even the internet. And the developing nations benefit from all that work by being able to take advantage of the finished product without having had to foot the bill. Now you think that somehow that's not enough, that the western nations "owe" you even more than that? I think when western nations can tax developing nations to support these projects, just like they taxed me, then you can have a "fair" leg to stand on. -lee ------------------------------ Message: 7 Date: Tue, 3 Apr 2007 20:22:12 +0200 From: Iljitsch van Beijnum Subject: Re: [ppml] Summary of Trial Balloons for Dealing with IPv4 Address Countdown To: Jim Weyand Cc: ppml at arin.net Message-ID: <3D08044E-7626-4254-8988-672E59A055B6 at muada.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 30-mrt-2007, at 23:34, Jim Weyand wrote: > I find myself struggling with how to convert the suggestions and > comments on this list into actual policy proposals. Perhaps it would be a good idea to see if we can agree on what our goals and assumptions are. An important question is whether it's a good idea to try and postpone the moment when the RIRs have to turn down requests for lack of free address space. Assuming we still have around five years, and that a great deal can be accomplished in that time, is it worth going through a lot of trouble to buy us a limited number of additional years? > 4) Several similar informal proposals to encourage recycling by > empowering ARIN to more actively police the use of IPv4 addresses by > various means > 6) An informal proposal to ask holders of unused address IPv4 > addresses to voluntarily return the addresses A "use it or lose it" policy would make sense. Large amounts of address space aren't visible on the global internet, so either people aren't using it at all, or they're only using it internally. If we set a deadline by which address space must be "in use" (hard to define) or it will be put at the end of the free list, this gives people who are using it for internal purposes a reasonable amount of time to move to something else. > 7) Several variants of informal proposals to start assigning > IPv6 > space with IPv4 > 8) An informal proposal to get endusers to demand access to IPv6 > networks by creating a media storm similar to Y2K. The depletion of IPv4 and the adoption of IPv6 are largely orthogonal in the short term. Having IPv6 doesn't mean you don't need IPv4 any more, not having IPv4 doesn't make IPv6 more useful. This is what I suggest: In my opinion, it's a problem that the RIRs are giving out extremely large blocks of address space to the world's largest ISPs. For instance, Softbank has a /8, Comcast got a /8 in two installments and French, Deutsche and British Telecom all have multi-million sized blocks. Even very large ISPs need some time to put these amounts of address space to use, so what happens is that at various intervals, new large blocks are requested, so the number of addresses given out in any particular year varies widely because one request can be as much as 5 to 10 % of the yearly world-wide use. So giving out large blocks makes making predictions harder. Another problem is that if and when business stalls, a good part of a large block will go unused. For both of these reasons, it's a good idea to limit the maximum block size that is given out *today*. When we start to run out of address space for real, this only gets worse, and we run the risk that a large request clears out the remaining address space in one go. To avoid this, we should adopt a policy where there is a maximum block size, and a minimum interval between obtaining address blocks. As the number of addresses left gets smaller, the maximum block size is reduced. For instance, we could make the maximum block size 2 million and the minimum interval 2 months. So if an ISP thinks they need 16 million addresses in a year, they'll have request 2 million, wait 2 months, request another 2 million and so on. In 3 or 4 years, the limit could be half a million, so someone needing 16 million addresses would only be able to get 6 x 1/2 million = 3 million. (Note that people who need smaller blocks still get what they need.) The effect is that an ISP who signs up 16 million new users each year will then have to share an IPv4 address over several users, where the number of users per address increases every year, rather than that in year X every user can get their own address and in year Y there's nothing left. The maximum block size could each year be set to (for instance) the next higher CIDR boundary of 0.1% of the remaining IPv4 address space. This policy has the important property of being predictable so people can plan rolling out new technologies to deal with the IPv4 address shortage in ways that fit their business. A problem would be that this works per-organization, so it favors smaller organizations over larger ones. ------------------------------ Message: 8 Date: Tue, 3 Apr 2007 21:54:04 +0100 From: Subject: Re: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) To: , Message-ID: Content-Type: text/plain; charset="US-ASCII" > Have you ever used googles "translate this page" option? > > Or http://babelfish.altavista.com/ Yes. They are both difficult to use unless you actually have a basic to intermediate level of proficiency with the foreign language. I used http://translation1.paralink.com a lot when I was learning Russian, but it was most effective when I read the Russian text a SECOND time, after reading the confused machine translation. In other words the machine translation which was incomprehensible to a unilingual English speaker, gave me enough verb and noun translations to help my mind sort out the original sentence. > ?????????? connectivity ???????? ??????, ?? ?? ??????? ???? ?????. > > (Global connectivity is slowed by language, but those > barriers are going away.) Not quite. Somewhere along the path, your UNICODE (or other codeset) got translated to ASCII question marks. I would guess that you wrote in Russian because I see the same problem in a lot of MP3 tags. Here is an interesting experiment for most of you. Go to http://www.satka.ru and have a look around the site. How many of you would have a problem if this whole town was inaccessible from the USA if they decided to "borrow" some Earthlink IP addresses? --Michael Dillon ------------------------------ _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml End of PPML Digest, Vol 22, Issue 7 *********************************** From lsc at prgmr.com Tue Apr 3 17:08:57 2007 From: lsc at prgmr.com (Luke S. Crawford) Date: Tue, 3 Apr 2007 14:08:57 -0700 (PDT) Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: References: Message-ID: On Tue, 3 Apr 2007, michael.dillon at bt.com wrote: > Here is an interesting experiment for most of you. Go to > http://www.satka.ru and have a look around the site. How many of you > would have a problem if this whole town was inaccessible from the USA if > they decided to "borrow" some Earthlink IP addresses? As I said before in a private e-mail (in a failed attempt to reduce noise) even assuming the pesants don't need out-of-country connectivity, if the russian "tier-1" internet needs to talk to both the russian-only web and the whole internet, implementation of this "ip block theft" would be excessively difficult without NAT, and with NAT, it's not really IP block theft, as NAT will translate the IP addresses to something globaly routable. From dlw+arin at tellme.com Tue Apr 3 17:12:39 2007 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 3 Apr 2007 14:12:39 -0700 Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4AddressCountdown In-Reply-To: References: <20070402145742.GY24197@shell01.corp.tellme.com> Message-ID: <20070403211239.GH24197@shell01.corp.tellme.com> On Tue, Apr 03, 2007 at 01:52:25PM -0700, Ted Mittelstaedt wrote: > By the time the major ISPs in the country - the cable companies, (Comcast, > etc.) > and the phone companies (SBC, Cingular, etc) decide to switch their > subscribers over to IPv6 we probably will have 80% penetration into > home Internet connectivity. When you have a couple hundred million > adults who are running applications and software in their homes that > is IPv6 then the corporations won't stand a chance. Neither the users or the applications care if it's IPv4 or IPv6. It's completely irrelevant to the vast majority of either group. Unless it's software for controlling networking devices or a user like one of us, the difference is almost irrelevant. Until there's some good reason for businesses to move to v6, it won't happen in a global sense. Sure, the edges may go v6 earlier than much of the rest, but a 6-to-4 infrastructure negates the need for the middle to bother with the hastle. I'll openly admit that the present 6-to-4 infrastructure is, at best, very poor. Frankly, I'm not sure that an IPv4 core combined with a v6 edge is any better than a highly NAT'd all v4 world. Moving everything to v6 would probably be beneficial to everyone (as a whole), but until it's beneficial to individuals (and enterprises), I just don't see it moving quickly. Your mileage may vary. We can agree to disagree on this point, if you'd prefer. I'll let others chime in, if anyone cares to. -David From tedm at ipinc.net Tue Apr 3 17:15:14 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 3 Apr 2007 14:15:14 -0700 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: <89E1E711-05A4-4D25-B5EC-4390D4EBCE26@muada.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Iljitsch van Beijnum >Sent: Monday, April 02, 2007 2:52 PM >To: Sean Reifschneider >Cc: ppml at arin.net >Subject: Re: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) > > > >This is very true, and will largely remain true as IPv4 space runs >out. People who have IPv4 space today won't have a problem, it's the >people who need more address space when there no longer is any who >will be in a bind, because at that point, the vast majority of all >internet users will still only be reachable over IPv4. This means >massive amounts of NAT. This is not the nice, friendly NAT where you >have three PCs behind your Linksys DSL router and you get to forward >ports so fussy applications like VoIP still work. > >It will be the kind of NAT where a service provider puts 10, 100 or >even 1000 customers behind a single IP address, and the number of >usable TCP ports starts being a problem. Forget about port mappings >and hence any applications that are more complex than client-server. I'm not sure that this is going to be the sticking point with IPv6-IPv4 NAT. I suspect the real problem is fundamentally this. Looking out on the Internet from the IPv4 initiator's point of view, you have a total number of connectable addresses of X. However in the IPv6 world the total connectable number of addresses is Y, and Y is a hell of a lot bigger than X. So how do you map a large set to a small set? Kind of like wearing a set of eyeglasses with everything but a tiny little dot on the lenses covered up with paint. Sure, you can probably do it through any number of schemes, but all of these are going to be a lot more complicated than the typical NAT code in an IPv4 NAT today. And when you add in complexity your going to decrease reliability and break many specific applications. On the other hand, if the connection initiator is IPv6 and the Internet is IPv4 that kind of NAT code should be trivially easy to write. >At that point, those users may want to add IPv6 to their heavily >NATed IPv4 so they can run peer-to-peer and server-to-client >applications in addition to client-to-server applications. Only at >THAT point, it will become interesting for people with enough IPv4 >space to also support IPv6 so they can talk to those of us who are >behind several layers of NAT. > It seems to me in your typical "windows-user-on-a-DSL-line" paradigm that it would be far far easier to have the NAT router dynamically assign IPv6 only to the Windows user, and the NAT router itself would be dual-stacked. Ted From Lee at Dilkie.com Tue Apr 3 18:17:06 2007 From: Lee at Dilkie.com (Lee Dilkie) Date: Tue, 03 Apr 2007 18:17:06 -0400 Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4AddressCountdown In-Reply-To: <20070403211239.GH24197@shell01.corp.tellme.com> References: <20070402145742.GY24197@shell01.corp.tellme.com> <20070403211239.GH24197@shell01.corp.tellme.com> Message-ID: <4612D262.1070804@Dilkie.com> David Williamson wrote: > Neither the users or the applications care if it's IPv4 or IPv6. It's > completely irrelevant to the vast majority of either group. Unless > it's software for controlling networking devices or a user like one of > us, the difference is almost irrelevant. > Except that there *is* a lot of s/w that will have to change. Most business s/w has moved to a client-server model for years now and that will be affected. E-mail, bug tracking, source code change systems, sap, workgroup productivity, VoIP, video conferencing, business intelligence. Any piece of s/w that creates a socket or makes/displays/inputs an address is affected. It's a long list and smells a lot like Y2K. While the cost of upgrading switching infrastructure and re-training IT staff can be relatively accurately estimated, the same is not true for legacy s/w. And for that reason I think the corporate world might hang on a lot longer than the home user. Regardless to all that. I question ARINs role in this. In my mind the move will happen when it does and probably at the best speed (too early and costs are high, too late and productivity is lost). The decision will occur at different intervals and for different reasons. For that reason I object to a social engineering role that would have ARIN essentially making the decision of 'when'. I don't see how that is ARIN's mandate. I especially don't like the idea of taxing users for something that wasn't previously a cost just to encourage a behaviour. We know how that generally works out, those with money can afford to ignore the nudge and those without money are forced to spend either on keeping the status quo or spend on an unneeded or pre-mature upgrade. If you truly believe that the move is in the best interests of all, then use a carrot. Offer money to give up address blocks. I'll bet your shrinking ipv4 space problem will have a longer horizon. -lee From jafo at tummy.com Tue Apr 3 18:35:40 2007 From: jafo at tummy.com (Sean Reifschneider) Date: Tue, 3 Apr 2007 16:35:40 -0600 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: References: <89E1E711-05A4-4D25-B5EC-4390D4EBCE26@muada.com> Message-ID: <20070403223540.GZ1032@tummy.com> On Tue, Apr 03, 2007 at 02:15:14PM -0700, Ted Mittelstaedt wrote: >On the other hand, if the connection initiator is IPv6 and the Internet >is IPv4 that kind of NAT code should be trivially easy to write. Which is why I think we need a Comcast or other largely client oriented provider to switch. Thanks, Sean -- Like its politicians and its wars, society has the teenagers it deserves. -- J. B. Priestley Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability From gih at apnic.net Tue Apr 3 19:27:11 2007 From: gih at apnic.net (Geoff Huston) Date: Wed, 04 Apr 2007 09:27:11 +1000 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: <1582DCBFF968F044A9A910C0AB177C9012FFB3@cliff.cdi.local> References: <1582DCBFF968F044A9A910C0AB177C9012FFB3@cliff.cdi.local> Message-ID: <7.0.0.16.2.20070404092316.015a1ea8@apnic.net> At 03:37 AM 4/04/2007, Jim Weyand wrote: >- it's unfair that more than 50% of all IPv4 address space is held by >US entities which then get to make a lot of money from them, while >the developing world holds next to no address space and would have to >buy it from richer countries > >Can anybody document the 50% figure? When I go to: > http://www.arin.net/statistics/jointstats.pdf > >It looks to me like ARIN has only assigned about 30% of the allocated >IPv4 space. http://resources.potaroo.net/iso3166/v4cc.html (Its a pretty crude approach, and it uses the country code in the RIRs' stats files as the means of matching country codes to assignments) From sleibrand at internap.com Tue Apr 3 21:35:52 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 03 Apr 2007 18:35:52 -0700 Subject: [ppml] Proposed Policy: IPv4 Countdown In-Reply-To: References: Message-ID: <461300F8.80008@internap.com> Ted Mittelstaedt wrote: > The one thing that I have come even more firmly into belief though > after reading all of this discussion is that it will be a huge mistake > if IPv6 adoption by the Internet core is not done before IPv4 address > runout, but instead was done months or years after IPv4 runout as > a result of political/economic pressure. > > In other words, we can have it the easy way or the hard way. > > The easy way would be to get agressive about IPv4 reclamation now, > which would push back the deadline for IPv4 runout. Then after a > year or so of more agressive reclamation, then set a IPv4 end-date > that all RIR's agree would be the actual end of addresses (with the > understanding that this is nothing more than a best-guess). Then > set a conversion date that would be 6 months before that date, of > conversion of the global BGP table to IPv6. > > That doesn't seem very easy to me... :) > The hard way would be to do nothing until the actual end of IPv4 > allocations, then see if the free market will step in and do some > sort of IPv4 brokering thing, then let the Internet's global > BGP table sort of morph/evolve into an IPv4/IPv6 table then > eventually become all IPv6. > I'm not so sure this is worse. We already have a BGP table slowly morphing and evolving into an IPv4/IPv6 table. With use of tunneling technologies like 6PE (IPv6 at the edge running over MPLS in the core), it doesn't even look all that painful for the network operators. I think the bigger barrier to IPv6 adoption is the work required to get everything else (from the NSP edge to the LAN) working as seamlessly with IPv6 as it does with v4. I would agree that prudent policies to deal with impending IPv4 exhaustion are a good idea. But I don't think we're headed for a train wreck, a falling sky, or any other similar catastrophe. An economic adage I heard once is appropriate here: If a trend is unsustainable, it won't be sustained. > In the absense of political will or agreement for the former the > latter is what is going to happen by default. The sad thing is that > it seems like a lot of people WANT the latter to happen. > > I think that's because people aren't looking for a catastrophe, they just believe from experience that in a free market economy, shortages are seldom catastrophic, so there's not as much urgency to solve the problem in advance as there might otherwise be. -Scott From alh-ietf at tndh.net Tue Apr 3 23:16:30 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 3 Apr 2007 20:16:30 -0700 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: <20070403223540.GZ1032@tummy.com> References: <89E1E711-05A4-4D25-B5EC-4390D4EBCE26@muada.com> <20070403223540.GZ1032@tummy.com> Message-ID: <015001c77667$a4f3ab10$eedb0130$@net> Sean, You appear to be approaching this from the most complicated perspective of 'only one version at a time'... Your focus on 'switching' raises all of the problems without any obvious value return. If you take the approach of 'adding IPv6' alongside IPv4, you gain the ability for applications and users that can use IPv6 to do so without cutting off IPv4 or creating a translation-nightmare. The easiest way to get the end users to switch is to make it transparent to them. Vista and Mac OS support will do the right thing if you provide the infrastructure, and the content hosting organizations do the same. Trying to force an unnatural and visible 'switch' will only raise costs for everyone. Tony > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Sean Reifschneider > Sent: Tuesday, April 03, 2007 3:36 PM > To: Ted Mittelstaedt > Cc: ppml at arin.net > Subject: Re: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) > > On Tue, Apr 03, 2007 at 02:15:14PM -0700, Ted Mittelstaedt wrote: > >On the other hand, if the connection initiator is IPv6 and the Internet > >is IPv4 that kind of NAT code should be trivially easy to write. > > Which is why I think we need a Comcast or other largely client oriented > provider to switch. > > Thanks, > Sean > -- > Like its politicians and its wars, society has the teenagers it > deserves. > -- J. B. Priestley > Sean Reifschneider, Member of Technical Staff > tummy.com, ltd. - Linux Consulting since 1995: Ask me about High > Availability > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From jafo at tummy.com Tue Apr 3 23:33:56 2007 From: jafo at tummy.com (Sean Reifschneider) Date: Tue, 3 Apr 2007 21:33:56 -0600 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: <015001c77667$a4f3ab10$eedb0130$@net> References: <89E1E711-05A4-4D25-B5EC-4390D4EBCE26@muada.com> <20070403223540.GZ1032@tummy.com> <015001c77667$a4f3ab10$eedb0130$@net> Message-ID: <20070404033356.GO1032@tummy.com> On Tue, Apr 03, 2007 at 08:16:30PM -0700, Tony Hain wrote: >'only one version at a time'... Your focus on 'switching' raises all of the >problems without any obvious value return. If you take the approach of If a Comcast wants to deploy v6 alongside v4, that would be fine as far as my view goes... The problem is that everyone wants someone else to go first. Still doesn't change the fact that we don't have any users asking for v6... Sean -- "If all you have is a hammer, every problem tends to look like a nail." Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability Back off man. I'm a scientist. http://HackingSociety.org/ From michael.dillon at bt.com Wed Apr 4 10:17:57 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 4 Apr 2007 15:17:57 +0100 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: <20070404033356.GO1032@tummy.com> Message-ID: > If a Comcast wants to deploy v6 alongside v4, that would be > fine as far as > my view goes... The problem is that everyone wants someone else to go > first. Still doesn't change the fact that we don't have any > users asking > for v6... Doesn't the US DOD count as a user? The US Government? The research community? These sectors are all asking for v6 and many more users are asking for v6 roadmaps. In other words, if your company has a realistic roadmap towards implementing v6 services, you stand a better chance of selling v4 services (or not losing existing v4 customers). --Michael Dillon From kloch at kl.net Wed Apr 4 11:45:39 2007 From: kloch at kl.net (Kevin Loch) Date: Wed, 04 Apr 2007 11:45:39 -0400 Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4AddressCountdown In-Reply-To: <20070403211239.GH24197@shell01.corp.tellme.com> References: <20070402145742.GY24197@shell01.corp.tellme.com> <20070403211239.GH24197@shell01.corp.tellme.com> Message-ID: <4613C823.1040102@kl.net> David Williamson wrote: > I'll openly admit that the present 6-to-4 infrastructure is, at best, > very poor. Frankly, I'm not sure that an IPv4 core combined with a v6 > edge is any better than a highly NAT'd all v4 world. Moving everything > to v6 would probably be beneficial to everyone (as a whole), but until > it's beneficial to individuals (and enterprises), I just don't see it > moving quickly. Your mileage may vary. As someone who has to deal with rfc1918 collisions almost daily, I can see benefits of v6 edge over nat. Of course this would require teredo and not 6to4 to have only one v4 address per site. - Kevin From bob at FiberInternetCenter.com Wed Apr 4 12:37:31 2007 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 4 Apr 2007 09:37:31 -0700 (PDT) Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: References: <20070404033356.GO1032@tummy.com> Message-ID: <17602.66.201.44.146.1175704651.squirrel@bobevans.net> After following for sometime - Paying one's taxes online and checking how your congress person voted, doesnt drive the desire for internet ..... I feel the need to remind that "primarly" (unfortunately) it's PORNO that needs to go first - that seems to start everything. If comcast does offer IPv6 and there is such content via IPv6 , customers will begin to ask/expect IPv6. Therefore, any network that provides consumer access or co-lo services should begin IPv6 to be ready for the content that does drive the desire (if not porno-but most likely). bob evans >> If a Comcast wants to deploy v6 alongside v4, that would be >> fine as far as >> my view goes... The problem is that everyone wants someone else to go >> first. Still doesn't change the fact that we don't have any >> users asking >> for v6... > > Doesn't the US DOD count as a user? The US Government? The research > community? These sectors are all asking for v6 and many more users are > asking for v6 roadmaps. In other words, if your company has a realistic > roadmap towards implementing v6 services, you stand a better chance of > selling v4 services (or not losing existing v4 customers). > > --Michael Dillon > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > > www.FiberInternetCenter.com From Lee.Howard at stanleyassociates.com Wed Apr 4 13:35:57 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 4 Apr 2007 13:35:57 -0400 Subject: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) In-Reply-To: <7.0.0.16.2.20070404092316.015a1ea8@apnic.net> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4056CC5E8@CL-S-EX-1.stanleyassociates.com> > >Can anybody document the 50% figure? When I go to: > > http://www.arin.net/statistics/jointstats.pdf > > > >It looks to me like ARIN has only assigned about 30% of the allocated > >IPv4 space. There was space assigned (in the ARIN region and elsewhere) before ARIN existed. Those statistics are great, though, and I appreciate the work Registration Services staff and their peers at the other RIRs do. > http://resources.potaroo.net/iso3166/v4cc.html > > (Its a pretty crude approach, and it uses the country code in > the RIRs' stats files as the means of matching country codes > to assignments) That's pretty nifty. Is there any way to list hostcount along with headcount? (e.g. http://www.infoplease.com/ipa/A0883396.html ) Lee From mahler at louisiana.edu Wed Apr 4 15:24:23 2007 From: mahler at louisiana.edu (Stephen J. Mahler) Date: Wed, 4 Apr 2007 14:24:23 -0500 Subject: [ppml] PPML Digest, Vol 22, Issue 9 In-Reply-To: Message-ID: Throwing caution to the wind, and becoming involved in this discussion ... I suggest that the problem is not getting people out of the IPV4 address space, the problem is getting them into the IPv6 space. If moving to IPV6 is easy, interesting, has a clear benefit, and worked as more of a long term project than a flash cut... they will move. The existing IPV4 address space is a tiny fraction of the IPV6 space. Follow the lead of Madison Ave. ... give away samples. GIVE each existing address space owner (OK, not really the owner) an upsized chunk of the new space. Let the computers handle the application for the space, just copy the registration information. Each IPV4 Class C is given a range equal in size to a IPV4 class B. Each Class B is given a range equal to a current Class A. Each Class A is given a SUPER-A. Make this the last time you have to worry about your existing address space between now and your retirement. Make the advantage of switching to IPV6 that you have room to operate and test for years to come. Make it a reason to work thru the headaches of using IPV6. You won't have to worry about closing down IPV4 if there are advantages to moving to IPV6. If the only advantage to switching to IPV6 is that IPV4 is closing down tomorrow, everyone will wait till the day before. ...STeve Stephen J. Mahler, Director Information Networks University of Louisiana at Lafayette http://info.louisiana.edu/mahler 337-482-6418 voice 337-482-2489 fax > >-----Original Message----- > >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > >Iljitsch van Beijnum > >Sent: Monday, April 02, 2007 2:52 PM > >To: Sean Reifschneider > >Cc: ppml at arin.net > >Subject: Re: [ppml] My view on IPv4 (was: Re: IPv4 wind-down) > > > > > > > >This is very true, and will largely remain true as IPv4 space runs > >out. People who have IPv4 space today won't have a problem, it's the > >people who need more address space when there no longer is any who > >will be in a bind, because at that point, the vast majority of all > >internet users will still only be reachable over IPv4. This means > >massive amounts of NAT. This is not the nice, friendly NAT where you > >have three PCs behind your Linksys DSL router and you get to forward > >ports so fussy applications like VoIP still work. > > > >It will be the kind of NAT where a service provider puts 10, 100 or > >even 1000 customers behind a single IP address, and the number of > >usable TCP ports starts being a problem. Forget about port mappings > >and hence any applications that are more complex than client-server. > > I'm not sure that this is going to be the sticking point with IPv6-IPv4 > NAT. > > I suspect the real problem is fundamentally this. Looking out on the > Internet from the IPv4 initiator's point of view, you have a total > number of connectable addresses of X. However in the IPv6 world the > total connectable number of addresses is Y, and Y is a hell of a lot > bigger than X. So how do you map a large set to a small set? Kind > of like wearing a set of eyeglasses with everything but a tiny little > dot on the lenses covered up with paint. > > Sure, you can probably do it through any number of schemes, but all > of these are going to be a lot more complicated than the typical NAT > code in an IPv4 NAT today. And when you add in complexity your going > to decrease reliability and break many specific applications. > > On the other hand, if the connection initiator is IPv6 and the Internet > is IPv4 that kind of NAT code should be trivially easy to write. > > >At that point, those users may want to add IPv6 to their heavily > >NATed IPv4 so they can run peer-to-peer and server-to-client > >applications in addition to client-to-server applications. Only at > >THAT point, it will become interesting for people with enough IPv4 > >space to also support IPv6 so they can talk to those of us who are > >behind several layers of NAT. > > > > It seems to me in your typical "windows-user-on-a-DSL-line" paradigm > that it would be far far easier to have the NAT router dynamically assign > IPv6 only to the Windows user, and the NAT router itself would be > dual-stacked. > > > Ted > From iljitsch at muada.com Wed Apr 4 16:16:32 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 4 Apr 2007 22:16:32 +0200 Subject: [ppml] PPML Digest, Vol 22, Issue 9 In-Reply-To: References: Message-ID: On 4-apr-2007, at 21:24, Stephen J. Mahler wrote: > I suggest that the problem is not getting people out of the IPV4 > address > space, the problem is getting them into the IPv6 space. If the latter is your goal, that's certainly a problem. However, neither is the problem at hand. That would be the simple fact that somewhere in the first part of the next decade, there won't be enough IPv4 addresses left to fulfill the requests for IPv4 address space, if things continue in any way that has a reasonable relationship to current practice. > The existing IPV4 address space is a tiny fraction of the IPV6 space. > Follow the lead of Madison Ave. ... give away samples. GIVE each > existing > address space owner (OK, not really the owner) an upsized chunk of > the new > space. Let the computers handle the application for the space, > just copy > the registration information. Each IPV4 Class C is given a range > equal in > size to a IPV4 class B. Each Class B is given a range equal to a > current > Class A. Each Class A is given a SUPER-A. Already done: every IPv4 address comes with a /48 worth of IPv6 address space, and a way to use those addresses without having access to the rest of the IPv6 internet. It's called 6to4. From tedm at ipinc.net Wed Apr 4 20:57:30 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 4 Apr 2007 17:57:30 -0700 Subject: [ppml] PPML Digest, Vol 22, Issue 9 In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Stephen J. Mahler >Sent: Wednesday, April 04, 2007 12:24 PM >To: ppml at arin.net >Subject: Re: [ppml] PPML Digest, Vol 22, Issue 9 > > >Throwing caution to the wind, and becoming involved in this discussion ... > >I suggest that the problem is not getting people out of the IPV4 address >space, the problem is getting them into the IPv6 space. If moving to IPV6 >is easy, interesting, has a clear benefit, and worked as more of a >long term >project than a flash cut... they will move. > >The existing IPV4 address space is a tiny fraction of the IPV6 space. >Follow the lead of Madison Ave. ... give away samples. GIVE each existing >address space owner (OK, not really the owner) an upsized chunk of the new >space. Let the computers handle the application for the space, just copy >the registration information. Each IPV4 Class C is given a range equal in >size to a IPV4 class B. Each Class B is given a range equal to a current >Class A. Each Class A is given a SUPER-A. > I already suggested this last week and we had some discussion on it. The biggest problem is that there's large swaths of IPv4 that was assigned pre-RIR and the holders never signed an RSA. This kind of creates a catch-22 situation; we need to move to IPv6 because large amounts of IPv4 was assigned to legacy holders who we can't tell if they are wasting it or not (but, compare the list to assigned addressing to what is in the BGP table to get some idea) but the legacy holders, having not signed an RSA, are not subject to utilization requirements that would help prevent them from wasting it. The key is to force the legacy holders to sign RSAs. To do that we have to make them come out of the woodwork and sign IPv6 allocation requests that commit them to an RSA. This is why they would never go for an auto-allocation scheme. Sure, we can auto-assign IPv6 but in order for them to use it they would have to sign an RSA for their existing IPv4 assignments in order to get the IPv6 that is auto-assigned. Consider ARIN's fee schedule. Above a /14 is $18,000.00 USD a year. Why would a legacy /8 holder who is currently paying ARIN not a cent, because they have not signed an RSA, want to sign an RSA to get auto-allocated IPv6 for free so they can start paying $18,000 a year for their /8 and be subject to utilization requirements as well? A legacy holder of a /8 IPv4 that wants IPv6 would be better off simply registering IPv6 by itself and paying much less money. In fact, that is one of the loopholes I would like to see closed in ARIN's policy. A pre-RIR /8 holder who didn't sign an RSA for the /8 could I believe go to ARIN and pay the yearly membership fee of $500 and then the minimum $500 under the fee wavier and get all the IPv6 they wanted. Of course they would be subject to an RSA for the IPv6 but according to the published policies I think they would only be required to demonstrate 80% utilization on their existing /8. In that case it would be $17,000 cheaper per year for them to NOT participate in an IPv6 auto-allocation program. >Make this the last time you have to worry about your existing address space >between now and your retirement. Make the advantage of switching to IPV6 >that you have room to operate and test for years to come. Make it a reason >to work thru the headaches of using IPV6. > I think an auto-allocation scheme would work for IPv4 holders who are paying ARIN now. What I would like to see is the separate fee schedules for IPv4 and IPv6 to disappear and there to be only a single fee schedule and both IPv4 and an equivalent amount of IPv6 be allocated on each request - in other words, an IPv4 holder would no longer pay 1 fee for IPv4 and 1 fee for IPv6, then would pay a single fee for "Amount of IP addressing" they are using. >You won't have to worry about closing down IPV4 if there are advantages to >moving to IPV6. If the only advantage to switching to IPV6 is that IPV4 is >closing down tomorrow, everyone will wait till the day before. > Then everyone will wait till the day before, because right now there is no "killer app" that is an advantage to switch to IPv6. Ted From mahler at louisiana.edu Thu Apr 5 08:05:24 2007 From: mahler at louisiana.edu (Stephen J. Mahler) Date: Thu, 5 Apr 2007 07:05:24 -0500 Subject: [ppml] PPML Digest, Vol 22, Issue 9 In-Reply-To: Message-ID: Ted: Thank you for your comments. I believe that it doesn't matter if they have signed an RIR RSA. Here is why ... The IPV4 address space represents 1/(2^96)th of the IPV6 address space. Yet it holds the most important people in the world. These are the people that need to be convinced to switch to IPV6. Even if you give each owner a larger segment as described below they represent 1/(2^88)th of the new address space. Give it away (pay exactly what your last years payment was) to anyone that has an IPV4 as of July 4th, 2007. All allocations after that date are only issued as dual assignments (one request gets some IPV4 and IPV6) with all the paperwork that a papershuffler would dream of having. Lose the tiny address space income to make the change over. If someone says they can't operate without that income, well then we really don't need change to the IPV6 address space. Sacrificing 1/(2^88) of possible income isn't a big deal. The big deal is making the current owners interested in doing the work to make the change. Just make it worth their while. ...STeve > >Throwing caution to the wind, and becoming involved in this > discussion ... > > > >I suggest that the problem is not getting people out of the IPV4 address > >space, the problem is getting them into the IPv6 space. If > moving to IPV6 > >is easy, interesting, has a clear benefit, and worked as more of a > >long term > >project than a flash cut... they will move. > > > >The existing IPV4 address space is a tiny fraction of the IPV6 space. > >Follow the lead of Madison Ave. ... give away samples. GIVE > each existing > >address space owner (OK, not really the owner) an upsized chunk > of the new > >space. Let the computers handle the application for the space, just copy > >the registration information. Each IPV4 Class C is given a > range equal in > >size to a IPV4 class B. Each Class B is given a range equal to > a current > >Class A. Each Class A is given a SUPER-A. > > > > I already suggested this last week and we had some discussion on it. The > biggest problem is that there's large swaths of IPv4 that was assigned > pre-RIR and the holders never signed an RSA. This kind of creates a > catch-22 > situation; we need to move to IPv6 because large amounts of IPv4 was > assigned to legacy holders who we can't tell if they are wasting it > or not (but, compare the list to assigned addressing to what is in the BGP > table to get some idea) but the legacy > holders, having not signed an RSA, are not subject to utilization > requirements that would help prevent them from wasting it. > > The key is to force the legacy holders to sign RSAs. To do that we have > to make them come out of the woodwork and sign IPv6 allocation requests > that commit them to an RSA. This is why they would never go for an > auto-allocation scheme. Sure, we can auto-assign IPv6 but in > order for them > to > use it they would have to sign an RSA for their existing IPv4 assignments > in order to get the IPv6 that is auto-assigned. > > Consider ARIN's fee schedule. Above a /14 is $18,000.00 USD a year. Why > would a legacy /8 holder who is currently paying ARIN not a cent, because > they > have not signed an RSA, want to sign an RSA to get auto-allocated IPv6 > for free so they can start paying $18,000 a year for their /8 and be > subject to utilization requirements as well? > > A legacy holder of a /8 IPv4 that wants IPv6 would be better off simply > registering IPv6 by itself and paying much less money. In fact, that is > one of the loopholes I would like to see closed in ARIN's policy. > > A pre-RIR /8 holder who didn't sign an RSA for the /8 could I believe > go to ARIN and pay the yearly membership fee of $500 and then the minimum > $500 under the fee wavier and get all the IPv6 they wanted. Of > course they > would be subject to an RSA for the IPv6 but according to the published > policies I think they would only be required to demonstrate 80% > utilization on their existing /8. In that case it would be $17,000 > cheaper per year for them to NOT participate in an IPv6 auto-allocation > program. > > >Make this the last time you have to worry about your existing > address space > >between now and your retirement. Make the advantage of switching to IPV6 > >that you have room to operate and test for years to come. Make > it a reason > >to work thru the headaches of using IPV6. > > > > I think an auto-allocation scheme would work for IPv4 holders who are > paying ARIN now. What I would like to see is the separate fee schedules > for IPv4 and IPv6 to disappear and there to be only a single fee schedule > and both IPv4 and an equivalent amount of IPv6 be allocated on each > request - in other words, an IPv4 holder would no longer pay 1 fee for > IPv4 and 1 fee for IPv6, then would pay a single fee for "Amount of IP > addressing" they are using. > > >You won't have to worry about closing down IPV4 if there are > advantages to > >moving to IPV6. If the only advantage to switching to IPV6 is > that IPV4 is > >closing down tomorrow, everyone will wait till the day before. > > > > Then everyone will wait till the day before, because right now there is no > "killer app" that is an advantage to switch to IPv6. > > Ted > > From Lee.Howard at stanleyassociates.com Thu Apr 5 10:01:17 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 5 Apr 2007 10:01:17 -0400 Subject: [ppml] fee clarification was: PPML Digest, Vol 22, Issue 9 In-Reply-To: Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB405741F80@CL-S-EX-1.stanleyassociates.com> When the subject of money comes up, I want to be as clear as possible. Discussions of fees really belong on the members mailing list, arin-discuss, but I personally think the debate of whether fees should be a tool in policy is appropriate here. > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Wednesday, April 04, 2007 8:58 PM > To: mahler at louisiana.edu; ppml at arin.net > Subject: Re: [ppml] PPML Digest, Vol 22, Issue 9 > > Consider ARIN's fee schedule. Above a /14 is $18,000.00 USD > a year. Why would a legacy /8 holder who is currently paying > ARIN not a cent, because they have not signed an RSA, want to > sign an RSA to get auto-allocated IPv6 for free so they can > start paying $18,000 a year for their /8 and be subject to > utilization requirements as well? http://www.arin.net/billing/fee_schedule.html Renewal fees are equal to initial registration fees only for allocations (i.e., to ISPs). Maintenance fees for assignments (i.e., to end-users) are $100 per year. This is true both in IPv4 and IPv6 (ignoring the waiver). > A legacy holder of a /8 IPv4 that wants IPv6 would be better > off simply registering IPv6 by itself and paying much less > money. In fact, that is one of the loopholes I would like to > see closed in ARIN's policy. > > A pre-RIR /8 holder who didn't sign an RSA for the /8 could I > believe go to ARIN and pay the yearly membership fee of $500 > and then the minimum $500 under the fee wavier and get all > the IPv6 they wanted. Of course they would be subject to an > RSA for the IPv6 but according to the published policies I > think they would only be required to demonstrate 80% > utilization on their existing /8. In that case it would be > $17,000 cheaper per year for them to NOT participate in an > IPv6 auto-allocation program. This loophole was intentional. Members pay either the annual allocation renewal on their IPv4 allocation, or a $500 annual renewal fee. As a member, you not only get this waiver, you also get to vote for Board and Advisory Council members, you get 2 free seats at the public policy and members meeting (transportation, room and board are still up to you), and you get to discuss fees and finances on arin-discuss. > >Make this the last time you have to worry about your > existing address > >space between now and your retirement. Make the advantage > of switching > >to IPV6 that you have room to operate and test for years to > come. Make > >it a reason to work thru the headaches of using IPV6. It's debatable whether we're there yet. Since ARINs default assignment size is /48, and default allocation size is /32, there's a lot of space for most people to work with. Is that enough to last until retirement? Depends on how much your network grows (and maybe how close you are to retirement). > > I think an auto-allocation scheme would work for IPv4 holders > who are paying ARIN now. What I would like to see is the > separate fee schedules for IPv4 and IPv6 to disappear and > there to be only a single fee schedule and both IPv4 and an > equivalent amount of IPv6 be allocated on each request - in > other words, an IPv4 holder would no longer pay 1 fee for > IPv4 and 1 fee for IPv6, then would pay a single fee for > "Amount of IP addressing" they are using. If you compare the IPv4 and IPv6 Initial Allocation and Annual Renewal Fees tables in the fee schedule, you'll see that there is a correlation. Since IPv6 initial allocation fees and IPv6 renewal fees are waived for members in good standing (whether subscriber or non-subscriber members), we're not far from this point now. I should mention that fee waivers are set to expire at the end of this calendar year. Lee > Ted From plzak at arin.net Thu Apr 5 10:25:53 2007 From: plzak at arin.net (Ray Plzak) Date: Thu, 5 Apr 2007 10:25:53 -0400 Subject: [ppml] fee clarification was: PPML Digest, Vol 22, Issue 9 In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB405741F80@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB405741F80@CL-S-EX-1.stanleyassociates.com> Message-ID: I agree that a discussion of whether to use fees as a policy tool is appropriate, however in the end, the board after consultation with the members of ARIN will decide whether or not to use such a tool. Ray > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Howard, W. Lee > Sent: Thursday, April 05, 2007 10:01 AM > To: ppml at arin.net > Subject: Re: [ppml] fee clarification was: PPML Digest, Vol 22, Issue 9 > > When the subject of money comes up, I want to be as clear as > possible. Discussions of fees really belong on the members > mailing list, arin-discuss, but I personally think the debate > of whether fees should be a tool in policy is appropriate > here. > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > Behalf Of Ted Mittelstaedt > > Sent: Wednesday, April 04, 2007 8:58 PM > > To: mahler at louisiana.edu; ppml at arin.net > > Subject: Re: [ppml] PPML Digest, Vol 22, Issue 9 > > > > Consider ARIN's fee schedule. Above a /14 is $18,000.00 USD > > a year. Why would a legacy /8 holder who is currently paying > > ARIN not a cent, because they have not signed an RSA, want to > > sign an RSA to get auto-allocated IPv6 for free so they can > > start paying $18,000 a year for their /8 and be subject to > > utilization requirements as well? > > http://www.arin.net/billing/fee_schedule.html > > Renewal fees are equal to initial registration fees only > for allocations (i.e., to ISPs). Maintenance fees for > assignments (i.e., to end-users) are $100 per year. This is > true both in IPv4 and IPv6 (ignoring the waiver). > > > A legacy holder of a /8 IPv4 that wants IPv6 would be better > > off simply registering IPv6 by itself and paying much less > > money. In fact, that is one of the loopholes I would like to > > see closed in ARIN's policy. > > > > A pre-RIR /8 holder who didn't sign an RSA for the /8 could I > > believe go to ARIN and pay the yearly membership fee of $500 > > and then the minimum $500 under the fee wavier and get all > > the IPv6 they wanted. Of course they would be subject to an > > RSA for the IPv6 but according to the published policies I > > think they would only be required to demonstrate 80% > > utilization on their existing /8. In that case it would be > > $17,000 cheaper per year for them to NOT participate in an > > IPv6 auto-allocation program. > > This loophole was intentional. Members pay either the annual > allocation renewal on their IPv4 allocation, or a $500 annual > renewal fee. As a member, you not only get this waiver, you > also get to vote for Board and Advisory Council members, you > get 2 free seats at the public policy and members meeting > (transportation, room and board are still up to you), and you > get to discuss fees and finances on arin-discuss. > > > > >Make this the last time you have to worry about your > > existing address > > >space between now and your retirement. Make the advantage > > of switching > > >to IPV6 that you have room to operate and test for years to > > come. Make > > >it a reason to work thru the headaches of using IPV6. > > It's debatable whether we're there yet. Since ARINs default > assignment size is /48, and default allocation size is /32, > there's a lot of space for most people to work with. > > Is that enough to last until retirement? Depends on how much > your network grows (and maybe how close you are to retirement). > > > > > I think an auto-allocation scheme would work for IPv4 holders > > who are paying ARIN now. What I would like to see is the > > separate fee schedules for IPv4 and IPv6 to disappear and > > there to be only a single fee schedule and both IPv4 and an > > equivalent amount of IPv6 be allocated on each request - in > > other words, an IPv4 holder would no longer pay 1 fee for > > IPv4 and 1 fee for IPv6, then would pay a single fee for > > "Amount of IP addressing" they are using. > > If you compare the IPv4 and IPv6 Initial Allocation and Annual > Renewal Fees tables in the fee schedule, you'll see that there > is a correlation. Since IPv6 initial allocation fees and > IPv6 renewal fees are waived for members in good standing > (whether subscriber or non-subscriber members), we're not far > from this point now. > > I should mention that fee waivers are set to expire at the > end of this calendar year. > > Lee > > > Ted > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From iljitsch at muada.com Thu Apr 5 16:57:50 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 5 Apr 2007 22:57:50 +0200 Subject: [ppml] PPML Digest, Vol 22, Issue 9 In-Reply-To: References: Message-ID: <0085B6D3-D708-4506-8F6E-D3641D6BC574@muada.com> On 5-apr-2007, at 14:05, Stephen J. Mahler wrote: > Give it away (pay exactly what your last years payment was) to > anyone that > has an IPV4 as of July 4th, 2007. All allocations after that date > are only > issued as dual assignments (one request gets some IPV4 and IPV6) Why is it useful to give people IPv6 address space if they don't even ask for it? From jay at handynetworks.com Thu Apr 5 20:50:30 2007 From: jay at handynetworks.com (Jay Sudowski - Handy Networks LLC) Date: Thu, 5 Apr 2007 18:50:30 -0600 Subject: [ppml] PPML Digest, Vol 22, Issue 9 In-Reply-To: <0085B6D3-D708-4506-8F6E-D3641D6BC574@muada.com> References: <0085B6D3-D708-4506-8F6E-D3641D6BC574@muada.com> Message-ID: <7EC421F755E45242A47938C3B6F634B19F51CE@hnetavail1.exchange.handynetworks.com> >> Give it away (pay exactly what your last years payment was) to >> anyone that >> has an IPV4 as of July 4th, 2007. All allocations after that date >> are only >> issued as dual assignments (one request gets some IPV4 and IPV6) >Why is it useful to give people IPv6 address space if they don't even >ask for it? Giving IPv6 allocations to everyone (and setting a far off date before IPv6 allocations will cost money) is important because: 1. Cost. At present, I will have not requested an IPv6 allocation because it's only a given that the allocation will remain cost free until Dec 31 2007. Come Dec 31 2008, I *could* end up with a $2250 invoice on my desk for an IPv6 allocation that is only useful for experimentation. If it's 100% certain that my IPv6 allocation will be free for the next 3-5 years, I would have already applied for IPv6 space. 2. Organizations find ARIN difficult to deal with. In fact, I know of many people who absolutely *hate* dealing with ARIN. They go out of their way to avoid ARIN at all costs and only contact them when it's absolutely necessary. If ARIN automatically allocates IPv6 space to every IPv4 holder, people will not have to go through the perceived trauma of initiating contact with ARIN. Sad, but true. 3. Distributing IPv6 space in a proactive manner would be a favorable action to take from a political perspective. Most politicians are ignorant about technology, but I can guarantee that if there is a major impact to consumer/business services due to depletion of IPv4 and it appears that the community did not do everything possible to affect a smooth transition to IPv6, fingers will be pointed and regulations will be enacted. ARIN should seek to insulate itself from any potential political fallout by being as proactive as possible with issuing IPv6 allocations. -Jay From Ed.Lewis at neustar.biz Fri Apr 6 10:14:13 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 6 Apr 2007 10:14:13 -0400 Subject: [ppml] 2046 was Re: Summary of Trial Balloons In-Reply-To: <1582DCBFF968F044A9A910C0AB177C9012FF96@cliff.cdi.local> References: <1582DCBFF968F044A9A910C0AB177C9012FF96@cliff.cdi.local> Message-ID: At 16:34 -0500 3/30/07, Jim Weyand wrote: >It seems like it is time to start the relatively hard work of actually >developing alternative policy proposals to deal with the IPv4 Address >Exhaustion Issue. I'm following up on this message just as an anchor point, having read the large volume of mail on this. I'll start with the negative statements as I don't have a divine answer myself and I have doubts on many of the proposals to date. I don't think that ARIN has as a goal of promoting IPv6 over IPv4. This isn't about one technology or the other. I think that the "battle" over that has to happen in protocol and applications arenas and ultimately in the marketplace. But I still think it is important that ARIN help wean us off of IPv4. I don't really care about address reclamation procedures as answers to the problem. Although I am all for efficient use of the resource and for ARIN taking as active a role as permitted in doing this, IPv4 ultimately will not support a truly global Internet - not in my opinion. Squeezing a few more years only postpones the inevitable. I don't think that ARIN can really use any economic tools (I won't say "fees" to keep Lee happy) to make IPv6 adoption happen - whether it is "taxing" IPv4 or giving/assigning away IPv6 for free. The reason is that the cost of moving to IPv6 is not just the cost of IP service, there are other costs involved. My motivation for caring about this issue is that a future in which we have a segmented network, whether it is IPv4 in North America and IPv6 in Asia or a plethora of NAT boxes or 6-to-4 boxes gluing it all together, is not desirable. We are already saddled with "legacy IP resource assignment" - the swamp, the pre-RIR assigned space with unclear policy and "ownership." Do we also want to see a "black-market" if you will of IP addressing resources? Wouldn't that create an economic drag on this system? The are a lot of hypothetical futures already presented and we can argue over who's more right but I think that would be futile. We can also argue over a lot of other details, such as how big a prefix an ISP should allocate to an end user and so on. Ultimately though we (on this list) need to figure out what ARIN policy for address registration is needed (and perhaps that answer is to do nothing). >8) An informal proposal to get endusers to demand access to IPv6 networks >by creating a media storm similar to Y2K. Of all of the trial balloons that are listed, this seems the oddest but also the most alluring. I don't like the idea of a media storm because that's all bluff and bluster. But there is a parallel to the Y2K situation - or maybe the year that 32 bit clocks roll over to "0" again, which is what 2036-2038? I've forgotten. The parallel is that we are running towards a point in history when a one-time engineering assumption is about to be broken - that 32 bits were enough for an address. It's like explaining to someone that "1984" wasn't a year, it is a futuristic novel. Perhaps the greatest benefit ARIN is providing here is giving us a forum to discuss the issue. What I am thinking of is the post from Jason Schiller giving details on the problems an ISP faces in providing IPv6 service. We have a few opinions on what holds enterprises back, what motivates home consumers, and my perspective is from someone that has a service that is or ought to be provided over IPv6 in addition to IPv4 (as long as they are the two choices). I think that the bottlenecks to IPv6 adoption have already been presented on this list. I am not clear on what is the easiest one to remove nor the most important one to remove. I am not sure that a media barrage about IP6 would help because it might actually hurt our adoption of IPv6 - a vendor is demanding a large license fee for the software that does IPv6 on one of our "front matter" boxes. ("You need this new technology right? So you will pay more!") At the APNIC meeting, the least appealing part of ARIN's 2007-12 (12! It's only April) was the termination date. BTW, here are excerpted notes from APNIC on the discussion: http://www.apnic.net/mailing-lists/sig-policy/archive/2007/03/msg00015.html #Discussion at APNIC 23 #---------------------- # #There was general support the following three principals in the #proposal: # # - Global synchronization # - Keeping current practices until the last moment # - Recovery of unused address space should be discussed # separately # #The remaining principle, "Some Blocks to be left", was split into #two: # # - Need to define the last date of allocation in advance # - Keep some blocks reserved after the defined last date of # allocation # #There was no consensus on these two elements of the remaining #principle. I think that the first three principles are okay and I don't see the need really to keep some reserve. But I am more receptive to a termination date of the use of IPv4 - note I said "use" and not "allocation." I know, it's ludicrous, it's crazy. But maybe if we state that in the year 2046 IPv4 will be no longer recognized on the public Internet there will be just the right movement to accomplish - well - whatever "we" want. Of course, that's not something ARIN does - but maybe a global policy of retiring the IPv4 number resource by 2046 can be carried to IANA? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From iljitsch at muada.com Fri Apr 6 11:21:20 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 6 Apr 2007 17:21:20 +0200 Subject: [ppml] PPML Digest, Vol 22, Issue 9 In-Reply-To: <7EC421F755E45242A47938C3B6F634B19F51CE@hnetavail1.exchange.handynetworks.com> References: <0085B6D3-D708-4506-8F6E-D3641D6BC574@muada.com> <7EC421F755E45242A47938C3B6F634B19F51CE@hnetavail1.exchange.handynetworks.com> Message-ID: On 6-apr-2007, at 2:50, Jay Sudowski - Handy Networks LLC wrote: >> Why is it useful to give people IPv6 address space if they don't even >> ask for it? > Giving IPv6 allocations to everyone (and setting a far off date before > IPv6 allocations will cost money) is important because: [...] These are all issues that can and should be fixed in ways other than giving out IPv6 address space to people who didn't specifically ask for it. Addresses are necessary to make devices connected to the internet communicate. Please don't attach additional, unrelated uses. From dlw+arin at tellme.com Fri Apr 6 11:59:05 2007 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 6 Apr 2007 08:59:05 -0700 Subject: [ppml] IPv4 exhaustion - so what? Message-ID: <20070406155904.GF10559@shell01.corp.tellme.com> This entire conversation about what to do about v4 exhaustion is nice, but hardly relevant to some upcoming events. This entire discussion will make a great topic for the open policy hour at the next meeting. At the moment, however, I'd like to see more feedback on some of the existing policy proposals. There's been nearly zero feedback or discussion on all but one or two of *twelve* that are on the agenda. I can't imagine that we'll just rubberstamp ten or eleven of them, and spend the rest of the time on just a couple. Surely someone out there is either for or against some of the current proposals. Can we focus on something besides the present topic, please? -David From BillD at cait.wustl.edu Fri Apr 6 12:00:24 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 6 Apr 2007 11:00:24 -0500 Subject: [ppml] IPv4 exhaustion - so what? In-Reply-To: <20070406155904.GF10559@shell01.corp.tellme.com> Message-ID: Ok....good idea... You begin... Bill Darte ARIN AC > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of David Williamson > Sent: Friday, April 06, 2007 10:59 AM > To: ppml at arin.net > Subject: [ppml] IPv4 exhaustion - so what? > > > This entire conversation about what to do about v4 exhaustion > is nice, but hardly relevant to some upcoming events. This > entire discussion will make a great topic for the open policy > hour at the next meeting. > > At the moment, however, I'd like to see more feedback on some > of the existing policy proposals. There's been nearly zero > feedback or discussion on all but one or two of *twelve* that > are on the agenda. I can't imagine that we'll just > rubberstamp ten or eleven of them, and spend the rest of the > time on just a couple. Surely someone out there is either > for or against some of the current proposals. > > Can we focus on something besides the present topic, please? > > -David > > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). Manage your mailing list > subscription at: http://lists.arin.net/mailman/listinfo/ppml > From dlw+arin at tellme.com Fri Apr 6 12:16:20 2007 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 6 Apr 2007 09:16:20 -0700 Subject: [ppml] Policy Proposal 2007-7: Creation of Policy for Subsequent End-User IP Requests/Assignments Message-ID: <20070406161620.GJ10559@shell01.corp.tellme.com> Since no one seems to have commented on this or the other policies that appear to be designed to clean up parts of the NRPM, I will. I entirely support all of this proposal, as well as 2007-8, 2007-9, 2007-10, and 2007-11. I think the authors should be thanked for putting together a set of proposals that will rationalize some rather confusing parts of the NRPM. I know that we'll consider each of these five proposals independently, but I hope that all of them will be passed with minimal criticism, as all of them simply "make sense". -David > On Fri, Mar 02, 2007 at 12:13:31PM -0500, Member Services wrote: > > On 1 March 2007 the ARIN Advisory Council (AC) concluded its review > > of 'Creation of Policy for Subsequent End-User IP > > Requests/Assignments' and accepted it as a formal policy proposal for > > discussion by the community. > > > > The proposal is designated Policy Proposal 2007-7: Creation of Policy > > for Subsequent End-User IP Requests/Assignments The proposal text is > > below and can be found at: > > http://www.arin.net/policy/proposals/2007_7.html > > > > All persons in the community are encouraged to discuss Policy > > Proposal 2007-7 prior to it being presented at the ARIN Public Policy > > Meeting in San Juan, Puerto Rico, 23-24 April 2007. Both the discussion > > on the Public Policy Mailing List and at the Public Policy Meeting will > > be used to determine the community consensus regarding this policy proposal. > > > > The ARIN Internet Resource Policy Evaluation Process can be found at: > > http://www.arin.net/policy/irpep.html > > > > ARIN's Policy Proposal Archive can be found at: > > http://www.arin.net/policy/proposals/proposal_archive.html > > > > Regards, > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > Policy Proposal 2007-7: Creation of Policy for Subsequent End-User IP > > Requests/Assignments > > > > Author: Alex Rubenstein > > > > Proposal Version: 1 > > > > Submission Date: 15 February 2007 > > > > Proposal type: New > > > > Policy term: Permanent > > > > Policy statement: > > > > 4.3.6, Additional Assignments > > > > "In order to justify an additional assignment, end-users must have > > efficiently utilized at least 80% of all previous assignments, and must > > provide ARIN with utilization details. The prefix size for an additional > > assignment is determined by applying policies 4.3.2, and 4.3.3." > > > > Rationale: > > > > There are no published criteria for additional assignment requests from > > end-user networks. NRPM 4.3 seems to only cover initial assignments. > > NRPM 4.3.3 states, in part, "Requesters must show exactly how previous > > address assignments have been utilized and must provide appropriate > > details to verify their one-year growth projection." Unfortunately, the > > above text does not specify any metrics for ARIN staff to apply when > > determining if an additional assignment is justified. Though most > > end-users only get one assignment, some end-users request a 2nd or 3rd > > or Nth assignment. > > > > Currently, the ARIN staff applies what they perceive to be "efficient > > utilization" criteria; for instance, the end-user must have utilized at > > least 80% of last assignment and must provide ARIN with utilization details. > > > > Timetable for implementation: Immediate > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml From dlw+arin at tellme.com Fri Apr 6 12:20:34 2007 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 6 Apr 2007 09:20:34 -0700 Subject: [ppml] Policy Proposal 2007-1: Reinstatement of PGP Authentication Method In-Reply-To: <45D634B6.8090600@arin.net> References: <45D634B6.8090600@arin.net> Message-ID: <20070406162034.GM10559@shell01.corp.tellme.com> The below snippet outlines exactly why I am entirely in favor of this proposal. Let's get this one implemented in a hurry! -David On Fri, Feb 16, 2007 at 05:48:22PM -0500, Member Services wrote: > We need to get PGP support reinstated, so that our records can be > protected against hijacking and vandalism, and so we won't look like > idiots as the only one of the five regions that can't figure this stuff out. From stephen at sprunk.org Fri Apr 6 12:55:37 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 6 Apr 2007 11:55:37 -0500 Subject: [ppml] IPv4 exhaustion - so what? References: <20070406155904.GF10559@shell01.corp.tellme.com> Message-ID: <00bd01c7786c$7d58c840$4a3816ac@atlanta.polycom.com> Thus spake "David Williamson" > At the moment, however, I'd like to see more feedback on some > of the existing policy proposals. There's been nearly zero > feedback or discussion on all but one or two of *twelve* that are > on the agenda. I can't imagine that we'll just rubberstamp ten or > eleven of them, and spend the rest of the time on just a couple. > Surely someone out there is either for or against some of the > current proposals. Okay, I'll take the bait. 2006-7: I voiced my disagreement with this proposal when it was introduced, based on a lack of proven need for the change and the likely detrimental effects it would have on the DFZ -- not that ARIN controls the DFZ, but we have a long history of considering the effects of policies on it... 2007-1, -2, -3: These seem very straightforward, documenting what exists. I don't see any reason for debate; they truly are rubber-stamp items. 2007-4: Again, there's not much room for debate; all policies are "interim" in some sense, and this language is a hold-over from the draft global IPv6 policy. We need a lot more clean-up proposals like this, which will also likely not cause much debate as long as they're only changing the wording and not actual policy. 2007-5: I disagree with the supposed lack of implications of this policy. /48 should be enough for all but the largest sites, and those sites most likely will be getting direct assignments from ARIN, not from LIRs. If LIRs are allowed to assign excessive amounts of space to end users with no oversight, that will increase the amount/size of allocations ARIN needs to make to LIRs. Absent an actual policy on what justifies an assignment greater than /48, we should continue to require ARIN oversight of these assignments. Since no such policy has been submitted, I must be against 2007-5. 2007-6: I honestly have no opinion on this policy; I'll let the folks who actually live in the DFZ figure it out. 2007-7 through -11: These appear to be requests from the ARIN staff, either directly or indirectly, and are clarifying existing policy that is currently difficult to implement or documenting unwritten policies, not making any substantive changes that would require much debate. If anyone disagrees with them, I invite them to comment, but I don't see much to disagree with. 2007-12: I think my disagreement with this proposal, and the reasons why, is well-documented by now :) S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From BillD at cait.wustl.edu Fri Apr 6 13:17:01 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 6 Apr 2007 12:17:01 -0500 Subject: [ppml] IPv4 exhaustion - so what? In-Reply-To: <00bd01c7786c$7d58c840$4a3816ac@atlanta.polycom.com> Message-ID: Thanks Stephen (and David) Going into the PR public policy meeting, getting this kind of straight-forward 'for or against' itemizing makes for easy assessment by the AC. Don't get me wrong. We would all like to see comments and explanations, but in the end...please state your up or down opinion. And let's see....if another hundred or two of you do this we will have some real idea of what's up... Please don't think to yourself that others have expressed your opinion...we need your personal sentiment expressed. Thanks to all..... Bill Darte ARIN AC > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Stephen Sprunk > Sent: Friday, April 06, 2007 11:56 AM > To: David Williamson > Cc: ARIN PPML > Subject: Re: [ppml] IPv4 exhaustion - so what? > > > Thus spake "David Williamson" > > At the moment, however, I'd like to see more feedback on > some of the > > existing policy proposals. There's been nearly zero feedback or > > discussion on all but one or two of *twelve* that are on > the agenda. > > I can't imagine that we'll just rubberstamp ten or eleven > of them, and > > spend the rest of the time on just a couple. Surely someone > out there > > is either for or against some of the current proposals. > > Okay, I'll take the bait. > > 2006-7: I voiced my disagreement with this proposal when it > was introduced, > based on a lack of proven need for the change and the likely > detrimental > effects it would have on the DFZ -- not that ARIN controls > the DFZ, but we > have a long history of considering the effects of policies on it... > > 2007-1, -2, -3: These seem very straightforward, documenting > what exists. I > don't see any reason for debate; they truly are rubber-stamp items. > > 2007-4: Again, there's not much room for debate; all policies > are "interim" > in some sense, and this language is a hold-over from the > draft global IPv6 > policy. We need a lot more clean-up proposals like this, > which will also > likely not cause much debate as long as they're only changing > the wording > and not actual policy. > > 2007-5: I disagree with the supposed lack of implications of > this policy. > /48 should be enough for all but the largest sites, and those > sites most > likely will be getting direct assignments from ARIN, not from > LIRs. If LIRs > are allowed to assign excessive amounts of space to end users with no > oversight, that will increase the amount/size of allocations > ARIN needs to > make to LIRs. Absent an actual policy on what justifies an > assignment > greater than /48, we should continue to require ARIN > oversight of these > assignments. Since no such policy has been submitted, I must > be against > 2007-5. > > 2007-6: I honestly have no opinion on this policy; I'll let > the folks who > actually live in the DFZ figure it out. > > 2007-7 through -11: These appear to be requests from the ARIN > staff, either > directly or indirectly, and are clarifying existing policy > that is currently > difficult to implement or documenting unwritten policies, not > making any > substantive changes that would require much debate. If > anyone disagrees > with them, I invite them to comment, but I don't see much to > disagree with. > > 2007-12: I think my disagreement with this proposal, and the > reasons why, is > well-documented by now :) > > S > > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov > > > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). Manage your mailing list > subscription at: http://lists.arin.net/mailman/listinfo/ppml > From Ed.Lewis at neustar.biz Fri Apr 6 13:47:24 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 6 Apr 2007 13:47:24 -0400 Subject: [ppml] the "other" policy proposals Message-ID: http://www.arin.net/policy/proposals/2006_7.html Undecided Q: if I did support the proposal, I'd make the new text can justify intent to announce the requested IPv6 address space within one year I don't think that this has to be an organization "new" to the business. But I wonder what the intent is - is this supposed to be the means for getting Provider Independent space? I'd really be cautious about allowing this new avenue to be open only to those unfamiliar with the Internet. http://www.arin.net/policy/proposals/2007_1.html http://www.arin.net/policy/proposals/2007_2.html http://www.arin.net/policy/proposals/2007_3.html For as much as is on the surface, but against if the method appears in WhoIs. This is a dumb question, but these are to be implemented in order, 1, 2, 3, and if 1 is not approved 2 fails, if 2 fails, 3 fails, right? "Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached." ... but the "intentionally left blank" comments are interdependent and the "UPDATES TO" in the first policy mention the other two approaches. Will ARIN match the security mechanism used in the response to the security of the object? If a POC uses PGP, ARIN responds with PGP, if the POC uses X509, will ARIN? Will the authentication method in use by a POC be exposed in WhoIs? (I hope not, so as not to advertise the mail-from users). http://www.arin.net/policy/proposals/2007_4.html Undecided. I don't know. Has the policy really been changed - or maybe I should ask, does ARIN have interim policies? Is RFC 2373bis now RFC 3513? Are the references up to date? http://www.arin.net/policy/proposals/2007_5.html For. This I am for - I think that ARIN policies ought to care solely about the justification to get more space (or retain space) and not how assigned/allocated space is redelegated. http://www.arin.net/policy/proposals/2007_6.html For. Sounds good too - speaking not from hands-on experience, if a user only needs a /24 meaning that's enough for their addressing needs and they can get someone to route it, then why waste 75%? I did have an earlier question on this (whether it is true that a /24 is considered "always" routable.) http://www.arin.net/policy/proposals/2007_7.html For this one, my earlier question was answered. http://www.arin.net/policy/proposals/2007_8.html Undecided. This caused a lot of concern on my part. I'd have to go reread what I already wrote a month back. http://www.arin.net/policy/proposals/2007_9.html For that one. http://www.arin.net/policy/proposals/2007_10.html For that. http://www.arin.net/policy/proposals/2007_11.html Fer that. http://www.arin.net/policy/proposals/2007_12.html Comments elsewhere... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From arin-contact at dirtside.com Fri Apr 6 15:35:16 2007 From: arin-contact at dirtside.com (William Herrin) Date: Fri, 6 Apr 2007 15:35:16 -0400 Subject: [ppml] PPML Digest, Vol 22, Issue 12 In-Reply-To: References: Message-ID: <3c3e3fca0704061235q7b60fa46i1bdc8a278d8c2ca8@mail.gmail.com> On 4/6/07, ppml-request at arin.net < ppml-request at arin.net> wrote: > > Date: Fri, 6 Apr 2007 08:59:05 -0700 > From: David Williamson < dlw+arin at tellme.com> > Subject: [ppml] IPv4 exhaustion - so what? > > At the moment, however, I'd like to see more feedback on some of the > existing policy proposals. There's been nearly zero feedback or > discussion on all but one or two of *twelve* that are on the agenda. I > can't imagine that we'll just rubberstamp ten or eleven of them, and > spend the rest of the time on just a couple. Surely someone out there > is either for or against some of the current proposals. > David, Apologies in advance if I'm overly confrontational. I'm not so sure its a question of being for or against the propsals. Most of the proposed changes strike me as tweaking the absurdity of already dysfunctional policies. That's http://www.arin.net/policy/proposals/proposal_archive.html , yes? 2006-7: Not too many people WANT IPv6 space just now, so what possible difference does it make whether they're qualified to get it? Open it up wide and worry about qualifications after a reasonable percent of the space is actually in use. At this point in IPv6's adoption, almost ANY policy is counterproductive to its deployment. Play policy wonk if you want but don't imagine that doing so helps. Also, as another poster pointed out, it would be very helpful if every IPv4 allocation mapped directly to an IPv6 allocation so that folks who already hold v4 addresses can start working on v6 deployments without talking to ARIN or anybody else. That holds me back more than any other single thing: I'd start tinkering but its not worth the effort to talk to ARIN first. 2007-1: Why is ARIN still using email for this process anyway? 1997 was a long time ago. The process is tailor made for a web app, perhaps with email confirmations, and such an app can be reasonably locked down irrespective of PGP. Worrying about email authentication entirely misses the mark. 2007-2: Same. See 2007-1. 2007-3: Same. See 2007-1. 2007-4: See 2006-7. 2007-5: Same. See 2006-7. 2007-6: Seems to me that discontinuing "class C" assignments was intended to overcome late-90's router memory limitations. Is that still a significant issue? I'll leave it to folks more qualified than I am. 2007-7: Fine. 2007-8: You can revise this until you're old and gray and if transfers still require ARINs approval the only result will be networks that are re-routed in the BGP table with only a postal address update to ARIN. IP address space is an asset and folks will treat it like an asset. Treating address space as something else, something its obviously not, merely discourages people from talking with ARIN or taking it seriously. 2007-9: Shouldn't we be doing things to deliberately discourage folks from acquiring large quantities of IPv4 space? Plus there's a saying I'm fond of: "Your lack of planning is not my emergency." MSOs deploying CMTS' generally know they're doing it more than a year in advance. They have to: it takes a lot of money and manpower. How reasonable can their IP address planning actually be if they need the IP address component of that to turn around on an extremely short schedule? Answer: it can't. 2007-10: See 2007-9. 2007-11: Fine. 2007-12: You'll never make it stick. It'll turn out worse than the regularly postponed end of analog TV with ARIN as the punching bag for all sides. As at least a couple of the other posters have pointed out, the practical way to solve this is with economics: As exhaustion approaches, make it so holding IP addresses becomes progressively more expensive for everybody in direct proportion to the number of addresses held. Sooner or later you hit an equilibrium where the folks abandoning address space equal the folks requesting new space. Of course, it has to be in direct proportion to the number of addresses held. If it continues to cost much less per IP address to hold a /12 than it does to hold a /22 then increasing the cost would only serve to destroy the little guy. Hey, you asked what I really thought. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.hannigan at batelnet.bs Fri Apr 6 18:48:05 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Fri, 06 Apr 2007 18:48:05 -0400 Subject: [ppml] IPv4 exhaustion - so what? Message-ID: <4616ce25.1bb.364b.27035@batelnet.bs> > > 2007-1, -2, -3: These seem very straightforward, > documenting what exists. I don't see any reason for > debate; they truly are rubber-stamp items. Guardian was NetSol, not ARIN. Are you sure this functionality already exists? I don't remember it post NetSol. I do remember being converted to MH309-ARIN though. Grr. -M< From stephen at sprunk.org Fri Apr 6 19:24:03 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 6 Apr 2007 18:24:03 -0500 Subject: [ppml] PPML Digest, Vol 22, Issue 12 References: <3c3e3fca0704061235q7b60fa46i1bdc8a278d8c2ca8@mail.gmail.com> Message-ID: <023e01c778a4$1a4779d0$4a3816ac@atlanta.polycom.com> Thus spake William Herrin > I'm not so sure its a question of being for or against the propsals. > Most of the proposed changes strike me as tweaking the > absurdity of already dysfunctional policies. While some folks may be inclined to agree with that opinion, the fact is that these are the policies that ARIN needs to approve or disapprove at the coming meeting, and the cut-off date for new proposals has passed. > 2006-7: Not too many people WANT IPv6 space just now, so > what possible difference does it make whether they're qualified > to get it? Open it up wide and worry about qualifications after > a reasonable percent of the space is actually in use. > > At this point in IPv6's adoption, almost ANY policy is > counterproductive to its deployment. Play policy wonk if you > want but don't imagine that doing so helps. One of the concerns that has been voiced in the past is that opening the policies too wide may create a land-rush effect and we'll be forced to drastically alter policies in the future, creating a situation where early adopters get things that later adopters cannot. This accusation has been repeatedly leveled at the US in particular by folks overseas, since we gobbled up most of the IPv4 space before they got on the 'Net, leaving them very little. We're trying to prevent that from happening again, and the policies are still so liberal nobody should have any trouble getting v6 space if they have even the slightest need for it. Discussion of what to do for people who haven't requested v6 space is another topic, and IMHO it's best to postpone that until after the upcoming meeting so that we can work on the next round of proposals. > 2007-1: Why is ARIN still using email for this process anyway? > 1997 was a long time ago. The process is tailor made for a web > app, perhaps with email confirmations, and such an app can > be reasonably locked down irrespective of PGP. Worrying > about email authentication entirely misses the mark. > > 2007-2: Same. See 2007-1. > > 2007-3: Same. See 2007-1. If you only fill out a handful of requests/SWIPs per year, sure. However, larger ISPs may be sending in several hundred per day as customers are turned on and off, and they have automated systems that generate the templates and send them off without requiring a legion of NOC folks to click their way through forms on ARIN's web site. Ideally one would define some sort of RPC mechanism to do this without resorting to email, but the email mechanism has been in place for over a decade and won't go away any time soon. > 2007-9: Shouldn't we be doing things to deliberately discourage > folks from acquiring large quantities of IPv4 space? Plus there's > a saying I'm fond of: "Your lack of planning is not my emergency." The policy already exists; this change merely allows ARIN to issue a single larger block instead of many smaller blocks. That's a good thing. And, as the policy notes, this policy shouldn't be used that often anyways, but it's nice to have it if you're the one who gets a sudden burst of customer demand that blows up the projections you've been basing your occasional requests on. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From stephen at sprunk.org Fri Apr 6 19:30:18 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 6 Apr 2007 18:30:18 -0500 Subject: [ppml] IPv4 exhaustion - so what? References: <4616ce25.1bb.364b.27035@batelnet.bs> Message-ID: <024101c778a4$1aabb9e0$4a3816ac@atlanta.polycom.com> Thus spake "Martin Hannigan" >> 2007-1, -2, -3: These seem very straightforward, >> documenting what exists. I don't see any reason for >> debate; they truly are rubber-stamp items. > > Guardian was NetSol, not ARIN. Are you sure this functionality > already exists? I don't remember it post NetSol. I do remember > being converted to MH309-ARIN though. Grr. Oops, correction noted on the PGP authentication method. Still, this merely calls for reinstating what once existed, and unless someone expresses a specific objection to PGP being reintroduced, I consider it a rubber-stamp item. It worked fine in the past, the other RIRs all have it, and its use here will be optional if it passes, so the only objection I can see would be coming from the staffers who have to figure out how to reimplement it... S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From woody at pch.net Fri Apr 6 22:34:51 2007 From: woody at pch.net (Bill Woodcock) Date: Fri, 6 Apr 2007 19:34:51 -0700 (PDT) Subject: [ppml] the "other" policy proposals In-Reply-To: References: Message-ID: > http://www.arin.net/policy/proposals/2007_1.html > http://www.arin.net/policy/proposals/2007_2.html > http://www.arin.net/policy/proposals/2007_3.html > > For as much as is on the surface, but against if the method appears in WhoIs. There's no requirement for it to do so, and I agree, that would be an ill-conceived implementation. > This is a dumb question, but these are to be implemented in order, 1, > 2, 3, and if 1 is not approved 2 fails, if 2 fails, 3 fails, right? Correct. If 1 fails, we will immediately withdraw 2 and 3, since they would no longer serve any function. > Will ARIN match the security mechanism used in the response to the > security of the object? If a POC uses PGP, ARIN responds with PGP, > if the POC uses X509, will ARIN? That would be the sensible thing to do, it seems to me. We didn't want to get into over-specifying how all this should be done. The idea of the proposal was to define a set of minimum needs, rather than detail an exact implementation, which we feel can better be arrived at by staff interacting with membership in the real world. -Bill From woody at pch.net Fri Apr 6 23:11:59 2007 From: woody at pch.net (Bill Woodcock) Date: Fri, 6 Apr 2007 20:11:59 -0700 (PDT) Subject: [ppml] IPv4 exhaustion - so what? In-Reply-To: <4616ce25.1bb.364b.27035@batelnet.bs> References: <4616ce25.1bb.364b.27035@batelnet.bs> Message-ID: > Are you sure this functionality already exists? It exists in the other four RIRs, and we had it prior to ARIN. The fact that it _isn't_ presently available to us is exactly what the policy addresses. The policy doesn't claim that ARIN has secretly implemented it and is hiding it from us. -Bill From martin.hannigan at batelnet.bs Sat Apr 7 03:51:17 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Sat, 07 Apr 2007 03:51:17 -0400 Subject: [ppml] IPv4 exhaustion - so what? Message-ID: <46174d75.225.3a03.26374@batelnet.bs> ----- Original Message ----- From: Bill Woodcock To: Martin Hannigan Cc: Stephen Sprunk , David Williamson , ARIN PPML Subject: Re: [ppml] IPv4 exhaustion - so what? Date: Fri, 6 Apr 2007 20:11:59 -0700 (PDT) > > Are you sure this functionality already exists? > > It exists in the other four RIRs, and we had it prior to > ARIN. The fact that it _isn't_ presently available to us > is exactly what the policy addresses. The policy doesn't > claim that ARIN has secretly implemented it and is hiding > it from us. This is ARIN, not the "other" four RIR's, nor is it NSI. Nobody has claimed that is has been secretly implemented, but there seems to be a belief that there is a knob to turn it on and off. Please, by all means, set us straight. -M< From martin.hannigan at batelnet.bs Sat Apr 7 04:03:22 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Sat, 07 Apr 2007 04:03:22 -0400 Subject: [ppml] the "other" policy proposals Message-ID: <4617504a.29f.3a20.7557@batelnet.bs> > > http://www.arin.net/policy/proposals/2007_1.html > > http://www.arin.net/policy/proposals/2007_2.html > > http://www.arin.net/policy/proposals/2007_3.html > > > > For as much as is on the surface, but against if the > method appears in WhoIs. > > There's no requirement for it to do so, and I agree, that > would be an ill-conceived implementation. Should Board Members be proposing, and defending, proposed policies? This seems to border on a coerced confession to some extent, something that "appears" to carry the full weight of the board. Just thinking out loud a bit. -M< From jordi.palet at consulintel.es Sat Apr 7 03:51:17 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 07 Apr 2007 09:51:17 +0200 Subject: [ppml] the "other" policy proposals In-Reply-To: Message-ID: Hi Ed, First thanks for the inputs. Then, clarification regarding 2006-7. My original proposal was probably closer to the text that you're suggesting, and not restricted to "new". However the previous round of comments in the list was appearing as most of the folks participating prefer what we have now. In favor of the existing text I will say that those that supported the previous version also should support this one (seems to me better to have this than nothing), as it is somehow more restrictive, but at least a first step towards the objective, and if deemed necessary, we could propose in the future, if this version gets approved, new modifications. And to make it very clear this is NOT intended at all to be a new path for PI. Last, to explain again the intend of the proposal: There are ISPs (not end-users) that can't start IPv6 services unless they start also before with IPv4 and they come back for IPv6. But is even more important to realize that ISPs may have plans for less than 200 customers (and a good business plan behind even if this is not the ARIN question to look at) and still have the right to access to IPv6 (and looking to their upstream is not a solution as they may want to avoid depending on addresses from others to avoid renumbering or to allow multihoming). In the last meeting "open policy" session, a couple of folks (ISPs) clearly indicated that they are in this situation. I wish they speak up *now* especially if they aren't coming to the meeting. Regarding 2007-4: All policies are "interim" in the sense that they are subjected to changes. So why the other policies don't say so ? It is a question of fairness and avoiding what some folks when reading the policy could consider as "oh IPv6 is still interim, not good, let's wait". I will say that if we are not in favor of this change, we should write interim in all the other policies also. Regards, Jordi > De: Edward Lewis > Responder a: > Fecha: Fri, 6 Apr 2007 13:47:24 -0400 > Para: > CC: > Asunto: [ppml] the "other" policy proposals > > http://www.arin.net/policy/proposals/2006_7.html > > Undecided > > Q: if I did support the proposal, I'd make the new text > > can justify intent to announce the requested IPv6 address space within one > year > > I don't think that this has to be an organization "new" to the business. > > But I wonder what the intent is - is this supposed to be the means > for getting Provider Independent space? I'd really be cautious about > allowing this new avenue to be open only to those unfamiliar with the > Internet. > > http://www.arin.net/policy/proposals/2007_1.html > http://www.arin.net/policy/proposals/2007_2.html > http://www.arin.net/policy/proposals/2007_3.html > > For as much as is on the surface, but against if the method appears in WhoIs. > > This is a dumb question, but these are to be implemented in order, 1, > 2, 3, and if 1 is not approved 2 fails, if 2 fails, 3 fails, right? > > "Because the specific wording of the documentation may be subject to > debate, and is in no way interdependent upon the documentation of the > other two methods, it is being proposed in a separate policy, so that > consensus may be more easily reached." ... but the "intentionally > left blank" comments are interdependent and the "UPDATES TO" in the > first policy mention the other two approaches. > > Will ARIN match the security mechanism used in the response to the > security of the object? If a POC uses PGP, ARIN responds with PGP, > if the POC uses X509, will ARIN? > > Will the authentication method in use by a POC be exposed in WhoIs? > (I hope not, so as not to advertise the mail-from users). > > http://www.arin.net/policy/proposals/2007_4.html > > Undecided. > > I don't know. Has the policy really been changed - or maybe I should > ask, does ARIN have interim policies? > > Is RFC 2373bis now RFC 3513? Are the references up to date? > > http://www.arin.net/policy/proposals/2007_5.html > > For. > > This I am for - I think that ARIN policies ought to care solely about > the justification to get more space (or retain space) and not how > assigned/allocated space is redelegated. > > http://www.arin.net/policy/proposals/2007_6.html > > For. > > Sounds good too - speaking not from hands-on experience, if a user > only needs a /24 meaning that's enough for their addressing needs and > they can get someone to route it, then why waste 75%? I did have an > earlier question on this (whether it is true that a /24 is considered > "always" routable.) > > http://www.arin.net/policy/proposals/2007_7.html > > For this one, my earlier question was answered. > > http://www.arin.net/policy/proposals/2007_8.html > > Undecided. This caused a lot of concern on my part. I'd have to go > reread what I already wrote a month back. > > http://www.arin.net/policy/proposals/2007_9.html > > For that one. > > http://www.arin.net/policy/proposals/2007_10.html > > For that. > > http://www.arin.net/policy/proposals/2007_11.html > > Fer that. > > http://www.arin.net/policy/proposals/2007_12.html > > Comments elsewhere... > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > Sarcasm doesn't scale. > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** 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 michael.dillon at bt.com Sat Apr 7 15:26:22 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 7 Apr 2007 20:26:22 +0100 Subject: [ppml] PPML Digest, Vol 22, Issue 9 In-Reply-To: <7EC421F755E45242A47938C3B6F634B19F51CE@hnetavail1.exchange.handynetworks.com> Message-ID: > Giving IPv6 allocations to everyone (and setting a far off date before > IPv6 allocations will cost money) is important because: > > 1. Cost. At present, I will have not requested an IPv6 allocation > because it's only a given that the allocation will remain cost free > until Dec 31 2007. Come Dec 31 2008, I *could* end up with a $2250 > invoice on my desk for an IPv6 allocation that is only useful for > experimentation. If it's 100% certain that my IPv6 allocation will be > free for the next 3-5 years, I would have already applied for IPv6 > space. I strongly disagree with the idea of giving every IPv4 resource holder an IPv6 allocation/assignment without them asking for it. The registry needs accurate information about every blocki issued, and you lose the opportunity to collect that when you issue blocks with no prior interaction with the recipient. However, it seems to me that it is a good idea to officially recognize which IPv6 are being used in various ramp up activities but are not used in production. It is also a good idea to have a separate fee schedule for such blocks. Maybe not free, but as long as it is a separate fee schedule, we can argue the amounts later. Also, it seems to me that through policy we could specify that there be a separate fee schedule but we do not have the power to specify amounts. --Michael Dillon From woody at pch.net Sat Apr 7 21:51:51 2007 From: woody at pch.net (Bill Woodcock) Date: Sat, 7 Apr 2007 18:51:51 -0700 (PDT) Subject: [ppml] IPv4 exhaustion - so what? In-Reply-To: <46174d75.225.3a03.26374@batelnet.bs> References: <46174d75.225.3a03.26374@batelnet.bs> Message-ID: On Sat, 7 Apr 2007, Martin Hannigan wrote: > This is ARIN, not the "other" four RIR's, nor is it NSI. I don't think I'm getting your point, Marty. Are you suggesting that it's somehow more difficult for ARIN to get things done, so we shouldn't ask for parity with the level of services provided in the rest of the world? > There seems to be a belief that there is a knob to turn > it on and off. Yes. That knob is called "a little bit of hard work." Since it's not work that anybody is asking you to do, could you clarify your objection? Do you think that crypto is a bad idea? Do you think everybody should have to live with mail-from forever? -Bill From woody at pch.net Sat Apr 7 21:56:55 2007 From: woody at pch.net (Bill Woodcock) Date: Sat, 7 Apr 2007 18:56:55 -0700 (PDT) Subject: [ppml] the "other" policy proposals In-Reply-To: <4617504a.29f.3a20.7557@batelnet.bs> References: <4617504a.29f.3a20.7557@batelnet.bs> Message-ID: > Should Board Members be proposing, and defending, proposed > policies? You've made your thoughts on that matter very, very clear, to all who will listen, many many times. I've run, and won, twice, on the platform that I'm interested in, and have been successful at, working on achieving advances in ARIN policy which have widespread support. This is not a boast or some kind of claim of anything special, it's just work. I've offered to do that work, and the membership has, twice, taken me up on that offer. I'm not going to rescind that offer, once accepted, because you don't like it. If I decide to run again, you're very welcome to either run against me, on a platform of not working, or to campaign against me, on the platform that I shouldn't work. Going behind the membership's back and trying to get non-public policy made that precludes that work is dishonest and underhanded, and just makes all the more work for me. I'd really rather you stopped doing it. -Bill From martin.hannigan at batelnet.bs Sun Apr 8 13:24:59 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Sun, 08 Apr 2007 13:24:59 -0400 Subject: [ppml] the "other" policy proposals Message-ID: <4619256b.302.4669.6493@batelnet.bs> ----- Original Message ----- From: Bill Woodcock To: Martin Hannigan Cc: Edward Lewis , ppml at arin.net Subject: Re: [ppml] the "other" policy proposals Date: Sat, 7 Apr 2007 18:56:55 -0700 (PDT) > > Should Board Members be proposing, and defending, > proposed > > policies? > > You've made your thoughts on that matter very, very clear, > to all who will listen, many many times. Let's make sure the issues don't run together. First, what have I made clear? That I wonder if Board Members should be pushing policy? Um, no, actually, I've never said that before. You made me think of that. > I've run, and > won, twice, on the platform that I'm interested in, and > have been successful at, working on achieving advances in > ARIN policy which have widespread support. This is not a > boast or some kind of claim of anything special, it's just > work. I've offered to do that work, and the membership > has, twice, taken me up on that offer. I'm not going to > rescind that offer, once accepted, because you don't like > it. If I decide to run again, you're very welcome to > either run against me, on a platform of not working, or to > campaign against me, on the platform that I shouldn't > work. I appreciate a good slamming and can take it, but let's stay on-topic. Should board members be pushing policy that they are going to vote on? It was a very simple thought, and not even conclusive or authoritative. > Going behind the membership's back and trying to get > non-public policy made that precludes that work is > dishonest and underhanded, and just makes all the more > work for me. I'd really rather you stopped doing it. Really? I call "BS", Bill. If you have some information that the rest of us don't have, bring it on. Else, I accept your apology. Best, -M< From martin.hannigan at batelnet.bs Sun Apr 8 14:35:39 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Sun, 08 Apr 2007 14:35:39 -0400 Subject: [ppml] IPv4 exhaustion - so what? Message-ID: <461935fb.21e.46e1.15995@batelnet.bs> [ snip ] > could you clarify your objection? Do you think that > crypto is a bad idea? Do you think everybody should have > to live with mail-from forever? I never said I objected. I inferred that some of your rationale is weak. It is. Some of the inference should have been in question form. Are there knobs for turning this on and off? I'll support these proposals, but not for the reasons you seem to support them for. They are good security measures and don't need straw man arguments. -M< From stephen at sprunk.org Sun Apr 8 14:55:22 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 8 Apr 2007 13:55:22 -0500 Subject: [ppml] the "other" policy proposals References: <4617504a.29f.3a20.7557@batelnet.bs> Message-ID: <004401c77a10$59279460$6401a8c0@atlanta.polycom.com> Thus spake "Martin Hannigan" > Should Board Members be proposing, and defending, proposed > policies? Yes, they should. We elect people to the BoT and AC on the basis that they're smart and understand how this stuff works better than the rest of us. To muzzle them once they get into office, and thus deny ourselves the very wisdom we elected them to use, is counter-productive. I _want_ to know what the BoT and AC members think of the various proposals. > This seems to border on a coerced confession to some extent, > something that "appears" to carry the full weight of the board. Hardly; the BoT and AC can't coerce the community except by mishandling their official duties, and if they wanted to do that they wouldn't need to bother with PPML in the first place. Someone stating his opinion, particularly without pointing out he's a BoT/AC member, is hardly coercion. Some readers may give his words more weight, but the same is true for any of the other "high profile" contributors on PPML that have no official capacity at all. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From mysidia at gmail.com Sun Apr 8 15:23:03 2007 From: mysidia at gmail.com (James Hess) Date: Sun, 8 Apr 2007 14:23:03 -0500 Subject: [ppml] the "other" policy proposals In-Reply-To: <4619256b.302.4669.6493@batelnet.bs> References: <4619256b.302.4669.6493@batelnet.bs> Message-ID: <6eb799ab0704081223i2d7582bct45d13389e145ef06@mail.gmail.com> On 4/8/07, Martin Hannigan wrote: > I appreciate a good slamming and can take it, but let's > stay on-topic. Should board members be pushing policy > that they are going to vote on? It was a very simple > thought, > and not even conclusive or authoritative. I see nothing wrong with anyone proposing or defending policy, no matter what board they're on. Noone appears to have actually made any policy proposal that board members be forced to not publicly discuss policy whatever they may vote on. So I fail to see how this vein is at all on-topic, with regards to the policy discussion... I say debate the merits of policy itself all day if you like, but never the "merits" of a participant. I would regard it as inappropriate, for instance, to attempt to strike down a proposal, by urging that the proposer is not qualified or that the proposer will cause others to have an undue bias. And I agree with those that don't see much chance that a board member coerces the public. -- -J From jcurran at istaff.org Sun Apr 8 16:10:55 2007 From: jcurran at istaff.org (John Curran) Date: Sun, 8 Apr 2007 16:10:55 -0400 Subject: [ppml] ARIN Board and AC role in the policy process (Re: the "other" policy proposals) In-Reply-To: <004401c77a10$59279460$6401a8c0@atlanta.polycom.com> References: <4617504a.29f.3a20.7557@batelnet.bs> <004401c77a10$59279460$6401a8c0@atlanta.polycom.com> Message-ID: Folks - I'm going to jump in here to make sure that we have clarity on the role of the AC and the Board in this process. Per the bylaws, the ARIN AC "shall act in an advisory capacity to the Board of Trustees on matters as the Board of Trustees may, from time to time, request involving Internet numbering resource policies and related matters. " The ARIN's Board has a slightly different focus, and I'll reference the ARIN web site for this: "The Board of Trustees has ultimate responsibility for the business affairs and financial health of ARIN, and manages ARIN's operations in a manner consistent with the guidance received from the Advisory Council and the goals set by the registry's members." Historically, we've tried to keep the brunt of the work of policy formation, review, and advocacy in the AC, and have used the Board as the control mechanism to make sure that policy process has been followed and that ARIN is being true to its mission when adopting policy proposals. Neither Board members nor AC members become inherently less knowledgeable as a result of their election and indeed, we want to make sure that we gain the full benefit of that knowledge once elected. In the case of policy proposals, it is truly the AC's job to advocate for proposals, have engaging discussion, and create consensus positions where such are available. It is not an easy task, and I highly recommend that any and all IP resource knowledgeable people consider running when elections come around. The ARIN Board focuses heavily on the fidelity of the particular policy formation process to insure that full and open consideration was provided, and slightly less so on the relative merits of the policy recommendation. We're also very aware of the need for balance in conservation and growth per our charter. The Board has on multiple occasions received feedback that having Board members directly champion proposals can be confusing to the community, and can create an impression that such policy proposals may have "a priori" Board support (when in fact the Board doesn't even discuss such proposals until they've become recommendations from the AC...) As a result of these discussions, the members of the Board tend to avoid directly sponsoring proposals, and generally step in only when there's an absence of community or AC people addressing an important issue. With respect to the position of various Board members on a given proposal, the preference again is for such statements to come out during the public policy meeting if asked, but there is nothing to prevent a Board member from speaking or posting before that time if they truly feel they're attending to the best interests of the community. Apologies for the length, but the subject is both complex and worthy of explanation. /John John Curran Chairman, ARIN Board of Trustees At 1:55 PM -0500 4/8/07, Stephen Sprunk wrote: >Thus spake "Martin Hannigan" >> Should Board Members be proposing, and defending, proposed > > policies? > >Yes, they should. We elect people to the BoT and AC on the basis that >they're smart and understand how this stuff works better than the rest of >us. To muzzle them once they get into office, and thus deny ourselves the >very wisdom we elected them to use, is counter-productive. I _want_ to know >what the BoT and AC members think of the various proposals. From martin.hannigan at batelnet.bs Sun Apr 8 18:13:39 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Sun, 08 Apr 2007 18:13:39 -0400 Subject: [ppml] the "other" policy proposals Message-ID: <46196913.f7.48c4.25212@batelnet.bs> Stephen Sprunk Said: > >Yes, they should. We elect people to the BoT and AC on > the basis that >they're smart and understand how this > stuff works better than the rest of >us. To muzzle them > once they get into office, and thus deny ourselves the > >very wisdom we elected them to use, is > counter-productive. I _want_ to know >what the BoT and AC > members think of the various proposals. The intent of the question really was innocous, just a thought that struck me, but it was a thought created out of what I started to feel was an intimidation tactic. Whether that is true or not is irrelevant, the fact that I felt that twinge for a moment is what I felt is relevant. You said: "they're smart and understand how this stuff works better than the rest of us" This doesn't mean the rest of us are here to be lemmings. There are people that dont participate because they are worried that they will be ridiculed, made to look stupid, or be plain wrong and sometimes people in this forum contribute to that. I am not for eliminating participation, I am for increasing it. Intimidation has 0 place in our organization and perhaps a style class for certain BoT members would be a better remedy than not commenting or producing policy at all? Vigorous policy debate is not intimidation. Minimizing their contributions through their participation -- is. I hope this was a little clearer, FWIW. Best, -M< From martin.hannigan at batelnet.bs Mon Apr 9 00:00:21 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Mon, 09 Apr 2007 00:00:21 -0400 Subject: [ppml] the "other" policy proposals Message-ID: <4619ba55.76.4b8c.835@batelnet.bs> > > http://www.arin.net/policy/proposals/2007_1.html > http://www.arin.net/policy/proposals/2007_2.html > http://www.arin.net/policy/proposals/2007_3.html > > For as much as is on the surface, but against if the > method appears in WhoIs. I already said "for" to these policies, but I lost a thought in the ensuing argument. I wish to rescind my "for", for now. Shouldnt the discussion be around "why not both" vs. why pgp is better than certificates. In my experience, pgp or certs are not "free". When they are, they generally have restrictions on commercial use. Many organizations already have policy around authentication and encryption and making them choose between either seems like forcing a choice of "use" or "not use" the new method that this policy seeks to create. Creating this policy around pgp also seems like it may be ineffective since we would be creating something for a smaller subset of users. X.509, if anything, has widespread acceptance, much wider than PGP - at least commercially. Since we are talking commercial use case, that would mean that the records are corporate records and that they require the use, in most cases, of properly licensed applications. Still, minor nits in the grand scheme of things. The primary purpose to accept this policy would be widespread use. I do not see that as a reality in the existing policy. Assuming that there is no knob to turn this functionality on, sometimes, nothing can be better if the something is barely used or created for a relatively small subset and requires significant effort. Offering both would make it a more widely usable service. Why not both? Yes, I read the rationale. Why are certs good enough for eTrade, eBay, Fidelity, and others, but not ARIN? I think the section related to staff should also be removed. That seems like a customer service issue and not a policy issue. If certs are the most widely used auth method for emailing the staff, then the staff should choose how to operate the business. Best, -M< From woody at pch.net Mon Apr 9 00:07:56 2007 From: woody at pch.net (Bill Woodcock) Date: Sun, 8 Apr 2007 21:07:56 -0700 (PDT) Subject: [ppml] the "other" policy proposals In-Reply-To: <4619ba55.76.4b8c.835@batelnet.bs> References: <4619ba55.76.4b8c.835@batelnet.bs> Message-ID: > Shouldnt the discussion be around "why not both" Marty, the policy is only 44 words long. So far, you've spent 793 words critiquing it. Don't you think it would have made sense to at least _read_ it first? This policy adds support for PGP, and does not remove support for X.509. -Bill From martin.hannigan at batelnet.bs Mon Apr 9 01:52:23 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Mon, 09 Apr 2007 01:52:23 -0400 Subject: [ppml] the "other" policy proposals Message-ID: <4619d497.216.4c75.13534@batelnet.bs> ----- Original Message ----- From: Bill Woodcock To: Martin Hannigan Cc: ppml at arin.net Subject: Re: [ppml] the "other" policy proposals Date: Sun, 8 Apr 2007 21:07:56 -0700 (PDT) > > Shouldnt the discussion be around "why not both" > > Marty, the policy is only 44 words long. So far, you've > spent 793 words critiquing it. Don't you think it would > have made sense to at least _read_ it first? > > This policy adds support for PGP, and does not remove > support for X.509. Heh. I guess I did make a mistake. I thought that none of this stuff was in place since I don't use it. It's likely that I'm not the only one who missed it. You could've pointed out that I did put an effort into participating, that I made a mistake, and then simply pointed me at the relevant section. I'm not going to be intimidated into not participating, but you do realize that there is an effect on others? Enough said. Best, Martin From martin.hannigan at batelnet.bs Mon Apr 9 02:17:01 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Mon, 09 Apr 2007 02:17:01 -0400 Subject: [ppml] the "other" policy proposals Message-ID: <4619da5d.374.4cc4.27557@batelnet.bs> > http://www.arin.net/policy/proposals/2007_1.html > http://www.arin.net/policy/proposals/2007_2.html > http://www.arin.net/policy/proposals/2007_3.html > > For as much as is on the surface, but against if the > method appears in WhoIs. After all that wasted effort, I guess I do support these three after-all, especially since I made the case for both in another, longer, posting. :-] Best, -M< From bicknell at ufp.org Mon Apr 9 09:01:55 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 9 Apr 2007 09:01:55 -0400 Subject: [ppml] the "other" policy proposals In-Reply-To: <4619ba55.76.4b8c.835@batelnet.bs> References: <4619ba55.76.4b8c.835@batelnet.bs> Message-ID: <20070409130154.GA97321@ussenterprise.ufp.org> I'm going to try and stay strict to Marty's technical issues. 1) "Certificates are more commercial." While it's true more businesses use certificates and that more business software is likely to support X.509 that doesn't expose the real mechanics of the situation. A vast majority of businesses create their own CA which they trust internally (generally by pre-loading on PC's). These internal CA's generally aren't seen outside the company at all, and if they are there's no good mechanism to trust them as valid. Specifically before someone asks, it's likely that a company will purchase a commercial certificate for www.company.com, while using a internally run and operated CA internally with a wholly separate certificate. I believe this is driven by a combination of cost and administration difficulty. 2) "PGP is hard / costly to implement." PGP is available completely for free even for commercial use, one instance is at http://www.gnupg.org/. While I would agree there is less corporate support for PGP, there is a significantly higher use of PGP by Network Technologists due to a long history of being used for Domain, Numbering Resources and other Internet purposes. I also personally believe this will be the method of choice for automated tools since the command line clients for PGP are generally easier to incorporate into such home-grown solutions. I don't believe ARIN can implement this feature for free, however I do believe that it should be relatively inexpensive and easy for ARIN to implement. Now, to the real point: ARIN resources are not properly secured from unauthorized changes. We need to REMOVE Mail-From entirely. It is not secure. I suspect there is already some abuse going on, and as we move to IPv4 exhaustion it will only get worse. The sooner we start the better. I see no reason why ARIN can't cost effectively support X.509 Certificates, PGP Authentication, and high grade SSL web based authentication. (And that web authentication could be both X.509 based, as well as password, token, or other methods.) I fully support this proposal as an excellent first step. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From Ed.Lewis at neustar.biz Mon Apr 9 09:40:45 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 9 Apr 2007 09:40:45 -0400 Subject: [ppml] mail auth proposals, was Re: the "other"... In-Reply-To: <20070409130154.GA97321@ussenterprise.ufp.org> References: <4619ba55.76.4b8c.835@batelnet.bs> <20070409130154.GA97321@ussenterprise.ufp.org> Message-ID: At 9:01 -0400 4/9/07, Leo Bicknell wrote: >We need to REMOVE Mail-From entirely. I like such brash thinking but it seems to take a lot to "raise the bar." To help justify this, I am surprised ARIN records are treated seriously in a legal environment knowing how easy it is to falsify them. Having gained a legal education via watching prime-time TV police dramas, isn't there something about the chain of custody of evidence? I do have one question about the suggestion - what about the "legacy" or pre-ARIN space in the database? I don't know if we can arrange a trust relationship with anyone that has never agreed to ARIN's management of the, umm, registrations. >I see no reason why ARIN can't cost effectively support X.509 >Certificates, PGP Authentication, and high grade SSL web based >authentication. (And that web authentication could be both X.509 based, >as well as password, token, or other methods.) Having once considered how I would go about arranging for secured email via X.509 or PGP, I settled first on X.509 as it was easier to document a policy for that. The relationship is "clearer" in that one side asserts that there is a binding between some cryptographic data and an identified object. In PGP, with the idea of transitive trust via trusted introducers the picture became a little fuzzy. Both are doable, but one is easier to manage if you are the side doing the asserting (and are also relying on the assertions). What I am saying is that I prefer X.509 but I wouldn't object to ARIN supporting both X.509 and PGP. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From martin.hannigan at batelnet.bs Mon Apr 9 11:33:10 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Mon, 09 Apr 2007 11:33:10 -0400 Subject: [ppml] mail auth proposals, was Re: the "other"... Message-ID: <461a5cb6.18d.5047.10390@batelnet.bs> ----- Original Message ----- From: Edward Lewis To: Leo Bicknell Cc: ppml at arin.net Subject: [ppml] mail auth proposals, was Re: the "other"... Date: Mon, 9 Apr 2007 09:40:45 -0400 > At 9:01 -0400 4/9/07, Leo Bicknell wrote: > > >We need to REMOVE Mail-From entirely. > > I like such brash thinking but it seems to take a lot to > "raise the bar." > > To help justify this, I am surprised ARIN records are > treated seriously in a legal environment knowing how easy > it is to falsify them. Having gained a legal education > via watching prime-time TV police dramas, isn't there > something about the chain of custody of evidence? I'm not a lawyer "IANAL", but I know from experience that almost anything goes in civil court. The doubt standard is lower. "Chain of evidence" is related to criminal cases, to insure that there wasn't tampering by law enforcement or others associated with the legal system, and to insure that the higher proof standard is not tainted by corrupt evidence or people. I think it's different because you can lose your liberty as the result of a criminal proceeding, but not a civil proceeding. Not a lawyer, never studied law, never passed the bar, not a paralegal. Jury Duty. -M< From Ed.Lewis at neustar.biz Mon Apr 9 10:47:40 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 9 Apr 2007 10:47:40 -0400 Subject: [ppml] mail auth proposals, was Re: the "other"... In-Reply-To: <461a5cb6.18d.5047.10390@batelnet.bs> References: <461a5cb6.18d.5047.10390@batelnet.bs> Message-ID: At 11:33 -0400 4/9/07, Martin Hannigan wrote: >not a civil proceeding. Not a lawyer, never studied law, >never passed >the bar, not a paralegal. Jury Duty. Maybe this is something ARIN staff can get us a statement from the legal council on. Might be helpful to hear this before the Public Policy meeting. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From woody at pch.net Mon Apr 9 11:33:22 2007 From: woody at pch.net (Bill Woodcock) Date: Mon, 9 Apr 2007 08:33:22 -0700 (PDT) Subject: [ppml] the "other" policy proposals In-Reply-To: <20070409130154.GA97321@ussenterprise.ufp.org> References: <4619ba55.76.4b8c.835@batelnet.bs> <20070409130154.GA97321@ussenterprise.ufp.org> Message-ID: > We need to REMOVE Mail-From entirely. It is not secure. I agree completely, however, everything must be addressed step-wise, so we need to have PGP available before a proposal to remove mail-from could be entertained. And I suspect that removing mail-from will be considerably more controversial than adding PGP. SO they're best de-coupled, I believe. -Bill From woody at pch.net Mon Apr 9 11:37:00 2007 From: woody at pch.net (Bill Woodcock) Date: Mon, 9 Apr 2007 08:37:00 -0700 (PDT) Subject: [ppml] mail auth proposals, was Re: the "other"... In-Reply-To: References: <4619ba55.76.4b8c.835@batelnet.bs> <20070409130154.GA97321@ussenterprise.ufp.org> Message-ID: On Mon, 9 Apr 2007, Edward Lewis wrote: > What about the "legacy" or pre-ARIN space in the database? I don't > know if we can arrange a trust relationship with anyone that has > never agreed to ARIN's management of the, umm, registrations. I think that's one of the benefits of PGP: no direct relationship is needed between ARIN and the POC. If the POC has a key, and the key has been signed within a certain number of steps, you're good to go. The X.509 implementation required that the POC and ARIN enter into a heavy-weight contractual relationship. I think the numbers speak for themselves, on the success of that experiment. -Bill From Ed.Lewis at neustar.biz Mon Apr 9 11:57:31 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 9 Apr 2007 11:57:31 -0400 Subject: [ppml] mail auth proposals, was Re: the "other"... In-Reply-To: References: <4619ba55.76.4b8c.835@batelnet.bs> <20070409130154.GA97321@ussenterprise.ufp.org> Message-ID: Referring to: http://www.arin.net/policy/proposals/2007_1.html http://www.arin.net/policy/proposals/2007_2.html http://www.arin.net/policy/proposals/2007_3.html At 8:37 -0700 4/9/07, Bill Woodcock wrote: >I think that's one of the benefits of PGP: no direct relationship is >needed between ARIN and the POC. If the POC has a key, and the key has >been signed within a certain number of steps, you're good to go. The >X.509 implementation required that the POC and ARIN enter into a >heavy-weight contractual relationship. I think the numbers speak for >themselves, on the success of that experiment. I'm asking about "that experiment" - is that just a turn of a phrase or was something run? Last time I asked about the adoption of X.509 within ARIN the answer was "not very much, maybe a handful." But I thought that ARIN has it's own CA service. My impression of PGP is that "it's okay between friends" and my professional experience with it was limited to the days that a long-ago employer (I think the name at the time was Network Associates or McAfee) bought the technology from Phil Zimmerman and found that it wasn't commercially viable despite having a workable product. I am not trying to raise a debate over the technology, I mean to give my impressions as the view of someone in the audience. I am looking to fill in the background on the policy proposals and the "need for"/"viability of" them. (And debating whether email templates should be used at all is out of scope in the discussion of the proposals at hand.) Did ARIN (staff) also do a PGP option? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From woody at pch.net Mon Apr 9 12:44:06 2007 From: woody at pch.net (Bill Woodcock) Date: Mon, 9 Apr 2007 09:44:06 -0700 (PDT) Subject: [ppml] mail auth proposals, was Re: the "other"... In-Reply-To: References: <4619ba55.76.4b8c.835@batelnet.bs> <20070409130154.GA97321@ussenterprise.ufp.org> Message-ID: On Mon, 9 Apr 2007, Edward Lewis wrote: > > The X.509 implementation required that the POC and ARIN enter into > > a heavy-weight contractual relationship. I think the numbers > > speak for themselves, on the success of that experiment. > > I'm asking about "that experiment" - is that just a turn of a phrase or > was something run? By "experiment" I was referring ot ARIN's X.509 CA. > Last time I asked about the adoption of X.509 within ARIN the answer was > "not very much, maybe a handful." Correct. Which, if you think about the number of members ARIN has, wouldn't seem to me to be a marked success in real-world terms, no matter that staff provided exactly what they were asked to, and presumably with technical success. > My impression of PGP is that "it's okay between friends" I think the point is that it's okay between friends-of-friends, and somewhat farther. Whereas X.509 is okay between people who trust a common CA. It's sort of six-of-one, half-dozen-of-the-other, except that PGP is what's implemented successfuly elsewhere, it's what most or many of us already have implemented, and X.509 has demonstrably not solved the problem. Thus, I'd like to see us at least try what's been proven to work everywhere else. -Bill From Ed.Lewis at neustar.biz Mon Apr 9 12:54:26 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 9 Apr 2007 12:54:26 -0400 Subject: [ppml] mail auth proposals, was Re: the "other"... In-Reply-To: References: <4619ba55.76.4b8c.835@batelnet.bs> <20070409130154.GA97321@ussenterprise.ufp.org> Message-ID: At 9:44 -0700 4/9/07, Bill Woodcock wrote: >Thus, I'd like to see us at least try what's been proven to work >everywhere else. Okay. It's fair to say that it is time we (membership) put PGP into play. But why is this policy and not something under the ACSP? Sorry for seeming to derail the question at hand, yeah, I know it's not germane to the topic at hand but as I dig deeper I wonder when do we cross the line from "policies" to "services." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From randy at psg.com Mon Apr 9 13:06:27 2007 From: randy at psg.com (Randy Bush) Date: Mon, 9 Apr 2007 07:06:27 -1000 Subject: [ppml] mail auth proposals, was Re: the "other"... References: <4619ba55.76.4b8c.835@batelnet.bs> <20070409130154.GA97321@ussenterprise.ufp.org> Message-ID: <17946.29331.195163.903019@roam.psg.com> > Having once considered how I would go about arranging for secured > email via X.509 or PGP, I settled first on X.509 as it was easier to > document a policy for that. The relationship is "clearer" in that > one side asserts that there is a binding between some cryptographic > data and an identified object. In PGP, with the idea of transitive > trust via trusted introducers the picture became a little fuzzy. nope. do not be confused. the trust relationship is the same in both cases. the contractual relationship with arin binds a public private key pair. the pgp web of trust is not used. randy From martin.hannigan at batelnet.bs Mon Apr 9 15:25:18 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Mon, 09 Apr 2007 15:25:18 -0400 Subject: [ppml] mail auth proposals, was Re: the "other"... Message-ID: <461a931e.b5.53de.1847@batelnet.bs> ----- Original Message ----- From: Edward Lewis To: "Martin Hannigan" Cc: Edward Lewis , Leo Bicknell , ppml at arin.net Subject: Re: [ppml] mail auth proposals, was Re: the "other"... Date: Mon, 9 Apr 2007 10:47:40 -0400 > At 11:33 -0400 4/9/07, Martin Hannigan wrote: > > >not a civil proceeding. Not a lawyer, never studied law, > >never passed > >the bar, not a paralegal. Jury Duty. > > Maybe this is something ARIN staff can get us a statement > from the legal council on. Might be helpful to hear this > before the Public Policy meeting. Sure, I support that. My experience tells me they're going to say what we said, but certainly with more flair and definately authoritative. -M< From michael.dillon at bt.com Mon Apr 9 16:38:03 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 9 Apr 2007 21:38:03 +0100 Subject: [ppml] mail auth proposals, was Re: the "other"... In-Reply-To: Message-ID: > >X.509 implementation required that the POC and ARIN enter into a > >heavy-weight contractual relationship. I think the numbers speak for > >themselves, on the success of that experiment. > > I'm asking about "that experiment" - is that just a turn of a phrase > or was something run? I remember the X.509 experiment. First of all there was a very convoluted process required to get a certificate (or was that to send one) which involved some hidden corners of Netscape's browser. But one of the steps required was to receive an email message, sign it with the cert and send it back. The process was relatively straightforward if you used a brainless UNIX email client, but I simple couldn't get it to work via Lotus Notes which was the company email client at the time. Which may seem odd because Notes had some nice built-in X.509 message signing that was used internally wherever managers needed to approve spending some money. But, this ARIN cert was completely outside of our corporate world and therefore, not something that Notes would help me with. Given that PGP is a relatively stand-alone system, it makes it easier to adapt to the corporate email standard as an add-in. But I still prefer just plain SSL, i.e. https: POST transactions. --Michael Dillon From michael.dillon at bt.com Mon Apr 9 16:39:25 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 9 Apr 2007 21:39:25 +0100 Subject: [ppml] The authentication proposals, 1, 2, 3 Message-ID: There are three policy proposals which talk about authentication techniques for communications between ARIN and members/applicants, etc. These are the three. http://www.arin.net/policy/proposals/2007_1.html http://www.arin.net/policy/proposals/2007_2.html http://www.arin.net/policy/proposals/2007_3.html I'm of two minds about these. First of all, I'd rather that these proposals were not there. I'd rather that the policy not mention these things at all. And I would rather that such matters be dealt with in the ARIN Suggestion Box, not through PPML. If anything, I think policy needs to go no further than to state that ARIN will support commonly used authentication/encryption protocols to secure the communications between ARIN and various parties such as applicants, SWIPpers, db updaters, members. The preceding sentence isn't the right language, but that is the gist of what I think needs to be in policy. The rest of the details are operational technical matters and should, in my opinion, definitely not be in the policy. Having them in the policy blindsides ARIN and ARIN technical staff into thinking that they are doing a good job when they are not. The same goes for the board of trustees. I think that especially, the Board of Trustees, namely Scott Bradner, John Curran, Lee Howard, Bill Manning, Ray Plzak, Paul Vixie and Bill Woodcock, should be ashamed of the incompetence they have displayed in allowing things to go on as they have for so long. In my opinion, a competent BoT would have reinstated PGP, documented all the various supported technologies and added a non-email RPC submission protocol over secure HTTP. This last is what people commonly call REST used via an https: URL. For background on REST have a look at http://www.prescod.net/rest/security.html and for an example of how such things can be implemented by a flexible app which supports many protocols, look at http://www-128.ibm.com/developerworks/web/library/wa-wsgi/index.html Of course, Paul Vixie and Bill Woodcock are actually trying to sort out this mess, so perhaps they don't need to feel as ashamed as the rest of the BoT. This brings us to my second thoughts on these three proposals. I realize that the AC has some flexibility on rewording proposals before they actually go to the BoT, but I'm not sure what the limits of that are. So I would not want to, in any way delay the reinstatement of PGP. 2007-1 is a good thing. I am FOR this policy. As for the other two which merely document something that exists, I don't much care one way or the other. I'd rather not see such documentation in the policy itself, but I certainly DO WANT TO SEE some documentation of these things on the ARIN web site. And with more detail, including graphics, than are possible in a policy document. It is possible that the BoT collectively, does not have enough security expertise to determine what is the meaning of "support commonly used authentication/encryption protocols". In that case, I suggest that they consult someone with recognized security expertise who could spend a half hour to dash off a 2 page summary of what that implies. That 2 page summary could then become a roadmap for the ARIN technical staff to work against. I suggest that someone like Steve Bellovin would be an appropriate author for such guidance. I'm not going to put this suggestion into the ARIN suggestion box http://app.arin.net/suggestion/ because the whole matter is already being discussed in the public policy forum and I don't think the BoT can fail to miss it. Also, if you click that suggestion URL, you will notice that you are redirected to an https: URL. Probably the ARIN technical staff already knows how to provide more secure communications channels but the bad policy is hampering them from acting. ------------------------------------------------------- Michael Dillon Capacity Management, 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: michael.dillon at bt.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.btradianz.com One Community One Connection One Focus From michael.dillon at bt.com Mon Apr 9 16:39:30 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 9 Apr 2007 21:39:30 +0100 Subject: [ppml] the "other" policy proposals In-Reply-To: <20070409130154.GA97321@ussenterprise.ufp.org> Message-ID: > 2) "PGP is hard / costly to implement." PGP is available completely > for free even for commercial use, one instance is at > http://www.gnupg.org/. Another is http://www.gpg4win.org/ GPG for Windows which includes a plugin for Outlook 2003 (GPCol) amongst other things. > I don't believe ARIN can implement this feature for free, however > I do believe that it should be relatively inexpensive and easy > for ARIN to implement. Also cheap and easy for those who wish to communicate with ARIN securely. > We need to REMOVE Mail-From entirely. It is not secure. I suspect > there is already some abuse going on, and as we move to IPv4 > exhaustion > it will only get worse. The sooner we start the better. Mail-From can be secured in operation even though the protocol on its own is not secure. For instance, ARIN could communicate through another channel, i.e. telephone or email to a different address, to confirm MAIL-FROM changes. They could check the source address of the SMTP transaction. And so on. --Michael Dillon From jay at handynetworks.com Mon Apr 9 16:48:25 2007 From: jay at handynetworks.com (Jay Sudowski - Handy Networks LLC) Date: Mon, 9 Apr 2007 14:48:25 -0600 Subject: [ppml] mail auth proposals, was Re: the "other"... In-Reply-To: References: Message-ID: <7EC421F755E45242A47938C3B6F634B19F521B@hnetavail1.exchange.handynetworks.com> >But I still prefer just plain SSL, i.e. https: POST transactions. Me too! It is beyond me why ARIN has not yet implemented a straight forward web based system / web services based system for management of ARIN assets. -Jay From Kavalec at BSWA.com Mon Apr 9 18:31:35 2007 From: Kavalec at BSWA.com (G. Waleed Kavalec) Date: Mon, 9 Apr 2007 16:31:35 -0600 Subject: [ppml] the "other" policy proposals Message-ID: -----Original Message----- > 2) "PGP is hard / costly to implement." PGP is available completely > for free even for commercial use, one instance is at > http://www.gnupg.org/. Another is http://www.gpg4win.org/ GPG for Windows which includes a plugin for Outlook 2003 (GPCol) amongst other things. --Michael Dillon _______________________________________________ I can't agree enough. The various implementation of GnuPG (aka gpg) are fully compatible with PGP and very easy to implement. There are a slew of free, open-source wrappers available to integrate the tool with explore, outlook, etc. -- Greg Kavalec System Architect Baca, Stein, White and Associates, Inc. (281) 342-2646 office (281) 344-7515 cell From martin.hannigan at batelnet.bs Mon Apr 9 18:47:43 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Mon, 09 Apr 2007 18:47:43 -0400 Subject: [ppml] the "other" policy proposals Message-ID: <461ac28f.cc.56c4.19286@batelnet.bs> ----- Original Message ----- From: "G. Waleed Kavalec" To: , Subject: Re: [ppml] the "other" policy proposals Date: Mon, 9 Apr 2007 16:31:35 -0600 > -----Original Message----- > > > 2) "PGP is hard / costly to implement." PGP is > > available completely for free even for commercial use > > , one instance is at http://www.gnupg.org/. > > Another is http://www.gpg4win.org/ GPG for Windows which > includes a plugin for Outlook 2003 (GPCol) amongst other > things. > > --Michael Dillon > _______________________________________________ > > > > I can't agree enough. The various implementation of GnuPG > (aka gpg) are fully compatible with PGP and very easy to > implement. > > There are a slew of free, open-source wrappers available > to integrate the tool with explore, outlook, etc. Leo addressed this, but yes, they are fine for some. Most companies want support by default, even for a single seat. There's also the assumption that certificate users can use both. Many corporate security policies dont allow users to install software, and some have specific restrictions on open source of freeware. This is more complicated than it sounds, to be honest. Kinda moot, though. :-) -M< From bicknell at ufp.org Mon Apr 9 18:05:47 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 9 Apr 2007 18:05:47 -0400 Subject: [ppml] the "other" policy proposals In-Reply-To: References: <4619ba55.76.4b8c.835@batelnet.bs> <20070409130154.GA97321@ussenterprise.ufp.org> Message-ID: <20070409220547.GA30673@ussenterprise.ufp.org> In a message written on Mon, Apr 09, 2007 at 08:33:22AM -0700, Bill Woodcock wrote: > I agree completely, however, everything must be addressed step-wise, so we > need to have PGP available before a proposal to remove mail-from could be > entertained. And I suspect that removing mail-from will be considerably > more controversial than adding PGP. SO they're best de-coupled, I > believe. Quite right, we can't remove any solution until viable replacements are in place. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bicknell at ufp.org Mon Apr 9 18:07:05 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 9 Apr 2007 18:07:05 -0400 Subject: [ppml] the "other" policy proposals In-Reply-To: <461ac28f.cc.56c4.19286@batelnet.bs> References: <461ac28f.cc.56c4.19286@batelnet.bs> Message-ID: <20070409220705.GB30673@ussenterprise.ufp.org> In a message written on Mon, Apr 09, 2007 at 06:47:43PM -0400, Martin Hannigan wrote: > Leo addressed this, but yes, they are fine for some. > Most companies want support by default, even for a single > seat. There's also the assumption that certificate users can > use both. Many corporate security policies dont allow users > to > install software, and some have specific restrictions on > open > source of freeware. This is more complicated than it sounds, > to be honest. All the more reason to be inclusive. X.509, PGP, and SSL websites with authentication. None of the solutions requires leaving out any of the others. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From MOHLER at graceland.edu Mon Apr 9 18:25:31 2007 From: MOHLER at graceland.edu (Dave Mohler) Date: Mon, 9 Apr 2007 17:25:31 -0500 Subject: [ppml] the "other" policy proposals In-Reply-To: <20070409220705.GB30673@ussenterprise.ufp.org> Message-ID: In considering adding support for more solutions, I'd urge some restraint; ensuring that the new solution meets needs that can't reasonably be met by existing solutions. (To be clear, I'm not suggesting these proposals don't meet such needs.) The risk is that each solution added becomes one more solution whose removal "will be considerably more controversial" (from Bill Woodcock's message) at some point in the future, compounding the support effort required by the ARIN staff. David A. Mohler - mohler at graceland.edu > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Leo Bicknell > Sent: Monday, April 09, 2007 5:07 PM > To: ppml at arin.net > Subject: Re: [ppml] the "other" policy proposals > > In a message written on Mon, Apr 09, 2007 at 06:47:43PM -0400, Martin > Hannigan wrote: > > Leo addressed this, but yes, they are fine for some. > > Most companies want support by default, even for a single > > seat. There's also the assumption that certificate users can > > use both. Many corporate security policies dont allow users > > to > > install software, and some have specific restrictions on > > open > > source of freeware. This is more complicated than it sounds, > > to be honest. > > All the more reason to be inclusive. > > X.509, PGP, and SSL websites with authentication. None of the solutions > requires leaving out any of the others. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org From martin.hannigan at batelnet.bs Mon Apr 9 19:34:08 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Mon, 09 Apr 2007 19:34:08 -0400 Subject: [ppml] the "other" policy proposals Message-ID: <461acd70.2bd.5780.13896@batelnet.bs> ----- Original Message ----- From: Leo Bicknell To: ppml at arin.net Subject: Re: [ppml] the "other" policy proposals Date: Mon, 9 Apr 2007 18:07:05 -0400 > In a message written on Mon, Apr 09, 2007 at 06:47:43PM > > -0400, Martin Hannigan wrote: Leo addressed this, but > > yes, they are fine for some. Most companies want support > > by default, even for a single seat. There's also the > > assumption that certificate users can use both. Many > > corporate security policies dont allow users to > > install software, and some have specific restrictions on > > open > > source of freeware. This is more complicated than it > > sounds, to be honest. > > All the more reason to be inclusive. > > X.509, PGP, and SSL websites with authentication. None of > the solutions requires leaving out any of the others. If people are going to do some development work, why not do this all at once? I understand that the existing policy will probably go as is, but it seems more productive to do all 3 if there is support now. -M< From michael.dillon at bt.com Tue Apr 10 04:54:37 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 10 Apr 2007 09:54:37 +0100 Subject: [ppml] the "other" policy proposals In-Reply-To: <461ac28f.cc.56c4.19286@batelnet.bs> Message-ID: > Many corporate security policies dont allow users > to > install software, and some have specific restrictions on > open > source of freeware. This is more complicated than it sounds, > to be honest. Irrelevant. If they can't make the business case internally to install the software that they need to deal with ARIN, then they don't need to apply for IP addresses. On the other hand, if the company's business model requires IP addresses, then there is a business case to install the software needed to interact with ARIN. --Michael Dillon From michael.dillon at bt.com Tue Apr 10 05:20:57 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 10 Apr 2007 10:20:57 +0100 Subject: [ppml] the "other" policy proposals In-Reply-To: Message-ID: > In considering adding support for more solutions, I'd urge some > restraint; ensuring that the new solution meets needs that can't > reasonably be met by existing solutions. (To be clear, I'm not > suggesting these proposals don't meet such needs.) The risk is that > each solution added becomes one more solution whose removal "will be > considerably more controversial" (from Bill Woodcock's > message) at some > point in the future, compounding the support effort required > by the ARIN > staff. Another good reason for removing these details entirely from the policies. That way, if ARIN staff determine that a mechanism is unpopular, they can simply stop doing it. With signoff from the BoT of course. Do you recall the long and protracted discussion about the design of the new templates? Of course you don't because ARIN staff just did it. --Michael Dillon From MOHLER at graceland.edu Tue Apr 10 10:59:16 2007 From: MOHLER at graceland.edu (Dave Mohler) Date: Tue, 10 Apr 2007 09:59:16 -0500 Subject: [ppml] the "other" policy proposals In-Reply-To: Message-ID: I agree. Would policy be an appropriate place to indicate expectated conditions to terminate a mechanism the staff has determined to be "unpopular" (e.g. minimum duration of notice; availability of alternative mechanism, perhaps how to determine "unpopularity", BoT approval)? Also, would there be any appropriate policy to express expectations for staff to implement new mechanisms (e.g. "best practices", avoiding proliferation of too many ways to do the same thing, BoT approval)? -- David A. Mohler > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > michael.dillon at bt.com > Sent: Tuesday, April 10, 2007 4:21 AM > To: ppml at arin.net > Subject: Re: [ppml] the "other" policy proposals > > > In considering adding support for more solutions, I'd urge some > > restraint; ensuring that the new solution meets needs that can't > > reasonably be met by existing solutions. (To be clear, I'm not > > suggesting these proposals don't meet such needs.) The risk is that > > each solution added becomes one more solution whose removal "will be > > considerably more controversial" (from Bill Woodcock's > > message) at some > > point in the future, compounding the support effort required > > by the ARIN > > staff. > > Another good reason for removing these details entirely from the > policies. That way, if ARIN staff determine that a mechanism is > unpopular, they can simply stop doing it. With signoff from the BoT of > course. > > Do you recall the long and protracted discussion about the design of the > new templates? > > Of course you don't because ARIN staff just did it. > > --Michael Dillon > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From randy at psg.com Tue Apr 10 12:40:56 2007 From: randy at psg.com (Randy Bush) Date: Tue, 10 Apr 2007 06:40:56 -1000 Subject: [ppml] mail auth proposals, was Re: the "other"... References: <17946.29331.195163.903019@roam.psg.com> Message-ID: <17947.48664.285554.550528@roam.psg.com> someone has pointed out to me that the current draft of the pgp proposal says > ARIN shall accept PGP-signed communications, validate that a > chain of trust not longer than five steps exists between the > signing key and the ARIN host master role key... this is not wise. with pgp, i would not trust anything more than one hop from the key on file with the contract. pgp is not x.509. randy From michael.c.loevner at verizon.com Tue Apr 10 14:05:00 2007 From: michael.c.loevner at verizon.com (michael.c.loevner at verizon.com) Date: Tue, 10 Apr 2007 14:05:00 -0400 Subject: [ppml] 2007-1 and comments on 2007-9 and 10 Message-ID: All, I don't feel like I can directly respond to the current thread on 2007-1 because I'm going in a different direction with my opposal...and I wanted to add in something on 2007-9 and 2007-10 First, my opinion on 2007-1: While I like the idea of a higher level of security in ARIN transactions, I don't necessarily see people making use of this technology. Applying for an X.509 certificate is a process that takes time, and requires installation into the mail client or homebuilt software for an ISP. In a lot of cases, the risk of using mail-from outweighs the reward of a certification system and the work involved in doing so. Almost every organization that is a member of ARIN uses mail-from at this time, and I don't see any of the "big swippers" speaking up now to say they need a higher level of security in their ARIN transactions. I think it's a nice idea, but we need to ensure we aren't wasting ARIN's time and money by forcing a technology without an existing demand. I'd love to see some organizations that regularly transact with ARIN state that PGP will get them using certificates with ARIN. I'm not willing to say that at this point. As for 2007-9: Modernization of ISP Immediate Need Policy and 2007-10: End Site Immediate Need Policy: I do not support this particular modification of the policy because it limits the amount of address space that can be obtained under this policy to a /16. Since ARIN currently has no maximum allocation size, this should be reflected in the Immediate Need Policy as well. Since these cases are exceptional anyways, the possibility that the allocation would need to exceed a /16 would be exceptional as well, but since it may exist, the limitation must be removed. I support 2007-2, 3, 4, 5, 6, 7, 8, and 11 Regards, Mike Loevner Verizon Internet Services From Ed.Lewis at neustar.biz Tue Apr 10 14:51:19 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 10 Apr 2007 14:51:19 -0400 Subject: [ppml] 2007-1, was Re: mail auth proposals In-Reply-To: <17947.48664.285554.550528@roam.psg.com> References: <17946.29331.195163.903019@roam.psg.com> <17947.48664.285554.550528@roam.psg.com> Message-ID: http://www.arin.net/policy/proposals/2007_1.html At 6:40 -1000 4/10/07, Randy Bush wrote: >> ARIN shall accept PGP-signed communications, validate that a >> chain of trust not longer than five steps exists between the >> signing key and the ARIN host master role key... > >this is not wise. with pgp, i would not trust anything more than >one hop from the key on file with the contract. pgp is not x.509. I want to add a "I noticed this too and disagree" with the quip highlighted by Randy. It was in the back of my mind when "questioning" PGP but I didn't think to include it explicitly. Meaning - X.509 is clear; ARIN can fix/cement the certs so that it is both the issuer and the relying party hence put "trust" into the binding of the key to the POC and the message (via signature) to the POC. With PGP you have to either be willing to trust "introducers" or else restrict our trust to only those with whom you directly signed their keys. X.509 and PGP both can bind a key to an entity but they trust architecture is different. X.509 is hierarchical, PGP is not. Neither is better than the other, neither is worse than the other, but they are different. I am for ARIN making PGP available only if it is implemented in a way that ARIN has "control" of the trust arrangement as far as they "control" anything else. (By that I mean, via example - ARIN can delegate DNS to someone and has a policy for lame delegations. If that someone then delegates elsewhere, it is beyond ARIN's control and the lame delegation policy doesn't cover that.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From william at elan.net Tue Apr 10 16:55:46 2007 From: william at elan.net (william(at)elan.net) Date: Tue, 10 Apr 2007 13:55:46 -0700 (PDT) Subject: [ppml] 2007-1, was Re: mail auth proposals In-Reply-To: References: <17946.29331.195163.903019@roam.psg.com> <17947.48664.285554.550528@roam.psg.com> Message-ID: On Tue, 10 Apr 2007, Edward Lewis wrote: > http://www.arin.net/policy/proposals/2007_1.html > > At 6:40 -1000 4/10/07, Randy Bush wrote: > >>> ARIN shall accept PGP-signed communications, validate that a >>> chain of trust not longer than five steps exists between the >>> signing key and the ARIN host master role key... >> >> this is not wise. with pgp, i would not trust anything more than >> one hop from the key on file with the contract. pgp is not x.509. > > I want to add a "I noticed this too and disagree" with the quip > highlighted by Randy. It was in the back of my mind when > "questioning" PGP but I didn't think to include it explicitly. > > Meaning - X.509 is clear; ARIN can fix/cement the certs so that it is > both the issuer and the relying party hence put "trust" into the > binding of the key to the POC and the message (via signature) to the > POC. With PGP you have to either be willing to trust "introducers" > or else restrict our trust to only those with whom you directly > signed their keys. > > X.509 and PGP both can bind a key to an entity but they trust > architecture is different. X.509 is hierarchical, PGP is not. > Neither is better than the other, neither is worse than the other, > but they are different. I am for ARIN making PGP available only if > it is implemented in a way that ARIN has "control" of the trust > arrangement as far as they "control" anything else. (By that I mean, > via example - ARIN can delegate DNS to someone and has a policy for > lame delegations. If that someone then delegates elsewhere, it is > beyond ARIN's control and the lame delegation policy doesn't cover > that.) I don't quite understand how you connected PGP authorizatoin policy with lame-deligations. As far as PGP I have a comment. Current policy text states that: "ARIN shall accept PGP-signed communications, validate that a chain of trust not longer than five steps exists between the signing key and the ARIN hostmaster role key" I believe that is too long and opens for security holes when ARIN does not know for sure if it can trust persons in between. I think ARIN should accept maximum 2-step PGP chain but have special system where ARIN will sign key for any contact it previously authenticated by either PGP or S/MIME (maybe use different key for that if person is not authenticated in person). Also text says "ARIN shall PGP-sign all outgoing hostmaster email with the hostmaster role key, and staff members may optionally also sign mail with their own individual keys." Last part is completely unnecessary, staff members should feel free to use PGP no matter if policy states it or not. -- William Leibzon Elan Networks william at elan.net From randy at psg.com Tue Apr 10 16:26:51 2007 From: randy at psg.com (Randy Bush) Date: Tue, 10 Apr 2007 10:26:51 -1000 Subject: [ppml] mail auth proposals, was Re: the "other"... References: <17946.29331.195163.903019@roam.psg.com> <17947.48664.285554.550528@roam.psg.com> Message-ID: <17947.62219.819924.703715@roam.psg.com> > this is not wise. with pgp, i would not trust anything more than > one hop from the key on file with the contract. pgp is not x.509. i recant. it is worse. i checked with smb, and he advises as appended (with permission). i believe that, unless we do a whole lot more inftastructure work (to what end?) safe numHops == 0 randy --- Date: Tue, 10 Apr 2007 16:16:17 -0400 From: "Steven M. Bellovin" To: Randy Bush Subject: Re: [ppml] mail auth proposals, was Re: the "other"... On Tue, 10 Apr 2007 09:45:15 -1000 Randy Bush wrote: The issue isn't x509 vs PGP; it's the policies practices of the intermediate signers. What's missing from PGP in general -- and from x509 for this particular purpose -- is a way to say "this delegation is for ARIN access". In fact, some would assert that it's a flaw in the entire model, and that we really need something like spki/sdsi to express the concept properly. Put another way, suppose you register your ordinary PGP key with ARIN. You've signed my key. Does that authorize me to access your resources? You need to use a special key, for that only, and only use that to sign delegatees' keys. Should they have the right to delegate further? You're the custodian of the IIJ key, perhaps, and maybe you sign one key per NOC/hosting center/per-continent customer care site; these in turn are used to issue keys to the local responsible individuals. Is that right? Neither x509 or PGP really solve that problem. The right answer, in either case, is to associate a policy with the registered key. It could be in an ARIN database, it could be in x509 fields, or it could be in some stylized real-name subfield with PGP. The simplest such policy is legal delegation depth below that point. --Steve Bellovin, http://www.cs.columbia.edu/~smb From michael.dillon at bt.com Tue Apr 10 19:19:32 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 11 Apr 2007 00:19:32 +0100 Subject: [ppml] 2007-1, was Re: mail auth proposals In-Reply-To: Message-ID: > I believe that is too long and opens for security holes when ARIN does > not know for sure if it can trust persons in between. I think > ARIN should > accept maximum 2-step PGP chain but have special system where > ARIN will > sign key for any contact it previously authenticated by either PGP or > S/MIME (maybe use different key for that if person is not > authenticated > in person). I don't think it's too long and I don't think it's too short. I don't think that 5 steps is right either and I don't think that details like this belong in policy. I do think that ARIN should consult a recognized security expert for advice on this. Someone with the stature of Steve Bellovin or Bruce Schneier for instance or someone who has credentials from IETF security-related working groups. 99% or more of the people on this list, including me, are not qualified to give expert opinions on this even if we have implemented security systems in the past. --Michael Dillon From martin.hannigan at batelnet.bs Tue Apr 10 21:09:18 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Tue, 10 Apr 2007 21:09:18 -0400 Subject: [ppml] 2007-1, was Re: mail auth proposals Message-ID: <461c353e.155.10af.23466@batelnet.bs> > I do think that ARIN should consult a recognized security > expert for advice on this. Someone with the stature of > Steve Bellovin or Bruce Schneier for instance or someone > who has credentials from IETF security-related working > groups. Randy Bush? -M< From woody at pch.net Tue Apr 10 21:13:02 2007 From: woody at pch.net (Bill Woodcock) Date: Tue, 10 Apr 2007 18:13:02 -0700 (PDT) Subject: [ppml] 2007-1, was Re: mail auth proposals In-Reply-To: References: <17946.29331.195163.903019@roam.psg.com> <17947.48664.285554.550528@roam.psg.com> Message-ID: On Tue, 10 Apr 2007, william(at)elan.net wrote: > I think ARIN should accept maximum 2-step PGP chain... I think I can guess that the authors would all be fine with that. I certainly would be. I don't think anyone's attached to the number five, and I think most of us aren't positive we need to specify a number in the policy. > ...but have special system where ARIN will > sign key for any contact it previously authenticated... Well, the idea was that ARIN hostmasters would do key-signings at ARIN meetings, and participate in key-signings at other meetings, but we felt that it was too prescriptive to get into that level of detail in the policy. We don't feel that ARIN should apply something other than the normally-accepted PGP authentication process (check government-issued photo ID in the physical presence of the other person, and hear their key fingerprint from them directly). There's a right way to do it, and ARIN shouldn't break an established practice. > Last part is completely unnecessary, staff members should feel free to > use PGP no matter if policy states it or not. That would be nice, but unfortunately we didn't agree that it was unnecessary to say it. :-/ -Bill From info at arin.net Wed Apr 11 13:55:47 2007 From: info at arin.net (Member Services) Date: Wed, 11 Apr 2007 13:55:47 -0400 Subject: [ppml] ARIN XIX - Open Policy Hour Message-ID: <461D2123.5010802@arin.net> Some Questions About the Policy Process 1. Do you want to know what policy proposals will be discussed at the upcoming ARIN Public Policy Meeting? 2. Do you have an idea about how ARIN should manage Internet Number Resources? 3. Do you think that a current policy should be enhanced or changed, or even retired? 4. Are you hesitant about making a formal proposal on the Public Policy Mail List (PPML)? 5. Are you new to the Policy Development Process? If the answer to any of these questions is yes, then you should attend the Open Policy Hour! What is The Open Policy Hour? Quite simply, it is your opportunity to get a better understanding of what is going to be discussed at the upcoming Public Policy Meeting or for you to discuss your ideas in an open, informal forum and receive feedback or both! The Open Policy Hour consists of two parts. Part One is the P2B2 or the Policy Proposal Background Briefing. ARIN staff will provide summary information regarding the policy proposals that will be discussed at the meeting. Members of the ARIN Advisory Council will be present to answer general questions about the policy proposals. There will be no discussion of the proposals, just the information that you need to help you understand the nature of the proposals. ARIN staff will also provide a Policy Evaluation and Feedback Report. This report provides a staff evaluation of current ARIN policies, based on the experience gained by the staff in policy implementation and application, as well as feedback provided by ARIN customers. Part Two is the P2B or the Policy Proposal BoF. This is where you get a chance to "test drive" a policy idea. How can you participate? Bring your ideas and questions. If you have a policy suggestion for which you would like to receive feedback prior to submitting it to the community on the PPML, here is your opportunity. If you have a short (3-minute) presentation prepared you will be given the first opportunity to present it. To sign up to give a presentation please send an e-mail to policy at arin.net by 18 April 2007 with your name, organization, and a brief description of your policy subject. Come join your colleagues in this informal setting. The Open Policy Hour for ARIN XIX will be held on Sunday, 22 April, from 4:30 - 6:00 PM. If you are not familiar with the way policies are developed in the ARIN region, join ARIN staff a half hour earlier, at 4:00 PM, for a review of the Internet Resource Policy Evaluation Process. Registration information for ARIN XIX is available at: http://www.arin.net/ARIN-XIX/ Contact Member Services at info at arin.net if you have any questions. Regards, Member Services Department American Registry for Internet Numbers From william at elan.net Thu Apr 12 03:58:50 2007 From: william at elan.net (william(at)elan.net) Date: Thu, 12 Apr 2007 00:58:50 -0700 (PDT) Subject: [ppml] 2007-1, was Re: mail auth proposals In-Reply-To: References: <17946.29331.195163.903019@roam.psg.com> <17947.48664.285554.550528@roam.psg.com> Message-ID: On Tue, 10 Apr 2007, Bill Woodcock wrote: > On Tue, 10 Apr 2007, william(at)elan.net wrote: > > I think ARIN should accept maximum 2-step PGP chain... > > I think I can guess that the authors would all be fine with that. I > certainly would be. I don't think anyone's attached to the number five, > and I think most of us aren't positive we need to specify a number in the > policy. Perhaps the issue is that its unclear what the goals are for deploying this email authentication. There can actually be two gaols: 1. To verify that email address sent to ARIN really came from listed email address 2. To verify that the person sending the email and using email address is really who he says he is Two other email authentication methods being proposed focus only on #1 and in fact there is no way to do #2 with them at all. PGP does allow #2 which happens during direct key signing (i.e. somebody from ARIN verifies identity of the person with such and such PGP key) and less directly through PGP chain of trust. However if you really do not have #2 as requirement, then chain of trust is of limited interest. What you really want is to make sure that ARIN knows that this public key really does correspond to this email address and to nobody else. This can be done by just looking up fingerprint on the key server or ARIN could do direct verification upon request and send some "check" message to listed email address who would then have to respond to ARIN and include relevant part of check message (some verification id) in email signed by his/her PGP key; that is not the only way to do it; it could also be done for example by including URL in verification email message where the person who received it would click and there paste his/her fingerprint; many other similar ways exist so perhaps details are better left to ARIN staff. > Well, the idea was that ARIN hostmasters would do key-signings at ARIN > meetings, and participate in key-signings at other meetings, but we felt > that it was too prescriptive to get into that level of detail in the > policy. > > We don't feel that ARIN should apply something other than the > normally-accepted PGP authentication process (check government-issued > photo ID in the physical presence of the other person, and hear their key > fingerprint from them directly). There's a right way to do it, and ARIN > shouldn't break an established practice. So you're in fact thinking about #2 and identity verification as main purpose behind it? > > Last part is completely unnecessary, staff members should feel free to > > use PGP no matter if policy states it or not. > > That would be nice, but unfortunately we didn't agree that it was > unnecessary to say it. :-/ I don't understand your reasons. ARIN staff should be free to use any email authentication method relevant to their job duties and they dont need our permission. And I don't think policy should be used to educate them especially when its basically MAY anyway. -- William Leibzon Elan Networks william at elan.net From Ed.Lewis at neustar.biz Thu Apr 12 10:12:54 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 12 Apr 2007 10:12:54 -0400 Subject: [ppml] 2007-1, was Re: mail auth proposals In-Reply-To: References: <17946.29331.195163.903019@roam.psg.com> <17947.48664.285554.550528@roam.psg.com> Message-ID: At 0:58 -0700 4/12/07, william(at)elan.net wrote: > 1. To verify that email address sent to ARIN really came from listed > email address > 2. To verify that the person sending the email and using email address > is really who he says he is > >Two other email authentication methods being proposed focus only on #1 >and in fact there is no way to do #2 with them at all. PGP does allow >#2 which happens during direct key signing (i.e. somebody from ARIN >verifies identity of the person with such and such PGP key) and less >directly through PGP chain of trust. Neither, really, is the goal of signing a message. A signature over a message only means that someone with access to the private key calculated the signature. Regardless of the email address used to send it, regardless of the true author of the message, regardless of whether this was even an email delivery. I think that this is too fine a detail though. It is reasonable to believe that a POC will create a key pair, present the public one to ARIN along with meta-data to validate that the key is the POC's and keep the private one appropriately secure. The POC will then most likely use the key in an application which will sign templates are they are mailed to ARIN. That is reasonable, although there are other scenarios. The point of using PGP or X509 (and realize they are "service equivalents" but the mechanics are different) is to remove the need for "mail-from" so neither #1 nor #2 are goals - it doesn't matter what the sending email address is. If I have access to my private key but not my email I should be able to send in a signed template. When a template is submitted under mail-from, there is no "claimed identity," that is the sender is inferred via the authentication process. (Look at a template you have submitted. Where is there a "who is requesting this?" field.) With a certificate mechanism, whether PGP or X.509, the claimed identity of the sender of the template is in the identity field of the certificate, and the binding of the message to that identity is verified via analysis of the signature. When you begin the authorization step (i.e., is the sender allowed to ask this) by inferring the sender, the process is much more complicated than if you at least know who the sender claims to be. Removing mail-from has other benefits besides just making template submission more secure. For one, only mail-from requires that the submission be in mail. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From bicknell at ufp.org Thu Apr 12 21:28:54 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 12 Apr 2007 21:28:54 -0400 Subject: [ppml] 2007-1, was Re: mail auth proposals In-Reply-To: References: <17946.29331.195163.903019@roam.psg.com> <17947.48664.285554.550528@roam.psg.com> Message-ID: <20070413012854.GA84671@ussenterprise.ufp.org> In a message written on Thu, Apr 12, 2007 at 12:58:50AM -0700, william(at)elan.net wrote: > Perhaps the issue is that its unclear what the goals are for deploying > this email authentication. There can actually be two gaols: > 1. To verify that email address sent to ARIN really came from listed > email address > 2. To verify that the person sending the email and using email address > is really who he says he is Actually, I don't think either of those are the goal. 3. To make it more difficult for a bad actor to supply fraudulent data to ARIN that appears authentic. Having a dead bolt on the door keeps out someone who might walk in if there was no lock, but won't keep out someone willing to break down the door. I think those for PGP would like to see a dead bolt installed. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From mysidia at gmail.com Fri Apr 13 02:29:51 2007 From: mysidia at gmail.com (James Hess) Date: Fri, 13 Apr 2007 01:29:51 -0500 Subject: [ppml] 2007-1, was Re: mail auth proposals In-Reply-To: References: <17946.29331.195163.903019@roam.psg.com> <17947.48664.285554.550528@roam.psg.com> Message-ID: <6eb799ab0704122329v74f964bbv69fb85ddb45491b9@mail.gmail.com> > Perhaps the issue is that its unclear what the goals are for deploying > this email authentication. There can actually be two gaols: > 1. To verify that email address sent to ARIN really came from listed > email address > 2. To verify that the person sending the email and using email address > is really who he says he is For the purposes of replacing mail-auth.. It seems neither #1 nor #2 are truly essential, and concentrating on providing verification features seems a nice distraction.. the needed rigorous verification process to perform verification effectively (I.E. having to examine government- issued ids in person) would encumber uptake of the new auth method and delay realization of some of the utility PGP can offer. I agree there is benefit of having positive verification of public keys associated with a contact also, but I think it should be optional, so contacts don't have that particular "cumbersome verification is required" excuse to stay with mail-from auth method which doesn't provide much safety against mail spoof/ bogus requests. I suggest it also be made possible to register a whois-invisible "update password" on a contact record. Presumably some confirmation e-mail would be used to verify establishment of the password. Instead of using merely the from address, you now have a keycode, that should be filled in to make changes. Users don't need specialized software to include a passcode in their template, and for a third-party to spoof a request, they would need to acquire a copy of a valid e-mail request. That would be a major improvement over simple mail-from auth, and certainly beats using merely mail-from auth to establish the initial PGP key for a contact. For contacts that didn't have a passcode before, generate one randomly, next time any PGP key change is requested, and send an informative e-mail with their generated passcode. Including the passcode later will demonstrate that the person making the request can at least read the e-mail incoming to the listed address. This would provide a means to "bootstrap" the contact's initial PGP public key that is less cumbersome than "chain of trust" in that it does not require third-party signatures to be made on the key, before ARIN could be sufficiently convinced of its legitimacy. Once a passcode is assigned... allow updates that contain the password (whether using PGP or not), provided mail-from auth is also correct. Then provide two options that do use PGP (a) Include the passcode and encrypt the message with a single public PGP key that the registry would provide In fact, this would allow some protection using PGP's encryption, without the contact actually having a PGP key of their own registered yet. And... (b) Provide the option of signing the message using a public key stored on a keyserver and whose fingerprint is part of the WHOIS record for the contact. In this case, the passcode is not included in the message, and neither plaintext nor option (a) is accepted any longer once (b) is successfully utilized. Once (b) is utilized, e-mail address and passcode are irrelevent, at least until such time as the key expires or the user found need to upload a revokation certificate for their PGP key (I.E. due to a later discovery that the key was compromised). [...] -- -J From woody at pch.net Fri Apr 13 05:25:09 2007 From: woody at pch.net (Bill Woodcock) Date: Fri, 13 Apr 2007 02:25:09 -0700 (PDT) Subject: [ppml] 2007-1, was Re: mail auth proposals In-Reply-To: References: <17946.29331.195163.903019@roam.psg.com> <17947.48664.285554.550528@roam.psg.com> Message-ID: On Thu, 12 Apr 2007, william(at)elan.net wrote: > > We don't feel that ARIN should apply something other than the > > normally-accepted PGP authentication process (check government-issued > > photo ID in the physical presence of the other person, and hear their > > key > > fingerprint from them directly). There's a right way to do it, and ARIN > > shouldn't break an established practice. > > So you're in fact thinking about #2 and identity verification as main > purpose behind it? Both #1 and #2. Basically, this is best-practice, as established globally by the other RIRs. It works well enough elsewhere. Obviously one could engineer something else if one were starting from scratch, but it would be unproven. This is proven, and good enough, and not much work. And there's no reason for ARIN to be gratuitously different from the rest of the world, when the difference is for the worse. > I don't understand your reasons. ARIN staff should be free to use any > email authentication method relevant to their job duties and they dont > need our permission. And I don't think policy should be used to educate > them especially when its basically MAY anyway. In this case, MAY is as opposed to MAY NOT, rather than as opposed to SHOULD or MUST. The worry of the authors is that internal staff policy (as opposed to bottom-up public policy) might later get made which precluded staff also signing with their own keys. We thought, as you do, that that would be unfortunate. -Bill From woody at pch.net Fri Apr 13 05:46:09 2007 From: woody at pch.net (Bill Woodcock) Date: Fri, 13 Apr 2007 02:46:09 -0700 (PDT) Subject: [ppml] 2007-1, was Re: mail auth proposals In-Reply-To: <20070413012854.GA84671@ussenterprise.ufp.org> References: <17946.29331.195163.903019@roam.psg.com> <17947.48664.285554.550528@roam.psg.com> <20070413012854.GA84671@ussenterprise.ufp.org> Message-ID: On Thu, 12 Apr 2007, Leo Bicknell wrote: > Having a dead bolt on the door keeps out someone who might walk in > if there was no lock, but won't keep out someone willing to break > down the door. I think those for PGP would like to see a dead bolt > installed. Yes, certainly. I think there are a lot of ways one can look at it. -Bill From info at arin.net Fri Apr 13 10:34:34 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 10:34:34 -0400 Subject: [ppml] Policy Proposal 2007-2 - Staff Assessment Message-ID: <461F94FA.4030708@arin.net> Policy Proposal 2007-2 Documentation of the Mail-From Authentication Method ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-2 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_2.html II. Understanding of the proposal ARIN staff understands that this proposal would define mail-from as the default authentication; it relies on the adoption of Policy Proposal 2007-1: Reinstatement of PGP Authentication Method. III. Issues and concerns A. ARIN Staff 1. Mail-from is the default authentication method by which e-mail communication is evaluated to determine authenticity of the message and identity of the sender. It is not used to protect against "vandalism". Even an authenticated user can vandalize, i.e. with inappropriate comments or with ASCII art. 2. We recommend that a new NRPM section be created, ?12. Communications? and that 12.1 be ?Authentication?. The subsequent numbering would change appropriately. B. ARIN General Counsel The policy as proposed poses no significant legal risks for ARIN. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. However, implementation will depend on the outcome of Policy Proposal 2007-1: Reinstatement of PGP Authentication Method. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-2 Documentation of the Mail-From Authentication Method Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 12.1 Mail-From This section intentionally left blank. ADDITION TO THE NRPM 12.1 Mail-From Mail-From is the default authentication method by which registration records are protected from vandalism. If a registrant fails to designate a more secure method, any subsequent email which bears the sender address of an authorized Point of Contact may be deemed authentic with regard to the registrant's records. Since it is trivial to forge a sender address, Mail-From should not be regarded as secure. Use of Mail-From authentication is not recommended to any registrant who has the means to implement either of the more secure cryptographic authentication methods. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 12 to the NRPM. Section 12 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the mail-from authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 10:34:55 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 10:34:55 -0400 Subject: [ppml] Policy Proposal 2007-3 - Staff Assessment Message-ID: <461F950F.2020605@arin.net> Policy Proposal 2007-3 Documentation of the X.509 Authentication Method ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-3 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_3.html II. Understanding of the proposal ARIN staff understands that this proposal would support X.509 authentication; it relies on the adoption of Policy Proposal 2007-1: Reinstatement of PGP Authentication Method. III. Issues and concerns A. ARIN Staff 1. Proposals use the term "crypt-auth", term needs to be defined. Also, would need specific notation, such as crypt-pgp and crypt-x509. 2. "Accepts X.509 signed transactions as authentic communications from authorized POCs" - this needs clarification. What certification sources should be considered when accepting X.509 certificates? 3. NRPM section 12.3 contains procedural language which constrains ARIN's ability to act in the best interest of all parties. It is too restrictive and detailed. 4. At this time, ARIN?s functionality covers only e-mail based communication. The policy uses the general term, ?communication?, which may be interpreted to cover other forms of electronic interaction such as web-based communication. The only other ?communication? that is directly tied into a specific POC is voting. Should the Election System need to be modified to allow x.509 authentication, assuming we could use parts of the existing system, a ballpark estimate on implementation would be 3-4 months. 5. We recommend that a new NRPM section be created, ?12. Communications? and that 12.1 be ?Authentication?. The subsequent numbering would change appropriately. B. ARIN General Counsel The policy as proposed poses no significant legal risks for ARIN. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 120 days from the date of the ratification of the policy by the ARIN Board of Trustees. However, implementation will depend on the outcome of Policy Proposal 2007-1: Reinstatement of PGP Authentication Method. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-3 Documentation of the X.509 Authentication Method Policy statement Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 12.3 X.509 This section intentionally left blank. ADDITION TO THE NRPM 12.3 X.509 ARIN accepts X.509-signed transactions as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 12 to the NRPM. Section 12 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the X.509 authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 10:35:08 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 10:35:08 -0400 Subject: [ppml] Policy Proposal 2007-4 - Staff Assessment Message-ID: <461F951C.6080104@arin.net> Policy Proposal 2007-4 Changes to IPv6 policy - removal of "interim" consideration ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-4 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_4.html II. Understanding of the proposal ARIN staff understands that this proposal would remove the sentence that refers to IPv6 policy as interim policy. III. Issues and concerns A. ARIN Staff No comments at this time. B. ARIN General Counsel The policy as proposed poses no significant legal risks for ARIN. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-4 Changes to IPv6 policy - removal of "interim" consideration Proposal type: delete Policy term: permanent Policy statement: Delete following text at section 6.1.1 of NRPM: "This policy is considered to be an interim policy. It will be reviewed in the future, subject to greater experience in the administration of IPv6." Rationale: The actual text suggest that it is an interim policy, however it is not longer the case. It is clear that any policy is always subjected to changes, however other policies don't have such text. It may be even considered as a negative "message" for IPv6 deployment, especially because the possible "reading" as "not enough experience and this is going to be changed, better wait", which is not a real situation. No financial/liability implications for the community and ARIN are foreseen. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 10:35:17 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 10:35:17 -0400 Subject: [ppml] Policy Proposal 2007-5 - Staff Assessment Message-ID: <461F9525.2030406@arin.net> Policy Proposal 2007-5 Changes to IPv6 policy - removal of "multiple /48" justification ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-5 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_5.html II. Understanding of the proposal Current policy is that ISPs are required to obtain approval from ARIN when assigning an additional /48 to a single site. ARIN staff understands that this proposal would remove that policy. III. Issues and concerns A. ARIN Staff 1. ARIN has not yet seen or reviewed any requests for additional or subsequent assignments to the same end site. 2. The existing policy text is confusing and might indicate to some that even initial assignments of more than a /48 would need to be reviewed by staff. However, we have not done this and have allowed larger than /48 reassignments to be processed. 3. In addition, the policy text contains no criteria for ARIN to use in their assessment of assignments larger than /48. B. ARIN General Counsel This policy as proposed poses no significant legal risks for ARIN. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Template change - Minor update to software - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-5 Changes to IPv6 policy - removal of "multiple /48" justification Proposal type: delete Policy term: permanent Policy statement: Delete section 6.5.4.2 of NRPM. Rationale: The current text requires the LIR to justify to the RIR/NIR when assigning multiple /48s to a single end site. It seems that the reason for this requirement is the lack of experience, which seems unreasonable after a few years this policy has been implemented, even if may not have been specific cases which used this policy section. It seems useless, now that there is already deployment experience, to require a justification from the LIR to ARIN for assigning multiple /48s (or a shorter prefix, such as for example a /47). It is up to the LIR to require the justification to its own customers and decide according to it. The LIR will be already responsible to justify to ARIN the usage of any allocated block(s) when requesting for more, and this will already implicate an implicit justification of this kind of assignments. With this policy change, both ARIN and LIR staff will save resources in a justification, which seems unnecessary and should be completely on the hands of the LIR itself. No financial/liability implications for the community and ARIN are foreseen. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 10:35:27 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 10:35:27 -0400 Subject: [ppml] Policy Proposal 2007-7 - Staff Assessment Message-ID: <461F952F.3070400@arin.net> Policy Proposal 2007-7 Creation of Policy for Subsequent End-User IP Requests/Assignments ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-7 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_7.html II. Understanding of the proposal ARIN staff understands that this proposal would establish the criteria for subsequent end-user IPv4 address space requests. III. Issues and concerns A. ARIN Staff No comments at this time. B. ARIN General Counsel The policy as proposed poses no significant legal risks for ARIN. We also believe that it is useful to be specific in the manner articulated by the proposed policy. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-7 Creation of Policy for Subsequent End-User IP Requests/Assignments Proposal type: New Policy term: Permanent Policy statement: 4.3.6 Additional Assignments "In order to justify an additional assignment, end-users must have efficiently utilized at least 80% of all previous assignments, and must provide ARIN with utilization details. The prefix size for an additional assignment is determined by applying policies 4.3.2, and 4.3.3." Rationale: There are no published criteria for additional assignment requests from end-user networks. NRPM 4.3 seems to only cover initial assignments. NRPM 4.3.3 states, in part, "Requesters must show exactly how previous address assignments have been utilized and must provide appropriate details to verify their one-year growth projection." Unfortunately, the above text does not specify any metrics for ARIN staff to apply when determining if an additional assignment is justified. Though most end-users only get one assignment, some end-users request a 2nd or 3rd or Nth assignment. Currently, the ARIN staff applies what they perceive to be "efficient utilization" criteria; for instance, the end-user must have utilized at least 80% of last assignment and must provide ARIN with utilization details. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 10:35:38 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 10:35:38 -0400 Subject: [ppml] Policy Proposal 2007-8 - Staff Assessment Message-ID: <461F953A.8000503@arin.net> Policy Proposal 2007-8 Transfer Policy Clarifications ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-8 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_8.html II. Understanding of the proposal ARIN staff understands that this proposal would standardize the use of the term "number resources" throughout the transfer section of the NRPM. III. Issues and concerns A. ARIN Staff No comments at this time. B. ARIN General Counsel The ARIN General Counsel stated, "We are reviewing this policy. In the past, we have advised that transfer issues create the risk of litigation when ARIN refuses to transfer resources. In view of the non-uniform RSAs, including some that have different dispute mechanisms, ARIN should handle any changes regarding transfer as a policy, rather than amending the RSA. ARIN should consider amending the proposed policy so as to provide, in sum or substance, that if a party does not obtain the transferred resources within a certain period of time, e.g., 30 days or 45 days, then it would have the right to initiate a dispute in the forum specified under the current RSA or the RSA that governs the party." IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-8 Transfer Policy Clarifications Proposal type: Modify Policy term: Permanent Policy statement: That Section 8 of the NRPM is replaced as follows: 8. Transfers 8.1. Transfers 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. Transfer Requirements ARIN will consider requests for the transfer of number resources only 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. 8.3. Documentation 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 resources 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 address space is being utilized * Network engineering plans, including: o Host counts o Subnet masking o Network diagrams o Reassignments to customers Policy Rationale Staff analysis and community comments have a problem with the inconsistent use of the terms "ASN" and "IP Address" in this section which leads to confusion on which resources can be transferred. The entire section now utilizes the term "number resources" to clarify what would appear to be the original intent. A section regarding the handling of customer networks outside ARIN's geographic region has been removed to reflect the actual current procedure utilized that was developed in conjunction with the ERX transfer project. The last section of old text has been removed as it does not appear to be so much policy as guidance. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 10:35:48 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 10:35:48 -0400 Subject: [ppml] Policy Proposal 2007-11 - Staff Assessment Message-ID: <461F9544.4070600@arin.net> Policy Proposal 2007-11 Refinement of ISP Initial Allocation Policy ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-11 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_11.html II. Understanding of the proposal ARIN staff understands that this proposal would remove a sentence which refers to completing a template. III. Issues and concerns A. ARIN Staff No comments at this time. B. ARIN General Counsel The policy as proposed poses no significant legal risks for ARIN. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-11 Refinement of ISP Initial Allocation Policy Policy statement Proposal type: modify Policy term: permanent Policy statement: In NRPM 4.2.4.3 (Initial Allocations to ISPs Policy), strike the following sentence: "When completing Section 7 of the ARIN ISP Network Request Template, please keep this in mind" Rationale: Instructions on filling out templates properly belong in the instructions attached to the template, not as part of a policy statement. This reminder makes reference to an obsolete template and section. ARIN released new templates in August 2006 and changed template names, field numbers, and sections which made both of these references obsolete. Timetable for implementation: Immediate From Ed.Lewis at neustar.biz Fri Apr 13 10:55:45 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 13 Apr 2007 10:55:45 -0400 Subject: [ppml] Policy Proposal 2007-3 - Staff Assessment In-Reply-To: <461F950F.2020605@arin.net> References: <461F950F.2020605@arin.net> Message-ID: At 10:34 -0400 4/13/07, Member Services wrote: >ARIN Staff Assessment I don't know if this is the first time these were sent in advance, I'm glad to see the assessments before the meeting. > http://www.arin.net/policy/proposals/2007_3.html > 3. NRPM section 12.3 contains procedural language which constrains >ARIN's ability to act in the best interest of all parties. It is too >restrictive and detailed. I have a question about this - this is about the "proposed" 12.3 as seen in the appendix? (OK, maybe this is a stupid question as there is no current 12.) I.e.,: >ADDITION TO THE NRPM > >12.3 X.509 > >ARIN accepts X.509-signed transactions as authentic communication from >authorized Points of Contact. POCs may denote their records >"crypt-auth," subsequent to which unsigned communications shall not be >deemed authentic with regard to those records. I don't see how it is "too" restrictive and detailed. I don't mean to say that I disagree, I'm not clear on the criticism levied on the proposal. What if a POC has both an PGP-signed-by-ARIN key and an ARIN issued X.509 certificate? (More of a question to the proposal writers than to staff I suppose.) Will either "PGP-signed" or "X.509-signed" templates/mail be accepted and unsigned templates/mail be dropped? > 4. At this time, ARIN's functionality covers only e-mail based >communication. The policy uses the general term, "communication", which >may be interpreted to cover other forms of electronic interaction such >as web-based communication. The only other "communication" that is >directly tied into a specific POC is voting. Should the Election System >need to be modified to allow x.509 authentication, assuming we could use >parts of the existing system, a ballpark estimate on implementation >would be 3-4 months. > > 5. We recommend that a new NRPM section be created, "12. >Communications" and that 12.1 be "Authentication". The subsequent >numbering would change appropriately. What about 12.1 being "Template Submission and Response" and 12.1.x being "Authentication? Given the comment in 4, that's where I thought 5 would lead. PS - and we thought the IPv4 sunset policy was complicated... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From michael.dillon at bt.com Fri Apr 13 11:15:47 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 13 Apr 2007 16:15:47 +0100 Subject: [ppml] Policy Proposal 2007-3 - Staff Assessment In-Reply-To: <461F950F.2020605@arin.net> Message-ID: > 4. At this time, ARIN's functionality covers only > e-mail based > communication. The policy uses the general term, > "communication", which > may be interpreted to cover other forms of electronic interaction such > as web-based communication. The only other "communication" that is > directly tied into a specific POC is voting. Should the > Election System > need to be modified to allow x.509 authentication, assuming > we could use > parts of the existing system, a ballpark estimate on implementation > would be 3-4 months. This is the kind of rathole you get into when you put too many details into a policy. Policy is not a process document. Policy is a general framework that defines limits, mandates, etc. > 5. We recommend that a new NRPM section be created, "12. > Communications" and that 12.1 be "Authentication". The subsequent > numbering would change appropriately. This is a good idea, but the details still need to be kept out of policy. For instance: ---------- 12.1 Authentication - ARIN will maintain and support a variety of mechanisms to authenticate communication. The mechanisms will meet the following principles: a) Organizations can implement the authentication using software which is in the public domain or is licenced by one of the open-source licences accepted by the Open Source Initiative. b) The mechanism is reviewed by someone certified by GIAC and if deficiencies are found, these are published and a more secure mechanism is also made available. c) The ARIN membership is polled on a regular basis to ensure that the mechanisms available meet their needs. d) Any suggestions made under the ASCP which indicate issues with the security of a mechanism are dealt with promptly in consultation with a GIAC-certified expert. ------------- Note that I never mentioned PGP or X.509 because these are irrelevant to policy. I did mention GIAC certification but this can be achieved by training ARIN staff, hiring new staff, or hiring a consultant as needed. I also mentioned polling the members to ensure that if there is demand for a new mechanism (RESTful API over HTTPS) it will get implemented and if there is demand to keep the insecure mail-from, it will be kept as one of a number of options. I also included the open-source comment because I believe that it is consistent with ARIN's nature as an open organization and with the history of RIR support software development. If that policy had been in place, and the ASCP had been in place, I suspect that the submitters of 2007-1, 2, 3 would never have bothered to submit these policy proposals. --Michael Dillon From Daniel_Alexander at Cable.Comcast.com Fri Apr 13 14:05:19 2007 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Fri, 13 Apr 2007 14:05:19 -0400 Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4 AddressCountdown In-Reply-To: <3D08044E-7626-4254-8988-672E59A055B6@muada.com> References: <1582DCBFF968F044A9A910C0AB177C9012FF96@cliff.cdi.local> <3D08044E-7626-4254-8988-672E59A055B6@muada.com> Message-ID: <2271C950731A734680BA3E2978816F1809C7B97E@NJCHLEXCMB01.cable.comcast.com> Iljitsch, Sorry for the late response, but I am having a hard time keeping up with this mailing list. I just wanted to clarify a point you made below about one of the allocations. Comcast actaully received that address space in three installments over an 18 month period. The first was in April of 05, with the last piece of the /8 being allocated in 12/06. All ISP, regardless of size, are still bound by the timeframe policies in every RIR. The size of any ISP's request can only be for what they can justifiably use within a certain timeframe. For the ARIN region it is currently six months. So while we ended up with the whole /8, we were only given it because we actaully put it to use over a now, two year time frame. The problem with a size restriction is that is doesn't change demand. It will only cause ISP to submit more applications, more often with the end result being the same. If you use a million IP for your customers in a year, the only difference between two applications in that year or a dozen, is the amount of administrative work that is done to process the apps. -Dan -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Iljitsch van Beijnum Sent: Tuesday, April 03, 2007 2:22 PM To: Jim Weyand Cc: ppml at arin.net Subject: Re: [ppml] Summary of Trial Balloons for Dealing with IPv4 AddressCountdown On 30-mrt-2007, at 23:34, Jim Weyand wrote: > I find myself struggling with how to convert the suggestions and > comments on this list into actual policy proposals. Perhaps it would be a good idea to see if we can agree on what our goals and assumptions are. An important question is whether it's a good idea to try and postpone the moment when the RIRs have to turn down requests for lack of free address space. Assuming we still have around five years, and that a great deal can be accomplished in that time, is it worth going through a lot of trouble to buy us a limited number of additional years? > 4) Several similar informal proposals to encourage recycling by > empowering ARIN to more actively police the use of IPv4 addresses by > various means > 6) An informal proposal to ask holders of unused address IPv4 > addresses to voluntarily return the addresses A "use it or lose it" policy would make sense. Large amounts of address space aren't visible on the global internet, so either people aren't using it at all, or they're only using it internally. If we set a deadline by which address space must be "in use" (hard to define) or it will be put at the end of the free list, this gives people who are using it for internal purposes a reasonable amount of time to move to something else. > 7) Several variants of informal proposals to start assigning > IPv6 > space with IPv4 > 8) An informal proposal to get endusers to demand access to IPv6 > networks by creating a media storm similar to Y2K. The depletion of IPv4 and the adoption of IPv6 are largely orthogonal in the short term. Having IPv6 doesn't mean you don't need IPv4 any more, not having IPv4 doesn't make IPv6 more useful. This is what I suggest: In my opinion, it's a problem that the RIRs are giving out extremely large blocks of address space to the world's largest ISPs. For instance, Softbank has a /8, Comcast got a /8 in two installments and French, Deutsche and British Telecom all have multi-million sized blocks. Even very large ISPs need some time to put these amounts of address space to use, so what happens is that at various intervals, new large blocks are requested, so the number of addresses given out in any particular year varies widely because one request can be as much as 5 to 10 % of the yearly world-wide use. So giving out large blocks makes making predictions harder. Another problem is that if and when business stalls, a good part of a large block will go unused. For both of these reasons, it's a good idea to limit the maximum block size that is given out *today*. When we start to run out of address space for real, this only gets worse, and we run the risk that a large request clears out the remaining address space in one go. To avoid this, we should adopt a policy where there is a maximum block size, and a minimum interval between obtaining address blocks. As the number of addresses left gets smaller, the maximum block size is reduced. For instance, we could make the maximum block size 2 million and the minimum interval 2 months. So if an ISP thinks they need 16 million addresses in a year, they'll have request 2 million, wait 2 months, request another 2 million and so on. In 3 or 4 years, the limit could be half a million, so someone needing 16 million addresses would only be able to get 6 x 1/2 million = 3 million. (Note that people who need smaller blocks still get what they need.) The effect is that an ISP who signs up 16 million new users each year will then have to share an IPv4 address over several users, where the number of users per address increases every year, rather than that in year X every user can get their own address and in year Y there's nothing left. The maximum block size could each year be set to (for instance) the next higher CIDR boundary of 0.1% of the remaining IPv4 address space. This policy has the important property of being predictable so people can plan rolling out new technologies to deal with the IPv4 address shortage in ways that fit their business. A problem would be that this works per-organization, so it favors smaller organizations over larger ones. _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From info at arin.net Fri Apr 13 14:21:49 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 14:21:49 -0400 Subject: [ppml] Policy Proposal 2007-6 - Staff Assessment Message-ID: <461FCA3D.2030400@arin.net> Policy Proposal 2007-6 IPv4 PI minimum size change ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-6 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_6.html II. Understanding of the proposal ARIN staff understands that this proposal would reduce the minimum assignment for multihomed end-users from a /22 to a /24 IPv4 address block. III. Issues and concerns A. ARIN Staff 1. There is very little qualification criteria which could lead to policy abuse by spammers. These entities could create many different accounts over time as their existing space gets blacklisted or becomes otherwise unusable. 2. This could significantly increase the number of requests for ARIN services thereby requiring additional Registration Services Department and Financial Services Department staff. 3. Policy applies only to end users which could be perceived as unfair to ISPs. This could also lead to potential abuse of the policy if ISPs apply as end users for single /24 IPv4 address block. 4. It is unclear exactly how an organization can qualify for a /24 IPv4 address block under this policy. It appears that NRPM section 4.3.3, Utilization rate, requires 25% immediate, 50% within 1 year, would be the justification criteria. However, NRPM section 4.2.3.6, Reassignments to multihomed downstream customers, indicates that an ISP can reassign a /24 IPv4 address block without regard to planned host counts as long as the customer is multi-homed. The question here is does this policy allow ARIN to qualify a requestor for a /24 IPv4 address block based solely on multi-homing or should host counts also be taken into account? 5. The policy does not address requests for more than one /24 IPv4 address block for multiple sites. 6. NRPM Section 4.4, Micro-allocation, should remain as is since it is a policy section essential for micro-allocation for critical infrastructure related requests. B. ARIN General Counsel The policy as proposed poses no significant legal risks for ARIN. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation might require the acquisition of staff personnel or equipment. It will require the following: - Minor update to software - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-6 IPv4 PI minimum size change Proposal type: modify Policy term: permanent Policy statement: In section 4.3.2.2 of the NRPM, change all occurences of "/22" to "/24". (That is, replace the existing 4.3.2.2 with this text: For end-users who demonstrate an intent to announce the requested space in a multihomed fashion, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose.) Remove references to IPv4 in section 4.4, as they are no longer relevant. Section 4.4 could be moved, at the discretion of the NRPM editors, to somewhere in section 6, for clarity. Rationale: The rationale for moving the allocation "edge" for IPv4 PI space to /24 has three fundamental points: routing slot consumption would be unchanged, it reflects widespread routing practices, and it discourages waste. While experiments indicate that a few ISPs still try to filter at the /22 boundary, I have been repeatedly told that most don't filter anything shorter than a /24. While routing policy and allocation policies don't need to necessarily match, it is not unreasonable to have them in alignment. In addition, by keeping the PI allocation size for multi-homed organizations at /22, organizations seeking PI space that don't meet the requirements may be encouraged to exaggerate their address usage. This is something that should clearly not be encouraged. On the topic of routing slots, I would like to note that any org qualifying under the PI policies in 4.3.2.2 would also qualify for PA space, and would likely have an interest in multi-homing regardless of the usage of PA vs. PI space. In either instance, a routing slot is consumed by a /24. This policy change should therefore have minimal, if any, impact on the size of the global routing table. It merely gives organizations more options at a slightly smaller network size. Remember that for consideration under 4.3.2.2, an organiztion *must* be multi-homed. On a side note, it's tempting to remove the restriction entirely. If an organization only qualifies for a /28 (for example), they could receive an allocation of that size. Market forces would decide if that /28 was worth a routing slot. If the /28 contained my personal website, I suspect it would not be routable. If that /28 contained Microsoft Update, I suspect it would. In the interest of operational sanity and simplicity, I am not making a proposal to remove the restriction. (Note that section 4.1.1 explicitly notes that PI addresses are not guaranteed to be globally routable.) There is fundamental conflict between the urge for aggregation and the desire for conservation. The latter would prefer that organizations not have any excess space, while the former would prefer that fewer networks exist in the DFZ, regardless of wastage. Since the DFZ already permits deaggregation to /24, the conservation urge should be allowed to push to that edge. As noted in 4.1.5, "determination of IP address allocation size is the responsibility of ARIN." This proposal simply allows the community to request appropriately sized blocks, and ARIN to allocate prefixes of a size that is commensurate with established need. Timetable for implementation: immediate From info at arin.net Fri Apr 13 14:21:59 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 14:21:59 -0400 Subject: [ppml] Policy Proposal 2007-9 - Staff Assessment Message-ID: <461FCA47.8040608@arin.net> Policy Proposal 2007-9 Modernization of ISP Immediate Need Policy ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-9 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_9.html II. Understanding of the proposal ARIN staff understands this proposal would change the immediate need policy by reducing the minimum allocation from a fixed /20 IPv4 address block to ARIN?s current minimum allocation as defined elsewhere in the NRPM, and would set the maximum allocation size at a /16 IPv4 address block. The policy also defines a 30 day utilization window of the IP address space. III. Issues and concerns A. ARIN Staff No comments at this time. B. ARIN General Counsel The policy as proposed poses no significant legal risks for ARIN. We also believe that this policy is beneficial because it prevents the waste of resources. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-9 Modernization of ISP Immediate Need Policy Proposal type: modify Policy term: permanent Policy statement: Modify NRPM 4.2.1.6 to read: If an ISP has an immediate need for address space, and can provide justification to show that the address space will be utilized within 30 days of the request, ARIN may issue a block of address space, not larger than a /16 nor smaller than ARIN's customary minimum allocation, to that organization. These cases are exceptional. Current text of 4.2.1.6: If an ISP has an immediate need for address space, i.e., the need exists the day of the request, ARIN may issue a /20 if the organization, such as a new company, shows justification. However, these cases are exceptional. Rationale: ARIN staff and ARIN members have identified a few long-standing problems with the Immediate Need policy. This policy proposal attempts to address the following concerns: * The Immediate Need policy only allows ISPs to qualify for a /20 worth of space, when a larger size block may be necessary to provide proper coverage for the proposed project. An example justifying larger space is an MSOs for which a /20 is insufficient to put an address block larger than a /29 or /30 on each CMTS in a metropolitan area). * Conversely, this policy was written before the current multi-homed policy (which allows allocations of /21s and /22s). The Immediate Need policy should allow assignment of smaller blocks of space if those are justified. * The example used in the Immediate Need policy gives the impression that an immediate need must exist the day of the request. This seems both unfair and unreasonable and should probably be changed to reflect a realistic timeframe. Concerns expressed about the Immediate Need Policy but NOT addressed by this policy proposal (but addressed in a subsequent policy proposal): * The policy as written allows ARIN to issue a /20 to an ISP only. However, section 4.3.4. "Additional Considerations" of the End User Policy in the NRPM states that "End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4].". In order to be consistent, the Immediate Need policy language should be changed to reflect the fact that both ISPs and end-users can qualify under this policy. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 14:22:09 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 14:22:09 -0400 Subject: [ppml] Policy Proposal 2007-10 - Staff Assessment Message-ID: <461FCA51.1080108@arin.net> Policy Proposal 2007-10 End Site Immediate Need Policy ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-10 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_10.html II. Understanding of the proposal ARIN staff understands that if Policy Proposal 2007-9: Modernization of ISP Immediate Need is adopted, then Policy Proposal 2007-10: End Site Immediate Need Policy would establish the immediate need policy for end-users. The minimum assignment would be the ARIN?s minimum assignment as defined elsewhere in the NRPM, and the maximum would be a /16 IPv4 address block. The policy also defines a 30 day utilization window of the IP address space. If Policy Proposal 2007-9: Modernization of ISP Immediate Need is not adopted, then Policy Proposal 2007-10: End Site Immediate Need would require replicating the text from the existing ISP Immediate Need policy into the end user section of NRPM. III. Issues and concerns A. ARIN Staff Text should have 'allocation' changed to 'assignment' because this refers to end-user assignments. B. ARIN General Counsel The policy as proposed poses no significant legal risks for ARIN. We also believe that this policy is beneficial because it treats categories of applicants equally. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-10 End Site Immediate Need Policy Proposal type: new Policy term: permanent Policy statement: Create new section in NRPM 4.3.6. to mirror the intent of 4.2.1.6, but modified for end sites. If pending proposal "Modernization of ISP Immediate Need Policy" is ratified, this new section will read: 4.3.6 Immediate Need: If an end-user has an immediate need for address space, and can provide justification to show that the address space will be utilized within 30 days of the request, ARIN may issue a block of address space, not larger than a /16 nor smaller than ARIN's customary minimum allocation, to that organization. These cases are exceptional. In the absence of ratification of ""Modernization of ISP Immediate Need Policy", this proposal is to add section 4.3.6 with a modification of the current text of 4.2.1.6 to make it apply to end-users: 4.3.6 Immediate Need: If an end-user has an immediate need for address space, i.e., the need exists the day of the request, ARIN may issue a /20 if the organization, such as a new company, shows justification. However, these cases are exceptional. Rationale: ARIN staff has expressed the concern that the current policy is self-contradictory, in one place stating that the Immediate Need Policy applies to ISPs, and in another place stating that end users can qualify under it. The communication received was: * The policy as written allows ARIN to issue a /20 to an ISP only. However, section 4.3.4. "Additional Considerations" of the End User Policy in the NRPM states that "End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4].". In order to be consistent, the Immediate Need policy language should be changed to reflect the fact that both ISPs and end-users can qualify under this policy. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 14:22:19 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 14:22:19 -0400 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment Message-ID: <461FCA5B.90109@arin.net> Policy Proposal 2007-1 Reinstatement of PGP Authentication Method ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-1 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_1.html II. Understanding of the proposal ARIN staff understands this proposal would support PGP authentication. III. Issues and concerns A. ARIN Staff 1. We recommend that a new NRPM section be created, "12. Communications", and that 12.1 be "Authentication". The subsequent numbering would change appropriately. 2. The proposal uses the term "crypt-auth" as a notation to be affixed to POC records. Such notation is not technically necessary for ARIN systems to discern authentication methods, because mere existence of a stronger-authentication method than mail-from can (and currently does) automatically disable mail-from authentication. 3. Staff believes that there was a formatting problem with the policy submission. It appears that the authors inadvertently incorporated procedural text under the headings "UPDATES TO TEMPLATES", "UPDATES TO DOCUMENTATION", and "KEY USE IN COMMUNICATION" under the policy text labeled "12.3 X.509: This section intentionally left blank.? If passed without edit, such procedural text could be incorporated into the NRPM. Staff suspects this was not the author's intent, as these headings and their subsequent text are not numbered. 4. In the section "KEY USE IN COMMUNICATION", the proposal requires validation of "a chain of trust not longer than five steps" between the signing key and ARIN's hostmaster role key, without regard to whether such intermediary signers are ARIN POCs, or are even known to ARIN. Without direct binding of the PGP key to an ARIN POC record, such anonymity in the chain of trust raises serious questions about how ARIN staff will know and evaluate that an e-mail from a signer is authentically from the ARIN POC that the sender claims to be. 5. A PGP-key for hostmaster at arin.net exists on pgp.mit.edu as well as other well-known PGP-key repositories. This key was set up during the early days of ARIN, and the passphrase for the key is, as of this writing, MIA. This prevents ARIN from using the key to sign anything, and furthermore prevents ARIN from removing the key from the key repositories mentioned above. Although ARIN could proceed by generating a new PGP-key, we would need to use a limited distribution mechanism that excludes well-known servers, since more than one key for the same e-mail address cannot exist in the key servers. Such distribution might occur at key-signing parties at ARIN meetings, et.al. so that persons wanting to rely upon PGP-signed communications from ARIN can validate using the proper key. However, those individuals inadvertently using the well-known repositories for ARIN's "old" PGP-key to encrypt their communication with ARIN will likely get an "invalid signature" type of response f rom ARIN since they have used a key that we cannot decrypt (because the passphrase is MIA). It is noted that all of these issues regarding the lost passphrase can be overcome (and, is overcome in generally accepted practice) by changing the e-mail address in question that's bound to the PGP-key. The difficulties introduced by changing the well-known e-mail address of hostmaster at arin.net to some other address makes such a change an unattractive option. 6. Currently ARIN uses two e-mail addresses, hostmaster at arin.net and reassign at arin.net, to accept e-mail. The purpose for the differentiation is primarily workflow-related: submissions to hostmaster are generally handled manually while submissions to reassign are generally able to be handled by automated software. PGP-key best practice dictates that each e-mail address have a separate key, and we would implement according to this practice. Staff notes that having two keys, and two addresses, may create opportunities for confusion or inadvertent misapplication of the wrong key to e-mails during functions like verification or encryption (i.e. use hostmaster's key to encrypt a submission to reassign). The concern is partially ameliorated by the fact that many MUAs will automatically select the proper key for encryption or verification based upon the e-mail address, but staff is aware that significant amounts of e-mail communication takes place outside of typical MUAs (e.g., c ustom scripts, etc.), leaving some degree of concern. 7. The proposal text "ARIN shall PGP-sign all outgoing hostmaster email with the hostmaster role key, and staff members may optionally also sign mail with their own individual keys" implies that staff may sign with arbitrarily-sourced individual keys. We intend that if such keys are generated, they would be signed with ARIN's hostmaster key and controlled procedurally to maintain communication integrity between ARIN and its customers, including publication of those keys in widely-known repositories. B. ARIN General Counsel Counsel has some concerns regarding liability that might be imposed on ARIN to by proposed policy 2007-1. These concerns may be resolved by explanation to cure my ignorance, or by editing if the concern exists. My most specific concern is that ARIN 'validate a chain of trust not longer than 5 steps"....I am concerned about fraud that may occur somewhere in the 5 steps that is not detected by ARIN. I have been told by techies that such an undetected fraud could easily occur. Does this policy leave ARIN responsible for damages to third parties, including our members, if it does not detect such fraud? It seems to me that establishment of an overall ARIN policy of cooperating in using PGP does not create this concern, but this specific language does. Is the additional language integral to PGP and hence unusual and unobjectionable? I apologize in advance if this is an instance where my lack of technical knowledge creates confusion. IV. Resource Impact - Significant The resource impact of implementing this policy is significant. Barring any unforeseen resource requirements, this policy could be implemented within 4-12 months from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Template change - Revision to Registration Software - Revision to Directory Services - Revisions to registration guidelines - Staff training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-1 Reinstatement of PGP Authentication Method Proposal type: New Policy term: Permanent Policy statement: ADDITION TO NRPM 12 Authentication Methods 12.1 Mail-From This section intentionally left blank. 12.2 PGP ARIN accepts PGP-signed email as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. 12.3 X.509 This section intentionally left blank. UPDATES TO TEMPLATES ARIN shall update templates as necessary to identify and distinguish between mail-from, PGP, and X.509 authentication methods. UPDATES TO DOCUMENTATION ARIN shall update documentation as appropriate to explain the differences between mail-from, PGP, and X.509 authentication methods. KEY USE IN COMMUNICATION: ARIN shall accept PGP-signed communications, validate that a chain of trust not longer than five steps exists between the signing key and the ARIN hostmaster role key, compare the signing key to the identity of the authorized POCs for records referenced in the correspondence, and act appropriately based upon the validity or invalidity of the signature. ARIN shall PGP-sign all outgoing hostmaster email with the hostmaster role key, and staff members may optionally also sign mail with their own individual keys. ARIN shall accept PGP-encrypted communications which are encrypted using ARIN's hostmaster public key. ARIN shall not encrypt any outgoing communications except at the prior request of the recipient. Policy Rationale Rationale: Globally, PGP is the most commonly used cryptographic authentication method between RIRs and resource recipients who wish to protect their resource registration records against unauthorized modification. The PGP-auth authentication method is supported by RIPE, APNIC, and AfriNIC, LACNIC supports an equivalent mechanism, and PGP was historically supported by the InterNIC prior to ARIN's formation. By contrast, current ARIN resource recipients have only two options: "mail-from," which is trivially spoofed and should not be relied upon to protect important database objects, and X.509, which involves a rigorous and lengthy proof-of-identity process and compels use of a compatible MUA, a combination which has dissuaded essentially all of ARIN's constituents. Additionally, X.509's centralized failure mode is technically and ideologically repugnant to some members of the community, who should not be forced to choose between two evils. There isn't a lot of work to do here, and certainly nothing tricky. PGP is simple code, which was supported by the InterNIC, and which the other RIRs deployed without a second thought or complaint. If RIPE and APNIC have always done this, the InterNIC did it before ARIN was formed, and LACNIC and AfriNIC took the need for cryptographic security for granted as a part of their startup process, we see no reason why ARIN should be the only RIR to not offer this most basic of protections to its members. We need to get PGP support reinstated, so that our records can be protected against hijacking and vandalism, and so we won't look like idiots as the only one of the five regions that can't figure this stuff out. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 14:22:31 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 14:22:31 -0400 Subject: [ppml] Policy Proposal 2007-12 - Staff Assessment Message-ID: <461FCA67.60702@arin.net> Policy Proposal 2007-12 IPv4 Countdown Policy Proposal ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-12 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_12.html II. Understanding of the proposal ARIN staff understands that this proposal would halt direct IPv4 allocations and assignments from ARIN on the day which is exactly two years after the day that the IANA pool is equal to 30 /8 IPv4 address blocks. III. Issues and concerns A. ARIN Staff 1. It is unclear what the reference to ?There will be no change to the policy on A-date? is. What does this mean? On this day and in the future? 2. What happens to customers who come in after T-date to request IPv4 space? Do we deny these requests? Do we recommend IPv6? Do we do nothing? How can we deny a legitimate request when v4 resources still exist? 3. Author did not indicate placement. Could be put in as new section 4.9 of the NRPM Section 4.9. Also, that section would need a heading, perhaps, "Availability of IPv4 Address Space". 4. Need to make clear this applies to both assignments and allocations. 5. Change text that says "RIRs must" to "ARIN must". And references such as, "set the date" to "ARIN will set the date?" 6. Change /8 references to have amounts written out, such as "10*/8" to "ten /8s". 7. The following text lacks criteria and detail, "- It is however possible to move T-date forward at the point where address consumption exceeds the projections during the course of two years". Who decides, what projections, how much? 8. Remove "Allocations or assignments to "critical infrastructure" after T-date should be defined by a separate policy." 9. Prior to T date, there may be an increase in requests, perhaps necessitating more staff. 10. What happens to reserved space? 11. If IPv4 is replaced by IPv6 then one could assume that organizations would return their IPv4 back to ARIN and that space would be available for reallocation. However, this policy would effectively preclude ARIN from reusing this returned space. 12. The proposal would hasten the loss of revenue by approximately 12% per year (4% if the IPv6 fee waiver was lifted). B. ARIN General Counsel This proposal addresses an important policy issue that is worthy of extended debate and consideration, but it proposes to do so in a way that may inadvertently create profound legal issues that would dramatically increase ARIN's potential legal liabilities. The policy proposes to set a hard date to terminate IPv4 allocations. Adoption and implementation of such a policy has a clear legal impact: it could, for example, be deemed a denial of service by ARIN, which is a utility provider of such services. For example, if IPV4 is exhausted and unavailable from IANA, there is little or no legal risk to ARIN. However, there are dramatically increased risks to ARIN associated with refusing to provide IPv4 addresses if ARIN has such addresses available, and is refusing to issue any of them to anyone based on a well intentioned but absolute policy. ARIN's legal counsel will need to carefully evaluate any policy which results from this activity. Based on my current understanding, and I am willing to constantly reconsider and do additional research, I am likely to recommend that ARIN not adopt such a policy in its current form because of the profound legal risks it creates. This is one of the few times my advice prior to consideration of a policy has been so direct. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Determining A and T dates assumes coordination among the RIRs. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-12 IPv4 Countdown Policy Proposal Proposal type: new Policy term: renewable Policy statement: - Set the date for termination of (IPv4) allocations and the date of announcement Set the date to terminate allocations as a general rule, and announce it a certain period in advance. Define the date of announcement as "A-date" and the date to terminate allocations as "T-date". The two dates will be set as follows: A-date (Date of Announcement): - The day in which the IANA pool becomes less than 30*/8 - RIRs must announce "T-date" on this day, which is defined later (*) There will be no changes in the policy on A-date T-date(Date of Termination): - Exactly two years after A-date - 10*/8 blocks should remain at T-date, and defined as two years after A-date, based on the current pace of allocations - It is however possible to move T-date forward at the point where address consumpution exceeds the projections during the course of two years (*) new allocations/assignments from RIRs should terminate on T-date as a general rule. Allocations or assignments to "critical infrastructure" after T-date should be defined by a separate policy. Rationale: 1. Introduction The exhaustion of IPv4 address is approaching round the corner. Geoff Huston's latest projection at Potaroo (as of January 6, 2007) (http://www.potaroo.net/tools/ipv4/) draws the date of IANA pool exhaustion as 31st May 2011, and that of RIR pool as 14th July 2012. Tony Hain projects similar dates based on a different algorithm of his own. From these data, we may observe that if that the current allocation trend continues, the exhaustion of IPv4 address space is expected to take place as early as within the next five years. ICANN/IANA and RIRs must co-ordinate with stakeholders to achieve smooth termination of IPv4 address space as the Internet bodies responsible for stable management and distribution of IP number resources. This proposal provides some ideas as well as concrete examples of the policy that helps IPv4 allocations come to an end with "the minimum confusion" and in "as fair manner as possible". "Five years at the earliest" is not too far in the future for the exhaustion of IPv4 address space. Assuming the minimum of one year is required for sufficient policy discussions with this proposal as a start, and two years for preparation and transfer by LIRs, we need to start the discussions right at this time. 2. Summary of current problems Despite the fact that several projections are made on IPv4 address to run out as early as within the next few years, no discussions are taking place on any of the RIR's policy fora. (we have submitted the same proposal to APNIC on January 2007) This section lists possible problems if no policies are defined to prepare for the terminal period of allocations. 2-1. LIR LIRs currently do not consider IPv4 address exhaustion as an imminent issue in the first place. It is possible that they will finally realize the situation only when impacts of the exhaustion becomes visible as a practical matter, and lead to confusions such as re-addressing their network or making subsequent requests at the last minute in within a limited time frame. There could also be cases where allocations blocks cannot be allocated to some of the LIRs even though requests are submitted on the same day. Moreover, although it would be necessary for LIRs to announce to their customers that IPv4 address space will not be available for assignments eventually, it is difficult to plan this timing without clear policy for the last phase of allocations. As new IPv4 address allocations space will no longer be available, LIRs have no choice but to build networks based on IPv6. However, there are risks of trouble if preparations are made from that point in time, as it will lead to premature actions even if some time can be bought by re-addressing and subsequent allocations. Lastly, using up all available IPv4 address space will disable assignments to services inevitable for co-existence of IPv4 and IPv6 networks, such as the translator service between the two networks, which it may create situation where transfer to IPv6 network will not even be possible. 2-2. RIR/NIR It is likely that smooth allocations by RIRs/NIRs will be hindered by rush of inquiries during the terminal phase of allocations. 2-3. End users End users generally receive address assignments from ISPs accompanied with Internet connection service. If an ISP no longer has IPv4 address space available, nor unable to provide IPv6 service, end users will not be able to receive services from that ISP. Moreover, if the terminal date of allocations remains ambiguous, it may leave end users behind to prepare for IPv6 ready network. 3. Benefits There will be the following benefits by implementing the policy for IPv4 address exhaustion as proposed on this paper. 3-1. LIR LIRs will be able to consciously plan their addressing within their networks if the final date of allocations is clearly demonstrated. Keeping a certain amount of unallocated address blocks enables allocations/assignments for "critical infrastructure" after the termination of regular allocations, which will be explained later section in more details. 3-2. RIR/NIR Announcing the date of terminating allocations in advance and ensuring that all allocations before this date will be made according to the policy at the time enables RIRs/NIRs to make the last allocation without confusions and avoids causing feelings of unfairness among LIRs and end users. In addition, consistent policy applied to all RIRs removes bias towards certain region as well as inter-regional unfairness. The period which IPv6 support is completed becomes clear, therefore, RIRs/NIRs can prepare for this. 3-3. End user As this proposal enables LIRs to prepare for the terminal period of allocations in advance, it reduces the risk of delays/ suspensions of assignments from LIRs to enduers, and end users will be able to continuously receive services from LIRs. As in the case of LIRs, end users will be able to prepare for IPv6 support by the date of allocation termination is clarified. In addition, IPv6 connectivity as well as IPv4 address required during the allocation termination period will be smoothly secured by LIRs preparing for such period. As listed above, there will be important, notable benefits for stakeholders as a result of this policy. It is therefore necessary to take the following actions to achieve a smooth transfer to IPv6 and prevent causing instability in the Internet as well as; - start discussions on allocation scheme during the exhaustion period, - indicate a roadmap to exhaustion after raising awareness on the issue, and - allow enough time for LIRs to plan timing of addressing of their networks, submit allocation requests, and consider how to switch to IPv6. 4. Proposal principles As the first step to discuss IPv4 exhaustion planning, we would like to have an agreement(consensus) on the following four principles. -------------------------------------------------------------------- (1) Global synchronization: All five RIRs will proceed at the same time for measures on IPv4 address exhaustion. (2) Some Blocks to be left: Keep a few /8 stocks instead of distributing all. (3) Keeping current practices until the last moment : Maintain the current policy until the last allocation. (4) Separate discussions on "Recycle" issue : Recovery of unused address space should be discussed separately. -------------------------------------------------------------------- (1) Global synchronization: All RIRs must proceed at the same time to take measures for IPv4 address exhaustion. This is important not only for ensuring fairness for LIRs across the regions, but alsot to prevent confusions such as attempts to receive allocations from an RIR outside their region. The five RIRs should facilitate bottom-up discussions, which should be well coordinated under the leaderships of ICANN ASO and NRO. (2) Some blocks to be left: It is not practical to consider that IPv4 address blocks can be allocated to the last piece. It is expected to cause confusions if one party can receive an allocation while the other has to give up, just with a touch of a difference. The best solution to avoid such confusion is to set in advance, a date in which one is able to receive an allocation if requests are submitted before this timeline. Furthermore, there are few cases where allocations or assignments of IPv4 address space become absolutely necessary in the future. For example, requirements to start a translator service between IPv4 and IPv6 networks should be supported, and there may be some requirements in the future that are beyond our imagination at this current moment. As such, a date to stop allocations under the current policy should be set/defined so that certain number of IPv4 address blocks will be kept as stocks instead of allocating all blocks without remains. (3) Maintaining current practices until the last moment : Allocations should be made based on the current policy until the time to terminate allocations. As the IPv4 Internet has now developed into a social infrastructure supporting large number of businesses, making large changes in the current policy towards conservation within the next one or two years will lead to large-scale confusions, and difficult in the reality. (4) Separate discussion from "Recycle" issue Recovering unused allocated/assigned address blocks is an important measure, and in fact, it has already be discussed and implemented in each RIR regions. This issue, however should be considered separately from this proposal as recovery of a few /8 blocks extends the lifetime of IPv4 for less than one year while efforts for the recovery is expected to require substantial time. 5. Rationale for "A-date" & "T-date" A-date is set in order to: - Allow some grace period and period for networks to be IPv6 ready until the termination of allocations. - Prevent unfairness among LIRs by clarifying the date, such as not being able to receive allocations by a small difference in timing. The rationale for setting A-date as "when IANA pool becomes less than 30*/8" is as follows: The rate of allocations from IANA to RIRs after 2000 is as follows. 2000 : 4*/8 2001 : 6*/8 2002 : 4*/8 2003 : 5*/8 2004 : 9*/8 2005 : 13*/8 2006 : 10*/8 Approximately 10*/8 has been allocated annually after 2003, and the consumption is likely to accelerate with rise of the last minute demands. As it is better to keep minimum stocks of address pool at IANA, 30*/8 is set as the threshold value, and allocations should be terminated two years after it reaches the value, which ensures that IANA/RIRs secure the address space for allocations/assignments to critical infrastructure. 6. Effect on RIR members RIR members are expected to concretely grasp the termination date of allocations and take actions within their organization to prepare for the event. Timetable for implementation: Immediate after all 5 RIRs ratified this policy. From randy at psg.com Fri Apr 13 14:27:59 2007 From: randy at psg.com (Randy Bush) Date: Fri, 13 Apr 2007 08:27:59 -1000 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: <461FCA5B.90109@arin.net> References: <461FCA5B.90109@arin.net> Message-ID: <461FCBAF.2070504@psg.com> > 4. In the section "KEY USE IN COMMUNICATION", the proposal requires > validation of "a chain of trust not longer than five steps" between the > signing key and ARIN's hostmaster role key, without regard to whether > such intermediary signers are ARIN POCs, or are even known to ARIN. > Without direct binding of the PGP key to an ARIN POC record, such > anonymity in the chain of trust raises serious questions about how ARIN > staff will know and evaluate that an e-mail from a signer is > authentically from the ARIN POC that the sender claims to be. this is critical! > 5. A PGP-key for hostmaster at arin.net exists on pgp.mit.edu as well > as other well-known PGP-key repositories. This key was set up during > the early days of ARIN, and the passphrase for the key is, as of this > writing, MIA. This prevents ARIN from using the key to sign anything, > and furthermore prevents ARIN from removing the key from the key > repositories mentioned above. Although ARIN could proceed by generating > a new PGP-key, we would need to use a limited distribution mechanism > that excludes well-known servers, since more than one key for the same > e-mail address cannot exist in the key servers. i believe that last assertion to be incorrect randy From dlw+arin at tellme.com Fri Apr 13 14:46:12 2007 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 13 Apr 2007 11:46:12 -0700 Subject: [ppml] Policy Proposal 2007-6 - Staff Assessment In-Reply-To: <461FCA3D.2030400@arin.net> References: <461FCA3D.2030400@arin.net> Message-ID: <20070413184612.GM26157@shell01.corp.tellme.com> I'll second the comment that it's great to get these assessments in advance of the meeting. Thanks! I wanted to take a moment to respond to the staff comments on this one. Comments inline. On Fri, Apr 13, 2007 at 02:21:49PM -0400, Member Services wrote: > 1. There is very little qualification criteria which could lead to > policy abuse by spammers. These entities could create many different > accounts over time as their existing space gets blacklisted or becomes > otherwise unusable. Do spammers take the time to become multihomed and then apply for IP space? If they do, I'm sure they can find a way to qualify under the existing policy for a /22. I'm not sure I understand the actual risk here. It seems to me that this could already be a problem, actually. Perhaps a process to identify or report spammers would help this problem, but I'm not convinced that spammers actually try to get valid IP space from RIRs. Do we (staff and or community) have any data on this possibility? > 2. This could significantly increase the number of requests for > ARIN services thereby requiring additional Registration Services > Department and Financial Services Department staff. This is true. It is likely that a small multi-homed enterprise would apply for space under this policy rather than applying for space via an ISP. > 3. Policy applies only to end users which could be perceived as > unfair to ISPs. This could also lead to potential abuse of the policy > if ISPs apply as end users for single /24 IPv4 address block. I respectfully disagree with the first sentence entirely. Existing policy is heavily biased towards ISPs, and is rather unfair for smaller entities that have a critical business need to be multi-homed, but wish to avoid being semi-permanently attached to a single ISP due to the need for address space. Indeed, the current lack of fairness is part of the desire to change the policy. On the second point - I agree that this could be an issue. I suspect it could be an issue now...there's nothing to stop an ISP from applying for a /22 as an end user, outside of the risk of getting caught by staff. > 4. It is unclear exactly how an organization can qualify for a /24 > IPv4 address block under this policy. It appears that NRPM section > 4.3.3, Utilization rate, requires 25% immediate, 50% within 1 year, > would be the justification criteria. However, NRPM section 4.2.3.6, > Reassignments to multihomed downstream customers, indicates that an ISP > can reassign a /24 IPv4 address block without regard to planned host > counts as long as the customer is multi-homed. The question here is > does this policy allow ARIN to qualify a requestor for a /24 IPv4 > address block based solely on multi-homing or should host counts also be > taken into account? Existing policy, as written, refers to section 4.3.3. That doesn't change with the proposed policy. ISPs can feel free to reassign a PA /24 via whatever policy they choose, but direct (PI) assignments should still be under the guidelines listed in 4.3.3, regardless of the minimum assignment size. There is explicitly no change in that. > 5. The policy does not address requests for more than one /24 IPv4 > address block for multiple sites. My intention for this issue is that this is handled in the same way that multiple /22 requests are handled now. Is the request justified? There's no change in how this would be handled, outside of the differences in minimum assignement size. > 6. NRPM Section 4.4, Micro-allocation, should remain as is since it > is a policy section essential for micro-allocation for critical > infrastructure related requests. I'm happy to concede this point, and change the policy appropriately. I'd like more (as in any) community input on this point. To some extent, the IPv4 micro-allocation section is irrelevant if this policy is approved. On the other hand, it may be useful to explicitly call out the allocation policy for critical infrastructure. What that infrastructure is defined to be is an interesting question, but beyond the scope of the current proposal. More opinions solicted! Thanks again for the opportunity to get some of this discussed in advance of the meeting! -David From Ed.Lewis at neustar.biz Fri Apr 13 14:49:54 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 13 Apr 2007 14:49:54 -0400 Subject: [ppml] nro global policy was Re: 2007-12 - Staff Assessment In-Reply-To: <461FCA67.60702@arin.net> References: <461FCA67.60702@arin.net> Message-ID: At 14:22 -0400 4/13/07, Member Services wrote: > http://www.arin.net/policy/proposals/2007_12.html > > 3. Author did not indicate placement. Could be put in as new >section 4.9 of the NRPM Section 4.9. Also, that section would need a >heading, perhaps, "Availability of IPv4 Address Space". The staff comment is valid and I'm not questioning that. But here is the beginning of the global policy process instruction on the NRO website: #Any individual may submit a global proposal. Each RIR community must ratify an identical version #of the proposed policy. How "identical?" If the policies have to be forced into the NRPM in ARIN and whatever the equivalent is in another region, can any policy ever meet the requirement above? Sorry for an idle though here - this isn't a comment on the policy but is related to this being targeted as a global policy. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. -------------- next part -------------- An HTML attachment was scrubbed... URL: From plzak at arin.net Fri Apr 13 15:00:51 2007 From: plzak at arin.net (Ray Plzak) Date: Fri, 13 Apr 2007 15:00:51 -0400 Subject: [ppml] nro global policy was Re: 2007-12 - Staff Assessment In-Reply-To: References: <461FCA67.60702@arin.net> Message-ID: Ed, My understanding is that the authors do not intend for this to be a global policy which would require identical language in all regions (see NRPM Section 10), but rather that the policy be implemented globally. The latter allows for regional differences. What is not clear in that regard is where the authors are willing to accept regional differences. Ray From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Edward Lewis Sent: Friday, April 13, 2007 2:50 PM To: ppml at arin.net Cc: ed.lewis at neustar.biz Subject: [ppml] nro global policy was Re: 2007-12 - Staff Assessment At 14:22 -0400 4/13/07, Member Services wrote: > http://www.arin.net/policy/proposals/2007_12.html > > 3. Author did not indicate placement. Could be put in as new >section 4.9 of the NRPM Section 4.9. Also, that section would need a >heading, perhaps, "Availability of IPv4 Address Space". The staff comment is valid and I'm not questioning that. But here is the beginning of the global policy process instruction on the NRO website: #Any individual may submit a global proposal. Each RIR community must ratify an identical version #of the proposed policy. How "identical?" If the policies have to be forced into the NRPM in ARIN and whatever the equivalent is in another region, can any policy ever meet the requirement above? Sorry for an idle though here - this isn't a comment on the policy but is related to this being targeted as a global policy. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at lava.net Fri Apr 13 15:04:27 2007 From: tony at lava.net (Antonio Querubin) Date: Fri, 13 Apr 2007 09:04:27 -1000 (HST) Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: <461FCA5B.90109@arin.net> References: <461FCA5B.90109@arin.net> Message-ID: On Fri, 13 Apr 2007, Member Services wrote: > 5. A PGP-key for hostmaster at arin.net exists on pgp.mit.edu as well > as other well-known PGP-key repositories. This key was set up during > the early days of ARIN, and the passphrase for the key is, as of this > writing, MIA. This prevents ARIN from using the key to sign anything, > and furthermore prevents ARIN from removing the key from the key > repositories mentioned above. Although ARIN could proceed by generating Just how many PGP repositories is it found on? Why not just make a call to the operators of those repositories and having them manually remove the key? Antonio Querubin whois: AQ7-ARIN From michael.dillon at bt.com Fri Apr 13 15:12:21 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 13 Apr 2007 20:12:21 +0100 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: <461FCA5B.90109@arin.net> Message-ID: > 5. A PGP-key for hostmaster at arin.net exists on > pgp.mit.edu as well > as other well-known PGP-key repositories. This key was set up during > the early days of ARIN, and the passphrase for the key is, as of this > writing, MIA. This prevents ARIN from using the key to sign anything, > and furthermore prevents ARIN from removing the key from the key > repositories mentioned above. Although ARIN could proceed by > generating > a new PGP-key, we would need to use a limited distribution mechanism > that excludes well-known servers, since more than one key for the same > e-mail address cannot exist in the key servers. The solution to this is to retire the archaic and obscure term "hostmaster" in favor of something straighforward like "regsvcs at arin.net". Of course the old address could continue to receive email indefinitely, but it would no longer be mentioned in any current documents nor would it be used to send any email. > The difficulties introduced by changing > the well-known e-mail address of hostmaster at arin.net to some other > address makes such a change an unattractive option. I disagree on this point. As long as the old email address continues to accept email, it should not be hard to change the address, just somewhat tedious to find all occurences of it. People who intend to *CHANGE* their processes to use PGP, will have no difficulty in changing the email address that they use. > 6. Currently ARIN uses two e-mail addresses, > hostmaster at arin.net > and reassign at arin.net, to accept e-mail. The purpose for the > differentiation is primarily workflow-related: submissions to > hostmaster > are generally handled manually while submissions to reassign are > generally able to be handled by automated software. Not true. All mail to ARIN is handled by automated software known as a mail server. This software makes dispatching decisions based on message content. Why can't all email go to regsvcs at arin.net and then get dispatched, based on SUBJECT line (or template in message body)? Admittedly you would need to make some systems changes, but this is not a technically difficult thing to do. --Michael Dillon From michael.dillon at bt.com Fri Apr 13 15:17:23 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 13 Apr 2007 20:17:23 +0100 Subject: [ppml] Policy Proposal 2007-12 - Staff Assessment In-Reply-To: <461FCA67.60702@arin.net> Message-ID: > 11. If IPv4 is replaced by IPv6 then one could assume that > organizations would return their IPv4 back to ARIN and that > space would > be available for reallocation. However, this policy would effectively > preclude ARIN from reusing this returned space. There, in a nutshell, is the biggest problem with any policy like this. > but it proposes to do so in a way > that may inadvertently create profound legal issues that would > dramatically increase ARIN's potential legal liabilities. And there is the 2nd biggest problem. Both problems kill this policy proposal and any other similar types of proposals. --Michael Dillon From jmccuine at scsfinancial.com Fri Apr 13 15:14:11 2007 From: jmccuine at scsfinancial.com (McCuine, Joe) Date: Fri, 13 Apr 2007 15:14:11 -0400 Subject: [ppml] Policy Proposal 2007-12 - Staff Assessment Message-ID: <8CC8036432F76B47BAD6C6E4192C0C73F0743D@scsmail.scs.corp> How do I get myself off of this email trail............ ______________________________________ Joseph E. McCuine, CFA|COO SCS Financial Services LLC 610 Lincoln Street|Suite 200|Waltham MA 02451 781.290.4533|781.290.4411 Fax|508.439.9371 Mobile jmccuine at scsfinancial.com -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com Sent: Friday, April 13, 2007 3:17 PM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2007-12 - Staff Assessment > 11. If IPv4 is replaced by IPv6 then one could assume that > organizations would return their IPv4 back to ARIN and that > space would > be available for reallocation. However, this policy would effectively > preclude ARIN from reusing this returned space. There, in a nutshell, is the biggest problem with any policy like this. > but it proposes to do so in a way > that may inadvertently create profound legal issues that would > dramatically increase ARIN's potential legal liabilities. And there is the 2nd biggest problem. Both problems kill this policy proposal and any other similar types of proposals. --Michael Dillon _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From stephen at sprunk.org Fri Apr 13 18:01:02 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 13 Apr 2007 17:01:02 -0500 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment References: <461FCA5B.90109@arin.net> <461FCBAF.2070504@psg.com> Message-ID: <016c01c77e1b$ee8dddc0$3b3816ac@atlanta.polycom.com> Thus spake "Randy Bush" >> 4. In the section "KEY USE IN COMMUNICATION", the >> proposal requires validation of "a chain of trust not longer than >> five steps" between the signing key and ARIN's hostmaster >> role key, without regard to whether such intermediary signers >> are ARIN POCs, or are even known to ARIN. Without direct >> binding of the PGP key to an ARIN POC record, such >> anonymity in the chain of trust raises serious questions about >> how ARIN staff will know and evaluate that an e-mail from a >> signer is authentically from the ARIN POC that the sender >> claims to be. > > this is critical! I think folks are confusing authentication with authorization here (which is common). The number of steps through the web of trust indicates how much confidence one has when authenticating a sender. It has nothing to do with authorizing the sender to perform a given action. For instance, if bob at foo.com signs a key for john at bar.com, ARIN could legitimately consider mail from john at bar.com to be authentic if ARIN trusts bob at foo.com. Still, ARIN would only allow john at bar.com to update FooCorp's records if he was a POC for FooCorp. Or is my understanding of the proposal wrong? I doubt that, if someone at AT&T signs a key of someone at Verizon, the authors intended to let Verizon modify all of AT&T's resources... I happen to think five steps is excessive, and would like that revised lower, but by itself that's not enough reason for me to be against this proposal. Still, counsel's reasonable concerns about liability may require us to eliminate the chain of trust entirely. >> Although ARIN could proceed by generating a new PGP-key, >> we would need to use a limited distribution mechanism that >> excludes well-known servers, since more than one key for the >> same e-mail address cannot exist in the key servers. > > i believe that last assertion to be incorrect I know for a fact it's incorrect; the same thing happened to me years ago and the keyserver network now has several different keys for me (only one of which I still possess). Still, I'd expect that the keyserver operators would cooperate with removing ARIN's old key if contacted by non-electronic means. They might not (er, won't) do this for individuals, but ARIN does have standing in the community that warrants an exception... Also, it's possible to have multiple email addresses attached to the same key, allowing hostmaser@, reassign@, and any other role addresses to use the same key. However, non-role addresses should not be added since they effectively cannot be removed. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From randy at psg.com Fri Apr 13 18:45:25 2007 From: randy at psg.com (Randy Bush) Date: Fri, 13 Apr 2007 12:45:25 -1000 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: <016c01c77e1b$ee8dddc0$3b3816ac@atlanta.polycom.com> References: <461FCA5B.90109@arin.net> <461FCBAF.2070504@psg.com> <016c01c77e1b$ee8dddc0$3b3816ac@atlanta.polycom.com> Message-ID: <46200805.2090904@psg.com> >>> 4. In the section "KEY USE IN COMMUNICATION", the >>> proposal requires validation of "a chain of trust not longer than >>> five steps" between the signing key and ARIN's hostmaster >>> role key, without regard to whether such intermediary signers >>> are ARIN POCs, or are even known to ARIN. Without direct >>> binding of the PGP key to an ARIN POC record, such >>> anonymity in the chain of trust raises serious questions about >>> how ARIN staff will know and evaluate that an e-mail from a >>> signer is authentically from the ARIN POC that the sender >>> claims to be. >> >> this is critical! > > I think folks are confusing authentication with authorization here yes. when i give my public pgp key to arin, i am saying o you know it is i because i can sign things with the private key which matches this public key (authentication), and o our contract authorizes me to conduct certain classes of transactions with arin (authorization) if i sign joe's key wi the private key, this might give arin some warm fuzzies that joe is joe (or not). but what it does not do is say that joe is authorized to conduct any transactions with arin. transitive pgp has no way of expressing what authorization is being transferred. randy From lchiorazzi at glowpoint.com Fri Apr 13 18:47:22 2007 From: lchiorazzi at glowpoint.com (Lou Chiorazzi) Date: Fri, 13 Apr 2007 18:47:22 -0400 Subject: [ppml] PPML Digest, Vol 22, Issue 26 In-Reply-To: Message-ID: I've unsubscribed 5 times now. Please help. -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of ppml-request at arin.net Sent: Friday, April 13, 2007 6:46 PM To: ppml at arin.net Subject: PPML Digest, Vol 22, Issue 26 Send PPML mailing list submissions to ppml at arin.net To subscribe or unsubscribe via the World Wide Web, visit http://lists.arin.net/mailman/listinfo/ppml or, via email, send a message with subject or body 'help' to ppml-request at arin.net You can reach the person managing the list at ppml-owner at arin.net When replying, please edit your Subject line so it is more specific than "Re: Contents of PPML digest..." Today's Topics: 1. Re: nro global policy was Re: 2007-12 - Staff Assessment (Ray Plzak) 2. Re: Policy Proposal 2007-1 - Staff Assessment (Antonio Querubin) 3. Re: Policy Proposal 2007-1 - Staff Assessment (michael.dillon at bt.com) 4. Re: Policy Proposal 2007-12 - Staff Assessment (michael.dillon at bt.com) 5. Re: Policy Proposal 2007-12 - Staff Assessment (McCuine, Joe) 6. Re: Policy Proposal 2007-1 - Staff Assessment (Stephen Sprunk) 7. Re: Policy Proposal 2007-1 - Staff Assessment (Randy Bush) ---------------------------------------------------------------------- Message: 1 Date: Fri, 13 Apr 2007 15:00:51 -0400 From: Ray Plzak Subject: Re: [ppml] nro global policy was Re: 2007-12 - Staff Assessment To: Edward Lewis , "ppml at arin.net" Message-ID: Content-Type: text/plain; charset="us-ascii" Ed, My understanding is that the authors do not intend for this to be a global policy which would require identical language in all regions (see NRPM Section 10), but rather that the policy be implemented globally. The latter allows for regional differences. What is not clear in that regard is where the authors are willing to accept regional differences. Ray From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Edward Lewis Sent: Friday, April 13, 2007 2:50 PM To: ppml at arin.net Cc: ed.lewis at neustar.biz Subject: [ppml] nro global policy was Re: 2007-12 - Staff Assessment At 14:22 -0400 4/13/07, Member Services wrote: > http://www.arin.net/policy/proposals/2007_12.html > > 3. Author did not indicate placement. Could be put in as new >section 4.9 of the NRPM Section 4.9. Also, that section would need a >heading, perhaps, "Availability of IPv4 Address Space". The staff comment is valid and I'm not questioning that. But here is the beginning of the global policy process instruction on the NRO website: #Any individual may submit a global proposal. Each RIR community must ratify an identical version #of the proposed policy. How "identical?" If the policies have to be forced into the NRPM in ARIN and whatever the equivalent is in another region, can any policy ever meet the requirement above? Sorry for an idle though here - this isn't a comment on the policy but is related to this being targeted as a global policy. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.arin.net/pipermail/ppml/attachments/20070413/9f4c002b/attac hment-0001.html ------------------------------ Message: 2 Date: Fri, 13 Apr 2007 09:04:27 -1000 (HST) From: Antonio Querubin Subject: Re: [ppml] Policy Proposal 2007-1 - Staff Assessment To: Member Services Cc: ppml at arin.net Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Fri, 13 Apr 2007, Member Services wrote: > 5. A PGP-key for hostmaster at arin.net exists on pgp.mit.edu as well > as other well-known PGP-key repositories. This key was set up during > the early days of ARIN, and the passphrase for the key is, as of this > writing, MIA. This prevents ARIN from using the key to sign anything, > and furthermore prevents ARIN from removing the key from the key > repositories mentioned above. Although ARIN could proceed by generating Just how many PGP repositories is it found on? Why not just make a call to the operators of those repositories and having them manually remove the key? Antonio Querubin whois: AQ7-ARIN ------------------------------ Message: 3 Date: Fri, 13 Apr 2007 20:12:21 +0100 From: Subject: Re: [ppml] Policy Proposal 2007-1 - Staff Assessment To: Message-ID: Content-Type: text/plain; charset="US-ASCII" > 5. A PGP-key for hostmaster at arin.net exists on > pgp.mit.edu as well > as other well-known PGP-key repositories. This key was set up during > the early days of ARIN, and the passphrase for the key is, as of this > writing, MIA. This prevents ARIN from using the key to sign anything, > and furthermore prevents ARIN from removing the key from the key > repositories mentioned above. Although ARIN could proceed by > generating > a new PGP-key, we would need to use a limited distribution mechanism > that excludes well-known servers, since more than one key for the same > e-mail address cannot exist in the key servers. The solution to this is to retire the archaic and obscure term "hostmaster" in favor of something straighforward like "regsvcs at arin.net". Of course the old address could continue to receive email indefinitely, but it would no longer be mentioned in any current documents nor would it be used to send any email. > The difficulties introduced by changing > the well-known e-mail address of hostmaster at arin.net to some other > address makes such a change an unattractive option. I disagree on this point. As long as the old email address continues to accept email, it should not be hard to change the address, just somewhat tedious to find all occurences of it. People who intend to *CHANGE* their processes to use PGP, will have no difficulty in changing the email address that they use. > 6. Currently ARIN uses two e-mail addresses, > hostmaster at arin.net > and reassign at arin.net, to accept e-mail. The purpose for the > differentiation is primarily workflow-related: submissions to > hostmaster > are generally handled manually while submissions to reassign are > generally able to be handled by automated software. Not true. All mail to ARIN is handled by automated software known as a mail server. This software makes dispatching decisions based on message content. Why can't all email go to regsvcs at arin.net and then get dispatched, based on SUBJECT line (or template in message body)? Admittedly you would need to make some systems changes, but this is not a technically difficult thing to do. --Michael Dillon ------------------------------ Message: 4 Date: Fri, 13 Apr 2007 20:17:23 +0100 From: Subject: Re: [ppml] Policy Proposal 2007-12 - Staff Assessment To: Message-ID: Content-Type: text/plain; charset="US-ASCII" > 11. If IPv4 is replaced by IPv6 then one could assume that > organizations would return their IPv4 back to ARIN and that > space would > be available for reallocation. However, this policy would effectively > preclude ARIN from reusing this returned space. There, in a nutshell, is the biggest problem with any policy like this. > but it proposes to do so in a way > that may inadvertently create profound legal issues that would > dramatically increase ARIN's potential legal liabilities. And there is the 2nd biggest problem. Both problems kill this policy proposal and any other similar types of proposals. --Michael Dillon ------------------------------ Message: 5 Date: Fri, 13 Apr 2007 15:14:11 -0400 From: "McCuine, Joe" Subject: Re: [ppml] Policy Proposal 2007-12 - Staff Assessment To: Message-ID: <8CC8036432F76B47BAD6C6E4192C0C73F0743D at scsmail.scs.corp> Content-Type: text/plain; charset="us-ascii" How do I get myself off of this email trail............ ______________________________________ Joseph E. McCuine, CFA|COO SCS Financial Services LLC 610 Lincoln Street|Suite 200|Waltham MA 02451 781.290.4533|781.290.4411 Fax|508.439.9371 Mobile jmccuine at scsfinancial.com -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com Sent: Friday, April 13, 2007 3:17 PM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2007-12 - Staff Assessment > 11. If IPv4 is replaced by IPv6 then one could assume that > organizations would return their IPv4 back to ARIN and that > space would > be available for reallocation. However, this policy would effectively > preclude ARIN from reusing this returned space. There, in a nutshell, is the biggest problem with any policy like this. > but it proposes to do so in a way > that may inadvertently create profound legal issues that would > dramatically increase ARIN's potential legal liabilities. And there is the 2nd biggest problem. Both problems kill this policy proposal and any other similar types of proposals. --Michael Dillon _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml ------------------------------ Message: 6 Date: Fri, 13 Apr 2007 17:01:02 -0500 From: "Stephen Sprunk" Subject: Re: [ppml] Policy Proposal 2007-1 - Staff Assessment To: "Randy Bush" , "Member Services" Cc: ARIN PPML Message-ID: <016c01c77e1b$ee8dddc0$3b3816ac at atlanta.polycom.com> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Thus spake "Randy Bush" >> 4. In the section "KEY USE IN COMMUNICATION", the >> proposal requires validation of "a chain of trust not longer than >> five steps" between the signing key and ARIN's hostmaster >> role key, without regard to whether such intermediary signers >> are ARIN POCs, or are even known to ARIN. Without direct >> binding of the PGP key to an ARIN POC record, such >> anonymity in the chain of trust raises serious questions about >> how ARIN staff will know and evaluate that an e-mail from a >> signer is authentically from the ARIN POC that the sender >> claims to be. > > this is critical! I think folks are confusing authentication with authorization here (which is common). The number of steps through the web of trust indicates how much confidence one has when authenticating a sender. It has nothing to do with authorizing the sender to perform a given action. For instance, if bob at foo.com signs a key for john at bar.com, ARIN could legitimately consider mail from john at bar.com to be authentic if ARIN trusts bob at foo.com. Still, ARIN would only allow john at bar.com to update FooCorp's records if he was a POC for FooCorp. Or is my understanding of the proposal wrong? I doubt that, if someone at AT&T signs a key of someone at Verizon, the authors intended to let Verizon modify all of AT&T's resources... I happen to think five steps is excessive, and would like that revised lower, but by itself that's not enough reason for me to be against this proposal. Still, counsel's reasonable concerns about liability may require us to eliminate the chain of trust entirely. >> Although ARIN could proceed by generating a new PGP-key, >> we would need to use a limited distribution mechanism that >> excludes well-known servers, since more than one key for the >> same e-mail address cannot exist in the key servers. > > i believe that last assertion to be incorrect I know for a fact it's incorrect; the same thing happened to me years ago and the keyserver network now has several different keys for me (only one of which I still possess). Still, I'd expect that the keyserver operators would cooperate with removing ARIN's old key if contacted by non-electronic means. They might not (er, won't) do this for individuals, but ARIN does have standing in the community that warrants an exception... Also, it's possible to have multiple email addresses attached to the same key, allowing hostmaser@, reassign@, and any other role addresses to use the same key. However, non-role addresses should not be added since they effectively cannot be removed. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ------------------------------ Message: 7 Date: Fri, 13 Apr 2007 12:45:25 -1000 From: Randy Bush Subject: Re: [ppml] Policy Proposal 2007-1 - Staff Assessment To: Stephen Sprunk Cc: ARIN PPML Message-ID: <46200805.2090904 at psg.com> Content-Type: text/plain; charset=ISO-8859-1 >>> 4. In the section "KEY USE IN COMMUNICATION", the >>> proposal requires validation of "a chain of trust not longer than >>> five steps" between the signing key and ARIN's hostmaster >>> role key, without regard to whether such intermediary signers >>> are ARIN POCs, or are even known to ARIN. Without direct >>> binding of the PGP key to an ARIN POC record, such >>> anonymity in the chain of trust raises serious questions about >>> how ARIN staff will know and evaluate that an e-mail from a >>> signer is authentically from the ARIN POC that the sender >>> claims to be. >> >> this is critical! > > I think folks are confusing authentication with authorization here yes. when i give my public pgp key to arin, i am saying o you know it is i because i can sign things with the private key which matches this public key (authentication), and o our contract authorizes me to conduct certain classes of transactions with arin (authorization) if i sign joe's key wi the private key, this might give arin some warm fuzzies that joe is joe (or not). but what it does not do is say that joe is authorized to conduct any transactions with arin. transitive pgp has no way of expressing what authorization is being transferred. randy ------------------------------ _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml End of PPML Digest, Vol 22, Issue 26 ************************************ From william at elan.net Fri Apr 13 22:00:22 2007 From: william at elan.net (william(at)elan.net) Date: Fri, 13 Apr 2007 19:00:22 -0700 (PDT) Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: <016c01c77e1b$ee8dddc0$3b3816ac@atlanta.polycom.com> References: <461FCA5B.90109@arin.net> <461FCBAF.2070504@psg.com> <016c01c77e1b$ee8dddc0$3b3816ac@atlanta.polycom.com> Message-ID: On Fri, 13 Apr 2007, Stephen Sprunk wrote: > Still, I'd expect that the keyserver operators would cooperate with removing > ARIN's old key if contacted by non-electronic means. They might not (er, > won't) do this for individuals, but ARIN does have standing in the community > that warrants an exception... Perhaps it would be good if somebody at ARIN privately check on if this is possible and report it at at the meeting and list if this can happen or not. This could be crucial for some people in deciding about this proposal. -- William Leibzon Elan Networks william at elan.net From woody at pch.net Sat Apr 14 01:16:04 2007 From: woody at pch.net (Bill Woodcock) Date: Fri, 13 Apr 2007 22:16:04 -0700 (PDT) Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: References: <461FCA5B.90109@arin.net> Message-ID: On Fri, 13 Apr 2007, Antonio Querubin wrote: > Just how many PGP repositories is it found on? Why not just make a call > to the operators of those repositories and having them manually remove the > key? That's what people tell me the standard procedure in cases like this is. -Bill From woody at pch.net Sat Apr 14 01:28:50 2007 From: woody at pch.net (Bill Woodcock) Date: Fri, 13 Apr 2007 22:28:50 -0700 (PDT) Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: <016c01c77e1b$ee8dddc0$3b3816ac@atlanta.polycom.com> References: <461FCA5B.90109@arin.net> <461FCBAF.2070504@psg.com> <016c01c77e1b$ee8dddc0$3b3816ac@atlanta.polycom.com> Message-ID: On Fri, 13 Apr 2007, Stephen Sprunk wrote: > If bob at foo.com signs a key for john at bar.com, ARIN could > legitimately consider mail from john at bar.com to be authentic if ARIN trusts > bob at foo.com. Still, ARIN would only allow john at bar.com to update FooCorp's > records if he was a POC for FooCorp. Yes, that is correct. The proposal neither says nor intends anything more than that. > I happen to think five steps is excessive, and would like that revised > lower, but by itself that's not enough reason for me to be against this > proposal. None of us have any stake in the number. As I said before, I think all of us would be just as happy with 2 as 5. 1 is too short, and 6 is definitely too long. But somewhere between 2 and 5 would seem to be a reasonable window. > Counsel's reasonable concerns about liability may require > us to eliminate the chain of trust entirely. With all due respect to my colleague Mr. Ryan, the alternative is mail-from. I think that needs to be kept in mind, when one speaks of relative liability. > I know for a fact it's incorrect; the same thing happened to me years ago > and the keyserver network now has several different keys for me (only one of > which I still possess). > > Still, I'd expect that the keyserver operators would cooperate with removing > ARIN's old key if contacted by non-electronic means. Yes, I believe both of these to be true, and pertinent. -Bill From woody at pch.net Sat Apr 14 01:32:07 2007 From: woody at pch.net (Bill Woodcock) Date: Fri, 13 Apr 2007 22:32:07 -0700 (PDT) Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: <46200805.2090904@psg.com> References: <461FCA5B.90109@arin.net> <461FCBAF.2070504@psg.com> <016c01c77e1b$ee8dddc0$3b3816ac@atlanta.polycom.com> <46200805.2090904@psg.com> Message-ID: On Fri, 13 Apr 2007, Randy Bush wrote: > transitive pgp has no way of expressing what authorization is being > transferred. Correct. No authorization is transferred. Authorization is a matter of ARIN hostmaster decisions about POCs. PGP and X.509 are simply ways of authenticating the sender as one of the POCs. If a POC wishes to _transfer_ or modify authorization, there are existing practices and procedures in place whereby the hostmaster and the POC make that change. This policy in no way modifies or impacts those existing processes. -Bill From randy at psg.com Sat Apr 14 01:33:36 2007 From: randy at psg.com (Randy Bush) Date: Fri, 13 Apr 2007 19:33:36 -1000 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: References: <461FCA5B.90109@arin.net> Message-ID: <462067B0.6000304@psg.com> >> Just how many PGP repositories is it found on? Why not just make a call >> to the operators of those repositories and having them manually remove the >> key? > That's what people tell me the standard procedure in cases like this is. bzzzt! there is no procedure to remove. period. if you get a pgp key and upload to repositories, keep the revoke or you may some day regret it. randy From randy at psg.com Sat Apr 14 01:37:30 2007 From: randy at psg.com (Randy Bush) Date: Fri, 13 Apr 2007 19:37:30 -1000 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: References: <461FCA5B.90109@arin.net> <461FCBAF.2070504@psg.com> <016c01c77e1b$ee8dddc0$3b3816ac@atlanta.polycom.com> <46200805.2090904@psg.com> Message-ID: <4620689A.2070801@psg.com> Bill Woodcock wrote: > On Fri, 13 Apr 2007, Randy Bush wrote: >> transitive pgp has no way of expressing what authorization is being >> transferred. > Correct. No authorization is transferred. Authorization is a matter of > ARIN hostmaster decisions about POCs. PGP and X.509 are simply ways of > authenticating the sender as one of the POCs. If a POC wishes to > _transfer_ or modify authorization, there are existing practices and > procedures in place whereby the hostmaster and the POC make that change. > This policy in no way modifies or impacts those existing processes. bingo. the procedure must be that all keys used to authorize transactions must be registered with arin and tied to the contract, period. under no circumstances should arin trust a message signed by a key not registered with arin through some business process. and the keys that are registered to act could be completely disjoint in signature chains. the pgp web of trust is and must be completely irrelevant. randy From fergdawg at netzero.net Sat Apr 14 01:49:46 2007 From: fergdawg at netzero.net (Fergie) Date: Sat, 14 Apr 2007 05:49:46 GMT Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment Message-ID: <20070413.225021.4392.2791240@webmail38.lax.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Randy Bush wrote: >Bill Woodcock wrote: >> On Fri, 13 Apr 2007, Randy Bush wrote: >>> transitive pgp has no way of expressing what authorization is being >>> transferred. >> Correct. No authorization is transferred. Authorization is a matter of >> ARIN hostmaster decisions about POCs. PGP and X.509 are simply ways of >> authenticating the sender as one of the POCs. If a POC wishes to >> _transfer_ or modify authorization, there are existing practices and >> procedures in place whereby the hostmaster and the POC make that change. >> This policy in no way modifies or impacts those existing processes. > >bingo. the procedure must be that all keys used to authorize >transactions must be registered with arin and tied to the contract, >period. > >under no circumstances should arin trust a message signed by a key not >registered with arin through some business process. > >and the keys that are registered to act could be completely disjoint in >signature chains. the pgp web of trust is and must be completely >irrelevant. Sorry for jumping into the middle of the discussion, but just a question in response to something Bill said w.r.t. x.509 -- this is an issue that continues to crop up on several fronts, yet there seems to be no real x.509 solution in sight. Granted: I understand that this is why the discussion is lending itself in the favor of PGP (which I highly endorse, by the way), but the whole x.509 seems to nothing more than a barrier these day, c'est nes pas? Just trying to separate reality from... pipe dream here. Thanks, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.0 (Build 214) wj8DBQFGIGs6q1pz9mNUZTMRAi+NAJ4mmhxzOisC4KERyq7keDKET67+FACgnCul WQOgq7BH/DG9Xj56ayOqalA= =xoCR -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ From randy at psg.com Sat Apr 14 01:59:49 2007 From: randy at psg.com (Randy Bush) Date: Fri, 13 Apr 2007 19:59:49 -1000 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: <20070413.225021.4392.2791240@webmail38.lax.untd.com> References: <20070413.225021.4392.2791240@webmail38.lax.untd.com> Message-ID: <46206DD5.6010503@psg.com> > Sorry for jumping into the middle of the discussion, but just a > question in response to something Bill said w.r.t. x.509 -- this > is an issue that continues to crop up on several fronts, yet there > seems to be no real x.509 solution in sight. not exactly. to quote russ housley from a different room where related issues are being discussed > There are two mechanisms in X.509 that might be useful: > > Cert Policy - Here an OID says that the certificate was issued in > accordance with a particular policy, and then the application makes > sure that the certification path is valid under that policy. > > EKU - Here an OID is carried in the extended key usage extension to > indicate the applications that the certificate was intended to support. these are not magic panacae. but they are a path that might be trod. randy From fergdawg at netzero.net Sat Apr 14 02:12:17 2007 From: fergdawg at netzero.net (Fergie) Date: Sat, 14 Apr 2007 06:12:17 GMT Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment Message-ID: <20070413.231232.4392.2791283@webmail38.lax.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Randy Bush wrote: >> Sorry for jumping into the middle of the discussion, but just a >> question in response to something Bill said w.r.t. x.509 -- this >> is an issue that continues to crop up on several fronts, yet there >> seems to be no real x.509 solution in sight. > >not exactly. to quote russ housley from a different room where related >issues are being discussed > >> There are two mechanisms in X.509 that might be useful: >> >> Cert Policy - Here an OID says that the certificate was issued in >> accordance with a particular policy, and then the application makes >> sure that the certification path is valid under that policy. >> >> EKU - Here an OID is carried in the extended key usage extension to >> indicate the applications that the certificate was intended to support. > >these are not magic panacae. but they are a path that might be trod. > Well, that's all well and good, in a manner of speaking. What would be _better_ is a convergence of a sane cert policy and a reasonable PKIX infrastructure -- many other things could work from this (e.g. IRR policy frobs, DNSSEC, SIDR, and even SAVA), but I'm aware this is not the right forum for those discussions. My point is this: an effort should be made to use an extensible certificate/certification/validation architecture which can also be extended for other technical mechanisms in the plumbing. If you go down the path of least resistance (a la PGP), then you've pretty much cornered yourselves into a semi- non-extensible mechanism that is pretty much "limited" w.r.t. how it could be used in a larger scheme. Would you agree? Or does it really matter. I'm just thinking out loud here... Thanks, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.0 (Build 214) wj8DBQFGIHCeq1pz9mNUZTMRAmEMAJ4weAjOpBf9v2/0fcz5xJdlqofhrwCeKvG8 TTAKIieYiXaAp8KRNraA5+w= =gNqa -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ From randy at psg.com Sat Apr 14 02:17:01 2007 From: randy at psg.com (Randy Bush) Date: Fri, 13 Apr 2007 20:17:01 -1000 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: <20070413.231232.4392.2791283@webmail38.lax.untd.com> References: <20070413.231232.4392.2791283@webmail38.lax.untd.com> Message-ID: <462071DD.1040904@psg.com> my take is the pgp proposal is catch-up with something that should have been in place for a long time. as the current proposal is not passable in current form, you could try adding x.509 to it and filling in the rather humorous > 12.3 X.509 > This section intentionally left blank. randy From fergdawg at netzero.net Sat Apr 14 02:20:54 2007 From: fergdawg at netzero.net (Fergie) Date: Sat, 14 Apr 2007 06:20:54 GMT Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment Message-ID: <20070413.232134.4392.2791304@webmail38.lax.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Randy Bush wrote: >my take is the pgp proposal is catch-up with something that should have >been in place for a long time. > >as the current proposal is not passable in current form, you could try >adding x.509 to it and filling in the rather humorous > >> 12.3 X.509 >> This section intentionally left blank. > Point well taken. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.0 (Build 214) wj8DBQFGIHLCq1pz9mNUZTMRAtepAJ9/8m2nAIbnd56iYTUG/kcG23Sr0ACg7Q55 VvYLjXfzmxOFedWcg5EfM9s= =b99v -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ From woody at pch.net Sat Apr 14 02:24:35 2007 From: woody at pch.net (Bill Woodcock) Date: Fri, 13 Apr 2007 23:24:35 -0700 (PDT) Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: <462067B0.6000304@psg.com> References: <461FCA5B.90109@arin.net> <462067B0.6000304@psg.com> Message-ID: > there is no procedure to remove. Correct. I'm told that in such exceptional cases, it has been done in the absence of procedure. That's what makes them exceptional. -Bill From woody at pch.net Sat Apr 14 02:26:37 2007 From: woody at pch.net (Bill Woodcock) Date: Fri, 13 Apr 2007 23:26:37 -0700 (PDT) Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: <4620689A.2070801@psg.com> References: <461FCA5B.90109@arin.net> <461FCBAF.2070504@psg.com> <016c01c77e1b$ee8dddc0$3b3816ac@atlanta.polycom.com> <46200805.2090904@psg.com> <4620689A.2070801@psg.com> Message-ID: > The pgp web of trust is and must be completely irrelevant. Perhaps you'd like to make an alternate proposal, then? This one is about PGP, not X.509. PGP authentication procedures are well-established, and this proposal does not seek to change them. -Bill From randy at psg.com Sat Apr 14 02:28:45 2007 From: randy at psg.com (Randy Bush) Date: Fri, 13 Apr 2007 20:28:45 -1000 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: References: <461FCA5B.90109@arin.net> <461FCBAF.2070504@psg.com> <016c01c77e1b$ee8dddc0$3b3816ac@atlanta.polycom.com> <46200805.2090904@psg.com> <4620689A.2070801@psg.com> Message-ID: <4620749D.6090904@psg.com> >> The pgp web of trust is and must be completely irrelevant. > Perhaps you'd like to make an alternate proposal, then? This one is about > PGP, not X.509. PGP authentication procedures are well-established, and > this proposal does not seek to change them. perhaps you should go back and read the parts of my message you elided randy From woody at pch.net Sat Apr 14 02:31:33 2007 From: woody at pch.net (Bill Woodcock) Date: Fri, 13 Apr 2007 23:31:33 -0700 (PDT) Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: <4620749D.6090904@psg.com> References: <461FCA5B.90109@arin.net> <461FCBAF.2070504@psg.com> <016c01c77e1b$ee8dddc0$3b3816ac@atlanta.polycom.com> <46200805.2090904@psg.com> <4620689A.2070801@psg.com> <4620749D.6090904@psg.com> Message-ID: On Fri, 13 Apr 2007, Randy Bush wrote: > perhaps you should go back and read the parts of my message you elided In which you suggested a distance of 1, rather than, say, somewhere between 2 and 5. Yes, if that were to be done, it would make PGP just as useless as X.509, thereby making X.509 not look quite so bad by comparison. What of it? -Bill From randy at psg.com Sat Apr 14 02:33:10 2007 From: randy at psg.com (Randy Bush) Date: Fri, 13 Apr 2007 20:33:10 -1000 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: References: <461FCA5B.90109@arin.net> <461FCBAF.2070504@psg.com> <016c01c77e1b$ee8dddc0$3b3816ac@atlanta.polycom.com> <46200805.2090904@psg.com> <4620689A.2070801@psg.com> <4620749D.6090904@psg.com> Message-ID: <462075A6.5060600@psg.com> > In which you suggested a distance of 1, rather than, say, somewhere > between 2 and 5. Yes, if that were to be done, it would make PGP just as > useless as X.509, thereby making X.509 not look quite so bad by > comparison. What of it? can we change channels to one with more neurons? From michael.dillon at bt.com Sun Apr 15 18:11:05 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 15 Apr 2007 23:11:05 +0100 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: <20070413.231232.4392.2791283@webmail38.lax.untd.com> Message-ID: > What would be _better_ is a convergence of a sane cert policy and > a reasonable PKIX infrastructure -- many other things could work > from this (e.g. IRR policy frobs, DNSSEC, SIDR, and even SAVA), but > I'm aware this is not the right forum for those discussions. > > My point is this: an effort should be made to use an extensible > certificate/certification/validation architecture which can also > be extended for other technical mechanisms in the plumbing. > > If you go down the path of least resistance (a la PGP), then you've > pretty much cornered yourselves into a semi- non-extensible mechanism > that is pretty much "limited" w.r.t. how it could be used in a > larger scheme. I would think ARIN should be looking into Simple PKI http://world.std.com/~cme/html/spki.html rather than the full-blown PKI infrastructure stuff. But ultimately it depends on what the users want, and that ultimately depends on what tools they use. If someone produced a SWIP/Rwhois management tool that could talk to a variety of database backends and then built your Rwhois db (or submitted required SWIPs), and if it was widely adopted, then the crypto/auth stuff used by such a tool is what ARIN would implement. But currently, there is a real mish-mash of homegrown systems and/or commercial systems, that have the archaic ARIN SWIP protocol baked into them somewhere. Even PGP may not be that easy for folks to adopt without painful system surgery. --Michael Dillon From michael.dillon at bt.com Sun Apr 15 18:11:12 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 15 Apr 2007 23:11:12 +0100 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: Message-ID: > Perhaps it would be good if somebody at ARIN privately check on if > this is possible and report it at at the meeting and list if this > can happen or not. This could be crucial for some people in deciding > about this proposal. This implies that it is crucial for some people that ARIN continues to use the address hostmaster at arin.net and does not switch to using some other email address. If this is so I would like to hear why the obsolete antiquated term "hostmaster" is so important? --Michael Dillon From michael.dillon at bt.com Sun Apr 15 18:20:29 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 15 Apr 2007 23:20:29 +0100 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: Message-ID: > In which you suggested a distance of 1, rather than, say, somewhere > between 2 and 5. Yes, if that were to be done, it would make > PGP just as > useless as X.509, thereby making X.509 not look quite so bad by > comparison. What of it? If I understand this argument correctly, it centers on how many steps in the chain should be allowed when deciding to accept a PGP key as authentication of the person submitting some type of transaction. If, one assumed that BOTH authentication and authorization were established by a valid key, then ARIN should not accept more than 1 step, namely, only keys signed by ARIN's key would be acceptable. However, if one does not make that assumption, and assumes that authorization is established out-of-band through some other business process (letter, phone call, etc.) then more steps in the chain are acceptable and Bill's policy language is fine as it is. The purpose for a limit of 5 steps is just to keep things reasonably under control. The PGP key will only be used to authenticate transactions as originating from a certain individual who is already in ARIN's db as an authorized individual. The authorization then happens once per indivudual, and the authentication happens on every single transaction. Therefore, there really is no argument between Bill and Randy, just a misunderstanding of assumptions. --Michael Dillon From woody at pch.net Sun Apr 15 22:36:24 2007 From: woody at pch.net (Bill Woodcock) Date: Sun, 15 Apr 2007 19:36:24 -0700 (PDT) Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: References: Message-ID: > This implies that it is crucial for some people that ARIN continues to > use the address hostmaster at arin.net and does not switch to using some > other email address. If this is so I would like to hear why the obsolete > antiquated term "hostmaster" is so important? This is not considered to be of any import by the proposal, and is in no way a requirement or a consideration of the proposal. It's an implementation detail, which staff can choose to address. -Bill From woody at pch.net Sun Apr 15 22:41:31 2007 From: woody at pch.net (Bill Woodcock) Date: Sun, 15 Apr 2007 19:41:31 -0700 (PDT) Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: References: Message-ID: On Sun, 15 Apr 2007 michael.dillon at bt.com wrote: > If I understand this argument correctly, it centers on how many steps in > the chain should be allowed when deciding to accept a PGP key as > authentication of the person submitting some type of transaction. Correct. > If authorization is established out-of-band through some other > business process (letter, phone call, etc.)... ...which it is, using the current process, which this proposal in no way seeks to change... > ...then more steps in the chain are acceptable and Bill's policy > language is fine as it is. The purpose for a limit of 5 steps is > just to keep things reasonably under control. The PGP key will only > be used to authenticate transactions as originating from a certain > individual who is already in ARIN's db as an authorized individual. Correct. > The authorization then happens once per indivudual, and the > authentication happens on every single transaction. Correct. > Therefore, there really is no argument between Bill and Randy, just > a misunderstanding of assumptions. Ah, would that all parties took that to heart; then we would live in a better world indeed. -Bill From martin.hannigan at batelnet.bs Mon Apr 16 01:07:16 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Mon, 16 Apr 2007 01:07:16 -0400 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment Message-ID: <46230484.202.52f8.11633@batelnet.bs> ----- Original Message ----- From: Bill Woodcock To: Randy Bush Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2007-1 - Staff Assessment Date: Fri, 13 Apr 2007 23:24:35 -0700 (PDT) > > there is no procedure to remove. > > Correct. I'm told that in such exceptional cases, it has > been done in the absence of procedure. That's what makes > them exceptional. Let us know which ones remove the key so we won't trust them. -M< From martin.hannigan at batelnet.bs Mon Apr 16 01:19:28 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Mon, 16 Apr 2007 01:19:28 -0400 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment Message-ID: <46230760.7a.531b.13922@batelnet.bs> > > Perhaps it would be good if somebody at ARIN privately > > check on if this is possible and report it at at the > > meeting and list if this can happen or not. This could > > be crucial for some people in deciding about this > proposal. > > This implies that it is crucial for some people that ARIN > continues to use the address hostmaster at arin.net and does > not switch to using some other email address. If this is > so I would like to hear why the obsolete antiquated term > "hostmaster" is so important? Hostmaster implies DNS sysadmin. I'm not sure how, or if, there is any relevance to ARIN to specifically utilize hostmaster, to be honest. I don't think so. I wouldn't be horrified if an address other than hostmaster for offiical communications. It would seem kind of odd, but only from the historical perspective. I do have a problem with having a key removed from public key servers through undocumented back channels. I'm not an expert in keyserver ops, but being able to make a call and get a key "fixed" seems to be an extremely bad idea. I'd appreciate some detail as to why this doesn't undermine the web of trust around pgp keys on public servers and how it's ok since I don't quite understand how it could be based on my existing knowledge. -M< From stephen at sprunk.org Mon Apr 16 01:17:32 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 16 Apr 2007 00:17:32 -0500 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment References: <46230760.7a.531b.13922@batelnet.bs> Message-ID: <036001c77fe6$9c730de0$6401a8c0@atlanta.polycom.com> Thus spake "Martin Hannigan" > I do have a problem with having a key removed from public > key servers through undocumented back channels. I'm not an > expert in keyserver ops, but being able to make a call and get > a key "fixed" seems to be an extremely bad idea. I'd > appreciate some detail as to why this doesn't undermine the > web of trust around pgp keys on public servers and how it's ok > since I don't quite understand how it could be based on my > existing knowledge. It's not getting a key "fixed"; it's getting a useless key removed. Ideally, it wouldn't be needed, and in practice it may not be, but it's confusing at best. Some folks would try to use the old key instead of the new one, and they wouldn't be able to communicate with ARIN securely on the first attempt. Keyservers aren't part of the PGP security model in the first place; their existence or reliability has no effect on the web of trust. Keys could randomly disappear all the time and nobody would really care, except that it'd be a minor annoyance when trying to contact someone new. The trust model is based on what signatures are present and who they're done by once one finds the key, not where one gets the key from. Of course, who exactly is going to be signing ARIN's key and why? Standard usage indicates folks who want to send PGP mail to ARIN would do so in their own keyrings, after verifying it was authentic by OOB means, but who would the original key on the keyservers be signed by (at first, or ever)? S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From info at arin.net Mon Apr 16 08:51:33 2007 From: info at arin.net (Member Services) Date: Mon, 16 Apr 2007 08:51:33 -0400 Subject: [ppml] Policy Proposal 2006-7 - Staff Assessment Message-ID: <46237155.8030404@arin.net> Policy Proposal 2006-7 Changes to IPv6 initial allocation criteria ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2006-7 is available as Annex A below and at: http://www.arin.net/policy/proposals/2006_7.html II. Understanding of the proposal ARIN staff understands this proposal would add to the list of criteria for an initial allocation of IPv6 address space (NRPM section 6.5.1.1.). Specifically, in addition to the common criteria, if an ISP is not known, nor can it provide a plan, it can instead attempt to justify intent to announce the address space within one year. III. Issues and concerns A. ARIN staff 1. ARIN staff is concerned about confusion that may occur if the text is inserted as the author indicated (letter "d" already has an "or"). ARIN staff has suggested alternative placement; see Annex B below. 2. How can staff verify that an organization is new to providing "Internet services"? 3. What happens at the end of 1 year if the v6 block is not announced? 4. What if the IPv6 address space is used on a ?private network? and can?t be seen from the public Internet? B. ARIN General Counsel This policy as proposed poses no significant legal risks for ARIN. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2006-7 Changes to IPv6 initial allocation criteria Proposal type: Insert a new additional line item e. to 6.5.1.1 of NRPM Policy term: permanent Policy statement: New organizations need a policy that allows them to apply for IPv6 address space. To provide this we need to insert a new additional line item to 6.5.1.1. The new line item would be line 'e' as follows: e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPv6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Rationale: - New organizations who do not want to use IPv4 at all and start off using IPv6 addresses only, need a policy that gives them permission to do so. This is also valid for existing companies that may or may not have assigned IPv4 addresses and now want to start offering IPv6 services. These organizations may also wish to request IPv4 at the same time. - One year is given as the sufficient time frame to actually implement usage of the IPv6 address space and reveal if the 'said organization' is truly using the IPv6 space granted. -Every means of documentation that can reveal 'true intent of use' is not listed as this can be a very long list and should be left to the discretion of the RIR staff. -An ISP or LIR may decide to assign a different prefix size than /48. For example, a cellular operator may use /64. -ASN is not required because as long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. - Organization in this is defined as a Corporation, ISP, LLC et al. In SUMMARY if this policy is implemented the change to the NRPM would read as follows: 6.5.1.1 Initial allocation criteria To qualify for an initial allocation of IPV6 address space, an organization must: a be a LIR; b. not be an end site; c. plan to provide IPV6 connectivity to which it will assign IPV6 address space, by advertising that connectivity through its single aggregated address allocation; d. be an existing, known ISP in the ARIN region or have a plan for making at least 200/48 assignments to other organizations within five years. e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPV6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Timetable for implementation: Immediate ##*## Annex B ARIN staff suggested format for the insertion of the policy text 6.5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: a. be an LIR; b. not be an end site; c. plan to provide IPv6 connectivity to organizations to which it will assign IPv6 address space, by advertising that connectivity through its single aggregated address allocation; and d. meet at least one of the following: 1. be an existing, known ISP in the ARIN region. 2. have a plan for making at least 200 /48 assignments to other organizations within five years. 3. be an organization new to providing internet services that can justify intent to announce the requested IPv6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. From kkargel at polartel.com Mon Apr 16 10:22:52 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 16 Apr 2007 09:22:52 -0500 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: <016c01c77e1b$ee8dddc0$3b3816ac@atlanta.polycom.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066706E28@mail> If it is just authentication we are worrying about why are we talking about limiting it to one method? I like the idea of having access to a method such as 'smtp from' as a fallback. If you want to make that stricter you could enforce SPF requirements on the SMTP for that to work. I am not sure about the SPF as that would place requirements on the email provider that may be beyond the end users control. The pgp (or other certificate method) would be simpler for the user once implemented, and would probably be the method of choice, but there are times that I am caught away from my normal resources and need to do "stuff" , where alternate methods come in handy. I do much like the Thawte Web of Trust (WoT) personal email signatures, which are easily implemented in current email clients (like the microsoft variants) and allow authenticated/encrypted email without needing to add a plugin or run a separate program. These signatures are also available for free. The biggest probem I see with using them is that they are not USA based and the US centric folks will go zenophobic. Kevin $s/worry/happy,g > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Stephen Sprunk > Sent: Friday, April 13, 2007 5:01 PM > To: Randy Bush; Member Services > Cc: ARIN PPML > Subject: Re: [ppml] Policy Proposal 2007-1 - Staff Assessment > > Thus spake "Randy Bush" > >> 4. In the section "KEY USE IN COMMUNICATION", the proposal > >> requires validation of "a chain of trust not longer than > five steps" > >> between the signing key and ARIN's hostmaster role key, without > >> regard to whether such intermediary signers are ARIN POCs, or are > >> even known to ARIN. Without direct binding of the PGP key > to an ARIN > >> POC record, such anonymity in the chain of trust raises serious > >> questions about how ARIN staff will know and evaluate that > an e-mail > >> from a signer is authentically from the ARIN POC that the sender > >> claims to be. > > > > this is critical! > > I think folks are confusing authentication with authorization > here (which is common). The number of steps through the web > of trust indicates how much confidence one has when > authenticating a sender. It has nothing to do with > authorizing the sender to perform a given action. > > For instance, if bob at foo.com signs a key for john at bar.com, > ARIN could legitimately consider mail from john at bar.com to be > authentic if ARIN trusts bob at foo.com. Still, ARIN would only > allow john at bar.com to update FooCorp's records if he was a > POC for FooCorp. Or is my understanding of the proposal > wrong? I doubt that, if someone at AT&T signs a key of > someone at Verizon, the authors intended to let Verizon > modify all of AT&T's resources... > > I happen to think five steps is excessive, and would like > that revised lower, but by itself that's not enough reason > for me to be against this proposal. Still, counsel's > reasonable concerns about liability may require us to > eliminate the chain of trust entirely. > > >> Although ARIN could proceed by generating a new PGP-key, we would > >> need to use a limited distribution mechanism that excludes > well-known > >> servers, since more than one key for the same e-mail > address cannot > >> exist in the key servers. > > > > i believe that last assertion to be incorrect > > I know for a fact it's incorrect; the same thing happened to > me years ago and the keyserver network now has several > different keys for me (only one of which I still possess). > > Still, I'd expect that the keyserver operators would > cooperate with removing ARIN's old key if contacted by > non-electronic means. They might not (er, > won't) do this for individuals, but ARIN does have standing > in the community that warrants an exception... > > Also, it's possible to have multiple email addresses attached > to the same key, allowing hostmaser@, reassign@, and any > other role addresses to use the same key. However, non-role > addresses should not be added since they effectively cannot > be removed. > > S > > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov > > > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From michael.dillon at bt.com Mon Apr 16 10:48:22 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 16 Apr 2007 15:48:22 +0100 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066706E28@mail> Message-ID: > The pgp (or other certificate method) would be simpler for > the user once > implemented, and would probably be the method of choice, but there are > times that I am caught away from my normal resources and need to do > "stuff" , where alternate methods come in handy. I have found that the phone works well in such sitiuations. After all, we're not trying to produce a razzle-dazzle crypto authentication show here, just implement good business practices. > I do much like the Thawte Web of Trust (WoT) personal email > signatures, > which are easily implemented in current email clients (like the > microsoft variants) and allow authenticated/encrypted email without > needing to add a plugin or run a separate program. The Thawte web pages don't give much info on how this works and they require you to sign up before you can read their "free" guide. No thank you. This is likely some web-based system and if we are going to go down that route, it is better to use an SSL web server with a RESTful API. --Michael Dillon From woody at pch.net Mon Apr 16 10:56:02 2007 From: woody at pch.net (Bill Woodcock) Date: Mon, 16 Apr 2007 07:56:02 -0700 (PDT) Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066706E28@mail> References: <70DE64CEFD6E9A4EB7FAF3A063141066706E28@mail> Message-ID: On Mon, 16 Apr 2007, Kevin Kargel wrote: > If it is just authentication why are we talking > about limiting it to one method? To the best of my knowledge, no one is. This proposal documents three methods: mail-from, PGP, and X.509. > I like the idea of having access to a > method such as 'smtp from' as a fallback. I think many people do. Moreover, there's an enormous legacy base of people who may never (or may not for a very long time) change to any cryptographic authentication method. -Bill From kkargel at polartel.com Mon Apr 16 11:18:24 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 16 Apr 2007 10:18:24 -0500 Subject: [ppml] Policy Proposal 2007-1 - Staff Assessment In-Reply-To: Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066706E2B@mail> Actually the way the Thawte WoT system works is that it allows web signup for creation of the key files, but requires a physical meeting and examination of paper credentials (drivers license, passport, etc) for "notarization" of the key. I like the multi-level (casual/official) method where you can choose whther or not to trust the casual certs. Off topic so that's all the time I'll take. Kevin $s/worry/happy,g > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of michael.dillon at bt.com > Sent: Monday, April 16, 2007 9:48 AM > To: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2007-1 - Staff Assessment > > > The pgp (or other certificate method) would be simpler for the user > > once implemented, and would probably be the method of choice, but > > there are times that I am caught away from my normal resources and > > need to do "stuff" , where alternate methods come in handy. > > I have found that the phone works well in such sitiuations. > After all, we're not trying to produce a razzle-dazzle crypto > authentication show here, just implement good business practices. > > > I do much like the Thawte Web of Trust (WoT) personal email > > signatures, which are easily implemented in current email clients > > (like the microsoft variants) and allow > authenticated/encrypted email > > without needing to add a plugin or run a separate program. > > The Thawte web pages don't give much info on how this works > and they require you to sign up before you can read their > "free" guide. No thank you. This is likely some web-based > system and if we are going to go down that route, it is > better to use an SSL web server with a RESTful API. > > --Michael Dillon > > > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From schiller at uu.net Mon Apr 16 17:34:45 2007 From: schiller at uu.net (Jason Schiller) Date: Mon, 16 Apr 2007 17:34:45 -0400 (EDT) Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4 AddressCountdown In-Reply-To: <2271C950731A734680BA3E2978816F1809C7B97E@NJCHLEXCMB01.cable.comcast.com> Message-ID: Dan, I want to disagree with you on one point... > The problem with a size restriction is that is doesn't change demand. It > will only cause ISP to submit more applications, more often with the end > result being the same. If you use a million IP for your customers in a > year, the only difference between two applications in that year or a > dozen, is the amount of administrative work that is done to process the > apps. > > -Dan There is another problem, the "end result" is not actually the same. While the ISP may end up utilizing the the same amount of space in both schemes, how it is used internally will be very different. When the address space is given out in large blocks, the ISP can divide up these blocks into reasonably sized pools for each of its internal regions. This allows for internal aggregation. If instead smaller blocks are given out more frequently, then the regional pools will be much smaller. Each subsequent block will be diviided into regional pools that will not be contiguous with the previous regional pool. This stacking of regional pools will lead to poor internal aggregation, and thus bloat in the routing and forwarding tables. __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Fri, 13 Apr 2007, Alexander, Daniel wrote: > Date: Fri, 13 Apr 2007 14:05:19 -0400 > From: "Alexander, Daniel" > To: Iljitsch van Beijnum > Cc: ppml at arin.net > Subject: Re: [ppml] Summary of Trial Balloons for Dealing with IPv4 > AddressCountdown > > Iljitsch, > > Sorry for the late response, but I am having a hard time keeping up with > this mailing list. I just wanted to clarify a point you made below about > one of the allocations. Comcast actaully received that address space in > three installments over an 18 month period. The first was in April of > 05, with the last piece of the /8 being allocated in 12/06. All ISP, > regardless of size, are still bound by the timeframe policies in every > RIR. The size of any ISP's request can only be for what they can > justifiably use within a certain timeframe. For the ARIN region it is > currently six months. So while we ended up with the whole /8, we were > only given it because we actaully put it to use over a now, two year > time frame. > > The problem with a size restriction is that is doesn't change demand. It > will only cause ISP to submit more applications, more often with the end > result being the same. If you use a million IP for your customers in a > year, the only difference between two applications in that year or a > dozen, is the amount of administrative work that is done to process the > apps. > > -Dan > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Iljitsch van Beijnum > Sent: Tuesday, April 03, 2007 2:22 PM > To: Jim Weyand > Cc: ppml at arin.net > Subject: Re: [ppml] Summary of Trial Balloons for Dealing with IPv4 > AddressCountdown > > On 30-mrt-2007, at 23:34, Jim Weyand wrote: > > > I find myself struggling with how to convert the suggestions and > > comments on this list into actual policy proposals. > > Perhaps it would be a good idea to see if we can agree on what our goals > and assumptions are. An important question is whether it's a good idea > to try and postpone the moment when the RIRs have to turn down requests > for lack of free address space. Assuming we still have around five > years, and that a great deal can be accomplished in that time, is it > worth going through a lot of trouble to buy us a limited number of > additional years? > > > 4) Several similar informal proposals to encourage recycling by > > empowering ARIN to more actively police the use of IPv4 addresses by > > various means > > 6) An informal proposal to ask holders of unused address IPv4 > > addresses to voluntarily return the addresses > > A "use it or lose it" policy would make sense. Large amounts of address > space aren't visible on the global internet, so either people aren't > using it at all, or they're only using it internally. If we set a > deadline by which address space must be "in use" (hard to > define) or it will be put at the end of the free list, this gives people > who are using it for internal purposes a reasonable amount of time to > move to something else. > > > 7) Several variants of informal proposals to start assigning > > IPv6 > > space with IPv4 > > 8) An informal proposal to get endusers to demand access to IPv6 > > networks by creating a media storm similar to Y2K. > > The depletion of IPv4 and the adoption of IPv6 are largely orthogonal in > the short term. Having IPv6 doesn't mean you don't need IPv4 any more, > not having IPv4 doesn't make IPv6 more useful. > > This is what I suggest: > > In my opinion, it's a problem that the RIRs are giving out extremely > large blocks of address space to the world's largest ISPs. For instance, > Softbank has a /8, Comcast got a /8 in two installments and French, > Deutsche and British Telecom all have multi-million sized blocks. Even > very large ISPs need some time to put these amounts of address space to > use, so what happens is that at various intervals, new large blocks are > requested, so the number of addresses given out in any particular year > varies widely because one request can be as much as 5 to 10 % of the > yearly world-wide use. So giving out large blocks makes making > predictions harder. Another problem is that if and when business stalls, > a good part of a large block will go unused. For both of these reasons, > it's a good idea to limit the maximum block size that is given out > *today*. > > When we start to run out of address space for real, this only gets > worse, and we run the risk that a large request clears out the remaining > address space in one go. To avoid this, we should adopt a policy where > there is a maximum block size, and a minimum interval between obtaining > address blocks. As the number of addresses left gets smaller, the > maximum block size is reduced. > > For instance, we could make the maximum block size 2 million and the > minimum interval 2 months. So if an ISP thinks they need 16 million > addresses in a year, they'll have request 2 million, wait 2 months, > request another 2 million and so on. > > In 3 or 4 years, the limit could be half a million, so someone needing > 16 million addresses would only be able to get 6 x 1/2 million = 3 > million. (Note that people who need smaller blocks still get what they > need.) The effect is that an ISP who signs up 16 million new users each > year will then have to share an IPv4 address over several users, where > the number of users per address increases every year, rather than that > in year X every user can get their own address and in year Y there's > nothing left. > > The maximum block size could each year be set to (for instance) the next > higher CIDR boundary of 0.1% of the remaining IPv4 address space. > > This policy has the important property of being predictable so people > can plan rolling out new technologies to deal with the IPv4 address > shortage in ways that fit their business. > > A problem would be that this works per-organization, so it favors > smaller organizations over larger ones. > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From ipgoddess at gmail.com Mon Apr 16 18:39:06 2007 From: ipgoddess at gmail.com (Stacy Taylor) Date: Mon, 16 Apr 2007 15:39:06 -0700 Subject: [ppml] Policy Proposal 2007-6 - Staff Assessment In-Reply-To: <20070413184612.GM26157@shell01.corp.tellme.com> References: <461FCA3D.2030400@arin.net> <20070413184612.GM26157@shell01.corp.tellme.com> Message-ID: <1c16a4870704161539gdaad609j177b7c767256539d@mail.gmail.com> Hello PPML, I oppose this policy. First, I believe there is no better way to chew through the remainder of the v4 space faster than to pass this policy. Second, I support staff comments about spammers using this policy for abuse of networks. In my experience, miscreants of this sort prefer multiple /24s for their 'businesses' to force spam hunters to play whack a mole with the blacklisting of space. A _former_ customer of mine had more than 30 different business names, all with different points of contact and physical addresses. Because we were the upstream, we were notified of his violations of our AUP. If the only contact were the miscreant himself, he would not have been held accountable. Spammers would adore directly assigned space for this very reason. For the good of the Internet, this policy must not be passed. Stacy On 4/13/07, David Williamson wrote: > I'll second the comment that it's great to get these assessments in > advance of the meeting. Thanks! > > I wanted to take a moment to respond to the staff comments on this > one. Comments inline. > > On Fri, Apr 13, 2007 at 02:21:49PM -0400, Member Services wrote: > > 1. There is very little qualification criteria which could lead to > > policy abuse by spammers. These entities could create many different > > accounts over time as their existing space gets blacklisted or becomes > > otherwise unusable. > > Do spammers take the time to become multihomed and then apply for IP > space? If they do, I'm sure they can find a way to qualify under the > existing policy for a /22. I'm not sure I understand the actual risk > here. It seems to me that this could already be a problem, actually. > Perhaps a process to identify or report spammers would help this > problem, but I'm not convinced that spammers actually try to get valid > IP space from RIRs. Do we (staff and or community) have any data on > this possibility? > > > 2. This could significantly increase the number of requests for > > ARIN services thereby requiring additional Registration Services > > Department and Financial Services Department staff. > > This is true. It is likely that a small multi-homed enterprise would apply > for space under this policy rather than applying for space via an ISP. > > > 3. Policy applies only to end users which could be perceived as > > unfair to ISPs. This could also lead to potential abuse of the policy > > if ISPs apply as end users for single /24 IPv4 address block. > > I respectfully disagree with the first sentence entirely. Existing > policy is heavily biased towards ISPs, and is rather unfair for smaller > entities that have a critical business need to be multi-homed, but wish > to avoid being semi-permanently attached to a single ISP due to the > need for address space. Indeed, the current lack of fairness is part of > the desire to change the policy. > > On the second point - I agree that this could be an issue. I suspect > it could be an issue now...there's nothing to stop an ISP from applying > for a /22 as an end user, outside of the risk of getting caught by staff. > > > 4. It is unclear exactly how an organization can qualify for a /24 > > IPv4 address block under this policy. It appears that NRPM section > > 4.3.3, Utilization rate, requires 25% immediate, 50% within 1 year, > > would be the justification criteria. However, NRPM section 4.2.3.6, > > Reassignments to multihomed downstream customers, indicates that an ISP > > can reassign a /24 IPv4 address block without regard to planned host > > counts as long as the customer is multi-homed. The question here is > > does this policy allow ARIN to qualify a requestor for a /24 IPv4 > > address block based solely on multi-homing or should host counts also be > > taken into account? > > Existing policy, as written, refers to section 4.3.3. That doesn't > change with the proposed policy. ISPs can feel free to reassign a PA > /24 via whatever policy they choose, but direct (PI) assignments should > still be under the guidelines listed in 4.3.3, regardless of the > minimum assignment size. There is explicitly no change in that. > > > 5. The policy does not address requests for more than one /24 IPv4 > > address block for multiple sites. > > My intention for this issue is that this is handled in the same way > that multiple /22 requests are handled now. Is the request justified? > There's no change in how this would be handled, outside of the > differences in minimum assignement size. > > > 6. NRPM Section 4.4, Micro-allocation, should remain as is since it > > is a policy section essential for micro-allocation for critical > > infrastructure related requests. > > I'm happy to concede this point, and change the policy appropriately. > I'd like more (as in any) community input on this point. To some > extent, the IPv4 micro-allocation section is irrelevant if this policy > is approved. On the other hand, it may be useful to explicitly call > out the allocation policy for critical infrastructure. What that > infrastructure is defined to be is an interesting question, but beyond > the scope of the current proposal. More opinions solicted! > > > Thanks again for the opportunity to get some of this discussed in > advance of the meeting! > > -David > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > -- :):) /S From Daniel_Alexander at Cable.Comcast.com Wed Apr 18 09:10:37 2007 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Wed, 18 Apr 2007 09:10:37 -0400 Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4 AddressCountdown In-Reply-To: References: <2271C950731A734680BA3E2978816F1809C7B97E@NJCHLEXCMB01.cable.comcast.com> Message-ID: <2271C950731A734680BA3E2978816F1809D60D03@NJCHLEXCMB01.cable.comcast.com> I completely agree with your point. If my memory is correct, it is also why 2003-13 was adopted, increasing the allocations from three to six month projections. It's interesting though that the ARIN region is the only one that allocates for six month projections, while all the other RIR's make one and two year allocations. Maybe there is a proposal in there for the fall meeting. -----Original Message----- From: Jason Schiller [mailto:schiller at uu.net] Sent: Monday, April 16, 2007 5:35 PM To: Alexander, Daniel Cc: Iljitsch van Beijnum; ppml at arin.net Subject: Re: [ppml] Summary of Trial Balloons for Dealing with IPv4 AddressCountdown Dan, I want to disagree with you on one point... > The problem with a size restriction is that is doesn't change demand. > It will only cause ISP to submit more applications, more often with > the end result being the same. If you use a million IP for your > customers in a year, the only difference between two applications in > that year or a dozen, is the amount of administrative work that is > done to process the apps. > > -Dan There is another problem, the "end result" is not actually the same. While the ISP may end up utilizing the the same amount of space in both schemes, how it is used internally will be very different. When the address space is given out in large blocks, the ISP can divide up these blocks into reasonably sized pools for each of its internal regions. This allows for internal aggregation. If instead smaller blocks are given out more frequently, then the regional pools will be much smaller. Each subsequent block will be diviided into regional pools that will not be contiguous with the previous regional pool. This stacking of regional pools will lead to poor internal aggregation, and thus bloat in the routing and forwarding tables. __Jason ======================================================================== == Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Fri, 13 Apr 2007, Alexander, Daniel wrote: > Date: Fri, 13 Apr 2007 14:05:19 -0400 > From: "Alexander, Daniel" > To: Iljitsch van Beijnum > Cc: ppml at arin.net > Subject: Re: [ppml] Summary of Trial Balloons for Dealing with IPv4 > AddressCountdown > > Iljitsch, > > Sorry for the late response, but I am having a hard time keeping up > with this mailing list. I just wanted to clarify a point you made > below about one of the allocations. Comcast actaully received that > address space in three installments over an 18 month period. The first > was in April of 05, with the last piece of the /8 being allocated in > 12/06. All ISP, regardless of size, are still bound by the timeframe > policies in every RIR. The size of any ISP's request can only be for > what they can justifiably use within a certain timeframe. For the ARIN > region it is currently six months. So while we ended up with the whole > /8, we were only given it because we actaully put it to use over a > now, two year time frame. > > The problem with a size restriction is that is doesn't change demand. > It will only cause ISP to submit more applications, more often with > the end result being the same. If you use a million IP for your > customers in a year, the only difference between two applications in > that year or a dozen, is the amount of administrative work that is > done to process the apps. > > -Dan > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf > Of Iljitsch van Beijnum > Sent: Tuesday, April 03, 2007 2:22 PM > To: Jim Weyand > Cc: ppml at arin.net > Subject: Re: [ppml] Summary of Trial Balloons for Dealing with IPv4 > AddressCountdown > > On 30-mrt-2007, at 23:34, Jim Weyand wrote: > > > I find myself struggling with how to convert the suggestions and > > comments on this list into actual policy proposals. > > Perhaps it would be a good idea to see if we can agree on what our > goals and assumptions are. An important question is whether it's a > good idea to try and postpone the moment when the RIRs have to turn > down requests for lack of free address space. Assuming we still have > around five years, and that a great deal can be accomplished in that > time, is it worth going through a lot of trouble to buy us a limited > number of additional years? > > > 4) Several similar informal proposals to encourage recycling by > > empowering ARIN to more actively police the use of IPv4 addresses by > > various means > > 6) An informal proposal to ask holders of unused address IPv4 > > addresses to voluntarily return the addresses > > A "use it or lose it" policy would make sense. Large amounts of > address space aren't visible on the global internet, so either people > aren't using it at all, or they're only using it internally. If we set > a deadline by which address space must be "in use" (hard to > define) or it will be put at the end of the free list, this gives > people who are using it for internal purposes a reasonable amount of > time to move to something else. > > > 7) Several variants of informal proposals to start assigning > > IPv6 > > space with IPv4 > > 8) An informal proposal to get endusers to demand access to IPv6 > > networks by creating a media storm similar to Y2K. > > The depletion of IPv4 and the adoption of IPv6 are largely orthogonal > in the short term. Having IPv6 doesn't mean you don't need IPv4 any > more, not having IPv4 doesn't make IPv6 more useful. > > This is what I suggest: > > In my opinion, it's a problem that the RIRs are giving out extremely > large blocks of address space to the world's largest ISPs. For > instance, Softbank has a /8, Comcast got a /8 in two installments and > French, Deutsche and British Telecom all have multi-million sized > blocks. Even very large ISPs need some time to put these amounts of > address space to use, so what happens is that at various intervals, > new large blocks are requested, so the number of addresses given out > in any particular year varies widely because one request can be as > much as 5 to 10 % of the yearly world-wide use. So giving out large > blocks makes making predictions harder. Another problem is that if and > when business stalls, a good part of a large block will go unused. For > both of these reasons, it's a good idea to limit the maximum block > size that is given out *today*. > > When we start to run out of address space for real, this only gets > worse, and we run the risk that a large request clears out the > remaining address space in one go. To avoid this, we should adopt a > policy where there is a maximum block size, and a minimum interval > between obtaining address blocks. As the number of addresses left gets > smaller, the maximum block size is reduced. > > For instance, we could make the maximum block size 2 million and the > minimum interval 2 months. So if an ISP thinks they need 16 million > addresses in a year, they'll have request 2 million, wait 2 months, > request another 2 million and so on. > > In 3 or 4 years, the limit could be half a million, so someone needing > 16 million addresses would only be able to get 6 x 1/2 million = 3 > million. (Note that people who need smaller blocks still get what they > need.) The effect is that an ISP who signs up 16 million new users > each year will then have to share an IPv4 address over several users, > where the number of users per address increases every year, rather > than that in year X every user can get their own address and in year Y > there's nothing left. > > The maximum block size could each year be set to (for instance) the > next higher CIDR boundary of 0.1% of the remaining IPv4 address space. > > This policy has the important property of being predictable so people > can plan rolling out new technologies to deal with the IPv4 address > shortage in ways that fit their business. > > A problem would be that this works per-organization, so it favors > smaller organizations over larger ones. > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From stephen at sprunk.org Thu Apr 19 15:23:10 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 19 Apr 2007 14:23:10 -0500 Subject: [ppml] IPv6 Workshops? References: <10793F3BC5C33C489C69893C14242C0905FA56B4@jupiter.chi.msusa> <02a501c76cd5$74ede4d0$413816ac@atlanta.polycom.com> Message-ID: <02b801c782b9$4cb1a660$443816ac@atlanta.polycom.com> Thus spake "Stephen Sprunk" > Thus spake >> Is there anyone at all reaching out to the enterprise network >> operator community, to tell them about IPv6 and to give them >> some hands-on experience with it? Perhaps that would help >> speed adoption of v6. > > I've submitted an official suggestion via the ACSP that ARIN > start community outreach efforts. I didn't mention hands-on > events, but that's a good thought to add if ARIN acts on the > suggestion (and they might not, or the members might reject it > if consulted, due to the high cost of reaching and influencing > people who aren't already involved in the discussion). As promised, here's the response: > This is in response to suggestion 2007.10 submitted 22 March > 2007. > > Education is a strong component of ARIN's mission and as > such we are actively engaged in education activities to explain > IPv6 protocol. We are especially interested to get the word out > about how to request IPv6 address space from ARIN. We have > sponsored IPv6 related tutorials and workshops at our > meetings, included general IPv6 articles in our newsletter, > and ARIN staff participate in IPv6 forums and conferences > throughout the region. We will continue to undertake these > types of efforts and strengthen our communications to include > statistics. > > While education about ARIN services and our mission is > appropriate, the promotion of any specific technology is not > within our charter. We do welcome any specific > recommendations of forums where we should participate > or topics you would like to see us cover on our website or > in public presentations. Such ideas should be sent to > info at arin.net. > > Thank you for participating in the ARIN Consultation and Suggestion > process. Suggestion 2007.10 is now considered closed. I do find this a bit disappointing, but I understand the rationale: it's not ARIN's job to tell people they need to use IPv6. This is probably true. Unfortunately, it doesn't seem to be anyone else's job either. ARIN, NANOG, and other groups are limiting their education to people who are already involved in those groups and have asked for it. This, to me, does not qualify as "outreach"; it's preaching to the choir. I got a similar response to a proposal that ARIN suggest requesting an IPv6 allocation/assignment when processing IPv4 requests: > This is in response to suggestion 2007.11 submitted 22 March > 2007. > > While ARIN is certainly interested in seeing the growth of IPv6 > across the Internet, it is not ARIN's place to promote IPv6, or any > other specific technology, to our customers. What ARIN can do > however, is continue to educate and inform the community > about IPv6 through participation in activities and events such > as workshops, tutorials, conferences, and publications. > > Noting that ARIN will continue to take the above noted > actions, suggestion 2007.11 is now closed. Same complaints from my end as above, and the same admission that ARIN is probably correct to have this position. *sigh* S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From stephen at sprunk.org Thu Apr 19 15:23:20 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 19 Apr 2007 14:23:20 -0500 Subject: [ppml] those pesky users... References: <029901c770ca$50b7b570$463816ac@atlanta.polycom.com> Message-ID: <02b901c782b9$4cdc86f0$443816ac@atlanta.polycom.com> Thus "Stephen Sprunk" > If a significant number of IPv6-only networks appear, which has not > happened yet, the waiver could be modified or not extended. For > instance, I doubt many would object to changing the waiver such > that members only have to pay either their IPv4 fees or their IPv6 > fees, whichever is greater. I did submit a suggestion to this effect, and it appears to have been received better than my other two about IPv6: > This is in response to suggestion 2007.13 submitted 6 April 2007. > > The ARIN Board of Trustees will soon begin an examination of > all aspects of ARIN fees. Your suggestion will be thrown into the > mix of scenarios to discuss. The outcome of these Board > deliberations will likely be a member consultation on fee options. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From dlw+arin at tellme.com Thu Apr 19 15:49:06 2007 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 19 Apr 2007 12:49:06 -0700 Subject: [ppml] Policy Proposal 2007-6 - Staff Assessment In-Reply-To: <1c16a4870704161539gdaad609j177b7c767256539d@mail.gmail.com> References: <461FCA3D.2030400@arin.net> <20070413184612.GM26157@shell01.corp.tellme.com> <1c16a4870704161539gdaad609j177b7c767256539d@mail.gmail.com> Message-ID: <20070419194906.GN2053@shell01.corp.tellme.com> I wanted to allow some time to see if this started any further discussion. Regrettably, it did not. I think your first point is inaccurate. Similar policies already exist in several of the other RIRs, and that hasn't led a run on space. Additionally, organizations that need IP space will get it one way or another. This policy simply provides another method for them. Indeed, ARIN's requirements are more strenuous than most provider's, so some organizations that need a multi-homed /24 may still go for PA space. Here's the key point: this only changes the minimum allocation size - all of the other requirements (multi-homing, utilization, et.c) still stand. On your second point...I'm not in the anti-spam community, so I don't have any real data on how much of a threat this is. Perhaps someone from another RIR could chime in on this, since APNIC, for example, already hands out PI /24s. Has there been any sort of known abuse involving spammers? Like I said, I'm not in the anti-spam community enough to know, but it seems unlikely that spammers would take the time to meet the utilization and multi-homing requirements and then turn around and make that space mostly unusuable. (Lather, rinse, repeat.) It just doesn't seem to me like a profitable business method. As I have mentioned before, additional information from someone with actual data on this point would be great. The general apparent lack of data actually gives me some confidence that this isn't as big of a threat as it may seem. Thanks for the feedback and the opinion! -David On Mon, Apr 16, 2007 at 03:39:06PM -0700, Stacy Taylor wrote: > Hello PPML, > I oppose this policy. > First, I believe there is no better way to chew through the remainder > of the v4 space faster than to pass this policy. > Second, I support staff comments about spammers using this policy for > abuse of networks. In my experience, miscreants of this sort prefer > multiple /24s for their 'businesses' to force spam hunters to play > whack a mole with the blacklisting of space. A _former_ customer of > mine had more than 30 different business names, all with different > points of contact and physical addresses. Because we were the > upstream, we were notified of his violations of our AUP. If the only > contact were the miscreant himself, he would not have been held > accountable. Spammers would adore directly assigned space for this > very reason. > For the good of the Internet, this policy must not be passed. > Stacy > > On 4/13/07, David Williamson wrote: > > I'll second the comment that it's great to get these assessments in > > advance of the meeting. Thanks! > > > > I wanted to take a moment to respond to the staff comments on this > > one. Comments inline. > > > > On Fri, Apr 13, 2007 at 02:21:49PM -0400, Member Services wrote: > > > 1. There is very little qualification criteria which could lead to > > > policy abuse by spammers. These entities could create many different > > > accounts over time as their existing space gets blacklisted or becomes > > > otherwise unusable. > > > > Do spammers take the time to become multihomed and then apply for IP > > space? If they do, I'm sure they can find a way to qualify under the > > existing policy for a /22. I'm not sure I understand the actual risk > > here. It seems to me that this could already be a problem, actually. > > Perhaps a process to identify or report spammers would help this > > problem, but I'm not convinced that spammers actually try to get valid > > IP space from RIRs. Do we (staff and or community) have any data on > > this possibility? > > > > > 2. This could significantly increase the number of requests for > > > ARIN services thereby requiring additional Registration Services > > > Department and Financial Services Department staff. > > > > This is true. It is likely that a small multi-homed enterprise would apply > > for space under this policy rather than applying for space via an ISP. > > > > > 3. Policy applies only to end users which could be perceived as > > > unfair to ISPs. This could also lead to potential abuse of the policy > > > if ISPs apply as end users for single /24 IPv4 address block. > > > > I respectfully disagree with the first sentence entirely. Existing > > policy is heavily biased towards ISPs, and is rather unfair for smaller > > entities that have a critical business need to be multi-homed, but wish > > to avoid being semi-permanently attached to a single ISP due to the > > need for address space. Indeed, the current lack of fairness is part of > > the desire to change the policy. > > > > On the second point - I agree that this could be an issue. I suspect > > it could be an issue now...there's nothing to stop an ISP from applying > > for a /22 as an end user, outside of the risk of getting caught by staff. > > > > > 4. It is unclear exactly how an organization can qualify for a /24 > > > IPv4 address block under this policy. It appears that NRPM section > > > 4.3.3, Utilization rate, requires 25% immediate, 50% within 1 year, > > > would be the justification criteria. However, NRPM section 4.2.3.6, > > > Reassignments to multihomed downstream customers, indicates that an ISP > > > can reassign a /24 IPv4 address block without regard to planned host > > > counts as long as the customer is multi-homed. The question here is > > > does this policy allow ARIN to qualify a requestor for a /24 IPv4 > > > address block based solely on multi-homing or should host counts also be > > > taken into account? > > > > Existing policy, as written, refers to section 4.3.3. That doesn't > > change with the proposed policy. ISPs can feel free to reassign a PA > > /24 via whatever policy they choose, but direct (PI) assignments should > > still be under the guidelines listed in 4.3.3, regardless of the > > minimum assignment size. There is explicitly no change in that. > > > > > 5. The policy does not address requests for more than one /24 IPv4 > > > address block for multiple sites. > > > > My intention for this issue is that this is handled in the same way > > that multiple /22 requests are handled now. Is the request justified? > > There's no change in how this would be handled, outside of the > > differences in minimum assignement size. > > > > > 6. NRPM Section 4.4, Micro-allocation, should remain as is since it > > > is a policy section essential for micro-allocation for critical > > > infrastructure related requests. > > > > I'm happy to concede this point, and change the policy appropriately. > > I'd like more (as in any) community input on this point. To some > > extent, the IPv4 micro-allocation section is irrelevant if this policy > > is approved. On the other hand, it may be useful to explicitly call > > out the allocation policy for critical infrastructure. What that > > infrastructure is defined to be is an interesting question, but beyond > > the scope of the current proposal. More opinions solicted! > > > > > > Thanks again for the opportunity to get some of this discussed in > > advance of the meeting! > > > > -David > > > > _______________________________________________ > > This message sent to you through the ARIN Public Policy Mailing List > > (PPML at arin.net). > > Manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > > > > -- > :):) > /S > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From marla.azinger at frontiercorp.com Thu Apr 19 17:11:16 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Thu, 19 Apr 2007 17:11:16 -0400 Subject: [ppml] Policy Proposal 2007-6 - Staff Assessment Message-ID: <454810F09B5AA04E9D78D13A5C39028A01A3DE2A@nyrofcs2ke2k01.corp.pvt> Dave thanks for keeping discussion going. I oppose this policy for the following reasons. 1. From experience with spammers, I feel this could actually make things easier on them as pointed out in an earlier string or just simply give them another avenue. 2. I tend to believe that a rush of some size will be brought on if this were to pass and that could lead to other negative effects such as depletion and maybe more aggregation than what was already needed, just because they can. 3.One of the rationale from this proposal is "In addition, by keeping the PI allocation size for multi-homed organizations at /22, organizations seeking PI space that don't meet the requirements may be encouraged to exaggerate their address usage. This is something that should clearly not be encouraged." I disagree with this rationale and here is why: I don't see proof of the exaggeration scam working or that it is done alot. For example, just this week I had a customer who tried to do this with ARIN and they were told no and to get IP addresses from me. When I reviewed what they had, they could only justify the use of a /23 and the rest of it was obvious "exaggeration". So I don't see the exaggeration thing working out so much. They may try it, but that doesn't mean they get away with it. And another point, if they were exaggerating /22's or let say /21's then what is to stop others from exaggerating /24's? And honestly, it would be allot easier to exaggerate your way through a /24 justification than it would be a /22. Also, I like to think that the number of people willing to "exaggerate" is smaller than those who are honest (yes I know, fire away, rose colored glasses). So in a quick summary, I don't think the reasons for this proposal outweigh potential spam issues or a run on IPv4 space and its related issues and just may lead to an increase of those willing to exaggerate justification because it is suddenly easier. Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of David Williamson Sent: Thursday, April 19, 2007 12:49 PM To: Stacy Taylor Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2007-6 - Staff Assessment I wanted to allow some time to see if this started any further discussion. Regrettably, it did not. I think your first point is inaccurate. Similar policies already exist in several of the other RIRs, and that hasn't led a run on space. Additionally, organizations that need IP space will get it one way or another. This policy simply provides another method for them. Indeed, ARIN's requirements are more strenuous than most provider's, so some organizations that need a multi-homed /24 may still go for PA space. Here's the key point: this only changes the minimum allocation size - all of the other requirements (multi-homing, utilization, et.c) still stand. On your second point...I'm not in the anti-spam community, so I don't have any real data on how much of a threat this is. Perhaps someone from another RIR could chime in on this, since APNIC, for example, already hands out PI /24s. Has there been any sort of known abuse involving spammers? Like I said, I'm not in the anti-spam community enough to know, but it seems unlikely that spammers would take the time to meet the utilization and multi-homing requirements and then turn around and make that space mostly unusuable. (Lather, rinse, repeat.) It just doesn't seem to me like a profitable business method. As I have mentioned before, additional information from someone with actual data on this point would be great. The general apparent lack of data actually gives me some confidence that this isn't as big of a threat as it may seem. Thanks for the feedback and the opinion! -David On Mon, Apr 16, 2007 at 03:39:06PM -0700, Stacy Taylor wrote: > Hello PPML, > I oppose this policy. > First, I believe there is no better way to chew through the remainder > of the v4 space faster than to pass this policy. > Second, I support staff comments about spammers using this policy for > abuse of networks. In my experience, miscreants of this sort prefer > multiple /24s for their 'businesses' to force spam hunters to play > whack a mole with the blacklisting of space. A _former_ customer of > mine had more than 30 different business names, all with different > points of contact and physical addresses. Because we were the > upstream, we were notified of his violations of our AUP. If the only > contact were the miscreant himself, he would not have been held > accountable. Spammers would adore directly assigned space for this > very reason. > For the good of the Internet, this policy must not be passed. > Stacy > > On 4/13/07, David Williamson wrote: > > I'll second the comment that it's great to get these assessments in > > advance of the meeting. Thanks! > > > > I wanted to take a moment to respond to the staff comments on this > > one. Comments inline. > > > > On Fri, Apr 13, 2007 at 02:21:49PM -0400, Member Services wrote: > > > 1. There is very little qualification criteria which could lead to > > > policy abuse by spammers. These entities could create many different > > > accounts over time as their existing space gets blacklisted or becomes > > > otherwise unusable. > > > > Do spammers take the time to become multihomed and then apply for IP > > space? If they do, I'm sure they can find a way to qualify under the > > existing policy for a /22. I'm not sure I understand the actual risk > > here. It seems to me that this could already be a problem, actually. > > Perhaps a process to identify or report spammers would help this > > problem, but I'm not convinced that spammers actually try to get valid > > IP space from RIRs. Do we (staff and or community) have any data on > > this possibility? > > > > > 2. This could significantly increase the number of requests for > > > ARIN services thereby requiring additional Registration Services > > > Department and Financial Services Department staff. > > > > This is true. It is likely that a small multi-homed enterprise would apply > > for space under this policy rather than applying for space via an ISP. > > > > > 3. Policy applies only to end users which could be perceived as > > > unfair to ISPs. This could also lead to potential abuse of the policy > > > if ISPs apply as end users for single /24 IPv4 address block. > > > > I respectfully disagree with the first sentence entirely. Existing > > policy is heavily biased towards ISPs, and is rather unfair for smaller > > entities that have a critical business need to be multi-homed, but wish > > to avoid being semi-permanently attached to a single ISP due to the > > need for address space. Indeed, the current lack of fairness is part of > > the desire to change the policy. > > > > On the second point - I agree that this could be an issue. I suspect > > it could be an issue now...there's nothing to stop an ISP from applying > > for a /22 as an end user, outside of the risk of getting caught by staff. > > > > > 4. It is unclear exactly how an organization can qualify for a /24 > > > IPv4 address block under this policy. It appears that NRPM section > > > 4.3.3, Utilization rate, requires 25% immediate, 50% within 1 year, > > > would be the justification criteria. However, NRPM section 4.2.3.6, > > > Reassignments to multihomed downstream customers, indicates that an ISP > > > can reassign a /24 IPv4 address block without regard to planned host > > > counts as long as the customer is multi-homed. The question here is > > > does this policy allow ARIN to qualify a requestor for a /24 IPv4 > > > address block based solely on multi-homing or should host counts also be > > > taken into account? > > > > Existing policy, as written, refers to section 4.3.3. That doesn't > > change with the proposed policy. ISPs can feel free to reassign a PA > > /24 via whatever policy they choose, but direct (PI) assignments should > > still be under the guidelines listed in 4.3.3, regardless of the > > minimum assignment size. There is explicitly no change in that. > > > > > 5. The policy does not address requests for more than one /24 IPv4 > > > address block for multiple sites. > > > > My intention for this issue is that this is handled in the same way > > that multiple /22 requests are handled now. Is the request justified? > > There's no change in how this would be handled, outside of the > > differences in minimum assignement size. > > > > > 6. NRPM Section 4.4, Micro-allocation, should remain as is since it > > > is a policy section essential for micro-allocation for critical > > > infrastructure related requests. > > > > I'm happy to concede this point, and change the policy appropriately. > > I'd like more (as in any) community input on this point. To some > > extent, the IPv4 micro-allocation section is irrelevant if this policy > > is approved. On the other hand, it may be useful to explicitly call > > out the allocation policy for critical infrastructure. What that > > infrastructure is defined to be is an interesting question, but beyond > > the scope of the current proposal. More opinions solicted! > > > > > > Thanks again for the opportunity to get some of this discussed in > > advance of the meeting! > > > > -David > > > > _______________________________________________ > > This message sent to you through the ARIN Public Policy Mailing List > > (PPML at arin.net). > > Manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > > > > -- > :):) > /S > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Thu Apr 19 20:58:16 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Apr 2007 17:58:16 -0700 Subject: [ppml] Policy Proposal 2007-6 - Staff Assessment In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01A3DE2A@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A01A3DE2A@nyrofcs2ke2k01.corp.pvt> Message-ID: <75AA345D-012D-4C45-A0E1-44EAF2486A67@delong.com> On Apr 19, 2007, at 2:11 PM, Azinger, Marla wrote: > Dave thanks for keeping discussion going. > > I oppose this policy for the following reasons. > I will restate my support for this policy since it's been several months... > 1. From experience with spammers, I feel this could actually make > things easier on them as pointed out in an earlier string or just > simply give them another avenue. From my experience with spammers, although this might make things a little easier on them, the reality is that they already have an easy enough time getting addresses, I just don't see this making a significant difference to spammers. > 2. I tend to believe that a rush of some size will be brought on if > this were to pass and that could lead to other negative effects > such as depletion and maybe more aggregation than what was already > needed, just because they can. > I think you mean de-aggregation, but, I'll point out that the most of the other RIRs have been issuing /24s for quite a while without encountering either of these effects on a meaningful scale. > 3.One of the rationale from this proposal is "In addition, by > keeping the PI allocation size for multi-homed > organizations at /22, organizations seeking PI space that don't > meet the requirements may be encouraged to exaggerate their address > usage. This is something that should clearly not be encouraged." I > disagree with this rationale and here is why: > > I don't see proof of the exaggeration scam working or that it is > done alot. For example, just this week I had a customer who tried > to do this with ARIN and they were told no and to get IP addresses > from me. When I reviewed what they had, they could only justify > the use of a /23 and the rest of it was obvious "exaggeration". So > I don't see the exaggeration thing working out so much. They may > try it, but that doesn't mean they get away with it. And another > point, if they were exaggerating /22's or let say /21's then what > is to stop others from exaggerating /24's? And honestly, it would > be allot easier to exaggerate your way through a /24 justification > than it would be a /22. Also, I like to think that the number of > people willing to "exaggerate" is smaller than those who are honest > (yes I know, fire away, rose colored glasses). > I am sure that it is possible to exaggerate in a manner that will pass muster with ARIN. I am sure it has happened. I do not have any data on how often this does or does not occur. I suspect nobody does. I will say that I know of networks who had choices of topologies and other implementation details where they could have been implemented using a smaller number of addresses, but, in order to have enough utilization to meet ARIN minimums, chose more IP-utilization heavy designs. This can be done within the guidelines. Having /24s available, or even /23s would make this less likely to occur. The bottom line is that if you have a significant number of VPNs to customers, partners, suppliers, or vendors, or have any other need for your addresses to be configured in a significant number of devices you do not control, the inability to get portable addresses is a major issue. So much so that it would, in many cases I can think of, justify $90,000 it would take to buy 300 extra servers if that's what it took to qualify for a /22 in an environment that only needs a /24. > So in a quick summary, I don't think the reasons for this proposal > outweigh potential spam issues or a run on IPv4 space and its > related issues and just may lead to an increase of those willing to > exaggerate justification because it is suddenly easier. > In summary, I think that both the SPAM and IPv4 run claims are red herrings with no evidence to support them. Given that this practice is already accepted in most of the other RIRs without having either of these effects, I would say there is some evidence to the contrary. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From michael.c.loevner at verizon.com Fri Apr 20 09:36:48 2007 From: michael.c.loevner at verizon.com (michael.c.loevner at verizon.com) Date: Fri, 20 Apr 2007 09:36:48 -0400 Subject: [ppml] Policy Proposal 2007-6 - Staff Assessment In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01A3DE2A@nyrofcs2ke2k01.corp.pvt> Message-ID: Marla, I don't see the same negatives from this policy. While it is true that spammers may take advantage of ARIN, they are just as likely to take advantage of an ISP that may not perform due diligence to get a PA /24. I think we need to concentrate more on the positives of this policy for organizations that need a /24 and don't want the hassle of renumbering rather than concentrating on the exceptions. Also, I don't think it will deplete address space. I think we all take cues from ARIN in developing ISP policies for assigning address space. All this means is that a /24 that an ISP would assign to a customer anyway is getting allocated by ARIN. - Mike "Azinger, Marla" Sent by: ppml-bounces at arin.net 04/19/2007 05:11 PM To "David Williamson" , "Stacy Taylor" cc ppml at arin.net Subject Re: [ppml] Policy Proposal 2007-6 - Staff Assessment Dave thanks for keeping discussion going. I oppose this policy for the following reasons. 1. From experience with spammers, I feel this could actually make things easier on them as pointed out in an earlier string or just simply give them another avenue. 2. I tend to believe that a rush of some size will be brought on if this were to pass and that could lead to other negative effects such as depletion and maybe more aggregation than what was already needed, just because they can. 3.One of the rationale from this proposal is "In addition, by keeping the PI allocation size for multi-homed organizations at /22, organizations seeking PI space that don't meet the requirements may be encouraged to exaggerate their address usage. This is something that should clearly not be encouraged." I disagree with this rationale and here is why: I don't see proof of the exaggeration scam working or that it is done alot. For example, just this week I had a customer who tried to do this with ARIN and they were told no and to get IP addresses from me. When I reviewed what they had, they could only justify the use of a /23 and the rest of it was obvious "exaggeration". So I don't see the exaggeration thing working out so much. They may try it, but that doesn't mean they get away with it. And another point, if they were exaggerating /22's or let say /21's then what is to stop others from exaggerating /24's? And honestly, it would be allot easier to exaggerate your way through a /24 justification than it would be a /22. Also, I like to think that the number of people willing to "exaggerate" is smaller than those who are honest (yes I know, fire away, rose colored glasses). So in a quick summary, I don't think the reasons for this proposal outweigh potential spam issues or a run on IPv4 space and its related issues and just may lead to an increase of those willing to exaggerate justification because it is suddenly easier. Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of David Williamson Sent: Thursday, April 19, 2007 12:49 PM To: Stacy Taylor Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2007-6 - Staff Assessment I wanted to allow some time to see if this started any further discussion. Regrettably, it did not. I think your first point is inaccurate. Similar policies already exist in several of the other RIRs, and that hasn't led a run on space. Additionally, organizations that need IP space will get it one way or another. This policy simply provides another method for them. Indeed, ARIN's requirements are more strenuous than most provider's, so some organizations that need a multi-homed /24 may still go for PA space. Here's the key point: this only changes the minimum allocation size - all of the other requirements (multi-homing, utilization, et.c) still stand. On your second point...I'm not in the anti-spam community, so I don't have any real data on how much of a threat this is. Perhaps someone from another RIR could chime in on this, since APNIC, for example, already hands out PI /24s. Has there been any sort of known abuse involving spammers? Like I said, I'm not in the anti-spam community enough to know, but it seems unlikely that spammers would take the time to meet the utilization and multi-homing requirements and then turn around and make that space mostly unusuable. (Lather, rinse, repeat.) It just doesn't seem to me like a profitable business method. As I have mentioned before, additional information from someone with actual data on this point would be great. The general apparent lack of data actually gives me some confidence that this isn't as big of a threat as it may seem. Thanks for the feedback and the opinion! -David On Mon, Apr 16, 2007 at 03:39:06PM -0700, Stacy Taylor wrote: > Hello PPML, > I oppose this policy. > First, I believe there is no better way to chew through the remainder > of the v4 space faster than to pass this policy. > Second, I support staff comments about spammers using this policy for > abuse of networks. In my experience, miscreants of this sort prefer > multiple /24s for their 'businesses' to force spam hunters to play > whack a mole with the blacklisting of space. A _former_ customer of > mine had more than 30 different business names, all with different > points of contact and physical addresses. Because we were the > upstream, we were notified of his violations of our AUP. If the only > contact were the miscreant himself, he would not have been held > accountable. Spammers would adore directly assigned space for this > very reason. > For the good of the Internet, this policy must not be passed. > Stacy > > On 4/13/07, David Williamson wrote: > > I'll second the comment that it's great to get these assessments in > > advance of the meeting. Thanks! > > > > I wanted to take a moment to respond to the staff comments on this > > one. Comments inline. > > > > On Fri, Apr 13, 2007 at 02:21:49PM -0400, Member Services wrote: > > > 1. There is very little qualification criteria which could lead to > > > policy abuse by spammers. These entities could create many different > > > accounts over time as their existing space gets blacklisted or becomes > > > otherwise unusable. > > > > Do spammers take the time to become multihomed and then apply for IP > > space? If they do, I'm sure they can find a way to qualify under the > > existing policy for a /22. I'm not sure I understand the actual risk > > here. It seems to me that this could already be a problem, actually. > > Perhaps a process to identify or report spammers would help this > > problem, but I'm not convinced that spammers actually try to get valid > > IP space from RIRs. Do we (staff and or community) have any data on > > this possibility? > > > > > 2. This could significantly increase the number of requests for > > > ARIN services thereby requiring additional Registration Services > > > Department and Financial Services Department staff. > > > > This is true. It is likely that a small multi-homed enterprise would apply > > for space under this policy rather than applying for space via an ISP. > > > > > 3. Policy applies only to end users which could be perceived as > > > unfair to ISPs. This could also lead to potential abuse of the policy > > > if ISPs apply as end users for single /24 IPv4 address block. > > > > I respectfully disagree with the first sentence entirely. Existing > > policy is heavily biased towards ISPs, and is rather unfair for smaller > > entities that have a critical business need to be multi-homed, but wish > > to avoid being semi-permanently attached to a single ISP due to the > > need for address space. Indeed, the current lack of fairness is part of > > the desire to change the policy. > > > > On the second point - I agree that this could be an issue. I suspect > > it could be an issue now...there's nothing to stop an ISP from applying > > for a /22 as an end user, outside of the risk of getting caught by staff. > > > > > 4. It is unclear exactly how an organization can qualify for a /24 > > > IPv4 address block under this policy. It appears that NRPM section > > > 4.3.3, Utilization rate, requires 25% immediate, 50% within 1 year, > > > would be the justification criteria. However, NRPM section 4.2.3.6, > > > Reassignments to multihomed downstream customers, indicates that an ISP > > > can reassign a /24 IPv4 address block without regard to planned host > > > counts as long as the customer is multi-homed. The question here is > > > does this policy allow ARIN to qualify a requestor for a /24 IPv4 > > > address block based solely on multi-homing or should host counts also be > > > taken into account? > > > > Existing policy, as written, refers to section 4.3.3. That doesn't > > change with the proposed policy. ISPs can feel free to reassign a PA > > /24 via whatever policy they choose, but direct (PI) assignments should > > still be under the guidelines listed in 4.3.3, regardless of the > > minimum assignment size. There is explicitly no change in that. > > > > > 5. The policy does not address requests for more than one /24 IPv4 > > > address block for multiple sites. > > > > My intention for this issue is that this is handled in the same way > > that multiple /22 requests are handled now. Is the request justified? > > There's no change in how this would be handled, outside of the > > differences in minimum assignement size. > > > > > 6. NRPM Section 4.4, Micro-allocation, should remain as is since it > > > is a policy section essential for micro-allocation for critical > > > infrastructure related requests. > > > > I'm happy to concede this point, and change the policy appropriately. > > I'd like more (as in any) community input on this point. To some > > extent, the IPv4 micro-allocation section is irrelevant if this policy > > is approved. On the other hand, it may be useful to explicitly call > > out the allocation policy for critical infrastructure. What that > > infrastructure is defined to be is an interesting question, but beyond > > the scope of the current proposal. More opinions solicted! > > > > > > Thanks again for the opportunity to get some of this discussed in > > advance of the meeting! > > > > -David > > > > _______________________________________________ > > This message sent to you through the ARIN Public Policy Mailing List > > (PPML at arin.net). > > Manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > > > > -- > :):) > /S > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From andy at nosignal.org Fri Apr 20 21:21:30 2007 From: andy at nosignal.org (Andy Davidson) Date: Fri, 20 Apr 2007 21:21:30 -0400 Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4 AddressCountdown In-Reply-To: References: Message-ID: <2DAD819C-2054-4A0F-9F0D-6E6E57E536C0@nosignal.org> On 16 Apr 2007, at 17:34, Jason Schiller wrote: > When the address space is given out in large blocks, the ISP can > divide up these blocks into reasonably sized pools for each of its > internal regions. This allows for internal aggregation. [...] > This stacking of regional pools will lead to poor internal > aggregation, and thus bloat in the routing and forwarding tables. Do we have any empirical research of this, i.e. can someone who uses large chunks of v4 calculate a model that shows what the effect on the routing table would have been if they'd had to apply for smaller chunks of non-contiguous space more regularly ? Room to breathe in your v4 allocations could have also encouraged sloppiness and wastefulness. (Do we think all of - picking on some companies at random - all of 9/8, 13/8, 15/8, 44/8, etc.,etc. are effective use of large assignments..) A big routing table is bad, we all agree. Running out of v4 is really really bad. From dlw+arin at tellme.com Fri Apr 20 22:02:02 2007 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 20 Apr 2007 19:02:02 -0700 Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4 AddressCountdown In-Reply-To: <2DAD819C-2054-4A0F-9F0D-6E6E57E536C0@nosignal.org> References: <2DAD819C-2054-4A0F-9F0D-6E6E57E536C0@nosignal.org> Message-ID: <20070421020202.GL1898@shell01.corp.tellme.com> On Fri, Apr 20, 2007 at 09:21:30PM -0400, Andy Davidson wrote: > A big routing table is bad, we all agree. Running out of v4 is > really really bad. Indeed. You can always make/add more memory/processor. It may be excessively difficult and expensive (or ruinous to your business), but you can. Making more address space...well, that's a bit harder if you want it to be globally routed. I actually work with two different carriers (who will remain anonymous) who have large internal backbones. One uses 95/8 and the other uses 100/8. (I don't know why.) They have the opinion that it doesn't matter that it's not their space, since they don't touch the global Internet. (At least not with that network.) The problem is that I do, and I touch them. It makes for either some messy NAT or messy routing policy. (The former is not always possible.) You really can't make more space, no matter how hard you try. :) -David From stephen at sprunk.org Sat Apr 21 00:47:00 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 20 Apr 2007 23:47:00 -0500 Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4AddressCountdown References: <2DAD819C-2054-4A0F-9F0D-6E6E57E536C0@nosignal.org> Message-ID: <092c01c783d2$3d61d120$443816ac@atlanta.polycom.com> Thus spake "Andy Davidson" > Do we have any empirical research of this, i.e. can someone > who uses large chunks of v4 calculate a model that shows what > the effect on the routing table would have been if they'd had to > apply for smaller chunks of non-contiguous space more > regularly? Logically, if one multiplies the number of requests needed by N, then the number of required routing slots will multiply by N as well. The only exception would be if allocations were sparse enough that subsequent requests would allow aggregation, but given the rate we're going through /8s, allocations can't be sparse enough for this to be true in enough cases to matter. > Room to breathe in your v4 allocations could have also > encouraged sloppiness and wastefulness. Any org that has to come back for subsequent allocations shouldn't be wasteful or sloppy, because policy says they can't get any new space until they efficiently utilize their existing space. > (Do we think all of - picking on some companies at random - all > of 9/8, 13/8, 15/8, 44/8, etc.,etc. are effective use of large > assignments..) I don't think anyone doubts that excessive direct assignments are bad, particularly the legacy /8s. In theory, the same effect as above applies, but in practice if one gives a slow-growing org more space than they'll ever need, they can't efficiently utilize it. Their growth will lead to gradual efficiency improvements over time, but it'll never reach the level of an org that's given only what they need or that grows quickly, requiring multiple requests and thus audits. I've worked with dozens of folks that used 10/8 internally, but most of them wouldn't have qualified for more than a /16 today if they had to follow ARIN's rules. Many of those orgs are comparable in size to other orgs that adopted IPv4 early and got legacy /8 assignments. Ditto for smaller folks that got legacy /16 assignments; many wouldn't qualify for more than a handful of /24s today. > A big routing table is bad, we all agree. Running out of v4 is > really really bad. Both are going to happen, no matter what we do. Given that we're all going to have to pay to move to IPv6 sooner or later, how much justification is there for collectively spending billions of dollars making IPv4 limp along another few years? S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From alex at basespace.net Sat Apr 21 14:07:55 2007 From: alex at basespace.net (Alex) Date: Sat, 21 Apr 2007 14:07:55 -0400 Subject: [ppml] Policy Proposal 2007-6 - Staff Assessment References: <454810F09B5AA04E9D78D13A5C39028A01A3DE2A@nyrofcs2ke2k01.corp.pvt> Message-ID: <004701c7843f$fcbed780$08067126@basespacenf1s7> ----- Original Message ----- From: "Azinger, Marla" To: "David Williamson" ; "Stacy Taylor" Cc: Sent: Thursday, April 19, 2007 5:11 PM Subject: Re: [ppml] Policy Proposal 2007-6 - Staff Assessment >I don't see the exaggeration thing working out so much... It seems to me that one can claim efficient usage while remaining within the letter, if not the spirit, of ARIN policies. One could give all of ones' shared web hosting customers each their own IP address, claiming it is for future SSL certificate use. One could put each single colocated server customer on their own /30 subnet with a network, gateway, and broadcast address, claiming it is for improved security. >Also, I like to think that the number of people willing to "exaggerate" is >smaller than those who are honest (yes I know, fire away, rose colored >glasses). When I founded BaseSpace.net in 2000, I drafted a mission statement in a fit of idealism: http://www.basespace.net/about/about.html. Bullet one says: * To, by action and by example, make the internet a place where things are done right. So I am not going to exaggerate my IP space usage in order to qualify for a /22. PI space is very important to my business, but being able to look myself in the mirror every morning for the rest of my life and know that I remained true to my principles is more important. Unfortunately, the current policy penalizes the honest. I urge you to reconsider your opposition to 2006-7 in order to help keep the world a place where rose colored glasses are not necessary. Thank you for your time and attention, - Alex Aminoff BaseSpace.net From owen at delong.com Sat Apr 21 15:37:18 2007 From: owen at delong.com (Owen DeLong) Date: Sat, 21 Apr 2007 12:37:18 -0700 Subject: [ppml] Summary of Trial Balloons for Dealing with IPv4 AddressCountdown In-Reply-To: <2DAD819C-2054-4A0F-9F0D-6E6E57E536C0@nosignal.org> References: <2DAD819C-2054-4A0F-9F0D-6E6E57E536C0@nosignal.org> Message-ID: > A big routing table is bad, we all agree. Running out of v4 is > really really bad. > A big table is bad until we fix routing (which was supposed to happen with v6, but, didn't). Running out of v4 may be perceived as bad, but, it's also inevitable. 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 Sun Apr 22 17:03:04 2007 From: owen at delong.com (Owen DeLong) Date: Sun, 22 Apr 2007 14:03:04 -0700 Subject: [ppml] Definition of "Existing Known ISP" Message-ID: According to Leslie, ARIN staff would like community input on the definition of "Existing Known ISP" in the NRPM. I would propose that the following definition seems self-evident to me, but, I would like to see what others here have to say: "An existing, known ISP is any ARIN Subscriber Organization who has received an IPv4 allocation from ARIN or an ARIN predecessor which now is an ARIN Subscriber Organization." Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From michael.dillon at bt.com Sun Apr 22 18:01:41 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 22 Apr 2007 23:01:41 +0100 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: Message-ID: > "An existing, known ISP is any ARIN Subscriber Organization who has > received an IPv4 allocation from ARIN or an ARIN predecessor which > now is an ARIN Subscriber Organization." Convoluted grammar. There is a reason why laws (an policies) are written like computer programs. Let's start by getting rid of the awful term "existing, known ISP". Somewhere in the policy you have a sentence that says something like: ARIN will provide free 7th degree widgets to all organizations which, a) are ARIN subscribers in good standing, and b) currently hold an IPv4 direct allocation This means that they have to be subscribers. It means they have to have paid their fees up to date or they don't get their widgets. The specific wording "direct allocation" comes from the whois directory. If you look at the DoD's 21/8 allocation or the 72.1.0.0/19 to Northern Telephone and Data, they both show "Direct Allocation" even though the DoD clearly got theirs from an ARIN predecessor organization. Therefore I consider that this wording covers predecessors without explicitly mentioning them. It is possible that "direct allocation" isn't defined explicitly enough elsewhere in the policy, and I would suggest that if this is the case, the policy proposal should include a modification elsewhere in the NPRM to fix it up. Anyone think there should be an additional condition c)? Please don't suggest changes that would introduce the word "or" into that list. It's best to stick with all "or" or all "and". In this case, it was relatively straightforward to hide the "or" in a subroutine... I mean in a term that covers both cases of the "or". --Michael Dillon From kloch at kl.net Sun Apr 22 18:02:10 2007 From: kloch at kl.net (Kevin Loch) Date: Sun, 22 Apr 2007 18:02:10 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: References: Message-ID: <462BDB62.5080007@kl.net> Owen DeLong wrote: > According to Leslie, ARIN staff would like community input on the > definition of "Existing Known ISP" in the NRPM. > > I would propose that the following definition seems self-evident to me, > but, I would like to see what others here have to say: > > "An existing, known ISP is any ARIN Subscriber Organization who has > received an IPv4 allocation from ARIN or an ARIN predecessor which > now is an ARIN Subscriber Organization." s/allocation/allocation or direct assignment/ There may be some orgs who elected to be an end user in there IPv4 request who may wish to be considered an ISP under IPv6. I wouldn't want an actual ISP to be forced into being considered an End Site due to an historical but outdated decision. - Kevin From owen at delong.com Sun Apr 22 18:15:31 2007 From: owen at delong.com (Owen DeLong) Date: Sun, 22 Apr 2007 15:15:31 -0700 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: References: Message-ID: <5B5F9DD7-B3A0-4623-8949-7397E3C9622F@delong.com> > Are you intentionally excluding ISPs who have thus-far made use of > PA addresses? > > I'm not arguing a point either way, just saying that you may be > leaving some people out who consider themselves "known". > > -- Kevin My intent is not to change policy or in any way push things in any particular direction. My intent was to solicit clarification of an existing term in an existing policy for the ARIN staff. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From mike at mathbox.com Sun Apr 22 18:19:37 2007 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Sun, 22 Apr 2007 18:19:37 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <9C9C5D53-1BAF-4D7D-A48C-772F72BBC89A@delong.com> Message-ID: <200704221819373.SM02668@mikesplace> Owen, Allow me to revise my comment. I still believe the definition is too narrow. The definition ought to include also anyone who has an assigned ASN. I have had ASN 13775 since 1995. I personally consider $2500 for a /19 or /20 punitive. So, for years we ran with assigned IPv4 from upstream providers and only recently received an initial IPv4 allocation. Because private individuals or organizations with a proven need can be allocated IPv4 space, the term "existing, known ISP" would be too narrow also. ARIN should consider anyone with an IPv4 allocation, not just those organizations that consider themselves ISP. Michael Thomas > >> "An existing, known ISP is any ARIN Subscriber > Organization who has > >> received an IPv4 allocation from ARIN or an ARIN predecessor which > >> now is an ARIN Subscriber Organization." > > > > I am sure that I do not have a definition, but I would > point out that > > there "may" exist a small regional ISP that has an IPv6 allocation, > > but gets their > > IPv4 from upstream providers. > > > > Michael Thomas > > > > Since this definition is for purposes of an ISP receiving > their initial > IPv6 allocation from ARIN, such an ISP would be irrelevant to > this context as any allocation they would receive would not > be their initial allocation. > > Owen > > From marla.azinger at frontiercorp.com Sun Apr 22 18:29:58 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Sun, 22 Apr 2007 18:29:58 -0400 Subject: [ppml] Policy Proposal 2007-8: Transfer Policy Clarifications Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272F8AB@nyrofcs2ke2k01.corp.pvt> Ed and All- I'm a little behind getting my response out, sorry. I think your concerns about wording should be looked at. Hopfully I'm not missing some postings to this that already resolved your concerns. If there are...just ignore this email. ;o) I worked on some rewrites of the text you are concerned about. I thought it might be good to have some rewritten text suggestions put out to everyone so that if we decide we dont like how it is currrently written, we can already start looking at another way of saying "what we mean". So here are my suggestions to the parts that may need some rewriting. 1. Current proposal verbage: "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." Suggested Rewrite: Number Resources are managed as a finite resource and not as a commodity. Number resources are assigned or allocated 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 to be managed in accordance with ARIN's Published Policies. 2. Current proposal verbage: "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." Suggested Rewrite: Under the circumstance of an organization closure where said organization has Number Resources from ARIN, said organization must notify ARIN to either return the Number Resources to ARIN or transfer the Number Resources in accordance with ARIN Policy (reference section 8.2 and 8.3). Cheers! Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Edward Lewis Sent: Monday, March 05, 2007 7:55 PM To: ppml at arin.net Cc: ed.lewis at neustar.biz Subject: Re: [ppml] Policy Proposal 2007-8: Transfer Policy Clarifications At 12:15 -0500 3/2/07, Member Services wrote: >http://www.arin.net/policy/proposals/2007_8.html >Policy Proposal 2007-8: Transfer Policy Clarifications > >Author: Paul Andersen > >Proposal Version: 1.0 > >It should be understood that number resources are not "sold" under ARIN >administration. Rather, number resources are assigned to an organization What I find a bit confusing is the difference between the thought that ARIN "leases" resources versus the thought that a company might "sell" resources from one to another. (An off-shoot of this comes from the fee discussion in APNIC, where resources whose registration is static see the per-year fees decrease. This reflects the nature of the activity as that of managing a registry and not as a "LAN-lord.") ... >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. What exactly does "going out of business" mean? A company can be absorbed by another through a purchase and the brand name tossed away while still maintaining the need for the resources. In a way I can see this saying the transfers can never happen, meaning that if I buy someone's hosting service I may have to apply for new addresses. Worse is the thought that I'd have to renumber if I don't get the transfer of resources. I'm asking an obtuse question because the text doesn't say which POC(s) is/are involved. What if the POC is a role account that transfers with the rest of a once independent company? >8.2 Transfer Requirements > >ARIN will consider requests for the transfer of number resources only >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: I pretty much agree with the intent of this proposal...it's the words I am quibbling about in the previous section. >Rationale: > >Staff analysis and community comments have a problem with the >inconsistent use of the terms "ASN" and "IP Address" in this section >which leads to confusion on which resources can be transferred. The >entire section now utilizes the term "number resources" to clarify what >would appear to be the original intent. I have come across people that find the ARIN on-web flow-chart confusing because AS numbers are not included in the prose. And I have been told that the prose comes from the policy. So I'll add a data point saying that this is in need or updating. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From stephen at sprunk.org Sun Apr 22 18:32:44 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 22 Apr 2007 17:32:44 -0500 Subject: [ppml] Definition of "Existing Known ISP" References: <462BDB62.5080007@kl.net> Message-ID: <01a301c7852e$4d05e410$6401a8c0@atlanta.polycom.com> Thus spake "Kevin Loch" > Owen DeLong wrote: >> According to Leslie, ARIN staff would like community input on the >> definition of "Existing Known ISP" in the NRPM. >> >> I would propose that the following definition seems self-evident >> to me, but, I would like to see what others here have to say: >> >> "An existing, known ISP is any ARIN Subscriber Organization >> who has received an IPv4 allocation from ARIN or an ARIN >> predecessor which now is an ARIN Subscriber Organization." > > s/allocation/allocation or direct assignment/ > > There may be some orgs who elected to be an end user in there > IPv4 request who may wish to be considered an ISP under IPv6. > I wouldn't want an actual ISP to be forced into being considered > an End Site due to an historical but outdated decision. I fall in between these opinions. It's easier for me to define the phrase in terms of who it is (apparently) intended to exclude: 1. "Existing" excludes new orgs without an established customer base. 2. "Known" excludes orgs ARIN is not already aware of, either directly or indirectly. 3. "ISP" excludes orgs that are not in the business of providing IP (v4 or v6) transit service. All of this combines together to form the overall picture that an established ISP of any size should qualify, but a new entrant to the market (i.e. someone with no track record) would not and should go to their upstream for space. Of course, it's not exactly clear on how long an org needs to be in that state, or how many customers they need, to become an "existing, known ISP". It will probably end up being a judgement call on whether an org's track record demonstrates a bona fide attempt at being an ISP/LIR and at least some success at doing so. Specific examples (minus identifying information, of course) might help us pin down where the line is. To Mr. Thomas's point, I don't think an ISP that uses an IPv4 assignment or sub-allocation from their upstream should be disqualified from getting an IPv6 direct allocation. OTOH, an org using an IPv4 direct assignment probably should, because part of getting one of those is not being an ISP. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From owen at delong.com Sun Apr 22 23:25:58 2007 From: owen at delong.com (Owen DeLong) Date: Sun, 22 Apr 2007 20:25:58 -0700 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <01a301c7852e$4d05e410$6401a8c0@atlanta.polycom.com> References: <462BDB62.5080007@kl.net> <01a301c7852e$4d05e410$6401a8c0@atlanta.polycom.com> Message-ID: On Apr 22, 2007, at 3:32 PM, Stephen Sprunk wrote: > Thus spake "Kevin Loch" >> Owen DeLong wrote: >>> According to Leslie, ARIN staff would like community input on the >>> definition of "Existing Known ISP" in the NRPM. >>> >>> I would propose that the following definition seems self-evident >>> to me, but, I would like to see what others here have to say: >>> >>> "An existing, known ISP is any ARIN Subscriber Organization >>> who has received an IPv4 allocation from ARIN or an ARIN >>> predecessor which now is an ARIN Subscriber Organization." >> >> s/allocation/allocation or direct assignment/ >> >> There may be some orgs who elected to be an end user in there >> IPv4 request who may wish to be considered an ISP under IPv6. >> I wouldn't want an actual ISP to be forced into being considered >> an End Site due to an historical but outdated decision. > > I fall in between these opinions. It's easier for me to define the > phrase in terms of who it is (apparently) intended to exclude: > > 1. "Existing" excludes new orgs without an established customer base. > 2. "Known" excludes orgs ARIN is not already aware of, either > directly or indirectly. > 3. "ISP" excludes orgs that are not in the business of providing > IP (v4 or v6) transit service. > > All of this combines together to form the overall picture that an > established ISP of any size should qualify, but a new entrant to > the market (i.e. someone with no track record) would not and should > go to their upstream for space. > A new entrant doesn't qualify under the first clause (existing known ISP), but, could qualify under the second clause in the policy (or have a plan to assign 200 /48s to other organizations). > Of course, it's not exactly clear on how long an org needs to be in > that state, or how many customers they need, to become an > "existing, known ISP". It will probably end up being a judgement > call on whether an org's track record demonstrates a bona fide > attempt at being an ISP/LIR and at least some success at doing so. > Specific examples (minus identifying information, of course) might > help us pin down where the line is. > Given that the policy for which this definition is required only refers to "existing known ISPs" receiving their first v6 allocation from ARIN and has a separate provision for anyone who is not an existing known ISP, I would say it is safe to exclude the following: Anyone who has already received v6 from ARIN (initial allocation no longer applies) Any ISP which does not yet have v4 from ARIN (they should qualify under the 200 /48s provision rather than the existing known ISP). > To Mr. Thomas's point, I don't think an ISP that uses an IPv4 > assignment or sub-allocation from their upstream should be > disqualified from getting an IPv6 direct allocation. OTOH, an org > using an IPv4 direct assignment probably should, because part of > getting one of those is not being an ISP. > While I agree with you, I'm not sure they should qualify under the "existing known ISP" policy rather than the plan to assign 200 /48s provision. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From bicknell at ufp.org Mon Apr 23 08:51:57 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 23 Apr 2007 08:51:57 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: References: Message-ID: <20070423125157.GA55603@ussenterprise.ufp.org> Perhaps simpler, clearer language would be: Any current resource holder who has a signed RSA with ARIN. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From info at arin.net Mon Apr 23 09:04:48 2007 From: info at arin.net (Member Services) Date: Mon, 23 Apr 2007 09:04:48 -0400 Subject: [ppml] ARIN XIX Underway Message-ID: <462CAEF0.1040804@arin.net> The ARIN XIX Public Policy and Members Meeting is now underway in San Juan, Puerto Rico. For those in the community unable to make it to San Juan for the meeting, ARIN is once again offering a webcast of the Public Policy and Members Meetings via RealNetworks Helix Server. The times of the broadcast are as follows (All times are Atlantic Standard Time(AST), (UTC/GMT -4 hours): Public Policy Meeting (Policy and technical discussions) Monday, 23 April 9AM - 5PM Tuesday, 24 April 9AM - 5PM Members Meeting Wednesday, 25 April 9 AM - 12PM For those who already registered to participate remotely, you may send in questions or comments during the times listed above. The full agenda is available at http://www.arin.net/ARIN-XIX/agenda.html. For a link to the live webcast feed, for details about how to connect to the webcast, or to refer to the Remote Participation Acceptable Use Policy, please see: http://www.arin.net/ARIN-XIX/webcast.html Regards, Member Services American Registry for Internet Numbers (ARIN) From bicknell at ufp.org Mon Apr 23 10:09:58 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 23 Apr 2007 10:09:58 -0400 Subject: [ppml] Policy Proposal 2007-6 - Staff Assessment In-Reply-To: <461FCA3D.2030400@arin.net> References: <461FCA3D.2030400@arin.net> Message-ID: <20070423140957.GA60045@ussenterprise.ufp.org> Policy proposal 2002-3 moved the bar from a /20 to a /22 for multi-homed networks, and was implemented in May 2004. I would think statistics on /22 and /21 allocations since that time might provide some useful data when considering this policy to move the bar to a /24. Could staff have perhaps a slide or chart or similar for that discussion? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From michael.dillon at bt.com Mon Apr 23 11:33:28 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 23 Apr 2007 16:33:28 +0100 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <20070423125157.GA55603@ussenterprise.ufp.org> Message-ID: > Subject: Re: [ppml] Definition of "Existing Known ISP" > Perhaps simpler, clearer language would be: > > Any current resource holder who has a signed RSA with ARIN. I love it. But I fear that somebody might keep the term "existing, known ISP" and merely use your wording as a definition for it. Horrors! --Michael Dillon P.S. Any resource holder in good standing... From jordi.palet at consulintel.es Mon Apr 23 11:40:01 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 23 Apr 2007 11:40:01 -0400 Subject: [ppml] Policy Proposal 2006-7 - Staff Assessment In-Reply-To: <46237155.8030404@arin.net> Message-ID: Hi, I think this staff assessment (for all the policy proposals, not speaking about this one now) it is very useful. However, I will like to suggest that it may be much better to have it as part of the PDP with a different timing. For example, if this comes once the AC decide to accept the proposal, the author (and also other participants in ppml) could suggest alternative wordings or whatever it is required to react in time for a possible reviewed version of the proposal (of course if the proposal has been submitted in time to allow that, as in this case which was over half a year ago). Now regarding this proposal, the first thing I will like to say is that I like very much the staff wording suggested in Annex B below. I also believe that this doesn't change the content of the proposal, so hopefully it can be accepted as such by the PDP. Regarding "How can staff verify that an organization is new to providing "Internet services"?", it believe it is obvious. If the organization is NOT a "known ISP" as per the existing policy text, should be considered as "new". I think this could be read also as new to "ARIN" ? Regarding to "What happens at the end of 1 year if the v6 block is not announced?", I will say that the staff should follow the same criteria they use today for the existing option d. What they do if the 200 /48 aren't assigned to other organizations within five years ? Also c is still required. Regarding "What if the IPv6 address space is used on a ?private network? and can?t be seen from the public Internet?". The suggested proposal is not intended for private usage, and point b already indicates that must not be an end site, so the organization necessarily will need to announce the allocated space as in c. Regards, Jordi > De: Member Services > Responder a: > Fecha: Mon, 16 Apr 2007 08:51:33 -0400 > Para: > Asunto: [ppml] Policy Proposal 2006-7 - Staff Assessment > > Policy Proposal 2006-7 > Changes to IPv6 initial allocation criteria > > ARIN Staff Assessment > > The assessment of this proposal includes comments from ARIN staff and > the ARIN General Counsel. It contains analysis of procedural, legal, and > resource concerns regarding the implementation of this policy proposal > as it is currently stated. Any changes to the language of the proposal > may necessitate further analysis by staff and Counsel. > > I. Proposal > > Policy Proposal 2006-7 is available as Annex A below and at: > http://www.arin.net/policy/proposals/2006_7.html > > II. Understanding of the proposal > > ARIN staff understands this proposal would add to the list of > criteria for an initial allocation of IPv6 address space (NRPM section > 6.5.1.1.). Specifically, in addition to the common criteria, if an ISP > is not known, nor can it provide a plan, it can instead attempt to > justify intent to announce the address space within one year. > > III. Issues and concerns > > A. ARIN staff > > 1. ARIN staff is concerned about confusion that may occur if the > text is inserted as the author indicated (letter "d" already has an > "or"). ARIN staff has suggested alternative placement; see Annex B below. > > 2. How can staff verify that an organization is new to providing > "Internet services"? > > 3. What happens at the end of 1 year if the v6 block is not announced? > > 4. What if the IPv6 address space is used on a ?private network? > and can?t be seen from the public Internet? > > B. ARIN General Counsel > > This policy as proposed poses no significant legal risks for ARIN. > > IV. Resource Impact - Minimum > > The resource impact of implementing this policy is viewed as minimum. > Barring any unforeseen resource requirements, this policy could be > implemented within 90 days from the date of the ratification of the > policy by the ARIN Board of Trustees. Implementation would not require > the acquisition of staff personnel or equipment. It will require the > following: > > - Revisions to registration guidelines > - Staff Training > > Respectfully submitted, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ##*## > > > Annex A > > Policy Proposal 2006-7 > Changes to IPv6 initial allocation criteria > > Proposal type: Insert a new additional line item e. to 6.5.1.1 of NRPM > > Policy term: permanent > > Policy statement: > > New organizations need a policy that allows them to apply for IPv6 > address space. To provide this we need to insert a new additional line > item to 6.5.1.1. The new line item would be line 'e' as follows: > > e. OR be an organization new to providing internet services, and can > justify intent to announce the requested IPv6 address space within one > year, through records such as contracts, inventory and/or other > applicable documentation. > > Rationale: > > - New organizations who do not want to use IPv4 at all and start off > using IPv6 addresses only, need a policy that gives them permission to > do so. This is also valid for existing companies that may or may not > have assigned IPv4 addresses and now want to start offering IPv6 > services. These organizations may also wish to request IPv4 at the same > time. > > - One year is given as the sufficient time frame to actually implement > usage of the IPv6 address space and reveal if the 'said organization' is > truly using the IPv6 space granted. > > -Every means of documentation that can reveal 'true intent of use' is > not listed as this can be a very long list and should be left to the > discretion of the RIR staff. > > -An ISP or LIR may decide to assign a different prefix size than /48. > For example, a cellular operator may use /64. > > -ASN is not required because as long as they are statically routed to an > upstream and don't want to run bgp/announce directly to the Internet, > they don't need an ASN, therefore we shouldn't create policy that would > contribute to ASN bloat. > > - Organization in this is defined as a Corporation, ISP, LLC et al. > > In SUMMARY if this policy is implemented the change to the NRPM would > read as follows: > > 6.5.1.1 Initial allocation criteria > > To qualify for an initial allocation of IPV6 address space, an > organization must: > > a be a LIR; > > b. not be an end site; > > c. plan to provide IPV6 connectivity to which it will assign IPV6 > address space, by advertising that connectivity through its single > aggregated address allocation; > > d. be an existing, known ISP in the ARIN region or have a plan for > making at least 200/48 assignments to other organizations within five years. > > e. OR be an organization new to providing internet services, and can > justify intent to announce the requested IPV6 address space within one > year, through records such as contracts, inventory and/or other > applicable documentation. > > Timetable for implementation: Immediate > > ##*## > > > Annex B > > > ARIN staff suggested format for the insertion of the policy text > > 6.5.1.1. Initial allocation criteria > > To qualify for an initial allocation of IPv6 address space, an > organization must: > > a. be an LIR; > > b. not be an end site; > > c. plan to provide IPv6 connectivity to organizations to which it > will assign IPv6 address space, by advertising that connectivity through > its single aggregated address allocation; and > > d. meet at least one of the following: > > 1. be an existing, known ISP in the ARIN region. > > 2. have a plan for making at least 200 /48 assignments to other > organizations within five years. > > 3. be an organization new to providing internet services that can > justify intent to announce the requested IPv6 address space within one > year, through records such as contracts, inventory and/or other > applicable documentation. > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** 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 owen at delong.com Mon Apr 23 11:43:12 2007 From: owen at delong.com (Owen DeLong) Date: Mon, 23 Apr 2007 08:43:12 -0700 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: References: Message-ID: Michael, If you want the policy changed, by all means, submit a template to do so. Currently, no such proposal exists and my intent in the discussion was simply to provide some clarification of the definition as requested by Leslie. Owen On Apr 23, 2007, at 8:33 AM, wrote: >> Subject: Re: [ppml] Definition of "Existing Known ISP" > >> Perhaps simpler, clearer language would be: >> >> Any current resource holder who has a signed RSA with ARIN. > > I love it. But I fear that somebody might keep the term "existing, > known > ISP" and merely use your wording as a definition for it. > > Horrors! > > --Michael Dillon > > P.S. Any resource holder in good standing... > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From BillD at cait.wustl.edu Mon Apr 23 12:05:14 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Mon, 23 Apr 2007 11:05:14 -0500 Subject: [ppml] Historical Policy Proposal Event Message-ID: Wow... 4 policy proposals dealt with expeditiously and with overwhelming support and no dissent. That has never happened before. The credit goes to: Clear and concise proposals making it to the floor. Clear and concise language after significant vetting and changes in language based upon robust ppml participation. Crisp presentation by the author/shepherds of proposals Excellent management of open mic management by the Chair of BoT Remarkable contstraint by those approaching the mics.... Bravo.... But...the process is not done. Those of you who may have not yet weighed in on these proposals should still do so. The ppml is still open and the Advisory Council would like to hear from you about these proposals. We would like to have as much input as possible before judging consensus. For these and the subseqent policies, we will gather that input until Tuesday evening..... Bill Darte ARIN AC -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Mon Apr 23 12:59:11 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 23 Apr 2007 12:59:11 -0400 Subject: [ppml] Policy Proposal 2006-7 - Staff Assessment In-Reply-To: Message-ID: One more thing here. Thinking twice on this, I believe that 3 out of 4 of the staff comments are referring to issues with the existing policy (not the new proposed text). The one which is relevant, regarding the alternative formatting of the text, I already confirmed that I like it very much. Regards, Jordi > De: JORDI PALET MARTINEZ > Responder a: > Fecha: Mon, 23 Apr 2007 11:40:01 -0400 > Para: > Conversaci?n: [ppml] Policy Proposal 2006-7 - Staff Assessment > Asunto: Re: [ppml] Policy Proposal 2006-7 - Staff Assessment > > Hi, > > I think this staff assessment (for all the policy proposals, not speaking > about this one now) it is very useful. However, I will like to suggest that > it may be much better to have it as part of the PDP with a different timing. > For example, if this comes once the AC decide to accept the proposal, the > author (and also other participants in ppml) could suggest alternative > wordings or whatever it is required to react in time for a possible reviewed > version of the proposal (of course if the proposal has been submitted in > time to allow that, as in this case which was over half a year ago). > > Now regarding this proposal, the first thing I will like to say is that I > like very much the staff wording suggested in Annex B below. I also believe > that this doesn't change the content of the proposal, so hopefully it can be > accepted as such by the PDP. > > Regarding "How can staff verify that an organization is new to providing > "Internet services"?", it believe it is obvious. If the organization is NOT > a "known ISP" as per the existing policy text, should be considered as > "new". I think this could be read also as new to "ARIN" ? > > Regarding to "What happens at the end of 1 year if the v6 block is not > announced?", I will say that the staff should follow the same criteria they > use today for the existing option d. What they do if the 200 /48 aren't > assigned to other organizations within five years ? Also c is still > required. > > Regarding "What if the IPv6 address space is used on a ?private network? and > can?t be seen from the public Internet?". The suggested proposal is not > intended for private usage, and point b already indicates that must not be > an end site, so the organization necessarily will need to announce the > allocated space as in c. > > Regards, > Jordi > > > >> De: Member Services >> Responder a: >> Fecha: Mon, 16 Apr 2007 08:51:33 -0400 >> Para: >> Asunto: [ppml] Policy Proposal 2006-7 - Staff Assessment >> >> Policy Proposal 2006-7 >> Changes to IPv6 initial allocation criteria >> >> ARIN Staff Assessment >> >> The assessment of this proposal includes comments from ARIN staff and >> the ARIN General Counsel. It contains analysis of procedural, legal, and >> resource concerns regarding the implementation of this policy proposal >> as it is currently stated. Any changes to the language of the proposal >> may necessitate further analysis by staff and Counsel. >> >> I. Proposal >> >> Policy Proposal 2006-7 is available as Annex A below and at: >> http://www.arin.net/policy/proposals/2006_7.html >> >> II. Understanding of the proposal >> >> ARIN staff understands this proposal would add to the list of >> criteria for an initial allocation of IPv6 address space (NRPM section >> 6.5.1.1.). Specifically, in addition to the common criteria, if an ISP >> is not known, nor can it provide a plan, it can instead attempt to >> justify intent to announce the address space within one year. >> >> III. Issues and concerns >> >> A. ARIN staff >> >> 1. ARIN staff is concerned about confusion that may occur if the >> text is inserted as the author indicated (letter "d" already has an >> "or"). ARIN staff has suggested alternative placement; see Annex B below. >> >> 2. How can staff verify that an organization is new to providing >> "Internet services"? >> >> 3. What happens at the end of 1 year if the v6 block is not announced? >> >> 4. What if the IPv6 address space is used on a ?private network? >> and can?t be seen from the public Internet? >> >> B. ARIN General Counsel >> >> This policy as proposed poses no significant legal risks for ARIN. >> >> IV. Resource Impact - Minimum >> >> The resource impact of implementing this policy is viewed as minimum. >> Barring any unforeseen resource requirements, this policy could be >> implemented within 90 days from the date of the ratification of the >> policy by the ARIN Board of Trustees. Implementation would not require >> the acquisition of staff personnel or equipment. It will require the >> following: >> >> - Revisions to registration guidelines >> - Staff Training >> >> Respectfully submitted, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ##*## >> >> >> Annex A >> >> Policy Proposal 2006-7 >> Changes to IPv6 initial allocation criteria >> >> Proposal type: Insert a new additional line item e. to 6.5.1.1 of NRPM >> >> Policy term: permanent >> >> Policy statement: >> >> New organizations need a policy that allows them to apply for IPv6 >> address space. To provide this we need to insert a new additional line >> item to 6.5.1.1. The new line item would be line 'e' as follows: >> >> e. OR be an organization new to providing internet services, and can >> justify intent to announce the requested IPv6 address space within one >> year, through records such as contracts, inventory and/or other >> applicable documentation. >> >> Rationale: >> >> - New organizations who do not want to use IPv4 at all and start off >> using IPv6 addresses only, need a policy that gives them permission to >> do so. This is also valid for existing companies that may or may not >> have assigned IPv4 addresses and now want to start offering IPv6 >> services. These organizations may also wish to request IPv4 at the same >> time. >> >> - One year is given as the sufficient time frame to actually implement >> usage of the IPv6 address space and reveal if the 'said organization' is >> truly using the IPv6 space granted. >> >> -Every means of documentation that can reveal 'true intent of use' is >> not listed as this can be a very long list and should be left to the >> discretion of the RIR staff. >> >> -An ISP or LIR may decide to assign a different prefix size than /48. >> For example, a cellular operator may use /64. >> >> -ASN is not required because as long as they are statically routed to an >> upstream and don't want to run bgp/announce directly to the Internet, >> they don't need an ASN, therefore we shouldn't create policy that would >> contribute to ASN bloat. >> >> - Organization in this is defined as a Corporation, ISP, LLC et al. >> >> In SUMMARY if this policy is implemented the change to the NRPM would >> read as follows: >> >> 6.5.1.1 Initial allocation criteria >> >> To qualify for an initial allocation of IPV6 address space, an >> organization must: >> >> a be a LIR; >> >> b. not be an end site; >> >> c. plan to provide IPV6 connectivity to which it will assign IPV6 >> address space, by advertising that connectivity through its single >> aggregated address allocation; >> >> d. be an existing, known ISP in the ARIN region or have a plan for >> making at least 200/48 assignments to other organizations within five years. >> >> e. OR be an organization new to providing internet services, and can >> justify intent to announce the requested IPV6 address space within one >> year, through records such as contracts, inventory and/or other >> applicable documentation. >> >> Timetable for implementation: Immediate >> >> ##*## >> >> >> Annex B >> >> >> ARIN staff suggested format for the insertion of the policy text >> >> 6.5.1.1. Initial allocation criteria >> >> To qualify for an initial allocation of IPv6 address space, an >> organization must: >> >> a. be an LIR; >> >> b. not be an end site; >> >> c. plan to provide IPv6 connectivity to organizations to which it >> will assign IPv6 address space, by advertising that connectivity through >> its single aggregated address allocation; and >> >> d. meet at least one of the following: >> >> 1. be an existing, known ISP in the ARIN region. >> >> 2. have a plan for making at least 200 /48 assignments to other >> organizations within five years. >> >> 3. be an organization new to providing internet services that can >> justify intent to announce the requested IPv6 address space within one >> year, through records such as contracts, inventory and/or other >> applicable documentation. >> >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml > > > > > ********************************************** > 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. > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > > > ********************************************** > 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. > > ********************************************** 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 michael.dillon at bt.com Mon Apr 23 17:06:16 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 23 Apr 2007 22:06:16 +0100 Subject: [ppml] Policy Proposal 2006-7 - Staff Assessment In-Reply-To: Message-ID: > Thinking twice on this, I believe that 3 out of 4 of the > staff comments are > referring to issues with the existing policy (not the new > proposed text). However, regardless of the policy proposal being discussed, staff issues in the existing policy are still VERY welcome. All too often, the writers of a policy proposal focus on a narrow section of the existing policy when proposing changes. They fail to check their proposal against the entire set of existing policies and therefore, over time, we have more and more awkward areas in the existing policies. The rewrite that resulted in the NPRM with numbered paragraphs, did not attempt to rationalize all known issues since they were trying to *NOT* change the meaning of the existing policies. That means we still have all sorts of oddities that could be fixed up in a new policy proposal if we take the time to check them against the entire set. If staff comments can help us reach this goal, then we should encourage them. Basically, I think that any issue with existing policy is also an issue with the new proposed text because the new proposed text failed to identify and fix the issues with existing policy. --Michael Dillon From alh-ietf at tndh.net Tue Apr 24 14:42:34 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 24 Apr 2007 11:42:34 -0700 Subject: [ppml] Buying time... In-Reply-To: <462CAEF0.1040804@arin.net> References: <462CAEF0.1040804@arin.net> Message-ID: <026601c786a0$52e5f500$f8b1df00$@net> It is possibly my codec (though there are lots of lost/dup packets), but the arin.ram stream is very choppy so I am having a hard time following in detail. In any case, the discussion about 'buying time' to prepare for IPv6 is just a stalling tactic that will only make the eventual effort that much more painful. It is absolutely understandable that people want to have more time to prepare, but to do that they should have started earlier. Making the current processes more painful for new comers just so the lethargic can feel better is not 'stewardship'. Tony From woody at pch.net Tue Apr 24 14:45:39 2007 From: woody at pch.net (Bill Woodcock) Date: Tue, 24 Apr 2007 11:45:39 -0700 (PDT) Subject: [ppml] Buying time... In-Reply-To: <026601c786a0$52e5f500$f8b1df00$@net> References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net> Message-ID: > The discussion about 'buying time' to prepare for IPv6 is just > a stalling tactic that will only make the eventual effort that much more > painful. It is absolutely understandable that people want to have more time > to prepare, but to do that they should have started earlier. Making the > current processes more painful for new comers just so the lethargic can feel > better is not 'stewardship'. Agreed. ARIN just isn't in a position to save people from themselves. We're running out of v4. The solution to that is v6. If people want to avail themselves of the solution, it's there. We can't force them, and it's twenty years too late to come up with a different solution. -Bill From alh-ietf at tndh.net Tue Apr 24 15:03:04 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 24 Apr 2007 12:03:04 -0700 Subject: [ppml] 240/4 In-Reply-To: <026601c786a0$52e5f500$f8b1df00$@net> References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net> Message-ID: <026d01c786a3$30313170$90939450$@net> I just heard a part of Paul's comment about 240/4, and it sounded like Scott commented about implementations being difficult to fix. Even if the vendors implemented a change and shipped it within 18 months (an aggressive window), there is a very, very, very large installed base of systems that can't/won't be upgraded to allow use of a block that was 'undefined' at the time they were tested & shipped. By the time those work their way out of the network, we will be long past the point where the 240/4 block might have been useful. Tony From pwilson at apnic.net Tue Apr 24 15:36:08 2007 From: pwilson at apnic.net (Paul Wilson) Date: Wed, 25 Apr 2007 05:36:08 +1000 Subject: [ppml] 240/4 In-Reply-To: <026d01c786a3$30313170$90939450$@net> References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net> <026d01c786a3$30313170$90939450$@net> Message-ID: Tony, The suggestion was to use the space for private use, not for global unicast. The critical difference in private networks is that the operators can be expected to know what gear they have and exactly what needs to be upgraded, and also that the impacts of any problems are localised. Many such network deployments could occur independently and in parallel without impact on the rest of the network. A lot of legacy equipment may well be hard to upgrade, but a lot of new services these days are being developed or planned using new technologies that should be much more amenable to upgrade (set top boxes, VOIP gear, appliances etc). My other comment in today's session was that I was told last year of a planned national telco network deployment which would require 8 /8 blocks within the space of 2 or 3 years. The operator in that case would have been happy with private space, if there was enough of it. The cost of redesignating the class E address space seems very low, and without any downside, for the potential benefits which could occur (even if used by only a handful of networks which would otherwise ask for IPv4 public addresses). Paul --On Tuesday, 24 April 2007 12:03 PM -0700 Tony Hain wrote: > I just heard a part of Paul's comment about 240/4, and it sounded like > Scott commented about implementations being difficult to fix. > > Even if the vendors implemented a change and shipped it within 18 months > (an aggressive window), there is a very, very, very large installed base > of systems that can't/won't be upgraded to allow use of a block that was > 'undefined' at the time they were tested & shipped. By the time those work > their way out of the network, we will be long past the point where the > 240/4 block might have been useful. > > Tony > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From alh-ietf at tndh.net Tue Apr 24 15:59:37 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 24 Apr 2007 12:59:37 -0700 Subject: [ppml] 240/4 In-Reply-To: References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net> <026d01c786a3$30313170$90939450$@net> Message-ID: <02ec01c786ab$16fa23d0$44ee6b70$@net> I agree it could be used for Greenfield deployments that are based on completely new implementations. Most discussions though don't make that clear, and by talking about them as generic use for private networks people leap to the assumption that the block would be used the same way as 1918. I have no problem defining the 240/4 block, as long as it is very clear that the space is not generically useful for products not specifically designed to use it. Tony > -----Original Message----- > From: Paul Wilson [mailto:pwilson at apnic.net] > Sent: Tuesday, April 24, 2007 12:36 PM > To: alh-ietf at tndh.net; 'ARIN PPML' > Subject: Re: [ppml] 240/4 > > Tony, > > The suggestion was to use the space for private use, not for global > unicast. The critical difference in private networks is that the > operators > can be expected to know what gear they have and exactly what needs to be > upgraded, and also that the impacts of any problems are localised. Many > such network deployments could occur independently and in parallel > without > impact on the rest of the network. > > A lot of legacy equipment may well be hard to upgrade, but a lot of new > services these days are being developed or planned using new > technologies > that should be much more amenable to upgrade (set top boxes, VOIP gear, > appliances etc). > > My other comment in today's session was that I was told last year of a > planned national telco network deployment which would require 8 /8 > blocks > within the space of 2 or 3 years. The operator in that case would have > been happy with private space, if there was enough of it. > > The cost of redesignating the class E address space seems very low, and > without any downside, for the potential benefits which could occur (even > if > used by only a handful of networks which would otherwise ask for IPv4 > public addresses). > > Paul > > > --On Tuesday, 24 April 2007 12:03 PM -0700 Tony Hain > wrote: > > > I just heard a part of Paul's comment about 240/4, and it sounded like > > Scott commented about implementations being difficult to fix. > > > > Even if the vendors implemented a change and shipped it within 18 > months > > (an aggressive window), there is a very, very, very large installed > base > > of systems that can't/won't be upgraded to allow use of a block that > was > > 'undefined' at the time they were tested & shipped. By the time those > work > > their way out of the network, we will be long past the point where the > > 240/4 block might have been useful. > > > > Tony > > > > _______________________________________________ > > This message sent to you through the ARIN Public Policy Mailing List > > (PPML at arin.net). > > Manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml From raul at lacnic.net Tue Apr 24 16:02:54 2007 From: raul at lacnic.net (Raul Echeberria) Date: Tue, 24 Apr 2007 17:02:54 -0300 Subject: [ppml] Buying time... In-Reply-To: References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net> Message-ID: <7.0.1.0.1.20070424165809.034451a0@lacnic.net> Tony, Bill: I think that the situation is a bit more complicated that what I can understand from your comments. I agree regarding IPv6 is the solution, but IPv6 will not be widely adopted only because we think that would be the solution. So, we will have to deal with IPv4 still for some more time. And we have to work in ensuring the same possibilities of access to IPv4 resources to everybody around the world. IMHO we have to work in making IPv6 more feasible bat also in paralel we have to work in optimizing the usage of IPv4. It can be done in a "non very painful" way. I guess that nobody can obstract Intenet development. Concluding, "buying time" could be benefitial for the community, and it is enough for me. Ra?l At 03:45 p.m. 24/04/2007, Bill Woodcock wrote: > > The discussion about 'buying time' to prepare for IPv6 is just > > a stalling tactic that will only make the > eventual effort that much more > > painful. It is absolutely understandable > that people want to have more time > > to prepare, but to do that they should have started earlier. Making the > > current processes more painful for new > comers just so the lethargic can feel > > better is not 'stewardship'. > >Agreed. ARIN just isn't in a position to save people from themselves. >We're running out of v4. The solution to that is v6. If people want to >avail themselves of the solution, it's there. We can't force them, and >it's twenty years too late to come up with a different solution. > > -Bill > >_______________________________________________ >This message sent to you through the ARIN Public Policy Mailing List >(PPML at arin.net). >Manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/ppml > > >-- >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.5.463 / Virus Database: 269.5.10/774 >- Release Date: 23/04/2007 05:26 p.m. From Alain_Durand at cable.comcast.com Tue Apr 24 16:05:45 2007 From: Alain_Durand at cable.comcast.com (Durand, Alain) Date: Tue, 24 Apr 2007 16:05:45 -0400 Subject: [ppml] 240/4 In-Reply-To: <02ec01c786ab$16fa23d0$44ee6b70$@net> Message-ID: Private networks does not mean greenfield deployments... and even in the case of greenfield deployments, those are NOT done only with brand new code developped especially for that purpose, it is done with a large portion of off-the-shelves equipments, so the problem to deploy class E addresses are mostly the same in private networks as they would be in public networks; ie, class E is NOT a viable solution. - Alain. > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Tony Hain > Sent: Tuesday, April 24, 2007 4:00 PM > To: 'Paul Wilson'; 'ARIN PPML' > Subject: Re: [ppml] 240/4 > > I agree it could be used for Greenfield deployments that are > based on completely new implementations. Most discussions > though don't make that clear, and by talking about them as > generic use for private networks people leap to the > assumption that the block would be used the same way as 1918. > I have no problem defining the 240/4 block, as long as it is > very clear that the space is not generically useful for > products not specifically designed to use it. > > Tony > > > -----Original Message----- > > From: Paul Wilson [mailto:pwilson at apnic.net] > > Sent: Tuesday, April 24, 2007 12:36 PM > > To: alh-ietf at tndh.net; 'ARIN PPML' > > Subject: Re: [ppml] 240/4 > > > > Tony, > > > > The suggestion was to use the space for private use, not for global > > unicast. The critical difference in private networks is that the > > operators can be expected to know what gear they have and > exactly what > > needs to be upgraded, and also that the impacts of any problems are > > localised. Many such network deployments could occur independently > > and in parallel without impact on the rest of the network. > > > > A lot of legacy equipment may well be hard to upgrade, but a lot of > > new services these days are being developed or planned using new > > technologies that should be much more amenable to upgrade (set top > > boxes, VOIP gear, appliances etc). > > > > My other comment in today's session was that I was told > last year of a > > planned national telco network deployment which would require 8 /8 > > blocks within the space of 2 or 3 years. The operator in that case > > would have been happy with private space, if there was enough of it. > > > > The cost of redesignating the class E address space seems very low, > > and without any downside, for the potential benefits which > could occur > > (even if used by only a handful of networks which would > otherwise ask > > for IPv4 public addresses). > > > > Paul > > > > > > --On Tuesday, 24 April 2007 12:03 PM -0700 Tony Hain > > > > wrote: > > > > > I just heard a part of Paul's comment about 240/4, and it sounded > > > like Scott commented about implementations being difficult to fix. > > > > > > Even if the vendors implemented a change and shipped it within 18 > > months > > > (an aggressive window), there is a very, very, very large > installed > > base > > > of systems that can't/won't be upgraded to allow use of a > block that > > was > > > 'undefined' at the time they were tested & shipped. By the time > > > those > > work > > > their way out of the network, we will be long past the > point where > > > the > > > 240/4 block might have been useful. > > > > > > Tony > > > > > > _______________________________________________ > > > This message sent to you through the ARIN Public Policy > Mailing List > > > (PPML at arin.net). > > > Manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/ppml > > > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From alh-ietf at tndh.net Tue Apr 24 16:09:45 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 24 Apr 2007 13:09:45 -0700 Subject: [ppml] countdown proposal In-Reply-To: <026601c786a0$52e5f500$f8b1df00$@net> References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net> Message-ID: <02ed01c786ac$80f11a90$82d34fb0$@net> ...different codec, same chop ... We are on track to burn through just short of 1/3 of the remaining space this year. Given that we are on a compound growth curve rather than a flat 10 /8's per year, there is not enough time left to implement this proposal. I understand Geoff's numbers show a longer timeframe, but 13, 15, 18 is what it looks like at the moment, so to implement a 2 year stop the event would have to happen early next year. That is not far enough down the road for people to react. Tony From jordi.palet at consulintel.es Tue Apr 24 16:41:27 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 24 Apr 2007 16:41:27 -0400 Subject: [ppml] Buying time... In-Reply-To: <7.0.1.0.1.20070424165809.034451a0@lacnic.net> Message-ID: I don't really agree with the need for "buying" more time for deploying IPv6. It will take 1, 2 or 3 years more, but there will be no new products in the market in 1-2 years that don't support IPv6. Market will not accept it, and manufacturers will have no interest on doing so, just a matter of competition. Now, even if (some) ISPs decide not to deploy IPv6, neither transition tools in their networks, the addresses needed for running IPv4-only devices (considering the increase in the use of NAT if required), are already there. We don't need many more IPv4 addresses for keeping the network that we have today and the grown in the next couple of years. If we ever do anything, it will be just an artificial measure, never a perfectly fair solution. There is no way we can decide that we need to reserve some of the /8s for this or that region. Based on what ? And what if the development progress on this or that region is different after two years ? It may be a fair distribution now, but it can be radically different in 2 years. I also believe, as indicated already today in the previous session, that as much as we progress with IPv6 deployment and more traffic is dominant versus IPv4 one, there will be more and more core/distribution/access networks that will turn to be only-IPv6 instead of dual stack (always keeping the LANs with dual stack, even with private IPv4 and NAT), using mechanisms such as softwires to automatically setup IPv4-in-IPv6 tunnels for those applications/hosts that are not yet (or never will be) IPv6 ready. This will mean that some of the today used IPv4 addressing space may be returned, very slowly, and reused just in case new networks appear and they still decide to be dual stack for whatever reason (I tend to think that it will not make sense if IPv6 traffic is becoming dominant, but may be cases that I'm not thinking about). Regards, Jordi > De: Raul Echeberria > Responder a: > Fecha: Tue, 24 Apr 2007 17:02:54 -0300 > Para: 'ARIN PPML' > Asunto: Re: [ppml] Buying time... > > > Tony, Bill: > > I think that the situation is a bit more > complicated that what I can understand from your comments. > I agree regarding IPv6 is the solution, but IPv6 > will not be widely adopted only because we think that would be the solution. > So, we will have to deal with IPv4 still for some > more time. And we have to work in ensuring the > same possibilities of access to IPv4 resources to everybody around the world. > IMHO we have to work in making IPv6 more feasible > bat also in paralel we have to work in optimizing > the usage of IPv4. It can be done in a "non very > painful" way. I guess that nobody can obstract > Intenet development. Concluding, "buying time" > could be benefitial for the community, and it is enough for me. > > Ra?l > > At 03:45 p.m. 24/04/2007, Bill Woodcock wrote: >>> The discussion about 'buying time' to prepare for IPv6 is just >>> a stalling tactic that will only make the >> eventual effort that much more >>> painful. It is absolutely understandable >> that people want to have more time >>> to prepare, but to do that they should have started earlier. Making the >>> current processes more painful for new >> comers just so the lethargic can feel >>> better is not 'stewardship'. >> >> Agreed. ARIN just isn't in a position to save people from themselves. >> We're running out of v4. The solution to that is v6. If people want to >> avail themselves of the solution, it's there. We can't force them, and >> it's twenty years too late to come up with a different solution. >> >> -Bill >> >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.463 / Virus Database: 269.5.10/774 >> - Release Date: 23/04/2007 05:26 p.m. > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** 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 tedm at ipinc.net Tue Apr 24 17:10:55 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 24 Apr 2007 14:10:55 -0700 Subject: [ppml] Buying time... In-Reply-To: <026601c786a0$52e5f500$f8b1df00$@net> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Tony Hain >Sent: Tuesday, April 24, 2007 11:43 AM >To: 'ARIN PPML' >Subject: [ppml] Buying time... > > >It is possibly my codec (though there are lots of lost/dup >packets), but the >arin.ram stream is very choppy so I am having a hard time following in >detail. > >In any case, the discussion about 'buying time' to prepare for IPv6 is just >a stalling tactic that will only make the eventual effort that much more >painful. It is absolutely understandable that people want to have more time >to prepare, but to do that they should have started earlier. Making the >current processes more painful for new comers just so the >lethargic can feel >better is not 'stewardship'. > OK so you would agree that taking action to lengthen the time before IPv4 runout is just buying time and stalling. In other words, IPv4 runout should be allowed to proceed naturally without interference, correct? Then, if you are in favor of not interfering with the natural runout of IPv4, then why do you find all of the previous interference in the IPv4 runout date to be acceptable? The IPv4 runout date has been artifically advanced by past practices that artifically accellerated the consumption of IPv4. At one time you could get a /8 by just e-mailing someone and they wrote it down in their black book. And a lot of people did. As a result, the consumption of IPv4 was accellerated far in advance of what it's normal usage would have been. This so-called "stalling" is merely an attempt to reverse the past mistakes and return to a "natural" runout of IPv4, which should really be taking place far in the future of what it is projected to now. I find your position to be extremely inconsistent. If you want IPv4 runout to progress naturally, then logically ALL IPv4 assignments must fall under a single, uniform allocation scheme. That scheme today is the RIRs. But all IPv4 assignments today are currently NOT under a single allocation scheme. The truth is that people have been interfering with the so-called "natural" runout of IPv4 ever since allocations started. Who are you to say that the interference that is currently being proposed now - what you label "stalling" - is any less morally right than the past interference in runout that has taken place? Frankly, I really believe your argument sounds suspiciously like: "I've spent money and time on a crash course to prepare for IPv6 and by God I'm going to make all the rest of you &*ck* spend the same money and time preparing as I had to do so" If the rest of us "lethargic" people want to correct past allocation mistakes and thereby push forward the IPv4 runout date in advance of what it is projected to be, then I don't see why anyone can make any reasonable objection to that. In a way, those prepared for IPv6 who are arguing about IPv4 runout date are equivalent to a bunch of men sitting around arguing about abortion. It's nothing that will ever happen to them, so not a one of them have any place in the discussion, and the people who it does affect would all be better off if they would just get the hell out. Ted From william at elan.net Tue Apr 24 18:10:46 2007 From: william at elan.net (william(at)elan.net) Date: Tue, 24 Apr 2007 15:10:46 -0700 (PDT) Subject: [ppml] 240/4 In-Reply-To: References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net> <026d01c786a3$30313170$90939450$@net> Message-ID: Entire 240/4 for private use? Is this maybe a bit overreaching? On Wed, 25 Apr 2007, Paul Wilson wrote: > Tony, > > The suggestion was to use the space for private use, not for global > unicast. The critical difference in private networks is that the operators > can be expected to know what gear they have and exactly what needs to be > upgraded, and also that the impacts of any problems are localised. Many > such network deployments could occur independently and in parallel without > impact on the rest of the network. > > A lot of legacy equipment may well be hard to upgrade, but a lot of new > services these days are being developed or planned using new technologies > that should be much more amenable to upgrade (set top boxes, VOIP gear, > appliances etc). > > My other comment in today's session was that I was told last year of a > planned national telco network deployment which would require 8 /8 blocks > within the space of 2 or 3 years. The operator in that case would have > been happy with private space, if there was enough of it. > > The cost of redesignating the class E address space seems very low, and > without any downside, for the potential benefits which could occur (even if > used by only a handful of networks which would otherwise ask for IPv4 > public addresses). > > Paul > > > --On Tuesday, 24 April 2007 12:03 PM -0700 Tony Hain > wrote: > >> I just heard a part of Paul's comment about 240/4, and it sounded like >> Scott commented about implementations being difficult to fix. >> >> Even if the vendors implemented a change and shipped it within 18 months >> (an aggressive window), there is a very, very, very large installed base >> of systems that can't/won't be upgraded to allow use of a block that was >> 'undefined' at the time they were tested & shipped. By the time those work >> their way out of the network, we will be long past the point where the >> 240/4 block might have been useful. >> >> Tony >> >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml From schiller at uu.net Tue Apr 24 17:30:22 2007 From: schiller at uu.net (Jason Schiller) Date: Tue, 24 Apr 2007 17:30:22 -0400 (EDT) Subject: [ppml] Buying time... In-Reply-To: Message-ID: Jordi, Many IPS have a normal 5 year refresh cycle. Depending on where they are in the process, starting an upgrade now may short cut the refresh cycle and require an investment in hardware upgrades (ISPs require packet forwarding in hardware, and not all hardware that forward IPv4 traffic in hardware can also forward IPv6 in hardware). These investments would be in IPv6 which generate no new revune. Large networks can take a long time to upgrade if a fork-lift upgrade is required (think 2-3 years). __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Tue, 24 Apr 2007, JORDI PALET MARTINEZ wrote: > Date: Tue, 24 Apr 2007 16:41:27 -0400 > From: JORDI PALET MARTINEZ > To: ppml at arin.net > Subject: Re: [ppml] Buying time... > > I don't really agree with the need for "buying" more time for deploying > IPv6. It will take 1, 2 or 3 years more, but there will be no new products > in the market in 1-2 years that don't support IPv6. > > Market will not accept it, and manufacturers will have no interest on doing > so, just a matter of competition. > > Now, even if (some) ISPs decide not to deploy IPv6, neither transition tools > in their networks, the addresses needed for running IPv4-only devices > (considering the increase in the use of NAT if required), are already there. > We don't need many more IPv4 addresses for keeping the network that we have > today and the grown in the next couple of years. > > If we ever do anything, it will be just an artificial measure, never a > perfectly fair solution. There is no way we can decide that we need to > reserve some of the /8s for this or that region. Based on what ? And what if > the development progress on this or that region is different after two years > ? It may be a fair distribution now, but it can be radically different in 2 > years. > > I also believe, as indicated already today in the previous session, that as > much as we progress with IPv6 deployment and more traffic is dominant versus > IPv4 one, there will be more and more core/distribution/access networks that > will turn to be only-IPv6 instead of dual stack (always keeping the LANs > with dual stack, even with private IPv4 and NAT), using mechanisms such as > softwires to automatically setup IPv4-in-IPv6 tunnels for those > applications/hosts that are not yet (or never will be) IPv6 ready. This will > mean that some of the today used IPv4 addressing space may be returned, very > slowly, and reused just in case new networks appear and they still decide to > be dual stack for whatever reason (I tend to think that it will not make > sense if IPv6 traffic is becoming dominant, but may be cases that I'm not > thinking about). > > Regards, > Jordi > > > > > > De: Raul Echeberria > > Responder a: > > Fecha: Tue, 24 Apr 2007 17:02:54 -0300 > > Para: 'ARIN PPML' > > Asunto: Re: [ppml] Buying time... > > > > > > Tony, Bill: > > > > I think that the situation is a bit more > > complicated that what I can understand from your comments. > > I agree regarding IPv6 is the solution, but IPv6 > > will not be widely adopted only because we think that would be the solution. > > So, we will have to deal with IPv4 still for some > > more time. And we have to work in ensuring the > > same possibilities of access to IPv4 resources to everybody around the world. > > IMHO we have to work in making IPv6 more feasible > > bat also in paralel we have to work in optimizing > > the usage of IPv4. It can be done in a "non very > > painful" way. I guess that nobody can obstract > > Intenet development. Concluding, "buying time" > > could be benefitial for the community, and it is enough for me. > > > > Ra?l > > > > At 03:45 p.m. 24/04/2007, Bill Woodcock wrote: > >>> The discussion about 'buying time' to prepare for IPv6 is just > >>> a stalling tactic that will only make the > >> eventual effort that much more > >>> painful. It is absolutely understandable > >> that people want to have more time > >>> to prepare, but to do that they should have started earlier. Making the > >>> current processes more painful for new > >> comers just so the lethargic can feel > >>> better is not 'stewardship'. > >> > >> Agreed. ARIN just isn't in a position to save people from themselves. > >> We're running out of v4. The solution to that is v6. If people want to > >> avail themselves of the solution, it's there. We can't force them, and > >> it's twenty years too late to come up with a different solution. > >> > >> -Bill > >> > >> _______________________________________________ > >> This message sent to you through the ARIN Public Policy Mailing List > >> (PPML at arin.net). > >> Manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/ppml > >> > >> > >> -- > >> No virus found in this incoming message. > >> Checked by AVG Free Edition. > >> Version: 7.5.463 / Virus Database: 269.5.10/774 > >> - Release Date: 23/04/2007 05:26 p.m. > > > > > > _______________________________________________ > > This message sent to you through the ARIN Public Policy Mailing List > > (PPML at arin.net). > > Manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > > > > ********************************************** > 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. > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From Alain_Durand at cable.comcast.com Tue Apr 24 17:32:06 2007 From: Alain_Durand at cable.comcast.com (Durand, Alain) Date: Tue, 24 Apr 2007 17:32:06 -0400 Subject: [ppml] 240/4 In-Reply-To: <78364.1177446275@sa.vix.com> Message-ID: > -----Original Message----- > From: vixie at vix.com [mailto:vixie at vix.com] On Behalf Of Paul Vixie > > does this argue for reserving a /4 out of the remaining IANA > pool for augmenting RFC 1918? i think that's not as likely > to happen as augmenting RFC 1918 space by adding 240/4. No. It simply argues that using 240/4 to augment RFC1918 is a non starter. Should RFC1918 be augmented at all is a whole other discussion. - Alain. From jordi.palet at consulintel.es Tue Apr 24 17:46:10 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 24 Apr 2007 17:46:10 -0400 Subject: [ppml] Buying time... In-Reply-To: Message-ID: Agree, but the current estimations for the "exhaustion" seems to still make if possible if anyone of those big carriers has not started yet, I believe. Also, I guess your figures are the worst case and if your existing hardware don't have that support already. I still believe that most of the time you're upgrading your network for other reasons, not necessarily because IPv6, and IPv6 hardware is coming as a value added choice. Of course, there are cases and cases ... Regards, Jordi > De: Jason Schiller > Responder a: > Fecha: Tue, 24 Apr 2007 17:30:22 -0400 (EDT) > Para: JORDI PALET MARTINEZ > CC: > Asunto: Re: [ppml] Buying time... > > Jordi, > > Many IPS have a normal 5 year refresh cycle. Depending on where they are > in the process, starting an upgrade now may short cut the refresh cycle > and require an investment in hardware upgrades (ISPs require packet > forwarding in hardware, and not all hardware that forward IPv4 traffic in > hardware can also forward IPv6 in hardware). These investments would be > in IPv6 which generate no new revune. > > Large networks can take a long time to upgrade if a fork-lift upgrade is > required (think 2-3 years). > > __Jason > ========================================================================== > Jason Schiller (703)886.6648 > Senior Internet Network Engineer fax:(703)886.0512 > Public IP Global Network Engineering schiller at uu.net > UUNET / Verizon jason.schiller at verizonbusiness.com > > The good news about having an email address that is twice as long is that > it increases traffic on the Internet. > > On Tue, 24 Apr 2007, JORDI PALET MARTINEZ wrote: > >> Date: Tue, 24 Apr 2007 16:41:27 -0400 >> From: JORDI PALET MARTINEZ >> To: ppml at arin.net >> Subject: Re: [ppml] Buying time... >> >> I don't really agree with the need for "buying" more time for deploying >> IPv6. It will take 1, 2 or 3 years more, but there will be no new products >> in the market in 1-2 years that don't support IPv6. >> >> Market will not accept it, and manufacturers will have no interest on doing >> so, just a matter of competition. >> >> Now, even if (some) ISPs decide not to deploy IPv6, neither transition tools >> in their networks, the addresses needed for running IPv4-only devices >> (considering the increase in the use of NAT if required), are already there. >> We don't need many more IPv4 addresses for keeping the network that we have >> today and the grown in the next couple of years. >> >> If we ever do anything, it will be just an artificial measure, never a >> perfectly fair solution. There is no way we can decide that we need to >> reserve some of the /8s for this or that region. Based on what ? And what if >> the development progress on this or that region is different after two years >> ? It may be a fair distribution now, but it can be radically different in 2 >> years. >> >> I also believe, as indicated already today in the previous session, that as >> much as we progress with IPv6 deployment and more traffic is dominant versus >> IPv4 one, there will be more and more core/distribution/access networks that >> will turn to be only-IPv6 instead of dual stack (always keeping the LANs >> with dual stack, even with private IPv4 and NAT), using mechanisms such as >> softwires to automatically setup IPv4-in-IPv6 tunnels for those >> applications/hosts that are not yet (or never will be) IPv6 ready. This will >> mean that some of the today used IPv4 addressing space may be returned, very >> slowly, and reused just in case new networks appear and they still decide to >> be dual stack for whatever reason (I tend to think that it will not make >> sense if IPv6 traffic is becoming dominant, but may be cases that I'm not >> thinking about). >> >> Regards, >> Jordi >> >> >> >> >>> De: Raul Echeberria >>> Responder a: >>> Fecha: Tue, 24 Apr 2007 17:02:54 -0300 >>> Para: 'ARIN PPML' >>> Asunto: Re: [ppml] Buying time... >>> >>> >>> Tony, Bill: >>> >>> I think that the situation is a bit more >>> complicated that what I can understand from your comments. >>> I agree regarding IPv6 is the solution, but IPv6 >>> will not be widely adopted only because we think that would be the solution. >>> So, we will have to deal with IPv4 still for some >>> more time. And we have to work in ensuring the >>> same possibilities of access to IPv4 resources to everybody around the >>> world. >>> IMHO we have to work in making IPv6 more feasible >>> bat also in paralel we have to work in optimizing >>> the usage of IPv4. It can be done in a "non very >>> painful" way. I guess that nobody can obstract >>> Intenet development. Concluding, "buying time" >>> could be benefitial for the community, and it is enough for me. >>> >>> Ra?l >>> >>> At 03:45 p.m. 24/04/2007, Bill Woodcock wrote: >>>>> The discussion about 'buying time' to prepare for IPv6 is just >>>>> a stalling tactic that will only make the >>>> eventual effort that much more >>>>> painful. It is absolutely understandable >>>> that people want to have more time >>>>> to prepare, but to do that they should have started earlier. Making the >>>>> current processes more painful for new >>>> comers just so the lethargic can feel >>>>> better is not 'stewardship'. >>>> >>>> Agreed. ARIN just isn't in a position to save people from themselves. >>>> We're running out of v4. The solution to that is v6. If people want to >>>> avail themselves of the solution, it's there. We can't force them, and >>>> it's twenty years too late to come up with a different solution. >>>> >>>> -Bill >>>> >>>> _______________________________________________ >>>> This message sent to you through the ARIN Public Policy Mailing List >>>> (PPML at arin.net). >>>> Manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/ppml >>>> >>>> >>>> -- >>>> No virus found in this incoming message. >>>> Checked by AVG Free Edition. >>>> Version: 7.5.463 / Virus Database: 269.5.10/774 >>>> - Release Date: 23/04/2007 05:26 p.m. >>> >>> >>> _______________________________________________ >>> This message sent to you through the ARIN Public Policy Mailing List >>> (PPML at arin.net). >>> Manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml >> >> >> >> >> ********************************************** >> 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. >> >> >> >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml >> > ********************************************** 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 alh-ietf at tndh.net Tue Apr 24 17:53:07 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 24 Apr 2007 14:53:07 -0700 Subject: [ppml] Buying time... In-Reply-To: References: <026601c786a0$52e5f500$f8b1df00$@net> Message-ID: <033b01c786ba$f1c66aa0$d5533fe0$@net> Ted Mittelstaedt wrote: > >-----Original Message----- > >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > >Tony Hain > >Sent: Tuesday, April 24, 2007 11:43 AM > >To: 'ARIN PPML' > >Subject: [ppml] Buying time... > > > > > >It is possibly my codec (though there are lots of lost/dup > >packets), but the > >arin.ram stream is very choppy so I am having a hard time following in > >detail. > > > >In any case, the discussion about 'buying time' to prepare for IPv6 is > just > >a stalling tactic that will only make the eventual effort that much > more > >painful. It is absolutely understandable that people want to have more > time > >to prepare, but to do that they should have started earlier. Making the > >current processes more painful for new comers just so the > >lethargic can feel > >better is not 'stewardship'. > > > > OK so you would agree that taking action to lengthen the time before > IPv4 runout is just buying time and stalling. In other words, IPv4 > runout should be allowed to proceed naturally without interference, > correct? My point was that stalling does not equate to preparation. If people would actually use the additional time to smooth out the transition, then I would have no problem with it. History shows that if we did extend the date through a policy change, we would be having exactly the same discussion with the same lack of preparation as we approached that new date. > > Then, if you are in favor of not interfering with the natural runout > of IPv4, then why do you find all of the previous interference in the > IPv4 runout date to be acceptable? You assume I was ... > > The IPv4 runout date has been artifically advanced by past practices > that artifically accellerated the consumption of IPv4. At one time > you could get a /8 by just e-mailing someone and they wrote it down in > their black book. And a lot of people did. As a result, the > consumption > of IPv4 was accellerated far in advance of what it's normal usage would > have been. Having been one of those people that received/approved/rejected those email requests for the Dept. of Energy, it was not as arbitrary as you make it out to be. You might be surprised to know that there were issues with routing table size in the ancient past... ;) So working within the block sizes that the stacks of the day were designed to use, on a case by case basis the trade-off was made between 'waste of space' and 'waste of routing slots'. > > This so-called "stalling" is merely an attempt to reverse the past > mistakes > and return to a "natural" runout of IPv4, which should really be taking > place > far in the future of what it is projected to now. The 'natural' rate would be much faster than it is now, if it were not for the artificial bias to force entities into private space. We are seeing that in the compound growth of consumption since 2000, despite the widespread availability and use of nat. See: http://www.tndh.net/~tony/ietf/IPv4-delegated-per-RIR.pdf > > I find your position to be extremely inconsistent. If you want IPv4 > runout > to progress naturally, then logically ALL IPv4 assignments must fall > under a single, uniform allocation scheme. That scheme today is the > RIRs. > But all IPv4 assignments today are currently NOT under a single > allocation > scheme. You logic does not follow. Essentially you are arguing for fairness over the entire space rather than policy for managing the remaining pool. Again, I am not opposed to changing policy if that resulted in a smooth transition. Having watched this saga though, it is clear that the only way we will get traction is to have the exhaustion event clearly in everyone's view. See: http://www.tndh.net/~tony/ietf/IPV4-pool-combined-view.pdf > > The truth is that people have been interfering with the so-called > "natural" > runout of IPv4 ever since allocations started. Who are you to say that > the interference that is currently being proposed now - what you label > "stalling" - is any less morally right than the past interference in > runout that has taken place? I would not call the design/deployment of 1918 & nat to have a particularly moral basis, though it clearly interfered with the burn rate of IPv4. > > Frankly, I really believe your argument sounds suspiciously like: > > "I've spent money and time on a crash course to prepare for IPv6 and by > God I'm going to make all the rest of you &*ck* spend the same money and > time preparing as I had to do so" No, it is based on the observation: Most Network Managers will not ask for IPv6 until they run into a problem getting IPv4 space. It is simple human nature to ignore a problem until it becomes a crisis. Extending the date does not change the observation. > > If the rest of us "lethargic" people > want to correct past allocation mistakes and thereby push forward the > IPv4 > runout date in advance of what it is projected to be, then I don't see > why > anyone can make any reasonable objection to that. There were no allocation mistakes as such. Applying current technology and policy to historical events is not a useful exercise. Again, you are arguing for fairness, and the real issue before us is managing the remaining space. > > In a way, those prepared for IPv6 who are arguing about IPv4 runout date > are equivalent to a bunch of men sitting around arguing about abortion. > It's nothing that will ever happen to them, so not a one of them have > any > place in the discussion, and the people who it does affect would all be > better off if they would just get the hell out. While I have been accused of spreading 'doom & gloom', my only point is to raise awareness that the pool exhaustion is approaching. It would be completely inappropriate to sit quietly and let the event happen, yet there continue to be people that would rather not hear it. From my perspective, if people don't want to hear, they can choose not to listen. At the same time, they have no valid reason to complain that 'they didn't know'. This is particularly an issue for the RIR's, because if people don't know until after the fact they would not be responsibly managing their assets. Tony From alh-ietf at tndh.net Tue Apr 24 17:58:40 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 24 Apr 2007 14:58:40 -0700 Subject: [ppml] 240/4 In-Reply-To: References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net> <026d01c786a3$30313170$90939450$@net> Message-ID: <034501c786bb$b86a5090$293ef1b0$@net> 240/4 is essentially useless space at this point. If it were defined for use by Greenfield deployments that only included new stack implementations that did not need to talk to the 'old world', then it could be used. There are very few deployments that would only include self-contained new implementations though, as people would naturally want to mix in their existing equipment rather than run parallel address spaces for old & new. If one were going to go down that path, it would make more sense to use IPv6 for the new implementation. The only real argument for using 240/4 is existing staff training. Tony > -----Original Message----- > From: william(at)elan.net [mailto:william at elan.net] > Sent: Tuesday, April 24, 2007 3:11 PM > To: Paul Wilson > Cc: alh-ietf at tndh.net; 'ARIN PPML' > Subject: Re: [ppml] 240/4 > > > Entire 240/4 for private use? Is this maybe a bit overreaching? > > On Wed, 25 Apr 2007, Paul Wilson wrote: > > > Tony, > > > > The suggestion was to use the space for private use, not for global > > unicast. The critical difference in private networks is that the > operators > > can be expected to know what gear they have and exactly what needs to > be > > upgraded, and also that the impacts of any problems are localised. > Many > > such network deployments could occur independently and in parallel > without > > impact on the rest of the network. > > > > A lot of legacy equipment may well be hard to upgrade, but a lot of > new > > services these days are being developed or planned using new > technologies > > that should be much more amenable to upgrade (set top boxes, VOIP > gear, > > appliances etc). > > > > My other comment in today's session was that I was told last year of a > > planned national telco network deployment which would require 8 /8 > blocks > > within the space of 2 or 3 years. The operator in that case would > have > > been happy with private space, if there was enough of it. > > > > The cost of redesignating the class E address space seems very low, > and > > without any downside, for the potential benefits which could occur > (even if > > used by only a handful of networks which would otherwise ask for IPv4 > > public addresses). > > > > Paul > > > > > > --On Tuesday, 24 April 2007 12:03 PM -0700 Tony Hain ietf at tndh.net> > > wrote: > > > >> I just heard a part of Paul's comment about 240/4, and it sounded > like > >> Scott commented about implementations being difficult to fix. > >> > >> Even if the vendors implemented a change and shipped it within 18 > months > >> (an aggressive window), there is a very, very, very large installed > base > >> of systems that can't/won't be upgraded to allow use of a block that > was > >> 'undefined' at the time they were tested & shipped. By the time those > work > >> their way out of the network, we will be long past the point where > the > >> 240/4 block might have been useful. > >> > >> Tony > >> > >> _______________________________________________ > >> This message sent to you through the ARIN Public Policy Mailing List > >> (PPML at arin.net). > >> Manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/ppml From tedm at ipinc.net Tue Apr 24 20:26:32 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 24 Apr 2007 17:26:32 -0700 Subject: [ppml] Buying time... In-Reply-To: <033b01c786ba$f1c66aa0$d5533fe0$@net> Message-ID: >-----Original Message----- >From: Tony Hain [mailto:alh-ietf at tndh.net] >Sent: Tuesday, April 24, 2007 2:53 PM >To: 'Ted Mittelstaedt'; 'ARIN PPML' >Subject: RE: [ppml] Buying time... > > >Ted Mittelstaedt wrote: >> >-----Original Message----- >> >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >> >Tony Hain >> >Sent: Tuesday, April 24, 2007 11:43 AM >> >To: 'ARIN PPML' >> >Subject: [ppml] Buying time... >> > >> > >> >It is possibly my codec (though there are lots of lost/dup >> >packets), but the >> >arin.ram stream is very choppy so I am having a hard time following in >> >detail. >> > >> >In any case, the discussion about 'buying time' to prepare for IPv6 is >> just >> >a stalling tactic that will only make the eventual effort that much >> more >> >painful. It is absolutely understandable that people want to have more >> time >> >to prepare, but to do that they should have started earlier. Making the >> >current processes more painful for new comers just so the >> >lethargic can feel >> >better is not 'stewardship'. >> > >> >> OK so you would agree that taking action to lengthen the time before >> IPv4 runout is just buying time and stalling. In other words, IPv4 >> runout should be allowed to proceed naturally without interference, >> correct? > >My point was that stalling does not equate to preparation. If people would >actually use the additional time to smooth out the transition, then I would >have no problem with it. History shows that if we did extend the date >through a policy change, we would be having exactly the same >discussion with >the same lack of preparation as we approached that new date. > That is rediculous. History shows a lot of things but it has not ever been a reliable guide to use to prognosticate dates of future technological events or how they were dealt with by society. In the pre-NAT days if you used that argument you would have reasonably concluded that runout would have already occurred by now. Even if all past date extensions of IPv6 caused discussion with no action, which is very debatable, you cannot use that to predict what will happen if it's extended again. And in any case, why did Microsoft put IPv6 support into Vista, if it wasn't for actions resulting from IPv4 runout discussions? I think you are greatly underestimating the amount of time that is needed for things to happen. And in any case, your argument is circular - you claim you have no opposition under conditions that you claim are impossible - thus having no opposition is impossible. In short, despite the flowery language, you aren't adding anything here. >> >> Then, if you are in favor of not interfering with the natural runout >> of IPv4, then why do you find all of the previous interference in the >> IPv4 runout date to be acceptable? > >You assume I was ... > No, I am saying that if you found it acceptable and your finding that future interference is unacceptable, then your completely inconsistent. If you find past interference to be unacceptable then what is the objection to undoing that interference? >> >> The IPv4 runout date has been artifically advanced by past practices >> that artifically accellerated the consumption of IPv4. At one time >> you could get a /8 by just e-mailing someone and they wrote it down in >> their black book. And a lot of people did. As a result, the >> consumption >> of IPv4 was accellerated far in advance of what it's normal usage would >> have been. > >Having been one of those people that received/approved/rejected those email >requests for the Dept. of Energy, it was not as arbitrary as you >make it out >to be. You might be surprised to know that there were issues with routing >table size in the ancient past... ;) So working within the block sizes that >the stacks of the day were designed to use, on a case by case basis the >trade-off was made between 'waste of space' and 'waste of routing slots'. > So what? That is like saying that because 60 years ago the decision in the United States to allow every last man, woman, and child to have the God-given right to own an automobile and drive it as much as possible was right at the time, that Global Warming today that resulted from it is not a mistake. There is such a thing as a technological decision that appears good at the time to turn out in retrospect to be horrible. Your essentially arguing that extending IPv4 runout is a horrible decision. How do you know that NOT extending it won't also be a horrible decision? >> >> This so-called "stalling" is merely an attempt to reverse the past >> mistakes >> and return to a "natural" runout of IPv4, which should really be taking >> place >> far in the future of what it is projected to now. > >The 'natural' rate would be much faster than it is now, if it were not for >the artificial bias to force entities into private space. We are >seeing that >in the compound growth of consumption since 2000, despite the widespread >availability and use of nat. >See: http://www.tndh.net/~tony/ietf/IPv4-delegated-per-RIR.pdf > Well, there you have it - NAT is a perfect example of sanctioned interference in IPv4 runout rates. And despite the engineers wringing their hands over it, a side effect of NAT has been the poor man's firewall. Do you really think the Internet wouldn't be overrrun with viruses today if it wasn't for widespread deployment of NAT? After all, Microsoft did put "classic" non-NAT-based firewalling in Windows. It's called Windows Firewall and it's active by default. But that classic firewalling approach proved to be worthless compared to the NAT in the little cable/DSL routers and such. Sure, the crackers are figuring their way around that, but it's given us years of breathing room. So, on the scales I would say that not all about NAT has been bad. >> >> I find your position to be extremely inconsistent. If you want IPv4 >> runout >> to progress naturally, then logically ALL IPv4 assignments must fall >> under a single, uniform allocation scheme. That scheme today is the >> RIRs. >> But all IPv4 assignments today are currently NOT under a single >> allocation >> scheme. > >You logic does not follow. Essentially you are arguing for >fairness over the >entire space rather than policy for managing the remaining pool. > Yes, because fairness is all that the RIR's are based on. Do you want the governments and courts involved with the RIRs? If the RIR's are arbitrary and capricious that will invite lawsuits, ones that will be won. And, when runout does happen, if an RIR gets sued for not allocating IPv4, they are going to have to show that they are not being discriminatory or they will be court-ordered to produce numbering. Claiming "well we can't touch all this -old- numbering out there that somebody assigned out of a notebook years ago" ain't gonna cut it. There will have to be evidence that the allocation process is applied uniformly over ALL IPv4 users, regardless of what was done in the past. Your kind of making the argument here that because Joe Blow bought 100 acres 50 years ago when there were no pollution controls, that he can go ahead and dump his sewer into the stream that runs across his property, like he did 50 years ago, because he has some sort of right to be able to do this since he was able to do it 50 years ago when he bought the land. It does not work that way in the legal sphere. If you toss out fairness, your gonna get yourself slapped down. Besides, it's the right and moral thing to do. >Again, I am not opposed to changing policy if that resulted in a smooth >transition. circular reasoning, would you just drop it, please? >Having watched this saga though, it is clear that the only way >we will get traction is to have the exhaustion event clearly in everyone's >view. >See: http://www.tndh.net/~tony/ietf/IPV4-pool-combined-view.pdf > I am not arguing that, but there are just as effective ways to publicize something than by deliberatly being cruel and hurting people. That is the argument that we want to reduce killings so when we hear the young girl down the street being murdered in broad daylight and screaming her head off, we should do nothing so that it makes a splashy headline the next morning, so we can get traction on fighting crime. After all, 1 death is justified because it's going to prevent 20 more deaths, eh? > >> >> The truth is that people have been interfering with the so-called >> "natural" >> runout of IPv4 ever since allocations started. Who are you to say that >> the interference that is currently being proposed now - what you label >> "stalling" - is any less morally right than the past interference in >> runout that has taken place? > >I would not call the design/deployment of 1918 & nat to have a particularly >moral basis, though it clearly interfered with the burn rate of IPv4. > Your arguing over the rightness of the decision, not on the rightness of being able to make the decision. Those are two different arguments. I'm not arguing that NAT was a good or bad decision. I am arguing that because things like NAT were permitted in the past, that you cannot now have any basis to argue that they should not be permitted now, other than that the specific thing being contemplated is bad. You can perhaps say that raising or lowering fees is good or bad but you cannot morally argue that we shouldn't have the ability to raise or lower fees. >> >> Frankly, I really believe your argument sounds suspiciously like: >> >> "I've spent money and time on a crash course to prepare for IPv6 and by >> God I'm going to make all the rest of you &*ck* spend the same money and >> time preparing as I had to do so" > >No, it is based on the observation: > >Most Network Managers will not ask for IPv6 until they run into a problem >getting IPv4 space. It is simple human nature to ignore a problem until it >becomes a crisis. > >Extending the date does not change the observation. > It is also human nature that not all humans pay attention to human nature. It's human nature to sit on your ass watching TV but there's still people jogging on the sidewalks - a minority, that, but they are there. Your essentially screwing the handful of network managers who are taking action but just need more time, on the basis that they are outnumbered by the lazy slob network managers that won't do anything until a fire is lit under them. >> >> If the rest of us "lethargic" people >> want to correct past allocation mistakes and thereby push forward the >> IPv4 >> runout date in advance of what it is projected to be, then I don't see >> why >> anyone can make any reasonable objection to that. > >There were no allocation mistakes as such. Applying current technology and >policy to historical events is not a useful exercise. Well, what exactly do you think that the invention of IPv6 -is-? Seems to me nothing more than the application of current technology to a historical event - the invention of IPv4. IPv4 isn't big enough, so we solved it by inventing IPv6. IPv4 isn't being fairly allocated so we solve it by going back to the people with IPv4 they aren't using and taking it back. If the IPv4 runout date gets advanced, well then happy side effect for some people, eh? >Again, you >are arguing >for fairness, and the real issue before us is managing the remaining space. > No, the REAL issue is managing ALL the IPv4 space. The term "remaining" assumes all past allocations are good, which they are not. You can look at the BGP table and compare it to the list of allocated IP and see that. >> >> In a way, those prepared for IPv6 who are arguing about IPv4 runout date >> are equivalent to a bunch of men sitting around arguing about abortion. >> It's nothing that will ever happen to them, so not a one of them have >> any >> place in the discussion, and the people who it does affect would all be >> better off if they would just get the hell out. > >While I have been accused of spreading 'doom & gloom', my only point is to >raise awareness that the pool exhaustion is approaching. Good, do so! But do not do so by being logically inconsistent and unfair. Doing so turns you from a statesman into nothing more than a pundit, and we have enough of those already. >It would be >completely inappropriate to sit quietly and let the event happen, I agree. Ted From william at elan.net Tue Apr 24 22:47:45 2007 From: william at elan.net (william(at)elan.net) Date: Tue, 24 Apr 2007 19:47:45 -0700 (PDT) Subject: [ppml] countdown proposal In-Reply-To: <02ed01c786ac$80f11a90$82d34fb0$@net> References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net> <02ed01c786ac$80f11a90$82d34fb0$@net> Message-ID: On Tue, 24 Apr 2007, Tony Hain wrote: > ...different codec, same chop ... > > We are on track to burn through just short of 1/3 of the remaining space > this year. Given that we are on a compound growth curve rather than a flat If you did polynomial approximation, what are your numbers? Or do you believe it to be exponential growth? Have you compared estimates & grown on per-region (RIR) basis? BTW - Personally I think even Geoff numbers are couple years ahead of when runout will actually happen (depending on how you define runout). But I'm not sure 1-3 year difference and exact year in projection is really that important, event will happen in next decade anyway and everyone should know and be preparing for it. > 10 /8's per year, there is not enough time left to implement this proposal. > I understand Geoff's numbers show a longer timeframe, but 13, 15, 18 is what > it looks like at the moment, so to implement a 2 year stop the event would > have to happen early next year. That is not far enough down the road for > people to react. Maybe its for the good. When time runs out is when people start to react, its just important to be ready and have all current computers, OS and network equipment suporting v6 (even if its not configured). The last one is however the one I'm most worried about - there are way too many personal routers & NAT devices out there and most are not capable of handling ipv6 and many do not know how to update them even if software were to be available. > Tony > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From michel at arneill-py.sacramento.ca.us Wed Apr 25 00:49:35 2007 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 24 Apr 2007 21:49:35 -0700 Subject: [ppml] 240/4 In-Reply-To: References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net><026d01c786a3$30313170$90939450$@net> Message-ID: Hi Paul, I'm not trying to bash at you, but I have a few things to comment on: > Paul Wilson wrote: > The suggestion was to use the space for private use, > not for global unicast. This does not make much of a difference. Anyone who needs more than 10.0.0.0/8 for a private network has routing issues the same as every large public operator. Maybe the difference is they would like the IS-IS and OSPF parts handling 240/4 faster than the eBGP. > The cost of redesignating the class E address space seems very low, This is exaggerated; moderately low is the best you can hope; there are gazillions of lines of code that needs to be patched. Does not happen overnight. > and without any downside Wishful thinking, but no game. Bottom line is, a network that you can't plug in any "legacy" (meaning, earlier than 2009) M$ or Ci$co hardware on (because you have a class E address) is not a network; there are way too many vested egoes in both these companies to expect they would implement 240/4 gracefully. If you have to wait IOS 23.x and Windows 2014 to have an IPv4 stack that handles 240/4 you are SOL. Let me put it in other words: I have no problem with 240/4 becoming either an extension of private addresses or global unicast, as long as it's not on _my_ network nor any I have to talk to :-D It's like software from a well-known vendor: as long as other people "beta-test" it before it reaches SP2, works fine with me :-D Bottom line is: I am among the large number of people who supported and/or co-authored something about reclaiming class E for a better use than experimental. That being said, this late in the game, it does more harm than good. Everyone is better off waiting for v4 allocations to expire, in order for the market to figure out if: a) Shortage of v4 addresses will be enough to launch v6 or b) Market will move to living on v4 stockpiles, more NAT and so on so we can declare v6 dead and move on. The way I see it: the sooner the better. We have been arguing for the last 10 years about IPv6, time to make the call if it's a valid solution or not. Time to let the market make the call. In the big scheme of things, a 240/4 address is not something I would want to use on my network today, too many bugs to sort out for the very little extra time it would provide. The world will move either to IPv6 or to more/double NAT, I have waited long enough. Let's exhaust IPv4 and see what happens. Michel. From michael.dillon at bt.com Wed Apr 25 03:47:27 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 25 Apr 2007 08:47:27 +0100 Subject: [ppml] Buying time... In-Reply-To: Message-ID: > The IPv4 runout date has been artifically advanced by past practices > that artifically accellerated the consumption of IPv4. At one time > you could get a /8 by just e-mailing someone and they wrote it down in > their black book. And a lot of people did. This is not true. You had to have a big network that was being converted to IP or you had to be building a big IP network, in order to get that /8. Few companies were in that position, therefore few /8s were handed out. The economic factors are outside of IP adressing policy, but the policy does leverage them to avoid making policies that are unneccessary. > I find your position to be extremely inconsistent. That's politics. Deal with it. Either your understanding is flawed or the other person is exercising their right to be inconsistent. > "I've spent money and time on a crash course to prepare for > IPv6 and by > God I'm going to make all the rest of you &*ck* spend the > same money and > time preparing as I had to do so" You'll win more flies with honey than with vinegar. > In a way, those prepared for IPv6 who are arguing about IPv4 > runout date > are equivalent to a bunch of men sitting around arguing about > abortion. > It's nothing that will ever happen to them, so not a one of > them have any > place in the discussion, and the people who it does affect > would all be > better off if they would just get the hell out. ARIN's public policy mailing list is open to all, not just to the people that you want to have in the discussion. In order to make a wise and balanced policy we need to see a variety of viewpoints. But we don't need to insult our opponents. We don't need to cuss and swear. And we don't need people who engage in these behaviors to be part of the discussion. --Michael Dillon From michael.dillon at bt.com Wed Apr 25 03:55:40 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 25 Apr 2007 08:55:40 +0100 Subject: [ppml] Buying time... In-Reply-To: Message-ID: >(ISPs require packet > forwarding in hardware, and not all hardware that forward > IPv4 traffic in > hardware can also forward IPv6 in hardware). That's an oversimplification. For one, not all routers in an ISP network need to forward in hardware, particularly at the edge where there is an opportunity to pick and choose. For instance, use new edge routers for IPv6 customers and old ones for IPv4-only customers. Also, MPLS can be used in the core where traffic levels are high. But it is true that some shortsighted ISPs have boxed themselves into a corner because their CTOs made mistakes, or their CEOs decided that they would bet the farm. If these companies run into economic difficulties, that is OK because that is how the free market system is supposed to operate. > Large networks can take a long time to upgrade if a fork-lift > upgrade is required (think 2-3 years). I've never come across a large ISP that would even consider a fork-lift upgrade. The reality is that upgrades are phased and they never really complete because there are always parts of the network where the older hardware causes no pain. Those old boxes will sit and work there for another 10 years until someone decides that it is too risky to continue to use boxes that are years past their end-of-life. IPv6 will not be a forklift upgrade because there are too many ways to make IPv6 and IPv4 coexist in the same network. Pseudowires, MPLS, tunneling, dual stack, diverse layer 3 networks. --Michael Dillon From Crumb_Anthony_A at cat.com Wed Apr 25 07:21:12 2007 From: Crumb_Anthony_A at cat.com (Anthony A. Crumb) Date: Wed, 25 Apr 2007 06:21:12 -0500 Subject: [ppml] Buying time... In-Reply-To: Message-ID: Thank you Michael, excellent post. We all have WAY too much information to digest, to spend it filtering through messages to weed out the ones that are not constructive. Anthony A. Crumb Sent by: ppml-bounces at arin.net 04/25/2007 02:47 AM To cc Subject Re: [ppml] Buying time... Caterpillar: Confidential Green Retain Until: 05/25/2007 Retention Category: G90 - General Matters/Administration > The IPv4 runout date has been artifically advanced by past practices > that artifically accellerated the consumption of IPv4. At one time > you could get a /8 by just e-mailing someone and they wrote it down in > their black book. And a lot of people did. This is not true. You had to have a big network that was being converted to IP or you had to be building a big IP network, in order to get that /8. Few companies were in that position, therefore few /8s were handed out. The economic factors are outside of IP adressing policy, but the policy does leverage them to avoid making policies that are unneccessary. > I find your position to be extremely inconsistent. That's politics. Deal with it. Either your understanding is flawed or the other person is exercising their right to be inconsistent. > "I've spent money and time on a crash course to prepare for > IPv6 and by > God I'm going to make all the rest of you &*ck* spend the > same money and > time preparing as I had to do so" You'll win more flies with honey than with vinegar. > In a way, those prepared for IPv6 who are arguing about IPv4 > runout date > are equivalent to a bunch of men sitting around arguing about > abortion. > It's nothing that will ever happen to them, so not a one of > them have any > place in the discussion, and the people who it does affect > would all be > better off if they would just get the hell out. ARIN's public policy mailing list is open to all, not just to the people that you want to have in the discussion. In order to make a wise and balanced policy we need to see a variety of viewpoints. But we don't need to insult our opponents. We don't need to cuss and swear. And we don't need people who engage in these behaviors to be part of the discussion. --Michael Dillon _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at basespace.net Wed Apr 25 11:45:47 2007 From: alex at basespace.net (Alex) Date: Wed, 25 Apr 2007 11:45:47 -0400 Subject: [ppml] Policy Proposal 2007-6 - Staff Assessment References: <454810F09B5AA04E9D78D13A5C39028A01A3DE2A@nyrofcs2ke2k01.corp.pvt> <004701c7843f$fcbed780$08067126@basespacenf1s7> Message-ID: <002701c78750$cb391e00$08067126@basespacenf1s7> Did 2007-6 pass? - Alex From schiller at uu.net Wed Apr 25 09:19:39 2007 From: schiller at uu.net (Jason Schiller) Date: Wed, 25 Apr 2007 09:19:39 -0400 (EDT) Subject: [ppml] Buying time... In-Reply-To: Message-ID: The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Tue, 24 Apr 2007, JORDI PALET MARTINEZ wrote: > Date: Tue, 24 Apr 2007 17:46:10 -0400 > From: JORDI PALET MARTINEZ > To: ppml at arin.net > Subject: Re: [ppml] Buying time... > > Agree, but the current estimations for the "exhaustion" seems to still make > if possible if anyone of those big carriers has not started yet, I believe. > > Also, I guess your figures are the worst case and if your existing hardware > don't have that support already. > > I still believe that most of the time you're upgrading your network for > other reasons, not necessarily because IPv6, and IPv6 hardware is coming as > a value added choice. Of course, there are cases and cases ... Yes I am in the process of upgrading the network for other efforts and other projects, but it is unlikely that these other efforts will result in a replacement of all assets that are not IPv6 capable by 2012. Whatever remains non-IPv6 capable will have to be upgraded, and as IPv6 generates no new revune there is not much of a return on investment. __Jason > > Regards, > Jordi > > > > > > De: Jason Schiller > > Responder a: > > Fecha: Tue, 24 Apr 2007 17:30:22 -0400 (EDT) > > Para: JORDI PALET MARTINEZ > > CC: > > Asunto: Re: [ppml] Buying time... > > > > Jordi, > > > > Many IPS have a normal 5 year refresh cycle. Depending on where they are > > in the process, starting an upgrade now may short cut the refresh cycle > > and require an investment in hardware upgrades (ISPs require packet > > forwarding in hardware, and not all hardware that forward IPv4 traffic in > > hardware can also forward IPv6 in hardware). These investments would be > > in IPv6 which generate no new revune. > > > > Large networks can take a long time to upgrade if a fork-lift upgrade is > > required (think 2-3 years). > > > > __Jason > > ========================================================================== > > Jason Schiller (703)886.6648 > > Senior Internet Network Engineer fax:(703)886.0512 > > Public IP Global Network Engineering schiller at uu.net > > UUNET / Verizon jason.schiller at verizonbusiness.com > > > > The good news about having an email address that is twice as long is that > > it increases traffic on the Internet. > > > > On Tue, 24 Apr 2007, JORDI PALET MARTINEZ wrote: > > > >> Date: Tue, 24 Apr 2007 16:41:27 -0400 > >> From: JORDI PALET MARTINEZ > >> To: ppml at arin.net > >> Subject: Re: [ppml] Buying time... > >> > >> I don't really agree with the need for "buying" more time for deploying > >> IPv6. It will take 1, 2 or 3 years more, but there will be no new products > >> in the market in 1-2 years that don't support IPv6. > >> > >> Market will not accept it, and manufacturers will have no interest on doing > >> so, just a matter of competition. > >> > >> Now, even if (some) ISPs decide not to deploy IPv6, neither transition tools > >> in their networks, the addresses needed for running IPv4-only devices > >> (considering the increase in the use of NAT if required), are already there. > >> We don't need many more IPv4 addresses for keeping the network that we have > >> today and the grown in the next couple of years. > >> > >> If we ever do anything, it will be just an artificial measure, never a > >> perfectly fair solution. There is no way we can decide that we need to > >> reserve some of the /8s for this or that region. Based on what ? And what if > >> the development progress on this or that region is different after two years > >> ? It may be a fair distribution now, but it can be radically different in 2 > >> years. > >> > >> I also believe, as indicated already today in the previous session, that as > >> much as we progress with IPv6 deployment and more traffic is dominant versus > >> IPv4 one, there will be more and more core/distribution/access networks that > >> will turn to be only-IPv6 instead of dual stack (always keeping the LANs > >> with dual stack, even with private IPv4 and NAT), using mechanisms such as > >> softwires to automatically setup IPv4-in-IPv6 tunnels for those > >> applications/hosts that are not yet (or never will be) IPv6 ready. This will > >> mean that some of the today used IPv4 addressing space may be returned, very > >> slowly, and reused just in case new networks appear and they still decide to > >> be dual stack for whatever reason (I tend to think that it will not make > >> sense if IPv6 traffic is becoming dominant, but may be cases that I'm not > >> thinking about). > >> > >> Regards, > >> Jordi > >> > >> > >> > >> > >>> De: Raul Echeberria > >>> Responder a: > >>> Fecha: Tue, 24 Apr 2007 17:02:54 -0300 > >>> Para: 'ARIN PPML' > >>> Asunto: Re: [ppml] Buying time... > >>> > >>> > >>> Tony, Bill: > >>> > >>> I think that the situation is a bit more > >>> complicated that what I can understand from your comments. > >>> I agree regarding IPv6 is the solution, but IPv6 > >>> will not be widely adopted only because we think that would be the solution. > >>> So, we will have to deal with IPv4 still for some > >>> more time. And we have to work in ensuring the > >>> same possibilities of access to IPv4 resources to everybody around the > >>> world. > >>> IMHO we have to work in making IPv6 more feasible > >>> bat also in paralel we have to work in optimizing > >>> the usage of IPv4. It can be done in a "non very > >>> painful" way. I guess that nobody can obstract > >>> Intenet development. Concluding, "buying time" > >>> could be benefitial for the community, and it is enough for me. > >>> > >>> Ra?l > >>> > >>> At 03:45 p.m. 24/04/2007, Bill Woodcock wrote: > >>>>> The discussion about 'buying time' to prepare for IPv6 is just > >>>>> a stalling tactic that will only make the > >>>> eventual effort that much more > >>>>> painful. It is absolutely understandable > >>>> that people want to have more time > >>>>> to prepare, but to do that they should have started earlier. Making the > >>>>> current processes more painful for new > >>>> comers just so the lethargic can feel > >>>>> better is not 'stewardship'. > >>>> > >>>> Agreed. ARIN just isn't in a position to save people from themselves. > >>>> We're running out of v4. The solution to that is v6. If people want to > >>>> avail themselves of the solution, it's there. We can't force them, and > >>>> it's twenty years too late to come up with a different solution. > >>>> > >>>> -Bill > >>>> > >>>> _______________________________________________ > >>>> This message sent to you through the ARIN Public Policy Mailing List > >>>> (PPML at arin.net). > >>>> Manage your mailing list subscription at: > >>>> http://lists.arin.net/mailman/listinfo/ppml > >>>> > >>>> > >>>> -- > >>>> No virus found in this incoming message. > >>>> Checked by AVG Free Edition. > >>>> Version: 7.5.463 / Virus Database: 269.5.10/774 > >>>> - Release Date: 23/04/2007 05:26 p.m. > >>> > >>> > >>> _______________________________________________ > >>> This message sent to you through the ARIN Public Policy Mailing List > >>> (PPML at arin.net). > >>> Manage your mailing list subscription at: > >>> http://lists.arin.net/mailman/listinfo/ppml > >> > >> > >> > >> > >> ********************************************** > >> 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. > >> > >> > >> > >> _______________________________________________ > >> This message sent to you through the ARIN Public Policy Mailing List > >> (PPML at arin.net). > >> Manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/ppml > >> > > > > > > > ********************************************** > 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. > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From info at arin.net Wed Apr 25 10:20:17 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 10:20:17 -0400 Subject: [ppml] Policy Proposal: Removal of ISP Immediate Need from End-User Message-ID: <462F63A1.6050101@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next regularly scheduled meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Removal of ISP Immediate Need from End-User Author: Rob Seastrom, David Williamson, Owen DeLong Proposal Version: 0.1 Submission Date: 4/24/07 Proposal type: delete Policy term: permanent Policy statement: Delete section 4.3.4, which reads: 4.3.4. Additional considerations End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4]. from the NRPM. Rationale: As discussed at ARIN XIX, section 4.3.4 creates a conflict with section 4.2.1.6 in that section 4.2.1.6 specifically excludes end users while section 4.3.4 is specifically for end users. Prior to the development of the multihoming policy for end users, the immediate need policy was required in order to support end users being able to get address space under some circumstances. The "immediate need" title is a misnomer as it is more an issue of "initial need without prior address utilization" than "immediate need". Such initial needs for end users are now addressed best through the multihoming policy. Timetable for implementation: immediate From info at arin.net Wed Apr 25 10:20:37 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 10:20:37 -0400 Subject: [ppml] Policy Proposal: Resource Renewal and Verification Message-ID: <462F63B5.3000809@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next regularly scheduled meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Resource Renewal and Verification Author: Owen DeLong Proposal Version: 0.0.1 Submission Date: 4/24/07 Proposal type: new Policy term: permanent Policy statement: At any time after a resource is allocated or assigned, ARIN staff may audit the usage of the resource to verify that it is in compliance with the policies under which it was issued and the RSA which governs its use. Should the staff develop reason to believe that such usage no longer meets ARIN policy, ARIN shall immediately notify the appropriate POCs and attempt to resolve the issue. Should the issue not be resolved to ARIN's satisfaction, ARIN shall have the option of not renewing the effected resources at the next renewal of the organization. If renewal is not at least 90 days out when the POC is notified of ARIN's decision not to renew, a 90 day grace period shall be granted. Any decision not to renew may be appealed to the BoT who shall act an the appeal within 30 days. The decision of the BoT shall be final. Rationale: It was my understanding that ARIN staff already had this option. However, it is not clear in policy that such an option exists. Codifying this ability will prevent fraud and reduce the likelihood of resources being obtained under false pretense. For example, a claim was made at a policy meeting that organizations can/do apply under the multi-home policy, then become single-homed and remain single-homed, essentially doing an end-run on the multi-home policy. Timetable for implementation: Immediate From m.hertrick at neovera.com Wed Apr 25 10:44:44 2007 From: m.hertrick at neovera.com (Michael Hertrick) Date: Wed, 25 Apr 2007 10:44:44 -0400 Subject: [ppml] Policy Proposal: Resource Renewal and Verification In-Reply-To: <462F63B5.3000809@arin.net> References: <462F63B5.3000809@arin.net> Message-ID: <462F695C.1080606@neovera.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think this policy is already clearly stated in the ARIN Number Resource Policy Manual sections 4.1.2 through 4.1.5. ~Mike. Member Services wrote: > ARIN received the following policy proposal. In accordance with the > ARIN Internet Resource Policy Evaluation Process, the proposal is > being posted to the ARIN Public Policy Mailing List (PPML) and > being placed on ARIN's website. > > The AC will review this proposal and may decide to: > > 1. Accept the proposal as a formal policy proposal as it is > presented; > > 2. Work with the author to: a) clarify the language or intent of > the proposal; b) divide the proposal into two (2) or more > proposals; or c) combine the proposal with other proposals; or, > > 3. Not accept the proposal as a formal policy proposal. > > The AC will review this proposal at their next regularly scheduled > meeting. If the AC accepts the proposal, then it will be posted as > a formal policy proposal to PPML and it will be presented at a > Public Policy Meeting. If the AC does not accept the proposal, then > the AC will explain that decision; and at that time the author may > elect to use the petition process to advance their proposal. If the > author elects not to petition or the petition fails, then the > proposal will be closed. > > The ARIN Internet Resource Policy Evaluation Process can be found > at: http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > Regards, > > Member Services American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Resource Renewal and Verification > > Author: Owen DeLong Proposal Version: 0.0.1 > > Submission Date: 4/24/07 > > Proposal type: new > > Policy term: permanent Policy statement: > > At any time after a resource is allocated or assigned, ARIN staff > may audit the usage of the resource to verify that it is in > compliance with the policies under which it was issued and the RSA > which governs its use. > > Should the staff develop reason to believe that such usage no > longer meets ARIN policy, ARIN shall immediately notify the > appropriate POCs and attempt to resolve the issue. Should the > issue not be resolved to ARIN's satisfaction, ARIN shall have the > option of not renewing the effected resources at the next renewal > of the organization. > > If renewal is not at least 90 days out when the POC is notified of > ARIN's decision not to renew, a 90 day grace period shall be > granted. > > Any decision not to renew may be appealed to the BoT who shall act > an the appeal within 30 days. The decision of the BoT shall be > final. > > Rationale: > > It was my understanding that ARIN staff already had this option. > However, it is not clear in policy that such an option exists. > Codifying this ability will prevent fraud and reduce the likelihood > of resources being obtained under false pretense. For example, a > claim was made at a policy meeting that organizations can/do apply > under the multi-home policy, then become single-homed and remain > single-homed, essentially doing an end-run on the multi-home > policy. > > Timetable for implementation: Immediate > > _______________________________________________ This message sent > to you through the ARIN Public Policy Mailing List (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGL2lccJVdtfpkLb8RAvvEAJ0WRhoz8qEbbMYqEwE8W0hlHLXh+wCdF8IC +j417Bvb8v2aZQFxKdyTsGo= =NQxi -----END PGP SIGNATURE----- From michael.dillon at bt.com Wed Apr 25 12:29:09 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 25 Apr 2007 17:29:09 +0100 Subject: [ppml] Policy Proposal: Resource Renewal and Verification In-Reply-To: <462F63B5.3000809@arin.net> Message-ID: > If renewal is not at least 90 days out when the POC is notified of > ARIN's decision not to renew, a 90 day grace period shall be granted. That's a really bad rounding algorithm. It would be better to say that the date, 90 days before the renewal date, is considered to be the deadline for discussions. That way, everyone marches to the same rhythm and ARIN staff can plan their actions based on when renewal dates come around. > Any decision not to renew may be appealed to the BoT who shall act an > the appeal within 30 days. The decision of the BoT shall be final. An appellate court? Do they need some rules by which they must reach their decisions? In any case, I am opposed to this policy. It is too simplistic and I don't believe that it can be repaired with a bit of editing because it starts with the wrong premises. --Michael Dillon From alh-ietf at tndh.net Wed Apr 25 13:58:44 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 25 Apr 2007 10:58:44 -0700 Subject: [ppml] Buying time... In-Reply-To: References: <033b01c786ba$f1c66aa0$d5533fe0$@net> Message-ID: <048d01c78763$5dd54b00$197fe100$@net> Ted Mittelstaedt wrote: > >> ....snip > >> OK so you would agree that taking action to lengthen the time before > >> IPv4 runout is just buying time and stalling. In other words, IPv4 > >> runout should be allowed to proceed naturally without interference, > >> correct? > > > >My point was that stalling does not equate to preparation. If people > would > >actually use the additional time to smooth out the transition, then I > would > >have no problem with it. History shows that if we did extend the date > >through a policy change, we would be having exactly the same > >discussion with > >the same lack of preparation as we approached that new date. > > > > That is rediculous. History shows a lot of things but it has not ever > been a reliable guide to use to prognosticate dates of future > technological > events or how they were dealt with by society. > > In the pre-NAT days if you used that argument you would have reasonably > concluded that runout would have already occurred by now. > > Even if all past date extensions of IPv6 caused discussion with no > action, > which is very debatable, you cannot use that to predict what will happen > if it's extended again. And in any case, why did Microsoft put IPv6 > support > into Vista, if it wasn't for actions resulting from IPv4 runout > discussions? That was about reducing the support costs related to nat for both the operation of the applications and development of traversal technologies. I was the Program Manager that put the stake in the ground about how XP would lay the groundwork, and those that followed me took it further than I expected in Vista to totally insulate the application developer from IPv4. > > I think you are greatly underestimating the amount of time that is > needed > for > things to happen. In a life prior to MSFT I managed the transitions from a collection of random protocols to IPv4, across a set of semi-autonomous organizations that really didn't want to change from what they knew, so I am well aware of how long things take. At the same time, as WG chair for ngtrans I guided the direction toward dual-stack as the primary deployment model because that ends up making things smoother and faster over the long run. This is particularly true when the new protocol is tried first because that ends up making the switch almost transparent as soon as both ends are ready. > > And in any case, your argument is circular - you claim you have no > opposition > under conditions that you claim are impossible - thus having no > opposition > is impossible. In short, despite the flowery language, you aren't > adding > anything here. There has been an ongoing discussion about the need to prepare for IPv6 for several years now, and exactly how much progress has been made (outside of Japan)? People that have a one-quarter-focus will not react just because the time was extended, they will simply continue doing nothing until they are forced to. > > >> > >> Then, if you are in favor of not interfering with the natural runout > >> of IPv4, then why do you find all of the previous interference in the > >> IPv4 runout date to be acceptable? > > > >You assume I was ... > > > > No, I am saying that if you found it acceptable and your finding that > future interference is unacceptable, then your completely inconsistent. > > If you find past interference to be unacceptable then what is the > objection to undoing that interference? You can't kill off nat at this point, yet that was clearly an interference in the 'natural' exhaustion of IPv4. > > >> > >> The IPv4 runout date has been artifically advanced by past practices > >> that artifically accellerated the consumption of IPv4. At one time > >> you could get a /8 by just e-mailing someone and they wrote it down > in > >> their black book. And a lot of people did. As a result, the > >> consumption > >> of IPv4 was accellerated far in advance of what it's normal usage > would > >> have been. > > > >Having been one of those people that received/approved/rejected those > email > >requests for the Dept. of Energy, it was not as arbitrary as you > >make it out > >to be. You might be surprised to know that there were issues with > routing > >table size in the ancient past... ;) So working within the block sizes > that > >the stacks of the day were designed to use, on a case by case basis the > >trade-off was made between 'waste of space' and 'waste of routing > slots'. > > > > So what? That is like saying that because 60 years ago the decision in > the United States to allow every last man, woman, and child to have the > God-given right to own an automobile and drive it as much as possible > was right at the time, that Global Warming today that resulted from it > is > not a mistake. The right to own & drive was fine. Where the U.S. differed from other governments around the world was to keep taxes on fuel low. If the U.S. tax rates on fuel were significantly higher over that timeframe, the sprawl would be much lower, which in turn would impact commute times, ...... > > There is such a thing as a technological decision that appears good at > the time to turn out in retrospect to be horrible. > > Your essentially arguing that extending IPv4 runout is a horrible > decision. > How do you know that NOT extending it won't also be a horrible decision? I am not arguing that it would be a bad decision, because I don't know either way. What I am arguing is that extending the date will not do anything to make it easier, and if anything will allow the deployment of that much more stuff that will add to the problem of translation later. > > >> > >> This so-called "stalling" is merely an attempt to reverse the past > >> mistakes > >> and return to a "natural" runout of IPv4, which should really be > taking > >> place > >> far in the future of what it is projected to now. > > > >The 'natural' rate would be much faster than it is now, if it were not > for > >the artificial bias to force entities into private space. We are > >seeing that > >in the compound growth of consumption since 2000, despite the > widespread > >availability and use of nat. > >See: http://www.tndh.net/~tony/ietf/IPv4-delegated-per-RIR.pdf > > > > Well, there you have it - NAT is a perfect example of sanctioned > interference in IPv4 runout rates. And despite the engineers wringing > their hands over it, a side effect of NAT has been the poor man's > firewall. A real firewall would have been a much better outcome. > > Do you really think the Internet wouldn't be overrrun with viruses today > if it wasn't for widespread deployment of NAT? After all, Microsoft > did put "classic" non-NAT-based firewalling in Windows. It's called > Windows Firewall and it's active by default. But that classic > firewalling > approach proved to be worthless compared to the NAT in the little > cable/DSL routers and such. Sure, the crackers are figuring their way > around that, but it's given us years of breathing room. So, on the > scales > I would say that not all about NAT has been bad. Focusing on symptoms does not solve the problems. Since nat provided an easy path to block traffic that was not email or web client originated, there was no effort put into that cable/DSL device to make it trivial to manage as a real firewall. > > >> > >> I find your position to be extremely inconsistent. If you want IPv4 > >> runout > >> to progress naturally, then logically ALL IPv4 assignments must fall > >> under a single, uniform allocation scheme. That scheme today is the > >> RIRs. > >> But all IPv4 assignments today are currently NOT under a single > >> allocation > >> scheme. > > > >You logic does not follow. Essentially you are arguing for > >fairness over the > >entire space rather than policy for managing the remaining pool. > > > > Yes, because fairness is all that the RIR's are based on. > > Do you want the governments and courts involved with the RIRs? No, but they will be if the world is 'taken by surprise' by the exhaustion of IPv4, because that will be a sign that the RIR's are not competent for the task. > > If the RIR's are arbitrary and capricious > that will invite lawsuits, ones that will be won. And, when runout > does happen, if an RIR gets sued for not allocating IPv4, they are > going to have to show that they are not being discriminatory or they > will be court-ordered to produce numbering. Claiming "well we can't > touch all this -old- numbering out there that somebody assigned > out of a notebook years ago" ain't gonna cut it. There will have to > be evidence that the allocation process is applied > uniformly over ALL IPv4 users, regardless of what was done in the > past. IANAL: but as I understand it, rulings are based on how the policies in effect at the time were followed, and policy revisions are not retroactively applied. > > Your kind of making the argument here that because Joe Blow bought > 100 acres 50 years ago when there were no pollution controls, that > he can go ahead and dump his sewer into the stream that runs across > his property, like he did 50 years ago, because he has some sort > of right to be able to do this since he was able to do it 50 years ago > when he bought the land. It does not work that way in the legal > sphere. No, I am arguing that since he built a barn on that property 50 years ago that he is not required to tear it down just because the area now has building codes that don't allow barns. > > If you toss out fairness, your gonna get yourself slapped down. > Besides, > it's the right and moral thing to do. If you really want fairness, then ~50 /8's have to go to China, another ~50 have to go to India, ... In the end the ARIN region gets left with less than 20 /8's, so not only those old allocations have to go back to IANA, but 8 or so of the 'by ARIN policy' ones do to. Also, I don't hear you arguing that everyone that received an ARIN allocation in 1997 has to rejustify based on current policy, so don't be too quick to throw out accusations about inconsistency. > ...... > > Your essentially screwing the handful of network managers who are taking > action but just need more time, on the basis that they are outnumbered > by > the lazy slob network managers that won't do anything until a fire is > lit > under them. I really don't understand this argument. I absolutely agree that it takes time. Essentially people that are taking action are already working off that time. Are you arguing that current policy does not allow you to have enough addresses today to carry you through? Or: Are you arguing that you will be stuck needing to provide IPv4 to customers until they are ready to move? I completely understand the last point, and have been telling ISP's that if they don't want to be paying an arm-&-leg in the open market for IPv4 to add customers, they had better be encouraging existing customers to move to IPv6 now. > > >> > >> If the rest of us "lethargic" people > >> want to correct past allocation mistakes and thereby push forward the > >> IPv4 > >> runout date in advance of what it is projected to be, then I don't > see > >> why > >> anyone can make any reasonable objection to that. > > > >There were no allocation mistakes as such. Applying current technology > and > >policy to historical events is not a useful exercise. > > Well, what exactly do you think that the invention of IPv6 -is-? Seems > to > me nothing more than the application of current technology to a > historical > event - the invention of IPv4. > > IPv4 isn't big enough, so we solved it by inventing IPv6. > > IPv4 isn't being fairly allocated so we solve it by going back to the > people > with IPv4 they aren't using and taking it back. If the IPv4 runout date > gets advanced, well then happy side effect for some people, eh? You claim to be concerned about lawsuits, but are completely oblivious to the problem that there is no consistent definition of 'using'. An organization that does not announce a /8 to public providers could well be announcing it to others to keep from having overlapping 1918 between a large private group, or because some set of the group has a public presence and needs to keep the routing sorted out. > > >Again, you > >are arguing > >for fairness, and the real issue before us is managing the remaining > space. > > > > No, the REAL issue is managing ALL the IPv4 space. The term "remaining" > assumes all past allocations are good, which they are not. You can look > at the BGP table and compare it to the list of allocated IP and see > that. Which BGP table? There are many views around the world of what is call the dfz, so even there it is not a single instance. Since you said 'the BGP table', I assume you are defining private BGP peerings as 'unused space'. ...... The bottom line is that for any policy change to have a real impact it will have to be a globally consistent policy. The entire reason there are multiple RIR's is that people don't want a globally consistent allocation policy, otherwise it would make more sense to combine the resources into IANA and do it all centrally. Even getting agreement on a globally coordinated set of policies is difficult, and past experience shows that takes a couple of years. At the current growing burn rate, by the time we get 2 years down the road there will not be enough of the IPv4 space left for that to matter, even counting what might be reclaimed. Reclamation is a nice thing to debate about, but implementing the changes to free up blocks takes just about as long as deploying IPv6, and it is only a stop-gap on top of it. In the end IPv4 reclamation has an even lower ROI than IPv6, which will have to be deployed anyway. Any network manager would use the legal system to stall a reclamation effort while they deployed IPv6, just because that would be the lowest cost path for them. That would raise costs for the RIR's, & therefore their members, which is 'not fair' to those that have followed policies and have enough space to last them until they are ready to deploy IPv6. I don't know why you are so insistent on delay, unless the current policy does not allow you to get enough space to last you through an already active effort to transition. If this is really about making the policies friendly to those that are trying to transition, then I am all for it. If it is simply a stalling tactic, then it really has no long term value to anyone. Tony From alh-ietf at tndh.net Wed Apr 25 14:12:58 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 25 Apr 2007 11:12:58 -0700 Subject: [ppml] Buying time... In-Reply-To: References: Message-ID: <049a01c78765$5acd9e60$1068db20$@net> Jason Schiller wrote: > .... > Whatever remains non-IPv6 capable will have to be upgraded, and as IPv6 > generates no new revune there is not much of a return on investment. For those cases it becomes a risk-avoidance justification: How much are you willing to pay for IPv4 in the open market to add new customers or services? What will the price be in the open market for a resource that is not considered property now, but even another part of Jason's organization gets away with effectively leasing for ~ $1.33/day per address? Hotels typically get ~ $5/day/address, and from what I hear globally, long term contracts already average ~ $1/day/address. Prices for scarce resources don't go down as they become harder to get ... Tony From alex at basespace.net Wed Apr 25 14:20:30 2007 From: alex at basespace.net (Alex Aminoff) Date: Wed, 25 Apr 2007 14:20:30 -0400 (EDT) Subject: [ppml] Policy Proposal 2007-6 - Staff Assessment In-Reply-To: <20070425141917.GF22289@shell01.corp.tellme.com> References: <454810F09B5AA04E9D78D13A5C39028A01A3DE2A@nyrofcs2ke2k01.corp.pvt> <004701c7843f$fcbed780$08067126@basespacenf1s7> <002701c78750$cb391e00$08067126@basespacenf1s7> <20070425141917.GF22289@shell01.corp.tellme.com> Message-ID: On Wed, 25 Apr 2007, David Williamson wrote: > On Wed, Apr 25, 2007 at 11:45:47AM -0400, Alex wrote: >> Did 2007-6 pass? > > No. The poll in the room was 19 for and 21 against, and the AC decided > to abandon the proposal. I'm not sure that was the correct choice, but > I'm not on the AC. I'm sure a formal post from the AC on this decision > (and all of the other proposals) will appear soon. OK, next meeting I will try to be more involved. This past month we had a new baby and due to an invoice not being signed a cash flow issue. If folks don't want little guys like me to have PI space, would it be acceptable to modify the policy on PA space so that I can SWIP my assigned space directly in the ARIN whois? One of the problems I have with PA space is that nobody ever bothers to chase down the recursive whois at Cogent to find out that it is actually assigned to me, they always just contact Cogent, who rarely forward me the contacts. - Alex Aminoff BaseSpace.net From owen at delong.com Wed Apr 25 14:49:25 2007 From: owen at delong.com (Owen DeLong) Date: Wed, 25 Apr 2007 11:49:25 -0700 Subject: [ppml] Policy Proposal: Resource Renewal and Verification In-Reply-To: <462F695C.1080606@neovera.com> References: <462F63B5.3000809@arin.net> <462F695C.1080606@neovera.com> Message-ID: I thought so too, however, when I suggested that this fact should be considered as mitigation for fraud concerns expressed about a policy proposal, the chairman of the board suggested that if the community wanted ARIN to be able to take such action, we should submit a policy proposal to support it. So, this proposal is an effort to address the chairman of the board's comments at the public policy meeting. Owen On Apr 25, 2007, at 7:44 AM, Michael Hertrick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I think this policy is already clearly stated in the ARIN Number > Resource Policy Manual sections 4.1.2 through 4.1.5. > > ~Mike. > > > Member Services wrote: >> ARIN received the following policy proposal. In accordance with the >> ARIN Internet Resource Policy Evaluation Process, the proposal is >> being posted to the ARIN Public Policy Mailing List (PPML) and >> being placed on ARIN's website. >> >> The AC will review this proposal and may decide to: >> >> 1. Accept the proposal as a formal policy proposal as it is >> presented; >> >> 2. Work with the author to: a) clarify the language or intent of >> the proposal; b) divide the proposal into two (2) or more >> proposals; or c) combine the proposal with other proposals; or, >> >> 3. Not accept the proposal as a formal policy proposal. >> >> The AC will review this proposal at their next regularly scheduled >> meeting. If the AC accepts the proposal, then it will be posted as >> a formal policy proposal to PPML and it will be presented at a >> Public Policy Meeting. If the AC does not accept the proposal, then >> the AC will explain that decision; and at that time the author may >> elect to use the petition process to advance their proposal. If the >> author elects not to petition or the petition fails, then the >> proposal will be closed. >> >> The ARIN Internet Resource Policy Evaluation Process can be found >> at: http://www.arin.net/policy/irpep.html >> >> Mailing list subscription information can be found at: >> http://www.arin.net/mailing_lists/index.html >> >> Regards, >> >> Member Services American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Policy Proposal Name: Resource Renewal and Verification >> >> Author: Owen DeLong Proposal Version: 0.0.1 >> >> Submission Date: 4/24/07 >> >> Proposal type: new >> >> Policy term: permanent Policy statement: >> >> At any time after a resource is allocated or assigned, ARIN staff >> may audit the usage of the resource to verify that it is in >> compliance with the policies under which it was issued and the RSA >> which governs its use. >> >> Should the staff develop reason to believe that such usage no >> longer meets ARIN policy, ARIN shall immediately notify the >> appropriate POCs and attempt to resolve the issue. Should the >> issue not be resolved to ARIN's satisfaction, ARIN shall have the >> option of not renewing the effected resources at the next renewal >> of the organization. >> >> If renewal is not at least 90 days out when the POC is notified of >> ARIN's decision not to renew, a 90 day grace period shall be >> granted. >> >> Any decision not to renew may be appealed to the BoT who shall act >> an the appeal within 30 days. The decision of the BoT shall be >> final. >> >> Rationale: >> >> It was my understanding that ARIN staff already had this option. >> However, it is not clear in policy that such an option exists. >> Codifying this ability will prevent fraud and reduce the likelihood >> of resources being obtained under false pretense. For example, a >> claim was made at a policy meeting that organizations can/do apply >> under the multi-home policy, then become single-homed and remain >> single-homed, essentially doing an end-run on the multi-home >> policy. >> >> Timetable for implementation: Immediate >> >> _______________________________________________ This message sent >> to you through the ARIN Public Policy Mailing List (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFGL2lccJVdtfpkLb8RAvvEAJ0WRhoz8qEbbMYqEwE8W0hlHLXh+wCdF8IC > +j417Bvb8v2aZQFxKdyTsGo= > =NQxi > -----END PGP SIGNATURE----- > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From stephen at sprunk.org Wed Apr 25 14:38:53 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 25 Apr 2007 13:38:53 -0500 Subject: [ppml] Policy Proposal: Resource Renewal and Verification References: <462F63B5.3000809@arin.net> <462F695C.1080606@neovera.com> Message-ID: <017601c7876b$1b3cd350$343816ac@atlanta.polycom.com> Thus spake "Michael Hertrick" > I think this policy is already clearly stated in the ARIN Number > Resource Policy Manual sections 4.1.2 through 4.1.5. I thought so as well, particularly given what the RSA says, but the response from ARIN is that it's not clear that policy supports it or what the process should be. In practice, ARIN is limited to refusing to issue new resources if existing ones aren't utilized efficiently. I dislike Owen's wording, and was planning on submitting my own proposal shortly, so I'll work with Owen on modifying his. I think we agree on intent. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From info at arin.net Wed Apr 25 16:00:47 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:00:47 -0400 Subject: [ppml] Policy Proposal 2007-1 - Last Call Message-ID: <462FB36F.50308@arin.net> Policy Proposal 2007-1 Reinstatement of PGP Authentication Method The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_1.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-1 Reinstatement of PGP Authentication Method Proposal type: New Policy term: Permanent Policy statement: ADDITION TO NRPM 12 Authentication Methods 12.1 Mail-From This section intentionally left blank. 12.2 PGP ARIN accepts PGP-signed email as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. 12.3 X.509 This section intentionally left blank. UPDATES TO TEMPLATES ARIN shall update templates as necessary to identify and distinguish between mail-from, PGP, and X.509 authentication methods. UPDATES TO DOCUMENTATION ARIN shall update documentation as appropriate to explain the differences between mail-from, PGP, and X.509 authentication methods. KEY USE IN COMMUNICATION: ARIN shall accept PGP-signed communications, validate that a chain of trust not longer than five steps exists between the signing key and the ARIN hostmaster role key, compare the signing key to the identity of the authorized POCs for records referenced in the correspondence, and act appropriately based upon the validity or invalidity of the signature. ARIN shall PGP-sign all outgoing hostmaster email with the hostmaster role key, and staff members may optionally also sign mail with their own individual keys. ARIN shall accept PGP-encrypted communications which are encrypted using ARIN's hostmaster public key. ARIN shall not encrypt any outgoing communications except at the prior request of the recipient. Policy Rationale Rationale: Globally, PGP is the most commonly used cryptographic authentication method between RIRs and resource recipients who wish to protect their resource registration records against unauthorized modification. The PGP-auth authentication method is supported by RIPE, APNIC, and AfriNIC, LACNIC supports an equivalent mechanism, and PGP was historically supported by the InterNIC prior to ARIN's formation. By contrast, current ARIN resource recipients have only two options: "mail-from," which is trivially spoofed and should not be relied upon to protect important database objects, and X.509, which involves a rigorous and lengthy proof-of-identity process and compels use of a compatible MUA, a combination which has dissuaded essentially all of ARIN's constituents. Additionally, X.509's centralized failure mode is technically and ideologically repugnant to some members of the community, who should not be forced to choose between two evils. There isn't a lot of work to do here, and certainly nothing tricky. PGP is simple code, which was supported by the InterNIC, and which the other RIRs deployed without a second thought or complaint. If RIPE and APNIC have always done this, the InterNIC did it before ARIN was formed, and LACNIC and AfriNIC took the need for cryptographic security for granted as a part of their startup process, we see no reason why ARIN should be the only RIR to not offer this most basic of protections to its members. We need to get PGP support reinstated, so that our records can be protected against hijacking and vandalism, and so we won't look like idiots as the only one of the five regions that can't figure this stuff out. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:01:04 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:01:04 -0400 Subject: [ppml] Policy Proposal 2007-3 - Last Call Message-ID: <462FB380.4040606@arin.net> Policy Proposal 2007-3 Documentation of the X.509 Authentication Method The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_3.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-3 Documentation of the X.509 Authentication Method Policy statement Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 12.3 X.509 This section intentionally left blank. ADDITION TO THE NRPM 12.3 X.509 ARIN accepts X.509-signed transactions as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 12 to the NRPM. Section 12 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the X.509 authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:01:18 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:01:18 -0400 Subject: [ppml] Policy Proposal 2006-7 - To Be Revised Message-ID: <462FB38E.6000003@arin.net> Policy Proposal 2006-7 Changes to IPv6 initial allocation criteria The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that while there is not community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The AC will work with the author of the proposal to make the community suggested revisions and return the proposal to the PPML for further discussion. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2006_7.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2006-7 Changes to IPv6 initial allocation criteria Proposal type: Insert a new additional line item e. to 6.5.1.1 of NRPM Policy term: permanent Policy statement: New organizations need a policy that allows them to apply for IPv6 address space. To provide this we need to insert a new additional line item to 6.5.1.1. The new line item would be line 'e' as follows: e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPv6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Rationale: - New organizations who do not want to use IPv4 at all and start off using IPv6 addresses only, need a policy that gives them permission to do so. This is also valid for existing companies that may or may not have assigned IPv4 addresses and now want to start offering IPv6 services. These organizations may also wish to request IPv4 at the same time. - One year is given as the sufficient time frame to actually implement usage of the IPv6 address space and reveal if the 'said organization' is truly using the IPv6 space granted. -Every means of documentation that can reveal 'true intent of use' is not listed as this can be a very long list and should be left to the discretion of the RIR staff. -An ISP or LIR may decide to assign a different prefix size than /48. For example, a cellular operator may use /64. -ASN is not required because as long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. - Organization in this is defined as a Corporation, ISP, LLC et al. In SUMMARY if this policy is implemented the change to the NRPM would read as follows: 6.5.1.1 Initial allocation criteria To qualify for an initial allocation of IPV6 address space, an organization must: a be a LIR; b. not be an end site; c. plan to provide IPV6 connectivity to which it will assign IPV6 address space, by advertising that connectivity through its single aggregated address allocation; d. be an existing, known ISP in the ARIN region or have a plan for making at least 200/48 assignments to other organizations within five years. e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPV6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:01:29 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:01:29 -0400 Subject: [ppml] Policy Proposal 2007-4 - Last Call Message-ID: <462FB399.5030105@arin.net> Policy Proposal 2007-4 Changes to IPv6 policy - removal of "interim" consideration The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_4.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-4 Changes to IPv6 policy - removal of "interim" consideration Proposal type: delete Policy term: permanent Policy statement: Delete following text at section 6.1.1 of NRPM: "This policy is considered to be an interim policy. It will be reviewed in the future, subject to greater experience in the administration of IPv6." Rationale: The actual text suggest that it is an interim policy, however it is not longer the case. It is clear that any policy is always subjected to changes, however other policies don't have such text. It may be even considered as a negative "message" for IPv6 deployment, especially because the possible "reading" as "not enough experience and this is going to be changed, better wait", which is not a real situation. No financial/liability implications for the community and ARIN are foreseen. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:01:39 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:01:39 -0400 Subject: [ppml] Policy Proposal 2007-2 - Last Call Message-ID: <462FB3A3.9020902@arin.net> Policy Proposal 2007-2 Documentation of the Mail-From Authentication Method The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_2.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-2 Documentation of the Mail-From Authentication Method Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 12.1 Mail-From This section intentionally left blank. ADDITION TO THE NRPM 12.1 Mail-From Mail-From is the default authentication method by which registration records are protected from vandalism. If a registrant fails to designate a more secure method, any subsequent email which bears the sender address of an authorized Point of Contact may be deemed authentic with regard to the registrant's records. Since it is trivial to forge a sender address, Mail-From should not be regarded as secure. Use of Mail-From authentication is not recommended to any registrant who has the means to implement either of the more secure cryptographic authentication methods. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 12 to the NRPM. Section 12 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the mail-from authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:01:48 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:01:48 -0400 Subject: [ppml] Policy Proposal 2007-5 - Abandoned Message-ID: <462FB3AC.5090306@arin.net> Policy Proposal 2007-5 Changes to IPv6 policy - removal of "multiple /48" justification The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is not community consensus in favor of the proposal and abandoned it. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html In order for this proposal to be further considered the author must use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 23:59, Eastern Time, 2 May 2007. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_5.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-5 Changes to IPv6 policy - removal of "multiple /48" justification Proposal type: delete Policy term: permanent Policy statement: Delete section 6.5.4.2 of NRPM. Rationale: The current text requires the LIR to justify to the RIR/NIR when assigning multiple /48s to a single end site. It seems that the reason for this requirement is the lack of experience, which seems unreasonable after a few years this policy has been implemented, even if may not have been specific cases which used this policy section. It seems useless, now that there is already deployment experience, to require a justification from the LIR to ARIN for assigning multiple /48s (or a shorter prefix, such as for example a /47). It is up to the LIR to require the justification to its own customers and decide according to it. The LIR will be already responsible to justify to ARIN the usage of any allocated block(s) when requesting for more, and this will already implicate an implicit justification of this kind of assignments. With this policy change, both ARIN and LIR staff will save resources in a justification, which seems unnecessary and should be completely on the hands of the LIR itself. No financial/liability implications for the community and ARIN are foreseen. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:01:56 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:01:56 -0400 Subject: [ppml] Policy Proposal 2007-6 - Abandoned Message-ID: <462FB3B4.3030609@arin.net> Policy Proposal 2007-6 IPv4 PI minimum size change The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is not community consensus in favor of the proposal and abandoned it. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html In order for this proposal to be further considered the author must use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 23:59, Eastern Time, 2 May 2007. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_6.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-6 IPv4 PI minimum size change Proposal type: modify Policy term: permanent Policy statement: In section 4.3.2.2 of the NRPM, change all occurences of "/22" to "/24". (That is, replace the existing 4.3.2.2 with this text: For end-users who demonstrate an intent to announce the requested space in a multihomed fashion, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose.) Remove references to IPv4 in section 4.4, as they are no longer relevant. Section 4.4 could be moved, at the discretion of the NRPM editors, to somewhere in section 6, for clarity. Rationale: The rationale for moving the allocation "edge" for IPv4 PI space to /24 has three fundamental points: routing slot consumption would be unchanged, it reflects widespread routing practices, and it discourages waste. While experiments indicate that a few ISPs still try to filter at the /22 boundary, I have been repeatedly told that most don't filter anything shorter than a /24. While routing policy and allocation policies don't need to necessarily match, it is not unreasonable to have them in alignment. In addition, by keeping the PI allocation size for multi-homed organizations at /22, organizations seeking PI space that don't meet the requirements may be encouraged to exaggerate their address usage. This is something that should clearly not be encouraged. On the topic of routing slots, I would like to note that any org qualifying under the PI policies in 4.3.2.2 would also qualify for PA space, and would likely have an interest in multi-homing regardless of the usage of PA vs. PI space. In either instance, a routing slot is consumed by a /24. This policy change should therefore have minimal, if any, impact on the size of the global routing table. It merely gives organizations more options at a slightly smaller network size. Remember that for consideration under 4.3.2.2, an organiztion *must* be multi-homed. On a side note, it's tempting to remove the restriction entirely. If an organization only qualifies for a /28 (for example), they could receive an allocation of that size. Market forces would decide if that /28 was worth a routing slot. If the /28 contained my personal website, I suspect it would not be routable. If that /28 contained Microsoft Update, I suspect it would. In the interest of operational sanity and simplicity, I am not making a proposal to remove the restriction. (Note that section 4.1.1 explicitly notes that PI addresses are not guaranteed to be globally routable.) There is fundamental conflict between the urge for aggregation and the desire for conservation. The latter would prefer that organizations not have any excess space, while the former would prefer that fewer networks exist in the DFZ, regardless of wastage. Since the DFZ already permits deaggregation to /24, the conservation urge should be allowed to push to that edge. As noted in 4.1.5, "determination of IP address allocation size is the responsibility of ARIN." This proposal simply allows the community to request appropriately sized blocks, and ARIN to allocate prefixes of a size that is commensurate with established need. Timetable for implementation: immediate From info at arin.net Wed Apr 25 16:02:05 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:02:05 -0400 Subject: [ppml] Policy Proposal 2007-7 - Last Call Message-ID: <462FB3BD.8060806@arin.net> Policy Proposal 2007-7 Creation of Policy for Subsequent End-User IP Requests/Assignments The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The AC edited the last sentence; they changed the NRPM section reference from "...policies 4.3.2, and 4.3.3." to "...the policies found in Section 4.3 of the NRPM." The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_7.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-7 Creation of Policy for Subsequent End-User IP Requests/Assignments Proposal type: New Policy term: Permanent Policy statement: 4.3.6 Additional Assignments In order to justify an additional assignment, end-users must have efficiently utilized at least 80% of all previous assignments, and must provide ARIN with utilization details. The prefix size for an additional assignment is determined by applying the policies found in Section 4.3 of the NRPM. Rationale: There are no published criteria for additional assignment requests from end-user networks. NRPM 4.3 seems to only cover initial assignments. NRPM 4.3.3 states, in part, "Requesters must show exactly how previous address assignments have been utilized and must provide appropriate details to verify their one-year growth projection." Unfortunately, the above text does not specify any metrics for ARIN staff to apply when determining if an additional assignment is justified. Though most end-users only get one assignment, some end-users request a 2nd or 3rd or Nth assignment. Currently, the ARIN staff applies what they perceive to be "efficient utilization" criteria; for instance, the end-user must have utilized at least 80% of last assignment and must provide ARIN with utilization details. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:02:14 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:02:14 -0400 Subject: [ppml] Policy Proposal 2007-8 - Last Call Message-ID: <462FB3C6.8020205@arin.net> Policy Proposal 2007-8 Transfer Policy Clarifications The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The AC edited one instance of "address space" to "number resources." The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_8.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-8 Transfer Policy Clarifications Proposal type: Modify Policy term: Permanent Policy statement: That Section 8 of the NRPM is replaced as follows: 8. Transfers 8.1. Transfers 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. Transfer Requirements ARIN will consider requests for the transfer of number resources only 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. 8.3. Documentation 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 resources 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: o Host counts o Subnet masking o Network diagrams o Reassignments to customers Policy Rationale Staff analysis and community comments have a problem with the inconsistent use of the terms "ASN" and "IP Address" in this section which leads to confusion on which resources can be transferred. The entire section now utilizes the term "number resources" to clarify what would appear to be the original intent. A section regarding the handling of customer networks outside ARIN's geographic region has been removed to reflect the actual current procedure utilized that was developed in conjunction with the ERX transfer project. The last section of old text has been removed as it does not appear to be so much policy as guidance. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:02:23 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:02:23 -0400 Subject: [ppml] Policy Proposal 2007-9 - Last Call Message-ID: <462FB3CF.8000401@arin.net> Policy Proposal 2007-9 Modernization of ISP Immediate Need Policy The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_9.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-9 Modernization of ISP Immediate Need Policy Proposal type: modify Policy term: permanent Policy statement: Modify NRPM 4.2.1.6 to read: If an ISP has an immediate need for address space, and can provide justification to show that the address space will be utilized within 30 days of the request, ARIN may issue a block of address space, not larger than a /16 nor smaller than ARIN's customary minimum allocation, to that organization. These cases are exceptional. Current text of 4.2.1.6: If an ISP has an immediate need for address space, i.e., the need exists the day of the request, ARIN may issue a /20 if the organization, such as a new company, shows justification. However, these cases are exceptional. Rationale: ARIN staff and ARIN members have identified a few long-standing problems with the Immediate Need policy. This policy proposal attempts to address the following concerns: * The Immediate Need policy only allows ISPs to qualify for a /20 worth of space, when a larger size block may be necessary to provide proper coverage for the proposed project. An example justifying larger space is an MSOs for which a /20 is insufficient to put an address block larger than a /29 or /30 on each CMTS in a metropolitan area). * Conversely, this policy was written before the current multi-homed policy (which allows allocations of /21s and /22s). The Immediate Need policy should allow assignment of smaller blocks of space if those are justified. * The example used in the Immediate Need policy gives the impression that an immediate need must exist the day of the request. This seems both unfair and unreasonable and should probably be changed to reflect a realistic timeframe. Concerns expressed about the Immediate Need Policy but NOT addressed by this policy proposal (but addressed in a subsequent policy proposal): * The policy as written allows ARIN to issue a /20 to an ISP only. However, section 4.3.4. "Additional Considerations" of the End User Policy in the NRPM states that "End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4].". In order to be consistent, the Immediate Need policy language should be changed to reflect the fact that both ISPs and end-users can qualify under this policy. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:02:34 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:02:34 -0400 Subject: [ppml] Policy Proposal 2007-11 - Last Call Message-ID: <462FB3DA.8000001@arin.net> Policy Proposal 2007-11 Refinement of ISP Initial Allocation Policy The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_11.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-11 Refinement of ISP Initial Allocation Policy Policy statement Proposal type: modify Policy term: permanent Policy statement: In NRPM 4.2.4.3 (Initial Allocations to ISPs Policy), strike the following sentence: "When completing Section 7 of the ARIN ISP Network Request Template, please keep this in mind" Rationale: Instructions on filling out templates properly belong in the instructions attached to the template, not as part of a policy statement. This reminder makes reference to an obsolete template and section. ARIN released new templates in August 2006 and changed template names, field numbers, and sections which made both of these references obsolete. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:02:43 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:02:43 -0400 Subject: [ppml] Policy Proposal 2007-10 - Abandoned Message-ID: <462FB3E3.4090704@arin.net> Policy Proposal 2007-10 End Site Immediate Need Policy The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is not community consensus in favor of the proposal and abandoned it. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The AC felt that a fresh new start would be best to address concerns put forward on the mailing list and at the microphone. In order for this proposal to be further considered the author must use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 23:59, Eastern Time, 2 May 2007. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_10.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-10 End Site Immediate Need Policy Proposal type: new Policy term: permanent Policy statement: Create new section in NRPM 4.3.6. to mirror the intent of 4.2.1.6, but modified for end sites. If pending proposal "Modernization of ISP Immediate Need Policy" is ratified, this new section will read: 4.3.6 Immediate Need: If an end-user has an immediate need for address space, and can provide justification to show that the address space will be utilized within 30 days of the request, ARIN may issue a block of address space, not larger than a /16 nor smaller than ARIN's customary minimum allocation, to that organization. These cases are exceptional. In the absence of ratification of ""Modernization of ISP Immediate Need Policy", this proposal is to add section 4.3.6 with a modification of the current text of 4.2.1.6 to make it apply to end-users: 4.3.6 Immediate Need: If an end-user has an immediate need for address space, i.e., the need exists the day of the request, ARIN may issue a /20 if the organization, such as a new company, shows justification. However, these cases are exceptional. Rationale: ARIN staff has expressed the concern that the current policy is self-contradictory, in one place stating that the Immediate Need Policy applies to ISPs, and in another place stating that end users can qualify under it. The communication received was: * The policy as written allows ARIN to issue a /20 to an ISP only. However, section 4.3.4. "Additional Considerations" of the End User Policy in the NRPM states that "End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4].". In order to be consistent, the Immediate Need policy language should be changed to reflect the fact that both ISPs and end-users can qualify under this policy. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:02:52 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:02:52 -0400 Subject: [ppml] Policy Proposal 2007-12 - Abandoned Message-ID: <462FB3EC.9060303@arin.net> Policy Proposal 2007-12 IPv4 Countdown Policy Proposal The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is not community consensus in favor of the proposal and abandoned it. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The AC noted that this subject still needs to be looked at for other possible policy creation. In order for this proposal to be further considered the author must use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 23:59, Eastern Time, 2 May 2007. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_12.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-12 IPv4 Countdown Policy Proposal Proposal type: new Policy term: renewable Policy statement: - Set the date for termination of (IPv4) allocations and the date of announcement Set the date to terminate allocations as a general rule, and announce it a certain period in advance. Define the date of announcement as "A-date" and the date to terminate allocations as "T-date". The two dates will be set as follows: A-date (Date of Announcement): - The day in which the IANA pool becomes less than 30*/8 - RIRs must announce "T-date" on this day, which is defined later (*) There will be no changes in the policy on A-date T-date(Date of Termination): - Exactly two years after A-date - 10*/8 blocks should remain at T-date, and defined as two years after A-date, based on the current pace of allocations - It is however possible to move T-date forward at the point where address consumpution exceeds the projections during the course of two years (*) new allocations/assignments from RIRs should terminate on T-date as a general rule. Allocations or assignments to "critical infrastructure" after T-date should be defined by a separate policy. Rationale: 1. Introduction The exhaustion of IPv4 address is approaching round the corner. Geoff Huston's latest projection at Potaroo (as of January 6, 2007) (http://www.potaroo.net/tools/ipv4/) draws the date of IANA pool exhaustion as 31st May 2011, and that of RIR pool as 14th July 2012. Tony Hain projects similar dates based on a different algorithm of his own. From these data, we may observe that if that the current allocation trend continues, the exhaustion of IPv4 address space is expected to take place as early as within the next five years. ICANN/IANA and RIRs must co-ordinate with stakeholders to achieve smooth termination of IPv4 address space as the Internet bodies responsible for stable management and distribution of IP number resources. This proposal provides some ideas as well as concrete examples of the policy that helps IPv4 allocations come to an end with "the minimum confusion" and in "as fair manner as possible". "Five years at the earliest" is not too far in the future for the exhaustion of IPv4 address space. Assuming the minimum of one year is required for sufficient policy discussions with this proposal as a start, and two years for preparation and transfer by LIRs, we need to start the discussions right at this time. 2. Summary of current problems Despite the fact that several projections are made on IPv4 address to run out as early as within the next few years, no discussions are taking place on any of the RIR's policy fora. (we have submitted the same proposal to APNIC on January 2007) This section lists possible problems if no policies are defined to prepare for the terminal period of allocations. 2-1. LIR LIRs currently do not consider IPv4 address exhaustion as an imminent issue in the first place. It is possible that they will finally realize the situation only when impacts of the exhaustion becomes visible as a practical matter, and lead to confusions such as re-addressing their network or making subsequent requests at the last minute in within a limited time frame. There could also be cases where allocations blocks cannot be allocated to some of the LIRs even though requests are submitted on the same day. Moreover, although it would be necessary for LIRs to announce to their customers that IPv4 address space will not be available for assignments eventually, it is difficult to plan this timing without clear policy for the last phase of allocations. As new IPv4 address allocations space will no longer be available, LIRs have no choice but to build networks based on IPv6. However, there are risks of trouble if preparations are made from that point in time, as it will lead to premature actions even if some time can be bought by re-addressing and subsequent allocations. Lastly, using up all available IPv4 address space will disable assignments to services inevitable for co-existence of IPv4 and IPv6 networks, such as the translator service between the two networks, which it may create situation where transfer to IPv6 network will not even be possible. 2-2. RIR/NIR It is likely that smooth allocations by RIRs/NIRs will be hindered by rush of inquiries during the terminal phase of allocations. 2-3. End users End users generally receive address assignments from ISPs accompanied with Internet connection service. If an ISP no longer has IPv4 address space available, nor unable to provide IPv6 service, end users will not be able to receive services from that ISP. Moreover, if the terminal date of allocations remains ambiguous, it may leave end users behind to prepare for IPv6 ready network. 3. Benefits There will be the following benefits by implementing the policy for IPv4 address exhaustion as proposed on this paper. 3-1. LIR LIRs will be able to consciously plan their addressing within their networks if the final date of allocations is clearly demonstrated. Keeping a certain amount of unallocated address blocks enables allocations/assignments for "critical infrastructure" after the termination of regular allocations, which will be explained later section in more details. 3-2. RIR/NIR Announcing the date of terminating allocations in advance and ensuring that all allocations before this date will be made according to the policy at the time enables RIRs/NIRs to make the last allocation without confusions and avoids causing feelings of unfairness among LIRs and end users. In addition, consistent policy applied to all RIRs removes bias towards certain region as well as inter-regional unfairness. The period which IPv6 support is completed becomes clear, therefore, RIRs/NIRs can prepare for this. 3-3. End user As this proposal enables LIRs to prepare for the terminal period of allocations in advance, it reduces the risk of delays/ suspensions of assignments from LIRs to enduers, and end users will be able to continuously receive services from LIRs. As in the case of LIRs, end users will be able to prepare for IPv6 support by the date of allocation termination is clarified. In addition, IPv6 connectivity as well as IPv4 address required during the allocation termination period will be smoothly secured by LIRs preparing for such period. As listed above, there will be important, notable benefits for stakeholders as a result of this policy. It is therefore necessary to take the following actions to achieve a smooth transfer to IPv6 and prevent causing instability in the Internet as well as; - start discussions on allocation scheme during the exhaustion period, - indicate a roadmap to exhaustion after raising awareness on the issue, and - allow enough time for LIRs to plan timing of addressing of their networks, submit allocation requests, and consider how to switch to IPv6. 4. Proposal principles As the first step to discuss IPv4 exhaustion planning, we would like to have an agreement(consensus) on the following four principles. -------------------------------------------------------------------- (1) Global synchronization: All five RIRs will proceed at the same time for measures on IPv4 address exhaustion. (2) Some Blocks to be left: Keep a few /8 stocks instead of distributing all. (3) Keeping current practices until the last moment : Maintain the current policy until the last allocation. (4) Separate discussions on "Recycle" issue : Recovery of unused address space should be discussed separately. -------------------------------------------------------------------- (1) Global synchronization: All RIRs must proceed at the same time to take measures for IPv4 address exhaustion. This is important not only for ensuring fairness for LIRs across the regions, but alsot to prevent confusions such as attempts to receive allocations from an RIR outside their region. The five RIRs should facilitate bottom-up discussions, which should be well coordinated under the leaderships of ICANN ASO and NRO. (2) Some blocks to be left: It is not practical to consider that IPv4 address blocks can be allocated to the last piece. It is expected to cause confusions if one party can receive an allocation while the other has to give up, just with a touch of a difference. The best solution to avoid such confusion is to set in advance, a date in which one is able to receive an allocation if requests are submitted before this timeline. Furthermore, there are few cases where allocations or assignments of IPv4 address space become absolutely necessary in the future. For example, requirements to start a translator service between IPv4 and IPv6 networks should be supported, and there may be some requirements in the future that are beyond our imagination at this current moment. As such, a date to stop allocations under the current policy should be set/defined so that certain number of IPv4 address blocks will be kept as stocks instead of allocating all blocks without remains. (3) Maintaining current practices until the last moment : Allocations should be made based on the current policy until the time to terminate allocations. As the IPv4 Internet has now developed into a social infrastructure supporting large number of businesses, making large changes in the current policy towards conservation within the next one or two years will lead to large-scale confusions, and difficult in the reality. (4) Separate discussion from "Recycle" issue Recovering unused allocated/assigned address blocks is an important measure, and in fact, it has already be discussed and implemented in each RIR regions. This issue, however should be considered separately from this proposal as recovery of a few /8 blocks extends the lifetime of IPv4 for less than one year while efforts for the recovery is expected to require substantial time. 5. Rationale for "A-date" & "T-date" A-date is set in order to: - Allow some grace period and period for networks to be IPv6 ready until the termination of allocations. - Prevent unfairness among LIRs by clarifying the date, such as not being able to receive allocations by a small difference in timing. The rationale for setting A-date as "when IANA pool becomes less than 30*/8" is as follows: The rate of allocations from IANA to RIRs after 2000 is as follows. 2000 : 4*/8 2001 : 6*/8 2002 : 4*/8 2003 : 5*/8 2004 : 9*/8 2005 : 13*/8 2006 : 10*/8 Approximately 10*/8 has been allocated annually after 2003, and the consumption is likely to accelerate with rise of the last minute demands. As it is better to keep minimum stocks of address pool at IANA, 30*/8 is set as the threshold value, and allocations should be terminated two years after it reaches the value, which ensures that IANA/RIRs secure the address space for allocations/assignments to critical infrastructure. 6. Effect on RIR members RIR members are expected to concretely grasp the termination date of allocations and take actions within their organization to prepare for the event. Timetable for implementation: Immediate after all 5 RIRs ratified this policy. From JOHN at egh.com Wed Apr 25 17:28:37 2007 From: JOHN at egh.com (John Santos) Date: Wed, 25 Apr 2007 17:28:37 -0400 Subject: [ppml] Buying time... In-Reply-To: <048d01c78763$5dd54b00$197fe100$@net> Message-ID: <1070425170914.592A-100000@Ives.egh.com> On Wed, 25 Apr 2007, Tony Hain wrote: > Ted Mittelstaedt wrote: > > >> ....snip [snip] > > >> If the rest of us "lethargic" people > > >> want to correct past allocation mistakes and thereby push forward the > > >> IPv4 > > >> runout date in advance of what it is projected to be, then I don't > > see > > >> why > > >> anyone can make any reasonable objection to that. > > > > > >There were no allocation mistakes as such. Applying current technology > > and > > >policy to historical events is not a useful exercise. > > > > Well, what exactly do you think that the invention of IPv6 -is-? Seems > > to > > me nothing more than the application of current technology to a > > historical > > event - the invention of IPv4. > > > > IPv4 isn't big enough, so we solved it by inventing IPv6. > > > > IPv4 isn't being fairly allocated so we solve it by going back to the > > people > > with IPv4 they aren't using and taking it back. If the IPv4 runout date > > gets advanced, well then happy side effect for some people, eh? > > You claim to be concerned about lawsuits, but are completely oblivious to > the problem that there is no consistent definition of 'using'. An > organization that does not announce a /8 to public providers could well be > announcing it to others to keep from having overlapping 1918 between a large > private group, or because some set of the group has a public presence and > needs to keep the routing sorted out. That's exactly the situation I'm in with my little old pre-ARIN /24. Where "large" is defined as "4" entities, mostly competitors of each other, and some or all of whom may have similar arrangements with many other entities, some or all of which are compititors with us. The fact that most or all of the involved entities are competitors means none of them want to make changes at their own expense that make things easier for the others, an real life example of the prisoners dilemma. This is why it is necessary to have a neutral 3rd party, like ARIN, administer the addresses, even though they aren't, for the most part, public. Especially when all the entities concerned already have ARIN or pre-ARIN address blocks assigned to them. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From drc at virtualized.org Wed Apr 25 18:54:48 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 25 Apr 2007 15:54:48 -0700 Subject: [ppml] 240/4 In-Reply-To: References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net><026d01c786a3$30313170$90939450$@net> Message-ID: Michel, On Apr 24, 2007, at 9:49 PM, Michel Py wrote: >> The cost of redesignating the class E address space seems very low, > This is exaggerated; moderately low is the best you can hope; there > are > gazillions of lines of code that needs to be patched. Does not happen > overnight. Err, no. The cost of redesignating class E space is the cost of writing an RFC, IANA editing a file, and IANA publishing that file on IANA's web site. While the first bit may cost a bit of stomach lining and sanity, I don't think anyone can call the cost anything but very low. The cost of utilizing class E space will likely be significantly higher. However, if you judge the cost of utilization high, don't use it. That is, "Doctor, it hurts when I do this..." Rgds, -drc From bicknell at ufp.org Wed Apr 25 19:31:21 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 25 Apr 2007 19:31:21 -0400 Subject: [ppml] 240/4 In-Reply-To: <026d01c786a3$30313170$90939450$@net> References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net> <026d01c786a3$30313170$90939450$@net> Message-ID: <20070425233121.GA36485@ussenterprise.ufp.org> In a message written on Tue, Apr 24, 2007 at 12:03:04PM -0700, Tony Hain wrote: > Even if the vendors implemented a change and shipped it within 18 months (an > aggressive window), there is a very, very, very large installed base of > systems that can't/won't be upgraded to allow use of a block that was > 'undefined' at the time they were tested & shipped. By the time those work > their way out of the network, we will be long past the point where the 240/4 > block might have been useful. I would hope that anyone who interpreted "reserved" to mean "code so that it can never be used" has been fired from all vendors. That's a mistake we should never make again. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From alh-ietf at tndh.net Wed Apr 25 20:20:14 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 25 Apr 2007 17:20:14 -0700 Subject: [ppml] 240/4 In-Reply-To: <20070425233121.GA36485@ussenterprise.ufp.org> References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net> <026d01c786a3$30313170$90939450$@net> <20070425233121.GA36485@ussenterprise.ufp.org> Message-ID: <060c01c78798$a98876a0$fc9963e0$@net> Leo Bicknell wrote: > In a message written on Tue, Apr 24, 2007 at 12:03:04PM -0700, Tony Hain > wrote: > > Even if the vendors implemented a change and shipped it within 18 > > months (an aggressive window), there is a very, very, very large > > installed base of systems that can't/won't be upgraded to allow use of > > a block that was 'undefined' at the time they were tested & shipped. > > By the time those work their way out of the network, we will be long > > past the point where the 240/4 block might have been useful. > > I would hope that anyone who interpreted "reserved" to mean "code so > that it can never be used" has been fired from all vendors. > That's a mistake we should never make again. > Reserved does not mean the same thing in all parts of the IANA space. You appear to assume the 'right thing' to do was to just make them respond like all the 'Reserved' space below 224. Why would a vendor assume that? The 224/4 block was 'special', and the RFC text says: " Note: No addresses are allowed with the four highest-order bits set to 1-1-1-1. These addresses, called "class E", are reserved. " If the vendors had ignored that and said 'despite 224/4 being special we will make the 240/4 block just like everything below'; then someone decided that 'googlecasting' (don't come after me if that is already trademarked - if not it's mine) needed an identifiable address block for special handling, everyone would be screaming about the 'incompetents' that ignored the RFC and built up an installed base that could not be changed to use that space according to the new definition. >From a vendor perspective there is no simple answer, so the 'right thing' to do is to believe that space will be defined later, and lacking another definition to test against just obey the RFC and disallow use of that block. If you want that status changed, write an RFC to define it differently. Just don't expect the installed base to conform to changes in definition. Tony From bicknell at ufp.org Wed Apr 25 23:04:12 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 25 Apr 2007 23:04:12 -0400 Subject: [ppml] 240/4 In-Reply-To: <060c01c78798$a98876a0$fc9963e0$@net> References: <462CAEF0.1040804@arin.net> <026601c786a0$52e5f500$f8b1df00$@net> <026d01c786a3$30313170$90939450$@net> <20070425233121.GA36485@ussenterprise.ufp.org> <060c01c78798$a98876a0$fc9963e0$@net> Message-ID: <20070426030412.GA46779@ussenterprise.ufp.org> In a message written on Wed, Apr 25, 2007 at 05:20:14PM -0700, Tony Hain wrote: > Reserved does not mean the same thing in all parts of the IANA space. You > appear to assume the 'right thing' to do was to just make them respond like > all the 'Reserved' space below 224. Why would a vendor assume that? The > 224/4 block was 'special', and the RFC text says: > " Note: No addresses are allowed with the four highest-order bits > set to 1-1-1-1. These addresses, called "class E", are reserved. " > >From a vendor perspective there is no simple answer, so the 'right thing' to > do is to believe that space will be defined later, and lacking another > definition to test against just obey the RFC and disallow use of that block. > If you want that status changed, write an RFC to define it differently. Just > don't expect the installed base to conform to changes in definition. First off, I believe any vendor for which the code chance was more than commenting out: if (ADDRESS_IS_CLASS_E(addr)) { warning(foo); /* alternatively error(foo) */ } Was exercising poor coding. The flag that has been thrown up is that the "class E assumption" is littered across code, and possibly committed to hardware. If either are true it's a case of amazingly poor software design. But I'll give the vendors a full pass on getting that wrong in revision 1.0. Back in 1986 that may have been a fine assumption, and I'll not penalize for that. However, even if a vendor made that mistake they should have seen the writing on the wall with CIDR. When they went through the code removing /all classful instances" "class e" space should have been one of them. Again, a warning or even an error would be fine, in a small number of places. I am appalled that vendors response to "we might want to use class e space" is anything other than "we'll have that fixed in the next release of code we put out". To have the response be "we aren't sure we can fix that for all platforms" or "it may take three years to get that change out" is amazing to me. Can the code really be that bad, or are the vendors just that lazy? Last but not least, I will submit any vendor hard coding /64 into their IPv6 code (or /56, or /48, etc) is being amazingly short sighted and stupid. Code classless, period. Put checks in the CLI, in one place, only if necessary. Be prepared to change later, because odds are, we won't get it right on the first try. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From william at elan.net Thu Apr 26 07:38:31 2007 From: william at elan.net (william(at)elan.net) Date: Thu, 26 Apr 2007 04:38:31 -0700 (PDT) Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: <462FB36F.50308@arin.net> References: <462FB36F.50308@arin.net> Message-ID: Is the proposal going in as-is or would the text be changed in some way? On Wed, 25 Apr 2007, Member Services wrote: > Policy Proposal 2007-1 > Reinstatement of PGP Authentication Method > > The ARIN Advisory Council (AC), acting under the provisions of the ARIN > Internet Resource Policy Evaluation Process (IRPEP), determined that > there is community consensus in favor of the proposal and moved it to > last call. The AC made this determination at their meeting at the > conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair > of the AC reported the results of the AC meeting during the Members > Meeting. The AC Chair's report can be found at: > http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html > > The policy proposal text is provided below and is also available at: > http://www.arin.net/policy/proposals/2007_1.html > > Comments are encouraged. All comments should be provided to > ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May > 2007. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ##*## > > > Policy Proposal 2007-1 > Reinstatement of PGP Authentication Method > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > ADDITION TO NRPM > > 12 Authentication Methods > > 12.1 Mail-From > This section intentionally left blank. > > 12.2 PGP > ARIN accepts PGP-signed email as authentic communication from authorized > Points of Contact. POCs may denote their records "crypt-auth," > subsequent to which unsigned communications shall not be deemed > authentic with regard to those records. > > 12.3 X.509 > This section intentionally left blank. > > UPDATES TO TEMPLATES > > ARIN shall update templates as necessary to identify and distinguish > between mail-from, PGP, and X.509 authentication methods. > > UPDATES TO DOCUMENTATION > > ARIN shall update documentation as appropriate to explain the > differences between mail-from, PGP, and X.509 authentication methods. > > KEY USE IN COMMUNICATION: > > ARIN shall accept PGP-signed communications, validate that a chain of > trust not longer than five steps exists between the signing key and the > ARIN hostmaster role key, compare the signing key to the identity of the > authorized POCs for records referenced in the correspondence, and act > appropriately based upon the validity or invalidity of the signature. > > ARIN shall PGP-sign all outgoing hostmaster email with the hostmaster > role key, and staff members may optionally also sign mail with their own > individual keys. > > ARIN shall accept PGP-encrypted communications which are encrypted using > ARIN's hostmaster public key. > > ARIN shall not encrypt any outgoing communications except at the prior > request of the recipient. > Policy Rationale > > Rationale: > > Globally, PGP is the most commonly used cryptographic authentication > method between RIRs and resource recipients who wish to protect their > resource registration records against unauthorized modification. The > PGP-auth authentication method is supported by RIPE, APNIC, and AfriNIC, > LACNIC supports an equivalent mechanism, and PGP was historically > supported by the InterNIC prior to ARIN's formation. By contrast, > current ARIN resource recipients have only two options: "mail-from," > which is trivially spoofed and should not be relied upon to protect > important database objects, and X.509, which involves a rigorous and > lengthy proof-of-identity process and compels use of a compatible MUA, a > combination which has dissuaded essentially all of ARIN's constituents. > Additionally, X.509's centralized failure mode is technically and > ideologically repugnant to some members of the community, who should not > be forced to choose between two evils. > > There isn't a lot of work to do here, and certainly nothing tricky. PGP > is simple code, which was supported by the InterNIC, and which the other > RIRs deployed without a second thought or complaint. If RIPE and APNIC > have always done this, the InterNIC did it before ARIN was formed, and > LACNIC and AfriNIC took the need for cryptographic security for granted > as a part of their startup process, we see no reason why ARIN should be > the only RIR to not offer this most basic of protections to its members. > > We need to get PGP support reinstated, so that our records can be > protected against hijacking and vandalism, and so we won't look like > idiots as the only one of the five regions that can't figure this stuff out. > > Timetable for implementation: Immediate > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From woody at pch.net Thu Apr 26 07:00:11 2007 From: woody at pch.net (Bill Woodcock) Date: Thu, 26 Apr 2007 04:00:11 -0700 (PDT) Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: References: <462FB36F.50308@arin.net> Message-ID: > Is the proposal going in as-is or would the text be changed in some way? The intention is to at the very least, make the staff-suggested clean-up with regard to removing the "crypt-auth" reference, and the prescriptive bit about the length of the chain-of-trust. That will probably happen next week. -Bill From randy at psg.com Thu Apr 26 07:05:29 2007 From: randy at psg.com (Randy Bush) Date: Thu, 26 Apr 2007 12:05:29 +0100 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: References: <462FB36F.50308@arin.net> Message-ID: <46308779.3040701@psg.com> if the trust chain is allowed at all, this proposal should die immediately. just because i signed that i believe that the holder of the private key for pgp id 0x8972C7C1 is the human we know as paul vixie does not mean i give him one iota of authority over my data or any other relationship with arin. randy From owen at delong.com Thu Apr 26 07:15:20 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 26 Apr 2007 04:15:20 -0700 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: <46308779.3040701@psg.com> References: <462FB36F.50308@arin.net> <46308779.3040701@psg.com> Message-ID: <708F88B7-ED80-42F7-8C79-377650C74031@delong.com> It was pretty clear that the trust chain is being used for AUTHENTICATION only. The AUTHORIZATION part comes from being a listed POC. Owen On Apr 26, 2007, at 4:05 AM, Randy Bush wrote: > if the trust chain is allowed at all, this proposal should die > immediately. > > just because i signed that i believe that the holder of the private > key for > pgp id 0x8972C7C1 is the human we know as paul vixie does not mean > i give > him one iota of authority over my data or any other relationship > with arin. > > randy > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From Ed.Lewis at neustar.biz Thu Apr 26 08:42:53 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 26 Apr 2007 08:42:53 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: References: Message-ID: At 14:03 -0700 4/22/07, Owen DeLong wrote: >Content-Type: multipart/signed; micalg=sha1; >boundary=Apple-Mail-35--747394378; > protocol="application/pkcs7-signature" > >According to Leslie, ARIN staff would like community input on the >definition of "Existing Known ISP" in the NRPM. > >I would propose that the following definition seems self-evident to me, >but, I would like to see what others here have to say: > >"An existing, known ISP is any ARIN Subscriber Organization who has >received an IPv4 allocation from ARIN or an ARIN predecessor which >now is an ARIN Subscriber Organization." At 8:51 -0400 4/23/07, Leo Bicknell wrote: >Perhaps simpler, clearer language would be: > > Any current resource holder who has a signed RSA with ARIN. Defining any "insert adjective here" ISP has risen many times in different contexts, particularly on the NANOG mail list. Each time the topic has been raised the effort stalls over a concern about creating a categorization that runs afoul of someone's legal issues with anti-trust, etc. (I am not pretending to understand the legal issue/red herring, I'm just mentioning it because it seems to be the end of the effort to categorize ISPs.) I like Owen's definition because it gets to the core of what is important to ARIN - the bar to joining the group is the same bar as it takes to get resources. There is no other secret handshake or ISO certification implied. And, for the purposes of ARIN policy, "known/established" to ARIN is what is important, not any other form of legitimacy. What's lacking in Leo's definition is that ARIN does have a different policy section for ISPs and for end-users. Both sign RSA's but the policy proposal that (if I recall correctly) prompting the need to define "existing known" does differentiate between ISPs and end-users. The intent is to draw a somewhat restrictive circle around the registrants for the purpose of making a definition. Defining the term does not mean that it is a policy, so I don't think it hurts to at least define this as tightly as we may need - and then worry whether the policy that uses the term does so with the right justification. I have in mind too that there were legal council comments encouraging the goal of having policy that does not differentiate between ISP and end-site, in general, does not classify registrants. But there are places in the policy where a distinction is useful to have. In summary - I think the start Owen has is on the right track - perhaps I would loosen it a bit and tighten it a bit by saying that it is any organization that currently has resources from ARIN and has (in the past emphasized) received number resources under a policy that it qualified it for as an ISP, maintained records, and has qualified at least once for additional resources. By resources, I mean IPv4 and IPv6 ranges, possibly AS numbers. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From michael.dillon at bt.com Thu Apr 26 09:30:07 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 26 Apr 2007 14:30:07 +0100 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: <46308779.3040701@psg.com> Message-ID: > if the trust chain is allowed at all, this proposal should > die immediately. > > just because i signed that i believe that the holder of the > private key for > pgp id 0x8972C7C1 is the human we know as paul vixie does not > mean i give > him one iota of authority over my data or any other > relationship with arin. I think you don't really understand how PGP-auth is supposed to work. ARIN will only use PGP to authenticate the communication transaction. This means that the chain of trust will only be used to authenticate that the PGP key used in the transaction is a valid PGP key for ARIN purposes. Any PGP key signed directly by ARIN is valid. Any PGP key signed by somebody whose key is signed directly by ARIN is also valid because ARIN will accept a chain of trust that is 5 steps away from ARIN. So by signing Paul's key you are giving him FULL AUTHORITY over his own data, not yours. If you sign keys with ARIN then ARIN will trust that any keys that you sign are authentic keys. You are not delegating any authority via the chain of trust, because it is a chain of *TRUST* not a chain of delegation. The only key that is valid for modifying your data is your own key. But, if you sign another person's key(person X), and person X has an ARIN contact record and person X tells ARIN their PGP key, then ARIN will trust that this is really person X because ARIN trusts you and you trust person X. In the absence of this chain of trust, person X would have to arrange a face to face meeting with an ARIN keyholder in order to have their PGP key signed by ARIN. Thank God we didn't try to put any of this stuff in the policy. It already has far too many unneccessary technical details and it is obvious that not all of the people who are involved in policymaking do not have a good grasp of security technology. It is unfortunate that we used the term "chain of trust" in the policy because googling for "PGP web-of-trust" leads to numerous explanations of this concept. --Michael Dillon From Ed.Lewis at neustar.biz Thu Apr 26 10:58:00 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 26 Apr 2007 10:58:00 -0400 Subject: [ppml] Policy Proposal 2007-8: Transfer Policy Clarifications In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A0272F8AB@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A0272F8AB@nyrofcs2ke2k01.corp.pvt> Message-ID: Perhaps it is a bit late to respond to this, but I didn't get to see mail until this morning. And I think that what I am about to say here is something I already expressed at the mic earlier in the week. The case I am concerned with is number resources "issued" without a registration service agreement in place, more concretely and colloquially described as legacy space or "space gotten from Postel." But I suppose that is a matter for another would-be policy proposal. At 18:29 -0400 4/22/07, Azinger, Marla wrote: >Ed and All- I'm a little behind getting my response out, sorry. I >think your concerns about wording should be looked at. Hopfully I'm >not missing some postings to this that already resolved your >concerns. If there are...just ignore this email. ;o) > >I worked on some rewrites of the text you are concerned about. I >thought it might be good to have some rewritten text suggestions put >out to everyone so that if we decide we dont like how it is >currrently written, we can already start looking at another way of >saying "what we mean". So here are my suggestions to the parts that >may need some rewriting. > >1. Current proposal verbage: >"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." > >Suggested Rewrite: >Number Resources are managed as a finite resource and not as a >commodity. Number resources are assigned or allocated 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 to be managed in accordance >with ARIN's Published Policies. > > >2. Current proposal verbage: >"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." > >Suggested Rewrite: >Under the circumstance of an organization closure where said >organization has Number Resources from ARIN, said organization must >notify ARIN to either return the Number Resources to ARIN or >transfer the Number Resources in accordance with ARIN Policy >(reference section 8.2 and 8.3). > > >Cheers! >Marla >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Edward Lewis >Sent: Monday, March 05, 2007 7:55 PM >To: ppml at arin.net >Cc: ed.lewis at neustar.biz >Subject: Re: [ppml] Policy Proposal 2007-8: Transfer Policy >Clarifications > > >At 12:15 -0500 3/2/07, Member Services wrote: > >>http://www.arin.net/policy/proposals/2007_8.html > >>Policy Proposal 2007-8: Transfer Policy Clarifications >> >>Author: Paul Andersen >> >>Proposal Version: 1.0 >> > >>It should be understood that number resources are not "sold" under ARIN >>administration. Rather, number resources are assigned to an organization > >What I find a bit confusing is the difference between the thought >that ARIN "leases" resources versus the thought that a company might >"sell" resources from one to another. > >(An off-shoot of this comes from the fee discussion in APNIC, where >resources whose registration is static see the per-year fees >decrease. This reflects the nature of the activity as that of >managing a registry and not as a "LAN-lord.") > >... >>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. > >What exactly does "going out of business" mean? A company can be >absorbed by another through a purchase and the brand name tossed away >while still maintaining the need for the resources. > >In a way I can see this saying the transfers can never happen, >meaning that if I buy someone's hosting service I may have to apply >for new addresses. Worse is the thought that I'd have to renumber if >I don't get the transfer of resources. > >I'm asking an obtuse question because the text doesn't say which >POC(s) is/are involved. What if the POC is a role account that >transfers with the rest of a once independent company? > >>8.2 Transfer Requirements >> >>ARIN will consider requests for the transfer of number resources only >>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: > >I pretty much agree with the intent of this proposal...it's the words >I am quibbling about in the previous section. > >>Rationale: >> >>Staff analysis and community comments have a problem with the >>inconsistent use of the terms "ASN" and "IP Address" in this section >>which leads to confusion on which resources can be transferred. The >>entire section now utilizes the term "number resources" to clarify what >>would appear to be the original intent. > >I have come across people that find the ARIN on-web flow-chart >confusing because AS numbers are not included in the prose. And I >have been told that the prose comes from the policy. So I'll add a >data point saying that this is in need or updating. > >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-571-434-5468 >NeuStar > >Sarcasm doesn't scale. >_______________________________________________ >PPML mailing list >PPML at arin.net >http://lists.arin.net/mailman/listinfo/ppml >_______________________________________________ >This message sent to you through the ARIN Public Policy Mailing List >(PPML at arin.net). >Manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/ppml -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From Ed.Lewis at neustar.biz Thu Apr 26 11:27:15 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 26 Apr 2007 11:27:15 -0400 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: <708F88B7-ED80-42F7-8C79-377650C74031@delong.com> References: <462FB36F.50308@arin.net> <46308779.3040701@psg.com> <708F88B7-ED80-42F7-8C79-377650C74031@delong.com> Message-ID: I thought I understood Randy's objection, but after a re-read I don't think I do. Still, I believe that any chain relying on non-ARIN (approved) trusted introductions is a bad idea. Let's say I get someone to sign a key for me with an identity of Owen DeLong. If ARIN accepts that someone as a trusted introducer, then how can ARIN distinguish between templates submitted by me signed with my Owen key and templates Owen genuinely submits? Authorization policy is undermined by weakness in the authentication method. By ARIN-approved, I mean either ARIN-only or some set of other established Internet organizations (like AfriNIC, IETF, etc.), or even some set of ARIN members that have a good track record in being trusted to introduce. The latter to me is a bit of a stretch. At 4:15 -0700 4/26/07, Owen DeLong wrote: >Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9--437058209; > protocol="application/pkcs7-signature" > >It was pretty clear that the trust chain is being used for AUTHENTICATION >only. The AUTHORIZATION part comes from being a listed POC. > >Owen > >On Apr 26, 2007, at 4:05 AM, Randy Bush wrote: > >> if the trust chain is allowed at all, this proposal should die immediately. >> >> just because i signed that i believe that the holder of the private key for >> pgp id 0x8972C7C1 is the human we know as paul vixie does not mean i give >> him one iota of authority over my data or any other relationship with arin. >> >> randy >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml > > > >Attachment converted: Macintosh HD:smime 297.p7s ( / ) (00309FB4) >_______________________________________________ >This message sent to you through the ARIN Public Policy Mailing List >(PPML at arin.net). >Manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/ppml -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From michael.dillon at bt.com Thu Apr 26 12:25:14 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 26 Apr 2007 17:25:14 +0100 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: Message-ID: > Let's say I get someone to sign a key for me with an identity of Owen > DeLong. If ARIN accepts that someone as a trusted introducer, then > how can ARIN distinguish between templates submitted by me signed > with my Owen key and templates Owen genuinely submits? On the surface, this sounds like a valid objection. In the absence of comment from a recognized and trusted voice in the security field, I can think of nothing to say that would alleviate your fears. This doesn't mean that I don't know the answer to your concern but it means that because security is a secondary area of expertise for me, I have no certificates, I don't speak at security conferences and I don't publish papers in the field of security. Therefore, from a policy point of view, I recommend that people should not trust any security advice that I give. In fact, I believe that there are very, very few PPML participants (maybe none) who have recognized security expertise. Therefore, such technical details of security SHOULD NOT BE IN POLICY!!! Language such as the following would be far superior to limiting the chain of trust to 5 steps: ARIN will publish guidelines describing how it makes use of PGP for authentication. These guidelines will be written in accordance with accepted industry standards for security and will be signed off by a recognized security expert before being implemented. The published guidelines will include a description of the conditions under which ARIN will accept a PGP key for authentication. After that, I would not be surprised to see the guidelines mention a chain of trust with 5 steps. I would not be surprised if ARIN technical staff get in a security consultant to review the entire authentication architecture. And I would not be surprised if the guidelines change so that it is no longer simply 5 steps in the chain of trust. Maybe it will end up being 3 steps with step 1 being ARIN staff, step 2 being an ARIN resource holder, and step 3 being Joe Bloe. Who knows? But these details do NOT belong in policy. And the detailed technical discussion does NOT belong on PPML. --Michael Dillon From dlw+arin at tellme.com Thu Apr 26 12:49:27 2007 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 26 Apr 2007 09:49:27 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <462FB3B4.3030609@arin.net> References: <462FB3B4.3030609@arin.net> Message-ID: <20070426164927.GN22289@shell01.corp.tellme.com> On Wed, Apr 25, 2007 at 04:01:56PM -0400, Member Services wrote: > Policy Proposal 2007-6 > IPv4 PI minimum size change > > The ARIN Advisory Council (AC), acting under the provisions of the ARIN > Internet Resource Policy Evaluation Process (IRPEP), determined that > there is not community consensus in favor of the proposal and abandoned > it. While I agree that there's not community consensus, I'm disappointed that the AC chose to ignore the half of the people in the room who voted in favor of this proposal by not choosing to work to revise the proposal. As the author, I agree that the proposal needs additional modification to be a viable part of existing policy. (Indeed, other parts of the PI policy may need work.) Still, there's fairly strong interest in doing something to make the PI policy a bit more level. (I also had someone express interest to me in modifying the PA minimum allocation level to /24 as well. If I do propose that, it will be a separate proposal from any new PI proposal.) Given that interest, I think a different choice by the AC might have been appropriate. -David From stephen at sprunk.org Thu Apr 26 12:56:20 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 26 Apr 2007 11:56:20 -0500 Subject: [ppml] Policy Proposal 2007-1 - Last Call References: <462FB36F.50308@arin.net><46308779.3040701@psg.com><708F88B7-ED80-42F7-8C79-377650C74031@delong.com> Message-ID: <00a501c78825$6c304a20$383816ac@atlanta.polycom.com> Thus spake "Edward Lewis" >I thought I understood Randy's objection, but after a re-read I don't > think I do. Still, I believe that any chain relying on non-ARIN > (approved) trusted introductions is a bad idea. > > Let's say I get someone to sign a key for me with an identity of > Owen DeLong. If ARIN accepts that someone as a trusted > introducer, then how can ARIN distinguish between templates > submitted by me signed with my Owen key and templates Owen > genuinely submits? > > Authorization policy is undermined by weakness in the > authentication method. All valid objections, and ones that counsel noted, but one must remember that MAIL-FROM authentication means that today anyone can send in an email template with Owen's From: address and it'll be considered "authentic". While I agree there's potential for fraud with PGP, pulling it off in practice is more difficult than what we have today and the proposal should not be rejected solely on those grounds. I do urge the AC to reduce the number of steps in the chain before moving this proposal forward. Five seems to be way too many; I'd be happiest with one, but I'd accept two or three. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From owen at delong.com Thu Apr 26 13:23:12 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 26 Apr 2007 10:23:12 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <20070426164927.GN22289@shell01.corp.tellme.com> References: <462FB3B4.3030609@arin.net> <20070426164927.GN22289@shell01.corp.tellme.com> Message-ID: <122024E6-4FAF-4287-B244-FB5DE72D3D72@delong.com> I agree. I get the strong impression that there is much more opposition to this idea on the AC than in the community. I agree there was not consensus, but, given the extremely close show-of-hands (19 for, 21 against) and the relatively small number of issues raised in opposition, I feel this policy should be worked on. Discussing it with some AC members on Wed. they felt the most likely path to success was to again introduce new policy proposal which takes the feedback from the room into account. I have introduced a general anti-fraud/reclamation policy which I think addresses most of the concerns expressed about this proposal (but does so in a broader and more generic context). I am happy to work with anyone who wishes to author a new version of this proposal. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From woody at pch.net Thu Apr 26 14:03:25 2007 From: woody at pch.net (=?UTF-8?B?QmlsbCBXb29kY29jaw==?=) Date: Thu, 26 Apr 2007 18:03:25 +0000 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: References: <462FB36F.50308@arin.net><46308779.3040701@psg.com><708F88B7-ED80-42F7-8C79-377650C74031@delong.com> Message-ID: <585613880-1177610803-cardhu_blackberry.rim.net-846946439-@bwe020-cell00.bisx.prod.on.blackberry> Ed: Ask yourself what it is that ARIN knows that uniquely identifies a POC. There may be many "Owen Delongs" in the world, but only one of them controls the owen at delong.com email account, and that's the identifier ARIN uses. No other, because nothing else that ARIN knows about is necessarily unique. Thus, in order to successfully spoof Owen's identity, you would need: 1) A private key identifying you as Owen Delong 2) A sufficiently convincing set of paths between the hostmaster key and your key to not arouse the suspicion of the hostmaster 3) The ability to intercept mail to owen at delong.com 4) The ability to prevent Owen himself from seeing the handshake email 5) The ability to keep Owen from suspecting that he's not receiving some of his mail Of course the coincidence of all of those conditions is possible, as this is a world of infinite possibility. But that's not interesting. What's interesting is that: 1) It's better than mail-from 2) It's good enough for the rest of the world 3) It passed unanimously. We don't live in a theoretically perfect world. Denying ourselves the basic tools which make the rest of the world a better place, merely because we're unhappy that we can't somehow magically leap-frog into a perfect world, doesn't buy us anything. -Bill Please excuse the brevity of this message; I typed it on my pager. I could be more loquacious, but then I'd crash my car. -----Original Message----- From: Edward Lewis Date: Thu, 26 Apr 2007 11:27:15 To:Owen DeLong Cc:Randy Bush , ppml at arin.net Subject: Re: [ppml] Policy Proposal 2007-1 - Last Call I thought I understood Randy's objection, but after a re-read I don't think I do. Still, I believe that any chain relying on non-ARIN (approved) trusted introductions is a bad idea. Let's say I get someone to sign a key for me with an identity of Owen DeLong. If ARIN accepts that someone as a trusted introducer, then how can ARIN distinguish between templates submitted by me signed with my Owen key and templates Owen genuinely submits? Authorization policy is undermined by weakness in the authentication method. By ARIN-approved, I mean either ARIN-only or some set of other established Internet organizations (like AfriNIC, IETF, etc.), or even some set of ARIN members that have a good track record in being trusted to introduce. The latter to me is a bit of a stretch. At 4:15 -0700 4/26/07, Owen DeLong wrote: >Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9--437058209; > protocol="application/pkcs7-signature" > >It was pretty clear that the trust chain is being used for AUTHENTICATION >only. The AUTHORIZATION part comes from being a listed POC. > >Owen > >On Apr 26, 2007, at 4:05 AM, Randy Bush wrote: > >> if the trust chain is allowed at all, this proposal should die immediately. >> >> just because i signed that i believe that the holder of the private key for >> pgp id 0x8972C7C1 is the human we know as paul vixie does not mean i give >> him one iota of authority over my data or any other relationship with arin. >> >> randy >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml > > > >Attachment converted: Macintosh HD:smime 297.p7s ( / ) (00309FB4) >_______________________________________________ >This message sent to you through the ARIN Public Policy Mailing List >(PPML at arin.net). >Manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/ppml -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From Ed.Lewis at neustar.biz Thu Apr 26 14:26:33 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 26 Apr 2007 14:26:33 -0400 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: <00a501c78825$6c304a20$383816ac@atlanta.polycom.com> References: <462FB36F.50308@arin.net> <46308779.3040701@psg.co m><708F88B7-ED80-42F7-8C79-377650C74031@delong.com> <00a501c78825$6c304a20$383816ac@atlanta.polycom.com> Message-ID: http://www.arin.net/policy/proposals/2007_1.html At 11:56 -0500 4/26/07, Stephen Sprunk wrote: >All valid objections, and ones that counsel noted, but one must remember that >MAIL-FROM authentication means that today anyone can send in an email >template with Owen's From: address and it'll be considered "authentic". While >I agree there's potential for fraud with PGP, pulling it off in practice is >more difficult than what we have today and the proposal should not be rejected >solely on those grounds. I have been reviewing the proposals as much as possible individually, meaning I try not to compare the merits of one versus the other. I haven't been trying to compare PGP to mail-from, but there is no doubt that any approach to security using PGP is better than relying on mail-from. I just haven't considered settling for a "step up" as the goal - not to argue, but to let you know my frame of reference. >I do urge the AC to reduce the number of steps in the chain before moving this >proposal forward. Five seems to be way too many; I'd be happiest with one, >but I'd accept two or three. Being that I am not a fan of PGP (I am not against it, but do not use it after my experience working with it about 8 years ago at a company that bought the rights to it from Zimmerman and then ditched the product before selling a copy), I would like to hear, from the proposal authors perhaps, why the number 5 is in the policy proposal. (When I say I am not a fan, take that as I am not someone who has full and accurate knowledge of the technology and isn't about to set down my other duties to go and study up on it. I am not against PGP, maybe I just don't understand some fine point.) BTW, I am sympathetic to Dillon's belief that this is too detailed for PPML, but, it is in the proposal and there really is no other venue to cover this within the ARIN umbrella of discussion fora. When I read the policy proposal 2007-1, my vision of five steps was from Pat Blow's keys signed by Menynty Encyunse in Elbonia, signed by the mythical $mail-troll, signed by someone that has legacy space but managed to have PGP keys signed by ARIN. Perhaps the vision of the authors would be more along the lines of "IP-admin-role-of-Bill's-Bait-n-Sushi-ISP" signed by "Bill's-Bait-n-Sushi-ISP" signed by ARIN. In the latter case, I can see a multi-step $word-of-trust being used, but not in the former case. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From Ed.Lewis at neustar.biz Thu Apr 26 14:48:50 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 26 Apr 2007 14:48:50 -0400 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: <585613880-1177610803-cardhu_blackberry.rim.net-846946439-@bwe020-cell00.b isx.prod.on.blackberry> References: <462FB36F.50308@arin.net> <46308779.3040701@psg.co m><708F88B7-ED80-42F7-8C79-377650C74031@delong.com> <585613880-1177610803-cardhu_blackberry.rim.net-846946439-@bwe020-cell00.b isx.prod.on.blackberry> Message-ID: At 18:03 +0000 4/26/07, =?UTF-8?B?QmlsbCBXb29kY29jaw==?= wrote: >1) It's better than mail-from Yes, but is that an important criteria? >2) It's good enough for the rest of the world Apparently... >3) It passed unanimously. I did support the proposal in the sense that we should have PGP available as an option. Now I am asking questions because I want to be sure ARIN implements a PGP authentication method that works and that what is in the proposal text gives me some hesitation. I would unquestionably support a policy that ARIN "do" PGP but I question a proposal that instructs staff to "do it in a way" that I don't understand. The unanimous straw poll in the room was a piece of data to be given to the AC to help them make their determination. When the poll was called, it wasn't clear if the poll was "yes, as written" or "yes, but hopefully with some guiding smart hands to make sure we do the policy right." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From woody at pch.net Thu Apr 26 14:56:16 2007 From: woody at pch.net (=?UTF-8?B?QmlsbCBXb29kY29jaw==?=) Date: Thu, 26 Apr 2007 18:56:16 +0000 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: References: <462FB36F.50308@arin.net><46308779.3040701@psg.com><708F88B7-ED80-42F7-8C79-377650C74031@delong.com><00a501c78825$6c304a20$383816ac@atlanta.polycom.com> Message-ID: <1484656390-1177613974-cardhu_blackberry.rim.net-1751478787-@bwe041-cell00.bisx.prod.on.blackberry> The number 5 _was_ in the proposal, but both that and the phrase "crypt-auth" were deemed unnecessary by staff, and the authors and AC agreed, so they won't be part of the final policy. Another issue that came up subsequent to the last published version of the proposal: Sandy Murphy brought up the issue of replay attacks (A swips to B, B somehow gets a copy of the signed message from A to ARIN, A unswips from B, B replays A's signed SWIP, re-taking the resource). Vixie pointed out that this is trivially addressed by maintaining a cache of hashes of already-accepted messages and implementing a full handshake or even human hostmaster intervention upon seeing the same hash a second time, and staff are now aware that a cache of that nature will need to be part of the implementation. I would point out that this is the public POLICY mailing list, and that the details of crypto implementation, should ARIN staff not just adopt wholesale one of the preexisting implementations, are probably best discussed with staff, rather than on this mailing list. -Bill Please excuse the brevity of this message; I typed it on my pager. I could be more loquacious, but then I'd crash my car. -----Original Message----- From: Edward Lewis Date: Thu, 26 Apr 2007 14:26:33 To:"Stephen Sprunk" Cc:ARIN PPML , Edward Lewis Subject: Re: [ppml] Policy Proposal 2007-1 - Last Call http://www.arin.net/policy/proposals/2007_1.html At 11:56 -0500 4/26/07, Stephen Sprunk wrote: >All valid objections, and ones that counsel noted, but one must remember that >MAIL-FROM authentication means that today anyone can send in an email >template with Owen's From: address and it'll be considered "authentic". While >I agree there's potential for fraud with PGP, pulling it off in practice is >more difficult than what we have today and the proposal should not be rejected >solely on those grounds. I have been reviewing the proposals as much as possible individually, meaning I try not to compare the merits of one versus the other. I haven't been trying to compare PGP to mail-from, but there is no doubt that any approach to security using PGP is better than relying on mail-from. I just haven't considered settling for a "step up" as the goal - not to argue, but to let you know my frame of reference. >I do urge the AC to reduce the number of steps in the chain before moving this >proposal forward. Five seems to be way too many; I'd be happiest with one, >but I'd accept two or three. Being that I am not a fan of PGP (I am not against it, but do not use it after my experience working with it about 8 years ago at a company that bought the rights to it from Zimmerman and then ditched the product before selling a copy), I would like to hear, from the proposal authors perhaps, why the number 5 is in the policy proposal. (When I say I am not a fan, take that as I am not someone who has full and accurate knowledge of the technology and isn't about to set down my other duties to go and study up on it. I am not against PGP, maybe I just don't understand some fine point.) BTW, I am sympathetic to Dillon's belief that this is too detailed for PPML, but, it is in the proposal and there really is no other venue to cover this within the ARIN umbrella of discussion fora. When I read the policy proposal 2007-1, my vision of five steps was from Pat Blow's keys signed by Menynty Encyunse in Elbonia, signed by the mythical $mail-troll, signed by someone that has legacy space but managed to have PGP keys signed by ARIN. Perhaps the vision of the authors would be more along the lines of "IP-admin-role-of-Bill's-Bait-n-Sushi-ISP" signed by "Bill's-Bait-n-Sushi-ISP" signed by ARIN. In the latter case, I can see a multi-step $word-of-trust being used, but not in the former case. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From dlw+arin at tellme.com Thu Apr 26 15:25:30 2007 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 26 Apr 2007 12:25:30 -0700 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: References: <585613880-1177610803-cardhu_blackberry.rim.net-846946439-@bwe020-cell00.bisx.prod.on.blackberry> Message-ID: <20070426192530.GT22289@shell01.corp.tellme.com> On Thu, Apr 26, 2007 at 02:48:50PM -0400, Edward Lewis wrote: > At 18:03 +0000 4/26/07, =?UTF-8?B?QmlsbCBXb29kY29jaw==?= wrote: > > >1) It's better than mail-from > > Yes, but is that an important criteria? Yes. It may be the key criterion, in fact. On the implementation question: despite my early diatribe, I trust the AC and BoT (both of which are filled by some really smart people) will do something to correct the issues raised, and that staff will implement something in conformance with the policy that Makes Sense. I look forward to when this is all available. -David From tony at lava.net Thu Apr 26 15:30:29 2007 From: tony at lava.net (Antonio Querubin) Date: Thu, 26 Apr 2007 09:30:29 -1000 (HST) Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: <46308779.3040701@psg.com> References: <462FB36F.50308@arin.net> <46308779.3040701@psg.com> Message-ID: On Thu, 26 Apr 2007, Randy Bush wrote: > if the trust chain is allowed at all, this proposal should die immediately. > > just because i signed that i believe that the holder of the private key for > pgp id 0x8972C7C1 is the human we know as paul vixie does not mean i give > him one iota of authority over my data or any other relationship with arin. I would hope ARIN staff are smart enough to know the difference between authentication of identity vs authorization to make changes and their internal procedures take these into account. From randy at psg.com Thu Apr 26 15:33:12 2007 From: randy at psg.com (Randy Bush) Date: Thu, 26 Apr 2007 20:33:12 +0100 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: References: <462FB36F.50308@arin.net> <46308779.3040701@psg.com> Message-ID: <4630FE78.80108@psg.com> >> just because i signed that i believe that the holder of the private key >> for pgp id 0x8972C7C1 is the human we know as paul vixie does not mean >> i give him one iota of authority over my data or any other relationship >> with arin. > I would hope ARIN staff are smart enough to know the difference between > authentication of identity vs authorization to make changes and their > internal procedures take these into account. i would love to hear your ideas on what possible internal procedures they might use to overcome this. and i am sure they would love to hear your ideas as well. randy From woody at pch.net Thu Apr 26 15:32:41 2007 From: woody at pch.net (=?UTF-8?B?QmlsbCBXb29kY29jaw==?=) Date: Thu, 26 Apr 2007 19:32:41 +0000 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: References: <462FB36F.50308@arin.net><46308779.3040701@psg.com><708F88B7-ED80-42F7-8C79-377650C74031@delong.com><585613880-1177610803-cardhu_blackberry.rim.net-846946439-@bwe020-cell00.bisx.prod.on.blackberry> Message-ID: <408361755-1177616160-cardhu_blackberry.rim.net-1570411433-@bwe002-cell00.bisx.prod.on.blackberry> No question. Guiding smart hands are always invaluable. -Bill Please excuse the brevity of this message; I typed it on my pager. I could be more loquacious, but then I'd crash my car. -----Original Message----- From: Edward Lewis Date: Thu, 26 Apr 2007 14:48:50 To:woody at pch.net Cc:"Ed Lewis" , ppml at arin.net Subject: Re: [ppml] Policy Proposal 2007-1 - Last Call At 18:03 +0000 4/26/07, =?UTF-8?B?QmlsbCBXb29kY29jaw==?= wrote: >1) It's better than mail-from Yes, but is that an important criteria? >2) It's good enough for the rest of the world Apparently... >3) It passed unanimously. I did support the proposal in the sense that we should have PGP available as an option. Now I am asking questions because I want to be sure ARIN implements a PGP authentication method that works and that what is in the proposal text gives me some hesitation. I would unquestionably support a policy that ARIN "do" PGP but I question a proposal that instructs staff to "do it in a way" that I don't understand. The unanimous straw poll in the room was a piece of data to be given to the AC to help them make their determination. When the poll was called, it wasn't clear if the poll was "yes, as written" or "yes, but hopefully with some guiding smart hands to make sure we do the policy right." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From Ed.Lewis at neustar.biz Thu Apr 26 15:41:37 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 26 Apr 2007 15:41:37 -0400 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: <1484656390-1177613974-cardhu_blackberry.rim.net-1751478787-@bwe041-cell00 .bisx.prod.on.blackberry> References: <462FB36F.50308@arin.net> <46308779.3040701@psg.co m><708F88B7-ED80-42F7-8C79-377650C74031@delong.com><00a501c78825$6c304a20$383816ac@atlanta.polycom.com> <1484656390-1177613974-cardhu_blackberry.rim.net-1751478787-@bwe041-cell00 .bisx.prod.on.blackberry> Message-ID: off-list... At 18:56 +0000 4/26/07, =?UTF-8?B?QmlsbCBXb29kY29jaw==?= wrote: >The number 5 _was_ in the proposal, but both that and the phrase "crypt-auth" >were deemed unnecessary by staff, and the authors and AC agreed, so they won't >be part of the final policy. Here's where the IRPEP gets confusing to me. The number 5 is in the last call message and it is still on the proposal version on the web site (URL given in my previous message and appears below). >I would point out that this is the public POLICY mailing list, and that the >details of crypto implementation, should ARIN staff not just adopt wholesale >one of the preexisting implementations, are probably best discussed with >staff, rather than on this mailing list. In the spirit of public policy review...shouldn't the last call cover what it is we want to last call? Does staff have permission to ignore parts of the policies? And considering that you are one of the authors...shouldn't the details have been revised out already? >-----Original Message----- >From: Edward Lewis >Date: Thu, 26 Apr 2007 14:26:33 >To:"Stephen Sprunk" >Cc:ARIN PPML , Edward Lewis >Subject: Re: [ppml] Policy Proposal 2007-1 - Last Call > >http://www.arin.net/policy/proposals/2007_1.html -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From woody at pch.net Thu Apr 26 15:48:24 2007 From: woody at pch.net (=?UTF-8?B?QmlsbCBXb29kY29jaw==?=) Date: Thu, 26 Apr 2007 19:48:24 +0000 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: References: <462FB36F.50308@arin.net><46308779.3040701@psg.com><708F88B7-ED80-42F7-8C79-377650C74031@delong.com><00a501c78825$6c304a20$383816ac@atlanta.polycom.com><1484656390-1177613974-cardhu_blackberry.rim.net-1751478787-@bwe041-cell00.bisx.prod.on.blackberry> Message-ID: <2047909650-1177617106-cardhu_blackberry.rim.net-1631400749-@bwe059-cell00.bisx.prod.on.blackberry> Well, not actually off-list, I guess. Speaking as someone who's gotten three hours of sleep a night since arriving at the meeting, I can authoritatively say that the reason no subsequent drafts have gotten out has nothing at all to do with process. :-) -Bill Please excuse the brevity of this message; I typed it on my pager. I could be more loquacious, but then I'd crash my car. -----Original Message----- From: Edward Lewis Date: Thu, 26 Apr 2007 15:41:37 To:woody at pch.net Cc:"Ed Lewis" , ARIN PPML Subject: Re: [ppml] Policy Proposal 2007-1 - Last Call off-list... At 18:56 +0000 4/26/07, =?UTF-8?B?QmlsbCBXb29kY29jaw==?= wrote: >The number 5 _was_ in the proposal, but both that and the phrase "crypt-auth" >were deemed unnecessary by staff, and the authors and AC agreed, so they won't >be part of the final policy. Here's where the IRPEP gets confusing to me. The number 5 is in the last call message and it is still on the proposal version on the web site (URL given in my previous message and appears below). >I would point out that this is the public POLICY mailing list, and that the >details of crypto implementation, should ARIN staff not just adopt wholesale >one of the preexisting implementations, are probably best discussed with >staff, rather than on this mailing list. In the spirit of public policy review...shouldn't the last call cover what it is we want to last call? Does staff have permission to ignore parts of the policies? And considering that you are one of the authors...shouldn't the details have been revised out already? >-----Original Message----- >From: Edward Lewis >Date: Thu, 26 Apr 2007 14:26:33 >To:"Stephen Sprunk" >Cc:ARIN PPML , Edward Lewis >Subject: Re: [ppml] Policy Proposal 2007-1 - Last Call > >http://www.arin.net/policy/proposals/2007_1.html -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From william at elan.net Thu Apr 26 16:58:29 2007 From: william at elan.net (william(at)elan.net) Date: Thu, 26 Apr 2007 13:58:29 -0700 (PDT) Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: <2047909650-1177617106-cardhu_blackberry.rim.net-1631400749-@bwe059-cell00.bisx.prod.on.blackberry> References: <462FB36F.50308@arin.net><46308779.3040701@psg.com><708F88B7-ED80-42F7-8C79-377650C74031@delong.com><00a501c78825$6c304a20$383816ac@atlanta.polycom.com><1484656390-1177613974-cardhu_blackberry.rim.net-1751478787-@bwe041-cell00.bisx.prod.on.blackberry> <2047909650-1177617106-cardhu_blackberry.rim.net-1631400749-@bwe059-cell00.bisx.prod.on.blackberry> Message-ID: On Thu, 26 Apr 2007, [UTF-8] Bill Woodcock wrote: > Speaking as someone who's gotten three hours of sleep a night since > arriving at the meeting, I can authoritatively say that the reason no > subsequent drafts have gotten out has nothing at all to do with process. :-) Which is a reason why I think last call should not be done on this proposal right now and new revision should be provided first that addresses concerns raised. I support this proposal (as in adding PGP authentication) in general like I think most others at ARIN (and I guess same in the meeting), but I can not support current version and as such can not support current last call and respectfully request that BoT based on number of issues raised before and "rare" discussion regarding this proposal seen at last call refer proposal to AC for additional revision with new last call afterward. If this requires additional 1/2 year and new meeting, that is unfortunate but I think this is worth the time for additional discussions and revisions since we're talking about security & authentication features. --- William Leibzon Elan Networks william at elan.net From owen at delong.com Thu Apr 26 16:30:39 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 26 Apr 2007 13:30:39 -0700 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: References: <462FB36F.50308@arin.net><46308779.3040701@psg.com><708F88B7-ED80-42F7-8C79-377650C74031@delong.com><00a501c78825$6c304a20$383816ac@atlanta.polycom.com><1484656390-1177613974-cardhu_blackberry.rim.net-1751478787-@bwe041-cell00.bisx.prod.on.blackberry> <2047909650-1177617106-cardhu_blackberry.rim.net-1631400749-@bwe059-cell00.bisx.prod.on.blackberry> Message-ID: <6BE6F41B-A729-42EE-B871-D476D36B80B3@delong.com> > If this requires additional 1/2 year and new meeting, that is > unfortunate but I think this is worth the time for additional > discussions and revisions since we're talking about security & > authentication features. I disagree. I think that even as is, this proposal is better than the current state of things. As such, I think we should move this policy forward as best we can. If what is able to move forward does not adequately address the concerns raised, then, it can be amended on the same time-table described above by a new policy submission. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From Ed.Lewis at neustar.biz Thu Apr 26 16:51:51 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 26 Apr 2007 16:51:51 -0400 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: <6BE6F41B-A729-42EE-B871-D476D36B80B3@delong.com> References: <462FB36F.50308@arin.net> <46308779.3040701@psg.co m><708F88B7-ED80-42F7-8C79-377650C74031@delong.com><00a501c78825$6c304a20$383816ac@atlanta.polycom.com><1484656390-1177613974-cardhu_blackberry. rim.net-1751478787-@bwe041-cell00.bisx.prod.on.blackberry> <2047909650-1177617106-cardhu_blackberry.rim.net-1631400749-@bwe059-cell00 .bisx.prod.on.blackberry> <6BE6F41B-A729-42EE-B871-D476D36B80B3@delong.com> Message-ID: At 13:30 -0700 4/26/07, Owen DeLong wrote: >Content-Type: multipart/signed; micalg=sha1; >boundary=Apple-Mail-33--403739806; > protocol="application/pkcs7-signature" > >> If this requires additional 1/2 year and new meeting, that is >> unfortunate but I think this is worth the time for additional >> discussions and revisions since we're talking about security & >> authentication features. > >I disagree. I think that even as is, this proposal is better than the current >state of things. As such, I think we should move this policy forward as >best we can. If what is able to move forward does not adequately address >the concerns raised, then, it can be amended on the same time-table >described above by a new policy submission. A agree with Owen...but I wish that what gets on the books is what we want. Also, the BoT always has the right to suspend a policy that is proving harmful (I believe). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From bicknell at ufp.org Thu Apr 26 20:11:14 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 26 Apr 2007 20:11:14 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: References: Message-ID: <20070427001114.GA39094@ussenterprise.ufp.org> Actually, Owen pointed out the same problem to me. I might amend: Anyone who has number resources from ARIN, a signed RSA, and falls under the ISP fee schedule. The idea being, end users should not meet the requirement, ASN only holders should not meet it, and legacy holders should not meet it until they bring their space under an RSA (or get a new block under the RSA). The latter is a bit of a stick to get legacy users under the RSA, but part of the policy's intent is that ARIN should "know" the ISP, and it's likely if they are legacy ARIN has never received any paperwork or anything from them, and thus does not "know" them. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bicknell at ufp.org Thu Apr 26 20:23:33 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 26 Apr 2007 20:23:33 -0400 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: References: <462FB36F.50308@arin.net> <46308779.3040701@psg.com> <708F88B7-ED80-42F7-8C79-377650C74031@delong.com> Message-ID: <20070427002333.GB39094@ussenterprise.ufp.org> I spoke with ARIN staff after the policy passed, and would like to offer the following "high level" path forward. 1) Mail-From is trivially spoofed by anyone with 30 seconds to spare. 2) PGP should be implemented as written, with care taken that the chain of trust length (5 in this case) is a constant defined in a single, easy to modify location. This is a huge improvement from Mail-From, as spoofing this will now likely take hours or days of work. At this point ARIN staff will have implemented the policy. 3) ARIN staff should then create a mechanism (yet to be defined) for a resource holder to 'register' their key with ARIN. At this point, if ARIN receives a mail and the key is registered the chain length must be 1. Longer chains would not be accepted for registered keys. This key holders can "opt in" to a higher security model that is virtually impossible to spoof. 4) At some point in the future, assuming a high percentage of keys are registered ARIN would consider reducing the chain length from 5 to a lower number, possibly eventually 1. Please note that staff has not agreed to implement this way, it was only a hallway discussion. However, this gives us something that can be implemented quickly, and is better than mail from. We need not wait for #3 to start to get something better. Resource holders will be able to opt for higher security, and do so individually so we don't need a flag day. I also want to remind people that this proposal ONLY does what is done with mail from today. If the key matches with a chain of 5 ARIN will only interpret that to mean the same things that "MAIL FROM: " means today. Even if I can steal Randy Bush's key and generate a properly signed message, or create a trust chain that makes a fake Randy Bush look like the real thing, I won't be able to send in an e-mail saying "give all of my (Randy's) resources to Microsoft" and have anything happen, because the process doesn't work like that with Mail From. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bicknell at ufp.org Thu Apr 26 20:32:13 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 26 Apr 2007 20:32:13 -0400 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <20070426164927.GN22289@shell01.corp.tellme.com> References: <462FB3B4.3030609@arin.net> <20070426164927.GN22289@shell01.corp.tellme.com> Message-ID: <20070427003212.GC39094@ussenterprise.ufp.org> In a message written on Thu, Apr 26, 2007 at 09:49:27AM -0700, David Williamson wrote: > While I agree that there's not community consensus, I'm disappointed > that the AC chose to ignore the half of the people in the room who > voted in favor of this proposal by not choosing to work to revise the > proposal. The thought process was that it was unlikely a "minor" change to this policy would produce a major change in community support. Typically the "work with the author" option is used to address straight forward objections raised in the meeting or on PPML and where it's believed that if those objections are addressed the policy has a good chance of passing. In this case I know I personally didn't see that. There were a wide range of objections in the meeting, and there was no obvious way to address them with language change. As an AC member I believe in these cases it's better to draft a new policy, with new title and number. There is a last call petition process to move forward if you feel that is the right thing to do. I'm not sure it's possible to petition "work with the author". I do believe that several people recommended the shepherds continue to work with you on a proposal in this line of thinking. I don't have the minutes of the AC meeting yet, so I can't be sure though. In any event, if you do want to revise I suggest you contact the shepherds for this proposal and see what you can do to increase the chances of gaining support at the next meeting. You can also, of course, resubmit the same proposal if you believe a different justification will make the difference. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From kloch at kl.net Thu Apr 26 20:46:25 2007 From: kloch at kl.net (Kevin Loch) Date: Thu, 26 Apr 2007 20:46:25 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <20070427001114.GA39094@ussenterprise.ufp.org> References: <20070427001114.GA39094@ussenterprise.ufp.org> Message-ID: <463147E1.1000904@kl.net> Leo Bicknell wrote: > Actually, Owen pointed out the same problem to me. I might amend: > > Anyone who has number resources from ARIN, a signed RSA, and falls under > the ISP fee schedule. There are ISP's who use address space reallocated via SWIP (as opposed to reassigned) to them by an upstream. This should make them a "known ISP" as reallocations are specifically to be used for downstream ISP's. My definition of "known isp" would be an entity that: - has IPv4 or IPv6 resources allocated to them by one of the following: a. directly by ARIN b. by an upstream provider reallocating space to them via SWIP of at least /24 (is it even possible to reallocate less than /24?) It would be difficult to argue that ARIN does not know that organizations meeting one of those two criteria are ISP's. In the second case ARIN is relying on the upstream provider to vet the assertion that the downstream customer is an ISP and not an end user. - Kevin From martin.hannigan at batelnet.bs Fri Apr 27 00:45:07 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Fri, 27 Apr 2007 00:45:07 -0400 Subject: [ppml] Definition of "Existing Known ISP" Message-ID: <46317fd3.c3.7256.20365@batelnet.bs> ----- Original Message ----- From: Leo Bicknell To: Public Policy Mailing List Subject: Re: [ppml] Definition of "Existing Known ISP" Date: Thu, 26 Apr 2007 20:11:14 -0400 > Actually, Owen pointed out the same problem to me. I > might amend: > > Anyone who has number resources from ARIN, a signed RSA, > and falls under the ISP fee schedule. > > The idea being, end users should not meet the requirement, Ok > ASN only holders should not meet it, Ok. > and legacy holders > should not meet it until they bring their space under an > RSA (or get a new block under the RSA). Aren't strong arm tactics to deny service somewhat premature? There are ISP's that are legitimate legacy holders. Carrots before hammers. -M< From dlw+arin at tellme.com Fri Apr 27 00:46:56 2007 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 26 Apr 2007 21:46:56 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <20070427003212.GC39094@ussenterprise.ufp.org> References: <462FB3B4.3030609@arin.net> <20070426164927.GN22289@shell01.corp.tellme.com> <20070427003212.GC39094@ussenterprise.ufp.org> Message-ID: <20070427044656.GB22289@shell01.corp.tellme.com> On Thu, Apr 26, 2007 at 08:32:13PM -0400, Leo Bicknell wrote: > There is a last call petition process to move forward if you feel > that is the right thing to do. I'm not sure it's possible to > petition "work with the author". There's not, which is an interesting (non-)pathway in the process flow. The only effective way to do this is to petition to move the proposal to last call, and then have the BoT ask for clarification from the AC. That's significantly more complicated than "just try again". Thanks for the insight, though. It's appreciated. -David From michael.dillon at bt.com Fri Apr 27 03:12:41 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 27 Apr 2007 08:12:41 +0100 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: <00a501c78825$6c304a20$383816ac@atlanta.polycom.com> Message-ID: > All valid objections, and ones that counsel noted, but one > must remember > that MAIL-FROM authentication means that today anyone can > send in an email > template with Owen's From: address and it'll be considered > "authentic". This is not true. ARIN's processes are not nearly so simplistic. The policy doesn't mention the details because it doesn't need to, and because policies are not process documents. > I do urge the AC to reduce the number of steps in the chain > before moving > this proposal forward. Five seems to be way too many; I'd be > happiest with > one, but I'd accept two or three. I don't think that you have the expertise to make this judgement. Why is two steps better than five? Why is the number of steps in the chain more important than some other factor? Why shouldn't we accept *MORE* than 5 steps in some circumstances? Why should the policy concern itself with technical details like "5 steps" rather than with policy details like "alignment with PGP authentication best practices"? --Michael Dillon From michael.dillon at bt.com Fri Apr 27 03:22:26 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 27 Apr 2007 08:22:26 +0100 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: Message-ID: > When I read the policy proposal 2007-1, my vision of five steps was > from Pat Blow's keys signed by Menynty Encyunse in Elbonia, signed by > the mythical $mail-troll, signed by someone that has legacy space but > managed to have PGP keys signed by ARIN. > > Perhaps the vision of the authors would be more along the lines of > "IP-admin-role-of-Bill's-Bait-n-Sushi-ISP" signed by > "Bill's-Bait-n-Sushi-ISP" signed by ARIN. Exactly! The trajectory of the chain is more important than an absolute number of steps in the chain. But this kind of thing does not belong in the policy. If possible, I'd like to see the AC fix the wording before going to the board. Outside of policy, I'd like the BoT to instruct ARIN staff to publish the details of their technical practice regarding authentication, and have that practice reviewed by someone with recognized security expertise. --Michael Dillon From michael.dillon at bt.com Fri Apr 27 03:28:19 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 27 Apr 2007 08:28:19 +0100 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: <20070426192530.GT22289@shell01.corp.tellme.com> Message-ID: > On the implementation question: despite my early diatribe, I trust the > AC and BoT (both of which are filled by some really smart people) Your trust is misplaced. There are some dumb people there as well and most of them are just about average in intelligence. This is because "being smart" is not one of the criteria of the job nor is it part of the selection process. The whole point of having a public policy process and a set of policies to be followed, is because we do *NOT* trust the AC and BoT, and we do *NOT* believe that they are smarter than us. That is politics. --Michael Dillon From michael.dillon at bt.com Fri Apr 27 03:31:04 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 27 Apr 2007 08:31:04 +0100 Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: <6BE6F41B-A729-42EE-B871-D476D36B80B3@delong.com> Message-ID: > I disagree. I think that even as is, this proposal is better than > the current > state of things. As such, I think we should move this policy > forward as > best we can. I agree. There is wide support for implementing the PGP authentication choice right now. Do it and we can fix any flaws the next time around. No policy is cut in stone, all are subject to change 6 months from now. --Michael Dillon From woody at pch.net Fri Apr 27 04:05:27 2007 From: woody at pch.net (Bill Woodcock) Date: Fri, 27 Apr 2007 01:05:27 -0700 (PDT) Subject: [ppml] Policy Proposal 2007-1 - Last Call In-Reply-To: References: <462FB36F.50308@arin.net><46308779.3040701@psg.com><708F88B7-ED80-42F7-8C79-377650C74031@delong.com><00a501c78825$6c304a20$383816ac@atlanta.polycom.com><1484656390-1177613974-cardhu_blackberry.rim.net-1751478787-@bwe041-cell00.bisx.prod.on.blackberry> <2047909650-1177617106-cardhu_blackberry.rim.net-1631400749-@bwe059-cell00.bisx.prod.on.blackberry> Message-ID: On Thu, 26 Apr 2007, william(at)elan.net wrote: > ...respectfully request that BoT based on number > of issues raised before and "rare" discussion regarding this proposal > seen at last call refer proposal to AC for additional revision with > new last call afterward. No such request is needed, because that's exactly the stage we're at right now. It has not been passed to the BoT for ratification yet, because it's still with the AC for final revision. -Bill From bicknell at ufp.org Fri Apr 27 09:24:51 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 27 Apr 2007 09:24:51 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <46317fd3.c3.7256.20365@batelnet.bs> References: <46317fd3.c3.7256.20365@batelnet.bs> Message-ID: <20070427132451.GA77256@ussenterprise.ufp.org> In a message written on Fri, Apr 27, 2007 at 12:45:07AM -0400, Martin Hannigan wrote: > > and legacy holders > > should not meet it until they bring their space under an > > RSA (or get a new block under the RSA). > > Aren't strong arm tactics to deny service somewhat > premature? I think this is actually kind of weak arm tactics. If the org is getting new resources from ARIN, they will have to sign an RSA from ARIN. Now, I believe it is the case they could leave their legacy blocks out, but if you're already willing to sign a RSA for new resources and abide by the community's rules I'm not sure many would object to doing it for the legacy block as well. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From dlw+arin at tellme.com Fri Apr 27 10:44:27 2007 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 27 Apr 2007 07:44:27 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <20070427003212.GC39094@ussenterprise.ufp.org> References: <462FB3B4.3030609@arin.net> <20070426164927.GN22289@shell01.corp.tellme.com> <20070427003212.GC39094@ussenterprise.ufp.org> Message-ID: <20070427144427.GD12057@shell01.corp.tellme.com> On Thu, Apr 26, 2007 at 08:32:13PM -0400, Leo Bicknell wrote: > There were a > wide range of objections in the meeting. I'm going to do something mildly dumb and think out loud. Let's see if we can list the major objections, with the goal of identifying them so they can be addressed in a possible future policy submission. Some of these are orthogonal issues, which should make it fun. * This will cause a run on space. * This will lead to an increase in spammers (and other fradulent users) applying for space. * It's trivial to show two contracts and consume arbitrary IP space, so people may try to get space under this policy in order to horde /24s for a future white/grey/black market. (It could be a good investment, to be fair.) * Any of the above may cause routing table bloat. * This didn't address reducing the minimum for PA space. * This didn't go far enough. * This will lead to an increase in applications and staff load. I think that's the primary troubles I heard. Please chime in if you were there and thought there was something more. Thanks! -David From leo.vegoda at icann.org Fri Apr 27 11:02:15 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 27 Apr 2007 17:02:15 +0200 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <20070427144427.GD12057@shell01.corp.tellme.com> References: <462FB3B4.3030609@arin.net> <20070426164927.GN22289@shell01.corp.tellme.com> <20070427003212.GC39094@ussenterprise.ufp.org> <20070427144427.GD12057@shell01.corp.tellme.com> Message-ID: <2BC4F0AD-A727-4B4E-8E77-CF434F223CCF@icann.org> On 27 Apr 2007, at 4:44pm, David Williamson wrote: > On Thu, Apr 26, 2007 at 08:32:13PM -0400, Leo Bicknell wrote: >> There were a >> wide range of objections in the meeting. > > I'm going to do something mildly dumb and think out loud. Let's > see if > we can list the major objections, with the goal of identifying them > so they can be addressed in a possible future policy submission. Some > of these are orthogonal issues, which should make it fun. > > * This will cause a run on space. While an exact comparison isn't possible, it might be useful to look at the statistics for similarly sized RIRs. They might seen a stronger or weaker drive towards addressing independence but the basic addressing independence issues remain the same. If the number of PI assignments to end users and the amount of space assigned isn't too scary then it is possible ARIN wouldn't see a run on space if a similar policy was implemented. Regards, -- Leo Vegoda IANA Numbers Liaison From dlw+arin at tellme.com Fri Apr 27 11:52:20 2007 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 27 Apr 2007 08:52:20 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <20070427144427.GD12057@shell01.corp.tellme.com> References: <462FB3B4.3030609@arin.net> <20070426164927.GN22289@shell01.corp.tellme.com> <20070427003212.GC39094@ussenterprise.ufp.org> <20070427144427.GD12057@shell01.corp.tellme.com> Message-ID: <20070427155220.GG12057@shell01.corp.tellme.com> On Fri, Apr 27, 2007 at 07:44:27AM -0700, David Williamson wrote: > I'm going to do something mildly dumb and think out loud. Let's see if > we can list the major objections, with the goal of identifying them > so they can be addressed in a possible future policy submission. Some > of these are orthogonal issues, which should make it fun. I missed one: * It was pointed out that a PA allocation of a given size results in an additional block of equal size being set aside for future growth. This is not done for PI space. I actually have been looking at this, and haven't been able to find any reference to this practice in section 4 of the NRPM. It's certainly possible that I'm just missing it. I suspect that either both PA and PI are actually treated in the same way, or there is a difference, but it's due to differences in policy implementation, and not in the policy itself. (Perhaps staff can comment on that.) Unless there's a real difference in how reservations of space are made in the NRPM, I think this point is, perhaps, a red herring. -David From owen at delong.com Fri Apr 27 13:47:09 2007 From: owen at delong.com (Owen DeLong) Date: Fri, 27 Apr 2007 10:47:09 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <20070427144427.GD12057@shell01.corp.tellme.com> References: <462FB3B4.3030609@arin.net> <20070426164927.GN22289@shell01.corp.tellme.com> <20070427003212.GC39094@ussenterprise.ufp.org> <20070427144427.GD12057@shell01.corp.tellme.com> Message-ID: <512FC041-D4E8-40C6-9CFF-E2B67609F7AA@delong.com> On Apr 27, 2007, at 7:44 AM, David Williamson wrote: > On Thu, Apr 26, 2007 at 08:32:13PM -0400, Leo Bicknell wrote: >> There were a >> wide range of objections in the meeting. > > I'm going to do something mildly dumb and think out loud. Let's > see if > we can list the major objections, with the goal of identifying them > so they can be addressed in a possible future policy submission. Some > of these are orthogonal issues, which should make it fun. > ;-) The below list was pretty comprehensive from my point of view, but, Please permit me to categorize each of these objections such that I think they can be summarized: > A * This will cause a run on space. > > A * This will lead to an increase in spammers (and other fradulent > users) > applying for space. > > A * It's trivial to show two contracts and consume arbitrary IP space, > so people may try to get space under this policy in order to > horde /24s for a future white/grey/black market. (It could > be a good investment, to be fair.) > > B * Any of the above may cause routing table bloat. > > C * This didn't address reducing the minimum for PA space. > > C * This didn't go far enough. > > A * This will lead to an increase in applications and staff load. A I think there was pretty good data to show that these objections were mostly "FUD" in the presentation. Indeed, other than the comments about the triviality of bullet 3, I don't recall those objections being raised in the room after the presentation and the general sense I got from most people was that the other points were well addressed. I believe that the NRPM already provides sufficient authority for staff to address bullet 3 (trivial fraud), but, given the BoT Chair's statement to the contrary, I have submitted a policy proposal to address this issue. I agree with David that it is orthogonal to this policy (why not hoard /22s instead from the same effort?), but, I think it can easily be addressed. B Since we're talking about multi-homers, absent fraud, these guys are consuming a routing-table slot no matter what, so, I don't see bloat as being an issue. C Objections to a policy on the basis that it's only a partial solution are kind of silly. That argument is being hashed out on 2007-1 in last call right now. So, it is my sense of the room that had we been able to address the fraud question, the show of hands probably would have gone quite differently. Anyway, bottom line now is that the best way forward is to make yet another new proposal for this. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From marla.azinger at frontiercorp.com Fri Apr 27 14:29:20 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Fri, 27 Apr 2007 14:29:20 -0400 Subject: [ppml] Policy Proposal 2007-6 - Abandoned Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt> I disagree. I think there are a few very loud (not that this is bad) voices that repeatedly state their support for this proposal. I also feel that there a allot of people who feel this is in general bad policy no matter how you try to spin the views of how spam, bloat and hording are addressed. Those people didn't speak up on ppml or much at the mic but they definitely showed their hands in opposition at the meeting. Thus...no consensus with a slight larger number of hands opposed vs. in support. In addition there was one point made that there really is a lack of what this is supposed to be solving. It seems like it is less of a need and more of a wish. Also, I have been working with one person that was in support of this proposal. After we got talking I discovered that the only reason they supported it was because their upstream isn't supporting them with proper re-allocation paperwork to ARIN WHOIS. Thus inhibiting them from sending re-assignments to ARIN WHOIS. So really, this is a problem, but educating their upstream to support them correctly is a better solution than writing policy that has negative consequences. Yes, I believe this would lead to a run on IPv4 space Yes, I believe network providers and ISP's can cut off and clean up IP space used by spammers faster than ARIN ( and I think that is important). Yes, I believe it is MUCH easier to fudge justification for a /24 than a /22 and set yourself up for hording IP addresses and possibly using them on black-market in the future. So again (sorry) I still don't support the proposal that no consensus was found for or one that like it in the near future. Cheers! Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Owen DeLong Sent: Friday, April 27, 2007 10:47 AM To: David Williamson Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2007-6 - Abandoned On Apr 27, 2007, at 7:44 AM, David Williamson wrote: > On Thu, Apr 26, 2007 at 08:32:13PM -0400, Leo Bicknell wrote: >> There were a >> wide range of objections in the meeting. > > I'm going to do something mildly dumb and think out loud. Let's > see if > we can list the major objections, with the goal of identifying them > so they can be addressed in a possible future policy submission. Some > of these are orthogonal issues, which should make it fun. > ;-) The below list was pretty comprehensive from my point of view, but, Please permit me to categorize each of these objections such that I think they can be summarized: > A * This will cause a run on space. > > A * This will lead to an increase in spammers (and other fradulent > users) > applying for space. > > A * It's trivial to show two contracts and consume arbitrary IP space, > so people may try to get space under this policy in order to > horde /24s for a future white/grey/black market. (It could > be a good investment, to be fair.) > > B * Any of the above may cause routing table bloat. > > C * This didn't address reducing the minimum for PA space. > > C * This didn't go far enough. > > A * This will lead to an increase in applications and staff load. A I think there was pretty good data to show that these objections were mostly "FUD" in the presentation. Indeed, other than the comments about the triviality of bullet 3, I don't recall those objections being raised in the room after the presentation and the general sense I got from most people was that the other points were well addressed. I believe that the NRPM already provides sufficient authority for staff to address bullet 3 (trivial fraud), but, given the BoT Chair's statement to the contrary, I have submitted a policy proposal to address this issue. I agree with David that it is orthogonal to this policy (why not hoard /22s instead from the same effort?), but, I think it can easily be addressed. B Since we're talking about multi-homers, absent fraud, these guys are consuming a routing-table slot no matter what, so, I don't see bloat as being an issue. C Objections to a policy on the basis that it's only a partial solution are kind of silly. That argument is being hashed out on 2007-1 in last call right now. So, it is my sense of the room that had we been able to address the fraud question, the show of hands probably would have gone quite differently. Anyway, bottom line now is that the best way forward is to make yet another new proposal for this. Owen From owen at delong.com Fri Apr 27 15:12:02 2007 From: owen at delong.com (Owen DeLong) Date: Fri, 27 Apr 2007 12:12:02 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt> Message-ID: <08CB8F9A-30BD-4398-81ED-E64AD0FF2698@delong.com> > Yes, I believe this would lead to a run on IPv4 space Please provide any documentation you can to support this belief. Certainly, the equivalant policy in EVERY other RIR has not created this problems in any other region, so, I'd like to see any data you have that supports this belief. > Yes, I believe network providers and ISP's can cut off and clean up > IP space used by spammers faster than ARIN ( and I think that is > important). Network providers can clean it up by de-routing it and adding it to the bogon filters etc. This can be done whether the space is a direct assignment from ARIN or provider-assigned. > Yes, I believe it is MUCH easier to fudge justification for a /24 > than a /22 and set yourself up for hording IP addresses and > possibly using them on black-market in the future. Again, data to support this belief would be good. I'm pretty familiar with what it takes to justify a /22, and, I think it's pretty trivial if you're willing to commit fraud either way. > > So again (sorry) I still don't support the proposal that no > consensus was found for or one that like it in the near future. Yep... I expected that. I'm also pretty sure that the vote in the room was much closer than the vote in the AC meeting. I believe there is more opposition to this policy on the AC than in the community. Now, as to your other comments: Yes, in terms of ARIN participation, this policy is championed by a small (but growing) group of people active in ARIN. One of the reasons for that is that the majority of organizations that would benefit from this policy are not present for ARIN public policy meetings. For them, the network is a tool and not their core business. As such, it's kind of hard to justify the time, travel budget, etc. Most of them depend on outsource companies and people like me to do that for them. While there's no provision for this fact in the public policy process, I was actually representing no less than 5 organizations with ARIN resources all of who would like to see this policy implemented. In addition, I have at least 10 clients who would benefit from this policy because it would allow them to multihome without taking additional routing slots and without business risk of abrupt renumbering being required when their provider goes out of business. These concerns are sufficiently important to at least half of them that they affect their SoX compliance. Hopefully that places the need in some perspective. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From jmorrison at bogomips.com Fri Apr 27 15:49:48 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Fri, 27 Apr 2007 12:49:48 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <08CB8F9A-30BD-4398-81ED-E64AD0FF2698@delong.com> References: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt> <08CB8F9A-30BD-4398-81ED-E64AD0FF2698@delong.com> Message-ID: <463253DC.4010609@bogomips.com> Owen DeLong wrote: >> Yes, I believe this would lead to a run on IPv4 space > Please provide any documentation you can to support this belief. > Certainly, the equivalant policy in EVERY other RIR has not > created this problems in > any other region, so, I'd like to see any data you have that > supports this belief. > I don't know how this would lead to a run on IPv4 space, because I have had to justify several /24's for customers - allocated out of Carriers/Telco IP address space to be used for BGP multi-homing. It's a hassle, you are tied to one carrier's address space, and you have more dependence on the carrier's BGP policies than if you had your own /24. I would prefer to have a direct allocation, but whether I get a /24 from a carrier or ARIN, doesn't really change the address consumption. The requirement for a /24 to do BGP multi-homing is basically arbitrary, but it dates back to concerns about routing table size. If you could convince the majority of ISPs and AS's that /25's or even longer prefixes belong in the global routing tables, then you could come up with a workable IPv4 multi-homing solution that doesn't require a /24 allocation. However in practice, longer prefixes may not be routable. Perhaps the wording of 2007-6 should be changed to remove the reference to a /24 allocation and focus on the actual need. Routing table bloat is a concern, but I'm not sure it's as big an issue as it once was 5 or 10 years ago. If routing table size is really a problem, it's going to be made worse with IPv6, since that's going to cause more growth. (I'm sure you can have an efficient IPv6+IPv4 RIB in backbone routers, but IPv6 will only add routing entries, and at that point, who cares whether a route is an IPv6 /48 or an IPv4 /28?) If ARIN sets aside some space specifically for multi-homed ASs, which is allowed to have /25 or longer allocations, carriers can still filter the rest of the routing table to restrict more specific routes, and can make exceptions for this address space. But the technical challenges will have to be addressed by the carriers and end users, because prefixes longer than /24 could easily be non-routable. John Paul Morrison From william at elan.net Fri Apr 27 17:07:13 2007 From: william at elan.net (william(at)elan.net) Date: Fri, 27 Apr 2007 14:07:13 -0700 (PDT) Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <20070427144427.GD12057@shell01.corp.tellme.com> References: <462FB3B4.3030609@arin.net> <20070426164927.GN22289@shell01.corp.tellme.com> <20070427003212.GC39094@ussenterprise.ufp.org> <20070427144427.GD12057@shell01.corp.tellme.com> Message-ID: On Fri, 27 Apr 2007, David Williamson wrote: > On Thu, Apr 26, 2007 at 08:32:13PM -0400, Leo Bicknell wrote: >> There were a >> wide range of objections in the meeting. > > I'm going to do something mildly dumb and think out loud. Let's see if > we can list the major objections, with the goal of identifying them > so they can be addressed in a possible future policy submission. Good that you're not abandoning the effort. And just FYI - it took 2 (or was it 3?) years and several abandoned policy proposals before original micro-allocation policy proposal was passed. > Some > of these are orthogonal issues, which should make it fun. > > * This will cause a run on space. Which will happen anyway. The amount of space for micro-allocations is actually comparatively very small considering amounts of space overall consumed by other entities. In fact the amount of space used by most isps who have < /19 (which is 80% of ARIN members) is about < 20% of the space actually allocated by ARIN overall [I did exact study few years ago, don't have exact numbers handy though; I plan to redo it based on current data end of 2007 again]. > * This will lead to an increase in spammers (and other fradulent users) > applying for space. It certainly will. Unfortunately these people have no issue with providing bad documentation and do it with others as well when they need space including for /22s. But good thing is that number of these players is actually somewhat limited and in the end ARIN will probably learn who they all are. > * It's trivial to show two contracts and consume arbitrary IP space, > so people may try to get space under this policy in order to > horde /24s for a future white/grey/black market. (It could > be a good investment, to be fair.) This point equally applies to those applying for micro-allocation now. > * Any of the above may cause routing table bloat. Important point to note that it should be requirement for entity to have and utilize micro-allocation with their ASN. This reduces amount of bloat - basically you have the same routing slot for PI space that you'd already see for PA advertised through separate ASN. > * This didn't address reducing the minimum for PA space. This point I don't get. > * This didn't go far enough. how far should it have gone??? > * This will lead to an increase in applications and staff load. ARIN does not seem to have any financial issues at the moment (its way in black) in fact additional money recovered from this would likely more then offset any potential cost to hire additional staff too. > I think that's the primary troubles I heard. Please chime in if you > were there and thought there was something more. > > Thanks! > > -David > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From bmanning at karoshi.com Fri Apr 27 16:12:31 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Fri, 27 Apr 2007 20:12:31 +0000 Subject: [ppml] don't eat the last Tuna! PP-2007-6 In-Reply-To: <08CB8F9A-30BD-4398-81ED-E64AD0FF2698@delong.com> References: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt> <08CB8F9A-30BD-4398-81ED-E64AD0FF2698@delong.com> Message-ID: <20070427201231.GB1913@vacation.karoshi.com.> I've never been entirely comfortable w/ the intimation, perhaps encouraged by Geoffs sensational graphics and "the sky is falling faster than you thought" presentations, that the community was about to make IPv4 extinct. ... e.g. treating IPv4 as a commodity. Its not. To borrow a fishing analogy, we are not about to eat the last tuna. It might be more realistic to view IPv4 and IPv6 as two blocks of spectrum, or two blocks of real estate. To date, ARIN polices have been constructed around a "frontier" model, where there was always enough open space/land "out there" to go greenfield in new areas when we had used up the old area... for some definition of "used". There has been some pushback in the request/demand for justification before being allowed to move into new space, but those justifications are malliable. The transitional state we are in (or approching) ... is much like the tension between ranchers and farmers in the 1800's in the US. Ranchers hate the fences. lets say we have one block of realestate, 15,000,000 sqm, centered at 35degrees 40'05 North, 139degrees 49'25 East ... we'll call that the analog of IPv4. I posit that it is hard to get a right to use for 10,000 sqm in that space. there are real costs, perhaps the need to track down the holders of rights to use for many smaller blocks of 1000 sqm and perhaps even 100 sqm blocks. And it might be prudent to consider that the most effective use of space is to understand that nearly no-one will need/can afford to aquire the RTU for 10,000 sqm in that space. There will be a need to track RTU for very small chucks of space (anyone uncomfortable w/ renting by the sqm/sqf these days? there are places, London, NYC and perhaps otheres, where you can find spaces that rent for the sqcm/sqinch) ... so if this analog holds, I would expect ARIN to eventually evolve policies to recognise /24 blocks and even /30 blocks... The farmers win. :) Prediction: Something like this policy will be back until we deal w/ it. What about those ranchers who want unfenced, frontiers to build new - exciting things with a different risk profile? My I suggest the other 15,000,000 sqm block - 36degrees 32'23 North, 114degrees 26'35 West. Lots of open room to breath/grow/expand ... try out new things. If i REALLY need 10,000 sqm, this is a place where its fairly easy to get that space in a single larger chunk. Perhaps this is a decent analog of IPv6. So, I think that a revisit of a proposal/policy of this kind is eventually inevitable. I also think that we may have to deal w/ two types of policies, one for dense, steady-state systems like IPv4 is becoming, and one for sparse open-ended systems like IPv6. Wacky Idea: Most of our existing policy assumptions work just fine for IPv6 and we need to change the basis on which we do IPv4 policy. YMMV of course. --bill From marla.azinger at frontiercorp.com Fri Apr 27 16:25:34 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Fri, 27 Apr 2007 16:25:34 -0400 Subject: [ppml] Policy Proposal 2007-6 - Abandoned Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272F8B4@nyrofcs2ke2k01.corp.pvt> Owen- just FYI your certification method is setting my email alarm of and shows your email not trustworthy. I don't know if I'm the only one getting that warning about your email or not.... As for this string of emails. Clearly there are opposing points of view. There always will be. That is a good thing. However, I feel dizzy at this point from going in conversation circles, so I am going to bow out from commenting anymore on this one for a while. One last clarification I would like to make due to your comment stating that "there must be more opposition on the AC to this than in the community". That is an assumption. The AC votes on community consensus. We did not see this proposal had consensus. Nor did we see a way to re-write it. That said, if someone has a great idea that manages to find a balance then that is what a new proposal would be good for. Cheers! Marla -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Friday, April 27, 2007 12:12 PM To: Azinger, Marla Cc: David Williamson; ppml at arin.net Subject: Re: [ppml] Policy Proposal 2007-6 - Abandoned > Yes, I believe this would lead to a run on IPv4 space Please provide any documentation you can to support this belief. Certainly, the equivalant policy in EVERY other RIR has not created this problems in any other region, so, I'd like to see any data you have that supports this belief. > Yes, I believe network providers and ISP's can cut off and clean up > IP space used by spammers faster than ARIN ( and I think that is > important). Network providers can clean it up by de-routing it and adding it to the bogon filters etc. This can be done whether the space is a direct assignment from ARIN or provider-assigned. > Yes, I believe it is MUCH easier to fudge justification for a /24 > than a /22 and set yourself up for hording IP addresses and > possibly using them on black-market in the future. Again, data to support this belief would be good. I'm pretty familiar with what it takes to justify a /22, and, I think it's pretty trivial if you're willing to commit fraud either way. > > So again (sorry) I still don't support the proposal that no > consensus was found for or one that like it in the near future. Yep... I expected that. I'm also pretty sure that the vote in the room was much closer than the vote in the AC meeting. I believe there is more opposition to this policy on the AC than in the community. Now, as to your other comments: Yes, in terms of ARIN participation, this policy is championed by a small (but growing) group of people active in ARIN. One of the reasons for that is that the majority of organizations that would benefit from this policy are not present for ARIN public policy meetings. For them, the network is a tool and not their core business. As such, it's kind of hard to justify the time, travel budget, etc. Most of them depend on outsource companies and people like me to do that for them. While there's no provision for this fact in the public policy process, I was actually representing no less than 5 organizations with ARIN resources all of who would like to see this policy implemented. In addition, I have at least 10 clients who would benefit from this policy because it would allow them to multihome without taking additional routing slots and without business risk of abrupt renumbering being required when their provider goes out of business. These concerns are sufficiently important to at least half of them that they affect their SoX compliance. Hopefully that places the need in some perspective. Owen From schiller at uu.net Fri Apr 27 17:30:32 2007 From: schiller at uu.net (Jason Schiller) Date: Fri, 27 Apr 2007 17:30:32 -0400 (EDT) Subject: [ppml] Buying time... In-Reply-To: <049a01c78765$5acd9e60$1068db20$@net> Message-ID: comments in line. __Jason On Wed, 25 Apr 2007, Tony Hain wrote: > > Jason Schiller wrote: > > .... > > Whatever remains non-IPv6 capable will have to be upgraded, and as IPv6 > > generates no new revune there is not much of a return on investment. > > For those cases it becomes a risk-avoidance justification: > > How much are you willing to pay for IPv4 in the open market to add new > customers or services? > ... Exactly. Large ISPs will wait until the last moment to before spending on hardware upgrades for the sole purpose of supporting IPv6 when it does not generate new revenue. To not wait puts you at a competitive disadvantage. The longer IPv4 lasts, the greater the chance that other projects or normal refresh will allow an ISP to upgrade more equipment, leaving less legacy equipment to upgrade for the sole purpose of supporting IPv6 with no ROI. At the same time, ISPs want to be somewhat IPv6 capable with minimal investments. This allows them to test and certify their equipment, configuration, and migration plan. It allows them some capabilities to offer IPv6 to customer who want to experiment, and the capability to offer IPv6 to any customer where the business case covers the cost of the upgrades. It allows them to demonstrate IPv6 expertise, and provide useful insite to shaping community policy and protocol standards. The problem with building a just in time network is making sure it is in time. This becomes more difficult as the amount of time required to upgrade the network is large. Projecting the run out time three years in advance to start upgrades in time is not a sure thing. Just consider the two leading projections are 2.5 years apart. > ... > What will the price be in the open market for a resource that is not > considered property now, but even another part of Jason's organization gets > away with effectively leasing for ~ $1.33/day per address? Hotels typically > get ~ $5/day/address, and from what I hear globally, long term contracts > already average ~ $1/day/address. Prices for scarce resources don't go down > as they become harder to get ... Yes, if IPv4 addresses are available, and they are cheaper than the cost of upgrading the remaining network to IPv6, then those upgrades will be delayed. Those upgrades will progress when the projected price (projected out buy the amount of time the remaining upgrades will take to complete) is more than cost of upgrading the remaining network > > Tony > From ipgoddess at gmail.com Fri Apr 27 18:13:59 2007 From: ipgoddess at gmail.com (Stacy Taylor) Date: Fri, 27 Apr 2007 15:13:59 -0700 Subject: [ppml] Policy Proposal 2007-6 - Abandoned In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A0272F8B4@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A0272F8B4@nyrofcs2ke2k01.corp.pvt> Message-ID: <1c16a4870704271513o70555729v2dbb98545465d866@mail.gmail.com> Hi Everyone, I was a documented opponent to 2006-7, for the reasons I have already stated and still believe. That being said, I need to echo Marla's statements about the AC vote. The AC did move to abandon, but because there was no consensus to either move it forward or work with the author. The dividing issue on this policy was not wordsmithing, or any other small qualification that the author could change. It was the very heart of the proposal - whether or not end users should qualify for /24s direct from ARIN - that was the point of contention of the community, and it was the opinion of the majority of the AC that the policy be abandoned for lack of consensus on that point. I will be happy to engage in the discussion of merits of this concept should a new policy be generated. Really good meeting, everyone. Thank you! Stacy On 4/27/07, Azinger, Marla wrote: > Owen- just FYI your certification method is setting my email alarm of > and shows your email not trustworthy. I don't know if I'm the only one > getting that warning about your email or not.... > > As for this string of emails. Clearly there are opposing points of > view. There always will be. That is a good thing. However, I feel > dizzy at this point from going in conversation circles, so I am going to > bow out from commenting anymore on this one for a while. > > One last clarification I would like to make due to your comment stating > that "there must be more opposition on the AC to this than in the > community". That is an assumption. The AC votes on community > consensus. We did not see this proposal had consensus. Nor did we see > a way to re-write it. That said, if someone has a great idea that > manages to find a balance then that is what a new proposal would be good > for. > > Cheers! > Marla > > > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Friday, April 27, 2007 12:12 PM > To: Azinger, Marla > Cc: David Williamson; ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2007-6 - Abandoned > > > > Yes, I believe this would lead to a run on IPv4 space > Please provide any documentation you can to support this belief. > Certainly, the equivalant policy in EVERY other RIR has not > created > this problems in > any other region, so, I'd like to see any data you have > that > supports this belief. > > > Yes, I believe network providers and ISP's can cut off and clean up > > IP space used by spammers faster than ARIN ( and I think that is > > important). > Network providers can clean it up by de-routing it and adding it > to > the bogon filters > etc. This can be done whether the space is a direct > assignment > from ARIN or > provider-assigned. > > > Yes, I believe it is MUCH easier to fudge justification for a /24 > > than a /22 and set yourself up for hording IP addresses and > > possibly using them on black-market in the future. > Again, data to support this belief would be good. I'm pretty > familiar with what it > takes to justify a /22, and, I think it's pretty trivial > if you're > willing to commit > fraud either way. > > > > So again (sorry) I still don't support the proposal that no > > consensus was found for or one that like it in the near future. > Yep... I expected that. I'm also pretty sure that the vote in > the > room was much > closer than the vote in the AC meeting. I believe there > is more > opposition > to this policy on the AC than in the community. > > Now, as to your other comments: > > Yes, in terms of ARIN participation, this policy is championed by a > small (but growing) > group of people active in ARIN. One of the reasons for that is that > the majority of > organizations that would benefit from this policy are not present for > ARIN public > policy meetings. For them, the network is a tool and not their core > business. As > such, it's kind of hard to justify the time, travel budget, etc. > Most of them depend on > outsource companies and people like me to do that for them. > > While there's no provision for this fact in the public policy > process, I was actually > representing no less than 5 organizations with ARIN resources all of > who would > like to see this policy implemented. > > In addition, I have at least 10 clients who would benefit from this > policy because > it would allow them to multihome without taking additional routing > slots and without > business risk of abrupt renumbering being required when their > provider goes > out of business. These concerns are sufficiently important to at > least half of them > that they affect their SoX compliance. > > Hopefully that places the need in some perspective. > > Owen > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > -- :):) /S From schiller at uu.net Fri Apr 27 17:30:32 2007 From: schiller at uu.net (Jason Schiller) Date: Fri, 27 Apr 2007 17:30:32 -0400 (EDT) Subject: [ppml] Buying time... In-Reply-To: <049a01c78765$5acd9e60$1068db20$@net> Message-ID: comments in line. __Jason On Wed, 25 Apr 2007, Tony Hain wrote: > > Jason Schiller wrote: > > .... > > Whatever remains non-IPv6 capable will have to be upgraded, and as IPv6 > > generates no new revune there is not much of a return on investment. > > For those cases it becomes a risk-avoidance justification: > > How much are you willing to pay for IPv4 in the open market to add new > customers or services? > ... Exactly. Large ISPs will wait until the last moment to before spending on hardware upgrades for the sole purpose of supporting IPv6 when it does not generate new revenue. To not wait puts you at a competitive disadvantage. The longer IPv4 lasts, the greater the chance that other projects or normal refresh will allow an ISP to upgrade more equipment, leaving less legacy equipment to upgrade for the sole purpose of supporting IPv6 with no ROI. At the same time, ISPs want to be somewhat IPv6 capable with minimal investments. This allows them to test and certify their equipment, configuration, and migration plan. It allows them some capabilities to offer IPv6 to customer who want to experiment, and the capability to offer IPv6 to any customer where the business case covers the cost of the upgrades. It allows them to demonstrate IPv6 expertise, and provide useful insite to shaping community policy and protocol standards. The problem with building a just in time network is making sure it is in time. This becomes more difficult as the amount of time required to upgrade the network is large. Projecting the run out time three years in advance to start upgrades in time is not a sure thing. Just consider the two leading projections are 2.5 years apart. > ... > What will the price be in the open market for a resource that is not > considered property now, but even another part of Jason's organization gets > away with effectively leasing for ~ $1.33/day per address? Hotels typically > get ~ $5/day/address, and from what I hear globally, long term contracts > already average ~ $1/day/address. Prices for scarce resources don't go down > as they become harder to get ... Yes, if IPv4 addresses are available, and they are cheaper than the cost of upgrading the remaining network to IPv6, then those upgrades will be delayed. Those upgrades will progress when the projected price (projected out buy the amount of time the remaining upgrades will take to complete) is more than cost of upgrading the remaining network > > Tony > From matt.pounsett at cira.ca Sun Apr 29 10:49:22 2007 From: matt.pounsett at cira.ca (Matt Pounsett) Date: Sun, 29 Apr 2007 10:49:22 -0400 Subject: [ppml] IPREP, proposal revisions, and last call (was: Policy Proposal 2007-1 - Last Call) In-Reply-To: References: <462FB36F.50308@arin.net> <46308779.3040701@psg.co m><708F88B7-ED80-42F7-8C79-377650C74031@delong.com><00a501c78825$6c304a20$383816ac@atlanta.polycom.com> <1484656390-1177613974-cardhu_blackberry.rim.net-1751478787-@bwe041-cell00 .bisx.prod.on.blackberry> Message-ID: <81B3B1D9-9559-4270-86BD-2ACFC35CD66F@cira.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26-Apr-2007, at 15:41 , Edward Lewis wrote: > Here's where the IRPEP gets confusing to me. The number 5 is in the > last call message and it is still on the proposal version on the web > site (URL given in my previous message and appears below). The author(s) of a proposal can submit revisions at any point in the process right up until the end of last call. As long as those revisions make it to PPML with enough time for the community to review them, and as long as the proposal continues to hold consensus after those revisions are made, then the proposal will likely be sent to the BoT with those revisions. The AC has to judge whether the community had enough time to review any revisions, and whether the proposal still enjoys the support of the community. In this case, during the meeting there seemed to be some question as to whether certain statements in the proposal (in particular, some implementation details) belonged in the proposal, the authors have chosen to remove or alter those statements during Last Call. My understanding is that they intend to get their revisions out to the list this week, which should be enough time for the community to review and decide whether they still think the proposal is appropriate for the NRPM. Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFGNLB1ae4z2vjbC8sRAsA1AJ45yfzyXak4bmR3dNYx6SdWQsioeACgi8Xt pCL8ySezuQuN6lLTfD04kdI= =BuN6 -----END PGP SIGNATURE----- From alex at basespace.net Sun Apr 29 13:51:46 2007 From: alex at basespace.net (Alex) Date: Sun, 29 Apr 2007 13:51:46 -0400 Subject: [ppml] Policy Proposal 2007-6 - Abandoned References: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt> Message-ID: <005b01c78a87$0edf4600$08067126@basespacenf1s7> > Also, I have been working with one person that was in support of this > proposal. That's me. Thank you very much for all your helpful suggestions! > After we got talking I discovered that the only reason they supported it > was because their upstream isn't supporting them with proper re- > allocation paperwork to ARIN WHOIS. Actually, no, not the only reason, just one reason. The main reason I would like PI space is so that I can excercise freedom of choice among upstream ISPs without having to renumber, and so that I will not again be in danger of losing my livelihood when my upstream goes out of business or is bought. - Alex Aminoff BaseSpace.net From matt.pounsett at cira.ca Sun Apr 29 10:55:22 2007 From: matt.pounsett at cira.ca (Matt Pounsett) Date: Sun, 29 Apr 2007 10:55:22 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <46317fd3.c3.7256.20365@batelnet.bs> References: <46317fd3.c3.7256.20365@batelnet.bs> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27-Apr-2007, at 00:45 , Martin Hannigan wrote: >> and legacy holders >> should not meet it until they bring their space under an >> RSA (or get a new block under the RSA). > > Aren't strong arm tactics to deny service somewhat > premature? > There are ISP's that are legitimate legacy holders. Carrots > before hammers. Maybe this is a wording problem... I read this the other way 'round, as in: Holding and re-delegating legacy space is not sufficient to be classified as an ISP. Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFGNLHbae4z2vjbC8sRArG/AKCo0JnU3vbJWdWuGneG0L1GTwReJQCgnoV9 1+PxkA0kzqPSV8WTpOaZJWk= =0XjC -----END PGP SIGNATURE----- From matt.pounsett at cira.ca Sun Apr 29 11:22:15 2007 From: matt.pounsett at cira.ca (Matt Pounsett) Date: Sun, 29 Apr 2007 11:22:15 -0400 Subject: [ppml] The task of the AC (was: Policy Proposal 2007-6 - Abandoned) In-Reply-To: <08CB8F9A-30BD-4398-81ED-E64AD0FF2698@delong.com> References: <454810F09B5AA04E9D78D13A5C39028A0272F8B1@nyrofcs2ke2k01.corp.pvt> <08CB8F9A-30BD-4398-81ED-E64AD0FF2698@delong.com> Message-ID: <13E617E0-F564-4AEE-A2A5-C29DCB87EC28@cira.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27-Apr-2007, at 15:12 , Owen DeLong wrote: > Yep... I expected that. I'm also pretty sure that the vote in the > room was much > closer than the vote in the AC meeting. I believe there is more > opposition > to this policy on the AC than in the community. I think this reveals a misconception of what the AC is voting on in their meeting. The show of support by the community, and the vote taken by the AC are on very different subjects. Each community member shows how they individually feel about the proposal. When the AC votes, each AC member is voting on what they perceive the community as a whole felt about the proposal. There is no reason to believe that the percentage of votes to accept or reject a proposal in the AC meeting will match the percentage of community members that supported a proposal. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFGNLgqae4z2vjbC8sRAqZQAJ4mGtbrgXoZHUB4rMxEl7nITxJyjACfW2kl OdhwTOQH4HoSBdiOHJbpM1Q= =YrOG -----END PGP SIGNATURE----- From rich at nic.umass.edu Sun Apr 29 11:52:40 2007 From: rich at nic.umass.edu (Rich Emmings) Date: Sun, 29 Apr 2007 11:52:40 -0400 (EDT) Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: References: <46317fd3.c3.7256.20365@batelnet.bs> Message-ID: On Sun, 29 Apr 2007, Matt Pounsett wrote: > > Holding and re-delegating legacy space is not sufficient to be > classified as an ISP. > > Matt > Not having signed an RSA doesn't disqualify one from being an ISP either. From matt.pounsett at cira.ca Sun Apr 29 12:28:27 2007 From: matt.pounsett at cira.ca (Matt Pounsett) Date: Sun, 29 Apr 2007 12:28:27 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: References: <46317fd3.c3.7256.20365@batelnet.bs> Message-ID: <2D1E635E-83EA-4ECA-A35B-82E403D7CAC9@cira.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29-Apr-2007, at 11:52 , Rich Emmings wrote: > On Sun, 29 Apr 2007, Matt Pounsett wrote: > >> >> Holding and re-delegating legacy space is not sufficient to be >> classified as an ISP. >> >> Matt >> > > Not having signed an RSA doesn't disqualify one from being an ISP > either. In terms of the ARIN definition of "ISP" for the purposes of NRPM, I think it does. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFGNMewae4z2vjbC8sRAv/yAJ0XKscMT6saFzaDruAD5PV1lFG+HwCfdcTE fbWSm/4LSqYF7rNKA93Bfek= =Qrff -----END PGP SIGNATURE----- From m.hertrick at neovera.com Mon Apr 30 08:42:01 2007 From: m.hertrick at neovera.com (Michael Hertrick) Date: Mon, 30 Apr 2007 08:42:01 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: References: Message-ID: <4635E419.1030801@neovera.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There has already been a lot said regarding this topic, and while I have read much of it I honestly have not read every last word posted. I did search the thread for keywords like web hosting and colocation/co-location, and ASP and found nothing, so I believe that most of what I am about to say is not redundant. I think that today's definition of ISP not not limited to user access, transit, and backbone services as it once was. Companies providing web hosting and co-location services should be considered ISPs. For that matter, there are also companies that call themselves ASPs, Application Service Providers, that have the same Internet number needs as ISPs. I suppose that an ASP is an ISP even though the inverse is not necessarily true. There are undoubtedly many Internet related services that would constitute a company's recognition as an Internet Service Provider. Does the ARIN staff acknowledge that? In response to the numerous recommendations that IPv4 has some influence on the IPv6 policies, I think that the definition of "existing, known ISP in the ARIN region" needs to remain somewhat ambiguous. A company should be defined by what they do rather than how they happen to fit the IPv4 policy. To exclude companies based on how they comply with IPv4 policies would be unfair because those policies were only intended to apply to IPv4 address allocation. Therefore IPv6 allocations should be available to companies that provide Internet services. Perhaps the S. in I.S.P. should be pluralized because nowadays there are more than one type of service. Or perhaps the term "services provider" should be used in lieu of the acronym ISP. Thanks, ~Mike. Owen DeLong wrote: > According to Leslie, ARIN staff would like community input on the > definition of "Existing Known ISP" in the NRPM. > > I would propose that the following definition seems self-evident to me, > but, I would like to see what others here have to say: > > "An existing, known ISP is any ARIN Subscriber Organization who has > received an IPv4 allocation from ARIN or an ARIN predecessor which > now is an ARIN Subscriber Organization." > > Owen > > ---------------------------------------------------------------------- > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGNeQZcJVdtfpkLb8RAowfAJ4r3dkk3tTvb5cczD325irxh0lv0ACff+4s 59a3VrNkkJ3GTkXpbTbniUs= =qRcM -----END PGP SIGNATURE----- From michael.dillon at bt.com Mon Apr 30 09:22:09 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 30 Apr 2007 14:22:09 +0100 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <4635E419.1030801@neovera.com> References: <4635E419.1030801@neovera.com> Message-ID: > I think that today's definition of ISP not not limited to user access, > transit, and backbone services as it once was. Companies providing > web hosting and co-location services should be considered ISPs. Companies providing services that include connectivity to the Internet are Internet Service Providers. Not just the ones which provide Internet access services. Seems reasonable. > For > that matter, there are also companies that call themselves ASPs, > Application Service Providers, that have the same Internet number > needs as ISPs. This is a bit grey. There are ASPs that sit higher up the food chain. They by hosting services from someone who buys colocation services from someone who buys a rack from someone who has a data center on the Internet. Thinking about the difference between these two groupings, I think that infrastructure is the key factor. ISPs build infrastructure and ASPs may only use infrastructure, not build it. Web hosting and colo service also build infrastructure even if it is different from a backbone (inter-city telecommunications) or an access provider (last-mile telecommunications). It may be useful to try to use more generic terms and fully describe the situation rather than splitting hairs with in-group jargon that was defined back when the Internet ecosystem's architecture was rather different from today. If we get rid of the term ISP, then things become clearer. Orgs which build and operate IP network infrastructure composed of one or more of, a) inter-city telecommmunications links b) last-mile telecommunications links c) network-connected data centers In other words backbones, Internet access and hosting (or PoPs). Probably should throw in language to indicate that it is not necessary to own the fiber in the ground, or the buildings, but that some indication of long-term leases for these is needed. > Perhaps the S. in I.S.P. should be pluralized because nowadays there > are more than one type of service. Or perhaps the term "services > provider" should be used in lieu of the acronym ISP. Bad move. Then it becomes totally ambiguous and includes companies that are not in any way involved in telecommunications. --Michael Dillon From owen at delong.com Mon Apr 30 09:55:30 2007 From: owen at delong.com (Owen DeLong) Date: Mon, 30 Apr 2007 06:55:30 -0700 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <4635E419.1030801@neovera.com> References: <4635E419.1030801@neovera.com> Message-ID: <2238D069-1BA8-4387-A841-E5C1FFEFF28E@delong.com> 1. I don't believe my proposed definition in any way excludes ASP or colo. providers. In fact, I have worked with a number of colo. and ASP providers who meet that definition. 2. If you examine the full v6 policy in the NRPM, you will notice that there are methods for v6-only qualification as well as the method in question for qualification based on existing v4 status. The intent of this policy is to facilitate migration, not to be the complete v6 policy. Owen On Apr 30, 2007, at 5:42 AM, Michael Hertrick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > There has already been a lot said regarding this topic, and while I > have read much of it I honestly have not read every last word posted. > I did search the thread for keywords like web hosting and > colocation/co-location, and ASP and found nothing, so I believe that > most of what I am about to say is not redundant. > > I think that today's definition of ISP not not limited to user access, > transit, and backbone services as it once was. Companies providing > web hosting and co-location services should be considered ISPs. For > that matter, there are also companies that call themselves ASPs, > Application Service Providers, that have the same Internet number > needs as ISPs. I suppose that an ASP is an ISP even though the > inverse is not necessarily true. There are undoubtedly many Internet > related services that would constitute a company's recognition as an > Internet Service Provider. Does the ARIN staff acknowledge that? > > In response to the numerous recommendations that IPv4 has some > influence on the IPv6 policies, I think that the definition of > "existing, known ISP in the ARIN region" needs to remain somewhat > ambiguous. A company should be defined by what they do rather than > how they happen to fit the IPv4 policy. To exclude companies based on > how they comply with IPv4 policies would be unfair because those > policies were only intended to apply to IPv4 address allocation. > Therefore IPv6 allocations should be available to companies that > provide Internet services. > > Perhaps the S. in I.S.P. should be pluralized because nowadays there > are more than one type of service. Or perhaps the term "services > provider" should be used in lieu of the acronym ISP. > > > Thanks, > ~Mike. > > > Owen DeLong wrote: >> According to Leslie, ARIN staff would like community input on the >> definition of "Existing Known ISP" in the NRPM. >> >> I would propose that the following definition seems self-evident >> to me, >> but, I would like to see what others here have to say: >> >> "An existing, known ISP is any ARIN Subscriber Organization who has >> received an IPv4 allocation from ARIN or an ARIN predecessor which >> now is an ARIN Subscriber Organization." >> >> Owen >> >> --------------------------------------------------------------------- >> - >> >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFGNeQZcJVdtfpkLb8RAowfAJ4r3dkk3tTvb5cczD325irxh0lv0ACff+4s > 59a3VrNkkJ3GTkXpbTbniUs= > =qRcM > -----END PGP SIGNATURE----- > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From stephen at sprunk.org Mon Apr 30 10:06:32 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 30 Apr 2007 09:06:32 -0500 Subject: [ppml] Definition of "Existing Known ISP" References: <4635E419.1030801@neovera.com> Message-ID: <00cd01c78b30$c70eb770$363816ac@atlanta.polycom.com> Thus spake "Michael Hertrick" > I think that today's definition of ISP not not limited to user access, > transit, and backbone services as it once was. Companies > providing web hosting and co-location services should be > considered ISPs. For that matter, there are also companies that > call themselves ASPs, Application Service Providers, that have > the same Internet number needs as ISPs. I suppose that an ASP > is an ISP even though the inverse is not necessarily true. There > are undoubtedly many Internet related services that would > constitute a company's recognition as an Internet Service Provider. > Does the ARIN staff acknowledge that? I've heard comments to that effect. I've also heard comments that such folks often claim they're _not_ ISPs because getting direct space as an end-user org is much easier than as an ISP. I think that the common definition of ISP is pretty clear. However, I think that referencing "ISP" in the v4/v6 policy in the first place is inappropriate. The v4 policy should be modified to say "LIR" everywhere it currently says "ISP". That allows non-ISP LIRs, such as ASPs, web hosters, colo houses, etc. who meet the requirements for a direct allocation to become LIRs and get all the same services as ISPs. Also, I would propose that an LIR is any organization that sells some sort of IP connectivity and whose assignments to other orgs are _other than_ incidental to their business (for instance, McDonald's assigning space to its stores is incidental to selling burgers, therefore they shouldn't be an LIR). > In response to the numerous recommendations that IPv4 has > some influence on the IPv6 policies, I think that the definition of > "existing, known ISP in the ARIN region" needs to remain > somewhat ambiguous. In contrast, I think it's completely broken because it's _not_ ambiguous. v6 policy doesn't reference ISPs at all except in that bullet point. However, since v4 policy currently talks about ISPs and not LIRs, it's hard to fix the v6 LIR qualification policy until the v4 policy is fixed. In the meantime, current v6 policy clearly says one must be an "existing, known ISP" to become a v6 LIR under that rule, and unfortunately that's what our answers to Leslie must be based on. Proposals welcome. [ Of course, one doesn't need to be an "existing, known ISP" if one has a plan for making 200 assignments within five years. ] S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From sil at infiltrated.net Mon Apr 30 14:06:45 2007 From: sil at infiltrated.net (J. Oquendo) Date: Mon, 30 Apr 2007 14:06:45 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: References: <4635E419.1030801@neovera.com> Message-ID: <46363035.7040604@infiltrated.net> michael.dillon at bt.com wrote: > > Companies providing services that include connectivity to the Internet > are Internet Service Providers. Not just the ones which provide > Internet access services. Seems reasonable. > > Orgs which build and operate IP network infrastructure composed of one > or more of, > > a) inter-city telecommmunications links > b) last-mile telecommunications links > c) network-connected data centers > > In other words backbones, Internet access and hosting (or PoPs). > Probably should throw in language to indicate that it is not necessary > to own the fiber in the ground, or the buildings, but that some > indication of long-term leases for these is needed. > > > Bad move. Then it becomes totally ambiguous and includes companies that > are not in any way involved in telecommunications. > > > My company was recently shot down on a /21 because we "didn't fit the profile" of an ISP. My company provides VoIP services including a couple of entire county infrastructures (Mayor's office included) and a couple of Universities dormitories, as well as some prep schools. Because we also have to deal with e911 services and provide managed PBX services, it became difficult for us to keep a NAT'd insane scheme we had working and we requested a /21 knowing that 80% of that would have been filled the moment we'd gotten it. So off went the submission, in came the rejection. I sincerely hope you guys can re-define the term ISP to fit today's criteria. Org's composed of the inner-city, last-mile links and network-connected data centers aren't the only ones who should fall under these rules. I've seen spammers get blocks quicker then I got a response telling me my /21 was shot down. -- ==================================================== J. Oquendo http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743 echo infiltrated.net|sed 's/^/sil@/g' "Wise men talk because they have something to say; fools, because they have to say something." -- Plato -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5157 bytes Desc: S/MIME Cryptographic Signature URL: From owen at delong.com Mon Apr 30 16:26:25 2007 From: owen at delong.com (Owen DeLong) Date: Mon, 30 Apr 2007 13:26:25 -0700 Subject: [ppml] Revised Policy Proposal Resource Reclamation Message-ID: The following text replaces the previous version of this policy submitted by me. It incorporates my concerns into a better written policy originally drafted by Stephen Sprunk who now joins me as a co-author. 1. Policy Proposal Name: Reclamation of Number Resources 2. Author a. name: Owen DeLong, Stephen Sprunk b. email: owen at delong.com, stephen at sprunk.org c. telephone: +1.408.921.6984, +1 214 718-3791 d. organization: None Claimed 3. Proposal Version: 1.1 4. Submission Date: ? 5. Proposal type: modify 6. Policy term: permanent 7. Policy statement: Add a new sub-section under General Policies as follows: Resource Reclamation 1. ARIN may review the current usage of any resources allocated or assigned to an organization. The organization shall furnish whatever records are necessary to perform this review. 2. ARIN may conduct such reviews: a. when any new resource is requested, b. whenever ARIN has cause to believe that the resources had originally been obtained fraudulently, or c. at any other time without cause unless a prior review has been completed in the preceding 12 months. 3. ARIN shall communicate the results of the review to the organization. 4. If the review shows that existing usage is substantially not in compliance with current allocation and/or assignment policies, the organization shall return resources as required to bring them into compliance. If an organization holds multiple ARIN delegations, they may return any number of whole delegations necessary to restore compliance. If an organization holds a single ARIN delegation, they shall return a single aggregate portion of the delegation to restore compliance. 5. If the organization does not voluntarily return resources as required, ARIN may revoke any resources as required to bring the organization into compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 6. Return or revocation of resources shall be immediate for billing purposes. 7. ARIN shall not issue any returned or revoked resources to another organization for a minimum of six months after reclamation. ARIN shall negotiate a longer term with the resource holder if ARIN believes the resource holder is working in good faith to restore compliance and has a valid need for additional time to renumber out of the affected blocks. 8. The whois database shall indicate that such blocks are scheduled for reclamation and shall display the date determined under the previous paragraph. Delete sections 4.1.2, 4.1.3, 4.1.4 Remove the sentence "In extreme cases, existing allocations may be affected." from section 4.2.3.1. 8. Rationale: ARIN feels that current policy does not give them the power to audit or reclaim resources except in cases of fraud, despite this being mentioned in the Registration Services Agreement. This policy proposal provides clear policy authority to do so, guidelines for how and under what conditions it shall be done, and a guarantee of a (minimum) six-month grace period so that the current user shall have time to stop using any resources to be reclaimed. The deleted sections/text would be redundant with the adoption of this proposal. 9. Timetable for implementation: immediate 10. Meeting presenter: Owen DeLong -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From sleibrand at internap.com Mon Apr 30 17:34:45 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 30 Apr 2007 14:34:45 -0700 Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: References: Message-ID: <463660F5.9030109@internap.com> I would support this (or a substantially similar) policy proposal. I had always read existing policy as implicitly granting ARIN this authority, and I believe this proposal reasonably outlines such authority. -Scott Owen DeLong wrote: > The following text replaces the previous version of this policy > submitted by > me. It incorporates my concerns into a better written policy > originally drafted > by Stephen Sprunk who now joins me as a co-author. > > > 1. Policy Proposal Name: Reclamation of Number Resources > 2. Author > a. name: Owen DeLong, Stephen Sprunk > b. email: owen at delong.com, stephen at sprunk.org > c. telephone: +1.408.921.6984, +1 214 718-3791 > d. organization: None Claimed > 3. Proposal Version: 1.1 > 4. Submission Date: ? > 5. Proposal type: modify > 6. Policy term: permanent > 7. Policy statement: > > Add a new sub-section under General Policies as follows: > > Resource Reclamation > 1. ARIN may review the current usage of any resources > allocated or assigned to an organization. The organization shall > furnish whatever records are necessary to perform this review. > 2. ARIN may conduct such reviews: > a. when any new resource is requested, > b. whenever ARIN has cause to believe that the resources > had originally been obtained fraudulently, or > c. at any other time without cause unless a prior review > has been completed in the preceding 12 months. > 3. ARIN shall communicate the results of the review to the > organization. > 4. If the review shows that existing usage is substantially > not in compliance with current allocation and/or assignment policies, > the organization shall return resources as required to bring them into > compliance. If an organization holds multiple ARIN delegations, they > may return any number of whole delegations necessary to restore > compliance. If an organization holds a single ARIN delegation, they > shall return a single aggregate portion of the delegation to restore > compliance. > 5. If the organization does not voluntarily return resources > as required, ARIN may revoke any resources as required to bring the > organization into compliance. ARIN shall follow the same guidelines > for revocation that are required for voluntary return in the previous > paragraph. > 6. Return or revocation of resources shall be immediate for > billing purposes. > 7. ARIN shall not issue any returned or revoked resources to > another organization for a minimum of six months after reclamation. > ARIN shall negotiate a longer term with the resource holder if ARIN > believes the resource holder is working in good faith to restore > compliance and has a valid need for additional time to renumber out of > the affected blocks. > 8. The whois database shall indicate that such blocks are > scheduled for reclamation and shall display the date determined under > the previous paragraph. > > > Delete sections 4.1.2, 4.1.3, 4.1.4 > > Remove the sentence "In extreme cases, existing allocations may be > affected." from section 4.2.3.1. > > 8. Rationale: > > ARIN feels that current policy does not give them the power to audit > or reclaim resources except in cases of fraud, despite this being > mentioned in the Registration Services Agreement. This policy > proposal provides clear policy authority to do so, guidelines for how > and under what conditions it shall be done, and a guarantee of a > (minimum) six-month grace period so that the current user shall have > time to stop using any resources to be reclaimed. > > The deleted sections/text would be redundant with the adoption of this > proposal. > > 9. Timetable for implementation: immediate > 10. Meeting presenter: Owen DeLong > > ------------------------------------------------------------------------ > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From matt.pounsett at cira.ca Mon Apr 30 18:19:58 2007 From: matt.pounsett at cira.ca (Matt Pounsett) Date: Mon, 30 Apr 2007 18:19:58 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <4635E419.1030801@neovera.com> References: <4635E419.1030801@neovera.com> Message-ID: <0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30-Apr-2007, at 08:42 , Michael Hertrick wrote: > I think that today's definition of ISP not not limited to user access, > transit, and backbone services as it once was. Companies providing > web hosting and co-location services should be considered ISPs. For > that matter, there are also companies that call themselves ASPs, > Application Service Providers, that have the same Internet number > needs as ISPs. I suppose that an ASP is an ISP even though the > inverse is not necessarily true. There are undoubtedly many Internet > related services that would constitute a company's recognition as an > Internet Service Provider. Does the ARIN staff acknowledge that? I agree with much of what you're saying here and in the rest of your email, but I don't completely agree with where you end up. All ASPs, web hosting companies, and colo providers are not ISPs in the sense that the term is used in the NRPM. I think it's important to look at the intent of the policy in order to find a better definition for "ISP" or to find a different word to use. The defining characteristic of an "ISP" as referenced in the NRPM is that the organization reassigns address space to organizations other than itself. Most web hosting companies and ASPs that I've seen do not fit this model, and are actually end users (though in some cases very large end users), and I think most colo providers do fit this model and should be classed as ISPs. I think Steven Sprunk is on the right track, that we should perhaps be looking at using a new term (such as LIR) for these non-end-user organizations. That would go a long way to helping clear up confusion. Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFGNmuSae4z2vjbC8sRArjpAJ9iSdpsIurYfy+uauwGXKOV123dtACffUCk X+tlH9c7RptfWmNkYLK+BRE= =/VCn -----END PGP SIGNATURE----- From bicknell at ufp.org Mon Apr 30 18:57:15 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 30 Apr 2007 18:57:15 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <4635E419.1030801@neovera.com> References: <4635E419.1030801@neovera.com> Message-ID: <20070430225715.GA87639@ussenterprise.ufp.org> In a message written on Mon, Apr 30, 2007 at 08:42:01AM -0400, Michael Hertrick wrote: > I think that today's definition of ISP not not limited to user access, > transit, and backbone services as it once was. Companies providing > web hosting and co-location services should be considered ISPs. For We have an unfortunate overloading terms. ISP is a term used by people to talk about a broad catagory of companies that provide some sort of Internet based service. Web hosting, NSP's, ASP's, dial up providers, all sorts of companies. Unfortunately none of these have anything to do with the ARIN defintion of an ISP. ARIN has a section of the PPML manual dealing with ISP's: http://www.arin.net/policy/nrpm.html#four2 I quote: ] 4.2.1.1. Purpose ] ] ARIN allocates blocks of IP addresses to Internet Service Providers ] (ISPs) for the purpose of reassigning that space to their customers. So for ARIN's purposes an ISP is someone who received a block of IP space from ARIN, for the purpose of reassigning space to their customers. They also fall under the ISP fee schedule. Compare and contrast, they are not end users, they are not RIPE members, they are not APNIC members, and they are not Legacy space holders; although of course an "ARIN ISP" may be any of the above as well. I personally think it's unfortunate the policy manual uses the term ISP, because it is misleading. I don't have a better one to suggest though. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From kevin at your.org Mon Apr 30 19:19:03 2007 From: kevin at your.org (Kevin - Your.Org) Date: Mon, 30 Apr 2007 18:19:03 -0500 Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: References: Message-ID: On Apr 30, 2007, at 3:26 PM, Owen DeLong wrote: > 2. ARIN may conduct such reviews: > a. when any new resource is requested, > b. whenever ARIN has cause to believe that the resources had > originally been obtained fraudulently, or > c. at any other time without cause unless a prior review has > been completed in the preceding 12 months. I'm fine with A and B, but I can't say I support clause C in there as it's written. While I don't think anyone at ARIN is malicious or would conduct reviews unnecessarily, this strikes me as a blank check to get an undefined "audit" every year that would require furnishing arbitrary amounts of paperwork to comply. Getting paperwork and justification materials together when requesting additional space is a predictable cost that can be planned for in advance, and argued that it's necessary for business expansion or whatever. More space = more revenue, so it's an investment. And, the worst case that can happen there is you walk away no worse off than you started, if the expenses/time required exceed what it's worth to you. Especially for a small business where regular allocation requests aren't made, these costs can be significant. A random inspection is at least as much effort, more risk (you risk losing what you already have if you're unable to satisfy whatever undocumented requirements there are for this) so you're probably going to have to invest more time/money in making sure you get it right, and a money hole in terms of what you get out of it. I can only see three reasons why an audit would need to take place. You're asking for more space(you initiate this, you're planning for it in advance, and you can walk away if you get in over your head), you lied on your last application(all you would have to do is prove you didn't lie), or whatever justification you used in a previous application doesn't apply anymore(you've downsized and you really should be giving space back.) Are there any other reasons why an audit should take place, other than "because someone felt like it"? If not, spell that out. I'd support: 2. ARIN may conduct such reviews: a. when any new resource is requested, b. whenever ARIN has cause to believe that the resources had originally been obtained fraudulently, or c. whenever ARIN has cause to believe the justification for the resources no longer exists. Along with some kind of definition of exactly what a review entails, how much time you have to respond to one, can it be appealed, etc. As your proposal stands, it seems like ARIN can request arbitrary amounts of paperwork While I understand that several people's interpretations of the existing policy already gives ARIN the right to do this now, if we're going to enumerate this policy specifically, don't turn it into the ability to audit every organization every year without cause, with no definition of what an audit even is, how the procedure is supposed to work, or why you can get audited. -- Kevin From michael.dillon at bt.com Mon Apr 30 19:20:44 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 1 May 2007 00:20:44 +0100 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <20070430225715.GA87639@ussenterprise.ufp.org> References: <4635E419.1030801@neovera.com> <20070430225715.GA87639@ussenterprise.ufp.org> Message-ID: > I personally think it's unfortunate the policy manual uses the term > ISP, because it is misleading. I don't have a better one to suggest > though. The rest of the world uses the term, LIR, something which is totally meaningless and therefore could be precisely and unambiguously defined by the RIRs. Note that ARIN uses the term LIR in the IPv6 policy. Local Internet Registry has a vague whiff of an org that gets IP addresses and gives them to others, but only to those who already understand RIR stuff. The big question is, do all occurences of the term "ISP" in ARIN's policy and other documents, actually refer to the narrow definition of an LIR, or is ARIN also sometimes using the term with other contexts in mind. --Michael Dillon From Ed.Lewis at neustar.biz Mon Apr 30 21:54:02 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 30 Apr 2007 21:54:02 -0400 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: <0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca> References: <4635E419.1030801@neovera.com> <0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca> Message-ID: Having been hyperactive this past week on the mailing list I waited to jump in on this" - hoping to read a post with the same sentiment that I have. And I have. At 18:19 -0400 4/30/07, Matt Pounsett wrote: >I agree with much of what you're saying here and in the rest of your >email, but I don't completely agree with where you end up. All ASPs, >web hosting companies, and colo providers are not ISPs in the sense >that the term is used in the NRPM. I think it's important to look at >the intent of the policy in order to find a better definition for >"ISP" or to find a different word to use. Metoo. We aren't trying to define what an ISP is, we are trying to distinguish between organizations in the context of the policies of ARIN. So, the arguments that we all are ISPs are (arguably) right, but what we really need is to distinguish between organizations getting resources for themselves and organizations getting resources for their "customers." >model and should be classed as ISPs. I think Steven Sprunk is on the >right track, that we should perhaps be looking at using a new term >(such as LIR) for these non-end-user organizations. That would go a >long way to helping clear up confusion. At first I disagreed with the use of the term "LIR," but what Matt adds on here makes me think that that might be the right thing to do. Historically ARIN has used ISP and "the other" RIRs use LIR and I always thought that it was just a terminology thing. But it is true - we aren't distinguishing between ISPs and ASPs, rather LIRs from end-users of the resources. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From paul at vix.com Mon Apr 30 19:27:37 2007 From: paul at vix.com (Paul Vixie) Date: Mon, 30 Apr 2007 23:27:37 +0000 Subject: [ppml] Definition of "Existing Known ISP" In-Reply-To: Your message of "Mon, 30 Apr 2007 18:19:58 -0400." <0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca> References: <4635E419.1030801@neovera.com> <0EEA620C-6E34-4462-88EE-A1D9E00B11A3@cira.ca> Message-ID: <2316.1177975657@sa.vix.com> > > I think that today's definition of ISP not not limited to user access, > > transit, and backbone services as it once was. Companies providing > > web hosting and co-location services should be considered ISPs. For > > that matter, there are also companies that call themselves ASPs, > > Application Service Providers, that have the same Internet number > > needs as ISPs. ... > I agree with much of what you're saying here and in the rest of your email, > but I don't completely agree with where you end up. All ASPs, web hosting > companies, and colo providers are not ISPs in the sense that the term is > used in the NRPM. ... > > The defining characteristic of an "ISP" as referenced in the NRPM is that > the organization reassigns address space to organizations other than itself. > ... and I think most colo providers do fit this model and should be classed > as ISPs. if an asp or web hosting company allocates a /32 to an organization other than itself, for example a customer with an SSL service (where it's impossible due to the protocol design to put more than one customer on an IP address) then they are in my opinion, by ARIN's current definition, an ISP. they also need portable multihomable address space since it is otherwise impossible, due to the routing system design, to compete on reachability and price level against larger/older providers. ARIN doesn't do protocol design like SSL nor routing system design like BGP, but we have to recognize the effects on the industry of design choices made in those protocols and systems. note that these are my opinions alone, and may not reflect those of the board of trustees, nor my daytime employer.