From owen at delong.com Sun Oct 2 20:32:56 2005 From: owen at delong.com (Owen DeLong) Date: Sun, 02 Oct 2005 17:32:56 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - Revised Text In-Reply-To: <01e001c5c607$63706c30$6501a8c0@dax> References: <433D8FF6.7010304@hotnic.net> <01e001c5c607$63706c30$6501a8c0@dax> Message-ID: Let's see if we can get the following kind of consensus gauge at the meeting: 1. Everyone who would support this proposal at 100,000 devices 1/year, raise your hands. 2. Keep 'em up... Everyone who would not support 100,000 devices 2/years, put your hands down. 3. Keep 'em up... If you would not support 50,000 devices 2/years, put your hand down. 4. If you would not support 25,000 devices 2/years, put your hand down. Whenever we get below say 60% of the room, call the previous mark consensus? Owen --On September 30, 2005 4:18:52 PM -0500 Stephen Sprunk wrote: > Thus spake "Kevin Loch" >> Hannigan, Martin wrote: >>> The rationale is to be conservative, but holding this to only the >>> Fortune 10 and cellular carriers seems to be slightly tilted towards >>> detrimental to the adaptation and use of IPV6. >> >> I agree. what number would you pick to balance conservation >> with encouraging deployment? > > My two cents: the lowest possible number that will still get approval. > Martin's 25k/2yrs sounds much more reasonable than 100k/1yr, and I would > hope others here would back that. Could we go even lower safely? I'm > not sure. > > Does anyone have any stats on the number of ISPs and businesses that > would qualify at various levels? > > 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 > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From paul at vix.com Mon Oct 3 15:20:02 2005 From: paul at vix.com (Paul Vixie) Date: Mon, 03 Oct 2005 19:20:02 +0000 Subject: [ppml] tony hain speaks out about ipv4 address space consumption Message-ID: <20051003192002.5B25C11449@sa.vix.com> http://www.cisco.com/application/pdf/en/us/guest/about/about/c644/ccmigration_09186a00805320df.pdf From william at elan.net Sun Oct 23 06:09:56 2005 From: william at elan.net (william(at)elan.net) Date: Sun, 23 Oct 2005 03:09:56 -0700 (PDT) Subject: [ppml] Regarding private residence listing recommendations athttp://www.arin.net/registration/guidelines/report_reassign.html Message-ID: I noticed that at http://www.arin.net/registration/guidelines/report_reassign.html it says under "IPv4 Reassign-Simple" section (and similar text in the next section for "IPv6 Reassign"). When registering residential customers, ARIN recommends the phrase "Private Residence" for the address. ISPs should provide the person's name, city, state, postal code, and country to complement the private residence designation. I'd like to inquire why this "recommendation" is in this guidelines as I believe it is not an appropriate derivation of current ARIN policies which make no such recommendation and simply give ISPs an option if (if requested from residential customer) to not list an address for residential customers and substitute that with phrase "Private Residence". I believe making it a recommendation has an effect that it may appear to ISPs that they should be doing it for all residential customers in-regardless if those customers requested to keep their address private or not. This is very different then current scenario with white and yellow books in the US where residential users have to specifically ask phone company to be excluded and not the other way around. P.S. I may bring this topic us as remote participant at the open mic, but I'll try to make information about it short and assume that people in the audience have read this message. But if we can deal with it on the list before ARIN meeting that would be better. -- William Leibzon Elan Networks william at elan.net From william at elan.net Sun Oct 23 06:37:48 2005 From: william at elan.net (william(at)elan.net) Date: Sun, 23 Oct 2005 03:37:48 -0700 (PDT) Subject: [ppml] Maps for RIR regions not correct Message-ID: At http://www.arin.net/community/RIPEcountries.html and http://www.arin.net/community/APNICcountries.html the maps are not correct. In particular they identify Central Asian countries that were formerly part of Soviet Union as being in the APNIC region where as those countries receive ip space from RIPE (they are properly listed in the list of countries - its only the maps that are wrong). P.S. No need to reply especially on the list unless I'm wrong in above. I'm ccing the list just in case and main message is addressed to ARIN webmaster. -- William Leibzon Elan Networks william at elan.net From Michael.Dillon at btradianz.com Mon Oct 24 04:47:55 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 24 Oct 2005 09:47:55 +0100 Subject: [ppml] Technical error was ( Regarding private residence... ) In-Reply-To: Message-ID: > When registering residential customers, ARIN recommends the phrase > "Private Residence" for the address. ISPs should provide the > person's name, city, state, postal code, and country to complement the > private residence designation. There is a technical error in this recommendation. It assumes that by replacing the street name and number with the term "Private Residence", that ARIN is providing some privacy for residential customers. This is simply not true. For example, go to this page: http://www.westminster.ca/index.html and enter the postal code "N2L 3A7" and then click the circle labeled "lookup this address". You will see that this postal code refers to odd addresses on Central Streeet, Waterloo, Ontario in the range 35-43. In other words, either 35, 37, 39, 41 or 43. What privacy is provided to a residential customer when their home location is pinpointed to an accuracy of within 5 possible houses? I believe that the US full zipcode provides similar pinpoint accuracy. If there is no intent to enable people to knock on someone's door, then there should be no address at all in the ARIN whois database. To date, nobody has given any good reasons for why end user contact information is in the ARIN whois directory. The desire of SPAM hunters to shakedown innocent people in the hunt for spammers, is not a good reason. I support the requirement for network operators of all sizes to be listed in the whois directory, but non-technical end users who are not in charge of operating any network, should not be in this directory. The ARIN whois directory is not an Internet phonebook! Any addresses used by non-operator customers of an ISP should be traced back to the ISP, not to the non-operator customers. --Michael Dillon From william at elan.net Mon Oct 24 06:29:29 2005 From: william at elan.net (william(at)elan.net) Date: Mon, 24 Oct 2005 03:29:29 -0700 (PDT) Subject: [ppml] Technical error was ( Regarding private residence... ) In-Reply-To: References: Message-ID: Michael, Do you believe it is appropriate for phone companies to publish phone books with everyone's name and phone number and with their address? Now when you order a phone line, the phone company would at the end ask you if you want the phone number made public or not (they did every time I ordered lines which is 3 times for residences so far). I'm arguing that the same should be done for ip addresses and that ISPs during provisioning process should give an option for users to decide if their information is to be entered in whois without ISPs making a decision on their behalf using some kind of ARIN "recommendation". Now - note that for ip addresses we're not talking about everyone being listed, it already only applies to users who get enough ip space to qualify for reassignment listing and most of these are not novices but usually those who ask for multiple static ip addresses run some kind of network operation at home and often enough with public internet presence using their dsl line (be it for-profit small business or some non-profit user activity). BTW - All these listings are typically of not much use for "SPAM hunters" as spammers are really not going to provide their real addresses for public database if they have a choice (and residential privacy policy gives this choice), nor is the spam coming from dsl lines is really from the users who actually ordered these lines (its all zombies). There is however certain value that can be obtained from this information for statistical purposes to determine grown rate of internet use in specific area. On Mon, 24 Oct 2005 Michael.Dillon at btradianz.com wrote: >> When registering residential customers, ARIN recommends the phrase >> "Private Residence" for the address. ISPs should provide the >> person's name, city, state, postal code, and country to complement the >> private residence designation. > > There is a technical error in this recommendation. > It assumes that by replacing the street name and > number with the term "Private Residence", that ARIN > is providing some privacy for residential customers. > This is simply not true. > > For example, go to this page: > http://www.westminster.ca/index.html > and enter the postal code "N2L 3A7" and then click > the circle labeled "lookup this address". You will > see that this postal code refers to odd addresses > on Central Streeet, Waterloo, Ontario in the range > 35-43. In other words, either 35, 37, 39, 41 or 43. > > What privacy is provided to a residential customer > when their home location is pinpointed to an accuracy > of within 5 possible houses? I believe that the US > full zipcode provides similar pinpoint accuracy. > > If there is no intent to enable people to knock > on someone's door, then there should be no address > at all in the ARIN whois database. > > To date, nobody has given any good reasons for why > end user contact information is in the ARIN whois > directory. The desire of SPAM hunters to shakedown > innocent people in the hunt for spammers, is not > a good reason. > > I support the requirement for network operators > of all sizes to be listed in the whois directory, but > non-technical end users who are not in charge of > operating any network, should not be in this directory. > The ARIN whois directory is not an Internet phonebook! > > Any addresses used by non-operator customers of an > ISP should be traced back to the ISP, not to the non-operator > customers. > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From Michael.Dillon at btradianz.com Mon Oct 24 07:19:27 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 24 Oct 2005 12:19:27 +0100 Subject: [ppml] Technical error was ( Regarding private residence... ) In-Reply-To: Message-ID: > Do you believe it is appropriate for phone companies to publish phone > books with everyone's name and phone number and with their address? As I said, the ARIN whois directory is NOT a phone book. > Now - note that for ip addresses we're not talking about everyone being > listed, it already only applies to users who get enough ip space to > qualify for reassignment listing and most of these are not novices but Most of them? Where is your data? As I said, we should only have network operators in the whois directory. There is no advantage to having lots of other records mixed in there. > There is however certain value that can be obtained from this > information for statistical purposes to determine grown rate of > internet use in specific area. That is a different question. If the ARIN community felt that there was some value in using the whois directory for statistical analyses, then why was there no support for this proposal? http://www.arin.net/policy/proposals/2004_4.html The relevant parts are section 7. and explanatory point i). 7. The records mentioned in item 6 will not identify the organization or individual receiving the address block or their exact location. These records will only indicate an organizational type, the nearest municipality providing postal service to the end user, state/province and country. i) The classification system for organization types has been intentionally left unspecified. Obviously, it needs to include "individual" as a type but it could include NAICS sector codes, e.g. "NAICS 25" is the construction industry. It could also include NTEE codes for non-profits e.g. "NTEE H" is Medical research. And it could include some simple codes like "Company", "Non-Profit", "Education", "Government" for users who don't know about the various classification systems. If statistical analysis is an important role for the whois directory then people need to speak up about it. --Michael Dillon From Lee.Howard at stanleyassociates.com Mon Oct 24 09:29:35 2005 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 24 Oct 2005 09:29:35 -0400 Subject: [ppml] Technical error was ( Regarding private residence... ) Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB471E54B@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Michael.Dillon at btradianz.com > Sent: Monday, October 24, 2005 7:19 AM > To: ppml at arin.net > Subject: Re: [ppml] Technical error was ( Regarding private > residence... ) > > > Do you believe it is appropriate for phone companies to > publish phone > > books with everyone's name and phone number and with their address? > > As I said, the ARIN whois directory is NOT a phone book. > > > Now - note that for ip addresses we're not talking about > everyone being > > listed, it already only applies to users who get enough ip space to > > qualify for reassignment listing and most of these are not > novices but > > Most of them? Where is your data? > As I said, we should only have network operators in the > whois directory. There is no advantage to having lots of other > records mixed in there. Do you mean "network operator" in the NANOG sense, or in the sense of someone who operates a network? Listings in whois [1] are for /29 or greater, meaning multiple hosts, i.e., a network. Network operators in either sense may be listed [2]; the person responsible for resolving network issues should be listed. > If statistical analysis is an important role for the whois > directory then people need to speak up about it. People did, which is why there's a bulk whois policy. > > --Michael Dillon Lee [1] APID, as Leo would have it [2] or not, for residences, at the discretion of the assignor From Michael.Dillon at btradianz.com Mon Oct 24 09:52:59 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 24 Oct 2005 14:52:59 +0100 Subject: [ppml] Technical error was ( Regarding private residence... ) In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB471E54B@CL-S-EX-1.stanleyassociates.com> Message-ID: > Do you mean "network operator" in the NANOG sense, or in the > sense of someone who operates a network? The second sense which includes the former. > Listings in whois [1] > are for /29 or greater, meaning multiple hosts, i.e., a network. This does not mean that the person who pays for Internet access is the operator of the network. Let's imagine a guy named Lee living in Virginia with a grandmother in California. Grandma orders Internet access for her home network which was designed by grandson Lee. She gets a /29 assignment as requested. Lee flies over and sets up the network including various remote network management tools. If there are any network problems, Grandma calls Lee who logs in remotely and fixes them. Who operates this network? I would argue that Lee in Virginia is the network operator. If the California ISP puts Grandma's contact info in the whois directory then I believe they are doing the wrong thing. They should be asking the question... > Network operators in either sense may be listed [2]; the person > responsible for resolving network issues should be listed. "Who resolves network issues for this /29?" The correct answer is "Lee in Virginia" so they should answer with that. If there is any uncertainty about who is the real technical contact, then they should list THEMSELVES as the network operator. Uncertainty could be there on day 1 when it is clear that Grandma is no technical wizard. Or it could arise at a later date when the California ISP does its annual update of contact records and discovers that Lee in Virginia has moved on and not left an updated address and phone number. > > If statistical analysis is an important role for the whois > > directory then people need to speak up about it. > > People did, which is why there's a bulk whois policy. That is an awfully weak response. ARIN has always made bulk whois data available. But ARIN has never accepted that statistical analysis is a justification for collecting whois data. And ARIN has never asked "What statistical information is useful to researchers and is it justified to collect such statistical info?". People hunting down spammers are not the only "researchers" out there. It is my understanding that the bulk whois policy is just ensuring that people which had access to the existing data, continue to have access. I believe that statistical analysis is a good thing and that ARIN should facilitate such analysis. But making available the existing bad and incomplete data does not serve the goal of statistical analysis very well. If an effort was made to provide clean data and relevant data, then there would be a lot more justification for the whois directory than there is today. When you compare ARIN's record on this to the record of RIPE or APNIC, then ARIN looks like the poor second cousin wearing ragged hand-me-downs that grandpa used to wear. --Michael Dillon P.S. the whole "private residence" issue is still based on a flawed assumption. Hiding the street address is not sufficient to provide privacy when a postal code is in the directory. From Lee.Howard at stanleyassociates.com Mon Oct 24 11:13:26 2005 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 24 Oct 2005 11:13:26 -0400 Subject: [ppml] Technical error was ( Regarding private residence... ) Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB471E5BA@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Michael.Dillon at btradianz.com > Sent: Monday, October 24, 2005 9:53 AM > To: ppml at arin.net > Subject: Re: [ppml] Technical error was ( Regarding private > residence... ) > > > Do you mean "network operator" in the NANOG sense, or in the > > sense of someone who operates a network? > > The second sense which includes the former. > > > Listings in whois [1] > > are for /29 or greater, meaning multiple hosts, i.e., a network. > > Who operates this network? I would argue that Lee > in Virginia is the network operator. If the California > ISP puts Grandma's contact info in the whois directory > then I believe they are doing the wrong thing. They > should be asking the question... Good example, but seems to me that the answer could be to list Lee in VA or the ISP; either one is valid, and it's a local decision. > > People did, which is why there's a bulk whois policy. > > That is an awfully weak response. ARIN has always made > bulk whois data available. But ARIN has never accepted that > statistical analysis is a justification for collecting whois > data. And ARIN has never asked "What statistical information > is useful to researchers and is it justified to collect such > statistical info?". People hunting down spammers are not the > only "researchers" out there. It is my understanding that > the bulk whois policy is just ensuring that people which had > access to the existing data, continue to have access. My understanding is different. I recall several people offering examples of research other than spam vigilantes. > --Michael Dillon > > P.S. the whole "private residence" issue is still based on > a flawed assumption. Hiding the street address is not sufficient > to provide privacy when a postal code is in the directory. Agreed, and I remember you raising the point when the policy was discussed, and I agreed then. Is it enough to say "Postal code optional for residences" or do we need to prohibit, politically or systematically, ZIP when street is like "residence." Lee From heather.skanks at gmail.com Tue Oct 25 18:02:03 2005 From: heather.skanks at gmail.com (heather skanks) Date: Tue, 25 Oct 2005 18:02:03 -0400 Subject: [ppml] Technical error was ( Regarding private residence... ) In-Reply-To: References: Message-ID: <616812070510251502m4c92023md64fba916010cb31@mail.gmail.com> On 10/24/05, william(at)elan.net wrote: > > > ...... > > BTW - All these listings are typically of not much use for "SPAM hunters" > as spammers are really not going to provide their real addresses for > public database if they have a choice (and residential privacy policy > gives this choice), nor is the spam coming from dsl lines is really > from the users who actually ordered these lines (its all zombies). > There is however certain value that can be obtained from this > information for statistical purposes to determine grown rate of > internet use in specific area. I disagree, it's possible to have published real addresses -- Set aside the garbage that comes from dsl/cable modem users - and look only at that which comes from dedicated connections. With a few exceptions, most spammers don't get dedicated space directly from the RIR (which would require info to be public anyway - whether or not the info is good) For a variety of reasons, it's too expensive, you can't get the blocks swapped and it will get RBL'd quickly. So they go to their provider, and for suballocations to customers, don't give them a choice, don't ask them what address and contact info they want listed. List the info that they gave to turn up the circuit- which usually turns out to be where their noc is or where the circuit terminates. I agree that the info isn't of much use to spam hunters (tho it could be useful to others) - with the exception that it gives you one more point to find discrepencies or tie organizations together -- and arguably, that doesn't require the info to be valid. --heather On Mon, 24 Oct 2005 Michael.Dillon at btradianz.com wrote: > > >> When registering residential customers, ARIN recommends the phrase > >> "Private Residence" for the address. ISPs should provide the > >> person's name, city, state, postal code, and country to complement the > >> private residence designation. > > > > There is a technical error in this recommendation. > > It assumes that by replacing the street name and > > number with the term "Private Residence", that ARIN > > is providing some privacy for residential customers. > > This is simply not true. > > > > For example, go to this page: > > http://www.westminster.ca/index.html > > and enter the postal code "N2L 3A7" and then click > > the circle labeled "lookup this address". You will > > see that this postal code refers to odd addresses > > on Central Streeet, Waterloo, Ontario in the range > > 35-43. In other words, either 35, 37, 39, 41 or 43. > > > > What privacy is provided to a residential customer > > when their home location is pinpointed to an accuracy > > of within 5 possible houses? I believe that the US > > full zipcode provides similar pinpoint accuracy. > > > > If there is no intent to enable people to knock > > on someone's door, then there should be no address > > at all in the ARIN whois database. > > > > To date, nobody has given any good reasons for why > > end user contact information is in the ARIN whois > > directory. The desire of SPAM hunters to shakedown > > innocent people in the hunt for spammers, is not > > a good reason. > > > > I support the requirement for network operators > > of all sizes to be listed in the whois directory, but > > non-technical end users who are not in charge of > > operating any network, should not be in this directory. > > The ARIN whois directory is not an Internet phonebook! > > > > Any addresses used by non-operator customers of an > > ISP should be traced back to the ISP, not to the non-operator > > customers. > > > > --Michael Dillon > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weiler at tislabs.com Thu Oct 27 14:54:10 2005 From: weiler at tislabs.com (Samuel Weiler) Date: Thu, 27 Oct 2005 14:54:10 -0400 (EDT) Subject: [ppml] Technical error was ( Regarding private residence... ) Message-ID: I concur with the observation that including postal code effectively destroys the privacy intended by policy 2003-3, "Residential Customer Privacy". I interpret 2003-3 to allow suppression of all physical address information, up to and including country. If ARIN's interpretation is otherwise, I'd like to hear a clear statement of that. For reference: http://arin.net/policy/proposals/2003_3.html Furthermore, policy 2003-3 also allows the customers' name to be suppressed, and the recommendation, if any, should reflect that. And going back to the original complaint, I have no objection to ARIN encouraging the suppression of residential registrant information. In fact, I think that's a very good idea. Keeping the phone book analogy, most folks know that their phone number may be listed in the phone book and, if nothing else, they receive a copy of the phone book every year to remind them of that directory's existence. Absent that cultural expectation, I think it's better to default to suppression. -- Sam From william at elan.net Thu Oct 27 16:52:17 2005 From: william at elan.net (william(at)elan.net) Date: Thu, 27 Oct 2005 13:52:17 -0700 (PDT) Subject: [ppml] Technical error was ( Regarding private residence... ) In-Reply-To: References: Message-ID: On Thu, 27 Oct 2005, Samuel Weiler wrote: > And going back to the original complaint, I have no objection to ARIN > encouraging the suppression of residential registrant information. I'm not at all surprised that some/many don't objection to it - that is to be expected, but privacy & information-publication related debates have been going on both at ARIN and in country at large for long time showing very different opinions from various people on this topic. The point of the complaint was really that ARIN has decided unilaterally to recommend certain view which is not specified by the policies and has not undergone process of checking if consensus exist for this view. Its actually more general issue on what kind of recommendations are really appropriate for ARIN to make. I think the kind of recommendations that are ok are technical once where certain way is considered more efficient for ARIN to deal with (i.e. ARIN might recommend that ReassignmentSimple template be used if no POC would be entered for organization). > In fact, I think that's a very good idea. Keeping the phone book > analogy, most folks know that their phone number may be listed in the > phone book and, if nothing else, they receive a copy of the phone book > every year to remind them of that directory's existence. Absent that > cultural expectation, I think it's better to default to suppression. How can you find what "cultural expectation" is? And the "default no" view is actually not supported by what has been going on. Its always that congress or similar local government ended up having to specify that certain privacy data should or must not be released. I note also that in addition to phone book that you receive, personal data (including address) is also made available for all those who register to vote (and people don't receive book of registered voters in their community unlike the phone books...) and in many other cases you might or might not realize. -- William Leibzon Elan Networks william at elan.net From weiler at tislabs.com Thu Oct 27 18:17:41 2005 From: weiler at tislabs.com (Samuel Weiler) Date: Thu, 27 Oct 2005 18:17:41 -0400 (EDT) Subject: [ppml] Matching NRPM sections to policies Message-ID: I'd like to see ARIN go through the (wonderful) NRPM and 1) add more cross-references to the policies as adopted, much as a code of regulations may refer back to the enacting legislation and 2) add complete forward citations from the policy archive into the NRPM. Will the staff do that? For example: Section 6.5.5.1 cites the Residential Customer Privacy by number (2003-3), but the corresponding section about v4, 4.2.3.7.6, doesn't mention the policy number. Similarly, section 3.2 makes reference to this policy without citing it by number and perhaps making some errors in transcription (per the other thread). In the policy archive, 2003-3 mentions 4.2.3.7.6 as the section where the adopted policy was recorded, but does not mention the other two sections. -- Sam From woody at pch.net Thu Oct 27 20:30:37 2005 From: woody at pch.net (Bill Woodcock) Date: Thu, 27 Oct 2005 17:30:37 -0700 (PDT) Subject: [ppml] 2005-1 or its logical successor Message-ID: I say we go back to what owendelongtellmenetworks proposed, and see if there was anything we actually didn't like about it. -Bill From william at elan.net Thu Oct 27 20:38:07 2005 From: william at elan.net (william(at)elan.net) Date: Thu, 27 Oct 2005 17:38:07 -0700 (PDT) Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: Message-ID: +1 On Thu, 27 Oct 2005, Bill Woodcock wrote: > I say we go back to what owendelongtellmenetworks proposed, and see if there > was anything we actually didn't like about it. > > -Bill From andrew.dul at quark.net Thu Oct 27 20:46:43 2005 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Fri, 28 Oct 2005 00:46:43 +0000 Subject: [ppml] 2005-1 or its logical successor Message-ID: <20051028004643.4260.qmail@hoster908.com> I would expect all those who didn't support the policy on the grounds of routing/FIB table growth also to object to the original 2005-1 text. Andrew > -------Original Message------- > From: Bill Woodcock > Subject: [ppml] 2005-1 or its logical successor > Sent: 27 Oct '05 16:30 > > > I say we go back to what owendelongtellmenetworks proposed, and see if there > was anything we actually didn't like about it. > > > -Bill > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From tme at multicasttech.com Thu Oct 27 20:51:16 2005 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 27 Oct 2005 20:51:16 -0400 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: Message-ID: On Thu, 27 Oct 2005 17:30:37 -0700 (PDT) Bill Woodcock wrote: > > I say we go back to what owendelongtellmenetworks proposed, and see if there > was anything we actually didn't like about it. > For those who couldn't make it to L.A. (I am assuming you did), could you provide some context for this ? Of course, I supported the original 2005-1, which was similar to 2002-3. Regards Marshall Eubanks > > -Bill > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From william at elan.net Thu Oct 27 20:58:15 2005 From: william at elan.net (william(at)elan.net) Date: Thu, 27 Oct 2005 17:58:15 -0700 (PDT) Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <20051028004643.4260.qmail@hoster908.com> References: <20051028004643.4260.qmail@hoster908.com> Message-ID: On Fri, 28 Oct 2005, Andrew Dul wrote: > I would expect all those who didn't support the policy on the grounds > of routing/FIB table growth also to object to the original 2005-1 text. I think that its fairly clear that if all those who use ipv4 move to ipv6 the number of routes in ipv6 would be considerably smaller then with ipv4 simply because we'd have less organizations using and announcing different ip blocks and instead would have mostly one ipv6 block per organization. In that sense while too open a policy might pose a risk with future growth of ipv6, it is considerably more important in our immediate future to actually start using and help with migration to ipv6 in the next 10 years if possible. And unfortunately shim6 is not a solution and many realize it so I think open policy for multi-homing must be done for at least the period of migration. And yes, I realize that the trade-off of this is possible inequality similar to early ipv4 adaption since if we decide to change policy later to limit those who qualify, this would mean early adapters have certain advantage. -- William Leibzon Elan Networks william at elan.net From woody at pch.net Thu Oct 27 21:18:44 2005 From: woody at pch.net (Bill Woodcock) Date: Thu, 27 Oct 2005 18:18:44 -0700 (PDT) Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <20051028004643.4260.qmail@hoster908.com> References: <20051028004643.4260.qmail@hoster908.com> Message-ID: On Fri, 28 Oct 2005, [iso-8859-1] Andrew Dul wrote: > I would expect all those who didn't support the policy on the grounds of routing/FIB table growth also to object to the original 2005-1 text. And is that a non-zero set? -Bill From woody at pch.net Thu Oct 27 21:22:00 2005 From: woody at pch.net (Bill Woodcock) Date: Thu, 27 Oct 2005 18:22:00 -0700 (PDT) Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: Message-ID: On Thu, 27 Oct 2005, Marshall Eubanks wrote: > For those who couldn't make it to L.A. (I am assuming you did), could you provide some > context for this ? A revised-by-committee manglement of 2005-1 was presented, which had a ton of restrictions piled on top of it, which made it useless. That is, there was no remaining constituency for it. A huge queue of speakers denounced it, and only one person spoke in its favor, Dan Golding, and he said the only reason he supported it was because he thought fixing it later would be faster than revising it again. Fortunately, sanity prevailed, and the whole thing was sent back to the drawing board to have all the junk stripped back off. Which, I think, brings us back to the original 2005-1. So my question was whether there's anyone who, having seen the much nastier alternative, doesn't now support the original 2005-1? -Bill From lea.roberts at stanford.edu Fri Oct 28 02:04:44 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Thu, 27 Oct 2005 23:04:44 -0700 (PDT) Subject: [ppml] 2005-1 or its logical successor In-Reply-To: Message-ID: hi Bill (et al) - as you might have guessed from my comments in the hall, I don't quite agree with you on this... On Thu, 27 Oct 2005, Bill Woodcock wrote: > On Thu, 27 Oct 2005, Marshall Eubanks wrote: > > For those who couldn't make it to L.A. (I am assuming you did), could you provide some > > context for this ? > > A revised-by-committee manglement of 2005-1 was presented, which had a ton > of restrictions piled on top of it, which made it useless. That is, there > was no remaining constituency for it. A huge queue of speakers denounced > it, and only one person spoke in its favor, Dan Golding, and he said the > only reason he supported it was because he thought fixing it later would > be faster than revising it again. Fortunately, sanity prevailed, and the > whole thing was sent back to the drawing board to have all the junk > stripped back off. for the record, the straw poll was 24 vs 25. > > Which, I think, brings us back to the original 2005-1. > > So my question was whether there's anyone who, having seen the much > nastier alternative, doesn't now support the original 2005-1? > I understand that it would be really nice if we could really reach consensus to not care about the size of the IPv6 routing table, but that wasn't the reality I experienced in Orlando (where the split in the room was about even as well). Routing table size was a major concern sited by those whose indicated opposition to the original 2005-1. For the record, here are some excerpts from what I wrote to Kevin Loch inviting him to work on the combined 2005-1 that you are so unhappy about. I hope this will help others (and maybe even you) to understand how the extra stuff got piled on. I honestly believe that for 2005-1 to achieve consensus it has to focus on the large organizations for whom renumbering is a problem while having criteria which would limit the number of qualifying organizations to the range of 5K to 10K. When I wrote the text below, the feedback from other AC members is that it matched their recollection from ARIN XV. I gather you don't agree. Hopefully we'll hear more from others on PPML... :-) sincerely, /Lea Roberts, ARIN AC as written on 31-August-2005: Hi Kevin - Earlier today, the ARIN Advisory Council had a teleconference to act on the recently submitted policy proposals. By a close vote, a motion to move your proposal, "IPv6 Direct assignments to end sites", forward as submitted was defeated. The AC members present then unanimously voted for the option to work with you to see if it would be possible to combine your proposal with the existing 2005-1 policy proposal, which, although it failed to reach consensus in the previous ARIN meeting, the AC believed had enough support to work with the author to craft a proposal which might reach consensus. As the AC member who has been working with Owen DeLong on 2005-1, I volunteered to be the one to contact you regarding this choice. As you and Owen have already stated on PPML, both proposals aim in a very similar direction and so it should be easy to combine them. However, before you agree, I would like to inform you about the direction that the changes to 2005-1 are taking as they may not be to your liking. I have been working with Owen to modify policy proposal 2005-1 in response to the concerns of those who opposed it. I don't know if you were at the meeting, but there were a number of objections to the original 2005-1, the main ones being a concern over a run on AS numbers, which are currently the most constrained Internet Resource until 4-byte ASN's are a reality, and major concerns over the possibility of a large increase in the size of the IPv6 default-free routing table. There were assertions that it was too early for making multi-homing a rationale for a direct assignment of IPv6 address space, unless it was only for a limited time, until the viability of the shim6 effort in IETF could be determined. While the current number of sites who multi-home could easily be accomodated at this time, the effect of an IPv6 policy has to be looked at over the multiple 10s of years that IPv6 will need to be functional. Very few people believed that limited time assignments were viable (i.e. could actually be reclaimed) and asserted that it would create a similar situation to IPv4, where early adopters have an unfair advantage. In support of the proposal, a number of commercial companies, who were attending the co-located NAv6TF meeting, expressed their unwillingness to invest resources in deploying IPv6 with Provider Assigned address space, as they were unwilling to be "locked in" to a provider or else have to renumber their entire enterprise. When the sense of the room was taken, the attendees were about evenly split and so there was clearly not a consensus. I have been relying, as much if not more, on hallway conversations with those who opposed the advancement of 2005-1 to try to craft a new version of the proposal which could achieve consensus sooner rather than later. Most of those who opposed 2005-1 admitted that the design concept of only Provider Assigned space for IPv6 was clearly no longer tenable, but they were very concerned about almost unrestricted access to Provider Independent IPv6 address assignments. They indicated that it was too early in the protocol's lifetime to allow unrestricted routing table growth and expressed the hope that shim6 might still be successful. There is a real belief that IPv4-like multi-homing will doom the IPv6 routing table to grow beyond a workable size and some other solution has to be found! They expressed an understanding of the large enterprise renumbering problem and indicated that they would support a policy that provided for PI address assignments to a small number of large organizations for whom the cost of renumbering would be a significant expense. FYI, I think that once a PI assignment policy exists, the requirements can continue to change over time, much like the current IPv4 assignment size continues to become less restrictive. I think that getting over the "only Provider Assigned" hump would be a major policy achievement that's within sight. From steven.feldman at cnet.com Fri Oct 28 02:33:15 2005 From: steven.feldman at cnet.com (Steve Feldman) Date: Thu, 27 Oct 2005 23:33:15 -0700 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: Message-ID: <0A79726C-B546-4DEE-945F-92B9F4A148C7@cnet.com> On Oct 27, 2005, at 11:04 PM, Lea Roberts wrote: > > for the record, the straw poll was 24 vs 25. ... And for what it's worth, my vote for the policy was mostly because it was better than no policy at all, and hoping it could be cleaned up on the way to adoption. I was also in favor of the original 2005-1. > > For the record, here are some excerpts from what I wrote to Kevin Loch > inviting him to work on the combined 2005-1 that you are so unhappy > about. > I hope this will help others (and maybe even you) to understand how > the > extra stuff got piled on. I honestly believe that for 2005-1 to > achieve > consensus it has to focus on the large organizations for whom > renumbering > is a problem while having criteria which would limit the number of > qualifying organizations to the range of 5K to 10K. When I wrote > the text > below, the feedback from other AC members is that it matched their > recollection from ARIN XV. I think it's a mistake to focus on renumbering as the main issue; it really comes down to multihoming. Whether I multihome using PA or PI addresses, my prefix is necessarily going to take up a slot in the global routing table. So if multihoming is to be allowed at all, routing tables will have to grow. Given that, it doesn't make much sense to force the multihomers into PA space (unless the objective is to provide a disincentive to switch providers.) So the fundamental questions should be: 1) should IPv6 end sites be permitted to multhome? 2) if so, should there be more stringent restrictions than on IPv4 multihoming? 3) if so, what sorts of entities should qualify, and how can the restrictions be crafted to achieve that goal? Steve From paul at vix.com Fri Oct 28 02:48:04 2005 From: paul at vix.com (Paul Vixie) Date: Fri, 28 Oct 2005 06:48:04 +0000 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: Your message of "Thu, 27 Oct 2005 23:33:15 MST." <0A79726C-B546-4DEE-945F-92B9F4A148C7@cnet.com> References: <0A79726C-B546-4DEE-945F-92B9F4A148C7@cnet.com> Message-ID: <20051028064804.88AEA11457@sa.vix.com> # I think it's a mistake to focus on renumbering as the main issue; it really # comes down to multihoming. Whether I multihome using PA or PI addresses, my # prefix is necessarily going to take up a slot in the global routing table. # So if multihoming is to be allowed at all, routing tables will have to grow. there are three similar sounding reasons for preferring PI space: 1. multihoming 2. anycasting 3. independence of these, the first two are indistinguishable by external parties. i said as much to david williamson after his "allow a /24 for anycast" policy proposal got so few votes. my recommendation there is, craft a policy that treats anycast and multihoming the same, and it would probably get more traction. (by "indistinguishable" i mean that from the point of view of the rest of the internet, there is no difference from you announcing a prefix from many places because you have your own backbone, or because you're able to generate the same services from lots of pops using replicated server resources.) ((and note that multihoming can be one-site many-exits, or many-sites many-exits, the commonality is many-exits, which can be transits or peers or a mixture. there are more similarities than differences in this taxonomy.)) "independence" is the thing that specifically covers "fear of renumbering" and while it may not seem like a large problem to a business of ~100 employees mostly using DHCP, it's a VERY big deal to a business of ~10000 employees, or to a tier-2 ISP wishing to sell services to such businesses. we've heard from members and others who have said "we don't want our address space to lock us into an ISP" and i think we have to take that seriously even if some of us might not share that concern in our own networks. From paul at vix.com Fri Oct 28 02:54:55 2005 From: paul at vix.com (Paul Vixie) Date: Fri, 28 Oct 2005 06:54:55 +0000 Subject: [ppml] early adopter advantage Message-ID: <20051028065455.0E18511457@sa.vix.com> it's been spake several times today that one big problem with the IPv6 PI proposal was that it would not scale to the full IPv6 population, and therefore we ought to craft a policy that gave no special advantages to the early adopters. MIT and Stanford and DEC and HP all having "class A" IPv6 networks whereas China can't get one, was cited as an example of this. another more specific concern i heard today was "if we allow PI IPv6 space then there will be no incentive to develop non-PI multihoming technology". i think both of these concerns are misplaced. if we want there to be an IPv6 network economy we're going to have to give folks what they need to become early adopters, and if they're asking for PI IPv6, then we have to at least listen. furthermore, the incentive to more quickly develop non-PI alternatives for IPv6 multihoming might actually be higher if there's PI space being granted, since it's *such* a bad idea in the long run. (this assumes that the primary developers of non-PI IPv6 multihoming technology will be vendors and registries rather than end-users; this seems ~likely.) From paul at vix.com Fri Oct 28 03:01:07 2005 From: paul at vix.com (Paul Vixie) Date: Fri, 28 Oct 2005 07:01:07 +0000 Subject: [ppml] trade in your IPv4 block for an IPv6? Message-ID: <20051028070107.4473D11457@sa.vix.com> what if someone could get PI IPv6 space by agreeing to return PI IPv4 space? not the same day, mind you. within two years, perhaps. or five years. an exchange rate would have to be established, like "if you return a V4 /16, we will give you a V6 /48" or even "we'll give you a V6 /(49-N) for the N V4 /16's you return". the goal would be to shrink or keep stable the size of the routing table in dual stacked routers, while getting V4 space back that we can use for address lifetime extension later when V4 space gets short. (i'm trying to think of some early adopter advantages that would have beneficial side effects.) From woody at pch.net Fri Oct 28 03:59:15 2005 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Oct 2005 00:59:15 -0700 (PDT) Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: Message-ID: On Thu, 27 Oct 2005, Lea Roberts wrote: > > So my question was whether there's anyone who, having seen the much > > nastier alternative, doesn't now support the original 2005-1? > I understand that it would be really nice if we could really reach > consensus to not care about the size of the IPv6 routing table, but that > wasn't the reality I experienced in Orlando. Routing table size was > a major concern sited by those whose indicated opposition to the > original 2005-1. Right, but that wasn't my question. I know there were people who were worried about that in Orlando. My question is whether they're still concerned about it, _now_ that they've seen the alternative. Which you haven't answered... You've said what you thought then. What do you think _now_, and why? > I hope this will help others (and maybe even you) to understand how the > extra stuff got piled on. Really no concern. Spilt milk. Water under the bridge. No sweat. I'm not worried about history, I'm interested in the future. -Bill From woody at pch.net Fri Oct 28 04:03:52 2005 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Oct 2005 01:03:52 -0700 (PDT) Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <0A79726C-B546-4DEE-945F-92B9F4A148C7@cnet.com> References: <0A79726C-B546-4DEE-945F-92B9F4A148C7@cnet.com> Message-ID: On Thu, 27 Oct 2005, Steve Feldman wrote: > > for the record, the straw poll was 24 vs 25. > ... And for what it's worth, my vote for the policy was mostly because > it was better than no policy at all, and hoping it could be cleaned > up on the way to adoption. I was also in favor of the original 2005-1. Right, I assume that was true of the other 22 people besides you and Dan Golding, as well. I didn't hear anyone say that the revisions to 2005-1 were acceptable, or were even _not worse_. I did hear many, many people queue up at the mics and all agree that they _were much much worse_, and unacceptable. So the two people who've explained their "yes" votes have both said that they voted for something unacceptable, hoping it could be salvaged afterwards. Hardly a ringing endorsement. Whereas the second vote, to fix this, was unanimous except for Randy and Lee, both of whom were joking because Stacy had offered to spank them. -Bill From woody at pch.net Fri Oct 28 04:23:27 2005 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Oct 2005 01:23:27 -0700 (PDT) Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: <0A79726C-B546-4DEE-945F-92B9F4A148C7@cnet.com> Message-ID: So Chris Morrow and Mike Hughes and Thomas Narten and I were talking more about this over dinner, and I think the consensus out of that conversation was this: - an IPv6 direct-assignment policy should be based directly on the ipv4 direct-assignment policy, as closely as possible. - one-size-fits-all probably isn't useful in the long run. - host-counts are stupid. - a strict multi-homing requirement is perfectly reasonable. - preexisting IPv4 deployment should qualify you for IPv6 assignment. - the size of the assignment should probably be /48 times the number of sites you have already deployed. - in order to avoid creative interpretation of "sites," no more than one site per metro area should be counted. That's arbitrary, but it's an objectively-verifiable quantity, which is what's needed for the ARIN analyst staff. Thoughts? -Bill From owen at delong.com Fri Oct 28 06:49:54 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Oct 2005 03:49:54 -0700 Subject: [ppml] trade in your IPv4 block for an IPv6? In-Reply-To: <20051028070107.4473D11457@sa.vix.com> References: <20051028070107.4473D11457@sa.vix.com> Message-ID: I like the idea, but, for it to be practical today, I think we'd need to specify the return date in terms of events rather than time. I don't think anyone will be willing to migrate off of their V4 space until such time as adequate 6to4 connectivity exists to guarantee that they do not lose connectivity to some significant portion of the internet by removing the V4 addresses from their machines. Owen --On October 28, 2005 7:01:07 AM +0000 Paul Vixie wrote: > what if someone could get PI IPv6 space by agreeing to return PI IPv4 > space? > > not the same day, mind you. within two years, perhaps. or five years. > an exchange rate would have to be established, like "if you return a V4 > /16, we will give you a V6 /48" or even "we'll give you a V6 /(49-N) for > the N V4 /16's you return". the goal would be to shrink or keep stable > the size of the routing table in dual stacked routers, while getting V4 > space back that we can use for address lifetime extension later when V4 > space gets short. > > (i'm trying to think of some early adopter advantages that would have > beneficial side effects.) > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at btradianz.com Fri Oct 28 07:21:33 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 28 Oct 2005 12:21:33 +0100 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: Message-ID: > - one-size-fits-all probably isn't useful in the long run. Yes. > - host-counts are stupid. Agreed. The size of v6 allocations is not related to the number of hosts. Hostcounts are v4 thinking. > - a strict multi-homing requirement is perfectly reasonable. Yes. And since this requires an ASN and since there are some 12,000 ASNs in the ARIN region this would tend to limit the number of end-user PI blocks to the 5,000-10,000 range which some people desire. > - preexisting IPv4 deployment should qualify you for IPv6 assignment. Yes. Why do people need IPv6 addresses? To deploy a network. How do they prove that they will deploy a network? Show that they have already done so using v4 addresses. > - the size of the assignment should probably be /48 times the number of > sites you have already deployed. More or less. Round this number up to some rational bit boundary. And I assume that the "already deployed" refers to preexisting v4 deployment. > - in order to avoid creative interpretation of "sites," no more than one > site per metro area should be counted. That's arbitrary, but it's an > objectively-verifiable quantity, which is what's needed for the ARIN > analyst staff. No, too restrictive. I agree that we need a verifiable definition of "site" but I think this can be done in a way that allows multiple sites per city. Two possible ways to prove it to ARIN analysts are to provide an IP address per site that can be tracerouted to show a unique path or ISP bills/contracts that demonstrate one circuit per site. I'm sure that there are other ways of proving site count such as municipal tax bills, water bills, etc. Rather than define "site" we should refer to IPv6 RFCs which talk about how to assign /48s. As long as the count is consistent with IPv6 network design practices, it should be allowable. If a company has one router per floor of their building, then it is one site per floor. If they have one router per building on their campus then it is one site per building. --Michael Dillon From tme at multicasttech.com Fri Oct 28 08:07:58 2005 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 28 Oct 2005 08:07:58 -0400 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: Message-ID: Good morning all; On Fri, 28 Oct 2005 12:21:33 +0100 Michael.Dillon at btradianz.com wrote: > > - one-size-fits-all probably isn't useful in the long run. > > Yes. > > > - host-counts are stupid. > > Agreed. The size of v6 allocations is not related > to the number of hosts. Hostcounts are v4 thinking. > > > - a strict multi-homing requirement is perfectly reasonable. > > Yes. And since this requires an ASN and since there are > some 12,000 ASNs in the ARIN region this would tend to > limit the number of end-user PI blocks to the 5,000-10,000 > range which some people desire. > > > - preexisting IPv4 deployment should qualify you for IPv6 assignment. > > Yes. Why do people need IPv6 addresses? To deploy a network. > How do they prove that they will deploy a network? Show > that they have already done so using v4 addresses. > I agree. I do not think it should be the only requirement (v6 only deployments should count too !). > > - the size of the assignment should probably be /48 times the number of > > sites you have already deployed. > > More or less. Round this number up to some rational Agree > bit boundary. And I assume that the "already deployed" > refers to preexisting v4 deployment. > It could be IPv6 deployment too. (I keep thinking of the IPv6 only cell phone providers we keep hearing rumors about.) > > - in order to avoid creative interpretation of "sites," no more than one > > site per metro area should be counted. That's arbitrary, but it's an > > objectively-verifiable quantity, which is what's needed for the ARIN > > analyst staff. > > No, too restrictive. I agree that we need a verifiable > definition of "site" but I think this can be done in a > way that allows multiple sites per city. Two possible ways > to prove it to ARIN analysts are to provide an IP address > per site that can be tracerouted to show a unique path > or ISP bills/contracts that demonstrate one circuit per > site. I'm sure that there are other ways of proving site > count such as municipal tax bills, water bills, etc. > I agree with Michael here. I also don't think that any restriction to "city" or "metro area" is well posed, at least from a network standpoint. In the US, the census defines metro areas, and these change every ten years. Moreover, this says nothing about network topology. As as example, I have a router in Tysons Corner, Virginia (unincorporated Fairfax county, Washington DC metro area). If I decide to multihome with Sprint, and put a router in their facility just down the road, a completely different location from the standpoint of network topology, but also unincorporated Fairfax county, Washington DC metro area, why should that not count as a different location ? Or, conversely, I might put a router in Equinix Ashburn (10 miles away, but in a different county). Is that in a different "city" ? (At least in the 1990 census, it was not in the Washington DC metro area.) Or maybe I put a site in Columbia, Maryland - same metro area (I think), but in a different state, and a good 50+ miles away. Is ARIN going to set up some tool to or hire people to figure out if all these sites are actually in the same area ? Is Newark, N.J., going to count as the same or a different city from New York city ? I don't think that ARIN should be involved in this, it seems like a good way to waste time and resources. > Rather than define "site" we should refer to IPv6 RFCs > which talk about how to assign /48s. As long as the count > is consistent with IPv6 network design practices, it should > be allowable. If a company has one router per floor of > their building, then it is one site per floor. If they > have one router per building on their campus then it is > one site per building. > I think that this is at lot more reasonable. > --Michael Dillon > Regards Marshall Eubanks > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From craig at more.net Fri Oct 28 08:36:32 2005 From: craig at more.net (Pepmiller, Craig E.) Date: Fri, 28 Oct 2005 07:36:32 -0500 Subject: [ppml] early adopter advantage Message-ID: <52274948E96C7147A43711DD5FF61DE201747835@UM-EMAIL07.um.umsystem.edu> We need to avoid past mistakes in excessive allocation but keep in mind that early adopters are also innovators and can drive the overall adoption and progress. What have we done so far? Granted temporary allocations (3F) and then withdrew them. I would suggest that early adopters get a reasonable allocation with a 'reserved' block next to it that could be used to expand their block (2X, 4X, 8X, 16X?) if it works out that general allocations turned out to be larger. -Craig -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Paul Vixie Sent: Friday, October 28, 2005 1:55 AM To: ppml at arin.net Subject: [ppml] early adopter advantage it's been spake several times today that one big problem with the IPv6 PI proposal was that it would not scale to the full IPv6 population, and therefore we ought to craft a policy that gave no special advantages to the early adopters. MIT and Stanford and DEC and HP all having "class A" IPv6 networks whereas China can't get one, was cited as an example of this. another more specific concern i heard today was "if we allow PI IPv6 space then there will be no incentive to develop non-PI multihoming technology". i think both of these concerns are misplaced. if we want there to be an IPv6 network economy we're going to have to give folks what they need to become early adopters, and if they're asking for PI IPv6, then we have to at least listen. furthermore, the incentive to more quickly develop non-PI alternatives for IPv6 multihoming might actually be higher if there's PI space being granted, since it's *such* a bad idea in the long run. (this assumes that the primary developers of non-PI IPv6 multihoming technology will be vendors and registries rather than end-users; this seems ~likely.) _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From craig at more.net Fri Oct 28 08:43:44 2005 From: craig at more.net (Pepmiller, Craig E.) Date: Fri, 28 Oct 2005 07:43:44 -0500 Subject: [ppml] trade in your IPv4 block for an IPv6? Message-ID: <52274948E96C7147A43711DD5FF61DE201747836@UM-EMAIL07.um.umsystem.edu> Nice if it works out but it could also give an advantage to address homesteaders- Those who grabbed up IPv4 space that they did not need. The emphasis in IPv4 allocations has been to give blocks to those that can prove a current need as well as prove a good track record in usage. I don't know anyone who has open blocks to give back in this period of dual stack transitioning. -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Paul Vixie Sent: Friday, October 28, 2005 2:01 AM To: ppml at arin.net Subject: [ppml] trade in your IPv4 block for an IPv6? what if someone could get PI IPv6 space by agreeing to return PI IPv4 space? not the same day, mind you. within two years, perhaps. or five years. an exchange rate would have to be established, like "if you return a V4 /16, we will give you a V6 /48" or even "we'll give you a V6 /(49-N) for the N V4 /16's you return". the goal would be to shrink or keep stable the size of the routing table in dual stacked routers, while getting V4 space back that we can use for address lifetime extension later when V4 space gets short. (i'm trying to think of some early adopter advantages that would have beneficial side effects.) _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From bmanning at vacation.karoshi.com Fri Oct 28 09:23:35 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 28 Oct 2005 13:23:35 +0000 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: Message-ID: <20051028132335.GA12469@vacation.karoshi.com.> > Really no concern. Spilt milk. Water under the bridge. No sweat. I'm > not worried about history, I'm interested in the future. those who can not remember the past are condemed to repeat it - Santayana --bill > > -Bill > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From bmanning at vacation.karoshi.com Fri Oct 28 09:26:42 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 28 Oct 2005 13:26:42 +0000 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: Message-ID: <20051028132642.GB12469@vacation.karoshi.com.> > > - preexisting IPv4 deployment should qualify you for IPv6 assignment. > > Yes. Why do people need IPv6 addresses? To deploy a network. > How do they prove that they will deploy a network? Show > that they have already done so using v4 addresses. i would not want to see a restriction on v6 delegations only to those w/ preexisting v4 delegations. --bill From tme at multicasttech.com Fri Oct 28 09:41:03 2005 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 28 Oct 2005 09:41:03 -0400 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <20051028132335.GA12469@vacation.karoshi.com.> Message-ID: On Fri, 28 Oct 2005 13:23:35 +0000 bmanning at vacation.karoshi.com wrote: > > Really no concern. Spilt milk. Water under the bridge. No sweat. I'm > > not worried about history, I'm interested in the future. > > those who can not remember the past are condemed to repeat it > - Santayana ... first time as tragedy, second time as farce (with apologies to Karl; I could resist as it sometimes seems appropriate in these discussions.) > --bill Marshall > > > > -Bill > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From plzak at arin.net Fri Oct 28 09:52:27 2005 From: plzak at arin.net (Ray Plzak) Date: Fri, 28 Oct 2005 09:52:27 -0400 Subject: [ppml] Matching NRPM sections to policies In-Reply-To: Message-ID: <20051028135230.49BF21FF38@mercury.arin.net> Sam, We will look at doing this. I don't know what the level of effort is to do this. That and of course other tasks will dictate if and when we can get this done. Ray > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Samuel Weiler > Sent: Thursday, October 27, 2005 6:18 PM > To: ppml at arin.net > Subject: [ppml] Matching NRPM sections to policies > > I'd like to see ARIN go through the (wonderful) NRPM and 1) add more > cross-references to the policies as adopted, much as a code of > regulations may refer back to the enacting legislation and 2) add > complete forward citations from the policy archive into the NRPM. > Will the staff do that? > > For example: > > Section 6.5.5.1 cites the Residential Customer Privacy by number > (2003-3), but the corresponding section about v4, 4.2.3.7.6, doesn't > mention the policy number. Similarly, section 3.2 makes reference to > this policy without citing it by number and perhaps making some errors > in transcription (per the other thread). > > In the policy archive, 2003-3 mentions 4.2.3.7.6 as the section where > the adopted policy was recorded, but does not mention the other two > sections. > > -- Sam > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From randy at psg.com Fri Oct 28 10:26:12 2005 From: randy at psg.com (Randy Bush) Date: Fri, 28 Oct 2005 07:26:12 -0700 Subject: [ppml] 2005-1 or its logical successor References: <20051028004643.4260.qmail@hoster908.com> Message-ID: <17250.13572.566490.203238@roam.psg.com> >> I would expect all those who didn't support the policy on the grounds of >> routing/FIB table growth also to object to the original 2005-1 text. > And is that a non-zero set? it is a non-null set From woody at pch.net Fri Oct 28 11:44:09 2005 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Oct 2005 08:44:09 -0700 (PDT) Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: Message-ID: > > > - preexisting IPv4 deployment should qualify you for IPv6 assignment. > > > > Yes. Why do people need IPv6 addresses? To deploy a network. > > How do they prove that they will deploy a network? Show > > that they have already done so using v4 addresses. > > I agree. I do not think it should be the only requirement (v6 only deployments > should count too !). Yes, of course... I didn't mean that to sound exclusive. The idea was that you could do your justification entirely based upon IPv6 use/need, or you could bootstrap into it by demonstrating prior use of IPv4. One suggestion was that case, IPv6 assignments could be scaled to how much IPv4 space was being advertized, since that's much easier to verify than use-claims, but I think the consensus was that that was too much of an unfair compounding of previous-generation early-adopter advantage, so number of sites was a better metric. -Bill From woody at pch.net Fri Oct 28 11:46:33 2005 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Oct 2005 08:46:33 -0700 (PDT) Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <20051028132335.GA12469@vacation.karoshi.com.> References: <20051028132335.GA12469@vacation.karoshi.com.> Message-ID: > those who can not remember the past are condemed to repeat it Gosh, I hope not, Bill... You really want to repeat the loading-on-of-unpopular-and-draconian-requirements again? Sorry, I'd rather not. -Bill From woody at pch.net Fri Oct 28 11:46:58 2005 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Oct 2005 08:46:58 -0700 (PDT) Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <20051028132642.GB12469@vacation.karoshi.com.> References: <20051028132642.GB12469@vacation.karoshi.com.> Message-ID: > i would not want to see a restriction on v6 delegations > only to those w/ preexisting v4 delegations. Straw-man. Nobody has suggested that. -Bill From woody at pch.net Fri Oct 28 11:48:15 2005 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Oct 2005 08:48:15 -0700 (PDT) Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <17250.13572.566490.203238@roam.psg.com> References: <20051028004643.4260.qmail@hoster908.com> <17250.13572.566490.203238@roam.psg.com> Message-ID: > >> I would expect all those who didn't support the policy on the grounds of > >> routing/FIB table growth also to object to the original 2005-1 text. > > And is that a non-zero set? > it is a non-null set Uh, right, I've heard that asserted twice, now, but no such people have yet manifested from the woodwork. Care to find one for us? -Bill From bmanning at vacation.karoshi.com Fri Oct 28 12:11:53 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 28 Oct 2005 16:11:53 +0000 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: <20051028132335.GA12469@vacation.karoshi.com.> Message-ID: <20051028161153.GB13157@vacation.karoshi.com.> On Fri, Oct 28, 2005 at 08:46:33AM -0700, Bill Woodcock wrote: > > those who can not remember the past are condemed to repeat it > > Gosh, I hope not, Bill... You really want to repeat the > loading-on-of-unpopular-and-draconian-requirements again? Sorry, I'd > rather not. > > -Bill i am not sure tht i want to repeat that, but it would be interesting as to WHY folks thought it was important to try that tactic - before - stripping down. --bill From bmanning at vacation.karoshi.com Fri Oct 28 13:54:12 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 28 Oct 2005 17:54:12 +0000 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: <20051028132642.GB12469@vacation.karoshi.com.> Message-ID: <20051028175412.GC13157@vacation.karoshi.com.> On Fri, Oct 28, 2005 at 08:46:58AM -0700, Bill Woodcock wrote: > > i would not want to see a restriction on v6 delegations > > only to those w/ preexisting v4 delegations. > > Straw-man. Nobody has suggested that. > > -Bill true, but the thread was tending in that direction... black-dimond slope there... FYI warning. --bill From woody at pch.net Fri Oct 28 13:55:01 2005 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Oct 2005 10:55:01 -0700 (PDT) Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: Message-ID: On Fri, 28 Oct 2005 Michael.Dillon at btradianz.com wrote: > > - in order to avoid creative interpretation of "sites," no more than one > > site per metro area should be counted. That's arbitrary, but it's an > > objectively-verifiable quantity, which is what's needed for the ARIN > > analyst staff. > > No, too restrictive. I agree that we need a verifiable > definition of "site" but I think this can be done in a > way that allows multiple sites per city. Two possible ways > to prove it to ARIN analysts are to provide an IP address > per site that can be tracerouted to show a unique path > or ISP bills/contracts that demonstrate one circuit per > site. I'm sure that there are other ways of proving site > count such as municipal tax bills, water bills, etc. Okay, that seems reasonable. -Bill From dlw+arin at tellme.com Fri Oct 28 14:25:33 2005 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 28 Oct 2005 11:25:33 -0700 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: <0A79726C-B546-4DEE-945F-92B9F4A148C7@cnet.com> Message-ID: <20051028182533.GX25562@shell01.corp.tellme.com> On Fri, Oct 28, 2005 at 01:23:27AM -0700, Bill Woodcock wrote: > [strawman proposal deleted] > Thoughts? As an end-site(s) that would very much like to get hold of v6 space, this proposal is completely reasonable to me. I agree with the previous posters that some greater leniancy in the definition of "site" might be required. As long as that definition is sufficient to make abuse very hard, I would completely support this. For the record, I like the original version of 2005-1, and I support the new one (even though it is entierly flawed and useless to me) simply because I think it is vital to get some PI space out there. Time keeps ticking along...until PI space is reasonably available to end-sites that have real need for it, v6 adoption will be very very slow. -David From stephen at sprunk.org Fri Oct 28 17:48:12 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 28 Oct 2005 16:48:12 -0500 Subject: [ppml] 2005-1 or its logical successor References: <0A79726C-B546-4DEE-945F-92B9F4A148C7@cnet.com> Message-ID: <00d301c5dc09$4bb64520$6a0016ac@ssprunk> Thus spake "Bill Woodcock" > So Chris Morrow and Mike Hughes and Thomas Narten and I were > talking more about this over dinner, and I think the consensus out of > that conversation was this: > > - an IPv6 direct-assignment policy should be based directly on the ipv4 > direct-assignment policy, as closely as possible. As far as initial qualification goes, but not in terms of size of allocation. > - one-size-fits-all probably isn't useful in the long run. Well, I think a minimum allocation of /48 is reasonable, with specific requirements on hosts/sites/segments/etc. only applicable if the requestor wants something larger. > - host-counts are stupid. Ditto. But counting subnets might not be. > - a strict multi-homing requirement is perfectly reasonable. > > - preexisting IPv4 deployment should qualify you for IPv6 assignment. I hope you meant preexisting IPv4 _multihomed_ deployment. Do we need to consider folks who intend to only deploy v6, or is that still fantasy for the next few years? > - the size of the assignment should probably be /48 times the number of > sites you have already deployed. > > - in order to avoid creative interpretation of "sites," no more than one > site per metro area should be counted. That's arbitrary, but it's an > objectively-verifiable quantity, which is what's needed for the ARIN > analyst staff. We really need to get consensus on the definition of "site". For instance, should McDonalds get a block for each city they have a restaurant in, even if they're all connected back to a handful of "hub" sites for {inter|intra}net access? In contrast, should a Fortune 1000 company with large offices in NY, LA, Chicago, and Houston be considered a single "site" because they only have four locations of importance? To me, a "site" is a network, however large, that has complete internal reachability and is effectively under a single administrative umbrella. In fact, it's pretty close to the definition of an Autonomous System, but that may be an effect of current/past allocation policies clouding my thinking. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From owen at delong.com Fri Oct 28 18:13:13 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Oct 2005 15:13:13 -0700 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <20051028132642.GB12469@vacation.karoshi.com.> References: <20051028132642.GB12469@vacation.karoshi.com.> Message-ID: --On October 28, 2005 1:26:42 PM +0000 bmanning at vacation.karoshi.com wrote: >> > - preexisting IPv4 deployment should qualify you for IPv6 assignment. >> >> Yes. Why do people need IPv6 addresses? To deploy a network. >> How do they prove that they will deploy a network? Show >> that they have already done so using v4 addresses. > > i would not want to see a restriction on v6 delegations > only to those w/ preexisting v4 delegations. I don't think the intent was to restrict it, but, to allow people who had already qualified for V4 delegations to use it as one method of v6 justification. If the policies are made consistent, then, the fact that you already made it through the process for a V4 allocation does provide substantial evidence that you should be entitled to a V6 allocation. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From billd at cait.wustl.edu Sat Oct 29 08:04:44 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Sat, 29 Oct 2005 07:04:44 -0500 Subject: [ppml] 2005-1 or its logical successor Message-ID: Stephen Sprunk said..... We really need to get consensus on the definition of "site". For instance, should McDonalds get a block for each city they have a restaurant in, even if they're all connected back to a handful of "hub" sites for {inter|intra}net access? In contrast, should a Fortune 1000 company with large offices in NY, LA, Chicago, and Houston be considered a single "site" because they only have four locations of importance? To me, a "site" is a network, however large, that has complete internal reachability and is effectively under a single administrative umbrella. In fact, it's pretty close to the definition of an Autonomous System, but that may be an effect of current/past allocation policies clouding my thinking. S *************** I believe that the purpose is to provide a PI block to an 'enterprise' that has a large distributed network and thus needs lots of addresses and subnetting capability. So site=enterprise with me. Bill Darte ARIN AC From bicrawf at yahoo.com Sat Oct 29 11:56:29 2005 From: bicrawf at yahoo.com (Benjamin Crawford) Date: Sat, 29 Oct 2005 08:56:29 -0700 (PDT) Subject: [ppml] early adopter advantage In-Reply-To: <20051028065455.0E18511457@sa.vix.com> Message-ID: <20051029155629.79571.qmail@web52011.mail.yahoo.com> I agree with Paul. I think putting off a policy for PI space due to concerns on giving certain special advantages might be a little off based. If allowing PI space will help start the drive towards adoption of IPv6, it make sense to try to make that available. If a PI policy is put on the shelf while non-PI alternatives are developed, I think a lot of people continue propagating IPv4 and continue to push out the adoption of v6. -Ben Crawford --- Paul Vixie wrote: > it's been spake several times today that one big > problem with the IPv6 PI > proposal was that it would not scale to the full > IPv6 population, and > therefore we ought to craft a policy that gave no > special advantages to > the early adopters. MIT and Stanford and DEC and HP > all having "class A" > IPv6 networks whereas China can't get one, was cited > as an example of this. > > another more specific concern i heard today was "if > we allow PI IPv6 space > then there will be no incentive to develop non-PI > multihoming technology". > > i think both of these concerns are misplaced. if we > want there to be an > IPv6 network economy we're going to have to give > folks what they need to > become early adopters, and if they're asking for PI > IPv6, then we have to > at least listen. furthermore, the incentive to more > quickly develop non-PI > alternatives for IPv6 multihoming might actually be > higher if there's PI > space being granted, since it's *such* a bad idea in > the long run. (this > assumes that the primary developers of non-PI IPv6 > multihoming technology > will be vendors and registries rather than > end-users; this seems ~likely.) > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs From kloch at hotnic.net Sat Oct 29 12:07:18 2005 From: kloch at hotnic.net (Kevin Loch) Date: Sat, 29 Oct 2005 12:07:18 -0400 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: Message-ID: <43639E36.5040808@hotnic.net> Bill Woodcock wrote: > Yes, of course... I didn't mean that to sound exclusive. The idea was > that you could do your justification entirely based upon IPv6 use/need, or > you could bootstrap into it by demonstrating prior use of IPv4. While I would generally prefer to keep references to v4 out of v6 policy, I think this would be useful. It would simplify the majority of applications, reducing ARIN staff work. It would also lessen the controversey over whatever requirements we set for non v4 networks. > One > suggestion was that case, IPv6 assignments could be scaled to how much > IPv4 space was being advertized, since that's much easier to verify > than use-claims, Do they need to be scaled? Does anyone have more than 1m subnets now? > but I think the consensus was that that was too much > of an unfair compounding of previous-generation early-adopter > advantage, so number of sites was a better metric. One way to avoid the taint of early v4 delegations is to make the v4 exception only apply to assignments/allocations made by ARIN. - Kevin From owen at delong.com Sat Oct 29 13:50:07 2005 From: owen at delong.com (Owen DeLong) Date: Sat, 29 Oct 2005 10:50:07 -0700 Subject: [ppml] early adopter advantage In-Reply-To: <20051029155629.79571.qmail@web52011.mail.yahoo.com> References: <20051029155629.79571.qmail@web52011.mail.yahoo.com> Message-ID: I don't think that PI space will help start the drive. However, I do believe that the lack of PI space is definitely preventing the adoption. Owen --On October 29, 2005 8:56:29 AM -0700 Benjamin Crawford wrote: > I agree with Paul. I think putting off a policy for > PI space due to concerns on giving certain special > advantages might be a little off based. If allowing > PI space will help start the drive towards adoption of > IPv6, it make sense to try to make that available. If > a PI policy is put on the shelf while non-PI > alternatives are developed, I think a lot of people > continue propagating IPv4 and continue to push out the > adoption of v6. > > -Ben Crawford > > --- Paul Vixie wrote: > >> it's been spake several times today that one big >> problem with the IPv6 PI >> proposal was that it would not scale to the full >> IPv6 population, and >> therefore we ought to craft a policy that gave no >> special advantages to >> the early adopters. MIT and Stanford and DEC and HP >> all having "class A" >> IPv6 networks whereas China can't get one, was cited >> as an example of this. >> >> another more specific concern i heard today was "if >> we allow PI IPv6 space >> then there will be no incentive to develop non-PI >> multihoming technology". >> >> i think both of these concerns are misplaced. if we >> want there to be an >> IPv6 network economy we're going to have to give >> folks what they need to >> become early adopters, and if they're asking for PI >> IPv6, then we have to >> at least listen. furthermore, the incentive to more >> quickly develop non-PI >> alternatives for IPv6 multihoming might actually be >> higher if there's PI >> space being granted, since it's *such* a bad idea in >> the long run. (this >> assumes that the primary developers of non-PI IPv6 >> multihoming technology >> will be vendors and registries rather than >> end-users; this seems ~likely.) >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> > > > > > __________________________________ > Start your day with Yahoo! - Make it your home page! > http://www.yahoo.com/r/hs > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From aaronh at bind.com Sat Oct 29 13:55:43 2005 From: aaronh at bind.com (Aaron Hughes) Date: Sat, 29 Oct 2005 13:55:43 -0400 Subject: [ppml] early adopter advantage In-Reply-To: References: <20051029155629.79571.qmail@web52011.mail.yahoo.com> Message-ID: <20051029175543.GC14815@user1.bind.com> It would however make it easier for providers to start working with their smaller multi-homed customers on adoption. I do not believe the non-service provider, non-government networks will start dual-stack or migration without push from the community, the providers or some compelling v6 only application. I do however, believe this is a step in the right direction. Cheers. Aaron On Sat, Oct 29, 2005 at 10:50:07AM -0700, Owen DeLong wrote: > I don't think that PI space will help start the drive. However, I do > believe > that the lack of PI space is definitely preventing the adoption. > > Owen > > > --On October 29, 2005 8:56:29 AM -0700 Benjamin Crawford > wrote: > > >I agree with Paul. I think putting off a policy for > >PI space due to concerns on giving certain special > >advantages might be a little off based. If allowing > >PI space will help start the drive towards adoption of > >IPv6, it make sense to try to make that available. If > >a PI policy is put on the shelf while non-PI > >alternatives are developed, I think a lot of people > >continue propagating IPv4 and continue to push out the > >adoption of v6. > > > >-Ben Crawford > > > >--- Paul Vixie wrote: > > > >>it's been spake several times today that one big > >>problem with the IPv6 PI > >>proposal was that it would not scale to the full > >>IPv6 population, and > >>therefore we ought to craft a policy that gave no > >>special advantages to > >>the early adopters. MIT and Stanford and DEC and HP > >>all having "class A" > >>IPv6 networks whereas China can't get one, was cited > >>as an example of this. > >> > >>another more specific concern i heard today was "if > >>we allow PI IPv6 space > >>then there will be no incentive to develop non-PI > >>multihoming technology". > >> > >>i think both of these concerns are misplaced. if we > >>want there to be an > >>IPv6 network economy we're going to have to give > >>folks what they need to > >>become early adopters, and if they're asking for PI > >>IPv6, then we have to > >>at least listen. furthermore, the incentive to more > >>quickly develop non-PI > >>alternatives for IPv6 multihoming might actually be > >>higher if there's PI > >>space being granted, since it's *such* a bad idea in > >>the long run. (this > >>assumes that the primary developers of non-PI IPv6 > >>multihoming technology > >>will be vendors and registries rather than > >>end-users; this seems ~likely.) > >>_______________________________________________ > >>PPML mailing list > >>PPML at arin.net > >>http://lists.arin.net/mailman/listinfo/ppml > >> > > > > > > > > > >__________________________________ > >Start your day with Yahoo! - Make it your home page! > >http://www.yahoo.com/r/hs > >_______________________________________________ > >PPML mailing list > >PPML at arin.net > >http://lists.arin.net/mailman/listinfo/ppml > > > > -- > If this message was not signed with gpg key 0FE2AA3D, it's probably > a forgery. > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- Aaron Hughes aaronh at bind.com (703) 244-0427 For public PGP key: finger aaronh at bind.com Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From paul at vix.com Sat Oct 29 14:34:12 2005 From: paul at vix.com (Paul Vixie) Date: Sat, 29 Oct 2005 18:34:12 +0000 Subject: [ppml] early adopter advantage In-Reply-To: Your message of "Sat, 29 Oct 2005 13:55:43 -0400." <20051029175543.GC14815@user1.bind.com> References: <20051029155629.79571.qmail@web52011.mail.yahoo.com> <20051029175543.GC14815@user1.bind.com> Message-ID: <20051029183412.52D3D11426@sa.vix.com> # It would however make it easier for providers to start working with their # smaller multi-homed customers on adoption. in terms of marketing, the obvious first customers for IPv6 are those who are already multihoming with IPv4. this preselection is due to the need for an ASN, routers, BGP, and higher basic understanding. if we want to know why V6 growth is even flatter than the most pessimistic projections of five years ago we need look no further than "let's disenfranchise the users most capable of being our early adopters" as the somewhat odd reason for it. From randy at psg.com Sat Oct 29 14:53:54 2005 From: randy at psg.com (Randy Bush) Date: Sat, 29 Oct 2005 11:53:54 -0700 Subject: [ppml] early adopter advantage References: <20051029155629.79571.qmail@web52011.mail.yahoo.com> <20051029175543.GC14815@user1.bind.com> <20051029183412.52D3D11426@sa.vix.com> Message-ID: <17251.50498.107148.783703@roam.psg.com> if we look at the history of v4, email, http, ... it seems clear that, if v6 actually did anything for users/sites/... nothing we could do would stop its explosive growth. what we seem to be demonstrating is that, since v6 brings no perceptible benefit to the users/sites/..., that giving it away for free can not get folk to adopt it at any perceptable rate. discussions of *how* to give it away for free may keep folk with too much free time on their hands amused. but discussion of making v6 sufficiently useful to give the user a perceptible advantage would seem to be more germane. technically and socially better multi-homing than v4 seems one real thing we could do, at least for sites. and making it easy for sites and services to be available via v6 will at least *allow* users to migrate, though making it attractive for them to do so is yet another matter. randy From alh-ietf at tndh.net Sat Oct 29 19:48:33 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Sat, 29 Oct 2005 16:48:33 -0700 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: Message-ID: <0f9701c5dce3$473ec4b0$5ea723c0@tndh.net> For the purposes of discussion, one approach would be to define the PI space in a way that could be aggregated the further it went from the source. A sequential assignment scheme creates a swamp that is hard to manage over time. An approach like: http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-08.txt would allow for aggregation at distance, while still allowing those that want to have a route carried globally to enter into a direct business relationship with each carrier for that routing slot. This would seem to align the burden with the financial model. Even if you started with the assumption that there was no aggregation in the geo based PI approach, as it became popular in each region a business case for exchange based aggregation would emerge. I know that 'topology does not match geography', but this approach would act to constrain topology in a way that would force alignment of the finances with the exceptions. Tony From alh-ietf at tndh.net Sat Oct 29 19:48:33 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Sat, 29 Oct 2005 16:48:33 -0700 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: Message-ID: <0f9b01c5dce3$48812fc0$5ea723c0@tndh.net> Bill Woodcock wrote: > So Chris Morrow and Mike Hughes and Thomas Narten and I were talking more > about this over dinner, and I think the consensus out of that conversation > was this: > I am going to number these to reference them: 1 > - an IPv6 direct-assignment policy should be based directly on the ipv4 > direct-assignment policy, as closely as possible. 2 > - one-size-fits-all probably isn't useful in the long run. 3 > - host-counts are stupid. 4 > - a strict multi-homing requirement is perfectly reasonable. 5 > - preexisting IPv4 deployment should qualify you for IPv6 assignment. 6 > - the size of the assignment should probably be /48 times the number of > sites you have already deployed. 7 > - in order to avoid creative interpretation of "sites," no more than one > site per metro area should be counted. That's arbitrary, but it's an > objectively-verifiable quantity, which is what's needed for the ARIN > analyst staff. > > Thoughts? I don't see a need for point 1. Point 2 is a subset of 6. Point 3 is really introductory text as to why 1 is irrelevant. Maybe 4 & 5 should be combined as 'pre-existing IPv4 multi-homing' is one way to demonstrate compliance. A better way to handle 7 would be to define 6 in terms of multi-party BGP peering points. Tony From alh-ietf at tndh.net Sat Oct 29 19:48:33 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Sat, 29 Oct 2005 16:48:33 -0700 Subject: [ppml] trade in your IPv4 block for an IPv6? In-Reply-To: <20051028070107.4473D11457@sa.vix.com> Message-ID: <0f9f01c5dce3$49bf06f0$5ea723c0@tndh.net> Paul Vixie wrote: > what if someone could get PI IPv6 space by agreeing to return PI IPv4 > space? > > not the same day, mind you. within two years, perhaps. or five years. > an > exchange rate would have to be established, like "if you return a V4 /16, > we > will give you a V6 /48" or even "we'll give you a V6 /(49-N) for the N V4 > /16's you return". the goal would be to shrink or keep stable the size of > the routing table in dual stacked routers, while getting V4 space back > that > we can use for address lifetime extension later when V4 space gets short. > > (i'm trying to think of some early adopter advantages that would have > beneficial side effects.) Encouraging early would be to set a decaying timer on the value of N. Tie both the request date and the actual return date into the equation. Something like 49-N with N=16 to start, and a decay of N at 2 per year. Always round down to the even number (ie: /30 to start) then if the organization returns the IPv4 space within the year they get the odd half that had been rounded out. Tony From alh-ietf at tndh.net Sat Oct 29 19:48:33 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Sat, 29 Oct 2005 16:48:33 -0700 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <0A79726C-B546-4DEE-945F-92B9F4A148C7@cnet.com> Message-ID: <0fa001c5dce3$4b017200$5ea723c0@tndh.net> Steve Feldman wrote: > On Oct 27, 2005, at 11:04 PM, Lea Roberts wrote: > > > > > for the record, the straw poll was 24 vs 25. > > ... And for what it's worth, my vote for the policy was mostly because > it was better than no policy at all, and hoping it could be cleaned > up on the way to adoption. I was also in favor of the original 2005-1. My vote against it was that this particular proposal was so bad that it would be *worse* than no policy at all. There is a need creating pressure so a reasonable policy will be created. If that version passed there would be a 'let it have a chance' attitude that would stall any reasonable text for years. > > > > > For the record, here are some excerpts from what I wrote to Kevin Loch > > inviting him to work on the combined 2005-1 that you are so unhappy > > about. > > I hope this will help others (and maybe even you) to understand how > > the > > extra stuff got piled on. I honestly believe that for 2005-1 to > > achieve > > consensus it has to focus on the large organizations for whom > > renumbering > > is a problem while having criteria which would limit the number of > > qualifying organizations to the range of 5K to 10K. When I wrote > > the text > > below, the feedback from other AC members is that it matched their > > recollection from ARIN XV. > > I think it's a mistake to focus on renumbering as the main issue; it > really comes > down to multihoming. Whether I multihome using PA or PI addresses, > my prefix > is necessarily going to take up a slot in the global routing table. > So if > multihoming is to be allowed at all, routing tables will have to grow. Renumbering, multi-homing, size, and use are all inadequate qualifications that will do nothing more than drag the debate on forever. You are correct that a dedicated PI block, or a whole punched in a PA will consume a routing slot. The issue that needs consideration is why that slot has to be global? Tradition says it will be, but is that really a requirement? Aggregation is about compartmentalizing the knowledge, so the fear here is that we don't know how else to do it. There have been proposals, including the ITU thoughts about country based prefixes, which are ignored because they don't allow the absolute freedom to do random things. PA is no better than country based schemes, unless you are a provider and want to maintain sovereignty over your decisions. > > Given that, it doesn't make much sense to force the multihomers into > PA space > (unless the objective is to provide a disincentive to switch providers.) > > So the fundamental questions should be: > 1) should IPv6 end sites be permitted to multhome? Yes, because they will despite allocation policy. > 2) if so, should there be more stringent restrictions than on IPv4 > multihoming? No. > 3) if so, what sorts of entities should qualify, and how can the > restrictions be > crafted to achieve that goal? It should not be ARIN's job (or any RIR for that matter) to be a judge here. As long as we have a model that says an independent slot has a global impact, the appropriate response is to create a set of membership thresholds each with a specific prefix length. There is no reason to even ask why they might want, or what they will do with that space, just set a price and let economics drive the allocations. It then becomes a routing question of what prefix length will get through, and that is explicitly outside ARIN's domain. Tony From kloch at hotnic.net Sun Oct 30 10:16:01 2005 From: kloch at hotnic.net (Kevin Loch) Date: Sun, 30 Oct 2005 10:16:01 -0500 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: <0A79726C-B546-4DEE-945F-92B9F4A148C7@cnet.com> Message-ID: <4364E3B1.3040404@hotnic.net> Bill Woodcock wrote: > So Chris Morrow and Mike Hughes and Thomas Narten and I were talking more > about this over dinner, and I think the consensus out of that conversation > was this: > > - an IPv6 direct-assignment policy should be based directly on the ipv4 > direct-assignment policy, as closely as possible. > > - one-size-fits-all probably isn't useful in the long run. > > - host-counts are stupid. > > - a strict multi-homing requirement is perfectly reasonable. > > - preexisting IPv4 deployment should qualify you for IPv6 assignment. > > - the size of the assignment should probably be /48 times the number of > sites you have already deployed. > > - in order to avoid creative interpretation of "sites," no more than one > site per metro area should be counted. That's arbitrary, but it's an > objectively-verifiable quantity, which is what's needed for the ARIN > analyst staff. Here's the policy I see condensing out of this: [summary] To qualify for a minimum end site assignment of /44 you must either: - have an allocation or assignment directly from ARIN (and not a legacy allocation or assignment) OR - meet the qualifications for an IPv4 assignment from ARIN without actually requesting one. OR - be currently connected to two or more IPv6 providers with at least one /48 assigned to you by an upstream visible in whois/rwhois. Assignment prefixes shorter than the minimum would be based on some metric and definition of "sites". [/summary] One practical way to look at sites is by number of connections to separate upstream provider POPs. +--------------------------+ | Connections | Assignment | +-------------+------------+ | <12 | /44 | | <=192 | /40 | | <=3072 | /36 | | >3072 | /32 | +-------------+------------+ (C=0.75 * 2^(48-A)) Or if /56 becomes the new default PA assignment shift the assignment sizes right 4 bits. - Kevin From packetgrrl at gmail.com Sun Oct 30 14:13:29 2005 From: packetgrrl at gmail.com (cja@daydream.com) Date: Sun, 30 Oct 2005 12:13:29 -0700 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <0f9701c5dce3$473ec4b0$5ea723c0@tndh.net> References: <0f9701c5dce3$473ec4b0$5ea723c0@tndh.net> Message-ID: Tony, As much as I think that geographical addressing could be a good idea, networks aren't routed geographically. The interconnections aren't there to make aggregation per your RFC feasible. I believe that currently there is as much geography taken into account as can be. The RIRs get blocks for their regions. Some aggregation could be done at that level depending on how things are connected together. I do not believe that assigning PI space per your rfc will gain us anything that assigning PI blocks per region out of a known PI block won't do. You refer in your note to aggregating the further from the source. Unfortunately "distance" is assessed on how far topologically in a provider network the traffic travels, not necessariliy on how far it goes geographically. ---Cathy On 10/29/05, Tony Hain wrote: > > For the purposes of discussion, one approach would be to define the PI > space > in a way that could be aggregated the further it went from the source. A > sequential assignment scheme creates a swamp that is hard to manage over > time. An approach like: > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-08.txt > would allow for aggregation at distance, while still allowing those that > want to have a route carried globally to enter into a direct business > relationship with each carrier for that routing slot. This would seem to > align the burden with the financial model. > > Even if you started with the assumption that there was no aggregation in > the > geo based PI approach, as it became popular in each region a business case > for exchange based aggregation would emerge. I know that 'topology does > not > match geography', but this approach would act to constrain topology in a > way > that would force alignment of the finances with the exceptions. > > Tony > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From memsvcs at arin.net Mon Oct 31 13:02:37 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 31 Oct 2005 13:02:37 -0500 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - to be revised Message-ID: <43665C3D.5010809@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-1 and has determined that while there is no 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 October 27, 2005. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVI/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 current policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_1.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 2005-1: Provider-independent IPv6 Assignments for End Sites Policy statement Add new subsection to the NRPM: 6.5.8. Direct assignments to end sites 6.5.8.1. To qualify for a direct end site assignment, an organization must: 1. not be an LIR; 2. be an end site; 3. be currently multihomed using IPv6 to two or more separate LIR's using at least one /48 assigned to them by each LIR. 4. be able to assign IPv6 addresses to at least 100,000 unique devices within 1 year and advertise that connectivity through it's single aggregated address assignment. 6.5.8.2. Direct assignment size to end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment of /44 6.5.8.3. Subsequent direct assignments to end sites Only one direct assignment may be made to an end site organization under Section 6.5.8 Policy Rationale The original proposal 2005-1 would have provided for a Provider Independent IPv6 allocation to anyone who could qualify for an Autonomous System number. While this proposal failed to reach consensus at the ARIN XV meeting in Orlando in April 2005, the Advisory Council agreed there was sufficient interest in the proposal to see if it could be recrafted into a proposal capable of reaching consensus. The main objections to the original 2005-1 were a concern over a run on AS numbers, which are currently the most constrained Internet Resource until 4-byte ASN's are a reality, and major concerns over the possibility of a large increase in the size of the IPv6 default-free routing table. There were assertions that it was too early for making multi-homing alone a rationale for a direct assignment of IPv6 address space, unless it was only for a limited time, until the viability of the shim6 effort in IETF could be determined. While the current number of sites who multi-home could easily be accomodated at this time, the effect of an IPv6 policy has to be looked at over the multiple 10s of years that IPv6 will need to be functional. Very few people believed that limited time assignments were viable (i.e. could actually be reclaimed) and asserted that it would create a similar situation to IPv4, where early adopters have an unfair advantage. In support of the proposal, a number of commercial companies, who were attending the co-located NAv6TF meeting, expressed their unwillingness to invest resources in deploying IPv6 with Provider Assigned address space, as they were unwilling to be "locked in" to a provider or else have to renumber their entire enterprise. When the sense of the room was taken, the attendees were about evenly split and so there was clearly not a consensus. Discussions with those who opposed the advancement of 2005-1 indicated they were very concerned about almost unlimited access to Provider Independent IPv6 address assignments. They indicated that it was too early in the protocol's lifetime to allow unrestricted routing table growth and expressed the hope that shim6 might still be successful. There is a real belief that IPv4-like multi-homing will doom the IPv6 routing table to grow beyond a workable size and some other solution must be found! Many of them expressed an understanding of the large organization renumbering problem and indicated that they would support a policy that provided for PI address assignments to a small number of large organizations for whom the cost of renumbering would be a significant expense. So this new version of proposal 2005-1 has been reworked to apply to a much more limited number of organizations and should not lead to unrestricted growth of the IPv6 routing table. Timetable for implementation: immediate From memsvcs at arin.net Mon Oct 31 13:04:16 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 31 Oct 2005 13:04:16 -0500 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul - withdrawn Message-ID: <43665CA0.4080301@arin.net> 2005-2 was withdrawn by the author. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on October 27, 2005. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVI/mem.html The current policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_2.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 2005-2: Directory Services Overhaul Policy statement Replace all of section three with the following rewrite. 3. Directory Services 3.1 ARIN Directory Services Databases The ARIN Public Information Database (APID) is a collection of information created and collected by ARIN during the due course of business which the ARIN membership has deemed public information and decided to publish. The ARIN Confidential Information Database (ACID) is a collection of information created and collected by ARIN during the due course of business which the ARIN membership has deemed is confidential information that should be kept under a strict privacy policy. 3.2 Directory Information Made Public ARIN shall publish verified contact information and the resource(s) allocated (including identification for that allocation, like date of allocation or other information identified by ARIN) in the APID in the following cases: * All resources delegated by ARIN. * If allowed by the parent delegation, and requested by the contact listed with the parent, a subdelegation of a resource. ARIN shall insure all contact information in the APID is verified from time to time and is correct to the best of ARIN's ability. ARIN staff shall maintain verification criteria and post it on the ARIN web site. 3.2.1 Non-Responsive Contacts If ARIN is unable to verify contact information via the normal verification procedure ARIN shall attempt to notify the parent of the resource to have the information updated. If there is no parent, or if the data is not corrected in a reasonable amount of time the resource shall be SUSPENDED. Once the resource is suspended ARIN shall make one more request of all contacts listed with the resource and the parent resource (if available), and if no response is received in a reasonable amount of time the resource shall be reclaimed. Third parties may report the inability to make contact with a party via information in the APID. In this case ARIN shall attempt the contact verification procedure for that contact immediately. If a response is received, ARIN should document that a problem occurred, and the response from the resource holder. Offenders who fail to respond to third parties more than 4 times per month for three months may have their resources reclaimed at the discretion of ARIN staff. If a third party submits reports of the inability to make contact that are subsequently disproven, ARIN may choose to ignore reports from specific companies, people, e-mail addresses, or any other classification means as appropriate. The ARIN staff shall publish the time thresholds and procedural details to implement this policy on the ARIN web site. If a resource is reclaimed under no circumstances shall the holder of that resource be entitled to a refund of any fees. 3.3 Data Distribution 3.3.1 Methods of Access ARIN shall publish the APID in the following methods using industry standard practices: * Via the WHOIS protocol. * Via a query form accessible via the HTTP protocol. * Via FTP to users who complete the bulk data form. * Via CDROM to users who complete the bulk data form. * Via the RWHOIS protocol. 3.3.1.1 Outside Sources ARIN may refer a query to a outside source (for instance via RWHOIS or HTTP redirect). Outside sources must: 1. Have an AUP deemed compatible with the ARIN AUP by ARIN staff. 2. Meet the requirements in section 3.3.3. 3. Support the applications in section 3.3.1. 4. Prohibit the applications in section 3.3.2. 3.3.2 Acceptable Usage Policy All data provided shall be subject to an AUP. The AUP shall be written by ARIN staff and legal and posted on the ARIN website. ARIN may require a signed copy of the AUP before providing bulk data. 3.3.3 Requirements for Internet Accessible Services For any method of access which is provided in real time via the Internet the following requirements must be met: * The distributed information service must be operational 24 hours a day, 7 days a week to both the general public and ARIN staff. The service is allowed reasonable downtime for server maintenance according to generally accepted community standards. * The distributed information service must allow public access to reassignment information. The service may restrict the number of queries allowed per time interval from a host or subnet to defend against DDOS attacks, remote mirroring attempts, and other nefarious acts. * The distributed information service must return current information. 3.4 Distribution of the ARIN Public Information Database 3.4.1 Supported Uses ARIN shall make the APID available for the following uses (supported uses): 1. ARIN's use in implementing ARIN policies and other business. 2. Community verification, allowing members of the community to confirm the proper users of the various resources ARIN controls. 3. Statistic gathering by ARIN and third parties on resource utilization. 4. As a contact database to facilitate communication with the person or entity responsible for a particular resource. 3.4.2 Prohibited Uses ARIN prohibits the use of the APID for the following uses: 1. Sending any unsolicited commercial correspondence advertising a product or service to any address (physical or electronic) listed in the APID. 2. Using data in the APID to facilitate violating any state, federal, or local law. 3.4.3 Other Uses ARIN shall allow all non-prohibited uses of the APID, however unless those uses are listed as a supported use the data set may be changed in such a way as to render them ineffective, or they may be blocked outright as deemed necessary by ARIN staff. Users of applications not listed who are concerned that they are supported should introduce a proposal to add their application to the supported list. 3.5 Distribution of the ARIN Confidential Information Database ARIN Staff shall use industry standard procedures to prevent the distribution of any data in the ARIN Confidential Information Database. 3.6 Implementation Details ARIN Staff shall document all implementation specific details for directory services in a single document available on the web site. The document must contain, but is not limited to: * Database field definitions. * Update procedures. * Templates. * Points of contact. * Copies of the AUP. * Verification procedures. 3.7 [Routing Registry] Copy Verbatim from the existing 3.4. Section 4.2.3.7.4: Replace with: All reassignment information for current blocks shall be submitted to ARIN prior to submitting a request for a new allocation. Section 4.2.3.7.6: Strike. Policy Rationale Various proposals affecting directory services have come and gone in the last 5 years leaving the policy affecting directory services fragemented. Also during that time deployments and laws have changed. Several large DSL and cable providers now offer subnets to residential customers that may require them to be registered with ARIN. Several laws have been passed that may restrict the personal information that can be published. This proposal attempts to provide a unified policy that is easier to understand, and is updated to deal with these new issues. Timetable for implementation: 6-18 months, depending on staff impact. From memsvcs at arin.net Mon Oct 31 13:05:03 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 31 Oct 2005 13:05:03 -0500 Subject: [ppml] Policy Proposal 2005-4: AfriNIC Recognition Policy - last call Message-ID: <43665CCF.30801@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-4 and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on October 27, 2005. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVI/mem.html The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_4.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, November 15, 2005. 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 2005-4: AfriNIC Recognition Policy Author: Andrew Dul Policy term: permanent Policy statement: Remove section 4.8 entitled "Policy for the African Portion of the ARIN Region" of the NRPM. Policy Rationale Rationale: The ARIN BoT recently suspended section 4.8 of the NRPM upon recognition of AfriNIC as an RIR by ICANN. Section 4.8 of the NRPM applied only to areas of the ARIN region that are now covered by AfriNIC. Timetable for implementation: Within 30 days of ratification by the BoT. From memsvcs at arin.net Mon Oct 31 13:05:46 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 31 Oct 2005 13:05:46 -0500 Subject: [ppml] Policy Proposal 2005-5: IPv6 HD ratio - last call Message-ID: <43665CFA.2000507@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-5 and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on October 27, 2005. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVI/mem.html The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_5.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, November 15, 2005. 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 2005-5: IPv6 HD ratio Author: Andrew Dul Policy term: permanent Policy statement: Change HD ratio used for IPv6 allocations to 0.94 This would modify sections 6.5.2.2 & 6.7 (including the HD-ratio to percentage table) of the NRPM. Policy Rationale Rationale: Recent research has shown that based upon certain growth models the current IPv6 allocation policy using the HD ratio of 0.8 will allocate between a /1 and /4 of Ipv6 address space over the period of about 60 years. http://www.ietf.org/internet-drafts/draft-huston-ipv6-hd-metric-00.txt By changing the HD ratio to 0.94, this would require LIRs to have a higher utilization of the /48s that are assigned to end sites before being able to obtain additional allocations. This policy would change the threshold for an LIR holding a /32 from approximately 11% to 51%. An LIR with a /20 would have a utilized percentage of approximately 31% vs. the current 2%. This policy may also prevent the hoarding of IPv6 addresses by current organizations with large customer bases, but no substantial current IPv6 network. Timetable for implementation: Within 30 days of ratification by the BoT. From memsvcs at arin.net Mon Oct 31 13:07:38 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 31 Oct 2005 13:07:38 -0500 Subject: [ppml] Policy Proposal 2005-6: IPv4 Micro-allocations for Anycast Services - abandoned Message-ID: <43665D6A.5040409@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-6 and has determined that there is no community consensus in favor of the proposal and should thus be abandoned. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on October 27, 2005. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVI/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 12:00 Noon, Eastern Time, November 8, 2005. The current policy proposal text is provided below and is also available http://www.arin.net/policy/proposals/2005_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 2005-6: IPv4 Micro-allocations for Anycast Services Policy term: permanent Policy statement: In the NRPM IPv4 section, renumber 4.4 to 4.4.1, and add: 4.4.2 Micro-allocations for anycast services - ARIN will make micro-allocations to organizations wishing to deploy anycast based services, provided they meet the following criteria: * All of the criteria normally required to receive IPv4 space, AND * The organization must have multiple (at least two) discrete multi-homed networks. * The organization must identify which networks, ASNs, or sites will host the new service. * The organization must provide a description of the anycast service. Micro-allocations for anycast services will be no longer than a /24. These allocations will be made out of blocks reserved for micro-allocation purposes. ISPs and other organizations receiving these micro-allocations will be charged under the ISP fee schedule, while end-users will be charged under the fee schedule for end-users. Policy Rationale There are an increasing number of anycast-based applications being offered by service providers and other organizations. Indeed, many basic infrastructure services (like the DNS root servers) are already anycast based. (See RFC 1546 for an authoritative discussion of anycast services.) Deployment of new services is hampered, however, by current IPv4 allocation policies. For organizations that do not have legacy IP space, justifying a /22 to serve a handful of addresses is effectively impossible. As many ISPs also filter routes longer than /22, it is impractical to use a longer mask for any netblock that is utilized for an anycast service. This situation is also generally unfavorable to younger organizations, while giving older organizations that do have a surplus of legacy space a competitive advantage. In light of this, some organizations may simply lie about their addressing needs in order to convince an RIR that a /22 is required, when a much smaller network would suffice. This is not a behavior that should be encouraged by policy. The obvious answer is that a micro-allocation scheme needs to be created to allow organizations deploying anycast services to acquire a network of more appropriate size. It is also clear that a micro-allocation policy that makes it easier for organizations to acquire small netblocks may lead to additional improper allocations to organizations that simply wish to acquire additional small blocks of space. This policy proposal attempts to address that by requiring more stringent requirements for such allocations. Timetable for implementation: immediate From memsvcs at arin.net Mon Oct 31 13:07:58 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 31 Oct 2005 13:07:58 -0500 Subject: [ppml] Policy Proposal 2005-7: Rationalize Multi-Homing Definition and Requirement - last call Message-ID: <43665D7E.90008@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-7 and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on October 27, 2005. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVI/mem.html The AC moved 2005-7 to last call as revised. The AC revised 2005-7 by adding a third paragraph to the policy statement to modify Section 4.3.2.2. The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_7.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, November 15, 2005. 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 2005-7: Rationalize Multi-Homing Definition and Requirement Policy statement In existing policy 4.2.2.2, replace the phrase "multi-homed organizations must:" with the phrase "organizations applying under the multi-homed policy must:" In existing policy 4.2.2.2.2, replace "Provide information showing that the requested IP address space will be utilized within three months." with "Provide information showing that the requested IP address space will be utilized within three months and demonstrating an intent to announce the requested space in a multi-homed fasion." In existing 4.3.2.2, replace "For multihomed end-users, the minimum block of IP address space assigned is a /22." with "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 /22." Policy Rationale Presently, organizations wishing to apply for their first address space under the multi-homed policy must demonstrate that they have ALREADY announced a DIFFERENT address block via multi-homing, while simultaneously promising to renumber out of that same block. This creates needless make-work for ISPs which are planning to multi-home, related to old resources which they're already trying to get out of. Likewise, it creates needless work for both of their upstream providers, who have to temporarily announce a prefix which DOESN'T NEED to be multi-homed, solely to demonstrate to ARIN analysts that the applying ISP is multi-homed. However, this same criterion can be demonstrated just as effectively by the applying ISP showing the analyst contracts with multiple ISPs under which the newly-applied-for block WILL BE multi-homed, and this more accurately reflects the intent of the original policy, while removing needless make-work at a time when the applicant is surely already quite busy with the real requirements of their change-over. From memsvcs at arin.net Mon Oct 31 13:08:14 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 31 Oct 2005 13:08:14 -0500 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - to be revised Message-ID: <43665D8E.8020903@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-8 and has determined that while there is no 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 October 27, 2005. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVI/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 current policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_8.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 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement Policy statement It is proposed to make the following changes to the existing ARIN IPv6 policy: 1. Define an additional end site assignment size of /56. This /56 assignment should be considered the general case, intended for small office, household, and personal networks, and other small and medium-sized deployments where the number of potential subnets exceeds 1, but is not expected to exceed 256. 2. Amend the existing policy regarding /48 end-site assignments to refer specifically to assignments to large enterprise and corporate end-site environments where there is a requirement for more than 255 subnets at the end site. 3. Amend the evaluation threshold calculation to be based on a default end site assignment size of a /56. Further end-site assignment information should be provided to ARIN in order to use a different average end-site assignment size for HD-ratio calculation purposes. Policy Rationale The key benefit of IPv6 is its large address space, and a fundamental assumption motivating its adoption is that with IPv6, sufficient address space will always be available to ensure that users can obtain sufficent public address space for their needs. Projections for IPv6 address consumption over the next 50-100 years indicate that there are scenarios (depending on one's assumptions) in which a signficant percentage of the total IPv6 address space could be handed out, raising the possibility that address allocation policies will then need to be revised to become significantly more conservative to ensure that the IPv6 address space does not become exhausted. Given the IPv4 experience, in which early adopters were able to acquire large amounts of address space easily, but later adopters were not, and the resultant problems this has caused, it would be preferable to take steps now to signficantly reduce the likelyhood of ever needing to make such a change, especially if changes can be made with minimal impact. The RIR communities adopted address allocation policies in 2002 in which the default assignment to end sites was assumed to be a /48 in many cases. For SOHO users (e.g., home users and small businesses), being given enough address space to number 65,536 subnets seems excessive given their anticipated needs. Changing the default assignment size to a /56 allows for numbering 256 subnets, still a large number. Making such a change would save roughly two orders of magnitude of address space. That is, for any projection made assuming a /48 assignment, assigning /56s instead would result in roughly 100 times less total consumption. The goal of this policy proposal is not to make it impossible for end sites to obtain a /48. Rather, it is intended to make the default assignment size a /56 in the vast number of cases where a /48 seems profligate. In those cases where the end site can argue that it has a need for more than 256 subnets, a /48 should be given out. Background information: "Issues Related to the Management of IPv6 Address Space", by Thomas Narten. http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6-considerations-00.txt Similar policy proposal submitted to APNIC (includes detailed background and pointers to more background information than is included here). http://www.apnic.net/docs/policy/discussions/prop-031-v001.txt State of related discussion in other RIRs: See section "Situation in other RIRs" in http://www.apnic.net/docs/policy/discussions/prop-031-v001.txt IETF revisitation of RFC 3177 "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", the document in which the case for assigning /48s was made. http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt (note: this document was adopted as a WG item by the IPv6 WG at IETF 63 in August.) Timetable for implementation: Immediate (upon approval) From ahp at hilander.com Mon Oct 31 13:15:06 2005 From: ahp at hilander.com (Alec H. Peterson) Date: Mon, 31 Oct 2005 11:15:06 -0700 Subject: [ppml] Policy Proposal 2005-7: Rationalize Multi-Homing Definition and Requirement - last call In-Reply-To: <43665D7E.90008@arin.net> References: <43665D7E.90008@arin.net> Message-ID: <0AF5343F-3079-44D6-9A48-023A66E4D177@hilander.com> Hi all, On Oct 31, 2005, at 11:07, Member Services wrote: > The ARIN Advisory Council (AC), acting under the provisions of the > ARIN > Internet Resource Policy Evaluation Process (IRPEP), has reviewed > policy > proposal 2005-7 and has determined that there is community > consensus in > favor of the proposal to move it to last call. The AC made this > determination at their meeting at the conclusion of the ARIN Public > Policy meeting on October 27, 2005. The results of the AC meeting were > reported by the Chair of the AC at the member meeting. This report can > be found at > http://www.arin.net/meetings/minutes/ARIN_XVI/mem.html > > The AC moved 2005-7 to last call as revised. The AC revised 2005-7 by > adding a third paragraph to the policy statement to modify Section > 4.3.2.2. It should be noted that while this was discussed at the public policy meeting a sense of the room was not gathered on this change. If anybody does object to this change they should speak up here. For what it's worth, I did object to this during the AC meeting on Thursday, not because I disagree with the change itself, but rather because ARIN policy has a history of distinguishing between assignments and allocations, and I felt it was not a 'minor' change. So, the only issue I saw with it was a procedural one rather than one that would cause any problem with the policy. Alec From billd at cait.wustl.edu Mon Oct 31 15:29:36 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Mon, 31 Oct 2005 14:29:36 -0600 Subject: [ppml] Policy Proposal 2005-7: Rationalize Multi-Homing Definition and Requirement - Clarifying Edit..... Message-ID: Alec Peterson said.... > Hi all, > > On Oct 31, 2005, at 11:07, Member Services wrote: > > > The ARIN Advisory Council (AC), acting under the provisions of the > > ARIN > > Internet Resource Policy Evaluation Process (IRPEP), has reviewed > > policy > > proposal 2005-7 and has determined that there is community > > consensus in > > favor of the proposal to move it to last call. The AC made this > > determination at their meeting at the conclusion of the ARIN Public > > Policy meeting on October 27, 2005. The results of the AC > meeting were > > reported by the Chair of the AC at the member meeting. This > report can > > be found at > > http://www.arin.net/meetings/minutes/ARIN_XVI/mem.html > > > > The AC moved 2005-7 to last call as revised. The AC revised > 2005-7 by > > adding a third paragraph to the policy statement to modify Section > > 4.3.2.2. > > It should be noted that while this was discussed at the > public policy > meeting a sense of the room was not gathered on this change. If > anybody does object to this change they should speak up here. > > For what it's worth, I did object to this during the AC meeting on > Thursday, not because I disagree with the change itself, but rather > because ARIN policy has a history of distinguishing between > assignments and allocations, and I felt it was not a 'minor' > change. > So, the only issue I saw with it was a procedural one rather > than one > that would cause any problem with the policy. > > Alec > Specifically what Alec is alluding to is the addition of an edit to 4.3.2.2 and thus the inclusion of the modified text as part of 2005-7 The ORIGINAL 4.3.2.2 text was... "For multihomed end-users, the minimum block of IP address space assigned is a /22. If assignments smaller than a /22 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." The proposed language becomes... "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 /22. If assignments smaller than a /22 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." As such, the first sentence of 4.3.2.2 is 'clarified' to explicitly state the expectation that addresses assigned for multihoming will be used for multihoming....and use language consistent with the 4.2.2.2 and 4.2.2.2.2 used in 2005-7. This clarification was deemed by the AC to be prudent and NOT represent material change to the policy on multihoming. Bill Darte ARIN AC From matt.pounsett at cira.ca Mon Oct 31 15:43:52 2005 From: matt.pounsett at cira.ca (Matt Pounsett) Date: Mon, 31 Oct 2005 15:43:52 -0500 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <4364E3B1.3040404@hotnic.net> References: <0A79726C-B546-4DEE-945F-92B9F4A148C7@cnet.com> <4364E3B1.3040404@hotnic.net> Message-ID: <72937AE9-4D14-4DEC-9D06-30AAD956D9FD@cira.ca> On 30-Oct-2005, at 10:16 , Kevin Loch wrote: > Here's the policy I see condensing out of this: > > [summary] > > To qualify for a minimum end site assignment of /44 you must > either: > > - have an allocation or assignment directly from ARIN (and not a > legacy allocation or assignment) > OR > > - meet the qualifications for an IPv4 assignment from ARIN without > actually requesting one. I like the idea of directly linking PI v6 assignments to some corresponding minimum size of v4 assignment. I think that approach has the potential to allow larger organizations to be early adopters while still limiting the number of assignments to prevent a run. Long term we will eventually have to find a better metric, but for the foreseeable future I don't think it's likely to expect anyone in the ARIN region to be deploying v6-only networks. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From Lee.Howard at stanleyassociates.com Mon Oct 31 16:46:38 2005 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 31 Oct 2005 16:46:38 -0500 Subject: [ppml] 2005-1 or its logical successor Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB47FFAEC@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Bill Woodcock > Sent: Friday, October 28, 2005 4:04 AM > To: Steve Feldman > Cc: ppml at arin.net > Subject: Re: [ppml] 2005-1 or its logical successor > > On Thu, 27 Oct 2005, Steve Feldman wrote: > > > for the record, the straw poll was 24 vs 25. > > ... And for what it's worth, my vote for the policy was > mostly because > > it was better than no policy at all, and hoping it > could be cleaned > > up on the way to adoption. I was also in favor of the > original 2005-1. > > So the two people who've explained their "yes" votes have > both said that > they voted for something unacceptable, hoping it could be salvaged > afterwards. Hardly a ringing endorsement. Whereas the > second vote, to > fix this, was unanimous except for Randy and Lee, both of whom were > joking because Stacy had offered to spank them. I suppose I should correct the record. I raised my hand for the policy as presented because it was sufficiently narrow that it was unlikely to cause problems, and the belt can be loosened later. I raised my hand against further work on this because I want the v6 sphincter opened slowly, and I'm not sure that's the sense of the AC. Though Stacy has wiles, the only way she could affect my conscience is through articulate argument, of which she is quite capable when she chooses. Lee > > -Bill > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From Lee.Howard at stanleyassociates.com Mon Oct 31 16:51:34 2005 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 31 Oct 2005 16:51:34 -0500 Subject: [ppml] 2005-1 or its logical successor Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB47FFAF4@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Bill Woodcock > Sent: Friday, October 28, 2005 4:23 AM > To: ppml at arin.net > Subject: Re: [ppml] 2005-1 or its logical successor > > > So Chris Morrow and Mike Hughes and Thomas Narten and I were > talking more > about this over dinner, and I think the consensus out of that > conversation > was this: > > - an IPv6 direct-assignment policy should be based directly > on the ipv4 direct-assignment policy, as closely as possible. As a starting point, but not all the way through. > - one-size-fits-all probably isn't useful in the long run. There doesn't seem to be consensus on this, though those of us who like CIDR/VLSM seem to agree. > - host-counts are stupid. Subnet counts make more sense in IPv6. > - a strict multi-homing requirement is perfectly reasonable. > - preexisting IPv4 deployment should qualify you for IPv6 assignment. Maybe, but not necessarily a direct assignment. > - the size of the assignment should probably be /48 times the > number of sites you have already deployed. Or plan to deploy in the next t months? > - in order to avoid creative interpretation of "sites," no > more than one > site per metro area should be counted. That's arbitrary, > but it's an > objectively-verifiable quantity, which is what's needed for the ARIN > analyst staff. That seems a bit odd. Why this? Lee > > Thoughts? > > -Bill > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From alh-ietf at tndh.net Mon Oct 31 19:51:08 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 31 Oct 2005 16:51:08 -0800 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: Message-ID: <10c601c5de7e$5cdcffc0$5ea723c0@tndh.net> Cathy, When you look too closely you can't see the forest for the trees. Yes on a fine grained scale topology is not currently limited by geography. On a global scale there are very few paths between major regions. The totally random interconnect model is not a technical requirement; it is a business choice that directly impacts the global routing system. People are complaining about the size of the routing table, but that table could be contracted by restricting topology. All of that misses the point though. Today we don't want to think about restricting topology. I was not suggesting that by using a geo method for PI would actually change anything in the short term. As long as everyone that gets PI has a real global routing slot it really doesn't matter how those are handed out. The point of the note was to look at the option that PI be allocated such that down the road if the decision about random interconnects changed we would have the option to aggregate out many of those PI prefixes that are not necessary in the 'local' context where local is truly defined by operators/policy makers in any given space. Structured interconnects have a different business model than we are currently operating under, but they do have substantial impact on the size of the routing system. There is no reason for ARIN to even bother with evaluating 'need' or 'appropriate use' of PI space as long as there is a way for providers to aggregate out the ones that have not paid enough to support a global slot. Most small/home multi-homers would be perfectly happy with failover between local providers in a city. Trying to set a threshold of number of hosts/subnets to get PI space is strictly about trying to limit the routing table size. That is not ARIN's problem, it is the provider's problem. ARIN has a role in that the assignments need to be done in a way that allows the providers to do the aggregation. Tony _____ From: cja at daydream.com [mailto:packetgrrl at gmail.com] Sent: Sunday, October 30, 2005 11:13 AM To: Tony Hain Cc: ppml at arin.net Subject: Re: [ppml] 2005-1 or its logical successor Tony, As much as I think that geographical addressing could be a good idea, networks aren't routed geographically. The interconnections aren't there to make aggregation per your RFC feasible. I believe that currently there is as much geography taken into account as can be. The RIRs get blocks for their regions. Some aggregation could be done at that level depending on how things are connected together. I do not believe that assigning PI space per your rfc will gain us anything that assigning PI blocks per region out of a known PI block won't do. You refer in your note to aggregating the further from the source. Unfortunately "distance" is assessed on how far topologically in a provider network the traffic travels, not necessariliy on how far it goes geographically. ---Cathy On 10/29/05, Tony Hain wrote: For the purposes of discussion, one approach would be to define the PI space in a way that could be aggregated the further it went from the source. A sequential assignment scheme creates a swamp that is hard to manage over time. An approach like: http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-08.txt would allow for aggregation at distance, while still allowing those that want to have a route carried globally to enter into a direct business relationship with each carrier for that routing slot. This would seem to align the burden with the financial model. Even if you started with the assumption that there was no aggregation in the geo based PI approach, as it became popular in each region a business case for exchange based aggregation would emerge. I know that 'topology does not match geography', but this approach would act to constrain topology in a way that would force alignment of the finances with the exceptions. Tony _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at vix.com Mon Oct 31 20:14:21 2005 From: paul at vix.com (Paul Vixie) Date: Tue, 01 Nov 2005 01:14:21 +0000 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: Your message of "Mon, 31 Oct 2005 16:51:08 PST." <10c601c5de7e$5cdcffc0$5ea723c0@tndh.net> References: <10c601c5de7e$5cdcffc0$5ea723c0@tndh.net> Message-ID: <20051101011421.E088311425@sa.vix.com> # On a global scale there are very few paths between major regions. that's not the forest i can see from here. but even if i agreed, i'd ask you to transform this numerology into science by showing actual numbers, and explaining why the current numbers are likely to be similar to future ones. (that's me channelling kc in case anybody's keeping score at home.) # The totally random interconnect model is not a technical requirement; it is # a business choice that directly impacts the global routing system. People # are complaining about the size of the routing table, but that table could be # contracted by restricting topology. ah, well, if you want to talk about ways that architectural choices can influence business choices, let's start with IPv4 PA space and CIDR, which was an architectural choice that led to large scale ISP lock-in. even if current numbers justified your proposed design, and if you had strong arguments as to why future numbers would also justify your proposed design, would the industry be well served by an address assignment architecture which favoured the "very few very fat pipes between regions" model? i think if we could get far enough through these weeds to reach that argument, i'd argue the opposite case VERY strongly. # All of that misses the point though. Today we don't want to think about # restricting topology. I was not suggesting that by using a geo method for PI # would actually change anything in the short term. As long as everyone that # gets PI has a real global routing slot it really doesn't matter how those # are handed out. The point of the note was to look at the option that PI be # allocated such that down the road if the decision about random interconnects # changed we would have the option to aggregate out many of those PI prefixes # that are not necessary in the 'local' context where local is truly defined # by operators/policy makers in any given space. Structured interconnects have # a different business model than we are currently operating under, but they # do have substantial impact on the size of the routing system. just as some folks have to pay more to route PI space than PA space, and some folks have to pay more for fixed than dynamic addresses, and some folks have to pay more for real than NAT'd addresses, we could some day live in a world where folks have to pay more for super-regional than regional addresses. i'm not sure i like where this is going. # There is no reason for ARIN to even bother with evaluating 'need' or # 'appropriate use' of PI space as long as there is a way for providers to # aggregate out the ones that have not paid enough to support a global slot. if we're going to do provider-centric address allocation design, why would we say we wanted PI space at all? how about we allocate space based on need and appropriate use, and let providers compete on how well they can serve their customers? # Most small/home multi-homers would be perfectly happy with failover between # local providers in a city. then let such cities get themselves some address space, build an internet exchange, build a wireless network, number their citizens, and let transit providers compete over the result. ARIN's current policies would allow this. (and it's a damned damned DAMNED fine idea.) # Trying to set a threshold of number of hosts/subnets to get PI space is # strictly about trying to limit the routing table size. That is not ARIN's # problem, it is the provider's problem. ARIN has a role in that the # assignments need to be done in a way that allows the providers to do the # aggregation. ARIN also has to balance the needs of the people who will use the addresses. if the only consideration was "what providers need", we'd stick with PA space. From alh-ietf at tndh.net Mon Oct 31 22:50:31 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 31 Oct 2005 19:50:31 -0800 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <20051101011421.E088311425@sa.vix.com> Message-ID: <112701c5de97$6c0bd570$5ea723c0@tndh.net> Paul Vixie wrote: > ... > # All of that misses the point though. Today we don't want to think about > # restricting topology. I was not suggesting that by using a geo method > for PI > # would actually change anything in the short term. As long as everyone > that > # gets PI has a real global routing slot it really doesn't matter how > those > # are handed out. The point of the note was to look at the option that PI > be > # allocated such that down the road if the decision about random > interconnects > # changed we would have the option to aggregate out many of those PI > prefixes > # that are not necessary in the 'local' context where local is truly > defined > # by operators/policy makers in any given space. Structured interconnects > have > # a different business model than we are currently operating under, but > they > # do have substantial impact on the size of the routing system. > > just as some folks have to pay more to route PI space than PA space, and > some > folks have to pay more for fixed than dynamic addresses, and some folks > have > to pay more for real than NAT'd addresses, we could some day live in a > world > where folks have to pay more for super-regional than regional addresses. > i'm > not sure i like where this is going. But that is exactly what is argued as necessary to align the cost with the pain. The super-regional addresses are the source of the pain in the routing system so why shouldn't they carry the cost? Multi-homing within a region does have impact on the routers serving that region, but ONLY the routers within that region. > > # There is no reason for ARIN to even bother with evaluating 'need' or > # 'appropriate use' of PI space as long as there is a way for providers to > # aggregate out the ones that have not paid enough to support a global > slot. > > if we're going to do provider-centric address allocation design, why would > we > say we wanted PI space at all? how about we allocate space based on need > and > appropriate use, and let providers compete on how well they can serve > their > customers? I didn't say they were provider centric, just that they could be aggregated out. In any case, who gets to decide the value of 'need' and why do they get to decide that? > > # Most small/home multi-homers would be perfectly happy with failover > between > # local providers in a city. > > then let such cities get themselves some address space, build an internet > exchange, build a wireless network, number their citizens, and let transit > providers compete over the result. ARIN's current policies would allow > this. > (and it's a damned damned DAMNED fine idea.) ARIN policy allows this, but there is an external conflict in 'use of public funds to compete with industry'. It really doesn't matter if the exchange operator is a city, a consortium of ISPs, or an independent enterprise as in the current set. The bottom line is that all the 'insanity' that is necessary to sort those things out within the city/region is contained at that exchange and the transit providers have a clean demarc to compete over. > > # Trying to set a threshold of number of hosts/subnets to get PI space is > # strictly about trying to limit the routing table size. That is not > ARIN's > # problem, it is the provider's problem. ARIN has a role in that the > # assignments need to be done in a way that allows the providers to do the > # aggregation. > > ARIN also has to balance the needs of the people who will use the > addresses. > if the only consideration was "what providers need", we'd stick with PA > space. One of the biggest issues that gets overlooked is that we are not restricted to choosing one or the other. PA space is fine for those that don't care where the space comes from. Some entities (including DNS roots) have needs that don't fit in the PA model. The current debate is about who gets to pass judgment on the value of 'need'. The most effective judge of value is the organization requesting the resource. If they are presented with a menu of resource bundles and prices they can make the clear determination of the bundle that actually meets their need with the value measure that will naturally pushback to keep them from demanding more than they need. A sequential allocation of PI space creates the swamp that becomes impossible to deal with over time. A structured allocation builds the option that down the road it is possible to enforce exchange point based aggregation if and/or where that becomes necessary. It really doesn't matter what structure you choose, the constraint of topology to fit that structure is what reduces the impact on the routing system. The point is to think about ways to allocate PI space that will allow for long terms options. Tony