From Ed.Lewis at neustar.biz Fri Jan 6 11:23:16 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 6 Jan 2006 11:23:16 -0500 Subject: [ppml] The coming end of the 6bone Message-ID: Questions just to provoke a moment of thought because but the 6Bone is slated to go away in 5 months from today (IETF RFC 3701). Is there anything that is still needed to prepare ARIN (policies, services) for this? Should we, the ARIN community, do any outreach to those still depending on 6Bone addresses - as in showing them the way to move onto production v6? ARIN is not responsible for 6Bone, but, is there something we need to do or consider? PS - Prompted by http://www.merit.edu/mail.archives/nanog/msg14803.html -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Inactionable unintelligence is bliss. From memsvcs at arin.net Mon Jan 9 10:34:36 2006 From: memsvcs at arin.net (Member Services) Date: Mon, 09 Jan 2006 10:34:36 -0500 Subject: [ppml] Deadline for Policy Proposals - February 9, 2006 Message-ID: <43C2828C.6080901@arin.net> The ARIN XVII Public Policy Meeting will take place April 10-11, 2006, in Montreal. New policy proposals must be submitted by 23:59 EST, February 9, 2006, in order to be considered by the ARIN Advisory Council for possible inclusion on the ARIN XVII agenda. This is in accordance with ARIN's Internet Resource Policy Evaluation Process, which requires that proposed policies be submitted at least 60 days prior to the meeting. Those who wish to propose new ARIN number resource policies or modifications to existing policies must submit a Policy Proposal Template. The template must be sent via e-mail to policy at arin.net. The Policy Proposal Template can be found at: http://www.arin.net/policy/irpep_template.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) From memsvcs at arin.net Tue Jan 10 14:03:18 2006 From: memsvcs at arin.net (Member Services) Date: Tue, 10 Jan 2006 14:03:18 -0500 Subject: [ppml] Maintenance Work on Monday, 16 January 2006 Message-ID: <43C404F6.5050201@arin.net> On Monday, January 16, 2006, ARIN will perform hardware maintenance. This work is scheduled from 8 AM until 12 PM Eastern time. During this time, the automated mail responder for our role accounts and the processing of credit card payments will be unavailable. All other services will not be affected. Role mail will queue during this maintenance window. Auto response messages will start being sent once all systems are back online. Please do not re-send your mail if you do not receive a ticket number right away. We apologize for any inconvenience this may cause to our members and all in the Internet community. Regards, Ginny Listman Director of Engineering American Registry for Internet Numbers From memsvcs at arin.net Fri Jan 13 17:06:53 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 13 Jan 2006 17:06:53 -0500 Subject: [ppml] ARIN's Interpretation of 2003-3 Message-ID: <43C8247D.9060306@arin.net> On 27 October 2005 the following statement was made on the ppml: "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." ARIN's interpretation: A. Background. 1. Policy Proposal 2003-3 as implemented is stated in paragraphs 4.2.3.7.6 and 6.5.5.1. Section 4 deals with policy statements relative to IPv4 while section 6 deals with IPv6. Both sections state the following: "To maintain the privacy of their residential customers, an organization with downstream residential customers may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block." Policy Proposal 2003-3 was adopted by the ARIN Board on 22 March 2004. 2. In section 3.2 the NRPM also mentions privacy where it states: "The service may allow for privacy protections for customers. For residential users, the service may follow ARIN's residential privacy policy that includes displaying only the city, state, zip code, and country." In this policy statement the address element that pertains to the street number and name is, by omission, identified as the portion of a postal address that may be chosen not to be displayed because of privacy protection. Section 3.2 is the implementation of Policy Proposal 2003-5. The Board adopted Policy Proposal 2003-5 on 10 June 2004. The Board, by sequential adoption of these two proposals, has interpreted street address to mean that element of a postal address that conveys the street number and name. This interpretation is substantiated by the USPS Domestic Mailing Manual publication DMM 300, Mailing Standards of the United States Postal Service, Section 602, paragraph 1.4 which describes the elements of a complete address. In this description the element that contains the street name and number or PO Box are identified as a distinct element from that element that contains the city and state. This distinction is further emphasized by the USPS Domestic Mail Manual publication DMM 100, A Customer's Guide to Mailing. In DMM 100 the term "Street Address" is used to refer to the element described in DMM 300 as the street name and number. B. Statement of Interpretation. ARIN interprets street address to mean that element of a postal address that identifies street name and number. Raymond A. Plzak President & CEO ARIN From billd at cait.wustl.edu Sat Jan 14 11:28:55 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Sat, 14 Jan 2006 10:28:55 -0600 Subject: [ppml] ARIN's Interpretation of 2003-3 Message-ID: 'First Class Post", Ray.... ;-) Happy new year to all.... Bill Darte ARIN AC -----Original Message----- From: ppml-bounces at arin.net To: ppml at arin.net Sent: 1/13/06 4:06 PM Subject: [ppml] ARIN's Interpretation of 2003-3 On 27 October 2005 the following statement was made on the ppml: "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." ARIN's interpretation: A. Background. 1. Policy Proposal 2003-3 as implemented is stated in paragraphs 4.2.3.7.6 and 6.5.5.1. Section 4 deals with policy statements relative to IPv4 while section 6 deals with IPv6. Both sections state the following: "To maintain the privacy of their residential customers, an organization with downstream residential customers may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block." Policy Proposal 2003-3 was adopted by the ARIN Board on 22 March 2004. 2. In section 3.2 the NRPM also mentions privacy where it states: "The service may allow for privacy protections for customers. For residential users, the service may follow ARIN's residential privacy policy that includes displaying only the city, state, zip code, and country." In this policy statement the address element that pertains to the street number and name is, by omission, identified as the portion of a postal address that may be chosen not to be displayed because of privacy protection. Section 3.2 is the implementation of Policy Proposal 2003-5. The Board adopted Policy Proposal 2003-5 on 10 June 2004. The Board, by sequential adoption of these two proposals, has interpreted street address to mean that element of a postal address that conveys the street number and name. This interpretation is substantiated by the USPS Domestic Mailing Manual publication DMM 300, Mailing Standards of the United States Postal Service, Section 602, paragraph 1.4 which describes the elements of a complete address. In this description the element that contains the street name and number or PO Box are identified as a distinct element from that element that contains the city and state. This distinction is further emphasized by the USPS Domestic Mail Manual publication DMM 100, A Customer's Guide to Mailing. In DMM 100 the term "Street Address" is used to refer to the element described in DMM 300 as the street name and number. B. Statement of Interpretation. ARIN interprets street address to mean that element of a postal address that identifies street name and number. Raymond A. Plzak President & CEO ARIN _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From Michael.Dillon at btradianz.com Tue Jan 17 09:40:44 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 17 Jan 2006 14:40:44 +0000 Subject: [ppml] ARIN's Interpretation of 2003-3 Message-ID: >ARIN interprets street address to mean that element of a postal address >that identifies street name and number. It is quite clear then that ISPs should replace the zip code or postal code with the text "Private Residence" since the U.S. zip code and the Canadian postal code both identify the street name and number. Therefore, ISPs should repeat the text "Private Residence" twice in their whois data. Unfortunately, ARIN's policy makers are unaware of how the postal system works and why zip codes and postal codes were introduced into the addressing system in North America. Otherwise they would have simply stated clearly that zip codes and postal codes could be left blank when obscuring the street address. It is a pity that they did not consult an expert in the workings of the postal system, or an expert in finding people. Either one would have informed ARIN that the zip code or postal code identifies the street address to within half a dozen houses. --Michael Dillon From Ed.Lewis at neustar.biz Tue Jan 17 09:50:59 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 17 Jan 2006 09:50:59 -0500 Subject: [ppml] ARIN's Interpretation of 2003-3 In-Reply-To: References: Message-ID: At 14:40 +0000 1/17/06, Michael.Dillon at btradianz.com wrote: >Unfortunately, ARIN's policy makers are unaware >of how the postal system works and why zip codes >and postal codes were introduced into the addressing >system in North America. Otherwise they would have >simply stated clearly that zip codes and postal codes >could be left blank when obscuring the street address. > >It is a pity that they did not consult an expert >in the workings of the postal system, or an expert >in finding people. Either one would have informed >ARIN that the zip code or postal code identifies >the street address to within half a dozen houses. ARIN Policy is *made* by the general population - i.e. anyone. (It is adopted by the board, not made by the board.) Not just ARIN members, not just those on a mailing list. That is why ARIN has "public policy" meetings twice a year in addition to member meetings. ARIN is doing its best to draw in comments, etc., from the "grass roots." Before anyone casts dispersions on ARIN policy makers remember that they too could be one - if they so desire. The process is open. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Inactionable unintelligence is bliss. From Ed.Lewis at neustar.biz Tue Jan 17 11:13:31 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 17 Jan 2006 11:13:31 -0500 Subject: [ppml] ARIN's Interpretation of 2003-3 In-Reply-To: References: Message-ID: At 9:50 -0500 1/17/06, Edward Lewis wrote: >Before anyone casts dispersions on ARIN policy makers remember that s/dispersions/aspersions/ >they too could be one - if they so desire. The process is open. Shoulda taken than English Vocabulary 201... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Inactionable unintelligence is bliss. From sleibrand at internap.com Tue Jan 17 11:32:06 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 17 Jan 2006 11:32:06 -0500 (EST) Subject: [ppml] ARIN's Interpretation of 2003-3 In-Reply-To: References: Message-ID: Michael, 5-digit ZIP codes do not identify street names or numbers, though 9-digit ZIP+4 codes often do. Is there any requirement that ISPs use ZIP+4 codes instead of 5-digit ZIP codes when dealing with Private Residences? The small sample of WHOIS queries I just did show mostly 5-digit ZIP codes. If ZIP+4 codes are not required, then I don't believe that inclusion of a (5-digit) ZIP code constitutes disclosure of identifying information that should be obfuscated. -Scott On 01/17/06 at 2:40pm -0000, Michael.Dillon at btradianz.com wrote: > >ARIN interprets street address to mean that element of a postal address > >that identifies street name and number. > > It is quite clear then that ISPs should replace > the zip code or postal code with the text > "Private Residence" since the U.S. zip code > and the Canadian postal code both identify the > street name and number. > > Therefore, ISPs should repeat the text > "Private Residence" twice in their whois > data. > > Unfortunately, ARIN's policy makers are unaware > of how the postal system works and why zip codes > and postal codes were introduced into the addressing > system in North America. Otherwise they would have > simply stated clearly that zip codes and postal codes > could be left blank when obscuring the street address. > > It is a pity that they did not consult an expert > in the workings of the postal system, or an expert > in finding people. Either one would have informed > ARIN that the zip code or postal code identifies > the street address to within half a dozen houses. > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From woody at pch.net Tue Jan 17 12:52:16 2006 From: woody at pch.net (Bill Woodcock) Date: Tue, 17 Jan 2006 09:52:16 -0800 (PST) Subject: [ppml] ARIN's Interpretation of 2003-3 In-Reply-To: References: Message-ID: On Tue, 17 Jan 2006 Michael.Dillon at btradianz.com wrote: > It is quite clear then that ISPs should replace > the zip code or postal code No, Michael, that's quite clear to _you_, but not to the _majority_ of ARIN policy process participants. The fact that other people see things differently than you do doesn't make them wrong and you right. This is a question of preference, not a question of correctness. A consensus was arrived at through the policy process. It's not correct or incorrect, it's the preference of the majority of the policy process participants. Which is what ARIN does. -Bill From weiler at tislabs.com Tue Jan 17 13:55:18 2006 From: weiler at tislabs.com (Samuel Weiler) Date: Tue, 17 Jan 2006 13:55:18 -0500 (EST) Subject: [ppml] ARIN's Interpretation of 2003-3 Message-ID: On Tue, 17 Jan 2006, Bill Woodcock wrote: > ... This is a question of preference, not a question of correctness. > A consensus was arrived at through the policy process. It's not > correct or incorrect, it's the preference of the majority of the > policy process participants. Which is what ARIN does. I'm not convinced this really is the preference of the majority -- this particular point (whether postal codes may be suppressed) was barely mentioned in the discussion of 2003-3. I assumed that the policy was talking about the entire address, in part based on the fact that "street name and number" wasn't generally called out in the discussion. Far more common were messages saying "address information" and posts like this one, which says "name and home address": http://lists.arin.net/pipermail/ppml/2003-July/001902.html Admittedly, there were two posts that highlighted the "street name and number only" bit, but I overlooked them at the time, and others may have also. I also don't see anything in the minutes of the public policy meetings suggesting that this point was mentioned there (though I haven't reviewed the audio). All that said, I think Michael is correct: in many cases postal codes do allow for identification of very few individuals, particularly considering the set of those likely to have their own IP assignments. So requiring them to be published defeats the intent of 2003-3, at least as I read it. It looks like the right path forward is a new policy proposal to clarify 2003-3 and 2003-5. I'll submit one shortly. -- Sam From arin-member at quadrix.com Tue Jan 17 15:46:37 2006 From: arin-member at quadrix.com (Bill Van Emburg) Date: Tue, 17 Jan 2006 14:46:37 -0600 Subject: [ppml] PPML Digest, Vol 7, Issue 5 In-Reply-To: References: Message-ID: <43CD57AD.5060303@quadrix.com> Michael, It seems quite clear to me that the statement of interpretation is NOT meant to suggest that "Private Residence" should be placed in the zip code field. First of all, as has already been mentioned, you need the ZIP+4 to narrow it down to a small area. Second, that would still not make it "street name and number." ARIN meant "street name and number," not "any field that might narrow things down to street name and number in some cases." Therefore, the policy would be to put "Private Residence" into the field for "street name and number," and not "other fields that the subject thinks might narrow things down too much." I think ARIN has been quite clear here. -Bill Van Emburg Quadrix Solutions, Inc. > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 17 Jan 2006 14:40:44 +0000 > From: Michael.Dillon at btradianz.com > Subject: Re: [ppml] ARIN's Interpretation of 2003-3 > >>ARIN interprets street address to mean that element of a postal address >>that identifies street name and number. > > > It is quite clear then that ISPs should replace > the zip code or postal code with the text > "Private Residence" since the U.S. zip code > and the Canadian postal code both identify the > street name and number. > > Therefore, ISPs should repeat the text > "Private Residence" twice in their whois > data. > > Unfortunately, ARIN's policy makers are unaware > of how the postal system works and why zip codes > and postal codes were introduced into the addressing > system in North America. Otherwise they would have > simply stated clearly that zip codes and postal codes > could be left blank when obscuring the street address. > > It is a pity that they did not consult an expert > in the workings of the postal system, or an expert > in finding people. Either one would have informed > ARIN that the zip code or postal code identifies > the street address to within half a dozen houses. > > --Michael Dillon > From william at elan.net Tue Jan 17 15:59:58 2006 From: william at elan.net (william(at)elan.net) Date: Tue, 17 Jan 2006 12:59:58 -0800 (PST) Subject: [ppml] PPML Digest, Vol 7, Issue 5 In-Reply-To: <43CD57AD.5060303@quadrix.com> References: <43CD57AD.5060303@quadrix.com> Message-ID: I agree with what Bill Van Emburg wrote below, it is quite clear now that current policy is such that private residence can only be entered as replacement for street name, house number and other unit-related numbers. If people concerned about privacy want to change things, I'd recommend submitting proposal to make entering zip-code optional (no matter if it goes with private-residence or not) - the justification is that postal code is not in fact required for delivery of mail although this does improve time & eficiency of postal delivery. I'd however be against any changes in privacy policies that replace city, state and country with some kind of "private residence" or alike words. On Tue, 17 Jan 2006, Bill Van Emburg wrote: > Michael, > > It seems quite clear to me that the statement of interpretation is NOT > meant to suggest that "Private Residence" should be placed in the zip > code field. First of all, as has already been mentioned, you need the > ZIP+4 to narrow it down to a small area. Second, that would still not > make it "street name and number." > > ARIN meant "street name and number," not "any field that might narrow > things down to street name and number in some cases." Therefore, the > policy would be to put "Private Residence" into the field for "street > name and number," and not "other fields that the subject thinks might > narrow things down too much." > > I think ARIN has been quite clear here. > > -Bill Van Emburg > Quadrix Solutions, Inc. > >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 17 Jan 2006 14:40:44 +0000 >> From: Michael.Dillon at btradianz.com >> Subject: Re: [ppml] ARIN's Interpretation of 2003-3 >> >>> ARIN interprets street address to mean that element of a postal address >>> that identifies street name and number. >> >> >> It is quite clear then that ISPs should replace >> the zip code or postal code with the text >> "Private Residence" since the U.S. zip code >> and the Canadian postal code both identify the >> street name and number. >> >> Therefore, ISPs should repeat the text >> "Private Residence" twice in their whois >> data. >> >> Unfortunately, ARIN's policy makers are unaware >> of how the postal system works and why zip codes >> and postal codes were introduced into the addressing >> system in North America. Otherwise they would have >> simply stated clearly that zip codes and postal codes >> could be left blank when obscuring the street address. >> >> It is a pity that they did not consult an expert >> in the workings of the postal system, or an expert >> in finding people. Either one would have informed >> ARIN that the zip code or postal code identifies >> the street address to within half a dozen houses. >> >> --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From Michael.Dillon at btradianz.com Wed Jan 18 05:59:52 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 18 Jan 2006 10:59:52 +0000 Subject: [ppml] ARIN's Interpretation of 2003-3 In-Reply-To: Message-ID: > In urban areas, the last three digits may indicate a specific city > block (one side of a street between two intersecting streets), a > single building or, in some cases, a large-volume mail receiver. > So, your assertion that it identifies the street number appear to be > false as well. One side of a street between two intersecting streets, is a very small number in the vast suburban belts which most Canadians live in. Earlier, when this was discussed, I looked up a postal code in the directory on the Canada Post website and found that it identified a group of 6 houses. Let's be clear on what these privacy initiatives are intended to combat. They are intended to make it impossible for a person to use the whois data in order to identify a private individual's home and make a personal visit to that home. If the ARIN whois records narrow down the individuals location to a single building or a group of 6 houses, then they have failed in preventing such unwanted visitors. It is trivial to knock on 6 doors and ask "Is Fred home?". It is not much harder to roam the halls of an apartment building to do the same. At the same time, not one single comment has been made explicitly supporting the need for postal codes and zip codes to be listed. Nobody has stated a reason why they need to see these codes for private individuals. Policies are never set in stone, and this is a bad policy that needs to be fixed. In addition, when ARIN is dealing with issues outside of the expertise of its members, it really needs to consult experts and make those expert opinions know to the PPML and the members. In this case experts on Canadian and U.S. privacy law, and experts on the workings of the postal systems in both countries. The fact that a particular policy proposal was accepted by the small group of people who happened to be present at one of ARIN's member meetings, really does not mean much in the grand scheme of things. Obviously, the Board of Trustees has to work with what they have got and if all they have is a mediocre policy, they have to cope as best they can. That doesn't change the fact that the policymakers did a mediocre job. --Michael Dillon --Michael Dillon From Michael.Dillon at btradianz.com Wed Jan 18 06:38:31 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 18 Jan 2006 11:38:31 +0000 Subject: [ppml] PPML Digest, Vol 7, Issue 5 In-Reply-To: <43CD57AD.5060303@quadrix.com> Message-ID: > It seems quite clear to me that the statement of interpretation is NOT > meant to suggest that "Private Residence" should be placed in the zip > code field. First of all, as has already been mentioned, you need the > ZIP+4 to narrow it down to a small area. Second, that would still not > make it "street name and number." I am puzzled by the way that you, and others, make a distinction between ZIP+4 codes and ZIP codes. I always thought that U.S. ZIP codes had been changed, many years ago, to a 9-digit number written as nnnnn-nnnn. I assume that the PostalCode field in the whois, is capable of handling arbitrary text such as the full zip code or the words "Private Residence". > ARIN meant "street name and number," not "any field that might narrow > things down to street name and number in some cases." The actual text of the ARIN statement was: The Board, by sequential adoption of these two proposals, has interpreted street address to mean that element of a postal address that conveys the street number and name. Since it is clear that the Canadian postal code does convey the street number and name, it should also be replaced by "Private Residence". I assume that the full U.S. zip code similarly conveys the street number and name because the USPS states here: http://www.usps.com/history/history/his3_5.htm The sixth and seventh numbers denote a delivery sector, which may be several blocks, a group of streets, a group of post office boxes, several office buildings, a single high-rise office building, a large apartment building, or a small geographic area. The last two numbers denote a delivery segment, which might be one floor of an office building, one side of a street between intersecting streets, specific departments in a firm, or a group of post office boxes. > I think ARIN has been quite clear here. I think that ARIN has been very unclear and very ambiguous. When you look at the Canada Post document quoted by Owen DeLong and the USPS document quoted by me, you can see that the PostalCode field does pinpoint a persons physical residence to a very small geographic area and therefore publishing this code defeats the privacy intent of the policy. --Michael Dillon From Michael.Dillon at btradianz.com Wed Jan 18 06:44:34 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 18 Jan 2006 11:44:34 +0000 Subject: [ppml] PPML Digest, Vol 7, Issue 5 In-Reply-To: Message-ID: > - the justification is that postal > code is not in fact required for delivery of mail although this does > improve time & eficiency of postal delivery. Street name and number is also not required for delivery of mail. When Canada introduced the postal code, many journalists attempted to send letters addressed like this: Fred Bloggs N2L 4H2 And they were all delivered promptly with no discernable delay. Judging by the USPS description of their ZIP+4(tm) codes, you should get similar results with: Sarah Bloggs 95121-1520 > I'd however be against any changes in privacy policies that replace city, > state and country with some kind of "private residence" or alike words. I agree. There is value in knowing the geographic distribution of address usage, especially if we want to adopt a geo-topological addressing scheme for IPv6 at some future date. --Michael Dillon From tme at multicasttech.com Wed Jan 18 07:09:13 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 18 Jan 2006 07:09:13 -0500 Subject: [ppml] PPML Digest, Vol 7, Issue 5 In-Reply-To: References: Message-ID: Use of the 9 digit code is optional (as, for that matter, is the 5 digit code); to a very rough approximation, the 5 digit code is viewed as being for humans, the 9 digit one, for machines. I could not tell you, for example, the 9 digit code for my house without looking it up, and I do not generally use in in correspondence, nor do I put it in forms, not even government ones. BTW, are you aware that Zip codes are subject to change ? When my central mail facility changed from Merrifield to Dulles, my zip prefix changed from 222 to 201. Such changes are relatively common in the US, especially in growing areas. Regards Marshall On Jan 18, 2006, at 6:38 AM, Michael.Dillon at btradianz.com wrote: >> It seems quite clear to me that the statement of interpretation is >> NOT >> meant to suggest that "Private Residence" should be placed in the zip >> code field. First of all, as has already been mentioned, you need >> the >> ZIP+4 to narrow it down to a small area. Second, that would still >> not >> make it "street name and number." > > I am puzzled by the way that you, and others, > make a distinction between ZIP+4 codes and > ZIP codes. I always thought that U.S. ZIP codes > had been changed, many years ago, to a 9-digit > number written as nnnnn-nnnn. I assume that the > PostalCode field in the whois, is capable of handling > arbitrary text such as the full zip code or the words > "Private Residence". > >> ARIN meant "street name and number," not "any field that might narrow >> things down to street name and number in some cases." > > The actual text of the ARIN statement was: > The Board, by sequential adoption of these two proposals, has > interpreted street address to mean that element of a postal address > that conveys the street number and name. > > Since it is clear that the Canadian postal code does convey > the street number and name, it should also be replaced by > "Private Residence". I assume that the full U.S. zip code > similarly conveys the street number and name because the > USPS states here: > http://www.usps.com/history/history/his3_5.htm > The sixth and seventh numbers denote a delivery sector, > which may be several blocks, a group of streets, a group > of post office boxes, several office buildings, a single > high-rise office building, a large apartment building, or > a small geographic area. The last two numbers denote a > delivery segment, which might be one floor of an office > building, one side of a street between intersecting streets, > specific departments in a firm, or a group of post office boxes. > >> I think ARIN has been quite clear here. > > I think that ARIN has been very unclear and very ambiguous. > > When you look at the Canada Post document quoted by Owen > DeLong and the USPS document quoted by me, you can see that > the PostalCode field does pinpoint a persons physical > residence to a very small geographic area and therefore > publishing this code defeats the privacy intent of the > policy. > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Wed Jan 18 07:09:32 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Jan 2006 04:09:32 -0800 Subject: [ppml] ARIN's Interpretation of 2003-3 In-Reply-To: References: Message-ID: Michael, I opposed 2003-3 to begin with, so, I'm probably never going to agree with you on this. My point in posting the data about what a postal code represented was to clarify exactly what they mean rather than leave your erroneous assertion standing. As long as City, State/Province, Country are present in the record, I really don't care whether ZIP is there or not, but, I think it is pretty clear 2003-3 as it was adopted does not provide for the elimination of the ZIP/Postal code. Apparently, ARIN agrees with me in this interpretation. If you want to change the policy, feel free to submit a proposal. What I find most disturbing in your comments is the way you characterize the policy process as proposals being accepted by "the small group of people who happened to be present at one of ARIN's member meetings". First, I think you know better than this, as you have been an active participant in the ARIN policy process for several years. ARIN policies are not even generally discussed at ARIN member meetings. They are discussed at ARIN Public Policy meetings which are open to ARIN members and non-members alike. They are not accepted or rejected at the Public Policy meetings, either. The Public Policy meetings combined with the content of the public policy mailing list on the subject are used by the ARIN Advisory Council (an elected representative body) to gage consensus on the policy. If the AC determines there is consensus for the policy, then it is published for last call to the PPML for another round of comments. Barring any extraordinary objections, the AC will then recommend the policy be adopted by the ARIN board. The ARIN board reviews the policy, and, unless there is some extraordinary problem (legal liability issue, etc.) with the policy in the board's perspective, the policy is adopted. Owen From Michael.Dillon at btradianz.com Wed Jan 18 07:43:09 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 18 Jan 2006 12:43:09 +0000 Subject: [ppml] Policy process In-Reply-To: Message-ID: > What I find most disturbing in your comments is the way you > characterize > the policy process as proposals being accepted by "the small group of > people > who happened to be present at one of ARIN's member meetings". > > First, I think you know better than this, as you have been an active > participant > in the ARIN policy process for several years. Whether I, a single person, happen to be present or not, does not change the fact that the policies are made by a relatively small group of people. > ARIN policies are not even generally discussed at ARIN member meetings. > They are discussed at ARIN Public Policy meetings which are open to > ARIN > members and non-members alike. You are splitting hairs. There are meetings twice a year. Part of the time, these meetings are open to all, and part of the time they are not. Nevertheless, the meetings are attended by a small number of people. > They are not accepted or rejected at the Public Policy meetings, > either. The > Public Policy meetings combined with the content of the public policy > mailing list > on the subject are used by the ARIN Advisory Council (an elected > representative > body) to gage consensus on the policy. If the AC determines there is > consensus > for the policy, then it is published for last call to the PPML for > another round of > comments. Barring any extraordinary objections, the AC will then > recommend > the policy be adopted by the ARIN board. The ARIN board reviews the > policy, > and, unless there is some extraordinary problem (legal liability > issue, etc.) > with the policy in the board's perspective, the policy is adopted. As you have pointed out in detail, the ARIN AC does not do much more than gauge the consensus of the small group of people who discuss the policy proposals on the list and at the meetings. It is my impression that more discussion takes place at meetings than on the list and since there is a straw poll taken at meetings, they appear to have more weight than the list. --Michael Dillon From Michael.Dillon at btradianz.com Wed Jan 18 07:49:58 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 18 Jan 2006 12:49:58 +0000 Subject: [ppml] What is this world coming to? In-Reply-To: <4BBD4AC6-5866-4399-8950-ABD2F1685C9C@delong.com> Message-ID: > I think that ignoring the content of the policy for the > sake of interpreting > its intent is not a precedent I would like to see set here. Whether > you like the result > or not, the granularity of a Postal or ZIP code is not sufficient to > meet the tests > for exclusion described by the board on adoption of the policy. That statement is sufficient to meet my tests for mindless bureaucracy. > As > such, the simple > and correct way to get what you want is to propose a policy which > amends this > section of the NRPM to say what you actually want it to say. So now there is a correct way to discuss policy problems? Please tell me more. I was labouring under the delusion that the PPML was an open list for discussion of ARIN policies. In other words, a list for anyone to use, regardless of whether or not they meet your tests for correctness. --Michael Dillon From Michael.Dillon at btradianz.com Wed Jan 18 07:57:25 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 18 Jan 2006 12:57:25 +0000 Subject: [ppml] PPML Digest, Vol 7, Issue 5 In-Reply-To: <51152386-901B-449E-A224-90889B5C679F@delong.com> Message-ID: > >> - the justification is that postal > >> code is not in fact required for delivery of mail although this does > >> improve time & eficiency of postal delivery. > > > > Street name and number is also not required for delivery of > > mail. When Canada introduced the postal code, many journalists > > attempted to send letters addressed like this: > > > > Fred Bloggs > > N2L 4H2 > > > > > And they were all delivered promptly with no discernable delay. > What is your point? It's rather simple and I have no idea why it gets you upset. The point is that in Canada, the postal code functions in exactly the same way as a US address with no postal code. Both are SUFFICIENT to get a letter delivered. > There's also value in having enough of the address to make it > possible to > track the party down for legal process service, if necessary. No address at all is necessary. The ARIN whois directory identifies the ISP and legal process delivery people can get the address they need from them. --Michael Dillon From Lee.Howard at stanleyassociates.com Wed Jan 18 08:32:18 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 18 Jan 2006 08:32:18 -0500 Subject: [ppml] Policy process Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB401149771@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: Wednesday, January 18, 2006 7:43 AM > To: ppml at arin.net > Subject: [ppml] Policy process > > > What I find most disturbing in your comments is the way you > > characterize the policy process as proposals being accepted by "the > > small group of people > > who happened to be present at one of ARIN's member meetings". > > > > First, I think you know better than this, as you have > > been an active participant > > in the ARIN policy process for several years. > > Whether I, a single person, happen to be present or not, > does not change the fact that the policies are made by a > relatively small group of people. "Relatively" small, to a value of "everyone who cares about it." I would like more participation, but I don't really know how to solicit it. > > ARIN policies are not even generally discussed at ARIN member > meetings. > > They are discussed at ARIN Public Policy meetings which > are open to > > ARIN > > members and non-members alike. > > You are splitting hairs. There are meetings twice a year. > Part of the time, these meetings are open to all, and part > of the time they are not. Policy meetings are open to all. Member meetings are for members; policy is not discussed. Recently (the last two meetings) attendees of public policy meetings have been invited to stay and observe the members' meetings. Checking the agenda, they're not exactly exciting meetings. > Nevertheless, the meetings are > attended by a small number of people. Couple hundred. Who represent a fairly broad, though not necessarily proportionate, variety of interests. > > Barring any extraordinary objections, the AC will then > > recommend > > the policy be adopted by the ARIN board. The ARIN board > > reviews the policy, > > and, unless there is some extraordinary problem (legal liability > > issue, etc.) > > with the policy in the board's perspective, the policy is adopted. > > As you have pointed out in detail, the ARIN AC does not do much more > than gauge the consensus of the small group of people who discuss > the policy proposals on the list and at the meetings. It is my > impression that more discussion takes place at meetings than on > the list and since there is a straw poll taken at meetings, they > appear to have more weight than the list. I agree with you that there tends to be more discussion at meetings than on the list, and that it tends to be more focussed, though that doesn't necessarily mean it's more thoughtful. I don't know how (or whether) to change that. Another fairly recent change is that when a proposal is presented for discussion at a meeting, staff summarizes the discussion that took place here. I can't say whether the AC formally counts mailing list posts and participation at meetings (and subtracts out people who did both), but in talking to them, I have the impression that they do carefully keep in mind the mailing list threads when voting on policy proposals. Lee > --Michael Dillon > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From memsvcs at arin.net Wed Jan 18 09:48:40 2006 From: memsvcs at arin.net (Member Services) Date: Wed, 18 Jan 2006 09:48:40 -0500 Subject: [ppml] Proposed Policy: Residential Customer Privacy Message-ID: <43CE5548.4020803@arin.net> ARIN received the following proposed policy. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List and being placed on ARIN's website. The ARIN Advisory Council (AC) will review the proposal and within ten working days may decide to: 1) Support the proposal as is, 2) Work with the author to clarify, divide or combine one or more policy proposals, or 3) Not support the policy proposal. If the AC supports the proposal or reaches an agreement to work with the author, then the proposal will be posted as a formal policy proposal to the Public Policy Mailing List and it will be presented at the Public Policy Meeting. If the AC does not support the proposal, then the author may elect to use the petition process to advance the proposal. If the author elects not to petition or the petition fails, then the proposed policy will be considered closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal Name: Residential Customer Privacy Author: Samuel Weiler Proposal type: modify Policy term: permanent Policy statement: An organization with downstream residential customers may substitute that organization's name for the customer's name, e.g. 'Private customer - XYZ Network', and the customer's entire address may be replaced with 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. NRPM Section 3.2 on Distributed Information Server Use Requirements (from policy proposal 2003-5) is also updated by striking the words "that includes displaying only the city, state, zip code, and country". Rationale: This policy allows for a residential customer's entire physical address to be suppressed, not just the street name and number. It also removes the US-centric phrases "state" and "zip code" from the NRPM, reflecting ARIN's broader service area. In many cases, a postal code or even a city name can identify few enough individuals, particularly considering the set of those likely to have their own IP assignments, that the intent of policy proposal 2003-3 is constructively defeated. Timetable for implementation: Immediately upon approval. From william at elan.net Wed Jan 18 09:54:48 2006 From: william at elan.net (william(at)elan.net) Date: Wed, 18 Jan 2006 06:54:48 -0800 (PST) Subject: [ppml] Clarification requested from ARIN staff in regards to postal-code field Message-ID: Can I get clarification from ARIN staff as to if current policies require providing data in PostalCode field for organization info when submitting SWIPS and other reassignment information (or for that matter when new organization is requesting new allocation/assignment directly from ARIN). -- William Leibzon Elan Networks william at elan.net From jlewis at lewis.org Wed Jan 18 09:55:55 2006 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 18 Jan 2006 09:55:55 -0500 (EST) Subject: [ppml] ARIN's Interpretation of 2003-3 In-Reply-To: References: Message-ID: 4.2.3.7.6. Residential Customer Privacy To maintain the privacy of their residential customers, an organization with downstream residential customers may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ ^^^^^^^^^^^^^^^ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. To me, this implies that each anonymized residential customer swip should actually cover a single customer. I have good reason to believe that at least one ARIN member is swipping IP blocks as "Private Customer" and then subnetting those IP blocks, assigning the IPs to multiple customers. That would seem to be a violation of 4.2.3.7.6. If it is, does anyone care? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From william at elan.net Wed Jan 18 10:02:47 2006 From: william at elan.net (william(at)elan.net) Date: Wed, 18 Jan 2006 07:02:47 -0800 (PST) Subject: [ppml] ARIN's Interpretation of 2003-3 In-Reply-To: References: Message-ID: On Wed, 18 Jan 2006, Jon Lewis wrote: > 4.2.3.7.6. Residential Customer Privacy > > To maintain the privacy of their residential customers, an > organization with downstream residential customers may substitute that > organization's name for the customer's name, e.g. 'Private Customer - XYZ > ^^^^^^^^^^^^^^^ > Network', and the customer's street address may read 'Private Residence'. > Each private downstream residential reassignment must have accurate > upstream Abuse and Technical POCs visible on the WHOIS record for that > block. > > To me, this implies that each anonymized residential customer swip > should actually cover a single customer. I have good reason to believe > that at least one ARIN member is swipping IP blocks as "Private Customer" > and then subnetting those IP blocks, assigning the IPs to multiple > customers. Yes, that would be SBC. I've reported this in commenary on public meeting (send as remote participant for open-mic if I remember). If I understand the response was that such practice would be discontinued, although I've not seen any changes to existing swips and have seen some new ones still being added (but I've not looked at this matter in the last few months). > That would seem to be a violation of 4.2.3.7.6. If it is, > does anyone care? From arin-member at quadrix.com Wed Jan 18 10:25:14 2006 From: arin-member at quadrix.com (Bill Van Emburg) Date: Wed, 18 Jan 2006 09:25:14 -0600 Subject: [ppml] PPML Digest, Vol 7, Issue 6 In-Reply-To: References: Message-ID: <43CE5DDA.2060205@quadrix.com> > From: Michael.Dillon at btradianz.com > ... > number written as nnnnn-nnnn. I assume that the > PostalCode field in the whois, is capable of handling > arbitrary text such as the full zip code or the words > "Private Residence". > That would be a bad assumption. Most zip code fields in systems of which I am aware do error checking to ensure that the entry matches a known zip code format. Therefore, they would not accept arbitrary text. I do not, however, know for certain how the various whois servers and clients might do things. > > The actual text of the ARIN statement was: > The Board, by sequential adoption of these two proposals, has > interpreted street address to mean that element of a postal address > that conveys the street number and name. > > Since it is clear that the Canadian postal code does convey > the street number and name, it should also be replaced by > "Private Residence". I assume that the full U.S. zip code > similarly conveys the street number and name because the > USPS states here: > http://www.usps.com/history/history/his3_5.htm > The sixth and seventh numbers denote a delivery sector, > which may be several blocks, a group of streets, a group > of post office boxes, several office buildings, a single > high-rise office building, a large apartment building, or > a small geographic area. The last two numbers denote a > delivery segment, which might be one floor of an office > building, one side of a street between intersecting streets, > specific departments in a firm, or a group of post office boxes. > The definition you have included here explicitly states that you're talking about multiple addresses, at least in the residential case. You are correct in stating that a full zip+4 narrows things down to a small number of residences (as does a full Canadian postal code). For that reason, it would be reasonable to modify the policy to allow only part of a Canadian postal code to be specified, or to explicitly state that a full zip+4 is not required (although that really doesn't seem necessary, in the U.S. case, as the +4 has always been optional). My point here is simply that ARIN has been quite clear in its current interpretation of policy, and I think that their interpretation is reasonable. There was a great deal of debate over how much of the whois record should be able to be obfuscated when this policy was written, so it is appropriate to interpret the policy narrowly. That does not, however, in any way prevent the introduction of a broader policy, one which does a more thorough job of hiding a person's location. You should not be so quick to judge the people involved in creating the current policy. It was NOT adopted merely by a "handful of people at an ARIN meeting." It was adopted in the same fashion as all other ARIN policies -- after intense debate on the mailing list, and further discussion at a meeting, and even more discussion afterwards on the mailing list. At least some of the people involved certainly understood the degree to which postal codes narrow down the location. (I certainly did. That's part of why I use a private mailbox for all of my mail.) Just because the policy doesn't read as you wish it would doesn't mean that those involved were ignorant. There is good reason to have a zip code in the whois record -- geographical systems all base their concepts of location on postal codes. This is very useful for analyzing geographical distribution of ARIN resources, as others have mentioned. Others may well have more reasons to offer. This does not have to be at odds with a desire for privacy for individuals. (In fact, I'm a big privacy advocate.) However, it is unreasonable to suggest that ARIN has been unclear in their interpretation of policy. I think what you are trying to get at is that the policy does not adequately address privacy concerns of individuals, at least in Canada. I would agree with that statement, and I would support a change in policy to address the issue for Canada. (It wouldn't be a bad idea to explicitly state that only the 5 digit zip code is required, as well.) Please feel free to write such a policy. It would be worth pursuing. -Bill Van Emburg Quadrix Solutions, Inc. From weiler at tislabs.com Wed Jan 18 10:58:39 2006 From: weiler at tislabs.com (Samuel Weiler) Date: Wed, 18 Jan 2006 10:58:39 -0500 (EST) Subject: [ppml] PPML Digest, Vol 7, Issue 6 Message-ID: Bill Van Emburg writes: > There was a great deal of debate over how much of the whois record > should be able to be obfuscated when this policy was written, so it > is appropriate to interpret the policy narrowly. Would you kindly point us at this discussion? I didn't see much in the 2003 discussion, and I was wondering exactly what the policy was before that and what discussion led to it. -- Sam From owen at delong.com Wed Jan 18 15:44:54 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Jan 2006 12:44:54 -0800 Subject: [ppml] Proposed Policy: Residential Customer Privacy Message-ID: <1CD960C5-FF28-487B-874C-F0396E7CAFC7@delong.com> I absolutely oppose this policy as written. Excluding the entire address removes the possibility of using the small claims court process as a means of remedy for network abuse, at least in several states within the united States. I think that would be an undesirable policy effect. Removing the City, State, and Postal code information would also reduce the availability of useful data for geographic address distribution research which has been identified as valuable by several participants on the list and at previous policy meetings. I would be more willing to accept a policy which allowed limitation of ZIP codes to 5 digit ZIP codes or limitation of Canadian Postal Codes to the first 3 characters. These modifications should be sufficient to address the privacy concerns raised in recent discussions on the list. Owen From randy at psg.com Wed Jan 18 20:11:28 2006 From: randy at psg.com (Randy Bush) Date: Thu, 19 Jan 2006 10:11:28 +0900 Subject: [ppml] ARIN's Interpretation of 2003-3 References: Message-ID: <17358.59200.58436.876828@roam.psg.com> > I assumed that the policy was talking about the entire address, in > part based on the fact that "street name and number" wasn't generally > called out in the discussion. as words such as "zip code" have a restricted cultural context, this whole discussion seems odd. randy From randy at psg.com Wed Jan 18 21:27:25 2006 From: randy at psg.com (Randy Bush) Date: Thu, 19 Jan 2006 11:27:25 +0900 Subject: [ppml] ARIN's Interpretation of 2003-3 References: <17358.59200.58436.876828@roam.psg.com> Message-ID: <17358.63757.637557.896574@roam.psg.com> >> I assumed that the policy was talking about the entire address, in >> part based on the fact that "street name and number" wasn't generally >> called out in the discussion. > as words such as "zip code" have a restricted cultural context, this > whole discussion seems odd. private comment indicates i may have been too terse. how unusual. when 2003-3 made the address info private, it should not have been necessary to attempt to specify each ort of each culture's way of specifying address. the idea was to make the location of the user private, end, period, stop pedantic silly word lawyer games, find useful work to do, ... randy From billd at cait.wustl.edu Thu Jan 19 09:11:39 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 19 Jan 2006 08:11:39 -0600 Subject: [ppml] Policy process Message-ID: > > As you have pointed out in detail, the ARIN AC does not do > much more than gauge the consensus of the small group of > people who discuss the policy proposals on the list and at > the meetings. It is my > impression that more discussion takes place at meetings than > on the list and since there is a straw poll taken at > meetings, they appear to have more weight than the list. > > --Michael Dillon > > Appearances are often deceiving. The straw poll is tangible evidence used to gauge the support for policy proposals at the policy meeting. These data and that of the ppml both before, during and after, the public policy meeting are given equal weight and in addition the experience of the AC membership is also applied to the overall deliberations typically for interpretation. It is unfortunate that there is not greater involvement in the ARIN policy process, but it is not because input is shunned or uninvited or unappreciated. I can only assume that the inactivity is associated with constituent disinterest in the policies under discussion or that they feel that the process through past experience delivers results that are consistent with their interests. Evidence does not exist to defeat that premise in my view. If you or others have evidence to the contrary, then we hare happy to here it. Bill Darte ARIN AC From billd at cait.wustl.edu Thu Jan 19 09:26:52 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 19 Jan 2006 08:26:52 -0600 Subject: [ppml] What is this world coming to? Message-ID: > > As > > such, the simple > > and correct way to get what you want is to propose a policy which > > amends this > > section of the NRPM to say what you actually want it to say. > > So now there is a correct way to discuss policy problems? > Please tell me more. I was labouring under the delusion that > the PPML was an open list for discussion of ARIN policies. In > other words, a list for anyone to use, regardless of whether > or not they meet your tests for correctness. > > --Michael Dillon > > The ppml is a legitimate way to discuss policy and advocate for new policy or policy change. That advocacy either way may be insufficient to encourage someone else to propose the changes you support. The 'most direct' way of influencing policy is to propose it in the formal way. If a 'small number' of persons advocate change of current policy on the ppml without concomitant formal policy proposals, then those voices are necessarily diminished with no possibility of those changes being adopted. It takes a formal proposal. On the other hand, if ppml proposal discussion were sufficiently vocal and sufficiently focus, then it is possible that the AC itself would author a proposal reflecting those voices even in the absence of a sponsor. Often an AC member presents a formal proposal at a meeting when the author is unwilling or unable to attend and present for themselves. There is no conspiracy to deny anyone a voice or to avoid new or changed policy. The objective is in fact to hear legitimate and broadbased support for such and present those perspectives fairly and to adjudge consensus of participants in the open and transparent policy proposal process. Bill Darte ARIN AC From marla_azinger at eli.net Thu Jan 19 11:56:51 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Thu, 19 Jan 2006 08:56:51 -0800 Subject: [ppml] 2003-3 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20295A2F2@wava00s2ke2k01.corp.pvt> Below is a short discussion on 2003-3 that was not posted to ppml by accident on my part. I now post this for involvment by anyone else interested: Regards Marla Azinger **************************************** No. Now you've allowed them to eliminate everything except the ZIP code. First, let me say that I do not think that there is any flaw in the current policy or ARIN's interpretation thereof, except that I would rather preserve the Name as a visible object. However, if we are going to further reduce the usefulness of whois, I would rather constrain that reduction to the smallest amount possible. An acceptable rewording might be: Section of the NRPM is modified to allow residential customer postal codes in Canada to be abbreviated to the first three characters of the Postal Code. Further, it is clarified that in the US, the 5 digit ZIP code is acceptable for all entries. That is a policy I would not oppose. Owen On Jan 18, 2006, at 2:28 PM, Azinger, Marla wrote: > So would a reasonable rewording of this proposal be the following: > > An organization with downstream residential customers may > substitute that organization's name for the customer's name, > e.g. 'Private customer - XYZ Network', and the customer's > address may be replaced with 'Private Residence', excluding > the zip code. > Non specific Zip codes must be included and specific building/ > structure location zip codes are not to be sumbitted. > Specification of specific versus non specific zip code is country > dependant. Each private downstream residential reassignment must > have accurate upstream Abuse and Technical POCs visible on the > WHOIS record for that > block. > > > Marla Azinger > ELI and Frontier > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Owen DeLong > Sent: Wednesday, January 18, 2006 12:45 PM > To: Member Services > Subject: Re: [ppml] Proposed Policy: Residential Customer Privacy > > > I absolutely oppose this policy as written. Excluding the entire > address > removes the possibility of using the small claims court process as a > means of remedy for network abuse, at least in several states within > the united States. I think that would be an undesirable policy > effect. > > Removing the City, State, and Postal code information would also > reduce > the availability of useful data for geographic address distribution > research which has been identified as valuable by several participants > on the list and at previous policy meetings. > > I would be more willing to accept a policy which allowed limitation > of ZIP codes to 5 digit ZIP codes or limitation of Canadian Postal > Codes to the first 3 characters. These modifications should be > sufficient to address the privacy concerns raised in recent > discussions > on the list. > > Owen > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From tme at multicasttech.com Thu Jan 19 12:06:32 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 19 Jan 2006 12:06:32 -0500 Subject: [ppml] 2003-3 In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D20295A2F2@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D20295A2F2@wava00s2ke2k01.corp.pvt> Message-ID: <0D389475-9F44-4DD0-B0C3-D651C6187159@multicasttech.com> So, what happens when the ZIP code changes ? Marshall On Jan 19, 2006, at 11:56 AM, Azinger, Marla wrote: > Below is a short discussion on 2003-3 that was not posted to ppml > by accident on my part. I now post this for involvment by anyone > else interested: > > Regards > Marla Azinger > > > **************************************** > > No. Now you've allowed them to eliminate everything except the ZIP > code. > > First, let me say that I do not think that there is any flaw in the > current > policy or ARIN's interpretation thereof, except that I would rather > preserve > the Name as a visible object. > > However, if we are going to further reduce the usefulness of whois, I > would > rather constrain that reduction to the smallest amount possible. > > An acceptable rewording might be: > > Section of the NRPM is modified to allow > residential > customer postal codes in Canada to be abbreviated to the first three > characters of the Postal Code. Further, it is clarified that in the > US, the 5 digit ZIP code is acceptable for all entries. > > That is a policy I would not oppose. > > Owen > > On Jan 18, 2006, at 2:28 PM, Azinger, Marla wrote: > >> So would a reasonable rewording of this proposal be the following: >> >> An organization with downstream residential customers may >> substitute that organization's name for the customer's name, >> e.g. 'Private customer - XYZ Network', and the customer's >> address may be replaced with 'Private Residence', excluding >> the zip code. >> Non specific Zip codes must be included and specific building/ >> structure location zip codes are not to be sumbitted. >> Specification of specific versus non specific zip code is country >> dependant. Each private downstream residential reassignment must >> have accurate upstream Abuse and Technical POCs visible on the >> WHOIS record for that >> block. >> >> >> Marla Azinger >> ELI and Frontier >> >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On >> Behalf Of >> Owen DeLong >> Sent: Wednesday, January 18, 2006 12:45 PM >> To: Member Services >> Subject: Re: [ppml] Proposed Policy: Residential Customer Privacy >> >> >> I absolutely oppose this policy as written. Excluding the entire >> address >> removes the possibility of using the small claims court process as a >> means of remedy for network abuse, at least in several states within >> the united States. I think that would be an undesirable policy >> effect. >> >> Removing the City, State, and Postal code information would also >> reduce >> the availability of useful data for geographic address distribution >> research which has been identified as valuable by several >> participants >> on the list and at previous policy meetings. >> >> I would be more willing to accept a policy which allowed limitation >> of ZIP codes to 5 digit ZIP codes or limitation of Canadian Postal >> Codes to the first 3 characters. These modifications should be >> sufficient to address the privacy concerns raised in recent >> discussions >> on the list. >> >> Owen >> >> _______________________________________________ >> 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 marla_azinger at eli.net Thu Jan 19 13:01:33 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Thu, 19 Jan 2006 10:01:33 -0800 Subject: [ppml] 2003-3 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100C9A@wava00s2ke2k01.corp.pvt> If you mean what happens "if the zip code structure changes", good point. This is why the rewording I suggested did not get specific down to the digits. The term "non specific zip code country dependent" leaves it open for restructuring of zip codes and simply states that that the most non specific form of a zip code is what must be registered. Regards Marla Azinger -----Original Message----- From: Marshall Eubanks [mailto:tme at multicasttech.com] Sent: Thursday, January 19, 2006 9:07 AM To: Azinger, Marla Cc: ppml at arin.net Subject: Re: [ppml] 2003-3 So, what happens when the ZIP code changes ? Marshall On Jan 19, 2006, at 11:56 AM, Azinger, Marla wrote: > Below is a short discussion on 2003-3 that was not posted to ppml > by accident on my part. I now post this for involvment by anyone > else interested: > > Regards > Marla Azinger > > > **************************************** > > No. Now you've allowed them to eliminate everything except the ZIP > code. > > First, let me say that I do not think that there is any flaw in the > current > policy or ARIN's interpretation thereof, except that I would rather > preserve > the Name as a visible object. > > However, if we are going to further reduce the usefulness of whois, I > would > rather constrain that reduction to the smallest amount possible. > > An acceptable rewording might be: > > Section of the NRPM is modified to allow > residential > customer postal codes in Canada to be abbreviated to the first three > characters of the Postal Code. Further, it is clarified that in the > US, the 5 digit ZIP code is acceptable for all entries. > > That is a policy I would not oppose. > > Owen > > On Jan 18, 2006, at 2:28 PM, Azinger, Marla wrote: > >> So would a reasonable rewording of this proposal be the following: >> >> An organization with downstream residential customers may >> substitute that organization's name for the customer's name, >> e.g. 'Private customer - XYZ Network', and the customer's >> address may be replaced with 'Private Residence', excluding >> the zip code. >> Non specific Zip codes must be included and specific building/ >> structure location zip codes are not to be sumbitted. >> Specification of specific versus non specific zip code is country >> dependant. Each private downstream residential reassignment must >> have accurate upstream Abuse and Technical POCs visible on the >> WHOIS record for that >> block. >> >> >> Marla Azinger >> ELI and Frontier >> >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On >> Behalf Of >> Owen DeLong >> Sent: Wednesday, January 18, 2006 12:45 PM >> To: Member Services >> Subject: Re: [ppml] Proposed Policy: Residential Customer Privacy >> >> >> I absolutely oppose this policy as written. Excluding the entire >> address >> removes the possibility of using the small claims court process as a >> means of remedy for network abuse, at least in several states within >> the united States. I think that would be an undesirable policy >> effect. >> >> Removing the City, State, and Postal code information would also >> reduce >> the availability of useful data for geographic address distribution >> research which has been identified as valuable by several >> participants >> on the list and at previous policy meetings. >> >> I would be more willing to accept a policy which allowed limitation >> of ZIP codes to 5 digit ZIP codes or limitation of Canadian Postal >> Codes to the first 3 characters. These modifications should be >> sufficient to address the privacy concerns raised in recent >> discussions >> on the list. >> >> Owen >> >> _______________________________________________ >> 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 tme at multicasttech.com Thu Jan 19 13:06:01 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 19 Jan 2006 13:06:01 -0500 Subject: [ppml] 2003-3 In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100C9A@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100C9A@wava00s2ke2k01.corp.pvt> Message-ID: <452DCFBF-44D6-48D8-A7EA-1BEFEFA9D4C8@multicasttech.com> Hello; On Jan 19, 2006, at 1:01 PM, Azinger, Marla wrote: > If you mean what happens "if the zip code structure changes", good > point. This is why the rewording I suggested did not get specific > down to the digits. The term "non specific zip code country > dependent" leaves it open for restructuring of zip codes and simply > states that that the most non specific form of a zip code is what > must be registered. What does this mean ? My zip code changed from 22024 to 20124 - is the nonspecific part of this "2" ? That's pretty non-specific. Marshall > > Regards > Marla Azinger > > > -----Original Message----- > From: Marshall Eubanks [mailto:tme at multicasttech.com] > Sent: Thursday, January 19, 2006 9:07 AM > To: Azinger, Marla > Cc: ppml at arin.net > Subject: Re: [ppml] 2003-3 > > > So, what happens when the ZIP code changes ? > > Marshall > > On Jan 19, 2006, at 11:56 AM, Azinger, Marla wrote: > >> Below is a short discussion on 2003-3 that was not posted to ppml >> by accident on my part. I now post this for involvment by anyone >> else interested: >> >> Regards >> Marla Azinger >> >> >> **************************************** >> >> No. Now you've allowed them to eliminate everything except the ZIP >> code. >> >> First, let me say that I do not think that there is any flaw in the >> current >> policy or ARIN's interpretation thereof, except that I would rather >> preserve >> the Name as a visible object. >> >> However, if we are going to further reduce the usefulness of whois, I >> would >> rather constrain that reduction to the smallest amount possible. >> >> An acceptable rewording might be: >> >> Section of the NRPM is modified to allow >> residential >> customer postal codes in Canada to be abbreviated to the first three >> characters of the Postal Code. Further, it is clarified that in the >> US, the 5 digit ZIP code is acceptable for all entries. >> >> That is a policy I would not oppose. >> >> Owen >> >> On Jan 18, 2006, at 2:28 PM, Azinger, Marla wrote: >> >>> So would a reasonable rewording of this proposal be the following: >>> >>> An organization with downstream residential customers may >>> substitute that organization's name for the customer's name, >>> e.g. 'Private customer - XYZ Network', and the customer's >>> address may be replaced with 'Private Residence', excluding >>> the zip code. >>> Non specific Zip codes must be included and specific building/ >>> structure location zip codes are not to be sumbitted. >>> Specification of specific versus non specific zip code is country >>> dependant. Each private downstream residential reassignment must >>> have accurate upstream Abuse and Technical POCs visible on the >>> WHOIS record for that >>> block. >>> >>> >>> Marla Azinger >>> ELI and Frontier >>> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On >>> Behalf Of >>> Owen DeLong >>> Sent: Wednesday, January 18, 2006 12:45 PM >>> To: Member Services >>> Subject: Re: [ppml] Proposed Policy: Residential Customer Privacy >>> >>> >>> I absolutely oppose this policy as written. Excluding the entire >>> address >>> removes the possibility of using the small claims court process as a >>> means of remedy for network abuse, at least in several states within >>> the united States. I think that would be an undesirable policy >>> effect. >>> >>> Removing the City, State, and Postal code information would also >>> reduce >>> the availability of useful data for geographic address distribution >>> research which has been identified as valuable by several >>> participants >>> on the list and at previous policy meetings. >>> >>> I would be more willing to accept a policy which allowed limitation >>> of ZIP codes to 5 digit ZIP codes or limitation of Canadian Postal >>> Codes to the first 3 characters. These modifications should be >>> sufficient to address the privacy concerns raised in recent >>> discussions >>> on the list. >>> >>> Owen >>> >>> _______________________________________________ >>> 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 marla_azinger at eli.net Thu Jan 19 13:16:33 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Thu, 19 Jan 2006 10:16:33 -0800 Subject: [ppml] 2003-3 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100C9C@wava00s2ke2k01.corp.pvt> LOL sorry. As an example, currently the U.S zip code structure is Specific with: 98226-4564 (the last four are the numbers that really narrow down where a person lives) 98226 ( this is not specific and only gets you in a mile radius) Granted if one of the locations in the ARIN region were to change or add another zip code structure then the breakdown of what is specific and not specific would change or just simply have another version added. I believe the point is for us to include a zip code that allows such things as geo research to occur but not for the pin point position of where your "relative" lives that is using ip address xxx.xxx.xxx.xxx (IPv4) Yes, this is alot of wordsmithing to find a balanced policy...but that is the nature of the work. -----Original Message----- From: Marshall Eubanks [mailto:tme at multicasttech.com] Sent: Thursday, January 19, 2006 10:06 AM To: Azinger, Marla Cc: ppml at arin.net Subject: Re: [ppml] 2003-3 Hello; On Jan 19, 2006, at 1:01 PM, Azinger, Marla wrote: > If you mean what happens "if the zip code structure changes", good > point. This is why the rewording I suggested did not get specific > down to the digits. The term "non specific zip code country > dependent" leaves it open for restructuring of zip codes and simply > states that that the most non specific form of a zip code is what > must be registered. What does this mean ? My zip code changed from 22024 to 20124 - is the nonspecific part of this "2" ? That's pretty non-specific. Marshall > > Regards > Marla Azinger > > > -----Original Message----- > From: Marshall Eubanks [mailto:tme at multicasttech.com] > Sent: Thursday, January 19, 2006 9:07 AM > To: Azinger, Marla > Cc: ppml at arin.net > Subject: Re: [ppml] 2003-3 > > > So, what happens when the ZIP code changes ? > > Marshall > > On Jan 19, 2006, at 11:56 AM, Azinger, Marla wrote: > >> Below is a short discussion on 2003-3 that was not posted to ppml >> by accident on my part. I now post this for involvment by anyone >> else interested: >> >> Regards >> Marla Azinger >> >> >> **************************************** >> >> No. Now you've allowed them to eliminate everything except the ZIP >> code. >> >> First, let me say that I do not think that there is any flaw in the >> current >> policy or ARIN's interpretation thereof, except that I would rather >> preserve >> the Name as a visible object. >> >> However, if we are going to further reduce the usefulness of whois, I >> would >> rather constrain that reduction to the smallest amount possible. >> >> An acceptable rewording might be: >> >> Section of the NRPM is modified to allow >> residential >> customer postal codes in Canada to be abbreviated to the first three >> characters of the Postal Code. Further, it is clarified that in the >> US, the 5 digit ZIP code is acceptable for all entries. >> >> That is a policy I would not oppose. >> >> Owen >> >> On Jan 18, 2006, at 2:28 PM, Azinger, Marla wrote: >> >>> So would a reasonable rewording of this proposal be the following: >>> >>> An organization with downstream residential customers may >>> substitute that organization's name for the customer's name, >>> e.g. 'Private customer - XYZ Network', and the customer's >>> address may be replaced with 'Private Residence', excluding >>> the zip code. >>> Non specific Zip codes must be included and specific building/ >>> structure location zip codes are not to be sumbitted. >>> Specification of specific versus non specific zip code is country >>> dependant. Each private downstream residential reassignment must >>> have accurate upstream Abuse and Technical POCs visible on the >>> WHOIS record for that >>> block. >>> >>> >>> Marla Azinger >>> ELI and Frontier >>> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On >>> Behalf Of >>> Owen DeLong >>> Sent: Wednesday, January 18, 2006 12:45 PM >>> To: Member Services >>> Subject: Re: [ppml] Proposed Policy: Residential Customer Privacy >>> >>> >>> I absolutely oppose this policy as written. Excluding the entire >>> address >>> removes the possibility of using the small claims court process as a >>> means of remedy for network abuse, at least in several states within >>> the united States. I think that would be an undesirable policy >>> effect. >>> >>> Removing the City, State, and Postal code information would also >>> reduce >>> the availability of useful data for geographic address distribution >>> research which has been identified as valuable by several >>> participants >>> on the list and at previous policy meetings. >>> >>> I would be more willing to accept a policy which allowed limitation >>> of ZIP codes to 5 digit ZIP codes or limitation of Canadian Postal >>> Codes to the first 3 characters. These modifications should be >>> sufficient to address the privacy concerns raised in recent >>> discussions >>> on the list. >>> >>> Owen >>> >>> _______________________________________________ >>> 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 weiler at tislabs.com Thu Jan 19 13:42:16 2006 From: weiler at tislabs.com (Samuel Weiler) Date: Thu, 19 Jan 2006 13:42:16 -0500 (EST) Subject: [ppml] Proposed Policy: Residential Customer Privacy Message-ID: Setting aside your implicit assertion that an individual's interest in protecting her privacy should be trumped by a researcher's desire for data, I'd like to explore the case you're making for still including some of this geographic data. Owen writes: > Removing the City, State, and Postal code information would also > reduce the availability of useful data for geographic address > distribution research which has been identified as valuable by > several participants on the list and at previous policy meetings. How significant is this effect? In particular, how much error in introduced by assuming that either 1) the location for the reassignment is the same as for the ISP's block or 2) that the distribution of suppressed reassigned blocks is the same as that of non-suppressed blocks? Could you get some of those who've previously identified the data as valuable to speak specifically about the effects of these assumptions? My suspicion is: a) either of the assumptions above would introduce negligible error, and b) most residential customers aren't using reassigned blocks anyway, so you're stuck with using the ISP's location for most addresses anyway, so errors introduced by the above assumptions are dwarfed by using non-customer-specific locations for the bulk of addresses. -- Sam From owen at delong.com Thu Jan 19 14:56:45 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Jan 2006 11:56:45 -0800 Subject: [ppml] 2003-3 In-Reply-To: <0D389475-9F44-4DD0-B0C3-D651C6187159@multicasttech.com> References: <10ECB7F03C568F48B9213EF9E7F790D20295A2F2@wava00s2ke2k01.corp.pvt> <0D389475-9F44-4DD0-B0C3-D651C6187159@multicasttech.com> Message-ID: Same thing that happens when the customer moves... The whois record should be updated to reflect the new data. Owen On Jan 19, 2006, at 9:06 AM, Marshall Eubanks wrote: > So, what happens when the ZIP code changes ? > > Marshall > > On Jan 19, 2006, at 11:56 AM, Azinger, Marla wrote: > >> Below is a short discussion on 2003-3 that was not posted to ppml >> by accident on my part. I now post this for involvment by anyone >> else interested: >> >> Regards >> Marla Azinger >> >> >> **************************************** >> >> No. Now you've allowed them to eliminate everything except the ZIP >> code. >> >> First, let me say that I do not think that there is any flaw in the >> current >> policy or ARIN's interpretation thereof, except that I would rather >> preserve >> the Name as a visible object. >> >> However, if we are going to further reduce the usefulness of whois, I >> would >> rather constrain that reduction to the smallest amount possible. >> >> An acceptable rewording might be: >> >> Section of the NRPM is modified to allow >> residential >> customer postal codes in Canada to be abbreviated to the first three >> characters of the Postal Code. Further, it is clarified that in the >> US, the 5 digit ZIP code is acceptable for all entries. >> >> That is a policy I would not oppose. >> >> Owen >> >> On Jan 18, 2006, at 2:28 PM, Azinger, Marla wrote: >> >>> So would a reasonable rewording of this proposal be the following: >>> >>> An organization with downstream residential customers may >>> substitute that organization's name for the customer's name, >>> e.g. 'Private customer - XYZ Network', and the customer's >>> address may be replaced with 'Private Residence', excluding >>> the zip code. >>> Non specific Zip codes must be included and specific building/ >>> structure location zip codes are not to be sumbitted. >>> Specification of specific versus non specific zip code is country >>> dependant. Each private downstream residential reassignment must >>> have accurate upstream Abuse and Technical POCs visible on the >>> WHOIS record for that >>> block. >>> >>> >>> Marla Azinger >>> ELI and Frontier >>> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On >>> Behalf Of >>> Owen DeLong >>> Sent: Wednesday, January 18, 2006 12:45 PM >>> To: Member Services >>> Subject: Re: [ppml] Proposed Policy: Residential Customer Privacy >>> >>> >>> I absolutely oppose this policy as written. Excluding the entire >>> address >>> removes the possibility of using the small claims court process as a >>> means of remedy for network abuse, at least in several states within >>> the united States. I think that would be an undesirable policy >>> effect. >>> >>> Removing the City, State, and Postal code information would also >>> reduce >>> the availability of useful data for geographic address distribution >>> research which has been identified as valuable by several >>> participants >>> on the list and at previous policy meetings. >>> >>> I would be more willing to accept a policy which allowed limitation >>> of ZIP codes to 5 digit ZIP codes or limitation of Canadian Postal >>> Codes to the first 3 characters. These modifications should be >>> sufficient to address the privacy concerns raised in recent >>> discussions >>> on the list. >>> >>> Owen >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Thu Jan 19 15:32:34 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Jan 2006 12:32:34 -0800 Subject: [ppml] 2003-3 In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100C9A@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100C9A@wava00s2ke2k01.corp.pvt> Message-ID: <88A436AF-C618-4D49-8382-6ECE743F1DF7@delong.com> If you want to do that, then, "Non specific Postal Code country dependent" is a more desirable wording. The term ZIP code applies to exactly one country. Owen On Jan 19, 2006, at 10:01 AM, Azinger, Marla wrote: > If you mean what happens "if the zip code structure changes", good > point. This is why the rewording I suggested did not get specific > down to the digits. The term "non specific zip code country > dependent" leaves it open for restructuring of zip codes and simply > states that that the most non specific form of a zip code is what > must be registered. > > Regards > Marla Azinger > > > -----Original Message----- > From: Marshall Eubanks [mailto:tme at multicasttech.com] > Sent: Thursday, January 19, 2006 9:07 AM > To: Azinger, Marla > Cc: ppml at arin.net > Subject: Re: [ppml] 2003-3 > > > So, what happens when the ZIP code changes ? > > Marshall > > On Jan 19, 2006, at 11:56 AM, Azinger, Marla wrote: > >> Below is a short discussion on 2003-3 that was not posted to ppml >> by accident on my part. I now post this for involvment by anyone >> else interested: >> >> Regards >> Marla Azinger >> >> >> **************************************** >> >> No. Now you've allowed them to eliminate everything except the ZIP >> code. >> >> First, let me say that I do not think that there is any flaw in the >> current >> policy or ARIN's interpretation thereof, except that I would rather >> preserve >> the Name as a visible object. >> >> However, if we are going to further reduce the usefulness of whois, I >> would >> rather constrain that reduction to the smallest amount possible. >> >> An acceptable rewording might be: >> >> Section of the NRPM is modified to allow >> residential >> customer postal codes in Canada to be abbreviated to the first three >> characters of the Postal Code. Further, it is clarified that in the >> US, the 5 digit ZIP code is acceptable for all entries. >> >> That is a policy I would not oppose. >> >> Owen >> >> On Jan 18, 2006, at 2:28 PM, Azinger, Marla wrote: >> >>> So would a reasonable rewording of this proposal be the following: >>> >>> An organization with downstream residential customers may >>> substitute that organization's name for the customer's name, >>> e.g. 'Private customer - XYZ Network', and the customer's >>> address may be replaced with 'Private Residence', excluding >>> the zip code. >>> Non specific Zip codes must be included and specific building/ >>> structure location zip codes are not to be sumbitted. >>> Specification of specific versus non specific zip code is country >>> dependant. Each private downstream residential reassignment must >>> have accurate upstream Abuse and Technical POCs visible on the >>> WHOIS record for that >>> block. >>> >>> >>> Marla Azinger >>> ELI and Frontier >>> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On >>> Behalf Of >>> Owen DeLong >>> Sent: Wednesday, January 18, 2006 12:45 PM >>> To: Member Services >>> Subject: Re: [ppml] Proposed Policy: Residential Customer Privacy >>> >>> >>> I absolutely oppose this policy as written. Excluding the entire >>> address >>> removes the possibility of using the small claims court process as a >>> means of remedy for network abuse, at least in several states within >>> the united States. I think that would be an undesirable policy >>> effect. >>> >>> Removing the City, State, and Postal code information would also >>> reduce >>> the availability of useful data for geographic address distribution >>> research which has been identified as valuable by several >>> participants >>> on the list and at previous policy meetings. >>> >>> I would be more willing to accept a policy which allowed limitation >>> of ZIP codes to 5 digit ZIP codes or limitation of Canadian Postal >>> Codes to the first 3 characters. These modifications should be >>> sufficient to address the privacy concerns raised in recent >>> discussions >>> on the list. >>> >>> Owen >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From tme at multicasttech.com Thu Jan 19 18:49:53 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 19 Jan 2006 18:49:53 -0500 Subject: [ppml] 2003-3 In-Reply-To: <88A436AF-C618-4D49-8382-6ECE743F1DF7@delong.com> References: <10ECB7F03C568F48B9213EF9E7F790D202100C9A@wava00s2ke2k01.corp.pvt> <88A436AF-C618-4D49-8382-6ECE743F1DF7@delong.com> Message-ID: <4C36E3AF-D5A6-4819-8A13-9ABB47FBECA1@multicasttech.com> And the Philippines On Jan 19, 2006, at 3:32 PM, Owen DeLong wrote: > If you want to do that, then, "Non specific Postal Code country > dependent" > is a more desirable wording. The term ZIP code applies to exactly > one country. > > Owen > > On Jan 19, 2006, at 10:01 AM, Azinger, Marla wrote: > >> If you mean what happens "if the zip code structure changes", good >> point. This is why the rewording I suggested did not get specific >> down to the digits. The term "non specific zip code country >> dependent" leaves it open for restructuring of zip codes and >> simply states that that the most non specific form of a zip code >> is what must be registered. >> >> Regards >> Marla Azinger >> >> >> -----Original Message----- >> From: Marshall Eubanks [mailto:tme at multicasttech.com] >> Sent: Thursday, January 19, 2006 9:07 AM >> To: Azinger, Marla >> Cc: ppml at arin.net >> Subject: Re: [ppml] 2003-3 >> >> >> So, what happens when the ZIP code changes ? >> >> Marshall >> >> On Jan 19, 2006, at 11:56 AM, Azinger, Marla wrote: >> >>> Below is a short discussion on 2003-3 that was not posted to ppml >>> by accident on my part. I now post this for involvment by anyone >>> else interested: >>> >>> Regards >>> Marla Azinger >>> >>> >>> **************************************** >>> >>> No. Now you've allowed them to eliminate everything except the ZIP >>> code. >>> >>> First, let me say that I do not think that there is any flaw in the >>> current >>> policy or ARIN's interpretation thereof, except that I would rather >>> preserve >>> the Name as a visible object. >>> >>> However, if we are going to further reduce the usefulness of >>> whois, I >>> would >>> rather constrain that reduction to the smallest amount possible. >>> >>> An acceptable rewording might be: >>> >>> Section of the NRPM is modified to allow >>> residential >>> customer postal codes in Canada to be abbreviated to the first three >>> characters of the Postal Code. Further, it is clarified that in the >>> US, the 5 digit ZIP code is acceptable for all entries. >>> >>> That is a policy I would not oppose. >>> >>> Owen >>> >>> On Jan 18, 2006, at 2:28 PM, Azinger, Marla wrote: >>> >>>> So would a reasonable rewording of this proposal be the following: >>>> >>>> An organization with downstream residential customers may >>>> substitute that organization's name for the customer's name, >>>> e.g. 'Private customer - XYZ Network', and the customer's >>>> address may be replaced with 'Private Residence', excluding >>>> the zip code. >>>> Non specific Zip codes must be included and specific building/ >>>> structure location zip codes are not to be sumbitted. >>>> Specification of specific versus non specific zip code is country >>>> dependant. Each private downstream residential reassignment must >>>> have accurate upstream Abuse and Technical POCs visible on the >>>> WHOIS record for that >>>> block. >>>> >>>> >>>> Marla Azinger >>>> ELI and Frontier >>>> >>>> -----Original Message----- >>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On >>>> Behalf Of >>>> Owen DeLong >>>> Sent: Wednesday, January 18, 2006 12:45 PM >>>> To: Member Services >>>> Subject: Re: [ppml] Proposed Policy: Residential Customer Privacy >>>> >>>> >>>> I absolutely oppose this policy as written. Excluding the entire >>>> address >>>> removes the possibility of using the small claims court process >>>> as a >>>> means of remedy for network abuse, at least in several states >>>> within >>>> the united States. I think that would be an undesirable policy >>>> effect. >>>> >>>> Removing the City, State, and Postal code information would also >>>> reduce >>>> the availability of useful data for geographic address distribution >>>> research which has been identified as valuable by several >>>> participants >>>> on the list and at previous policy meetings. >>>> >>>> I would be more willing to accept a policy which allowed limitation >>>> of ZIP codes to 5 digit ZIP codes or limitation of Canadian Postal >>>> Codes to the first 3 characters. These modifications should be >>>> sufficient to address the privacy concerns raised in recent >>>> discussions >>>> on the list. >>>> >>>> Owen >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml > From Michael.Dillon at btradianz.com Fri Jan 20 04:46:31 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 20 Jan 2006 09:46:31 +0000 Subject: [ppml] 2003-3 In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100C9C@wava00s2ke2k01.corp.pvt> Message-ID: > I believe the point is for us to include a zip code that allows such > things as geo research to occur but not for the pin point position > of where your "relative" lives that is using ip address xxx.xxx.xxx.xxx (IPv4) For this, it should be sufficient for whois entries to have the city, state/province and country. For example, here are two samples for an individual and a company: Joe Bloe Milwaukee, WI, USA Delta Cooperage Company Milwaukee, WI, USA That allows geo research and it keeps the home address of Joe Bloe private. Anybody who really needs the address of the Delta Cooperage Company can go to the ARIN member who allocated addresses to them. Of course this assumes that ARIN members are required to maintain up to date contact information in the whois directory. I realize that some people advocate a big brother style of oversight for ARIN, but I am opposed to this. It is not appropriate for non-governmental organizations such as ARIN to get into the big brother business. --Michael Dillon The purpose of Newspeak was not only to provide a medium of expression for the world-view and mental habits proper to the devotees of Ingsoc, but to make all other modes of thought impossible. -- George Orwell - 1984 From arin-member at quadrix.com Fri Jan 20 12:50:51 2006 From: arin-member at quadrix.com (Bill Van Emburg) Date: Fri, 20 Jan 2006 11:50:51 -0600 Subject: [ppml] PPML Digest, Vol 7, Issue 11 In-Reply-To: References: Message-ID: <43D122FB.1070609@quadrix.com> > Date: Fri, 20 Jan 2006 09:46:31 +0000 > From: Michael.Dillon at btradianz.com > >>I believe the point is for us to include a zip code that allows such >>things as geo research to occur but not for the pin point position >>of where your "relative" lives that is using ip address xxx.xxx.xxx.xxx > > For this, it should be sufficient for whois entries > to have the city, state/province and country. For > example, here are two samples for an individual and > a company: > > Joe Bloe > Milwaukee, WI, USA > > Delta Cooperage Company > Milwaukee, WI, USA > > That allows geo research and it keeps the home > address of Joe Bloe private. Anybody who really > needs the address of the Delta Cooperage Company > can go to the ARIN member who allocated addresses > to them. Of course this assumes that ARIN members > are required to maintain up to date contact information > in the whois directory. > ..except that all the current geo software uses zip codes, at least in the U.S. I am not aware of how this software works with Canada, nor whether partial postal codes would work with such software at all (and therefore negate any benefit for geo research purposes in Canada). I would strongly support a policy providing for the use of 5 digit zip codes in the U.S., and partial postal codes in Canada. Anybody from some of ARIN's other countries care to comment on how it works elsewhere in the region? -Bill Van Emburg Quadrix Solutions, Inc. From sleibrand at internap.com Sat Jan 21 10:35:38 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 21 Jan 2006 10:35:38 -0500 (EST) Subject: [ppml] PPML Digest, Vol 7, Issue 11 In-Reply-To: <43D122FB.1070609@quadrix.com> References: <43D122FB.1070609@quadrix.com> Message-ID: On 01/20/06 at 11:50am -0600, Bill Van Emburg wrote: > I would strongly support a policy providing for the use of 5 digit zip > codes in the U.S., and partial postal codes in Canada. Anybody from > some of ARIN's other countries care to comment on how it works elsewhere > in the region? Unless someone can contradict me here, I'm assuming that policy providing for the use of 5 digit ZIP codes in the US would simply codify into policy as acceptable a practice that is already permitted. Would the same be true of partial postal codes for Canadian addresses? IOW, does ARIN currently permit SWIPs to contain just the first three characters of the postal code for Canadian addresses? In any event, whether this policy proposal would change or simply clarify and codify existing poilcy, I would support a policy proposal that explicitly allows use of 5 digit ZIP codes for US addresses and partial (3 character?) postal codes for Canadian addresses. I would not support a policy that encourages omission of the ZIP/postal code entirely. -Scott From Michael.Dillon at btradianz.com Mon Jan 23 04:47:16 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 23 Jan 2006 09:47:16 +0000 Subject: [ppml] PPML Digest, Vol 7, Issue 11 In-Reply-To: <43D122FB.1070609@quadrix.com> Message-ID: > ..except that all the current geo software uses zip codes, at least in > the U.S. I am not aware of how this software works with Canada, nor > whether partial postal codes would work with such software at all (and > therefore negate any benefit for geo research purposes in Canada). I'm not sure what software you are referring to, however, I consider that the city, state/province and country are sufficient geographical information for people who want to research the geographic distribution of IP address usage. The lack of zip codes and postal codes will have no impact at all on such research. > I would strongly support a policy providing for the use of 5 digit zip > codes in the U.S., and partial postal codes in Canada. Anybody from > some of ARIN's other countries care to comment on how it works elsewhere > in the region? This idea of REQUIRING people to supply a partial zip code and a partial postal code is far too complex. As Owen DeLong has already pointed out, ARIN does not do any data format validation on these fields. They are simply treated as variable length text strings. If we did want ARIN to start validating the field entries then we would need to pay for the infrastructure to do this (i.e. publish lists of valid city names) and we would need to pay for the data cleanse to clean up the existing data. I don't see this as a productive direction for ARIN since I don't see any benefit from this. The fact is that at least some ARIN members are subject to privacy laws in which they cannot publish data collected from private citizens without their consent. This means that ARIN's previous policy either conflicted with the law or was unclear. The current policy does not change that state of affairs since the ZIP+4 code and the Canadian postal code, both narrow down the physical location of private citizens in a way that privacy laws intended to prevent. --Michael Dillon From tme at multicasttech.com Mon Jan 23 09:05:18 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 23 Jan 2006 09:05:18 -0500 Subject: [ppml] 2005-1 status Message-ID: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> Hello; When last I saw it, 2005-1 was to be reformatted to something more like its original version. Can someone tell me what the status of 2005-1 is currently ? Regards Marshall From kloch at hotnic.net Mon Jan 23 10:54:20 2006 From: kloch at hotnic.net (Kevin Loch) Date: Mon, 23 Jan 2006 10:54:20 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> Message-ID: <43D4FC2C.60903@hotnic.net> Marshall Eubanks wrote: > Hello; > > When last I saw it, 2005-1 was to be reformatted to something more like > its original version. These were my suggestions using feedback from the last meeting: 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". 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. > > Can someone tell me what the status of 2005-1 is currently ? As far as I know it hasn't changed since the last meeting. Obviously it should be updated one way or another. I would gladly write up a formal revision or new proposal if requested. - Kevin From william at elan.net Mon Jan 23 15:19:16 2006 From: william at elan.net (william(at)elan.net) Date: Mon, 23 Jan 2006 12:19:16 -0800 (PST) Subject: [ppml] ICANN task force report on purpose of whois Message-ID: Below is a document that ICANN recently made available: http://gnso.icann.org/issues/whois-privacy/prelim-tf-rpt-18jan06.htm "Preliminary task force report on the purpose of Whois and of the Whois contacts" I note that it is focused on gTLD whois and thus really has no direct consequence for ip registries whois, but it may still be of interest for when we talk on whois and privacy policies at ARIN. So if you have time (and its is a very large document) you may want to take a look. -- William Leibzon Elan Networks william at elan.net From owen at delong.com Mon Jan 23 15:25:18 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 23 Jan 2006 12:25:18 -0800 Subject: [ppml] 2005-1 status In-Reply-To: <43D4FC2C.60903@hotnic.net> References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> <43D4FC2C.60903@hotnic.net> Message-ID: <031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com> Kevin, Why don't you, Lea, and I take this off line and decide what to present back to the group. I apologize for not having followed up in a more timely manner after the last meeting. Owen On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: > Marshall Eubanks wrote: >> Hello; >> >> When last I saw it, 2005-1 was to be reformatted to something more >> like >> its original version. > > These were my suggestions using feedback from the last meeting: > > 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". > > 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. > >> >> Can someone tell me what the status of 2005-1 is currently ? > > As far as I know it hasn't changed since the last meeting. Obviously > it should be updated one way or another. I would gladly write up a > formal revision or new proposal if requested. > > - Kevin > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From dgolding at burtongroup.com Mon Jan 23 15:31:16 2006 From: dgolding at burtongroup.com (Daniel Golding) Date: Mon, 23 Jan 2006 15:31:16 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <43D4FC2C.60903@hotnic.net> Message-ID: This seems the only reasonable IPv6 allocation policy, and the one most likely to get a reasonable amount of support. Especially if part of your goal is to popularize IPv6. - Daniel Golding On 1/23/06 10:54 AM, "Kevin Loch" wrote: > 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. > From lea.roberts at stanford.edu Mon Jan 23 16:01:00 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 23 Jan 2006 13:01:00 -0800 (PST) Subject: [ppml] 2005-1 status In-Reply-To: <031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com> Message-ID: well, seems like maybe we should talk it out here (again... :-) for a while. this sounds more like a "PI for everyone" policy. while I'm sure there's a large number of people who would like that, I still think it's unlikely it can reach consensus... As I said at the meeting in L.A., I still think it is possible to reach consensus for PI assignments for large organizations and I thought that's where we were still headed after the last meeting., i.e. trying to find criteria that the latest round of objectors could live with. let the discussion begin! /Lea On Mon, 23 Jan 2006, Owen DeLong wrote: > Kevin, > Why don't you, Lea, and I take this off line and decide > what to present back to the group. I apologize for not having > followed up in a more timely manner after the last meeting. > > Owen > > On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: > > > Marshall Eubanks wrote: > >> Hello; > >> > >> When last I saw it, 2005-1 was to be reformatted to something more > >> like > >> its original version. > > > > These were my suggestions using feedback from the last meeting: > > > > 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". > > > > 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. > > > >> > >> Can someone tell me what the status of 2005-1 is currently ? > > > > As far as I know it hasn't changed since the last meeting. Obviously > > it should be updated one way or another. I would gladly write up a > > formal revision or new proposal if requested. > > > > - Kevin > > > > _______________________________________________ > > 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 billd at cait.wustl.edu Mon Jan 23 16:20:06 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Mon, 23 Jan 2006 15:20:06 -0600 Subject: [ppml] 2005-1 status Message-ID: OK, I'll start.... Why should the criteria for PI in v6 be ANY different than with v4? What was large under v4 is somehow not large under v6 apparently? Turn in you v4 PI block for a v6 PI block. That's probably a sufficiently high level argument to begin the discussion. Bill Darte ARIN AC > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Lea Roberts > Sent: Monday, January 23, 2006 3:01 PM > To: Owen DeLong > Cc: ppml at arin.net > Subject: Re: [ppml] 2005-1 status > > > well, seems like maybe we should talk it out here (again... > :-) for a while. this sounds more like a "PI for everyone" > policy. while I'm sure there's a large number of people who > would like that, I still think it's unlikely it can reach consensus... > > As I said at the meeting in L.A., I still think it is > possible to reach consensus for PI assignments for large > organizations and I thought that's where we were still headed > after the last meeting., i.e. trying to find criteria that > the latest round of objectors could live with. > > let the discussion begin! /Lea > > On Mon, 23 Jan 2006, Owen DeLong wrote: > > > Kevin, > > Why don't you, Lea, and I take this off line and decide > > what to present back to the group. I apologize for not having > > followed up in a more timely manner after the last meeting. > > > > Owen > > > > On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: > > > > > Marshall Eubanks wrote: > > >> Hello; > > >> > > >> When last I saw it, 2005-1 was to be reformatted to > something more > > >> like its original version. > > > > > > These were my suggestions using feedback from the last meeting: > > > > > > 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". > > > > > > 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. > > > > > >> > > >> Can someone tell me what the status of 2005-1 is currently ? > > > > > > As far as I know it hasn't changed since the last meeting. > > > Obviously it should be updated one way or another. I > would gladly > > > write up a formal revision or new proposal if requested. > > > > > > - Kevin > > > > > > _______________________________________________ > > > 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 > > > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From lea.roberts at stanford.edu Mon Jan 23 16:10:51 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 23 Jan 2006 13:10:51 -0800 (PST) Subject: [ppml] 2005-1 status In-Reply-To: Message-ID: because, as I'm sure you remember, Bill, the routing table won't scale over the lifetime of v6 On Mon, 23 Jan 2006, Bill Darte wrote: > OK, I'll start.... > > Why should the criteria for PI in v6 be ANY different than with v4? > What was large under v4 is somehow not large under v6 apparently? > Turn in you v4 PI block for a v6 PI block. > > That's probably a sufficiently high level argument to begin the discussion. > > Bill Darte > ARIN AC > > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > Behalf Of Lea Roberts > > Sent: Monday, January 23, 2006 3:01 PM > > To: Owen DeLong > > Cc: ppml at arin.net > > Subject: Re: [ppml] 2005-1 status > > > > > > well, seems like maybe we should talk it out here (again... > > :-) for a while. this sounds more like a "PI for everyone" > > policy. while I'm sure there's a large number of people who > > would like that, I still think it's unlikely it can reach consensus... > > > > As I said at the meeting in L.A., I still think it is > > possible to reach consensus for PI assignments for large > > organizations and I thought that's where we were still headed > > after the last meeting., i.e. trying to find criteria that > > the latest round of objectors could live with. > > > > let the discussion begin! /Lea > > > > On Mon, 23 Jan 2006, Owen DeLong wrote: > > > > > Kevin, > > > Why don't you, Lea, and I take this off line and decide > > > what to present back to the group. I apologize for not having > > > followed up in a more timely manner after the last meeting. > > > > > > Owen > > > > > > On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: > > > > > > > Marshall Eubanks wrote: > > > >> Hello; > > > >> > > > >> When last I saw it, 2005-1 was to be reformatted to > > something more > > > >> like its original version. > > > > > > > > These were my suggestions using feedback from the last meeting: > > > > > > > > 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". > > > > > > > > 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. > > > > > > > >> > > > >> Can someone tell me what the status of 2005-1 is currently ? > > > > > > > > As far as I know it hasn't changed since the last meeting. > > > > Obviously it should be updated one way or another. I > > would gladly > > > > write up a formal revision or new proposal if requested. > > > > > > > > - Kevin > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > From steven.feldman at cnet.com Mon Jan 23 16:11:38 2006 From: steven.feldman at cnet.com (Steve Feldman) Date: Mon, 23 Jan 2006 13:11:38 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <62586C5C-0C53-4526-9370-1A0BFC28E311@cnet.com> On Jan 23, 2006, at 1:01 PM, Lea Roberts wrote: > well, seems like maybe we should talk it out here (again... :-) for a > while. this sounds more like a "PI for everyone" policy. That's not the way I read it. To me, it says "If you've already justified PI space for IPv4, you don't have to jump through the hoops again for v6. If not, here are the hoops." Steve From dgolding at burtongroup.com Mon Jan 23 16:14:39 2006 From: dgolding at burtongroup.com (Daniel Golding) Date: Mon, 23 Jan 2006 16:14:39 -0500 Subject: [ppml] 2005-1 status In-Reply-To: Message-ID: Well, the last PP 2005-1 was completely unworkable. I supported it because it was better than nothing - but only barely. (Many) People who voted for it were holding their noses and voting yes in the hope of improving it later. I like consensus solutions, but it just didn't work. I don't think consensus on this issue will be possible. There are a couple camps here.... - IPv6 Proponents who want a policy that will encourage IPv6 deployment - Enterprise network managers (and their proxies) who will push for PI IPv6 space and enterprise multihoming - Service Providers - Router vendors and their allies who worry about routing table scalability A consensus PP was attempted. It failed. Now, we should attempt to craft the best possible PP for the greatest number of folks, and try to see it through. The AC and Board can move forward without consensus if the need is there. I think that should be done rarely, but this may be one of those cases. I like what Kevin had to say: You get IPv6 if you have IPv4 space now, or you are BGP multihomed, you should be able to request IPv6. - Dan On 1/23/06 4:01 PM, "Lea Roberts" wrote: > well, seems like maybe we should talk it out here (again... :-) for a > while. this sounds more like a "PI for everyone" policy. while I'm sure > there's a large number of people who would like that, I still think it's > unlikely it can reach consensus... > > As I said at the meeting in L.A., I still think it is possible to reach > consensus for PI assignments for large organizations and I thought that's > where we were still headed after the last meeting., i.e. trying to find > criteria that the latest round of objectors could live with. > > let the discussion begin! /Lea > > On Mon, 23 Jan 2006, Owen DeLong wrote: > >> Kevin, >> Why don't you, Lea, and I take this off line and decide >> what to present back to the group. I apologize for not having >> followed up in a more timely manner after the last meeting. >> >> Owen >> >> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: >> >>> Marshall Eubanks wrote: >>>> Hello; >>>> >>>> When last I saw it, 2005-1 was to be reformatted to something more >>>> like >>>> its original version. >>> >>> These were my suggestions using feedback from the last meeting: >>> >>> 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". >>> >>> 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. >>> >>>> >>>> Can someone tell me what the status of 2005-1 is currently ? >>> >>> As far as I know it hasn't changed since the last meeting. Obviously >>> it should be updated one way or another. I would gladly write up a >>> formal revision or new proposal if requested. >>> >>> - Kevin >>> >>> _______________________________________________ >>> 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 >> > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From dgolding at burtongroup.com Mon Jan 23 16:18:39 2006 From: dgolding at burtongroup.com (Daniel Golding) Date: Mon, 23 Jan 2006 16:18:39 -0500 Subject: [ppml] 2005-1 status In-Reply-To: Message-ID: That is proof by assertion. The routing table has grown relatively slowly, and there is NO reason to think it will grow faster under IPv6. The argument seems to be that IPv6 will have a much longer lifetime than IPv4, so we have to plan for 20 or 50 years from now. Trying to plan past 10 or so years in technology seems foolish. We can't imagine what technology will be like in 50 years. We may be approaching a technological singularity, making such projections useless (Kurzweil, et al), or the Internet may look completely different by then. I understand where the hardware vendors are coming from. Given that, I think we need to take it with a grain of salt. - Dan On 1/23/06 4:10 PM, "Lea Roberts" wrote: > because, as I'm sure you remember, Bill, the routing table won't scale > over the lifetime of v6 > > On Mon, 23 Jan 2006, Bill Darte wrote: > >> OK, I'll start.... >> >> Why should the criteria for PI in v6 be ANY different than with v4? >> What was large under v4 is somehow not large under v6 apparently? >> Turn in you v4 PI block for a v6 PI block. >> >> That's probably a sufficiently high level argument to begin the discussion. >> >> Bill Darte >> ARIN AC >> >> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>> Behalf Of Lea Roberts >>> Sent: Monday, January 23, 2006 3:01 PM >>> To: Owen DeLong >>> Cc: ppml at arin.net >>> Subject: Re: [ppml] 2005-1 status >>> >>> >>> well, seems like maybe we should talk it out here (again... >>> :-) for a while. this sounds more like a "PI for everyone" >>> policy. while I'm sure there's a large number of people who >>> would like that, I still think it's unlikely it can reach consensus... >>> >>> As I said at the meeting in L.A., I still think it is >>> possible to reach consensus for PI assignments for large >>> organizations and I thought that's where we were still headed >>> after the last meeting., i.e. trying to find criteria that >>> the latest round of objectors could live with. >>> >>> let the discussion begin! /Lea >>> >>> On Mon, 23 Jan 2006, Owen DeLong wrote: >>> >>>> Kevin, >>>> Why don't you, Lea, and I take this off line and decide >>>> what to present back to the group. I apologize for not having >>>> followed up in a more timely manner after the last meeting. >>>> >>>> Owen >>>> >>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: >>>> >>>>> Marshall Eubanks wrote: >>>>>> Hello; >>>>>> >>>>>> When last I saw it, 2005-1 was to be reformatted to >>> something more >>>>>> like its original version. >>>>> >>>>> These were my suggestions using feedback from the last meeting: >>>>> >>>>> 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". >>>>> >>>>> 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. >>>>> >>>>>> >>>>>> Can someone tell me what the status of 2005-1 is currently ? >>>>> >>>>> As far as I know it hasn't changed since the last meeting. >>>>> Obviously it should be updated one way or another. I >>> would gladly >>>>> write up a formal revision or new proposal if requested. >>>>> >>>>> - Kevin >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> >>> _______________________________________________ >>> 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 billd at cait.wustl.edu Mon Jan 23 16:32:52 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Mon, 23 Jan 2006 15:32:52 -0600 Subject: [ppml] 2005-1 status Message-ID: OK Lea, > > because, as I'm sure you remember, Bill, the routing table > won't scale over the lifetime of v6 > I do remember hearing something about that... ;-) But, that sounds like a routing protocol issue, not a address policy issue. Are you saying that there exist NO model for routing that would scale to that model of v6 assignment policy? I fell like socrates here.....mostly the part about drinking the potion... bd > On Mon, 23 Jan 2006, Bill Darte wrote: > > > OK, I'll start.... > > > > Why should the criteria for PI in v6 be ANY different than with v4? > > What was large under v4 is somehow not large under v6 > apparently? Turn > > in you v4 PI block for a v6 PI block. > > > > That's probably a sufficiently high level argument to begin the > > discussion. > > > > Bill Darte > > ARIN AC > > > From william at elan.net Mon Jan 23 16:38:11 2006 From: william at elan.net (william(at)elan.net) Date: Mon, 23 Jan 2006 13:38:11 -0800 (PST) Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: On Mon, 23 Jan 2006, Bill Darte wrote: > OK, I'll start.... > > Why should the criteria for PI in v6 be ANY different than with v4? Because we have an interest in promoting transition of internet users and organizations to v6 (and no such goal with v4) and virtually unlimited amount of resource space available (I know its not really unlimited and we have to be careful too, but its still a lot lot more space) as compared to very limited resources with v4. -- William Leibzon Elan Networks william at elan.net From william at elan.net Mon Jan 23 16:45:55 2006 From: william at elan.net (william(at)elan.net) Date: Mon, 23 Jan 2006 13:45:55 -0800 (PST) Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: On Mon, 23 Jan 2006, william(at)elan.net wrote: >> OK, I'll start.... >> >> Why should the criteria for PI in v6 be ANY different than with v4? > > Because we have an interest in promoting transition of internet users > and organizations to v6 (and no such goal with v4) and virtually > unlimited amount of resource space available (I know its not really > unlimited and we have to be careful too, but its still a lot lot more space) > as compared to very limited resources with v4. Ups, I guess I misunderstood the question a bit... Lea is right, there is also substantial difference in how size of ipv6 blocks and its use could effect routing table. However on this case I'd like to note that routers will likely get more memory in the future as all computers do after couple years, so change from v4 to v6 is likely not to be as much of an issue. Long-term the issues maybe if too many people apply for PI space, but I personally think we should first focus on getting existing v4 users to v6 and we can change policy later if necessary. -- William Leibzon Elan Networks william at elan.net From sleibrand at internap.com Mon Jan 23 16:49:58 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 23 Jan 2006 16:49:58 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: One possible argument (which I'm not sure I completely subscribe to) is that v6 at least has the possibility of multihoming without PI space, using shim6. The way I see it, shim6 will initially be most viable for the smallest sites, the ones that have no chance of getting PI space. It will be initially non-viable for large multihomed sites with traffic engineering requirements, lots of hosts, and spread out networks. Those sites are the ones doing PI now with v4, and IMO they will continue to need the ability to do PI with v6. So with that in mind, I would argue that ARIN's IPv6 PI policy should encourage small multihomed sites to use a non-PI multihoming model (shim6) while preserving the ability for large multihomed sites to get PI space and multihome the traditional way. Is that a consensus position? If not, which aspect of it do you disagree with, and why? If so, then we can and should proceed to defining who's big enough to need PI space for sure (regardless of the success of introducing TE into shim6), who's too small to warrant PI space regardless, and what to do about drawing the line in the middle. I'm of the opinion that we should start by letting the larger sites who're certain to need PI space get it sooner, and wait to relax the requirements later if shim6 can't be extended to meet the TE and management needs of intermediate-sized hosts. -Scott /me sits back to watch the discussion heat up, and see if flames actually erupt. On 01/23/06 at 3:20pm -0600, Bill Darte wrote: > OK, I'll start.... > > Why should the criteria for PI in v6 be ANY different than with v4? > What was large under v4 is somehow not large under v6 apparently? > Turn in you v4 PI block for a v6 PI block. > > That's probably a sufficiently high level argument to begin the discussion. > > Bill Darte > ARIN AC > > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > Behalf Of Lea Roberts > > Sent: Monday, January 23, 2006 3:01 PM > > To: Owen DeLong > > Cc: ppml at arin.net > > Subject: Re: [ppml] 2005-1 status > > > > > > well, seems like maybe we should talk it out here (again... > > :-) for a while. this sounds more like a "PI for everyone" > > policy. while I'm sure there's a large number of people who > > would like that, I still think it's unlikely it can reach consensus... > > > > As I said at the meeting in L.A., I still think it is > > possible to reach consensus for PI assignments for large > > organizations and I thought that's where we were still headed > > after the last meeting., i.e. trying to find criteria that > > the latest round of objectors could live with. > > > > let the discussion begin! /Lea > > > > On Mon, 23 Jan 2006, Owen DeLong wrote: > > > > > Kevin, > > > Why don't you, Lea, and I take this off line and decide > > > what to present back to the group. I apologize for not having > > > followed up in a more timely manner after the last meeting. > > > > > > Owen > > > > > > On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: > > > > > > > Marshall Eubanks wrote: > > > >> Hello; > > > >> > > > >> When last I saw it, 2005-1 was to be reformatted to > > something more > > > >> like its original version. > > > > > > > > These were my suggestions using feedback from the last meeting: > > > > > > > > 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". > > > > > > > > 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. > > > > > > > >> > > > >> Can someone tell me what the status of 2005-1 is currently ? > > > > > > > > As far as I know it hasn't changed since the last meeting. > > > > Obviously it should be updated one way or another. I > > would gladly > > > > write up a formal revision or new proposal if requested. > > > > > > > > - Kevin > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > > > _______________________________________________ > > 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 Lee.Howard at stanleyassociates.com Mon Jan 23 16:50:53 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 23 Jan 2006 16:50:53 -0500 Subject: [ppml] Policy without consensus? Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB401220F2C@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Daniel Golding > Sent: Monday, January 23, 2006 4:15 PM > To: Lea Roberts; Owen DeLong > Cc: PPML > Subject: Re: [ppml] 2005-1 status > > > Well, the last PP 2005-1 was completely unworkable. I > supported it because > it was better than nothing - but only barely. (Many) People > who voted for it > were holding their noses and voting yes in the hope of > improving it later. I > like consensus solutions, but it just didn't work. > > I don't think consensus on this issue will be possible. There > are a couple camps here.... That puts us in a difficult position. The process says we can only ratify a policy is there is evidence of consensus. The only exception would be in case of an emergency, and I think we're a couple of years from an emergency. http://www.arin.net/policy/irpep.html > A consensus PP was attempted. It failed. Now, we should > attempt to craft the > best possible PP for the greatest number of folks, and try to see it > through. The AC and Board can move forward without consensus > if the need is > there. I think that should be done rarely, but this may be > one of those cases. I'd have a hard time presenting this as an emergency. Lee > > - Dan > > > On 1/23/06 4:01 PM, "Lea Roberts" wrote: > > > well, seems like maybe we should talk it out here (again... > :-) for a > > while. this sounds more like a "PI for everyone" policy. > while I'm sure > > there's a large number of people who would like that, I > still think it's > > unlikely it can reach consensus... > > > > As I said at the meeting in L.A., I still think it is > possible to reach > > consensus for PI assignments for large organizations and I > thought that's > > where we were still headed after the last meeting., i.e. > trying to find > > criteria that the latest round of objectors could live with. > > > > let the discussion begin! /Lea > > > > On Mon, 23 Jan 2006, Owen DeLong wrote: > > > >> Kevin, > >> Why don't you, Lea, and I take this off line and decide > >> what to present back to the group. I apologize for not having > >> followed up in a more timely manner after the last meeting. > >> > >> Owen > >> > >> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: > >> > >>> Marshall Eubanks wrote: > >>>> Hello; > >>>> > >>>> When last I saw it, 2005-1 was to be reformatted to > something more > >>>> like > >>>> its original version. > >>> > >>> These were my suggestions using feedback from the last meeting: > >>> > >>> 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". > >>> > >>> 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. > >>> > >>>> > >>>> Can someone tell me what the status of 2005-1 is currently ? > >>> > >>> As far as I know it hasn't changed since the last > meeting. Obviously > >>> it should be updated one way or another. I would gladly > write up a > >>> formal revision or new proposal if requested. > >>> > >>> - Kevin > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > > > > > _______________________________________________ > > 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 Mon Jan 23 17:10:26 2006 From: plzak at arin.net (Ray Plzak) Date: Mon, 23 Jan 2006 17:10:26 -0500 Subject: [ppml] Policy without consensus? In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB401220F2C@CL-S-EX-1.stanleyassociates.com> Message-ID: <20060123221026.512261FE50@mercury.arin.net> Just to be clear, even in an emergency, the ARIN Board of Trustees can not make policy absent the community. The emergency provision allows the board to shorten the policy period but does not allow it to make policy. Any policy adopted through the emergency provision has a mandatory review that must be conducted at the next public policy meeting. Ray > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Howard, W. Lee > Sent: Monday, January 23, 2006 4:51 PM > To: Daniel Golding; Lea Roberts; Owen DeLong > Cc: PPML > Subject: [ppml] Policy without consensus? > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > Behalf Of Daniel Golding > > Sent: Monday, January 23, 2006 4:15 PM > > To: Lea Roberts; Owen DeLong > > Cc: PPML > > Subject: Re: [ppml] 2005-1 status > > > > > > Well, the last PP 2005-1 was completely unworkable. I > > supported it because > > it was better than nothing - but only barely. (Many) People > > who voted for it > > were holding their noses and voting yes in the hope of > > improving it later. I > > like consensus solutions, but it just didn't work. > > > > I don't think consensus on this issue will be possible. There > > are a couple camps here.... > > That puts us in a difficult position. The process says we can > only ratify a policy is there is evidence of consensus. The > only exception would be in case of an emergency, and I think > we're a couple of years from an emergency. > http://www.arin.net/policy/irpep.html > > > > A consensus PP was attempted. It failed. Now, we should > > attempt to craft the > > best possible PP for the greatest number of folks, and try to see it > > through. The AC and Board can move forward without consensus > > if the need is > > there. I think that should be done rarely, but this may be > > one of those cases. > > I'd have a hard time presenting this as an emergency. > > Lee > > > > > - Dan > > > > > > On 1/23/06 4:01 PM, "Lea Roberts" wrote: > > > > > well, seems like maybe we should talk it out here (again... > > :-) for a > > > while. this sounds more like a "PI for everyone" policy. > > while I'm sure > > > there's a large number of people who would like that, I > > still think it's > > > unlikely it can reach consensus... > > > > > > As I said at the meeting in L.A., I still think it is > > possible to reach > > > consensus for PI assignments for large organizations and I > > thought that's > > > where we were still headed after the last meeting., i.e. > > trying to find > > > criteria that the latest round of objectors could live with. > > > > > > let the discussion begin! /Lea > > > > > > On Mon, 23 Jan 2006, Owen DeLong wrote: > > > > > >> Kevin, > > >> Why don't you, Lea, and I take this off line and decide > > >> what to present back to the group. I apologize for not having > > >> followed up in a more timely manner after the last meeting. > > >> > > >> Owen > > >> > > >> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: > > >> > > >>> Marshall Eubanks wrote: > > >>>> Hello; > > >>>> > > >>>> When last I saw it, 2005-1 was to be reformatted to > > something more > > >>>> like > > >>>> its original version. > > >>> > > >>> These were my suggestions using feedback from the last meeting: > > >>> > > >>> 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". > > >>> > > >>> 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. > > >>> > > >>>> > > >>>> Can someone tell me what the status of 2005-1 is currently ? > > >>> > > >>> As far as I know it hasn't changed since the last > > meeting. Obviously > > >>> it should be updated one way or another. I would gladly > > write up a > > >>> formal revision or new proposal if requested. > > >>> > > >>> - Kevin > > >>> > > >>> _______________________________________________ > > >>> 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 > > >> > > > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From woody at pch.net Mon Jan 23 17:09:57 2006 From: woody at pch.net (Bill Woodcock) Date: Mon, 23 Jan 2006 14:09:57 -0800 (PST) Subject: [ppml] Policy without consensus? In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB401220F2C@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB401220F2C@CL-S-EX-1.stanleyassociates.com> Message-ID: On Mon, 23 Jan 2006, Howard, W. Lee wrote: > > Well, the last PP 2005-1 was completely unworkable. I > > supported it because > > it was better than nothing - but only barely. (Many) People > > who voted for it > > were holding their noses and voting yes in the hope of > > improving it later. Yup, that's certainly true of me, and of everyone else I know who voted for it. It wasn't acceptable as voted, but there was nothing else on the table, and nothing else we could vote for. Yes, that's a really major problem. > That puts us in a difficult position. The process says we can > only ratify a policy is there is evidence of consensus. The > only exception would be in case of an emergency, and I think > we're a couple of years from an emergency. I think we're a couple of years into an emergency. -Bill From kloch at hotnic.net Mon Jan 23 17:35:54 2006 From: kloch at hotnic.net (Kevin Loch) Date: Mon, 23 Jan 2006 17:35:54 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <43D55A4A.9090908@hotnic.net> Scott Leibrand wrote: > One possible argument (which I'm not sure I completely subscribe to) is > that v6 at least has the possibility of multihoming without PI > space, using shim6. Having read the shim6 drafts, I don't feel it is currently a viable substitute for PI. That may change, or some new technology may be developed that is a viable substitute. In any case it's not here today. > The way I see it, shim6 will initially be most viable > for the smallest sites, the ones that have no chance of getting PI space. > It will be initially non-viable for large multihomed sites with traffic > engineering requirements, lots of hosts, and spread out networks. Those > sites are the ones doing PI now with v4, and IMO they will continue to > need the ability to do PI with v6. I expect the vast majority of applicants would have or qualify for v4 PI space and pass through that part of the policy. > So with that in mind, I would argue that ARIN's IPv6 PI policy should > encourage small multihomed sites to use a non-PI multihoming model (shim6) > while preserving the ability for large multihomed sites to get PI space > and multihome the traditional way. I expect the number of v6 only applicants to be small initially so it isn't worth spending much time on that part until we have some experience with them. > I'm of the opinion that we should start by letting the larger sites who're > certain to need PI space get it sooner, and wait to relax the requirements > later if shim6 can't be extended to meet the TE and management needs of > intermediate-sized hosts. That approach was tried at the LA meeting and it was thoroughly rejected (based on microphone comments rather than votes). - Kevin From stephen at sprunk.org Mon Jan 23 18:07:13 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 23 Jan 2006 17:07:13 -0600 Subject: [ppml] Policy without consensus? References: <369EB04A0951824ABE7D8BAC67AF9BB401220F2C@CL-S-EX-1.stanleyassociates.com> Message-ID: <01eb01c62071$bf03fa20$730016ac@ssprunk> Thus spake "Bill Woodcock" > On Mon, 23 Jan 2006, Howard, W. Lee wrote: > > > Well, the last PP 2005-1 was completely unworkable. I > > > supported it because it was better than nothing - but only > > > barely. (Many) People who voted for it were holding their > > > noses and voting yes in the hope of improving it later. > > Yup, that's certainly true of me, and of everyone else I know who voted > for it. It wasn't acceptable as voted, but there was nothing else on the > table, and nothing else we could vote for. Yes, that's a really major > problem. So what's the alternative to floating one proposal that the author hopes appeases every faction? Floating a dozen and seeing which (if any) pass? > > That puts us in a difficult position. The process says we can > > only ratify a policy is there is evidence of consensus. The > > only exception would be in case of an emergency, and I think > > we're a couple of years from an emergency. > > I think we're a couple of years into an emergency. Emergency? The Internet is running just fine with IPv6, and will for nearly another decade even using the most pessimistic models I've seen. Routing slots and government interference present greater threats to the Internet than address scarcity for the time being. IMHO, this shouldn't qualify as an emergency in the eyes of the BoT until IANA runs out of IPv4 space to give the RIRs. 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 lea.roberts at stanford.edu Mon Jan 23 18:11:37 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 23 Jan 2006 15:11:37 -0800 (PST) Subject: [ppml] Policy without consensus? In-Reply-To: Message-ID: so do you gentlemen believe that we should allow unlimited allocation of IPv6 PI space to whomever wants to multihome and just consider the possible routing table scaling problems to be something that will be dealt with later? and you also don't worry about carrying over the "IPv4 early adopter bonus" into the brave new IPv6 world? assuming of course that the policy might have to be more restrictive later? just curious, /Lea On Mon, 23 Jan 2006, Bill Woodcock wrote: > On Mon, 23 Jan 2006, Howard, W. Lee wrote: > > > Well, the last PP 2005-1 was completely unworkable. I > > > supported it because > > > it was better than nothing - but only barely. (Many) People > > > who voted for it > > > were holding their noses and voting yes in the hope of > > > improving it later. > > Yup, that's certainly true of me, and of everyone else I know who voted > for it. It wasn't acceptable as voted, but there was nothing else on the > table, and nothing else we could vote for. Yes, that's a really major > problem. > > > That puts us in a difficult position. The process says we can > > only ratify a policy is there is evidence of consensus. The > > only exception would be in case of an emergency, and I think > > we're a couple of years from an emergency. > > I think we're a couple of years into an emergency. > > -Bill > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From gih at apnic.net Mon Jan 23 18:20:03 2006 From: gih at apnic.net (Geoff Huston) Date: Tue, 24 Jan 2006 10:20:03 +1100 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <6.2.0.14.2.20060124092523.02ba0120@kahuna.telstra.net> At 08:18 AM 24/01/2006, Daniel Golding wrote: >That is proof by assertion. The routing table has grown relatively slowly, Relative to what? >and there is NO reason to think it will grow faster under IPv6. Given that there are few natural constraints to routing table bloat other than an advanced state of social consciousness, the drivers for IPv6 routing table bloat appear to include a vastly larger end device population and a commodity utility provider structure that cares little about spending time (and money) to take measures to avoid routing table expansion. That would appear to constitute grounds for thinking that, yes, there is a distinct risk of IPv6 route table bloat at levels greater than we've seen in IPv4. So under what basis have you reached an opposite conclusion? >The argument >seems to be that IPv6 will have a much longer lifetime than IPv4, so we have >to plan for 20 or 50 years from now. Yes, among other considerations that consideration exists, yes. >Trying to plan past 10 or so years in technology seems foolish. On the other hand believing that the industry will spend in excess of 10**9 dollars every decade or so to undertake a complete technology shift also seems somewhat fanciful. There is some credibility to the proposition that IPv6 will be around for many decades to come, and it does appear to be a sad repetition of some of the known mistakes we made with IPv4 if we were to deliberately take a short term approach to IPv6. regards, Geoff Huston From tvest at pch.net Mon Jan 23 18:38:33 2006 From: tvest at pch.net (Tom Vest) Date: Mon, 23 Jan 2006 18:38:33 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <6.2.0.14.2.20060124092523.02ba0120@kahuna.telstra.net> References: <6.2.0.14.2.20060124092523.02ba0120@kahuna.telstra.net> Message-ID: On Jan 23, 2006, at 6:20 PM, Geoff Huston wrote: > At 08:18 AM 24/01/2006, Daniel Golding wrote: > >> That is proof by assertion. The routing table has grown relatively >> slowly, > > Relative to what? > >> and there is NO reason to think it will grow faster under IPv6. > > Given that there are few natural constraints to routing table bloat > other > than an advanced state of social consciousness, the drivers for IPv6 > routing table bloat appear to include a vastly larger end device > population > and a commodity utility provider structure that cares little about > spending > time (and money) to take measures to avoid routing table expansion. > That would appear to constitute grounds for thinking that, yes, > there is a distinct risk of IPv6 route table bloat at levels greater > than we've seen in IPv4. There is another factor also. ASes have now been implicitly adopted as a pricing factor for interconnection, in a way that could contribute to inflated demand for ASNs relative to the current demand drivers/trend. To the extent that ASN proliferation correlates with routing table bloat, and there are no new countervailing factors, we could be facing a new routing table growth dynamic altogether. c.f., > http://global.mci.com/uunet/peering/ redubbed today as: http://www.verizonbusiness.com/uunet/peering/ (section 1.5) TV From billd at cait.wustl.edu Mon Jan 23 19:00:16 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Mon, 23 Jan 2006 18:00:16 -0600 Subject: [ppml] 2005-1 status Message-ID: From: Scott Leibrand One possible argument (which I'm not sure I completely subscribe to) is that v6 at least has the possibility of multihoming without PI space, using shim6. The way I see it, shim6 will initially be most viable for the smallest sites, the ones that have no chance of getting PI space. Scott, The only reason that the smallest sites will have NO possibility of getting PI space is if a consensus number of supporters cannot be found to support their cause. Why should they be denied and their larger counterparts not? So with that in mind, I would argue that ARIN's IPv6 PI policy should encourage small multihomed sites to use a non-PI multihoming model (shim6) while preserving the ability for large multihomed sites to get PI space and multihome the traditional way. Is that a consensus position? If not, which aspect of it do you disagree with, and why? Scott, I'd say that placing a special burden on small operations, and SHIM6 from my limited observations seems like a very 'special' burden, to allow them to multihome whereas their larger counterparts can avoid the same burden with PI...well THAT is what needs to be justified, seems to me. If so, then we can and should proceed to defining who's big enough to need PI space for sure (regardless of the success of introducing TE into shim6), who's too small to warrant PI space regardless, and what to do about drawing the line in the middle. Scott, I'd say it is too early to decide the haves and havenots until we understand full the absolute NEED to make the distinction. I am in support of enabling v6 an opportunity to succeed, but not at any cost. I'd like to know that it is an assignment policy problem exclusively before we ascribe an assignment policy solution. From gih at apnic.net Mon Jan 23 18:56:52 2006 From: gih at apnic.net (Geoff Huston) Date: Tue, 24 Jan 2006 10:56:52 +1100 Subject: [ppml] 2005-1 status In-Reply-To: References: <6.2.0.14.2.20060124092523.02ba0120@kahuna.telstra.net> Message-ID: <6.2.0.14.2.20060124104832.02b97a80@kahuna.telstra.net> At 10:38 AM 24/01/2006, Tom Vest wrote: >On Jan 23, 2006, at 6:20 PM, Geoff Huston wrote: > >>At 08:18 AM 24/01/2006, Daniel Golding wrote: >> >>>That is proof by assertion. The routing table has grown relatively >>>slowly, >> >>Relative to what? >> >>>and there is NO reason to think it will grow faster under IPv6. >> >>Given that there are few natural constraints to routing table bloat >>other >>than an advanced state of social consciousness, the drivers for IPv6 >>routing table bloat appear to include a vastly larger end device >>population >>and a commodity utility provider structure that cares little about >>spending >>time (and money) to take measures to avoid routing table expansion. >>That would appear to constitute grounds for thinking that, yes, >>there is a distinct risk of IPv6 route table bloat at levels greater >>than we've seen in IPv4. > >There is another factor also. ASes have now been implicitly adopted >as a pricing factor for interconnection, in a way that could >contribute to inflated demand for ASNs relative to the current demand >drivers/trend. To the extent that ASN proliferation correlates with >routing table bloat, and there are no new countervailing factors, we >could be facing a new routing table growth dynamic altogether. hmm - assuming that the 4byte implementations appear in the coming years then its not a scarcity factor that would be driving AS consumption. I'm not sure of the extent to which AS number growth drives BGP scaling issues - I suppose I could identify two areas: a decline in the number of prefixes per Update message, causing a greater number of update messages to be generated, and (depending on implementation approach) a greater memory load (However, I vaguely recall that one major vendor's implementation of BGP used 1 prefix per update for many years - but I'm not sure when and where I heard it and whether it was "fixed" recently or not - if this is still the case then the update load for such an implementation would be independent of the number of ASs in the routing system.) Geoff From stephen at sprunk.org Mon Jan 23 19:19:57 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 23 Jan 2006 18:19:57 -0600 Subject: [ppml] Policy without consensus? References: <369EB04A0951824ABE7D8BAC67AF9BB401220F2C@CL-S-EX-1.stanleyassociates.com> <01eb01c62071$bf03fa20$730016ac@ssprunk> Message-ID: <028201c6207b$e8959060$730016ac@ssprunk> Thus spake "Stephen Sprunk" > Thus spake "Bill Woodcock" >> I think we're a couple of years into an emergency. > > Emergency? The Internet is running just fine with IPv6, and will for > nearly Oops, that should have been "without". What a typo... > another decade even using the most pessimistic models I've seen. > Routing slots and government interference present greater threats to > the Internet than address scarcity for the time being. 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 sleibrand at internap.com Mon Jan 23 19:20:30 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 23 Jan 2006 19:20:30 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: On 01/23/06 at 6:00pm -0600, Bill Darte wrote: > From: Scott Leibrand > > One possible argument (which I'm not sure I completely subscribe to) > > is that v6 at least has the possibility of multihoming without PI > > space, using shim6. The way I see it, shim6 will initially be most > > viable for the smallest sites, the ones that have no chance of getting > > PI space. > > Scott, The only reason that the smallest sites will have NO possibility of > getting PI space is if a consensus number of supporters cannot be found to > support their cause. Why should they be denied and their larger > counterparts not? Yes, there's one very important reason: If you give a small site PI space in the absence of some hierarchical allocation system (like geo-addressing, which has its own complexities that'd have to be worked out first), then that PI space will make it into the routing tables of nearly everyone running BGP. IOW, everyone running BGP will consume resources to support that small site's ability to multihome. In the case of the smallest sites, end users, I think everyone agrees that such a burden on the global routing system would not be justified. Now I'm not saying that an unrestricted PI space would result in many end users running BGP, since their ISPs would charge them for the privilege. However I think the extreme case illustrates the problems introduced by making PI space the only way to multihome in IPv6. In contrast, I think that small sites would jump on the chance to multihome their network without asking their ISP's permission. I believe shim6 will eventually be available in major OS's IP stacks, and it will get used. IMO it will be an alternative to running BGP, and a very attractive one to smaller sites. > > So with that in mind, I would argue that ARIN's IPv6 PI policy should > > encourage small multihomed sites to use a non-PI multihoming model > > (shim6) while preserving the ability for large multihomed sites to get > > PI space and multihome the traditional way. > > > > Is that a consensus position? If not, which aspect of it do you > > disagree with, and why? > > Scott, I'd say that placing a special burden on small operations, and SHIM6 > from my limited observations seems like a very 'special' burden, to allow > them to multihome whereas their larger counterparts can avoid the same > burden with PI...well THAT is what needs to be justified, seems to me. As I alluded to above, the burden is relative to the number of hosts and BGP-capable routers you control. If you control multiple BGP-capable routers and lots of hosts, then shim6 is harder than PI space. If you control no BGP routers and few hosts, then BGP is more of a burden. I think the large site / small site distinction is a natural one, not an artificial one. > > If so, then we can and should proceed to defining who's big enough to > > need PI space for sure (regardless of the success of introducing TE > > into shim6), who's too small to warrant PI space regardless, and what > > to do about drawing the line in the middle. > > Scott, I'd say it is too early to decide the haves and havenots until we > understand full the absolute NEED to make the distinction. I'm not asking us to decide the have nots. I'm saying we should allocate PI space to users who will have to have PI space regardless. In contrast to the last proposal submitted at the L.A. ARIN, I think that universe encompasses a large number of the sites currently running BGP with full routes. However, I'm pretty sure that universe doesn't *yet* include anyone not running BGP in IPv4. > I am in support of enabling v6 an opportunity to succeed, but not at any > cost. I'd like to know that it is an assignment policy problem > exclusively before we ascribe an assignment policy solution. I agree. That's why I think it's essential that we not allocate IPv6 PI space to just anyone who wants it immediately. I think the evidence is abundant that large currently-multihomed enterprises who currently run BGP and have (or qualify for) IPv4 PI space will need IPv6 PI space as well. The question in my mind is who else has to have PI space. I don't think that having a /48 from two ISPs should necessarily qualify you, at least until we give shim6 a chance to target that market. -Scott From randy at psg.com Mon Jan 23 19:21:27 2006 From: randy at psg.com (Randy Bush) Date: Tue, 24 Jan 2006 09:21:27 +0900 Subject: [ppml] 2005-1 status References: <6.2.0.14.2.20060124092523.02ba0120@kahuna.telstra.net> Message-ID: <17365.29447.652888.488964@roam.psg.com> > ASes have now been implicitly adopted as a pricing factor for > interconnection perhaps you could expand/explain randy From sleibrand at internap.com Mon Jan 23 19:47:43 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 23 Jan 2006 19:47:43 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: <43D573E7.7090503@comcast.net> References: <43D573E7.7090503@comcast.net> Message-ID: On 01/23/06 at 4:25pm -0800, Tony Li wrote: > > I'd like to know that it is an assignment policy problem exclusively > > before we ascribe an assignment policy solution. > > I believe that this hits the nail squarely on the head. The real issue > at hand is that we still do not have consensus on an acceptable routing > architecture for IPv6. Until we have consensus on a multi-homing > solution, we do not have a tractable technical solution for anyone to be > forming address allocation policies around. And it seems highly > unlikely that better policy is going to compensate for the lack of a > technical solution. I see two camps on the multi-homing solution, and I think they might both be right in some ways. Some network operators wonder what's wrong with continuing to multi-home the same way that has worked reasonably well for so many years. They look at Moore's Law as solving the memory usage problems introduced by routing table growth. They see a host-based solution as unworkable for large networks with sometimes complex traffic engineering requirements that shim6 hasn't even attempted to address yet. Many others see the need for a new multihoming model for a new and somewhat different Internet Protocol. They see a need for host and site multihoming that doesn't require coordination with transit providers, doesn't require global routing table resources to be used when a site multihomes, and in general provides more flexibility for end users. I started out in the first camp, but recently have been reading the shim6 Internet-Drafts and am starting to see the two approaches as complementary. For sites with hundreds, thousands or more diverse hosts who know and run BGP, IPv6 PI space seems the way to go. For multihomed end users, small sites not running BGP but who'd like to multihome, and sites who'd like their hosts to be able to reroute traffic when they see performance degradation, shim6 will provide a useful alternative. I think we can support both camps. Those who already have IPv4 PI space, who meet the requirements to get it, or who meet similar requirements adjusted for IPv6 concepts should be able to get IPv6 PI space. Smaller users who might have a /24 from their ISP announced with BGP to two or more upstreams can do the same with their IPv6 PA space, and at the same time roll out shim6 as appropriate to improve failover. Smaller users yet who currently have no good multihoming options will soon have an option with IPv6, as long as we don't throw the gates wide open for PI space assignments and discourage shim6 adoption. -Scott From woody at pch.net Mon Jan 23 20:01:59 2006 From: woody at pch.net (Bill Woodcock) Date: Mon, 23 Jan 2006 17:01:59 -0800 (PST) Subject: [ppml] Policy without consensus? In-Reply-To: References: Message-ID: > so do you gentlemen believe that we should allow unlimited allocation of > IPv6 PI space to whomever wants to multihome and just consider the > possible routing table scaling problems to be something that will be > dealt with later? and you also don't worry about carrying over the "IPv4 > early adopter bonus" into the brave new IPv6 world? assuming of course > that the policy might have to be more restrictive later? What am I missing? What's the point of having IPv6 if people can't actually get it and route it? Nobody's suggesting it be "unlimited." If it were "unlimited" ARIN wouldn't need to be involved. I just don't see why it's not allocated the same way IPv4 is. It's just integers, not magic. -Bill From woody at pch.net Mon Jan 23 20:06:42 2006 From: woody at pch.net (Bill Woodcock) Date: Mon, 23 Jan 2006 17:06:42 -0800 (PST) Subject: [ppml] Policy without consensus? In-Reply-To: <01eb01c62071$bf03fa20$730016ac@ssprunk> References: <369EB04A0951824ABE7D8BAC67AF9BB401220F2C@CL-S-EX-1.stanleyassociates.com> <01eb01c62071$bf03fa20$730016ac@ssprunk> Message-ID: On Mon, 23 Jan 2006, Stephen Sprunk wrote: > Emergency? The Internet is running just fine without IPv6, and will > for nearly another decade. It's not an emergency for the IPv4 Internet, it's an emergency for the IPv6 Internet, which is trying to operate with half-assed policies. -Bill From tvest at pch.net Mon Jan 23 20:34:06 2006 From: tvest at pch.net (Tom Vest) Date: Mon, 23 Jan 2006 20:34:06 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <17365.29447.652888.488964@roam.psg.com> References: <6.2.0.14.2.20060124092523.02ba0120@kahuna.telstra.net> <17365.29447.652888.488964@roam.psg.com> Message-ID: <3D858070-4F58-4F2B-87E6-8E9966799E33@pch.net> On Jan 23, 2006, at 7:21 PM, Randy Bush wrote: >> ASes have now been implicitly adopted as a pricing factor for >> interconnection > > perhaps you could expand/explain > > randy Commercial service providers profit from increasing revenue or decreasing opex, all things remaining equal. A smart operator will carefully weigh the costs of any SFP requirement against the projected long-term benefits. The value of global SFP may be incalculable, but it probably looks pretty good to operators that generate (or could profitably generate) a lot of traffic internally. In any case, SFP policies that measure the benefits of interconnection in terms of infrastructure scope and scale encourage operators to consider how quickly additional capex along those lines might be repaid in recurring opex/transit savings. No doubt most investments made on this basis made sense locally at the time. Equally likely the vast majority had no adverse impact, or at least none beyond the confines of the operator/investor's (and their employees') own bottom line. But there are always ways to game any system, and some would rightly be considered harmful. Presumably, SFP policies that measure the benefits of interconnection in terms of ASNs would encourage operators to compete more aggressively for transit customers. But zero sum competition is ugly and expensive, and there are probably easier ways to add new AS- mediated transit relationships. Most large operators administer multiple ASNs; who's to say that they don't need more? Most have many direct network service customers; who's to say that those customers might not be better served by having their own ASNs? I am not suggesting any malign intent here, but this is a tough market. *IF* (alt: whenever/wherever) the benefits of having more ASN- based transit relationships exceed the costs, the technical merits of such ASN requirements may come to seem a lot more compelling to the relevant parties. That said, if Geoff is correct and ASN proliferation has no relationship to routing table bloat, then maybe it doesn't matter in this context. TV (stock apology for pedantic tone applies) From billd at cait.wustl.edu Mon Jan 23 21:04:36 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Mon, 23 Jan 2006 20:04:36 -0600 Subject: [ppml] 2005-1 status Message-ID: Geoff, I'm interested in knowing whether you think that the consolidation of providers in a global commodity market for vX bit pushing will impact the routing table 'bloat'.....assuming you think that consolidation is a logical consequence of the commodity of bit pushing....assuming you think bit pushing IS a commodity. Didn't mean to make a riddle out of this.. Geoff said: Given that there are few natural constraints to routing table bloat other than an advanced state of social consciousness, the drivers for IPv6 routing table bloat appear to include a vastly larger end device population and a commodity utility provider structure that cares little about spending time (and money) to take measures to avoid routing table expansion. That would appear to constitute grounds for thinking that, yes, there is a distinct risk of IPv6 route table bloat at levels greater than we've seen in IPv4. From tme at multicasttech.com Mon Jan 23 21:01:43 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 23 Jan 2006 21:01:43 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <047324C6-C4C8-4FD8-9A9B-5A71B654D671@multicasttech.com> I cannot predict what might happen hundreds of years from now. I can say, however, that 2002-3 has not caused an explosion in the routing table for IPv4, nor would I expect that 2005-1 would do so for IPv6. Regards Marshall On Jan 23, 2006, at 4:10 PM, Lea Roberts wrote: > because, as I'm sure you remember, Bill, the routing table won't scale > over the lifetime of v6 > > On Mon, 23 Jan 2006, Bill Darte wrote: > >> OK, I'll start.... >> >> Why should the criteria for PI in v6 be ANY different than with v4? >> What was large under v4 is somehow not large under v6 apparently? >> Turn in you v4 PI block for a v6 PI block. >> >> That's probably a sufficiently high level argument to begin the >> discussion. >> >> Bill Darte >> ARIN AC >> >> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>> Behalf Of Lea Roberts >>> Sent: Monday, January 23, 2006 3:01 PM >>> To: Owen DeLong >>> Cc: ppml at arin.net >>> Subject: Re: [ppml] 2005-1 status >>> >>> >>> well, seems like maybe we should talk it out here (again... >>> :-) for a while. this sounds more like a "PI for everyone" >>> policy. while I'm sure there's a large number of people who >>> would like that, I still think it's unlikely it can reach >>> consensus... >>> >>> As I said at the meeting in L.A., I still think it is >>> possible to reach consensus for PI assignments for large >>> organizations and I thought that's where we were still headed >>> after the last meeting., i.e. trying to find criteria that >>> the latest round of objectors could live with. >>> >>> let the discussion begin! /Lea >>> >>> On Mon, 23 Jan 2006, Owen DeLong wrote: >>> >>>> Kevin, >>>> Why don't you, Lea, and I take this off line and decide >>>> what to present back to the group. I apologize for not having >>>> followed up in a more timely manner after the last meeting. >>>> >>>> Owen >>>> >>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: >>>> >>>>> Marshall Eubanks wrote: >>>>>> Hello; >>>>>> >>>>>> When last I saw it, 2005-1 was to be reformatted to >>> something more >>>>>> like its original version. >>>>> >>>>> These were my suggestions using feedback from the last meeting: >>>>> >>>>> 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". >>>>> >>>>> 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. >>>>> >>>>>> >>>>>> Can someone tell me what the status of 2005-1 is currently ? >>>>> >>>>> As far as I know it hasn't changed since the last meeting. >>>>> Obviously it should be updated one way or another. I >>> would gladly >>>>> write up a formal revision or new proposal if requested. >>>>> >>>>> - Kevin >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> >>> _______________________________________________ >>> 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 sleibrand at internap.com Mon Jan 23 21:08:02 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 23 Jan 2006 21:08:02 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: <047324C6-C4C8-4FD8-9A9B-5A71B654D671@multicasttech.com> References: <047324C6-C4C8-4FD8-9A9B-5A71B654D671@multicasttech.com> Message-ID: I would agree. However, 2005-1 did not reach consensus, so we need to come up with an alternative that's more likely to do so. I would love to hear what exactly everyone thinks is an appropriate standard for allocating IPv6 PI space so we can better gauge what would be a consensus position. -Scott On 01/23/06 at 9:01pm -0500, Marshall Eubanks wrote: > I cannot predict what might happen hundreds of years from now. > > I can say, however, that 2002-3 has not caused an explosion in the > routing table for IPv4, nor > would I expect that 2005-1 would do so for IPv6. > > Regards > Marshall > > On Jan 23, 2006, at 4:10 PM, Lea Roberts wrote: > > > because, as I'm sure you remember, Bill, the routing table won't scale > > over the lifetime of v6 > > > > On Mon, 23 Jan 2006, Bill Darte wrote: > > > >> OK, I'll start.... > >> > >> Why should the criteria for PI in v6 be ANY different than with v4? > >> What was large under v4 is somehow not large under v6 apparently? > >> Turn in you v4 PI block for a v6 PI block. > >> > >> That's probably a sufficiently high level argument to begin the > >> discussion. > >> > >> Bill Darte > >> ARIN AC > >> > >> > >>> -----Original Message----- > >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > >>> Behalf Of Lea Roberts > >>> Sent: Monday, January 23, 2006 3:01 PM > >>> To: Owen DeLong > >>> Cc: ppml at arin.net > >>> Subject: Re: [ppml] 2005-1 status > >>> > >>> > >>> well, seems like maybe we should talk it out here (again... > >>> :-) for a while. this sounds more like a "PI for everyone" > >>> policy. while I'm sure there's a large number of people who > >>> would like that, I still think it's unlikely it can reach > >>> consensus... > >>> > >>> As I said at the meeting in L.A., I still think it is > >>> possible to reach consensus for PI assignments for large > >>> organizations and I thought that's where we were still headed > >>> after the last meeting., i.e. trying to find criteria that > >>> the latest round of objectors could live with. > >>> > >>> let the discussion begin! /Lea > >>> > >>> On Mon, 23 Jan 2006, Owen DeLong wrote: > >>> > >>>> Kevin, > >>>> Why don't you, Lea, and I take this off line and decide > >>>> what to present back to the group. I apologize for not having > >>>> followed up in a more timely manner after the last meeting. > >>>> > >>>> Owen > >>>> > >>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: > >>>> > >>>>> Marshall Eubanks wrote: > >>>>>> Hello; > >>>>>> > >>>>>> When last I saw it, 2005-1 was to be reformatted to > >>> something more > >>>>>> like its original version. > >>>>> > >>>>> These were my suggestions using feedback from the last meeting: > >>>>> > >>>>> 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". > >>>>> > >>>>> 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. > >>>>> > >>>>>> > >>>>>> Can someone tell me what the status of 2005-1 is currently ? > >>>>> > >>>>> As far as I know it hasn't changed since the last meeting. > >>>>> Obviously it should be updated one way or another. I > >>> would gladly > >>>>> write up a formal revision or new proposal if requested. > >>>>> > >>>>> - Kevin > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From tme at multicasttech.com Mon Jan 23 21:11:29 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 23 Jan 2006 21:11:29 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: I do not agree with this position. I see no reason why the assignment policies should be different and I see a strong demand for multi-homing. BTW, is shim6 running code ? Regards Marshall On Jan 23, 2006, at 4:49 PM, Scott Leibrand wrote: > One possible argument (which I'm not sure I completely subscribe > to) is > that v6 at least has the possibility of multihoming without PI > space, using shim6. The way I see it, shim6 will initially be most > viable > for the smallest sites, the ones that have no chance of getting PI > space. > It will be initially non-viable for large multihomed sites with > traffic > engineering requirements, lots of hosts, and spread out networks. > Those > sites are the ones doing PI now with v4, and IMO they will continue to > need the ability to do PI with v6. > > So with that in mind, I would argue that ARIN's IPv6 PI policy should > encourage small multihomed sites to use a non-PI multihoming model > (shim6) > while preserving the ability for large multihomed sites to get PI > space > and multihome the traditional way. > > Is that a consensus position? If not, which aspect of it do you > disagree > with, and why? If so, then we can and should proceed to defining > who's > big enough to need PI space for sure (regardless of the success of > introducing TE into shim6), who's too small to warrant PI space > regardless, and what to do about drawing the line in the middle. > > I'm of the opinion that we should start by letting the larger sites > who're > certain to need PI space get it sooner, and wait to relax the > requirements > later if shim6 can't be extended to meet the TE and management > needs of > intermediate-sized hosts. > > -Scott > > /me sits back to watch the discussion heat up, and see if flames > actually > erupt. > > On 01/23/06 at 3:20pm -0600, Bill Darte wrote: > >> OK, I'll start.... >> >> Why should the criteria for PI in v6 be ANY different than with v4? >> What was large under v4 is somehow not large under v6 apparently? >> Turn in you v4 PI block for a v6 PI block. >> >> That's probably a sufficiently high level argument to begin the >> discussion. >> >> Bill Darte >> ARIN AC >> >> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>> Behalf Of Lea Roberts >>> Sent: Monday, January 23, 2006 3:01 PM >>> To: Owen DeLong >>> Cc: ppml at arin.net >>> Subject: Re: [ppml] 2005-1 status >>> >>> >>> well, seems like maybe we should talk it out here (again... >>> :-) for a while. this sounds more like a "PI for everyone" >>> policy. while I'm sure there's a large number of people who >>> would like that, I still think it's unlikely it can reach >>> consensus... >>> >>> As I said at the meeting in L.A., I still think it is >>> possible to reach consensus for PI assignments for large >>> organizations and I thought that's where we were still headed >>> after the last meeting., i.e. trying to find criteria that >>> the latest round of objectors could live with. >>> >>> let the discussion begin! /Lea >>> >>> On Mon, 23 Jan 2006, Owen DeLong wrote: >>> >>>> Kevin, >>>> Why don't you, Lea, and I take this off line and decide >>>> what to present back to the group. I apologize for not having >>>> followed up in a more timely manner after the last meeting. >>>> >>>> Owen >>>> >>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: >>>> >>>>> Marshall Eubanks wrote: >>>>>> Hello; >>>>>> >>>>>> When last I saw it, 2005-1 was to be reformatted to >>> something more >>>>>> like its original version. >>>>> >>>>> These were my suggestions using feedback from the last meeting: >>>>> >>>>> 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". >>>>> >>>>> 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. >>>>> >>>>>> >>>>>> Can someone tell me what the status of 2005-1 is currently ? >>>>> >>>>> As far as I know it hasn't changed since the last meeting. >>>>> Obviously it should be updated one way or another. I >>> would gladly >>>>> write up a formal revision or new proposal if requested. >>>>> >>>>> - Kevin >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From woody at pch.net Mon Jan 23 21:07:56 2006 From: woody at pch.net (Bill Woodcock) Date: Mon, 23 Jan 2006 18:07:56 -0800 (PST) Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: > I see no reason why the assignment policies > should be different and I see a strong demand for multi-homing. Agreed, with the exception that I'd like to see a small block allocated for swamp prefixes. -Bill From tme at multicasttech.com Mon Jan 23 21:24:41 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 23 Jan 2006 21:24:41 -0500 Subject: [ppml] Policy without consensus? In-Reply-To: References: Message-ID: <313A7142-4214-41BB-BE80-3476EF870C00@multicasttech.com> I would care more, at present at least, that the IPv6 routing table actually get USED. At present, it is, what, 1% of the total ? One thing we learned in multicast is not to worry about problems caused by success until you actually have something like success. Regards Marshall On Jan 23, 2006, at 6:11 PM, Lea Roberts wrote: > so do you gentlemen believe that we should allow unlimited > allocation of > IPv6 PI space to whomever wants to multihome and just consider the > possible routing table scaling problems to be something that will be > dealt with later? and you also don't worry about carrying over the > "IPv4 > early adopter bonus" into the brave new IPv6 world? assuming of > course > that the policy might have to be more restrictive later? > > just curious, /Lea > > On Mon, 23 Jan 2006, Bill Woodcock wrote: > >> On Mon, 23 Jan 2006, Howard, W. Lee wrote: >>>> Well, the last PP 2005-1 was completely unworkable. I >>>> supported it because >>>> it was better than nothing - but only barely. (Many) People >>>> who voted for it >>>> were holding their noses and voting yes in the hope of >>>> improving it later. >> >> Yup, that's certainly true of me, and of everyone else I know who >> voted >> for it. It wasn't acceptable as voted, but there was nothing else >> on the >> table, and nothing else we could vote for. Yes, that's a really >> major >> problem. >> >>> That puts us in a difficult position. The process says we can >>> only ratify a policy is there is evidence of consensus. The >>> only exception would be in case of an emergency, and I think >>> we're a couple of years from an emergency. >> >> I think we're a couple of years into an emergency. >> >> -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 dgolding at burtongroup.com Mon Jan 23 21:49:43 2006 From: dgolding at burtongroup.com (Daniel Golding) Date: Mon, 23 Jan 2006 21:49:43 -0500 Subject: [ppml] Policy without consensus? In-Reply-To: <313A7142-4214-41BB-BE80-3476EF870C00@multicasttech.com> Message-ID: We may have to change routing paradigms at some point. When we approach that scaling limit, it can be considered and examined. We are busy worrying about being able to route the entire IPv6 space. The funny thing is, unless there is a reasonable allocation policy, IPv6 will end up on the dust heap of history. Some folks assume that enterprises are willing to swallow a lack of PI space and multihoming. Wrong - they are not and will not now or in the future. They buy carrier services - and they will not buy IPv6 services without PI space and true multihoming. If we can't allocate IPv6 space to enterprises, then its time to scrap IPv6 and start again. There is really no middle case in the real world. - Daniel Golding On 1/23/06 9:24 PM, "Marshall Eubanks" wrote: > I would care more, at present at least, that the IPv6 routing table > actually get USED. At present, it is, what, 1% of the total ? > > One thing we learned in multicast is not to worry about problems caused > by success until you actually have something like success. > > Regards > Marshall > > > On Jan 23, 2006, at 6:11 PM, Lea Roberts wrote: > >> so do you gentlemen believe that we should allow unlimited >> allocation of >> IPv6 PI space to whomever wants to multihome and just consider the >> possible routing table scaling problems to be something that will be >> dealt with later? and you also don't worry about carrying over the >> "IPv4 >> early adopter bonus" into the brave new IPv6 world? assuming of >> course >> that the policy might have to be more restrictive later? >> >> just curious, /Lea >> >> On Mon, 23 Jan 2006, Bill Woodcock wrote: >> >>> On Mon, 23 Jan 2006, Howard, W. Lee wrote: >>>>> Well, the last PP 2005-1 was completely unworkable. I >>>>> supported it because >>>>> it was better than nothing - but only barely. (Many) People >>>>> who voted for it >>>>> were holding their noses and voting yes in the hope of >>>>> improving it later. >>> >>> Yup, that's certainly true of me, and of everyone else I know who >>> voted >>> for it. It wasn't acceptable as voted, but there was nothing else >>> on the >>> table, and nothing else we could vote for. Yes, that's a really >>> major >>> problem. >>> >>>> That puts us in a difficult position. The process says we can >>>> only ratify a policy is there is evidence of consensus. The >>>> only exception would be in case of an emergency, and I think >>>> we're a couple of years from an emergency. >>> >>> I think we're a couple of years into an emergency. >>> >>> -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 > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From lea.roberts at stanford.edu Mon Jan 23 21:50:43 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 23 Jan 2006 18:50:43 -0800 (PST) Subject: [ppml] whither 2005-1 (was: Policy without consensus? ) In-Reply-To: <313A7142-4214-41BB-BE80-3476EF870C00@multicasttech.com> Message-ID: hi Marshall - (I'm putting 2005-1 back in the subject line for later subject searches :-) On Mon, 23 Jan 2006, Marshall Eubanks wrote: > I would care more, at present at least, that the IPv6 routing table > actually get USED. At present, it is, what, 1% of the total ? I don't believe it should be the case that address allocation policy should be developed to encourage the deployment of a protocol. However, it is reasonable to do our best to not discourage deployment either... there are lots of opinons at play here and trying to find the consensus course is not easy. as I'm sure you know well, the current allocation policy is the result of the IAB/IESG recommendations in RFC3177. as far as I know, the IETF oriented folks are still concerned about routing table growth and many were the ones who objected to the original 2005-1 proposal. there was a flurry of discussion on the RIPE IPv6 list lately regarding the perceived need for more IPv6 PI space, but I'm not sure they've reached any consensus either. > One thing we learned in multicast is not to worry about problems caused > by success until you actually have something like success. I guess part of the question is whether IPv6 can be judged a success just because it works as "IPv4 with bigger addresses".... sorry, /Lea > Regards > Marshall > > > On Jan 23, 2006, at 6:11 PM, Lea Roberts wrote: > > > so do you gentlemen believe that we should allow unlimited > > allocation of > > IPv6 PI space to whomever wants to multihome and just consider the > > possible routing table scaling problems to be something that will be > > dealt with later? and you also don't worry about carrying over the > > "IPv4 > > early adopter bonus" into the brave new IPv6 world? assuming of > > course > > that the policy might have to be more restrictive later? > > > > just curious, /Lea > > > > On Mon, 23 Jan 2006, Bill Woodcock wrote: > > > >> On Mon, 23 Jan 2006, Howard, W. Lee wrote: > >>>> Well, the last PP 2005-1 was completely unworkable. I > >>>> supported it because > >>>> it was better than nothing - but only barely. (Many) People > >>>> who voted for it > >>>> were holding their noses and voting yes in the hope of > >>>> improving it later. > >> > >> Yup, that's certainly true of me, and of everyone else I know who > >> voted > >> for it. It wasn't acceptable as voted, but there was nothing else > >> on the > >> table, and nothing else we could vote for. Yes, that's a really > >> major > >> problem. > >> > >>> That puts us in a difficult position. The process says we can > >>> only ratify a policy is there is evidence of consensus. The > >>> only exception would be in case of an emergency, and I think > >>> we're a couple of years from an emergency. > >> > >> I think we're a couple of years into an emergency. > >> > >> -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 tme at multicasttech.com Mon Jan 23 21:52:46 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 23 Jan 2006 21:52:46 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <639526E5-DB48-4CF7-8947-F4B1EA97ACB2@multicasttech.com> Easy The experiment has been run. Something you basically never get to do in the real world, run a test case, has been done courtesy of IPv4. And it works and hasn't caused problems. The original 2005-1 matches the existing IPv4 model closely, so the burden should be on those who want to change it, to show that their plans will work and not cause problems or undue burdens. Without working code for SHIM6, I do not see how that can be done. (I am not saying that that is sufficient, just necessary.) Thus, my question. Regards Marshall On Jan 23, 2006, at 9:53 PM, Bill Darte wrote: > And I would request that alternatives posed should establish to the > extent > possible why this alternative is necessary or best suited to be the > consensus model. > > Bill Darte > ARIN AC > > > I would agree. However, 2005-1 did not reach consensus, so we need to > come up with an alternative that's more likely to do so. I would love > to > hear what exactly everyone thinks is an appropriate standard for > allocating IPv6 PI space so we can better gauge what would be a > consensus > position. > > -Scott > > > > On 01/23/06 at 9:01pm -0500, Marshall Eubanks > wrote: > >> I cannot predict what might happen hundreds of years from now. >> >> I can say, however, that 2002-3 has not caused an explosion in the >> routing table for IPv4, nor >> would I expect that 2005-1 would do so for IPv6. >> >> Regards >> Marshall >> >> On Jan 23, 2006, at 4:10 PM, Lea Roberts wrote: >> >>> because, as I'm sure you remember, Bill, the routing table won't > scale >>> over the lifetime of v6 >>> >>> On Mon, 23 Jan 2006, Bill Darte wrote: >>> >>>> OK, I'll start.... >>>> >>>> Why should the criteria for PI in v6 be ANY different than with v4? >>>> What was large under v4 is somehow not large under v6 apparently? >>>> Turn in you v4 PI block for a v6 PI block. >>>> >>>> That's probably a sufficiently high level argument to begin the >>>> discussion. >>>> >>>> Bill Darte >>>> ARIN AC >>>> >>>> >>>>> -----Original Message----- >>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>>> Behalf Of Lea Roberts >>>>> Sent: Monday, January 23, 2006 3:01 PM >>>>> To: Owen DeLong >>>>> Cc: ppml at arin.net >>>>> Subject: Re: [ppml] 2005-1 status >>>>> >>>>> >>>>> well, seems like maybe we should talk it out here (again... >>>>> :-) for a while. this sounds more like a "PI for everyone" >>>>> policy. while I'm sure there's a large number of people who >>>>> would like that, I still think it's unlikely it can reach >>>>> consensus... >>>>> >>>>> As I said at the meeting in L.A., I still think it is >>>>> possible to reach consensus for PI assignments for large >>>>> organizations and I thought that's where we were still headed >>>>> after the last meeting., i.e. trying to find criteria that >>>>> the latest round of objectors could live with. >>>>> >>>>> let the discussion begin! /Lea >>>>> >>>>> On Mon, 23 Jan 2006, Owen DeLong wrote: >>>>> >>>>>> Kevin, >>>>>> Why don't you, Lea, and I take this off line and decide >>>>>> what to present back to the group. I apologize for not having >>>>>> followed up in a more timely manner after the last meeting. >>>>>> >>>>>> Owen >>>>>> >>>>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: >>>>>> >>>>>>> Marshall Eubanks wrote: >>>>>>>> Hello; >>>>>>>> >>>>>>>> When last I saw it, 2005-1 was to be reformatted to >>>>> something more >>>>>>>> like its original version. >>>>>>> >>>>>>> These were my suggestions using feedback from the last meeting: >>>>>>> >>>>>>> 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". >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>>> >>>>>>>> Can someone tell me what the status of 2005-1 is currently ? >>>>>>> >>>>>>> As far as I know it hasn't changed since the last meeting. >>>>>>> Obviously it should be updated one way or another. I >>>>> would gladly >>>>>>> write up a formal revision or new proposal if requested. >>>>>>> >>>>>>> - Kevin >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> _______________________________________________ >> 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 dgolding at burtongroup.com Mon Jan 23 21:55:11 2006 From: dgolding at burtongroup.com (Daniel Golding) Date: Mon, 23 Jan 2006 21:55:11 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <6.2.0.14.2.20060124092523.02ba0120@kahuna.telstra.net> Message-ID: On 1/23/06 6:20 PM, "Geoff Huston" wrote: > At 08:18 AM 24/01/2006, Daniel Golding wrote: > >> That is proof by assertion. The routing table has grown relatively slowly, > > Relative to what? Well, there's not too much I can compare it with, but earlier cries of doom and disaster have largely proven false. See: discussion regarding RFC2547 VPNs, for example. > >> and there is NO reason to think it will grow faster under IPv6. > [snip] Ok, let me be clear - I don't think there are inherent properties of the IPv6 protocol suite that will cause more folks to multihome during a given time interval. Organizations multihome for business reasons, and those drivers will be similar regardless of the underlying protocol. > > -- Daniel Golding From lea.roberts at stanford.edu Mon Jan 23 21:58:56 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 23 Jan 2006 18:58:56 -0800 (PST) Subject: [ppml] wither 2005-1 (was: Policy without consensus?) In-Reply-To: Message-ID: (still trying to get 2005-1 back in the title... :-) On Mon, 23 Jan 2006, Daniel Golding wrote: > > We may have to change routing paradigms at some point. When we approach that > scaling limit, it can be considered and examined. We are busy worrying about > being able to route the entire IPv6 space. The funny thing is, unless there > is a reasonable allocation policy, IPv6 will end up on the dust heap of > history. > > Some folks assume that enterprises are willing to swallow a lack of PI space > and multihoming. Wrong - they are not and will not now or in the future. > They buy carrier services - and they will not buy IPv6 services without PI > space and true multihoming. > If we can't allocate IPv6 space to enterprises, then its time to scrap IPv6 > and start again. There is really no middle case in the real world. I think this was the one clear lesson from Orlando and why I felt that the first step for 2005-1 would be to address large organizations. maybe there's not even consensus there, but I had hoped... sorry, /Lea > - Daniel Golding > > On 1/23/06 9:24 PM, "Marshall Eubanks" wrote: > > > I would care more, at present at least, that the IPv6 routing table > > actually get USED. At present, it is, what, 1% of the total ? > > > > One thing we learned in multicast is not to worry about problems caused > > by success until you actually have something like success. > > > > Regards > > Marshall > > > > > > On Jan 23, 2006, at 6:11 PM, Lea Roberts wrote: > > > >> so do you gentlemen believe that we should allow unlimited > >> allocation of > >> IPv6 PI space to whomever wants to multihome and just consider the > >> possible routing table scaling problems to be something that will be > >> dealt with later? and you also don't worry about carrying over the > >> "IPv4 > >> early adopter bonus" into the brave new IPv6 world? assuming of > >> course > >> that the policy might have to be more restrictive later? > >> > >> just curious, /Lea > >> > >> On Mon, 23 Jan 2006, Bill Woodcock wrote: > >> > >>> On Mon, 23 Jan 2006, Howard, W. Lee wrote: > >>>>> Well, the last PP 2005-1 was completely unworkable. I > >>>>> supported it because > >>>>> it was better than nothing - but only barely. (Many) People > >>>>> who voted for it > >>>>> were holding their noses and voting yes in the hope of > >>>>> improving it later. > >>> > >>> Yup, that's certainly true of me, and of everyone else I know who > >>> voted > >>> for it. It wasn't acceptable as voted, but there was nothing else > >>> on the > >>> table, and nothing else we could vote for. Yes, that's a really > >>> major > >>> problem. > >>> > >>>> That puts us in a difficult position. The process says we can > >>>> only ratify a policy is there is evidence of consensus. The > >>>> only exception would be in case of an emergency, and I think > >>>> we're a couple of years from an emergency. > >>> > >>> I think we're a couple of years into an emergency. > >>> > >>> -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 > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > From tme at multicasttech.com Mon Jan 23 22:13:38 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 23 Jan 2006 22:13:38 -0500 Subject: [ppml] whither 2005-1 (was: Policy without consensus? ) In-Reply-To: References: Message-ID: <7A015384-1A42-43C0-BC07-6B5F6C716D5B@multicasttech.com> On Jan 23, 2006, at 9:50 PM, Lea Roberts wrote: > hi Marshall - > > (I'm putting 2005-1 back in the subject line for later subject > searches :-) > > On Mon, 23 Jan 2006, Marshall Eubanks wrote: > >> I would care more, at present at least, that the IPv6 routing table >> actually get USED. At present, it is, what, 1% of the total ? > > I don't believe it should be the case that address allocation policy > should be developed to encourage the deployment of a protocol. > However, > it is reasonable to do our best to not discourage deployment either... > there are lots of opinons at play here and trying to find the > consensus > course is not easy. > > as I'm sure you know well, the current allocation policy is the > result of > the IAB/IESG recommendations in RFC3177. as far as I know, the IETF > oriented folks are still concerned about routing table growth and many > were the ones who objected to the original 2005-1 proposal. there > was a I am an IETF oriented folk myself, and I have been down this road before. This, my comments re Multicast. We spent way too much time worrying about problems of success; as (relative) success is coming, it isn't coming in the way that we worried about. Just an observation. Marshall > flurry of discussion on the RIPE IPv6 list lately regarding the > perceived > need for more IPv6 PI space, but I'm not sure they've reached any > consensus either. > >> One thing we learned in multicast is not to worry about problems >> caused >> by success until you actually have something like success. > > I guess part of the question is whether IPv6 can be judged a > success just > because it works as "IPv4 with bigger addresses".... sorry, /Lea > >> Regards >> Marshall >> >> >> On Jan 23, 2006, at 6:11 PM, Lea Roberts wrote: >> >>> so do you gentlemen believe that we should allow unlimited >>> allocation of >>> IPv6 PI space to whomever wants to multihome and just consider the >>> possible routing table scaling problems to be something that will be >>> dealt with later? and you also don't worry about carrying over the >>> "IPv4 >>> early adopter bonus" into the brave new IPv6 world? assuming of >>> course >>> that the policy might have to be more restrictive later? >>> >>> just curious, /Lea >>> >>> On Mon, 23 Jan 2006, Bill Woodcock wrote: >>> >>>> On Mon, 23 Jan 2006, Howard, W. Lee wrote: >>>>>> Well, the last PP 2005-1 was completely unworkable. I >>>>>> supported it because >>>>>> it was better than nothing - but only barely. (Many) People >>>>>> who voted for it >>>>>> were holding their noses and voting yes in the hope of >>>>>> improving it later. >>>> >>>> Yup, that's certainly true of me, and of everyone else I know who >>>> voted >>>> for it. It wasn't acceptable as voted, but there was nothing else >>>> on the >>>> table, and nothing else we could vote for. Yes, that's a really >>>> major >>>> problem. >>>> >>>>> That puts us in a difficult position. The process says we can >>>>> only ratify a policy is there is evidence of consensus. The >>>>> only exception would be in case of an emergency, and I think >>>>> we're a couple of years from an emergency. >>>> >>>> I think we're a couple of years into an emergency. >>>> >>>> -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 tme at multicasttech.com Mon Jan 23 22:15:52 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 23 Jan 2006 22:15:52 -0500 Subject: [ppml] wither 2005-1 (was: Policy without consensus?) In-Reply-To: References: Message-ID: Hello; On Jan 23, 2006, at 9:58 PM, Lea Roberts wrote: > (still trying to get 2005-1 back in the title... :-) > > On Mon, 23 Jan 2006, Daniel Golding wrote: > >> >> We may have to change routing paradigms at some point. When we >> approach that >> scaling limit, it can be considered and examined. We are busy >> worrying about >> being able to route the entire IPv6 space. The funny thing is, >> unless there >> is a reasonable allocation policy, IPv6 will end up on the dust >> heap of >> history. >> >> Some folks assume that enterprises are willing to swallow a lack >> of PI space >> and multihoming. Wrong - they are not and will not now or in the >> future. >> They buy carrier services - and they will not buy IPv6 services >> without PI >> space and true multihoming. > >> If we can't allocate IPv6 space to enterprises, then its time to >> scrap IPv6 >> and start again. There is really no middle case in the real world. > > I think this was the one clear lesson from Orlando and why I felt > that the > first step for 2005-1 would be to address large organizations. maybe > there's not even consensus there, but I had hoped... sorry, /Lea > My feeling is that the lack consensus was caused primarily by those who thought that this was not enough. I could be wrong... Marshall >> - Daniel Golding >> >> On 1/23/06 9:24 PM, "Marshall Eubanks" wrote: >> >>> I would care more, at present at least, that the IPv6 routing table >>> actually get USED. At present, it is, what, 1% of the total ? >>> >>> One thing we learned in multicast is not to worry about problems >>> caused >>> by success until you actually have something like success. >>> >>> Regards >>> Marshall >>> >>> >>> On Jan 23, 2006, at 6:11 PM, Lea Roberts wrote: >>> >>>> so do you gentlemen believe that we should allow unlimited >>>> allocation of >>>> IPv6 PI space to whomever wants to multihome and just consider the >>>> possible routing table scaling problems to be something that >>>> will be >>>> dealt with later? and you also don't worry about carrying over the >>>> "IPv4 >>>> early adopter bonus" into the brave new IPv6 world? assuming of >>>> course >>>> that the policy might have to be more restrictive later? >>>> >>>> just curious, /Lea >>>> >>>> On Mon, 23 Jan 2006, Bill Woodcock wrote: >>>> >>>>> On Mon, 23 Jan 2006, Howard, W. Lee wrote: >>>>>>> Well, the last PP 2005-1 was completely unworkable. I >>>>>>> supported it because >>>>>>> it was better than nothing - but only barely. (Many) People >>>>>>> who voted for it >>>>>>> were holding their noses and voting yes in the hope of >>>>>>> improving it later. >>>>> >>>>> Yup, that's certainly true of me, and of everyone else I know who >>>>> voted >>>>> for it. It wasn't acceptable as voted, but there was nothing else >>>>> on the >>>>> table, and nothing else we could vote for. Yes, that's a really >>>>> major >>>>> problem. >>>>> >>>>>> That puts us in a difficult position. The process says we can >>>>>> only ratify a policy is there is evidence of consensus. The >>>>>> only exception would be in case of an emergency, and I think >>>>>> we're a couple of years from an emergency. >>>>> >>>>> I think we're a couple of years into an emergency. >>>>> >>>>> -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 >>> >>> _______________________________________________ >>> PPML mailing list >>> PPML at arin.net >>> http://lists.arin.net/mailman/listinfo/ppml >> >> > From lea.roberts at stanford.edu Mon Jan 23 22:26:47 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 23 Jan 2006 19:26:47 -0800 (PST) Subject: [ppml] whither 2005-1 (was: Policy without consensus?) In-Reply-To: Message-ID: (I wonder if the "wither" was a Freudian slip... :-) On Mon, 23 Jan 2006, Marshall Eubanks wrote: > Hello; > > On Jan 23, 2006, at 9:58 PM, Lea Roberts wrote: > > > (still trying to get 2005-1 back in the title... :-) > > > > On Mon, 23 Jan 2006, Daniel Golding wrote: > > > >> > >> We may have to change routing paradigms at some point. When we > >> approach that > >> scaling limit, it can be considered and examined. We are busy > >> worrying about > >> being able to route the entire IPv6 space. The funny thing is, > >> unless there > >> is a reasonable allocation policy, IPv6 will end up on the dust > >> heap of > >> history. > >> > >> Some folks assume that enterprises are willing to swallow a lack > >> of PI space > >> and multihoming. Wrong - they are not and will not now or in the > >> future. > >> They buy carrier services - and they will not buy IPv6 services > >> without PI > >> space and true multihoming. > > > >> If we can't allocate IPv6 space to enterprises, then its time to > >> scrap IPv6 > >> and start again. There is really no middle case in the real world. > > > > I think this was the one clear lesson from Orlando and why I felt > > that the > > first step for 2005-1 would be to address large organizations. maybe > > there's not even consensus there, but I had hoped... sorry, /Lea > > > > My feeling is that the lack consensus was caused primarily by those > who thought that this was not enough. > I could be wrong... > In Orlando we heard from the "this is too much" folks... In L.A. we heard from the "this is too restrictive" folks... if the pendulum swings all the way back, I fear the "this is too much" folks will once again step up to the mics... maybe I'm wrong and the time is right for those of you who believe that there should be "equal" policies between IPv4 and IPv6? we'll see, I guess, /Lea > Marshall > > >> - Daniel Golding > >> > >> On 1/23/06 9:24 PM, "Marshall Eubanks" wrote: > >> > >>> I would care more, at present at least, that the IPv6 routing table > >>> actually get USED. At present, it is, what, 1% of the total ? > >>> > >>> One thing we learned in multicast is not to worry about problems > >>> caused > >>> by success until you actually have something like success. > >>> > >>> Regards > >>> Marshall > >>> > >>> > >>> On Jan 23, 2006, at 6:11 PM, Lea Roberts wrote: > >>> > >>>> so do you gentlemen believe that we should allow unlimited > >>>> allocation of > >>>> IPv6 PI space to whomever wants to multihome and just consider the > >>>> possible routing table scaling problems to be something that > >>>> will be > >>>> dealt with later? and you also don't worry about carrying over the > >>>> "IPv4 > >>>> early adopter bonus" into the brave new IPv6 world? assuming of > >>>> course > >>>> that the policy might have to be more restrictive later? > >>>> > >>>> just curious, /Lea > >>>> > >>>> On Mon, 23 Jan 2006, Bill Woodcock wrote: > >>>> > >>>>> On Mon, 23 Jan 2006, Howard, W. Lee wrote: > >>>>>>> Well, the last PP 2005-1 was completely unworkable. I > >>>>>>> supported it because > >>>>>>> it was better than nothing - but only barely. (Many) People > >>>>>>> who voted for it > >>>>>>> were holding their noses and voting yes in the hope of > >>>>>>> improving it later. > >>>>> > >>>>> Yup, that's certainly true of me, and of everyone else I know who > >>>>> voted > >>>>> for it. It wasn't acceptable as voted, but there was nothing else > >>>>> on the > >>>>> table, and nothing else we could vote for. Yes, that's a really > >>>>> major > >>>>> problem. > >>>>> > >>>>>> That puts us in a difficult position. The process says we can > >>>>>> only ratify a policy is there is evidence of consensus. The > >>>>>> only exception would be in case of an emergency, and I think > >>>>>> we're a couple of years from an emergency. > >>>>> > >>>>> I think we're a couple of years into an emergency. > >>>>> > >>>>> -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 > >>> > >>> _______________________________________________ > >>> PPML mailing list > >>> PPML at arin.net > >>> http://lists.arin.net/mailman/listinfo/ppml > >> > >> > > > From gih at apnic.net Mon Jan 23 22:37:35 2006 From: gih at apnic.net (Geoff Huston) Date: Tue, 24 Jan 2006 14:37:35 +1100 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <6.2.0.14.2.20060124143249.02ba3298@kahuna.telstra.net> There is pressure for consolidation in the existing markets, yes. At the same time I suspect that the level of provider care and attention to some of the common issues, including routing table size will decline due to the price pressures on the providers. We saw in V4 that the most basic form of routing bloat pressure was from inattention to routing detail - these folk were in general not malicious - they were simply following the templates left by the original installers. This is certainly a more significant risk factor in an increasingly commoditized provider environment. (Its not that they won't care, but they they'll find it harder to fund caring) regards, Geoff At 01:04 PM 24/01/2006, Bill Darte wrote: >Geoff, >I'm interested in knowing whether you think that the consolidation of >providers in a global commodity market for vX bit pushing will impact the >routing table 'bloat'.....assuming you think that consolidation is a logical >consequence of the commodity of bit pushing....assuming you think bit >pushing IS a commodity. >Didn't mean to make a riddle out of this.. > >Geoff said: >Given that there are few natural constraints to routing table bloat >other than an advanced state of social consciousness, the drivers for IPv6 >routing table bloat appear to include a vastly larger end device >population and a commodity utility provider structure that cares little >about spending time (and money) to take measures to avoid routing table >expansion. >That would appear to constitute grounds for thinking that, yes, >there is a distinct risk of IPv6 route table bloat at levels greater >than we've seen in IPv4. From paul at vix.com Mon Jan 23 23:34:56 2006 From: paul at vix.com (Paul Vixie) Date: Tue, 24 Jan 2006 04:34:56 +0000 Subject: [ppml] whither 2005-1 (was: Policy without consensus? ) In-Reply-To: Your message of "Mon, 23 Jan 2006 22:13:38 EST." <7A015384-1A42-43C0-BC07-6B5F6C716D5B@multicasttech.com> References: <7A015384-1A42-43C0-BC07-6B5F6C716D5B@multicasttech.com> Message-ID: <20060124043456.B307B11425@sa.vix.com> # I am an IETF oriented folk myself, and I have been down this road before. # This, my comments re Multicast. We spent way too much time worrying about # problems of success; as (relative) success is coming, it isn't coming in the # way that we worried about. # # Just an observation. one way of interpreting these remarks is "multicast is still not in wide interdomain use because its creators held it back until they could figure out a deployable model". another is "multicast is still not in wide interdomain use today because its creators never found a deployable model." i could agree, and simultaneously disagree, with either interpretation. but i'm wondering-- marshall, what exactly do you mean here? if one has to choose among types of disasters, we would mostly all prefer a success disaster to a failure disaster. but what if we won't WANT a disaster? From tme at multicasttech.com Tue Jan 24 00:22:09 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 24 Jan 2006 00:22:09 -0500 Subject: [ppml] whither 2005-1 (was: Policy without consensus? ) In-Reply-To: <20060124043456.B307B11425@sa.vix.com> References: <7A015384-1A42-43C0-BC07-6B5F6C716D5B@multicasttech.com> <20060124043456.B307B11425@sa.vix.com> Message-ID: <5F2B15AC-0EB6-4585-8588-D501741C4532@multicasttech.com> Hello; On Jan 23, 2006, at 11:34 PM, Paul Vixie wrote: > # I am an IETF oriented folk myself, and I have been down this road > before. > # This, my comments re Multicast. We spent way too much time > worrying about > # problems of success; as (relative) success is coming, it isn't > coming in the > # way that we worried about. > # > # Just an observation. > > one way of interpreting these remarks is "multicast is still not in > wide > interdomain use because its creators held it back until they could > figure > out a deployable model". > > another is "multicast is still not in wide interdomain use today > because > its creators never found a deployable model." > > i could agree, and simultaneously disagree, with either > interpretation. > but i'm wondering-- marshall, what exactly do you mean here? > Neither, exactly. I would not agree with the former, and the latter is not entirely true. A lot of cycles were spun worrying about things that never happened. That was just my point. If you want my opinion, here it is : Multicasting, round 1, (DVMRP MBone) never found wide interdomain use because it just wasn't suitable. In some sense, though, I think it came closest to universal deployment. And it made Mark Cuban $ 6 billion USD or so. Multicasting, round 2 (PIM ASM) didn't find wide interdomain use because the service model has problems (ASM's and MSDP's sensitivity to interference and DOS attacks, and difficulty in actually getting it to work reliably interdomain). The timing was really bad too (just late enough that the money from the dot com boom primarily went to unicast streaming). Multicasting, round 3 (SSM and IGMP v3) . Now we are seeing lots of "walled garden" deployment of multicast. It's mostly ASM. It will move into SSM in the next few years. My personal feeling is that the walls of the gardens will eventually be breached by the implications of Zipf's law, but that remains to be seen. Note that SSM was finalized in Adelaide, just about 6 years ago. And it is still not universally available ! (IGMPv3 support not in every OS, not in most applications, and not in most IGMP snooping switches). I would guess than there are ~3 years to go there before it can just be assumed. I see no reason why SSM / MBGP can't be generally deployed, but it is taking a long time. It takes a long time to change things at the routing layer in the 21st century. Be careful what you put into millions of boxes, as it will take a long time to change it. > if one has to choose among types of disasters, we would mostly all > prefer > a success disaster to a failure disaster. but what if we won't WANT a > disaster? I have come to realize that new protocols have a certain amount of political capital. The balance of multicast is pretty depleted at present, even though usage is accelerating. Going from IGMPv2 to v3 in the way that was done was a big hit IMHO because it required both OS and edge box upgrades. A lot of the work on BGMP (not MBGP) and the related MADCAP address allocation stuff (deployed in Windows and never used) also burned up political capital with no real benefit. We had better not need to change anything in multicast now, as it will be real hard to get anything new into OS's and hardware IMHO. Fortunately, I don't see anything needed at present. What I see in IPv6 is a tiny amount of actual deployment (considerably smaller than inter-domain multicast), with a strong possibility that anything that really needs it will be a walled garden (the IPv6 as a super kind of NAT idea). If small entities want to multihome, I think that should be encouraged. Regards Marshall > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From christopher.morrow at gmail.com Tue Jan 24 01:49:00 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Tue, 24 Jan 2006 06:49:00 +0000 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <75cb24520601232249v46cf93a8yc70771bace6d9115@mail.gmail.com> On 1/24/06, Bill Darte wrote: > > From: Scott Leibrand > > So with that in mind, I would argue that ARIN's IPv6 PI policy should > encourage small multihomed sites to use a non-PI multihoming model > (shim6) > while preserving the ability for large multihomed sites to get PI space > and multihome the traditional way. > > Is that a consensus position? If not, which aspect of it do you > disagree with, and why? > > Scott, I'd say that placing a special burden on small operations, and SHIM6 > from my limited observations seems like a very 'special' burden, to allow > them to multihome whereas their larger counterparts can avoid the same > burden with PI...well THAT is what needs to be justified, seems to me. > I'd point out something here, that might not need pointing out explicitly, shim6 MAY only work if both sides of the conversation decide to use the protocol. So, if your small office situation (dsl and cablemodem connected and shim6 enabled) starts/tries to do shim6 with a 'content provider' site that has PI space and doesn't know from shim6 (some content providers, akamai, use strange kernel tweaks/os-tweaks and likely won't support shim6 'features' early on) doesn't shim6 isn't going to provide the multihoming and failover and TE (perhaps) it should be providing. I'd venture to guess it'll be a whole lot less useful than even it's proponents wish it would be, with the situation above in mind atleast :( -Chris From christopher.morrow at gmail.com Tue Jan 24 02:05:08 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Tue, 24 Jan 2006 07:05:08 +0000 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <75cb24520601232305s40104356l4aaf139389305a96@mail.gmail.com> On 1/24/06, Bill Woodcock wrote: > > I see no reason why the assignment policies > > should be different and I see a strong demand for multi-homing. > > Agreed, with the exception that I'd like to see a small block allocated > for swamp prefixes. So, basically... decide on some bit boundary for 'small site' (non-provider) PI assignments (call it /44 for arguements sake), and chop those out of some /16 (again /16 for arguement sake) of v6? Everyone gets to decide to accept /44's from this /16 and <=/32 from all other v6 space? Then decide what requirements would have to be met for v6 PI assignment, and why that should be any different than the policies for v4. In my opinion, there will be a need, in the short-term atleast, for PI space. There are plenty of folks (22k or so in the route table today) that are using PI and an ASN and BGP. Is ownership/use of an ASN qualification enough? The last policy (2005-1 I believe) had some wording about 'size' (100k devices it was?) Does that need to exist? Or, how should you quanitfy site size? -Chris From drc at virtualized.org Tue Jan 24 02:12:05 2006 From: drc at virtualized.org (David Conrad) Date: Mon, 23 Jan 2006 23:12:05 -0800 Subject: [ppml] Policy without consensus? In-Reply-To: References: Message-ID: <95D10010-231D-47D4-9F27-7010D7E0BE9C@virtualized.org> Hi, On Jan 23, 2006, at 6:49 PM, Daniel Golding wrote: > We may have to change routing paradigms at some point. Or we could stop pretending the existing routing paradigm can be ignored. > When we approach that > scaling limit, it can be considered and examined. In such a scenario, I imagine one concern would be how to deal with all the swamp of legacy IPv6 allocations. > We are busy worrying about > being able to route the entire IPv6 space. I really don't think anyone is worried about that. > The funny thing is, unless there > is a reasonable allocation policy, IPv6 will end up on the dust > heap of > history. Not that it matters, but I haven't been convinced that allocation policy is what has been holding back IPv6 deployment. > Some folks assume that enterprises are willing to swallow a lack of > PI space > and multihoming. Wrong - they are not and will not now or in the > future. Well, they have been in the IPv4 world. > They buy carrier services - and they will not buy IPv6 services > without PI > space and true multihoming. I might put it differently. If IPv6 service provided PI/true multihoming, something they have difficulty getting in IPv4, they might buy IPv6 services. SHIM6 could, in theory, provide PI/true multihoming, although one might argue it is approximately equivalent to starting the IPv6 code deployment from scratch. > If we can't allocate IPv6 space to enterprises, then its time to > scrap IPv6 > and start again. It isn't a question of IPv6 per se, after all, IPv6 is just how (a large number of) bits are organized. The real question is that of routing technology and routing policy. IPv6 uses CIDR and provider- based addressing, just like IPv4. Enterprises are (presumably) leaf nodes in the provider-based routing graph. Allocating PI space to enterprises is promoting leaf nodes to the highest level of routing graph. If you want to do flat routing, that is fine, but people will complain that it won't scale (and it won't), although where scalability bites you is, as always, open to discussion. > There is really no middle case in the real world. Sure there is. In my experience, most businesses generally don't have either the time nor the interest for architectural purity, religion, or the perfect solution. They just want stuff to work "good enough". -drc -------- My opinions are my own and do not necessarily represent the opinions of any organization I may be a part of. So there. From owen at delong.com Tue Jan 24 02:52:21 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 23 Jan 2006 23:52:21 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: We should at least learn some lessons from previous routing scalability problems. Personally, I do not believe the routing table growth problem will ever be solved until we separate the routing identifier from the end system identifier. However, until that is done, we have to look at IPv6 as it stands. What seems to be lost on a lot of the people who keep declaring that the sky will fall in if we open up IPv6 allocations is that when CIDR was first implemented, the following promises were essentially made to the internet community by the IETF and the ISPs in order to gain compliance and cooperation in implementing CIDR: 1. NAT where you can, please. This is a temporary hack to get us by until IPv6 solves these problems. 2. IPv6 renumbering will be quick, simple, painless, and, therefore PI space will be unnecessary. 3. Please use PA space wherever possible for now. We understand that it reduces the usefulness of internet routing for your business, but, crashing the core routers because they run out of table memory will reduce it a whole lot more. 4. IPv6 will make PA space as useful as PI space is today in IPv4, so, this is a temporary problem. Of these, the only one that has really been kept is number 1. Since number 2 was not delivered, and, number 3 is really just the same fear campaign (which was quite legitimate at the time, don't get me wrong), number 4 really isn't true either. Result: A large constituency of internet users is no longer willing to accept the tradeoffs of PA. Migration to IPv6 will not proceed beyond early adopter until such time as these issues are addressed by some method. Router vendors like the idea of a PA only internet because it is one less problem they have to solve going forward. ISPs like the idea of a PA only internet because it simplifies their topology and provides a barrier to churn. Customers like PI space because it removes the barrier to churn and allows for better and more reliable multihoming in the current environment. SHIM6 is complicated and has substantial multilateral dependencies, if it ever reaches fruition. (Customers is basically the combination of Enterprise, Business, and sophisticated Home constituencies). Given these competing interests, combined with the relative overrepresentation of hardware vendors and ISPs both on the list and at most ARIN meetings, I'm not sure how we can make progress on this issue or what the best ARIN policy could be. When I started on this process, I did so primarily with the intent of getting the debate out in the public view. I'd like to see good policy come out of it in the end, but, I don't know whether that will be possible. Owen On Jan 23, 2006, at 1:18 PM, Daniel Golding wrote: > > That is proof by assertion. The routing table has grown relatively > slowly, > and there is NO reason to think it will grow faster under IPv6. The > argument > seems to be that IPv6 will have a much longer lifetime than IPv4, > so we have > to plan for 20 or 50 years from now. > > Trying to plan past 10 or so years in technology seems foolish. We > can't > imagine what technology will be like in 50 years. We may be > approaching a > technological singularity, making such projections useless > (Kurzweil, et > al), or the Internet may look completely different by then. > > I understand where the hardware vendors are coming from. Given > that, I think > we need to take it with a grain of salt. > > - Dan > > On 1/23/06 4:10 PM, "Lea Roberts" wrote: > >> because, as I'm sure you remember, Bill, the routing table won't >> scale >> over the lifetime of v6 >> >> On Mon, 23 Jan 2006, Bill Darte wrote: >> >>> OK, I'll start.... >>> >>> Why should the criteria for PI in v6 be ANY different than with v4? >>> What was large under v4 is somehow not large under v6 apparently? >>> Turn in you v4 PI block for a v6 PI block. >>> >>> That's probably a sufficiently high level argument to begin the >>> discussion. >>> >>> Bill Darte >>> ARIN AC >>> >>> >>>> -----Original Message----- >>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>> Behalf Of Lea Roberts >>>> Sent: Monday, January 23, 2006 3:01 PM >>>> To: Owen DeLong >>>> Cc: ppml at arin.net >>>> Subject: Re: [ppml] 2005-1 status >>>> >>>> >>>> well, seems like maybe we should talk it out here (again... >>>> :-) for a while. this sounds more like a "PI for everyone" >>>> policy. while I'm sure there's a large number of people who >>>> would like that, I still think it's unlikely it can reach >>>> consensus... >>>> >>>> As I said at the meeting in L.A., I still think it is >>>> possible to reach consensus for PI assignments for large >>>> organizations and I thought that's where we were still headed >>>> after the last meeting., i.e. trying to find criteria that >>>> the latest round of objectors could live with. >>>> >>>> let the discussion begin! /Lea >>>> >>>> On Mon, 23 Jan 2006, Owen DeLong wrote: >>>> >>>>> Kevin, >>>>> Why don't you, Lea, and I take this off line and decide >>>>> what to present back to the group. I apologize for not having >>>>> followed up in a more timely manner after the last meeting. >>>>> >>>>> Owen >>>>> >>>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: >>>>> >>>>>> Marshall Eubanks wrote: >>>>>>> Hello; >>>>>>> >>>>>>> When last I saw it, 2005-1 was to be reformatted to >>>> something more >>>>>>> like its original version. >>>>>> >>>>>> These were my suggestions using feedback from the last meeting: >>>>>> >>>>>> 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". >>>>>> >>>>>> 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. >>>>>> >>>>>>> >>>>>>> Can someone tell me what the status of 2005-1 is currently ? >>>>>> >>>>>> As far as I know it hasn't changed since the last meeting. >>>>>> Obviously it should be updated one way or another. I >>>> would gladly >>>>>> write up a formal revision or new proposal if requested. >>>>>> >>>>>> - Kevin >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Tue Jan 24 03:32:41 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Jan 2006 00:32:41 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: <047324C6-C4C8-4FD8-9A9B-5A71B654D671@multicasttech.com> Message-ID: <7500A276-E652-4534-9495-5AA8B286375F@delong.com> There is a collection of constituents which is >5 which believes that after seeing the rewrites to 2005-1 presented in LA, the original 2005-1 is more likely to achieve consensus and should be revoted. If I see something resembling consensus coming out of the PPML discussion, I will work with Kevin and Lea to produce a new version of 2005-1 that I think is more in line with that consensus. If not, I'll suggest we go with Kevin's proposal presented on PPML earlier today. There are some things I don't like in it (I'm not sure I agree with penalizing early adopters just because they happen to have legacy blocks), but, I can live with it. Owen On Jan 23, 2006, at 6:08 PM, Scott Leibrand wrote: > I would agree. However, 2005-1 did not reach consensus, so we need to > come up with an alternative that's more likely to do so. I would > love to > hear what exactly everyone thinks is an appropriate standard for > allocating IPv6 PI space so we can better gauge what would be a > consensus > position. > > -Scott > > On 01/23/06 at 9:01pm -0500, Marshall Eubanks > wrote: > >> I cannot predict what might happen hundreds of years from now. >> >> I can say, however, that 2002-3 has not caused an explosion in the >> routing table for IPv4, nor >> would I expect that 2005-1 would do so for IPv6. >> >> Regards >> Marshall >> >> On Jan 23, 2006, at 4:10 PM, Lea Roberts wrote: >> >>> because, as I'm sure you remember, Bill, the routing table won't >>> scale >>> over the lifetime of v6 >>> >>> On Mon, 23 Jan 2006, Bill Darte wrote: >>> >>>> OK, I'll start.... >>>> >>>> Why should the criteria for PI in v6 be ANY different than with v4? >>>> What was large under v4 is somehow not large under v6 apparently? >>>> Turn in you v4 PI block for a v6 PI block. >>>> >>>> That's probably a sufficiently high level argument to begin the >>>> discussion. >>>> >>>> Bill Darte >>>> ARIN AC >>>> >>>> >>>>> -----Original Message----- >>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>>> Behalf Of Lea Roberts >>>>> Sent: Monday, January 23, 2006 3:01 PM >>>>> To: Owen DeLong >>>>> Cc: ppml at arin.net >>>>> Subject: Re: [ppml] 2005-1 status >>>>> >>>>> >>>>> well, seems like maybe we should talk it out here (again... >>>>> :-) for a while. this sounds more like a "PI for everyone" >>>>> policy. while I'm sure there's a large number of people who >>>>> would like that, I still think it's unlikely it can reach >>>>> consensus... >>>>> >>>>> As I said at the meeting in L.A., I still think it is >>>>> possible to reach consensus for PI assignments for large >>>>> organizations and I thought that's where we were still headed >>>>> after the last meeting., i.e. trying to find criteria that >>>>> the latest round of objectors could live with. >>>>> >>>>> let the discussion begin! /Lea >>>>> >>>>> On Mon, 23 Jan 2006, Owen DeLong wrote: >>>>> >>>>>> Kevin, >>>>>> Why don't you, Lea, and I take this off line and decide >>>>>> what to present back to the group. I apologize for not having >>>>>> followed up in a more timely manner after the last meeting. >>>>>> >>>>>> Owen >>>>>> >>>>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: >>>>>> >>>>>>> Marshall Eubanks wrote: >>>>>>>> Hello; >>>>>>>> >>>>>>>> When last I saw it, 2005-1 was to be reformatted to >>>>> something more >>>>>>>> like its original version. >>>>>>> >>>>>>> These were my suggestions using feedback from the last meeting: >>>>>>> >>>>>>> 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". >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>>> >>>>>>>> Can someone tell me what the status of 2005-1 is currently ? >>>>>>> >>>>>>> As far as I know it hasn't changed since the last meeting. >>>>>>> Obviously it should be updated one way or another. I >>>>> would gladly >>>>>>> write up a formal revision or new proposal if requested. >>>>>>> >>>>>>> - Kevin >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> _______________________________________________ >> 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 Michael.Dillon at btradianz.com Tue Jan 24 04:49:14 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 24 Jan 2006 09:49:14 +0000 Subject: [ppml] 2005-1 status In-Reply-To: Message-ID: > Why should the criteria for PI in v6 be ANY different than with v4? > What was large under v4 is somehow not large under v6 apparently? > Turn in you v4 PI block for a v6 PI block. OK, assuming that we accept this, the only additional thing that needs to be decided is what size of v6 PI block to give. Why should the method of sizing these v6 blocks be ANY different than the existing method of sizing v6 blocks? Either these applicants are LIRs and get a /32 or they are not and they get a /48 unless they can show that they are VERY LARGE SUBSCRIBERS. This is in accord with the existing v6 policy. Since the proposal is to change the existing policy, it really should be clear about which bits are being changed and why those changes are justified. --Michael Dillon From Michael.Dillon at btradianz.com Tue Jan 24 04:52:14 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 24 Jan 2006 09:52:14 +0000 Subject: [ppml] 2005-1 status In-Reply-To: Message-ID: > I like what Kevin had to say: You get IPv6 if you have IPv4 space now, or > you are BGP multihomed, you should be able to request IPv6. BGP multihoming is the current operationally deployed technology for IPv6 multihoming. If we are treating IPv6 as an operationally deployed technology then our policy making must recognize the CURRENT OPERATIONAL REALITIES. --Michael Dillon From Michael.Dillon at btradianz.com Tue Jan 24 04:56:35 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 24 Jan 2006 09:56:35 +0000 Subject: [ppml] 2005-1 status In-Reply-To: Message-ID: > so we have > to plan for 20 or 50 years from now. > > Trying to plan past 10 or so years in technology seems foolish. We can't > imagine what technology will be like in 50 years. One thing we do know is that if we make a mistake there will be time to recognize and fix the mistake. Unless there is hard proof that a decision WILL (not might) lead to a problem in the next few years, then we should go ahead with the decision. If a decision MIGHT cause a problem, then an experimental fram of mind would cause us to go ahead with the decision in order to measure the results and see if there really is cause for concern. This is inherent in the design of IPv6 because the designers set aside 7/8ths of the address space for a future rethink of how addressing (and presumably routing) should work. --Michael Dillon From Michael.Dillon at btradianz.com Tue Jan 24 05:05:34 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 24 Jan 2006 10:05:34 +0000 Subject: [ppml] Policy without consensus? In-Reply-To: Message-ID: > so do you gentlemen believe that we should allow unlimited allocation of > IPv6 PI space to whomever wants to multihome and just consider the > possible routing table scaling problems to be something that will be > dealt with later? Unless someone presents QUANTITATIVE information demonstrating a real route scaling problem then I do not believe that there is such a problem. Let us not forget that IPv6 route table scaling is NOT THE SAME AS IPV4 route table scaling. It is a completely different problem. For one thing, very few ASes will need more than a single IPv6 allocation. For another thing, there is a way out for organizations that feel pain. They can use IPv4 instead. This is an option that did not exist in the IPv4 Internet. We don't HAVE TO make policy in a vacuum. If it is important to have hard facts before us then we can simply refuse to make new policy until someone does the research and presents the facts. The IPv4 Internet was a success precisely because three groups of people worked closely together supporting each other. Vendors, network operators and RESEARCHERS each applied their strengths to the problems of scaling the IPv4 Internet. We need the same kind of support in the IPv6 Internet, in particular the support from researchers. --Michael Dillon From billd at cait.wustl.edu Tue Jan 24 08:23:31 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 24 Jan 2006 07:23:31 -0600 Subject: [ppml] 2005-1 status Message-ID: > There is pressure for consolidation in the existing markets, > yes. At the > same time I suspect that the level of provider care and > attention to some > of the common issues, including routing table size will > decline due to the > price pressures on the providers. We saw in V4 that the most > basic form of > routing bloat pressure was from inattention to routing detail > - these folk > were in general not malicious - they were simply following > the templates > left by the original installers. This is certainly a more > significant risk > factor in an increasingly commoditized provider environment. > (Its not that > they won't care, but they they'll find it harder to fund caring) > > regards, > > Geoff So, my interpretation of your views is that in the short term there will be upward pressure on the size of router table due to provider inexperience and distraction, but in the longer term these inefficiencies will be swept away by the consolidation of providers due to the commoditization of global communications. Is it reasonable to think that significan consolidation will happen over the 15 years? Imagining, just for the sake of argument, that the ensuing oligopoly is represented by 12 'super' providers and a few thousands of niche, value added, local providers....what then would be the impact on the router table given common practice (BGP)? > > > > > At 01:04 PM 24/01/2006, Bill Darte wrote: > >Geoff, > >I'm interested in knowing whether you think that the > consolidation of > >providers in a global commodity market for vX bit pushing > will impact > >the routing table 'bloat'.....assuming you think that > consolidation is > >a logical consequence of the commodity of bit > pushing....assuming you > >think bit pushing IS a commodity. Didn't mean to make a > riddle out of > >this.. > > > >Geoff said: > >Given that there are few natural constraints to routing table bloat > >other than an advanced state of social consciousness, the > drivers for > >IPv6 routing table bloat appear to include a vastly larger > end device > >population and a commodity utility provider structure that > cares little > >about spending time (and money) to take measures to avoid > routing table > >expansion. That would appear to constitute grounds for > thinking that, > >yes, there is a distinct risk of IPv6 route table bloat at levels > >greater than we've seen in IPv4. > > From billd at cait.wustl.edu Tue Jan 24 09:00:54 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 24 Jan 2006 08:00:54 -0600 Subject: [ppml] 2005-1 status Message-ID: > > > Why should the criteria for PI in v6 be ANY different than with v4? > > What was large under v4 is somehow not large under v6 > apparently? Turn > > in you v4 PI block for a v6 PI block. > > OK, assuming that we accept this, the only additional > thing that needs to be decided is what size of v6 PI > block to give. > > Why should the method of sizing these v6 blocks be > ANY different than the existing method of sizing > v6 blocks? Either these applicants are LIRs and > get a /32 or they are not and they get a /48 unless > they can show that they are VERY LARGE SUBSCRIBERS. I assume you mean v4 in your second reference in the above paragraph? I don't think the argument is about PI block size. Rather, it is about making PI space available to end-sites...Only once that hurdle is crossed, can a discussion of PI block size be entertained and given that the current size for PA to end-sites starts at a base of /48 and gets larger with justification, there may be no issue. bd > > This is in accord with the existing v6 policy. Since > the proposal is to change the existing policy, it really > should be clear about which bits are being changed and > why those changes are justified. > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From Lee.Howard at stanleyassociates.com Tue Jan 24 10:01:33 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 24 Jan 2006 10:01:33 -0500 Subject: [ppml] 2005-1 (was: Re: Policy without consensus?) Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB401221080@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Daniel Golding > Sent: Monday, January 23, 2006 9:50 PM > To: Marshall Eubanks; Lea Roberts > Cc: PPML > Subject: Re: [ppml] Policy without consensus? > > > We may have to change routing paradigms at some point. When > we approach that > scaling limit, it can be considered and examined. We are busy > worrying about > being able to route the entire IPv6 space. The funny thing > is, unless there > is a reasonable allocation policy, IPv6 will end up on the > dust heap of history. I see my role in policy development as avoiding disaster, not protecting legacies. > Some folks assume that enterprises are willing to swallow a > lack of PI space > and multihoming. Wrong - they are not and will not now or in > the future. As an enterprise network manager, I do not expect PI space. I do expect the ability to mulithome, and the ability to renumber should I change providers. PI space is, at best, a "nice to have." > They buy carrier services - and they will not buy IPv6 > services without PI space and true multihoming. I need reliable connectivity. To me, that means multihoming. PI space would be one way to ease transitions in multihoming, but good design and tools from major vendors would be enough. Lee > - Daniel Golding From Michael.Dillon at btradianz.com Tue Jan 24 10:17:43 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 24 Jan 2006 15:17:43 +0000 Subject: [ppml] 2005-1 status In-Reply-To: Message-ID: > > Why should the method of sizing these v6 blocks be > > ANY different than the existing method of sizing > > v6 blocks? Either these applicants are LIRs and > > get a /32 or they are not and they get a /48 unless > > they can show that they are VERY LARGE SUBSCRIBERS. > > I assume you mean v4 in your second reference in the above paragraph? No, I mean v6 where I wrote v6. > I don't think the argument is about PI block size. Rather, it is about > making PI space available to end-sites...Only once that hurdle is crossed, > can a discussion of PI block size be entertained and given that the current > size for PA to end-sites starts at a base of /48 and gets larger with > justification, there may be no issue. Right, there are two hurdles here. The first one is whether or not ARIN should give v6 PI allocations to organizations who currently have v4 PI allocations. Once that hurdle is crossed, we need to decide how big these PI allocations should be. Noting that the v6 policy gives out /32 blocks to LIRs, i.e. organizations that have an ironclad case for PI space, I wonder why 2005-1 does not specify a /32. Of course, the v6 policy also discusses assigning /48 blocks to sites so if these v4 PI holders are a single site, then /48 would be appropriate. The existing policy only allows for shorter prefixes like /44 in the case of VERY LARGE SUBSCRIBERS. So, the existing policy defines a world in which there are lots of /32 routes globally, lots of /48 routes in a more local context (one provider's IBGP) and no other prefix lengths. Do we have a good reason to add a new standard prefix size to the mix? If so, then what are the criteria for defining this size? I think that too many policy proposals come before us without adequate explanation of their relation to the existing policy set and without adequate explanation for the specific things that they change. There is too much off-the-cuff proposal writing and off-the-cuff analysis of proposals. It's all well and good to have a higher motivation like enabling existing v4 PI users to get v6 PI space with no fuss. But the details have to be thought through and explained and justified. Note, that I have not stated whether I am for or against 2005-1. That is not the point. I am trying to steer the discussion away from joining one camp or another and get to the meat of the matter. This is not party politics. This is technical policymaking. --Michael Dillon From billd at cait.wustl.edu Tue Jan 24 10:37:12 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 24 Jan 2006 09:37:12 -0600 Subject: [ppml] 2005-1 (was: Re: Policy without consensus?) Message-ID: > > Some folks assume that enterprises are willing to swallow a > > lack of PI space > > and multihoming. Wrong - they are not and will not now or in > > the future. > > As an enterprise network manager, I do not expect PI space. I > do expect the ability to mulithome, and the ability to renumber > should I change providers. PI space is, at best, a "nice to > have." Lee, the ability to renumber would be there whether you have a dozen hosts or a million. The requirement is that you can renumber in a manner that does not compromise your ability to maintain business continuity without significant costs (various kinds)... Multihoming gives you connectivity reliability or helps. Ease of renumbering or PI space gives you performance liability by ensuring that connectivity competition exists for you. Assuming multihoming, in the absence of that flexibility, who compensates you for the loss? If BIG guys get that benefit and little guys can effectively renumber without duress, it's the middle guy who gets screwed. If no one gets PI space, then the little guy is the only one to escape. Multihoming and flexibility to choose among providers are a requirements to move to v6 for most I think, unless v4 address depletion causes crisis, seems to me. > > > They buy carrier services - and they will not buy IPv6 > > services without PI space and true multihoming. > > I need reliable connectivity. To me, that means multihoming. > PI space would be one way to ease transitions in multihoming, > but good design and tools from major vendors would be enough. > > Lee > > > > - Daniel Golding > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From Lee.Howard at stanleyassociates.com Tue Jan 24 11:00:38 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 24 Jan 2006 11:00:38 -0500 Subject: [ppml] 2005-1 (was: Re: Policy without consensus?) Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4012210D8@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: Bill Darte [mailto:billd at cait.wustl.edu] > Sent: Tuesday, January 24, 2006 10:37 AM > To: Howard, W. Lee > Cc: PPML > Subject: RE: [ppml] 2005-1 (was: Re: Policy without consensus?) > > > > > Some folks assume that enterprises are willing to swallow a > > > lack of PI space > > > and multihoming. Wrong - they are not and will not now or in > > > the future. > > > > As an enterprise network manager, I do not expect PI space. I > > do expect the ability to mulithome, and the ability to renumber > > should I change providers. PI space is, at best, a "nice to > > have." > > Lee, the ability to renumber would be there whether you have > a dozen hosts or a million. The requirement is that you can renumber in a > manner that does not compromise your ability to maintain business > continuity without significant costs (various kinds)... Yes, that's a clearer statement of the requirement. I need to be able to renumber fast enough that my whole network isn't down. I can declare a maint window, but I can't manually renumber a few thousand hosts in that time. I can hit a few routers and/or DHCP servers, and several static servers. > Multihoming gives you connectivity reliability or helps. > Ease of renumbering or PI space gives you performance > liability by ensuring > that connectivity competition exists for you. > > Assuming multihoming, in the absence of that flexibility, who > compensates > you for the loss? If BIG guys get that benefit and little guys can > effectively renumber without duress, it's the middle guy who > gets screwed. > If no one gets PI space, then the little guy is the only one > to escape. > > Multihoming and flexibility to choose among providers are a > requirements to > move to v6 for most I think, unless v4 address depletion > causes crisis, seems to me. I agree with everything you say. The requirement is for me to be able to change providers. PI allocations are not the only way to do that. Lee From Lee.Howard at stanleyassociates.com Tue Jan 24 11:09:23 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 24 Jan 2006 11:09:23 -0500 Subject: [ppml] 2005-1 status Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4012210E3@CL-S-EX-1.stanleyassociates.com> Bill Darte said: > Imagining, just for the sake of argument, that the ensuing > oligopoly is > represented by 12 'super' providers and a few thousands of > niche, value > added, local providers....what then would be the impact on > the router table given common practice (BGP)? I'm not sure it's relevant to the policy proposal, but I'm not sure the question has been asked: Does de-aggregating for traffic engineering play a part? I've never been a traffic engineer. Looks to me like BGP is designed with lots of knobs to determine how bits flow away from you, but fewer knobs to determine how bits flow toward you, none of which extends beyond the neighbor AS (unless they choose to propagate). With multiple neighbor ASes with different policies, the only tool is to deaggregate announcements in careful ways. Is this characterization accurate? Should engineers be able to determine how traffic flows toward them? Will the need for traffic engineering by deaggregation be a major pressure on routing table size in the future? Lee From kloch at hotnic.net Tue Jan 24 11:11:42 2006 From: kloch at hotnic.net (Kevin Loch) Date: Tue, 24 Jan 2006 11:11:42 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <43D651BE.8060202@hotnic.net> Michael.Dillon at btradianz.com wrote: > Noting that the v6 policy gives out /32 blocks to > LIRs, i.e. organizations that have an ironclad case > for PI space, I wonder why 2005-1 does not specify > a /32. Of course, the v6 policy also discusses > assigning /48 blocks to sites so if these v4 PI > holders are a single site, then /48 would be appropriate. > The existing policy only allows for shorter prefixes > like /44 in the case of VERY LARGE SUBSCRIBERS. We're proposing a new cagetory of assignments distinct from LIR's and simple end sites. This would not change the existing policy for LIR's or simple end sites. I look at potential v6 PI holders as somewhere between simple end sites and LIR's. They may be large organizations with multiple physical locations, assigning /48's to internal units. Think of them as an "internal" LIR, justified by many physical locations. Others may be simple multihomed sites so assigning a /32 would be wasteful. Another reason to make the minimum size larger than /48 is to make it easy to distinguish between PI assignments and deaggregated PA /48's. In the future that could be extremely useful. > > So, the existing policy defines a world in which there > are lots of /32 routes globally, lots of /48 routes > in a more local context (one provider's IBGP) and > no other prefix lengths. /32 and /48 are "generous minimums", not fixed boundaries. I see a virtual continuum of prefix lengths in my table today, some RIR assigned, some deaggregated. There was alot of discussion at the last meeting about the negative aspects of fixed boundaries, or even the illusion of fixed boundaries. I don't see the benefit of taking it all the way down to single bits, but nibble boundaries seem reasonable/practical. > Do we have a good reason to add a new standard prefix > size to the mix? If so, then what are the criteria > for defining this size? I'd rather not do "standard prefixes". I think /44 is a reasonable (generous?) minimum for PI and allow larger sizes where they can be justified. - Kevin From packetgrrl at gmail.com Tue Jan 24 11:19:45 2006 From: packetgrrl at gmail.com (cja@daydream.com) Date: Tue, 24 Jan 2006 09:19:45 -0700 Subject: [ppml] 2005-1 status In-Reply-To: <43D651BE.8060202@hotnic.net> References: <43D651BE.8060202@hotnic.net> Message-ID: On 1/24/06, Kevin Loch wrote: > > Michael.Dillon at btradianz.com wrote: > > Noting that the v6 policy gives out /32 blocks to > > LIRs, i.e. organizations that have an ironclad case > > for PI space, I wonder why 2005-1 does not specify > > a /32. Of course, the v6 policy also discusses > > assigning /48 blocks to sites so if these v4 PI > > holders are a single site, then /48 would be appropriate. > > The existing policy only allows for shorter prefixes > > like /44 in the case of VERY LARGE SUBSCRIBERS. > > We're proposing a new cagetory of assignments > distinct from LIR's and simple end sites. This would > not change the existing policy for LIR's or simple > end sites. > > I look at potential v6 PI holders as somewhere between > simple end sites and LIR's. They may > be large organizations with multiple physical locations, > assigning /48's to internal units. Think of them > as an "internal" LIR, justified by many physical locations. > Others may be simple multihomed sites so assigning a /32 > would be wasteful. > > Another reason to make the minimum size larger than /48 > is to make it easy to distinguish between PI assignments > and deaggregated PA /48's. In the future that could be > extremely useful. We should be distingushing prefixes based on assignment block ranges not by length of prefix. Prefixes size should be decided based on appropriate need, not on differentiating PA from PI based on prefix length. ---Cathy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlw+arin at tellme.com Tue Jan 24 11:50:22 2006 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 24 Jan 2006 08:50:22 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <20060124165022.GS6015@shell01.corp.tellme.com> On Mon, Jan 23, 2006 at 11:52:21PM -0800, Owen DeLong wrote: > We should at least learn some lessons from previous routing scalability > problems. Some of us have! > Result: A large constituency of internet users is no longer willing > to accept the tradeoffs of PA. Migration to IPv6 will not proceed > beyond early adopter until such time as these issues are addressed > by some method. I believe this to be an extraordinary statement that everyone needs to read twice. This is the basic truth in this argument. Until those segments of the population fighting to keep the IPv6 Internet PA only realize that the vast majority of end sites have no interest in anything *but* PI space, we will simply continue to see this argument rehashed. I'm definitely waiting for PI space, and I suspect many other end sites will continue to wait until we can get reasonable policy in place. -David From kloch at hotnic.net Tue Jan 24 11:52:22 2006 From: kloch at hotnic.net (Kevin Loch) Date: Tue, 24 Jan 2006 11:52:22 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: <43D651BE.8060202@hotnic.net> Message-ID: <43D65B46.9060907@hotnic.net> cja at daydream.com wrote: > We should be distingushing prefixes based on assignment block ranges not > by length of prefix. Experience shows that assignment block range discriminators are not nearly as practical as prefix length discriminators. Look at the trouble people have with bogon filters. This is not to imply that anyone should or should not filter prefixes based on any crieteria. That is really not the RIR's business. However, just as I believe RIR's should make efforts to "not prevent" aggregation (as opposed to mandating it), we should see this opportunity to "not prevent" practical filtering. Especially when the cost is minimal. Plus there are other reasons already stated for making the minimum assignment larger than /48. - Kevin From dlw+arin at tellme.com Tue Jan 24 11:52:44 2006 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 24 Jan 2006 08:52:44 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: <43D651BE.8060202@hotnic.net> Message-ID: <20060124165244.GT6015@shell01.corp.tellme.com> On Tue, Jan 24, 2006 at 09:19:45AM -0700, cja at daydream.com wrote: > We should be distingushing prefixes based on assignment block ranges not by > length of prefix. Prefixes size should be decided based on appropriate > need, not on differentiating PA from PI based on prefix length. I agree. Prefix length is an accident of allocation or sub-allocation policy, which may be very localized. Specific prefixes will be identifiable as PA or PI only based on their block...I don't see any utility in even trying to differentiate prefixes based on length. I'd much prefer if we focus on making allocations of correct size for the need, rather than trying to be clever where it isn't necessary or won't work. -David From terry.l.davis at boeing.com Tue Jan 24 13:18:16 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Tue, 24 Jan 2006 10:18:16 -0800 Subject: [ppml] Policy without consensus? Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21B981@XCH-NW-8V1.nw.nos.boeing.com> Daniel/Marshall I agree with your position! Unless we find a reasonable way to allocate IP-v6 address space, IP-v6 is going nowhere here in the US! No major corporation CIO is likely to sign off on developing a major network infrastructure that will involve ultimately million of dollars and then be forced to rely on a single ISP to provide all their addresses and thus accept essentially a perpetual service contract with that provider. (Their view but I tend to agree...) I'm not even sure that a single ISP provider would pass a Sarbannes-Oxley audit anymore given the focus on "business continuity". Take care Terry L Davis Boeing Technical Fellow -----Original Message----- From: Daniel Golding [mailto:dgolding at burtongroup.com] Sent: Monday, January 23, 2006 6:50 PM To: Marshall Eubanks; Lea Roberts Cc: PPML Subject: Re: [ppml] Policy without consensus? We may have to change routing paradigms at some point. When we approach that scaling limit, it can be considered and examined. We are busy worrying about being able to route the entire IPv6 space. The funny thing is, unless there is a reasonable allocation policy, IPv6 will end up on the dust heap of history. Some folks assume that enterprises are willing to swallow a lack of PI space and multihoming. Wrong - they are not and will not now or in the future. They buy carrier services - and they will not buy IPv6 services without PI space and true multihoming. If we can't allocate IPv6 space to enterprises, then its time to scrap IPv6 and start again. There is really no middle case in the real world. - Daniel Golding On 1/23/06 9:24 PM, "Marshall Eubanks" wrote: > I would care more, at present at least, that the IPv6 routing table > actually get USED. At present, it is, what, 1% of the total ? > > One thing we learned in multicast is not to worry about problems caused > by success until you actually have something like success. > > Regards > Marshall > > > On Jan 23, 2006, at 6:11 PM, Lea Roberts wrote: > >> so do you gentlemen believe that we should allow unlimited >> allocation of >> IPv6 PI space to whomever wants to multihome and just consider the >> possible routing table scaling problems to be something that will be >> dealt with later? and you also don't worry about carrying over the >> "IPv4 >> early adopter bonus" into the brave new IPv6 world? assuming of >> course >> that the policy might have to be more restrictive later? >> >> just curious, /Lea >> >> On Mon, 23 Jan 2006, Bill Woodcock wrote: >> >>> On Mon, 23 Jan 2006, Howard, W. Lee wrote: >>>>> Well, the last PP 2005-1 was completely unworkable. I >>>>> supported it because >>>>> it was better than nothing - but only barely. (Many) People >>>>> who voted for it >>>>> were holding their noses and voting yes in the hope of >>>>> improving it later. >>> >>> Yup, that's certainly true of me, and of everyone else I know who >>> voted >>> for it. It wasn't acceptable as voted, but there was nothing else >>> on the >>> table, and nothing else we could vote for. Yes, that's a really >>> major >>> problem. >>> >>>> That puts us in a difficult position. The process says we can >>>> only ratify a policy is there is evidence of consensus. The >>>> only exception would be in case of an emergency, and I think >>>> we're a couple of years from an emergency. >>> >>> I think we're a couple of years into an emergency. >>> >>> -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 > > _______________________________________________ > 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 william at elan.net Tue Jan 24 13:52:11 2006 From: william at elan.net (william(at)elan.net) Date: Tue, 24 Jan 2006 10:52:11 -0800 (PST) Subject: [ppml] Policy without consensus? In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21B981@XCH-NW-8V1.nw.nos.boeing.com> References: <0D090F1E0F5536449C7E6527AFFA280A21B981@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: Well said. I entire agree with Terry. On Tue, 24 Jan 2006, Davis, Terry L wrote: > Daniel/Marshall > > I agree with your position! Unless we find a reasonable way to allocate > IP-v6 address space, IP-v6 is going nowhere here in the US! > > No major corporation CIO is likely to sign off on developing a major > network infrastructure that will involve ultimately million of dollars > and then be forced to rely on a single ISP to provide all their > addresses and thus accept essentially a perpetual service contract with > that provider. (Their view but I tend to agree...) I'm not even sure > that a single ISP provider would pass a Sarbannes-Oxley audit anymore > given the focus on "business continuity". > > Take care > Terry L Davis > Boeing Technical Fellow From sleibrand at internap.com Tue Jan 24 14:59:38 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 24 Jan 2006 14:59:38 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: <75cb24520601232249v46cf93a8yc70771bace6d9115@mail.gmail.com> References: <75cb24520601232249v46cf93a8yc70771bace6d9115@mail.gmail.com> Message-ID: On 01/24/06 at 6:49am -0000, Christopher Morrow I'd point out something here, that might not need pointing out > explicitly, shim6 MAY only work if both sides of the conversation > decide to use the protocol. It's not news (to me at least) but it's worth discussing. :) > So, if your small office situation (dsl and cablemodem connected and > shim6 enabled) starts/tries to do shim6 with a 'content provider' site > that has PI space and doesn't know from shim6 (some content providers, > akamai, use strange kernel tweaks/os-tweaks and likely won't support > shim6 'features' early on) doesn't shim6 isn't going to provide the > multihoming and failover and TE (perhaps) it should be providing. I would maintain that shim6 *support* and shim6 *use* are somewhat different things. For example, suppose that new OS versions start shipping with shim6 support enabled by default, but configured not to actually use shim6 by default. In that case, the default behavior would be to never initiate shim6 compatibility negotiation, but to accept shim6 initiation requests from peers. If a client is multihomed with multiple addresses per host, and needs/wants shim6, they can change the defaults to initiate shim6. In addition, much of the traffic to large akamaized websites may not need shim6 capabilities. It's really only needed for longer-lived sessions. Connectivity to the average website isn't really impeded by a change in the client's IP address because the average TCP session is so short. > I'd venture to guess it'll be a whole lot less useful than even it's > proponents wish it would be, with the situation above in mind atleast > :( That may be so, but IMO that's because it's only needed in a minority of cases, the ones where sessions are long-lived. But I think that with shim6 support, RFC3484 extensions for source address selection, and implementation of simple source-based routing to avoid tripping strict uRPF filters, multihoming can indeed be a possibility for end users and small sites who can't afford to run BGP. Call me naive, but I think that once the protocols are finalized and end users start to get access to IPv6, there will be enough demand for such functionality that it will be included by default in IPv6 stacks going forward. -Scott From sleibrand at internap.com Tue Jan 24 15:29:45 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 24 Jan 2006 15:29:45 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: <639526E5-DB48-4CF7-8947-F4B1EA97ACB2@multicasttech.com> References: <639526E5-DB48-4CF7-8947-F4B1EA97ACB2@multicasttech.com> Message-ID: I would agree that IPv6 PI space should be made available to anyone who qualifies for IPv4 PI space. 2005-1 as presented at L.A. was a bit more restrictive than that, with the 100,000 device requirement. No, I don't think there is any working shim6 code. However, as I've tried to say before, I think shim6 will provide a multihoming solution to those who've thus far not had one available. IMO such a solution, if widely implemented, would likely be better for small sites than trying to run BGP. -Scott On 01/23/06 at 9:52pm -0500, Marshall Eubanks wrote: > Easy > > The experiment has been run. Something you basically never get to do in > the real world, run a test case, has been done courtesy of IPv4. And it > works and hasn't caused problems. > > The original 2005-1 matches the existing IPv4 model closely, so the > burden should be on those who want to > change it, to show that their plans will work and not cause problems > or undue burdens. > > Without working code for SHIM6, I do not see how that can be done. (I > am not saying that that is sufficient, just necessary.) Thus, my > question. > > Regards > Marshall > > > > > On Jan 23, 2006, at 9:53 PM, Bill Darte wrote: > > > And I would request that alternatives posed should establish to the > > extent > > possible why this alternative is necessary or best suited to be the > > consensus model. > > > > Bill Darte > > ARIN AC > > > > > > I would agree. However, 2005-1 did not reach consensus, so we need to > > come up with an alternative that's more likely to do so. I would love > > to > > hear what exactly everyone thinks is an appropriate standard for > > allocating IPv6 PI space so we can better gauge what would be a > > consensus > > position. > > > > -Scott > > > > > > > > On 01/23/06 at 9:01pm -0500, Marshall Eubanks > > wrote: > > > >> I cannot predict what might happen hundreds of years from now. > >> > >> I can say, however, that 2002-3 has not caused an explosion in the > >> routing table for IPv4, nor > >> would I expect that 2005-1 would do so for IPv6. > >> > >> Regards > >> Marshall > >> > >> On Jan 23, 2006, at 4:10 PM, Lea Roberts wrote: > >> > >>> because, as I'm sure you remember, Bill, the routing table won't > > scale > >>> over the lifetime of v6 > >>> > >>> On Mon, 23 Jan 2006, Bill Darte wrote: > >>> > >>>> OK, I'll start.... > >>>> > >>>> Why should the criteria for PI in v6 be ANY different than with v4? > >>>> What was large under v4 is somehow not large under v6 apparently? > >>>> Turn in you v4 PI block for a v6 PI block. > >>>> > >>>> That's probably a sufficiently high level argument to begin the > >>>> discussion. > >>>> > >>>> Bill Darte > >>>> ARIN AC > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > >>>>> Behalf Of Lea Roberts > >>>>> Sent: Monday, January 23, 2006 3:01 PM > >>>>> To: Owen DeLong > >>>>> Cc: ppml at arin.net > >>>>> Subject: Re: [ppml] 2005-1 status > >>>>> > >>>>> > >>>>> well, seems like maybe we should talk it out here (again... > >>>>> :-) for a while. this sounds more like a "PI for everyone" > >>>>> policy. while I'm sure there's a large number of people who > >>>>> would like that, I still think it's unlikely it can reach > >>>>> consensus... > >>>>> > >>>>> As I said at the meeting in L.A., I still think it is > >>>>> possible to reach consensus for PI assignments for large > >>>>> organizations and I thought that's where we were still headed > >>>>> after the last meeting., i.e. trying to find criteria that > >>>>> the latest round of objectors could live with. > >>>>> > >>>>> let the discussion begin! /Lea > >>>>> > >>>>> On Mon, 23 Jan 2006, Owen DeLong wrote: > >>>>> > >>>>>> Kevin, > >>>>>> Why don't you, Lea, and I take this off line and decide > >>>>>> what to present back to the group. I apologize for not having > >>>>>> followed up in a more timely manner after the last meeting. > >>>>>> > >>>>>> Owen > >>>>>> > >>>>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: > >>>>>> > >>>>>>> Marshall Eubanks wrote: > >>>>>>>> Hello; > >>>>>>>> > >>>>>>>> When last I saw it, 2005-1 was to be reformatted to > >>>>> something more > >>>>>>>> like its original version. > >>>>>>> > >>>>>>> These were my suggestions using feedback from the last meeting: > >>>>>>> > >>>>>>> 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". > >>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>>>> > >>>>>>>> Can someone tell me what the status of 2005-1 is currently ? > >>>>>>> > >>>>>>> As far as I know it hasn't changed since the last meeting. > >>>>>>> Obviously it should be updated one way or another. I > >>>>> would gladly > >>>>>>> write up a formal revision or new proposal if requested. > >>>>>>> > >>>>>>> - Kevin > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >> > >> _______________________________________________ > >> 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 tme at multicasttech.com Tue Jan 24 15:34:47 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 24 Jan 2006 15:34:47 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: <639526E5-DB48-4CF7-8947-F4B1EA97ACB2@multicasttech.com> Message-ID: Hello; On Jan 24, 2006, at 3:29 PM, Scott Leibrand wrote: > I would agree that IPv6 PI space should be made available to anyone > who > qualifies for IPv4 PI space. 2005-1 as presented at L.A. was a bit > more > restrictive than that, with the 100,000 device requirement. Yes, thus the proposal to go back to the original 2005-1. (Shouldn't these have version #s?) > > No, I don't think there is any working shim6 code. However, as > I've tried > to say before, I think shim6 will provide a multihoming solution to > those > who've thus far not had one available. IMO such a solution, if widely > implemented, would likely be better for small sites than trying to run > BGP. > Sure. We can certainly revisit this once that day comes. > -Scott Marshall > > On 01/23/06 at 9:52pm -0500, Marshall Eubanks > wrote: > >> Easy >> >> The experiment has been run. Something you basically never get to >> do in >> the real world, run a test case, has been done courtesy of IPv4. >> And it >> works and hasn't caused problems. >> >> The original 2005-1 matches the existing IPv4 model closely, so the >> burden should be on those who want to >> change it, to show that their plans will work and not cause problems >> or undue burdens. >> >> Without working code for SHIM6, I do not see how that can be done. (I >> am not saying that that is sufficient, just necessary.) Thus, my >> question. >> >> Regards >> Marshall >> >> >> >> >> On Jan 23, 2006, at 9:53 PM, Bill Darte wrote: >> >>> And I would request that alternatives posed should establish to the >>> extent >>> possible why this alternative is necessary or best suited to be the >>> consensus model. >>> >>> Bill Darte >>> ARIN AC >>> >>> >>> I would agree. However, 2005-1 did not reach consensus, so we >>> need to >>> come up with an alternative that's more likely to do so. I would >>> love >>> to >>> hear what exactly everyone thinks is an appropriate standard for >>> allocating IPv6 PI space so we can better gauge what would be a >>> consensus >>> position. >>> >>> -Scott >>> >>> >>> >>> On 01/23/06 at 9:01pm -0500, Marshall Eubanks >>> >>> wrote: >>> >>>> I cannot predict what might happen hundreds of years from now. >>>> >>>> I can say, however, that 2002-3 has not caused an explosion in the >>>> routing table for IPv4, nor >>>> would I expect that 2005-1 would do so for IPv6. >>>> >>>> Regards >>>> Marshall >>>> >>>> On Jan 23, 2006, at 4:10 PM, Lea Roberts wrote: >>>> >>>>> because, as I'm sure you remember, Bill, the routing table won't >>> scale >>>>> over the lifetime of v6 >>>>> >>>>> On Mon, 23 Jan 2006, Bill Darte wrote: >>>>> >>>>>> OK, I'll start.... >>>>>> >>>>>> Why should the criteria for PI in v6 be ANY different than >>>>>> with v4? >>>>>> What was large under v4 is somehow not large under v6 apparently? >>>>>> Turn in you v4 PI block for a v6 PI block. >>>>>> >>>>>> That's probably a sufficiently high level argument to begin the >>>>>> discussion. >>>>>> >>>>>> Bill Darte >>>>>> ARIN AC >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>>>>> Behalf Of Lea Roberts >>>>>>> Sent: Monday, January 23, 2006 3:01 PM >>>>>>> To: Owen DeLong >>>>>>> Cc: ppml at arin.net >>>>>>> Subject: Re: [ppml] 2005-1 status >>>>>>> >>>>>>> >>>>>>> well, seems like maybe we should talk it out here (again... >>>>>>> :-) for a while. this sounds more like a "PI for everyone" >>>>>>> policy. while I'm sure there's a large number of people who >>>>>>> would like that, I still think it's unlikely it can reach >>>>>>> consensus... >>>>>>> >>>>>>> As I said at the meeting in L.A., I still think it is >>>>>>> possible to reach consensus for PI assignments for large >>>>>>> organizations and I thought that's where we were still headed >>>>>>> after the last meeting., i.e. trying to find criteria that >>>>>>> the latest round of objectors could live with. >>>>>>> >>>>>>> let the discussion begin! /Lea >>>>>>> >>>>>>> On Mon, 23 Jan 2006, Owen DeLong wrote: >>>>>>> >>>>>>>> Kevin, >>>>>>>> Why don't you, Lea, and I take this off line and decide >>>>>>>> what to present back to the group. I apologize for not having >>>>>>>> followed up in a more timely manner after the last meeting. >>>>>>>> >>>>>>>> Owen >>>>>>>> >>>>>>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: >>>>>>>> >>>>>>>>> Marshall Eubanks wrote: >>>>>>>>>> Hello; >>>>>>>>>> >>>>>>>>>> When last I saw it, 2005-1 was to be reformatted to >>>>>>> something more >>>>>>>>>> like its original version. >>>>>>>>> >>>>>>>>> These were my suggestions using feedback from the last >>>>>>>>> meeting: >>>>>>>>> >>>>>>>>> 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". >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Can someone tell me what the status of 2005-1 is currently ? >>>>>>>>> >>>>>>>>> As far as I know it hasn't changed since the last meeting. >>>>>>>>> Obviously it should be updated one way or another. I >>>>>>> would gladly >>>>>>>>> write up a formal revision or new proposal if requested. >>>>>>>>> >>>>>>>>> - Kevin >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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 sleibrand at internap.com Tue Jan 24 15:46:35 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 24 Jan 2006 15:46:35 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: References: <639526E5-DB48-4CF7-8947-F4B1EA97ACB2@multicasttech.com> Message-ID: Ok. Could you perhaps re-post the version of 2005-1 you're referring to to de-confuse folks like myself? :) -Scott On 01/24/06 at 3:34pm -0500, Marshall Eubanks wrote: > Hello; > > On Jan 24, 2006, at 3:29 PM, Scott Leibrand wrote: > > > I would agree that IPv6 PI space should be made available to anyone > > who qualifies for IPv4 PI space. 2005-1 as presented at L.A. was a > > bit more restrictive than that, with the 100,000 device requirement. > > Yes, thus the proposal to go back to the original 2005-1. (Shouldn't > these have version #s?) > > > > No, I don't think there is any working shim6 code. However, as > > I've tried > > to say before, I think shim6 will provide a multihoming solution to > > those > > who've thus far not had one available. IMO such a solution, if widely > > implemented, would likely be better for small sites than trying to run > > BGP. > > > > Sure. We can certainly revisit this once that day comes. > > > -Scott > > Marshall > > > > > On 01/23/06 at 9:52pm -0500, Marshall Eubanks > > wrote: > > > >> Easy > >> > >> The experiment has been run. Something you basically never get to > >> do in > >> the real world, run a test case, has been done courtesy of IPv4. > >> And it > >> works and hasn't caused problems. > >> > >> The original 2005-1 matches the existing IPv4 model closely, so the > >> burden should be on those who want to > >> change it, to show that their plans will work and not cause problems > >> or undue burdens. > >> > >> Without working code for SHIM6, I do not see how that can be done. (I > >> am not saying that that is sufficient, just necessary.) Thus, my > >> question. > >> > >> Regards > >> Marshall > >> > >> > >> > >> > >> On Jan 23, 2006, at 9:53 PM, Bill Darte wrote: > >> > >>> And I would request that alternatives posed should establish to the > >>> extent > >>> possible why this alternative is necessary or best suited to be the > >>> consensus model. > >>> > >>> Bill Darte > >>> ARIN AC > >>> > >>> > >>> I would agree. However, 2005-1 did not reach consensus, so we > >>> need to > >>> come up with an alternative that's more likely to do so. I would > >>> love > >>> to > >>> hear what exactly everyone thinks is an appropriate standard for > >>> allocating IPv6 PI space so we can better gauge what would be a > >>> consensus > >>> position. > >>> > >>> -Scott > >>> > >>> > >>> > >>> On 01/23/06 at 9:01pm -0500, Marshall Eubanks > >>> > >>> wrote: > >>> > >>>> I cannot predict what might happen hundreds of years from now. > >>>> > >>>> I can say, however, that 2002-3 has not caused an explosion in the > >>>> routing table for IPv4, nor > >>>> would I expect that 2005-1 would do so for IPv6. > >>>> > >>>> Regards > >>>> Marshall > >>>> > >>>> On Jan 23, 2006, at 4:10 PM, Lea Roberts wrote: > >>>> > >>>>> because, as I'm sure you remember, Bill, the routing table won't > >>> scale > >>>>> over the lifetime of v6 > >>>>> > >>>>> On Mon, 23 Jan 2006, Bill Darte wrote: > >>>>> > >>>>>> OK, I'll start.... > >>>>>> > >>>>>> Why should the criteria for PI in v6 be ANY different than > >>>>>> with v4? > >>>>>> What was large under v4 is somehow not large under v6 apparently? > >>>>>> Turn in you v4 PI block for a v6 PI block. > >>>>>> > >>>>>> That's probably a sufficiently high level argument to begin the > >>>>>> discussion. > >>>>>> > >>>>>> Bill Darte > >>>>>> ARIN AC > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > >>>>>>> Behalf Of Lea Roberts > >>>>>>> Sent: Monday, January 23, 2006 3:01 PM > >>>>>>> To: Owen DeLong > >>>>>>> Cc: ppml at arin.net > >>>>>>> Subject: Re: [ppml] 2005-1 status > >>>>>>> > >>>>>>> > >>>>>>> well, seems like maybe we should talk it out here (again... > >>>>>>> :-) for a while. this sounds more like a "PI for everyone" > >>>>>>> policy. while I'm sure there's a large number of people who > >>>>>>> would like that, I still think it's unlikely it can reach > >>>>>>> consensus... > >>>>>>> > >>>>>>> As I said at the meeting in L.A., I still think it is > >>>>>>> possible to reach consensus for PI assignments for large > >>>>>>> organizations and I thought that's where we were still headed > >>>>>>> after the last meeting., i.e. trying to find criteria that > >>>>>>> the latest round of objectors could live with. > >>>>>>> > >>>>>>> let the discussion begin! /Lea > >>>>>>> > >>>>>>> On Mon, 23 Jan 2006, Owen DeLong wrote: > >>>>>>> > >>>>>>>> Kevin, > >>>>>>>> Why don't you, Lea, and I take this off line and decide > >>>>>>>> what to present back to the group. I apologize for not having > >>>>>>>> followed up in a more timely manner after the last meeting. > >>>>>>>> > >>>>>>>> Owen > >>>>>>>> > >>>>>>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: > >>>>>>>> > >>>>>>>>> Marshall Eubanks wrote: > >>>>>>>>>> Hello; > >>>>>>>>>> > >>>>>>>>>> When last I saw it, 2005-1 was to be reformatted to > >>>>>>> something more > >>>>>>>>>> like its original version. > >>>>>>>>> > >>>>>>>>> These were my suggestions using feedback from the last > >>>>>>>>> meeting: > >>>>>>>>> > >>>>>>>>> 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". > >>>>>>>>> > >>>>>>>>> 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. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Can someone tell me what the status of 2005-1 is currently ? > >>>>>>>>> > >>>>>>>>> As far as I know it hasn't changed since the last meeting. > >>>>>>>>> Obviously it should be updated one way or another. I > >>>>>>> would gladly > >>>>>>>>> write up a formal revision or new proposal if requested. > >>>>>>>>> > >>>>>>>>> - Kevin > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> 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 > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>> > >>>> _______________________________________________ > >>>> 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 tme at multicasttech.com Tue Jan 24 15:57:26 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 24 Jan 2006 15:57:26 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: <639526E5-DB48-4CF7-8947-F4B1EA97ACB2@multicasttech.com> Message-ID: Sure : http://www.arin.net/policy/archive/2005_1_orig.html However, there is a caveat that it is 2:30 AM here, I am getting ready to leave for the airport, and this text may be tweaked, but not by me, at least not now. However, it should be close to what's resubmitted. Regards Marshall On Jan 24, 2006, at 3:46 PM, Scott Leibrand wrote: > Ok. Could you perhaps re-post the version of 2005-1 you're > referring to > to de-confuse folks like myself? :) > > -Scott > > On 01/24/06 at 3:34pm -0500, Marshall Eubanks > wrote: > >> Hello; >> >> On Jan 24, 2006, at 3:29 PM, Scott Leibrand wrote: >> >>> I would agree that IPv6 PI space should be made available to anyone >>> who qualifies for IPv4 PI space. 2005-1 as presented at L.A. was a >>> bit more restrictive than that, with the 100,000 device requirement. >> >> Yes, thus the proposal to go back to the original 2005-1. (Shouldn't >> these have version #s?) >>> >>> No, I don't think there is any working shim6 code. However, as >>> I've tried >>> to say before, I think shim6 will provide a multihoming solution to >>> those >>> who've thus far not had one available. IMO such a solution, if >>> widely >>> implemented, would likely be better for small sites than trying >>> to run >>> BGP. >>> >> >> Sure. We can certainly revisit this once that day comes. >> >>> -Scott >> >> Marshall >> >>> >>> On 01/23/06 at 9:52pm -0500, Marshall Eubanks >>> wrote: >>> >>>> Easy >>>> >>>> The experiment has been run. Something you basically never get to >>>> do in >>>> the real world, run a test case, has been done courtesy of IPv4. >>>> And it >>>> works and hasn't caused problems. >>>> >>>> The original 2005-1 matches the existing IPv4 model closely, so the >>>> burden should be on those who want to >>>> change it, to show that their plans will work and not cause >>>> problems >>>> or undue burdens. >>>> >>>> Without working code for SHIM6, I do not see how that can be >>>> done. (I >>>> am not saying that that is sufficient, just necessary.) Thus, my >>>> question. >>>> >>>> Regards >>>> Marshall >>>> >>>> >>>> >>>> >>>> On Jan 23, 2006, at 9:53 PM, Bill Darte wrote: >>>> >>>>> And I would request that alternatives posed should establish to >>>>> the >>>>> extent >>>>> possible why this alternative is necessary or best suited to be >>>>> the >>>>> consensus model. >>>>> >>>>> Bill Darte >>>>> ARIN AC >>>>> >>>>> >>>>> I would agree. However, 2005-1 did not reach consensus, so we >>>>> need to >>>>> come up with an alternative that's more likely to do so. I would >>>>> love >>>>> to >>>>> hear what exactly everyone thinks is an appropriate standard for >>>>> allocating IPv6 PI space so we can better gauge what would be a >>>>> consensus >>>>> position. >>>>> >>>>> -Scott >>>>> >>>>> >>>>> >>>>> On 01/23/06 at 9:01pm -0500, Marshall Eubanks >>>>> >>>>> wrote: >>>>> >>>>>> I cannot predict what might happen hundreds of years from now. >>>>>> >>>>>> I can say, however, that 2002-3 has not caused an explosion in >>>>>> the >>>>>> routing table for IPv4, nor >>>>>> would I expect that 2005-1 would do so for IPv6. >>>>>> >>>>>> Regards >>>>>> Marshall >>>>>> >>>>>> On Jan 23, 2006, at 4:10 PM, Lea Roberts wrote: >>>>>> >>>>>>> because, as I'm sure you remember, Bill, the routing table won't >>>>> scale >>>>>>> over the lifetime of v6 >>>>>>> >>>>>>> On Mon, 23 Jan 2006, Bill Darte wrote: >>>>>>> >>>>>>>> OK, I'll start.... >>>>>>>> >>>>>>>> Why should the criteria for PI in v6 be ANY different than >>>>>>>> with v4? >>>>>>>> What was large under v4 is somehow not large under v6 >>>>>>>> apparently? >>>>>>>> Turn in you v4 PI block for a v6 PI block. >>>>>>>> >>>>>>>> That's probably a sufficiently high level argument to begin the >>>>>>>> discussion. >>>>>>>> >>>>>>>> Bill Darte >>>>>>>> ARIN AC >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>>>>>>> Behalf Of Lea Roberts >>>>>>>>> Sent: Monday, January 23, 2006 3:01 PM >>>>>>>>> To: Owen DeLong >>>>>>>>> Cc: ppml at arin.net >>>>>>>>> Subject: Re: [ppml] 2005-1 status >>>>>>>>> >>>>>>>>> >>>>>>>>> well, seems like maybe we should talk it out here (again... >>>>>>>>> :-) for a while. this sounds more like a "PI for everyone" >>>>>>>>> policy. while I'm sure there's a large number of people who >>>>>>>>> would like that, I still think it's unlikely it can reach >>>>>>>>> consensus... >>>>>>>>> >>>>>>>>> As I said at the meeting in L.A., I still think it is >>>>>>>>> possible to reach consensus for PI assignments for large >>>>>>>>> organizations and I thought that's where we were still headed >>>>>>>>> after the last meeting., i.e. trying to find criteria that >>>>>>>>> the latest round of objectors could live with. >>>>>>>>> >>>>>>>>> let the discussion begin! /Lea >>>>>>>>> >>>>>>>>> On Mon, 23 Jan 2006, Owen DeLong wrote: >>>>>>>>> >>>>>>>>>> Kevin, >>>>>>>>>> Why don't you, Lea, and I take this off line and decide >>>>>>>>>> what to present back to the group. I apologize for not >>>>>>>>>> having >>>>>>>>>> followed up in a more timely manner after the last meeting. >>>>>>>>>> >>>>>>>>>> Owen >>>>>>>>>> >>>>>>>>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: >>>>>>>>>> >>>>>>>>>>> Marshall Eubanks wrote: >>>>>>>>>>>> Hello; >>>>>>>>>>>> >>>>>>>>>>>> When last I saw it, 2005-1 was to be reformatted to >>>>>>>>> something more >>>>>>>>>>>> like its original version. >>>>>>>>>>> >>>>>>>>>>> These were my suggestions using feedback from the last >>>>>>>>>>> meeting: >>>>>>>>>>> >>>>>>>>>>> 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". >>>>>>>>>>> >>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Can someone tell me what the status of 2005-1 is >>>>>>>>>>>> currently ? >>>>>>>>>>> >>>>>>>>>>> As far as I know it hasn't changed since the last meeting. >>>>>>>>>>> Obviously it should be updated one way or another. I >>>>>>>>> would gladly >>>>>>>>>>> write up a formal revision or new proposal if requested. >>>>>>>>>>> >>>>>>>>>>> - Kevin >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>> >>>>>> _______________________________________________ >>>>>> 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 sleibrand at internap.com Tue Jan 24 16:11:27 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 24 Jan 2006 16:11:27 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4012210E3@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4012210E3@CL-S-EX-1.stanleyassociates.com> Message-ID: On 01/24/06 at 11:09am -0500, Howard, W. Lee I've never been a traffic engineer. Looks to me like BGP is designed > with lots of knobs to determine how bits flow away from you, but fewer > knobs to determine how bits flow toward you, That much is true. > none of which extends beyond the neighbor AS (unless they > choose to propagate). With multiple neighbor ASes with different > policies, the only tool is to deaggregate announcements in > careful ways. > Is this characterization accurate? Not quite. You can also prepend your own ASN on announcements to your upstreams, making one path look longer than the other when the BGP decision falls to AS path length. This is a bit of a blunt instrument, but its use is preferable IMO to deaggregation. > Should engineers be able to determine how traffic flows toward > them? Yes, definitely. > Will the need for traffic engineering by deaggregation be a > major pressure on routing table size in the future? That depends on what other options are available for traffic engineering. See for example Jason Schiller's presentation on network operator traffic engineering concerns with shim6 that was presented at the L.A. NANOG. -Scott From dgolding at burtongroup.com Tue Jan 24 16:18:00 2006 From: dgolding at burtongroup.com (Daniel Golding) Date: Tue, 24 Jan 2006 16:18:00 -0500 Subject: [ppml] 2005-1 status In-Reply-To: Message-ID: On 1/24/06 3:29 PM, "Scott Leibrand" wrote: > I would agree that IPv6 PI space should be made available to anyone who > qualifies for IPv4 PI space. 2005-1 as presented at L.A. was a bit more > restrictive than that, with the 100,000 device requirement. > > No, I don't think there is any working shim6 code. However, as I've tried > to say before, I think shim6 will provide a multihoming solution to those > who've thus far not had one available. IMO such a solution, if widely > implemented, would likely be better for small sites than trying to run > BGP. > > -Scott > There is also a time-frame issue that makes shim6 unworkable as an initial IPv6 multihoming scheme. The top desktop OS is MS Windows. The next version of Windows, Vista, is coming out sometime next year, presumably. It is feature-complete - shim6 wouldn't be added, even if everyone agreed shim6 is a neat trick, which there is not agreement on. The timeframe for widescale deployment of shim6 capable code is (reasonably) past the date (choose one) for IPv4 RIR depletion. What does this mean? Any multihoming strategy must not require a host OS code change (router code changes are easier). That suggestions (for the time being) IPv6 PI with BGP. Shim6 is an interesting future, but if IPv6 is to succeed, we must have this functionality now. It seems that some folks in the IETF believe that enterprises and carriers can be strong-armed by IPv4 address exhaustion into implementing shim6 or some other suboptimal solution. This assumption needs to be questioned rather seriously. -- Daniel Golding From sleibrand at internap.com Tue Jan 24 17:02:50 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 24 Jan 2006 17:02:50 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: References: <639526E5-DB48-4CF7-8947-F4B1EA97ACB2@multicasttech.com> Message-ID: IMO, 2005_1_orig does not *just* make IPv6 PI space available to anyone who qualifies for IPv4 PI space, it goes much further (too far IMO). With IPv4, a small organization that wants to multihome with BGP usually gets a /24 from one or both of their ISPs, and announces that space to both of them. In the US, most tier1 networks accept such /24's from their peers, but some do not. However, those networks, and any networks (such as those overseas) with more aggressive filters, can still access the small organization, even in failover scenarios. This is because they still have the allocating ISP's aggregate netblock in their table, and the allocating ISP receives the customer's /24 announcement either from the customer directly or from the customer's other ISP in a failover scenario. If this small organization wishes to switch ISPs, he will have to renumber. This likely involves changing router configurations, DHCP server configurations, and server and DNS configurations for a small number of statically addressed servers. In most cases this can be done without interrupting service. If this small organization grows to the point where renumbering would become an undue burden (defined by current policy 4.2.2.2 as having efficiently utilized two /24's), he can request PI space from ARIN. Once he renumbers into that PI space, he needn't ever renumber those hosts again, as his PI space is portable. In the IPv6 world, I think we need a similar policy. IMO 2005_1_orig is not it. 2005_1_orig would allow the smallest multihomed organizations to get PI space to start with, essentially forcing everyone in the default-free zone to carry their routes or lose connectivity to them. A better policy would be to adopt the same sort of policy for IPv6 we have for IPv4, which would require small organizations, for whom renumbering is a small burden, to multihome with PA space initially. Once such an organization grows to the point where renumbering would become a significant burden, it should be eligible to apply for PI space. IMO the differences in recommended numbering practices between IPv4 and IPv6 require us to measure renumbering difficulty differently. Does anyone have any good information on what the obstacles to renumbering are in IPv6? Not having done so myself, I can only speculate that difficulty of renumbering is a function of the number of IPv6 subnets in use (which will have to be renumbered in router configuration or DHCP) and the number of statically configured IPv6 hosts (each of which would need to be reconfigured either on the host itself or in DHCP, then updated in DNS). Could a reasonable policy be written that makes a site eligible for PI space once it has either a certain number of subnets (discrete physical broadcast domains) in use, and/or has a certain number of statically configured IPv6 hosts (which would presumably each be pointed to by a discrete AAAA record in the DNS)? -Scott On 01/24/06 at 3:57pm -0500, Marshall Eubanks wrote: > Sure : > > http://www.arin.net/policy/archive/2005_1_orig.html > > However, there is a caveat that it is 2:30 AM here, I am getting > ready to leave for the airport, > and this text may be tweaked, but not by me, at least not now. > However, it should be close to what's resubmitted. > > Regards > Marshall > > On Jan 24, 2006, at 3:46 PM, Scott Leibrand wrote: > > > Ok. Could you perhaps re-post the version of 2005-1 you're > > referring to > > to de-confuse folks like myself? :) > > > > -Scott > > > > On 01/24/06 at 3:34pm -0500, Marshall Eubanks > > wrote: > > > >> Hello; > >> > >> On Jan 24, 2006, at 3:29 PM, Scott Leibrand wrote: > >> > >>> I would agree that IPv6 PI space should be made available to anyone > >>> who qualifies for IPv4 PI space. 2005-1 as presented at L.A. was a > >>> bit more restrictive than that, with the 100,000 device requirement. > >> > >> Yes, thus the proposal to go back to the original 2005-1. (Shouldn't > >> these have version #s?) > >>> > >>> No, I don't think there is any working shim6 code. However, as > >>> I've tried > >>> to say before, I think shim6 will provide a multihoming solution to > >>> those > >>> who've thus far not had one available. IMO such a solution, if > >>> widely > >>> implemented, would likely be better for small sites than trying > >>> to run > >>> BGP. > >>> > >> > >> Sure. We can certainly revisit this once that day comes. > >> > >>> -Scott > >> > >> Marshall > >> > >>> > >>> On 01/23/06 at 9:52pm -0500, Marshall Eubanks > >>> wrote: > >>> > >>>> Easy > >>>> > >>>> The experiment has been run. Something you basically never get to > >>>> do in > >>>> the real world, run a test case, has been done courtesy of IPv4. > >>>> And it > >>>> works and hasn't caused problems. > >>>> > >>>> The original 2005-1 matches the existing IPv4 model closely, so the > >>>> burden should be on those who want to > >>>> change it, to show that their plans will work and not cause > >>>> problems > >>>> or undue burdens. > >>>> > >>>> Without working code for SHIM6, I do not see how that can be > >>>> done. (I > >>>> am not saying that that is sufficient, just necessary.) Thus, my > >>>> question. > >>>> > >>>> Regards > >>>> Marshall > >>>> > >>>> > >>>> > >>>> > >>>> On Jan 23, 2006, at 9:53 PM, Bill Darte wrote: > >>>> > >>>>> And I would request that alternatives posed should establish to > >>>>> the > >>>>> extent > >>>>> possible why this alternative is necessary or best suited to be > >>>>> the > >>>>> consensus model. > >>>>> > >>>>> Bill Darte > >>>>> ARIN AC > >>>>> > >>>>> > >>>>> I would agree. However, 2005-1 did not reach consensus, so we > >>>>> need to > >>>>> come up with an alternative that's more likely to do so. I would > >>>>> love > >>>>> to > >>>>> hear what exactly everyone thinks is an appropriate standard for > >>>>> allocating IPv6 PI space so we can better gauge what would be a > >>>>> consensus > >>>>> position. > >>>>> > >>>>> -Scott > >>>>> > >>>>> > >>>>> > >>>>> On 01/23/06 at 9:01pm -0500, Marshall Eubanks > >>>>> > >>>>> wrote: > >>>>> > >>>>>> I cannot predict what might happen hundreds of years from now. > >>>>>> > >>>>>> I can say, however, that 2002-3 has not caused an explosion in > >>>>>> the > >>>>>> routing table for IPv4, nor > >>>>>> would I expect that 2005-1 would do so for IPv6. > >>>>>> > >>>>>> Regards > >>>>>> Marshall > >>>>>> > >>>>>> On Jan 23, 2006, at 4:10 PM, Lea Roberts wrote: > >>>>>> > >>>>>>> because, as I'm sure you remember, Bill, the routing table won't > >>>>> scale > >>>>>>> over the lifetime of v6 > >>>>>>> > >>>>>>> On Mon, 23 Jan 2006, Bill Darte wrote: > >>>>>>> > >>>>>>>> OK, I'll start.... > >>>>>>>> > >>>>>>>> Why should the criteria for PI in v6 be ANY different than > >>>>>>>> with v4? > >>>>>>>> What was large under v4 is somehow not large under v6 > >>>>>>>> apparently? > >>>>>>>> Turn in you v4 PI block for a v6 PI block. > >>>>>>>> > >>>>>>>> That's probably a sufficiently high level argument to begin the > >>>>>>>> discussion. > >>>>>>>> > >>>>>>>> Bill Darte > >>>>>>>> ARIN AC > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > >>>>>>>>> Behalf Of Lea Roberts > >>>>>>>>> Sent: Monday, January 23, 2006 3:01 PM > >>>>>>>>> To: Owen DeLong > >>>>>>>>> Cc: ppml at arin.net > >>>>>>>>> Subject: Re: [ppml] 2005-1 status > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> well, seems like maybe we should talk it out here (again... > >>>>>>>>> :-) for a while. this sounds more like a "PI for everyone" > >>>>>>>>> policy. while I'm sure there's a large number of people who > >>>>>>>>> would like that, I still think it's unlikely it can reach > >>>>>>>>> consensus... > >>>>>>>>> > >>>>>>>>> As I said at the meeting in L.A., I still think it is > >>>>>>>>> possible to reach consensus for PI assignments for large > >>>>>>>>> organizations and I thought that's where we were still headed > >>>>>>>>> after the last meeting., i.e. trying to find criteria that > >>>>>>>>> the latest round of objectors could live with. > >>>>>>>>> > >>>>>>>>> let the discussion begin! /Lea > >>>>>>>>> > >>>>>>>>> On Mon, 23 Jan 2006, Owen DeLong wrote: > >>>>>>>>> > >>>>>>>>>> Kevin, > >>>>>>>>>> Why don't you, Lea, and I take this off line and decide > >>>>>>>>>> what to present back to the group. I apologize for not > >>>>>>>>>> having > >>>>>>>>>> followed up in a more timely manner after the last meeting. > >>>>>>>>>> > >>>>>>>>>> Owen > >>>>>>>>>> > >>>>>>>>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: > >>>>>>>>>> > >>>>>>>>>>> Marshall Eubanks wrote: > >>>>>>>>>>>> Hello; > >>>>>>>>>>>> > >>>>>>>>>>>> When last I saw it, 2005-1 was to be reformatted to > >>>>>>>>> something more > >>>>>>>>>>>> like its original version. > >>>>>>>>>>> > >>>>>>>>>>> These were my suggestions using feedback from the last > >>>>>>>>>>> meeting: > >>>>>>>>>>> > >>>>>>>>>>> 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". > >>>>>>>>>>> > >>>>>>>>>>> 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. > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Can someone tell me what the status of 2005-1 is > >>>>>>>>>>>> currently ? > >>>>>>>>>>> > >>>>>>>>>>> As far as I know it hasn't changed since the last meeting. > >>>>>>>>>>> Obviously it should be updated one way or another. I > >>>>>>>>> would gladly > >>>>>>>>>>> write up a formal revision or new proposal if requested. > >>>>>>>>>>> > >>>>>>>>>>> - Kevin > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> 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 > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> 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 > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 memsvcs at arin.net Tue Jan 24 17:20:46 2006 From: memsvcs at arin.net (Member Services) Date: Tue, 24 Jan 2006 17:20:46 -0500 Subject: [ppml] Proposed Change to AC Initial Review Period Message-ID: <43D6A83E.2050804@arin.net> The ARIN Board of Trustees is soliciting community comment on its intent to change the initial review period by the Advisory Council of a submitted policy proposal. The proposed change would remove the current requirement for an AC review within ten (10) business days from the date the proposal is posted on the public policy mailing list, and instead require the review to take place at the next regularly scheduled meeting of the AC. If the period before the next regularly scheduled meeting is less than 10 days, then the period would be extended to the subsequent regularly scheduled meeting, but the period would not be extended beyond 45 days. The rationale for this change is that at the end of the review period the AC is required to take an action. In order to do this it must convene a meeting. The current criteria could put a burden on the AC as it could prompt the necessity of having very frequent meetings to perform this duty. The proposed change would allow the AC to meet no more than monthly to perform this task. If you have comments regarding this contemplated Board of Trustees action, please submit them to this list no later than 5 PM Eastern Time, 3 February 2006. Raymond A. Plzak President and CEO American Registry for Internet Numbers (ARIN) From owen at delong.com Tue Jan 24 17:34:22 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Jan 2006 14:34:22 -0800 Subject: [ppml] Proposed Change to AC Initial Review Period In-Reply-To: <43D6A83E.2050804@arin.net> References: <43D6A83E.2050804@arin.net> Message-ID: Ray, I think the proposed change is perfectly reasonable and, as long as the AC is required to meet monthly, I fully support it. Owen On Jan 24, 2006, at 2:20 PM, Member Services wrote: > The ARIN Board of Trustees is soliciting community comment on its > intent > to change the initial review period by the Advisory Council of a > submitted policy proposal. The proposed change would remove the > current > requirement for an AC review within ten (10) business days from the > date > the proposal is posted on the public policy mailing list, and instead > require the review to take place at the next regularly scheduled > meeting > of the AC. If the period before the next regularly scheduled > meeting is > less than 10 days, then the period would be extended to the subsequent > regularly scheduled meeting, but the period would not be extended > beyond > 45 days. > > The rationale for this change is that at the end of the review period > the AC is required to take an action. In order to do this it must > convene a meeting. The current criteria could put a burden on the > AC as > it could prompt the necessity of having very frequent meetings to > perform this duty. The proposed change would allow the AC to meet no > more than monthly to perform this task. If you have comments regarding > this contemplated Board of Trustees action, please submit them to this > list no later than 5 PM Eastern Time, 3 February 2006. > > Raymond A. Plzak > President and CEO > American Registry for Internet Numbers (ARIN) > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Tue Jan 24 17:35:17 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Jan 2006 14:35:17 -0800 Subject: [ppml] Fwd: 2005-1 status References: Message-ID: Oops... Experimenting with new mail client... Don't have the reply defaults quite worked out yet. Meant to post this originally... Owen Begin forwarded message: > From: Scott Leibrand > Date: January 24, 2006 2:25:42 PM PST > To: Owen DeLong > Subject: Re: [ppml] 2005-1 status > > Yeah. I think we agree here. Feel free to post your comments & > clarifications, though, for the benefit of people like Lee. > > -Scott > > On 01/24/06 at 2:23pm -0800, Owen DeLong wrote: > >> >>> >>>> none of which extends beyond the neighbor AS (unless they >>>> choose to propagate). With multiple neighbor ASes with different >>>> policies, the only tool is to deaggregate announcements in >>>> careful ways. >>>> Is this characterization accurate? >>> >>> Not quite. You can also prepend your own ASN on announcements to >>> your >>> upstreams, making one path look longer than the other when the BGP >>> decision falls to AS path length. This is a bit of a blunt >>> instrument, >>> but its use is preferable IMO to deaggregation. >>> >> Of course it is, but, if you want 1/2 of a prefix to have a longer >> AS path one way and the other 1/2 of the same prefix to be preferred >> the other way, then, it doesn't help without deaggregation. >> >>>> Should engineers be able to determine how traffic flows toward >>>> them? >>> >>> Yes, definitely. >>> >> I would say Yes, it would be nice, but, at the same time, determining >> how traffic flows towards your AS is, by definition, determining how >> traffic is routed by your neighboring ASs. I'm not so sure you >> should be able to do that. I agree that we need a mechanism to >> INFLUENCE how traffic flows towards your AS, and, several are >> available. However, determining should be done by the AS doing >> the forwarding. >> >>>> Will the need for traffic engineering by deaggregation be a >>>> major pressure on routing table size in the future? >>> >>> That depends on what other options are available for traffic >>> engineering. >>> See for example Jason Schiller's presentation on network operator >>> traffic >>> engineering concerns with shim6 that was presented at the L.A. >>> NANOG. >>> >> Invariably, traffic engineering eventually boils down to ways to >> divide >> traffic load. Eventually, this leads to ways to subdivide addressing >> blocks. >> >> Owen >> >> From weiler at tislabs.com Tue Jan 24 20:48:52 2006 From: weiler at tislabs.com (Sam Weiler) Date: Tue, 24 Jan 2006 17:48:52 -0800 (PST) Subject: [ppml] Proposed Change to AC Initial Review Period In-Reply-To: <43D6A83E.2050804@arin.net> References: <43D6A83E.2050804@arin.net> Message-ID: On Tue, 24 Jan 2006, Member Services wrote: > The proposed change would remove the current requirement for an AC > review within ten (10) business days from the date the proposal is > posted on the public policy mailing list, and instead require the > review to take place at the next regularly scheduled meeting of the > AC. This sounds reasonable and I generally support it, but ... I'm curious as to what happens to proposals submitted just before a meeting, right at the 60-day cut-off. If a decision on those was deferred 45 days three bad things could happen: a) most importantly, if the AC decline sthe proposal, there wouldn't be time to petition to have it considered at the next meeting b) there would only be 15 days for mailing list discussion, rather than the 30 days required by the current IRPREP. c) there could be difficulty with finalizing and printing the meeting agenda (will the proposal be on the agenda or not?) To be clear, I would NOT support extending the 60-day-before-a-meeting cut-off. Perhaps the 10-day requirement could be retained for proposals submitted close to meetings? -- Sam From billd at cait.wustl.edu Tue Jan 24 18:18:32 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 24 Jan 2006 17:18:32 -0600 Subject: [ppml] 2005-1 status Message-ID: We should at least learn some lessons from previous routing scalability problems. Personally, I do not believe the routing table growth problem will ever be solved until we separate the routing identifier from the end system identifier. However, until that is done, we have to look at IPv6 as it stands. Owen, so OK the conversation continues to be about changing address policy and shim6 and deagregations and ..... Why is GBP sacrosanct? Is there no better method of routing large scale networks? You mention a technique above. Is this a legitimate pursuit? Are there others? Does the problem we keep arguing about need to be solved with tweaks? Seems everything is about preserving the BGP routing tables....isn't there a routing fix? bd From tme at multicasttech.com Tue Jan 24 18:08:41 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 24 Jan 2006 18:08:41 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <777D336F-A588-4EB9-9120-848BB7EE70AC@multicasttech.com> GBP ? A typo for BGP ? Or some new acronym I should know about ? (Not a snark, I am just trying to finish this thread before I go to the airport.) Marshall On Jan 24, 2006, at 6:18 PM, Bill Darte wrote: > > > We should at least learn some lessons from previous routing > scalability > problems. Personally, I do not believe the routing table growth > problem > will ever be solved until we separate the routing identifier from the > end > system identifier. However, until that is done, we have to look at > IPv6 > as it stands. > > > Owen, so OK the conversation continues to be about changing address > policy > and shim6 and deagregations and ..... > > Why is GBP sacrosanct? Is there no better method of routing large > scale > networks? You mention a technique above. Is this a legitimate > pursuit? > Are there others? Does the problem we keep arguing about need to > be solved > with tweaks? Seems everything is about preserving the BGP routing > tables....isn't there a routing fix? > > bd > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From sleibrand at internap.com Tue Jan 24 18:13:54 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 24 Jan 2006 18:13:54 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: Bill, I think we do need to consider alternate routing methods and network technologies, but I think that they need to developed in the appropriate forum (IETF) and implemented by the appropriate folks (network operators). I think we need to make sure that ARIN policy supports the existing network technologies, without inhibiting future innovation. To that end, I think that IPv6 PI space is necessary for the same folks that need IPv4 PI space (so they can migrate from IPv4 to IPv6 with minimal changes to their network), but that non-PI multihoming techniques (advertising PA space into BGP, using shim6, or any other new multihoming method) should be preferred for folks without a compelling need for provider independent addresses. IMO that compelling need is directly related to the difficulty of renumbering when changing providers, which is large for the types of organizations that currently get IPv4 PI space, and small for most of the folks who don't. -Scott On 01/24/06 at 5:18pm -0600, Bill Darte wrote: > > > We should at least learn some lessons from previous routing scalability > problems. Personally, I do not believe the routing table growth problem > will ever be solved until we separate the routing identifier from the > end > system identifier. However, until that is done, we have to look at IPv6 > as it stands. > > > Owen, so OK the conversation continues to be about changing address policy > and shim6 and deagregations and ..... > > Why is GBP sacrosanct? Is there no better method of routing large scale > networks? You mention a technique above. Is this a legitimate pursuit? > Are there others? Does the problem we keep arguing about need to be solved > with tweaks? Seems everything is about preserving the BGP routing > tables....isn't there a routing fix? > > bd > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From sleibrand at internap.com Tue Jan 24 18:15:08 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 24 Jan 2006 18:15:08 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: <6FBA4E15-5984-4F42-9C9C-D361B353815D@delong.com> References: <639526E5-DB48-4CF7-8947-F4B1EA97ACB2@multicasttech.com> <6FBA4E15-5984-4F42-9C9C-D361B353815D@delong.com> Message-ID: Owen, I speculated that renumbering difficulty is "a function of the number of IPv6 subnets in use and the number of statically configured IPv6 hosts". I did not (and do not) assume that renumbering difficulty is a direct function of the number of devices. I recognize that (stateful|stateless) autoconfigured devices are very easy to renumber, whereas statically configured devices, which may have various references pointing to the static IP that must be updated, are much more difficult. I'm glad I'm not the only one having difficulty quantifying renumbering difficulty. On the other hand, if someone *has* come up a good way to quantify renumbering difficulty, please do share it. In the absence of a better method, I can accept that efficient utilization of ~500 IPv6 addresses would be a reasonable threshold for getting PI space if that's the threshold favored by others. I would also accept a composite metric based on a lower number (say ~200) of statically configured addresses, or a similarly smaller number (maybe ~100) of unique subnets (discrete physical broadcast domains). Or perhaps meeting any one of those three thresholds would be adequate to get PI space. What threshold(s) would everyone else consider reasonable? -Scott On 01/24/06 at 2:33pm -0800, Owen DeLong wrote: > Scott, > You continue to accept the fallacious assumption that > renumbering difficulty can be measured by prefix length or number > of devices. This simply isn't true. > > Here are some of the things that can make renumbering difficult: > > + Local addresses embedded in remote device configurations > * ACLs at customer/supplier/contractor sites > * VPN configurations > * NS Glue records > > + Number of statically configured devices > * Routers > * Servers > * Others > > + Number of users affected by "flag day" > > + Local addresses specified in zones not controlled by > local administrator > > * Web Hosting > * Certain Application Service Provider situations > * eMail hosting > * Other forms of server outsourcing > > Notice that most of them are affected by the number of remote sites > involved far more than they are affected by the number of local > addresses > involved. > > I have not, as yet, come up with a good method for quantifying > renumbering difficulty. I can accept efficient utilization of 508 > addresses as a reasonable compromise yardstick if you can (current IPv4 > policy). If you can't accept that, please elaborate on what you think > would be acceptable. > > Owen > > From tme at multicasttech.com Tue Jan 24 18:42:00 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 24 Jan 2006 18:42:00 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <5991CE33-FA09-41CA-8641-9B242856DDA5@multicasttech.com> To translate this, it will be at least 2010 before a substantial numbers of Windows hosts support shim6 with an aggressive schedule of pushing the protocol. vista in 2007. Daniel is correct; nothing but a serious bug can be changed in Vista now. next WOS is, by recent history, at least 2 years later, say 2009 it takes order several years for a new OS to achieve substantial numbers. The timing of a Mac OS X upgrade depends both on when it gets into Free BSD and how much political capital IPv6 has with Apple. I really don't think SHIM6 should impact 2005-1 one way or the other. As I said, when it's out there, we can revisit this. regards Marshall On Jan 24, 2006, at 4:18 PM, Daniel Golding wrote: > On 1/24/06 3:29 PM, "Scott Leibrand" wrote: > >> I would agree that IPv6 PI space should be made available to >> anyone who >> qualifies for IPv4 PI space. 2005-1 as presented at L.A. was a >> bit more >> restrictive than that, with the 100,000 device requirement. >> >> No, I don't think there is any working shim6 code. However, as >> I've tried >> to say before, I think shim6 will provide a multihoming solution >> to those >> who've thus far not had one available. IMO such a solution, if >> widely >> implemented, would likely be better for small sites than trying to >> run >> BGP. >> >> -Scott >> > > There is also a time-frame issue that makes shim6 unworkable as an > initial > IPv6 multihoming scheme. The top desktop OS is MS Windows. The next > version > of Windows, Vista, is coming out sometime next year, presumably. It is > feature-complete - shim6 wouldn't be added, even if everyone agreed > shim6 is > a neat trick, which there is not agreement on. The timeframe for > widescale > deployment of shim6 capable code is (reasonably) past the date > (choose one) > for IPv4 RIR depletion. > > What does this mean? Any multihoming strategy must not require a > host OS > code change (router code changes are easier). That suggestions (for > the time > being) IPv6 PI with BGP. > > Shim6 is an interesting future, but if IPv6 is to succeed, we must > have this > functionality now. It seems that some folks in the IETF believe that > enterprises and carriers can be strong-armed by IPv4 address > exhaustion into > implementing shim6 or some other suboptimal solution. This > assumption needs > to be questioned rather seriously. > > -- > Daniel Golding > > From tme at multicasttech.com Tue Jan 24 18:57:41 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 24 Jan 2006 18:57:41 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: <639526E5-DB48-4CF7-8947-F4B1EA97ACB2@multicasttech.com> Message-ID: I do not agree. I do not see why 2005-1 goes further than 2002-3 but I am certainly willing to be enlightened. What 2002-3 addressed (at least to me, when I was involved in writing the original draft) was not the difficulty of renumbering, but the difficulties associated with multihoming with aggregated addresses. There is a possibility of being black holed if you are multihomed and your PA space is aggregated. It's happened to me. It's not fun. It's not easy to detect, and it relies on the kindness of others to fix. The original 2002-3 envisioned a /24 PI space for any multihomer; that was weakened to a /22 with justification for the space required. I have never received a report of these micro-assignments being filtered out, and I have asked. I do not see signs that they are breaking the back of the IPv4 address table. If you want to put a barrier to keep out someone with two DSL lines and a Mac at home, fine. But I don't think that the difficulty of renumbering is that germane to setting that barrier. Just my opinion. And, certainly, I would view someone with a 2002-3 micro assignment as having qualified. So, maybe anyone who has filled up a /56 or /57 should qualify here. As you may know, I maintain my on list of ASN announced in BGP http://www.multicasttech.com/status/asn_expand.txt So, I keep up with new ASN announced. And, at least for ARIN, they seem to be dominated by (apparently) small multihomers. There is a big demand for this out there; IMHO Arin should give them the tools to do what they want to do. Regards Marshall On Jan 24, 2006, at 5:02 PM, Scott Leibrand wrote: > IMO, 2005_1_orig does not *just* make IPv6 PI space available to > anyone > who qualifies for IPv4 PI space, it goes much further (too far IMO). > > With IPv4, a small organization that wants to multihome with BGP > usually > gets a /24 from one or both of their ISPs, and announces that space to > both of them. In the US, most tier1 networks accept such /24's > from their > peers, but some do not. However, those networks, and any networks > (such > as those overseas) with more aggressive filters, can still access the > small organization, even in failover scenarios. This is because they > still have the allocating ISP's aggregate netblock in their table, > and the > allocating ISP receives the customer's /24 announcement either from > the > customer directly or from the customer's other ISP in a failover > scenario. > > If this small organization wishes to switch ISPs, he will have to > renumber. This likely involves changing router configurations, DHCP > server configurations, and server and DNS configurations for a small > number of statically addressed servers. In most cases this can be > done > without interrupting service. > > If this small organization grows to the point where renumbering would > become an undue burden (defined by current policy 4.2.2.2 as having > efficiently utilized two /24's), he can request PI space from > ARIN. Once > he renumbers into that PI space, he needn't ever renumber those hosts > again, as his PI space is portable. > > In the IPv6 world, I think we need a similar policy. IMO > 2005_1_orig is > not it. 2005_1_orig would allow the smallest multihomed > organizations to > get PI space to start with, essentially forcing everyone in the > default-free zone to carry their routes or lose connectivity to > them. A > better policy would be to adopt the same sort of policy for IPv6 we > have > for IPv4, which would require small organizations, for whom > renumbering is > a small burden, to multihome with PA space initially. Once such an > organization grows to the point where renumbering would become a > significant burden, it should be eligible to apply for PI space. > > IMO the differences in recommended numbering practices between IPv4 > and > IPv6 require us to measure renumbering difficulty differently. Does > anyone have any good information on what the obstacles to > renumbering are > in IPv6? Not having done so myself, I can only speculate that > difficulty > of renumbering is a function of the number of IPv6 subnets in use > (which > will have to be renumbered in router configuration or DHCP) and the > number > of statically configured IPv6 hosts (each of which would need to be > reconfigured either on the host itself or in DHCP, then updated in > DNS). > > Could a reasonable policy be written that makes a site eligible for PI > space once it has either a certain number of subnets (discrete > physical > broadcast domains) in use, and/or has a certain number of statically > configured IPv6 hosts (which would presumably each be pointed to by a > discrete AAAA record in the DNS)? > > -Scott > > On 01/24/06 at 3:57pm -0500, Marshall Eubanks > wrote: > >> Sure : >> >> http://www.arin.net/policy/archive/2005_1_orig.html >> >> However, there is a caveat that it is 2:30 AM here, I am getting >> ready to leave for the airport, >> and this text may be tweaked, but not by me, at least not now. >> However, it should be close to what's resubmitted. >> >> Regards >> Marshall >> >> On Jan 24, 2006, at 3:46 PM, Scott Leibrand wrote: >> >>> Ok. Could you perhaps re-post the version of 2005-1 you're >>> referring to >>> to de-confuse folks like myself? :) >>> >>> -Scott >>> >>> On 01/24/06 at 3:34pm -0500, Marshall Eubanks >>> wrote: >>> >>>> Hello; >>>> >>>> On Jan 24, 2006, at 3:29 PM, Scott Leibrand wrote: >>>> >>>>> I would agree that IPv6 PI space should be made available to >>>>> anyone >>>>> who qualifies for IPv4 PI space. 2005-1 as presented at L.A. >>>>> was a >>>>> bit more restrictive than that, with the 100,000 device >>>>> requirement. >>>> >>>> Yes, thus the proposal to go back to the original 2005-1. >>>> (Shouldn't >>>> these have version #s?) >>>>> >>>>> No, I don't think there is any working shim6 code. However, as >>>>> I've tried >>>>> to say before, I think shim6 will provide a multihoming >>>>> solution to >>>>> those >>>>> who've thus far not had one available. IMO such a solution, if >>>>> widely >>>>> implemented, would likely be better for small sites than trying >>>>> to run >>>>> BGP. >>>>> >>>> >>>> Sure. We can certainly revisit this once that day comes. >>>> >>>>> -Scott >>>> >>>> Marshall >>>> >>>>> >>>>> On 01/23/06 at 9:52pm -0500, Marshall Eubanks >>>>> wrote: >>>>> >>>>>> Easy >>>>>> >>>>>> The experiment has been run. Something you basically never get to >>>>>> do in >>>>>> the real world, run a test case, has been done courtesy of IPv4. >>>>>> And it >>>>>> works and hasn't caused problems. >>>>>> >>>>>> The original 2005-1 matches the existing IPv4 model closely, >>>>>> so the >>>>>> burden should be on those who want to >>>>>> change it, to show that their plans will work and not cause >>>>>> problems >>>>>> or undue burdens. >>>>>> >>>>>> Without working code for SHIM6, I do not see how that can be >>>>>> done. (I >>>>>> am not saying that that is sufficient, just necessary.) Thus, my >>>>>> question. >>>>>> >>>>>> Regards >>>>>> Marshall >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Jan 23, 2006, at 9:53 PM, Bill Darte wrote: >>>>>> >>>>>>> And I would request that alternatives posed should establish to >>>>>>> the >>>>>>> extent >>>>>>> possible why this alternative is necessary or best suited to be >>>>>>> the >>>>>>> consensus model. >>>>>>> >>>>>>> Bill Darte >>>>>>> ARIN AC >>>>>>> >>>>>>> >>>>>>> I would agree. However, 2005-1 did not reach consensus, so we >>>>>>> need to >>>>>>> come up with an alternative that's more likely to do so. I >>>>>>> would >>>>>>> love >>>>>>> to >>>>>>> hear what exactly everyone thinks is an appropriate standard for >>>>>>> allocating IPv6 PI space so we can better gauge what would be a >>>>>>> consensus >>>>>>> position. >>>>>>> >>>>>>> -Scott >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 01/23/06 at 9:01pm -0500, Marshall Eubanks >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> I cannot predict what might happen hundreds of years from now. >>>>>>>> >>>>>>>> I can say, however, that 2002-3 has not caused an explosion in >>>>>>>> the >>>>>>>> routing table for IPv4, nor >>>>>>>> would I expect that 2005-1 would do so for IPv6. >>>>>>>> >>>>>>>> Regards >>>>>>>> Marshall >>>>>>>> >>>>>>>> On Jan 23, 2006, at 4:10 PM, Lea Roberts wrote: >>>>>>>> >>>>>>>>> because, as I'm sure you remember, Bill, the routing table >>>>>>>>> won't >>>>>>> scale >>>>>>>>> over the lifetime of v6 >>>>>>>>> >>>>>>>>> On Mon, 23 Jan 2006, Bill Darte wrote: >>>>>>>>> >>>>>>>>>> OK, I'll start.... >>>>>>>>>> >>>>>>>>>> Why should the criteria for PI in v6 be ANY different than >>>>>>>>>> with v4? >>>>>>>>>> What was large under v4 is somehow not large under v6 >>>>>>>>>> apparently? >>>>>>>>>> Turn in you v4 PI block for a v6 PI block. >>>>>>>>>> >>>>>>>>>> That's probably a sufficiently high level argument to >>>>>>>>>> begin the >>>>>>>>>> discussion. >>>>>>>>>> >>>>>>>>>> Bill Darte >>>>>>>>>> ARIN AC >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: ppml-bounces at arin.net [mailto:ppml- >>>>>>>>>>> bounces at arin.net] On >>>>>>>>>>> Behalf Of Lea Roberts >>>>>>>>>>> Sent: Monday, January 23, 2006 3:01 PM >>>>>>>>>>> To: Owen DeLong >>>>>>>>>>> Cc: ppml at arin.net >>>>>>>>>>> Subject: Re: [ppml] 2005-1 status >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> well, seems like maybe we should talk it out here (again... >>>>>>>>>>> :-) for a while. this sounds more like a "PI for everyone" >>>>>>>>>>> policy. while I'm sure there's a large number of people who >>>>>>>>>>> would like that, I still think it's unlikely it can reach >>>>>>>>>>> consensus... >>>>>>>>>>> >>>>>>>>>>> As I said at the meeting in L.A., I still think it is >>>>>>>>>>> possible to reach consensus for PI assignments for large >>>>>>>>>>> organizations and I thought that's where we were still >>>>>>>>>>> headed >>>>>>>>>>> after the last meeting., i.e. trying to find criteria that >>>>>>>>>>> the latest round of objectors could live with. >>>>>>>>>>> >>>>>>>>>>> let the discussion begin! /Lea >>>>>>>>>>> >>>>>>>>>>> On Mon, 23 Jan 2006, Owen DeLong wrote: >>>>>>>>>>> >>>>>>>>>>>> Kevin, >>>>>>>>>>>> Why don't you, Lea, and I take this off line and decide >>>>>>>>>>>> what to present back to the group. I apologize for not >>>>>>>>>>>> having >>>>>>>>>>>> followed up in a more timely manner after the last meeting. >>>>>>>>>>>> >>>>>>>>>>>> Owen >>>>>>>>>>>> >>>>>>>>>>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Marshall Eubanks wrote: >>>>>>>>>>>>>> Hello; >>>>>>>>>>>>>> >>>>>>>>>>>>>> When last I saw it, 2005-1 was to be reformatted to >>>>>>>>>>> something more >>>>>>>>>>>>>> like its original version. >>>>>>>>>>>>> >>>>>>>>>>>>> These were my suggestions using feedback from the last >>>>>>>>>>>>> meeting: >>>>>>>>>>>>> >>>>>>>>>>>>> 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". >>>>>>>>>>>>> >>>>>>>>>>>>> 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. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can someone tell me what the status of 2005-1 is >>>>>>>>>>>>>> currently ? >>>>>>>>>>>>> >>>>>>>>>>>>> As far as I know it hasn't changed since the last meeting. >>>>>>>>>>>>> Obviously it should be updated one way or another. I >>>>>>>>>>> would gladly >>>>>>>>>>>>> write up a formal revision or new proposal if requested. >>>>>>>>>>>>> >>>>>>>>>>>>> - Kevin >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 randy at psg.com Tue Jan 24 19:27:33 2006 From: randy at psg.com (Randy Bush) Date: Wed, 25 Jan 2006 09:27:33 +0900 Subject: [ppml] Policy without consensus? References: <0D090F1E0F5536449C7E6527AFFA280A21B981@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: <17366.50677.75398.8809@roam.psg.com> > I agree with your position! Unless we find a reasonable way to allocate > IP-v6 address space, IP-v6 is going nowhere here in the US! > > No major corporation CIO is likely to sign off on developing a major > network infrastructure that will involve ultimately million of dollars > and then be forced to rely on a single ISP to provide all their > addresses and thus accept essentially a perpetual service contract with > that provider. thanks! this finally explains why ipv4 is such a failure. the list of asserted reasons for ipv6's lack of deployment includes the union of everybody's hobby-horses. randy From sleibrand at internap.com Tue Jan 24 21:53:26 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 24 Jan 2006 21:53:26 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: References: <639526E5-DB48-4CF7-8947-F4B1EA97ACB2@multicasttech.com> Message-ID: On 01/24/06 at 6:57pm -0500, Marshall Eubanks wrote: > I do not agree. I do not see why 2005-1 goes further than 2002-3 but > I am certainly willing to be enlightened. As I'll argue below, the original 2005-1 goes further than the original 2002-3. I'd like the version of 2005-1 that finally gets approved to be more like the final /22 version of 2002-3. > What 2002-3 addressed (at least to me, when I was involved in writing > the original draft) was not the difficulty of renumbering, but the > difficulties associated with multihoming with aggregated addresses. > There is a possibility of being black holed if you are multihomed and > your PA space is aggregated. It's happened to me. It's not fun. It's > not easy to detect, and it relies on the kindness of others to fix. I've also been involved in such situations. Though I haven't been directly affected, I've had to help our customers fix them. IMO this is no longer as much of a problem for IPv4, especially in the ARIN region. As was pointed out to me in a private reply, Verio no longer filters out PA /24's, so I don't know of any North American Tier 1 NSPs with problematic filters. IMO it remains to be seen how much of a problem this might be in IPv6. > The original 2002-3 envisioned a /24 PI space for any multihomer; > that was weakened to a /22 with justification for the space required. I wasn't involved then, but I think there ware good reasons for weakening 2002-3, and I think the same reasons apply to the original 2005-1. > I have never received a report of these micro-assignments being > filtered out, and I have asked. Nor have I. To do so would be to disconnect from part of the Internet, which I have not known to be a viable business model. > I do not see signs that they are breaking the back of the IPv4 > address table. > > If you want to put a barrier to keep out someone with two DSL lines and > a Mac at home, fine. But I don't think that the difficulty of > renumbering is that germane to setting that barrier. Just my opinion. And there we disagree. I think non-PI multihoming should be the default until the point where the benefits of PI space to the recipient outweigh the cost of requiring all default-free operators to carry the PI block. I don't know exactly where those two lines cross, but I believe we need to set the barrier as close to that point as we can, as was done with 2002-3. > And, certainly, I would view someone with a 2002-3 micro assignment > as having qualified. I would agree. > So, maybe anyone who has filled up a /56 or /57 should qualify here. Perhaps. I'm not sure, but will accept that as one possible solution. > As you may know, I maintain my on list of ASN announced in BGP > http://www.multicasttech.com/status/asn_expand.txt So, I keep up with > new ASN announced. And, at least for ARIN, they seem to be dominated by > (apparently) small multihomers. There is a big demand for this out > there; IMHO Arin should give them the tools to do what they want to do. That's fair, but IMO the policy providing those tools should try not unduly accelerate the growth in the routing table. There are a lot of folks whose routers become obsolete once the routing table reaches a size where they need more RAM than their router can handle. Those are the folks footing the bill each time another multihomed enterprise chooses to announce their route into BGP, and IMO we should consider their interests as well as those of the folks who would like to multihome. -Scott > On Jan 24, 2006, at 5:02 PM, Scott Leibrand wrote: > > > IMO, 2005_1_orig does not *just* make IPv6 PI space available to > > anyone > > who qualifies for IPv4 PI space, it goes much further (too far IMO). > > > > With IPv4, a small organization that wants to multihome with BGP > > usually > > gets a /24 from one or both of their ISPs, and announces that space to > > both of them. In the US, most tier1 networks accept such /24's > > from their > > peers, but some do not. However, those networks, and any networks > > (such > > as those overseas) with more aggressive filters, can still access the > > small organization, even in failover scenarios. This is because they > > still have the allocating ISP's aggregate netblock in their table, > > and the > > allocating ISP receives the customer's /24 announcement either from > > the > > customer directly or from the customer's other ISP in a failover > > scenario. > > > > If this small organization wishes to switch ISPs, he will have to > > renumber. This likely involves changing router configurations, DHCP > > server configurations, and server and DNS configurations for a small > > number of statically addressed servers. In most cases this can be > > done > > without interrupting service. > > > > If this small organization grows to the point where renumbering would > > become an undue burden (defined by current policy 4.2.2.2 as having > > efficiently utilized two /24's), he can request PI space from > > ARIN. Once > > he renumbers into that PI space, he needn't ever renumber those hosts > > again, as his PI space is portable. > > > > In the IPv6 world, I think we need a similar policy. IMO > > 2005_1_orig is > > not it. 2005_1_orig would allow the smallest multihomed > > organizations to > > get PI space to start with, essentially forcing everyone in the > > default-free zone to carry their routes or lose connectivity to > > them. A > > better policy would be to adopt the same sort of policy for IPv6 we > > have > > for IPv4, which would require small organizations, for whom > > renumbering is > > a small burden, to multihome with PA space initially. Once such an > > organization grows to the point where renumbering would become a > > significant burden, it should be eligible to apply for PI space. > > > > IMO the differences in recommended numbering practices between IPv4 > > and > > IPv6 require us to measure renumbering difficulty differently. Does > > anyone have any good information on what the obstacles to > > renumbering are > > in IPv6? Not having done so myself, I can only speculate that > > difficulty > > of renumbering is a function of the number of IPv6 subnets in use > > (which > > will have to be renumbered in router configuration or DHCP) and the > > number > > of statically configured IPv6 hosts (each of which would need to be > > reconfigured either on the host itself or in DHCP, then updated in > > DNS). > > > > Could a reasonable policy be written that makes a site eligible for PI > > space once it has either a certain number of subnets (discrete > > physical > > broadcast domains) in use, and/or has a certain number of statically > > configured IPv6 hosts (which would presumably each be pointed to by a > > discrete AAAA record in the DNS)? > > > > -Scott > > > > On 01/24/06 at 3:57pm -0500, Marshall Eubanks > > wrote: > > > >> Sure : > >> > >> http://www.arin.net/policy/archive/2005_1_orig.html > >> > >> However, there is a caveat that it is 2:30 AM here, I am getting > >> ready to leave for the airport, > >> and this text may be tweaked, but not by me, at least not now. > >> However, it should be close to what's resubmitted. > >> > >> Regards > >> Marshall > >> > >> On Jan 24, 2006, at 3:46 PM, Scott Leibrand wrote: > >> > >>> Ok. Could you perhaps re-post the version of 2005-1 you're > >>> referring to > >>> to de-confuse folks like myself? :) > >>> > >>> -Scott > >>> > >>> On 01/24/06 at 3:34pm -0500, Marshall Eubanks > >>> wrote: > >>> > >>>> Hello; > >>>> > >>>> On Jan 24, 2006, at 3:29 PM, Scott Leibrand wrote: > >>>> > >>>>> I would agree that IPv6 PI space should be made available to > >>>>> anyone > >>>>> who qualifies for IPv4 PI space. 2005-1 as presented at L.A. > >>>>> was a > >>>>> bit more restrictive than that, with the 100,000 device > >>>>> requirement. > >>>> > >>>> Yes, thus the proposal to go back to the original 2005-1. > >>>> (Shouldn't > >>>> these have version #s?) > >>>>> > >>>>> No, I don't think there is any working shim6 code. However, as > >>>>> I've tried > >>>>> to say before, I think shim6 will provide a multihoming > >>>>> solution to > >>>>> those > >>>>> who've thus far not had one available. IMO such a solution, if > >>>>> widely > >>>>> implemented, would likely be better for small sites than trying > >>>>> to run > >>>>> BGP. > >>>>> > >>>> > >>>> Sure. We can certainly revisit this once that day comes. > >>>> > >>>>> -Scott > >>>> > >>>> Marshall > >>>> > >>>>> > >>>>> On 01/23/06 at 9:52pm -0500, Marshall Eubanks > >>>>> wrote: > >>>>> > >>>>>> Easy > >>>>>> > >>>>>> The experiment has been run. Something you basically never get to > >>>>>> do in > >>>>>> the real world, run a test case, has been done courtesy of IPv4. > >>>>>> And it > >>>>>> works and hasn't caused problems. > >>>>>> > >>>>>> The original 2005-1 matches the existing IPv4 model closely, > >>>>>> so the > >>>>>> burden should be on those who want to > >>>>>> change it, to show that their plans will work and not cause > >>>>>> problems > >>>>>> or undue burdens. > >>>>>> > >>>>>> Without working code for SHIM6, I do not see how that can be > >>>>>> done. (I > >>>>>> am not saying that that is sufficient, just necessary.) Thus, my > >>>>>> question. > >>>>>> > >>>>>> Regards > >>>>>> Marshall > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Jan 23, 2006, at 9:53 PM, Bill Darte wrote: > >>>>>> > >>>>>>> And I would request that alternatives posed should establish to > >>>>>>> the > >>>>>>> extent > >>>>>>> possible why this alternative is necessary or best suited to be > >>>>>>> the > >>>>>>> consensus model. > >>>>>>> > >>>>>>> Bill Darte > >>>>>>> ARIN AC > >>>>>>> > >>>>>>> > >>>>>>> I would agree. However, 2005-1 did not reach consensus, so we > >>>>>>> need to > >>>>>>> come up with an alternative that's more likely to do so. I > >>>>>>> would > >>>>>>> love > >>>>>>> to > >>>>>>> hear what exactly everyone thinks is an appropriate standard for > >>>>>>> allocating IPv6 PI space so we can better gauge what would be a > >>>>>>> consensus > >>>>>>> position. > >>>>>>> > >>>>>>> -Scott > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 01/23/06 at 9:01pm -0500, Marshall Eubanks > >>>>>>> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> I cannot predict what might happen hundreds of years from now. > >>>>>>>> > >>>>>>>> I can say, however, that 2002-3 has not caused an explosion in > >>>>>>>> the > >>>>>>>> routing table for IPv4, nor > >>>>>>>> would I expect that 2005-1 would do so for IPv6. > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> Marshall > >>>>>>>> > >>>>>>>> On Jan 23, 2006, at 4:10 PM, Lea Roberts wrote: > >>>>>>>> > >>>>>>>>> because, as I'm sure you remember, Bill, the routing table > >>>>>>>>> won't > >>>>>>> scale > >>>>>>>>> over the lifetime of v6 > >>>>>>>>> > >>>>>>>>> On Mon, 23 Jan 2006, Bill Darte wrote: > >>>>>>>>> > >>>>>>>>>> OK, I'll start.... > >>>>>>>>>> > >>>>>>>>>> Why should the criteria for PI in v6 be ANY different than > >>>>>>>>>> with v4? > >>>>>>>>>> What was large under v4 is somehow not large under v6 > >>>>>>>>>> apparently? > >>>>>>>>>> Turn in you v4 PI block for a v6 PI block. > >>>>>>>>>> > >>>>>>>>>> That's probably a sufficiently high level argument to > >>>>>>>>>> begin the > >>>>>>>>>> discussion. > >>>>>>>>>> > >>>>>>>>>> Bill Darte > >>>>>>>>>> ARIN AC > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: ppml-bounces at arin.net [mailto:ppml- > >>>>>>>>>>> bounces at arin.net] On > >>>>>>>>>>> Behalf Of Lea Roberts > >>>>>>>>>>> Sent: Monday, January 23, 2006 3:01 PM > >>>>>>>>>>> To: Owen DeLong > >>>>>>>>>>> Cc: ppml at arin.net > >>>>>>>>>>> Subject: Re: [ppml] 2005-1 status > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> well, seems like maybe we should talk it out here (again... > >>>>>>>>>>> :-) for a while. this sounds more like a "PI for everyone" > >>>>>>>>>>> policy. while I'm sure there's a large number of people who > >>>>>>>>>>> would like that, I still think it's unlikely it can reach > >>>>>>>>>>> consensus... > >>>>>>>>>>> > >>>>>>>>>>> As I said at the meeting in L.A., I still think it is > >>>>>>>>>>> possible to reach consensus for PI assignments for large > >>>>>>>>>>> organizations and I thought that's where we were still > >>>>>>>>>>> headed > >>>>>>>>>>> after the last meeting., i.e. trying to find criteria that > >>>>>>>>>>> the latest round of objectors could live with. > >>>>>>>>>>> > >>>>>>>>>>> let the discussion begin! /Lea > >>>>>>>>>>> > >>>>>>>>>>> On Mon, 23 Jan 2006, Owen DeLong wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Kevin, > >>>>>>>>>>>> Why don't you, Lea, and I take this off line and decide > >>>>>>>>>>>> what to present back to the group. I apologize for not > >>>>>>>>>>>> having > >>>>>>>>>>>> followed up in a more timely manner after the last meeting. > >>>>>>>>>>>> > >>>>>>>>>>>> Owen > >>>>>>>>>>>> > >>>>>>>>>>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Marshall Eubanks wrote: > >>>>>>>>>>>>>> Hello; > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> When last I saw it, 2005-1 was to be reformatted to > >>>>>>>>>>> something more > >>>>>>>>>>>>>> like its original version. > >>>>>>>>>>>>> > >>>>>>>>>>>>> These were my suggestions using feedback from the last > >>>>>>>>>>>>> meeting: > >>>>>>>>>>>>> > >>>>>>>>>>>>> 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". > >>>>>>>>>>>>> > >>>>>>>>>>>>> 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. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Can someone tell me what the status of 2005-1 is > >>>>>>>>>>>>>> currently ? > >>>>>>>>>>>>> > >>>>>>>>>>>>> As far as I know it hasn't changed since the last meeting. > >>>>>>>>>>>>> Obviously it should be updated one way or another. I > >>>>>>>>>>> would gladly > >>>>>>>>>>>>> write up a formal revision or new proposal if requested. > >>>>>>>>>>>>> > >>>>>>>>>>>>> - Kevin > >>>>>>>>>>>>> > >>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>> 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 > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> 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 > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 owen at delong.com Wed Jan 25 01:01:46 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Jan 2006 22:01:46 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <9C7BB7DB-2914-44D7-86C9-844C58704AF9@delong.com> On Jan 24, 2006, at 3:18 PM, Bill Darte wrote: > > > We should at least learn some lessons from previous routing > scalability > problems. Personally, I do not believe the routing table growth > problem > will ever be solved until we separate the routing identifier from the > end > system identifier. However, until that is done, we have to look at > IPv6 > as it stands. > > > Owen, so OK the conversation continues to be about changing address > policy > and shim6 and deagregations and ..... > > Why is GBP sacrosanct? Is there no better method of routing large > scale > networks? You mention a technique above. Is this a legitimate > pursuit? > Are there others? Does the problem we keep arguing about need to > be solved > with tweaks? Seems everything is about preserving the BGP routing > tables....isn't there a routing fix? > I presume s/GBP/BGP/ above. I don't know. For the time being, it's the protocol we have. I personally think it is a legitimate pursuit, but, I have not been able to convince anyone who knows enough to move it forward in the IETF to help me write it up so that we can get it moving. There are a number of hurdles which would need to be overcome. There are issues regarding the association of ESIs to their corresponding RIs, and, questions about whether the path information would actually present less of a scaling issue than ESI prefix information, but, I don't have the knowledge or the resources to answer any of these questions by myself. Owen From Michael.Dillon at btradianz.com Wed Jan 25 04:43:02 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 25 Jan 2006 09:43:02 +0000 Subject: [ppml] 2005-1 status In-Reply-To: <43D651BE.8060202@hotnic.net> Message-ID: > Another reason to make the minimum size larger than /48 > is to make it easy to distinguish between PI assignments > and deaggregated PA /48's. In the future that could be > extremely useful. Then you think there should be a special meaning attached to /44 which is different from the current meaning -- an endsite which needs 16 times as much address space as the typical endsite. In that case would you propose changing the LIR rules so that they never assign /44 to very large subscribers? > I'd rather not do "standard prefixes". I think /44 > is a reasonable (generous?) minimum for PI and allow larger > sizes where they can be justified. If you would rather not do "standard prefixes" then why do you support /44 as a STANDARD PREFIX for PI end user allocations? I'm not yet convinced that the end user PI allocation needs to be any bigger than /48 per endsite. --Michael Dillon From Michael.Dillon at btradianz.com Wed Jan 25 04:47:37 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 25 Jan 2006 09:47:37 +0000 Subject: [ppml] 2005-1 status In-Reply-To: <43D65B46.9060907@hotnic.net> Message-ID: > > We should be distingushing prefixes based on assignment block ranges not > > by length of prefix. > > Experience shows that assignment block range discriminators are not > nearly as practical as prefix length discriminators. Look at the > trouble people have with bogon filters. If ARIN would maintain an IRR and a BGP feed of assignment block range discriminators and publish a best practice document on how to make use of this information, then the bogon problem would go away. > Plus there are other reasons already stated for making the minimum > assignment larger than /48. Pointing out that some PI end users need more than a /48 is not the same as making the case that the minimum allocation should be greater than /48. If a PI end user has one end site then they should get a /48. If they have two, then they should get a /47. And so on. --Michael Dillon From Michael.Dillon at btradianz.com Wed Jan 25 04:56:04 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 25 Jan 2006 09:56:04 +0000 Subject: [ppml] Proposed Change to AC Initial Review Period In-Reply-To: <43D6A83E.2050804@arin.net> Message-ID: > The rationale for this change is that at the end of the review period > the AC is required to take an action. In order to do this it must > convene a meeting. The current criteria could put a burden on the AC as > it could prompt the necessity of having very frequent meetings to > perform this duty. The proposed change would allow the AC to meet no > more than monthly to perform this task. Since the twice yearly ARIN meeting is an integral part of the policy process, there is already a "policymaking calendar" in place. It seems reasonable to extend this concept of a calendar to include the AC meetings and perhaps even go so far as to include the act of publishing the policy proposals. The end result would be that we can plan our year by knowing on exactly which day policy proposals will be published on the list, and on which day the results of the AC review will be published. To supplement this, perhaps a brief notice could go out to the members list as a heads up that something is being published on PPML (i.e. new policy proposal or AC review results). --Michael Dillon From billd at cait.wustl.edu Wed Jan 25 08:28:58 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 25 Jan 2006 07:28:58 -0600 Subject: [ppml] 2005-1 status Message-ID: Nice post.... focuses attention on renumbering. I reiterate Scott's inquiry into the 'real' issues of renumbering difficulty... Is it total numbers of devices, statically addresses servers, firewall configs, router configs. What makes it hard to renumber? bd > IMO, 2005_1_orig does not *just* make IPv6 PI space available > to anyone who qualifies for IPv4 PI space, it goes much > further (too far IMO). > > With IPv4, a small organization that wants to multihome with > BGP usually gets a /24 from one or both of their ISPs, and > announces that space to both of them. In the US, most tier1 > networks accept such /24's from their peers, but some do not. > However, those networks, and any networks (such as those > overseas) with more aggressive filters, can still access the > small organization, even in failover scenarios. This is > because they still have the allocating ISP's aggregate > netblock in their table, and the allocating ISP receives the > customer's /24 announcement either from the customer directly > or from the customer's other ISP in a failover scenario. > > If this small organization wishes to switch ISPs, he will > have to renumber. This likely involves changing router > configurations, DHCP server configurations, and server and > DNS configurations for a small number of statically addressed > servers. In most cases this can be done without interrupting service. > > If this small organization grows to the point where > renumbering would become an undue burden (defined by current > policy 4.2.2.2 as having efficiently utilized two /24's), he > can request PI space from ARIN. Once he renumbers into that > PI space, he needn't ever renumber those hosts again, as his > PI space is portable. > > In the IPv6 world, I think we need a similar policy. IMO > 2005_1_orig is not it. 2005_1_orig would allow the smallest > multihomed organizations to get PI space to start with, > essentially forcing everyone in the default-free zone to > carry their routes or lose connectivity to them. A better > policy would be to adopt the same sort of policy for IPv6 we > have for IPv4, which would require small organizations, for > whom renumbering is a small burden, to multihome with PA > space initially. Once such an organization grows to the > point where renumbering would become a significant burden, it > should be eligible to apply for PI space. > > IMO the differences in recommended numbering practices > between IPv4 and IPv6 require us to measure renumbering > difficulty differently. Does anyone have any good > information on what the obstacles to renumbering are in IPv6? > Not having done so myself, I can only speculate that > difficulty of renumbering is a function of the number of IPv6 > subnets in use (which will have to be renumbered in router > configuration or DHCP) and the number of statically > configured IPv6 hosts (each of which would need to be > reconfigured either on the host itself or in DHCP, then > updated in DNS). > > Could a reasonable policy be written that makes a site > eligible for PI space once it has either a certain number of > subnets (discrete physical broadcast domains) in use, and/or > has a certain number of statically configured IPv6 hosts > (which would presumably each be pointed to by a discrete AAAA > record in the DNS)? > > -Scott > > On 01/24/06 at 3:57pm -0500, Marshall Eubanks > wrote: > > > Sure : > > > > http://www.arin.net/policy/archive/2005_1_orig.html > > > > However, there is a caveat that it is 2:30 AM here, I am > getting ready > > to leave for the airport, and this text may be tweaked, but > not by me, > > at least not now. However, it should be close to what's resubmitted. > > > > Regards > > Marshall > > > > On Jan 24, 2006, at 3:46 PM, Scott Leibrand wrote: > > > > > Ok. Could you perhaps re-post the version of 2005-1 you're > > > referring to to de-confuse folks like myself? :) > > > > > > -Scott > > > > > > On 01/24/06 at 3:34pm -0500, Marshall Eubanks > > > wrote: > > > > > >> Hello; > > >> > > >> On Jan 24, 2006, at 3:29 PM, Scott Leibrand wrote: > > >> > > >>> I would agree that IPv6 PI space should be made available to > > >>> anyone who qualifies for IPv4 PI space. 2005-1 as presented at > > >>> L.A. was a bit more restrictive than that, with the > 100,000 device > > >>> requirement. > > >> > > >> Yes, thus the proposal to go back to the original 2005-1. > > >> (Shouldn't these have version #s?) > > >>> > > >>> No, I don't think there is any working shim6 code. However, as > > >>> I've tried to say before, I think shim6 will provide a > multihoming > > >>> solution to those > > >>> who've thus far not had one available. IMO such a solution, if > > >>> widely > > >>> implemented, would likely be better for small sites than trying > > >>> to run > > >>> BGP. > > >>> > > >> > > >> Sure. We can certainly revisit this once that day comes. > > >> > > >>> -Scott > > >> > > >> Marshall > > >> > > >>> > > >>> On 01/23/06 at 9:52pm -0500, Marshall Eubanks > > >>> wrote: > > >>> > > >>>> Easy > > >>>> > > >>>> The experiment has been run. Something you basically > never get to > > >>>> do in the real world, run a test case, has been done > courtesy of > > >>>> IPv4. And it > > >>>> works and hasn't caused problems. > > >>>> > > >>>> The original 2005-1 matches the existing IPv4 model > closely, so > > >>>> the burden should be on those who want to change it, > to show that > > >>>> their plans will work and not cause problems > > >>>> or undue burdens. > > >>>> > > >>>> Without working code for SHIM6, I do not see how that can be > > >>>> done. (I am not saying that that is sufficient, just > necessary.) > > >>>> Thus, my question. > > >>>> > > >>>> Regards > > >>>> Marshall > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> On Jan 23, 2006, at 9:53 PM, Bill Darte wrote: > > >>>> > > >>>>> And I would request that alternatives posed should > establish to > > >>>>> the extent > > >>>>> possible why this alternative is necessary or best > suited to be > > >>>>> the > > >>>>> consensus model. > > >>>>> > > >>>>> Bill Darte > > >>>>> ARIN AC > > >>>>> > > >>>>> > > >>>>> I would agree. However, 2005-1 did not reach > consensus, so we > > >>>>> need to come up with an alternative that's more > likely to do so. > > >>>>> I would love > > >>>>> to > > >>>>> hear what exactly everyone thinks is an appropriate > standard for > > >>>>> allocating IPv6 PI space so we can better gauge what > would be a > > >>>>> consensus > > >>>>> position. > > >>>>> > > >>>>> -Scott > > >>>>> > > >>>>> > > >>>>> > > >>>>> On 01/23/06 at 9:01pm -0500, Marshall Eubanks > > >>>>> > > >>>>> wrote: > > >>>>> > > >>>>>> I cannot predict what might happen hundreds of years > from now. > > >>>>>> > > >>>>>> I can say, however, that 2002-3 has not caused an > explosion in > > >>>>>> the routing table for IPv4, nor > > >>>>>> would I expect that 2005-1 would do so for IPv6. > > >>>>>> > > >>>>>> Regards > > >>>>>> Marshall > > >>>>>> > > >>>>>> On Jan 23, 2006, at 4:10 PM, Lea Roberts wrote: > > >>>>>> > > >>>>>>> because, as I'm sure you remember, Bill, the routing table > > >>>>>>> won't > > >>>>> scale > > >>>>>>> over the lifetime of v6 > > >>>>>>> > > >>>>>>> On Mon, 23 Jan 2006, Bill Darte wrote: > > >>>>>>> > > >>>>>>>> OK, I'll start.... > > >>>>>>>> > > >>>>>>>> Why should the criteria for PI in v6 be ANY different than > > >>>>>>>> with v4? What was large under v4 is somehow not > large under > > >>>>>>>> v6 apparently? > > >>>>>>>> Turn in you v4 PI block for a v6 PI block. > > >>>>>>>> > > >>>>>>>> That's probably a sufficiently high level argument > to begin > > >>>>>>>> the discussion. > > >>>>>>>> > > >>>>>>>> Bill Darte > > >>>>>>>> ARIN AC > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> -----Original Message----- > > >>>>>>>>> From: ppml-bounces at arin.net > [mailto:ppml-bounces at arin.net] > > >>>>>>>>> On Behalf Of Lea Roberts > > >>>>>>>>> Sent: Monday, January 23, 2006 3:01 PM > > >>>>>>>>> To: Owen DeLong > > >>>>>>>>> Cc: ppml at arin.net > > >>>>>>>>> Subject: Re: [ppml] 2005-1 status > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> well, seems like maybe we should talk it out here > (again... > > >>>>>>>>> :-) for a while. this sounds more like a "PI for > everyone" > > >>>>>>>>> policy. while I'm sure there's a large number of > people who > > >>>>>>>>> would like that, I still think it's unlikely it can reach > > >>>>>>>>> consensus... > > >>>>>>>>> > > >>>>>>>>> As I said at the meeting in L.A., I still think it is > > >>>>>>>>> possible to reach consensus for PI assignments for large > > >>>>>>>>> organizations and I thought that's where we were still > > >>>>>>>>> headed after the last meeting., i.e. trying to > find criteria > > >>>>>>>>> that the latest round of objectors could live with. > > >>>>>>>>> > > >>>>>>>>> let the discussion begin! /Lea > > >>>>>>>>> > > >>>>>>>>> On Mon, 23 Jan 2006, Owen DeLong wrote: > > >>>>>>>>> > > >>>>>>>>>> Kevin, > > >>>>>>>>>> Why don't you, Lea, and I take this off line and decide > > >>>>>>>>>> what to present back to the group. I apologize for not > > >>>>>>>>>> having followed up in a more timely manner after > the last > > >>>>>>>>>> meeting. > > >>>>>>>>>> > > >>>>>>>>>> Owen > > >>>>>>>>>> > > >>>>>>>>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote: > > >>>>>>>>>> > > >>>>>>>>>>> Marshall Eubanks wrote: > > >>>>>>>>>>>> Hello; > > >>>>>>>>>>>> > > >>>>>>>>>>>> When last I saw it, 2005-1 was to be reformatted to > > >>>>>>>>> something more > > >>>>>>>>>>>> like its original version. > > >>>>>>>>>>> > > >>>>>>>>>>> These were my suggestions using feedback from the last > > >>>>>>>>>>> meeting: > > >>>>>>>>>>> > > >>>>>>>>>>> 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". > > >>>>>>>>>>> > > >>>>>>>>>>> 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. > > >>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> Can someone tell me what the status of 2005-1 is > > >>>>>>>>>>>> currently ? > > >>>>>>>>>>> > > >>>>>>>>>>> As far as I know it hasn't changed since the > last meeting. > > >>>>>>>>>>> Obviously it should be updated one way or another. I > > >>>>>>>>> would gladly > > >>>>>>>>>>> write up a formal revision or new proposal if requested. > > >>>>>>>>>>> > > >>>>>>>>>>> - Kevin > > >>>>>>>>>>> > > >>>>>>>>>>> _______________________________________________ > > >>>>>>>>>>> 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 > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> _______________________________________________ > > >>>>>>>>> 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 > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> 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 > > >>>> > > >>>> > > >> > > >> > > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From william at elan.net Wed Jan 25 08:22:15 2006 From: william at elan.net (william(at)elan.net) Date: Wed, 25 Jan 2006 05:22:15 -0800 (PST) Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: On Wed, 25 Jan 2006, Bill Darte wrote: > Nice post.... focuses attention on renumbering. > I reiterate Scott's inquiry into the 'real' issues of renumbering > difficulty... > Is it total numbers of devices, statically addresses servers, firewall > configs, router configs. > What makes it hard to renumber? Human factor. If renumbering could be done easily enough as was for example envisioned with A6, then I think using provider ip addresses would be seen as less of a problem. I suspect that this would actually be sold with shim6, but not in the way shim6 designers want it but rather that shim6 addresses would be used in a way similar to NAT as private ips on entire lan. -- William Leibzon Elan Networks william at elan.net From billd at cait.wustl.edu Wed Jan 25 08:34:45 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 25 Jan 2006 07:34:45 -0600 Subject: [ppml] Proposed Change to AC Initial Review Period Message-ID: > > > The rationale for this change is that at the end of the > review period > > the AC is required to take an action. In order to do this it must > > convene a meeting. The current criteria could put a burden > on the AC as > > it could prompt the necessity of having very frequent meetings to > > perform this duty. The proposed change would allow the AC > to meet no > > more than monthly to perform this task. > > Since the twice yearly ARIN meeting is an integral > part of the policy process, there is already a > "policymaking calendar" in place. It seems reasonable > to extend this concept of a calendar to include the > AC meetings and perhaps even go so far as to include > the act of publishing the policy proposals. Michael, do you think this would constrain authors of policy proposals to timeframes that are less convenient for them? > > The end result would be that we can plan our year by knowing > on exactly which day policy proposals will be published on > the list, and on which day the results of the AC review > will be published. To supplement this, perhaps a brief > notice could go out to the members list as a heads up > that something is being published on PPML (i.e. new > policy proposal or AC review results). > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From billd at cait.wustl.edu Wed Jan 25 08:40:36 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 25 Jan 2006 07:40:36 -0600 Subject: [ppml] 2005-1 status Message-ID: > > > Bill, > > I think we do need to consider alternate routing methods and > network technologies, but I think that they need to developed > in the appropriate forum (IETF) and implemented by the > appropriate folks (network operators). Of course. Routing protocols are no more an ARIN issue than addressing policy is an IETF issue. What I ask is...is it likely in the next 15 years to have a scalable routing protocol that makes the issue of PI addressing of end-sites mute? 25 years? >I think we need to > make sure that ARIN policy supports the existing network > technologies, without inhibiting future innovation. To that > end, I think that IPv6 PI space is necessary for the same > folks that need IPv4 PI space (so they can migrate from IPv4 > to IPv6 with minimal changes to their network), but that > non-PI multihoming techniques (advertising PA space into BGP, > using shim6, or any other new multihoming > method) should be preferred for folks without a compelling > need for provider independent addresses. IMO that compelling > need is directly related to the difficulty of renumbering > when changing providers, which is large for the types of > organizations that currently get IPv4 PI space, and small for > most of the folks who don't. > > -Scott > Are there no other compelling reasons to need...desire... PI space? If it really IS simply renumbering, then > On 01/24/06 at 5:18pm -0600, Bill Darte wrote: > > > > > > > We should at least learn some lessons from previous routing > > scalability problems. Personally, I do not believe the > routing table > > growth problem will ever be solved until we separate the routing > > identifier from the end system identifier. However, until that is > > done, we have to look at IPv6 as it stands. > > > > > > Owen, so OK the conversation continues to be about changing address > > policy and shim6 and deagregations and ..... > > > > Why is GBP sacrosanct? Is there no better method of routing large > > scale networks? You mention a technique above. Is this a > legitimate > > pursuit? Are there others? Does the problem we keep arguing about > > need to be solved with tweaks? Seems everything is about > preserving > > the BGP routing tables....isn't there a routing fix? > > > > bd > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > From bmanning at vacation.karoshi.com Wed Jan 25 08:31:51 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 25 Jan 2006 13:31:51 +0000 Subject: [ppml] renumbering aka 2005-1 In-Reply-To: References: Message-ID: <20060125133151.GA5873@vacation.karoshi.com.> On Wed, Jan 25, 2006 at 05:22:15AM -0800, william(at)elan.net wrote: > > On Wed, 25 Jan 2006, Bill Darte wrote: > > > Nice post.... focuses attention on renumbering. > > I reiterate Scott's inquiry into the 'real' issues of renumbering > > difficulty... > > Is it total numbers of devices, statically addresses servers, firewall > > configs, router configs. > > What makes it hard to renumber? > > Human factor. If renumbering could be done easily enough as was > for example envisioned with A6, then I think using provider ip > addresses would be seen as less of a problem. I suspect that > this would actually be sold with shim6, but not in the way shim6 > designers want it but rather that shim6 addresses would be used > in a way similar to NAT as private ips on entire lan. > renumbering effects many things... DNS hints files (want to replace 10,000,000 of those?) MIBs Radius & AAA logs to name a few... shim6 gets ~60-70% of a solution and like HIP is a crack at EID/locator separation. Its not enough. --bill From Michael.Dillon at btradianz.com Wed Jan 25 08:36:24 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 25 Jan 2006 13:36:24 +0000 Subject: [ppml] 2005-1 status In-Reply-To: Message-ID: > Human factor. If renumbering could be done easily enough as was > for example envisioned with A6, then I think using provider ip > addresses would be seen as less of a problem. The lack of renumbering capability in IPv6 does not mean that renumbering an IPv6 network is either harder or easier than renumbering an IPv4 network. There is no agreement on whether or not renumbering capability belongs in the base IP protocol or not. Lot's of effort has gone into a separate protocol for and into tools to support that separate renumbering protocol. I refer you to the IETF's DHC working group: http://www.ietf.org/html.charters/dhc-charter.html Here is one such DHCPv6 tool: http://klub.com.pl/dhcpv6/ PI addresses are not the only implemented solution to the problem of renumbering an enterprise network. If we decide not to issue PI v6 allocations to end users, we are not making renumbering harder or easier. It is likely that well managed v6 networks will be able to easily make the transition and poorly managed v6 networks will struggle to make the transition. ARIN policies do not impact whether or not a network is poorly managed. However, we do have the option of crafting a policy which encourages and condones poorly-managed enterprise networks by allowing end users to receive PI allocations directly from ARIN. --Michael Dillon From Michael.Dillon at btradianz.com Wed Jan 25 08:42:44 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 25 Jan 2006 13:42:44 +0000 Subject: [ppml] Proposed Change to AC Initial Review Period In-Reply-To: Message-ID: > Michael, do you think this would constrain authors of policy proposals to > timeframes that are less convenient for them? Yes it would. But that is a good thing. Too often we see proposals which are convenient for the authors, i.e. knee jerk reactions to some perceived need. This tends to create poorly thought out proposals and also leads to disorganized discussions on PPML that end up somewhere in left field rather than focussing on a real solution to a real issue. I believe that the AC review step was put in place to improve the quality of proposals under discussion. Now, obviously, having a fixed publication date twice a year for new proposals doesn't prevent authors from dashing off a proposal on a moments notice. But it does provide some time for them to reflect and withdraw the proposal for further editing before PPML ends up losing the plot in its discussions. It also allows the ARIN policy editor to have some two-way discussions with the author without time pressure in order to address things like fitting the new policy into the NPRM, making sure that all the implications of the change are covered in the proposal, etc. --Michael Dillon From billd at cait.wustl.edu Wed Jan 25 08:55:00 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 25 Jan 2006 07:55:00 -0600 Subject: [ppml] 2005-1 status Message-ID: > > > Human factor. If renumbering could be done easily enough as was for > > example envisioned with A6, then I think using provider ip > addresses > > would be seen as less of a problem. > > The lack of renumbering capability in IPv6 does not mean > that renumbering an IPv6 network is either harder or > easier than renumbering an IPv4 network. There is no > agreement on whether or not renumbering capability belongs > in the base IP protocol or not. > > Lot's of effort has gone into a separate protocol for > and into tools to support that separate renumbering > protocol. I refer you to the IETF's DHC working group: > http://www.ietf.org/html.charters/dhc-charter.html > > Here is one such DHCPv6 tool: http://klub.com.pl/dhcpv6/ > > PI addresses are not the only implemented solution to > the problem of renumbering an enterprise network. If we > decide not to issue PI v6 allocations to end users, we > are not making renumbering harder or easier. It is likely > that well managed v6 networks will be able to easily make > the transition and poorly managed v6 networks will struggle > to make the transition. ARIN policies do not impact whether > or not a network is poorly managed. > > However, we do have the option of crafting a policy which > encourages and condones poorly-managed enterprise networks by > allowing end users to receive PI allocations directly from ARIN. > > --Michael Dillon I agree with you. Of course what I want to understand..through the experience of others..is the 'necessity' for PI to anyone (first) and smaller entities (as well). By exposing all the absolutes and relatives in appropriate perspective, it makes determining IF and WHO gets PI easier...not easy....easier. Consensus is only born from common understanding, I think. bd > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From billd at cait.wustl.edu Wed Jan 25 08:57:59 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 25 Jan 2006 07:57:59 -0600 Subject: [ppml] Proposed Change to AC Initial Review Period Message-ID: > > > Michael, do you think this would constrain authors of > policy proposals > to > > timeframes that are less convenient for them? > > Yes it would. But that is a good thing. Too often we > see proposals which are convenient for the authors, > i.e. knee jerk reactions to some perceived need. This > tends to create poorly thought out proposals and also > leads to disorganized discussions on PPML that end up > somewhere in left field rather than focussing on > a real solution to a real issue. > > I believe that the AC review step was put in place > to improve the quality of proposals under discussion. > > Now, obviously, having a fixed publication date twice > a year for new proposals doesn't prevent authors from > dashing off a proposal on a moments notice. But it does > provide some time for them to reflect and withdraw the > proposal for further editing before PPML ends up losing > the plot in its discussions. It also allows the ARIN > policy editor to have some two-way discussions with the > author without time pressure in order to address things > like fitting the new policy into the NPRM, making sure > that all the implications of the change are covered in > the proposal, etc. > > --Michael Dillon Would it make more sense to leave the submission calendar flexible as is, but require an author to submit a "pre-policy proposal" to the ppml 10 days before submitting the formal proposal in order to solicit positive feedback...and of course allow the industry to boo them off the proposal? > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From sleibrand at internap.com Wed Jan 25 10:12:33 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 25 Jan 2006 10:12:33 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: On 01/25/06 at 7:40am -0600, Bill Darte wrote: > Of course. Routing protocols are no more an ARIN issue than addressing > policy is an IETF issue. What I ask is...is it likely in the next 15 > years to have a scalable routing protocol that makes the issue of PI > addressing of end-sites mute? 25 years? Who knows. I've only been *alive* for 25 years, so I can't exactly predict that far into the future. :) In all seriousness, I think PI space will be needed as long as the Internet runs BGP. I have no idea what the drivers will be for moving beyond BGP, or when that might happen. It's certainly far enough away to have little or no bearing on the current policy discussions, though. > Are there no other compelling reasons to need...desire... PI space? There may be other reasons related to relative routability of different classes of IP space, but since ARIN expressly disclaims responsibility for routability, I'm not sure how germane that is to making policy. And in any case, I'm pretty sure NSP IPv6 BGP filtering policies will change significantly as everyone transitions from IPv4 to IPv6. > If it really IS simply renumbering, then Looks like your message got cut off... Then what? -Scott From Michael.Dillon at btradianz.com Wed Jan 25 10:31:13 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 25 Jan 2006 15:31:13 +0000 Subject: [ppml] Proposed Change to AC Initial Review Period In-Reply-To: Message-ID: > Would it make more sense to leave the submission calendar flexible as is, > but require an author to submit a "pre-policy proposal" to the ppml 10 days > before submitting the formal proposal in order to solicit positive > feedback...and of course allow the industry to boo them off the proposal? I think that one of the advantages in having a fixed publication schedule is that you can send a heads-up announcement to the members list and get more members to join the PPML discussions. This brings more diverse viewpoints to the discussions rather than the same old set of people hammering on the same positions. There is nothing preventing anyone from testing an idea on PPML before submitting a proposal. I've done that in the past. --Michael Dillon From bruce.eastman at adelphia.com Wed Jan 25 11:20:54 2006 From: bruce.eastman at adelphia.com (Bruce Eastman) Date: Wed, 25 Jan 2006 11:20:54 -0500 Subject: [ppml] Proposed Change to AC Initial Review Period Message-ID: > Would it make more sense to leave the submission calendar flexible as is, > but require an author to submit a "pre-policy proposal" to the ppml 10 days > before submitting the formal proposal in order to solicit positive > feedback...and of course allow the industry to boo them off the proposal? I think that one of the advantages in having a fixed publication schedule is that you can send a heads-up announcement to the members list and get more members to join the PPML discussions. This brings more diverse viewpoints to the discussions rather than the same old set of people hammering on the same positions. There is nothing preventing anyone from testing an idea on PPML before submitting a proposal. I've done that in the past. --Michael Dillon Michael, I agree that a policy proposal should be well thought out before submission. I disagree, however, with the fixed publication schedule. Not so much because of inconvenience to the author, but due to the fact that it is easier to follow discussion on one or two policies as they trickle in, rather than 4 or 5 at a predetermined date. I feel you are more likely to "lose the plot" as you put it, trying to discuss multiple polices on a set date verses 1 or 2 whenever they may be posted. Bruce Eastman Senior IP Analyst Adelphia Cable Communications From tony.li at tony.li Wed Jan 25 16:22:12 2006 From: tony.li at tony.li (Tony Li) Date: Wed, 25 Jan 2006 13:22:12 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <43D7EC04.7000608@tony.li> > What I ask is...is it likely in the next 15 years to have a scalable routing > protocol that makes the issue of PI addressing of end-sites mute? 25 years? This is a routing architecture issue, NOT a protocol issue. Tony From billd at cait.wustl.edu Wed Jan 25 20:28:40 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 25 Jan 2006 19:28:40 -0600 Subject: [ppml] 2005-1 status Message-ID: > What I ask is...is it likely in the next 15 years to have a scalable routing > protocol that makes the issue of PI addressing of end-sites mute? 25 years? This is a routing architecture issue, NOT a protocol issue. Tony OK, Tony...it's an architecture problem... what's the solution then. What architectural change can elimate the scaling problem posed by an expanding PI endsite population.... or is there an alternative to PI that allows flexibility of endsites to benignly exchange service providers? bd From tony.li at tony.li Wed Jan 25 21:14:43 2006 From: tony.li at tony.li (Tony Li) Date: Wed, 25 Jan 2006 18:14:43 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <43D83093.3070306@tony.li> > OK, Tony...it's an architecture problem... what's the solution then. What > architectural change can elimate the scaling problem posed by an expanding > PI endsite population.... or is there an alternative to PI that allows > flexibility of endsites to benignly exchange service providers? Well, the basic problem that we have to confront is that to keep the routing subsystem scalable, we can only relay a relatively small amount of information, regardless of the size of the network. Yes, I grant you that this amount can and will grow slightly over time and that Moore's law may (or may not) help us out, but any way we look at it routing must scale about logarithmically or so. For that to happen, we need to be able to create topological abstractions on the network. We need to be able to take a map of the network, draw a big circle around various parts of it and give everything in that circle a 'handle' for us to route on. Obviously, PI space flies right in the face of this. Every single PI allocation that is ever made comes at a constant cost to the network and covers a fixed portion of the network. Unless PI allocations effectively never happen, any reasonable PI allocation allotment will quickly cause a routing information explosion. Example 1: Suppose that a PI allocation gets a /48. Then the routing infrastructure needs to support 2^128 / 2^80 = 2^48 (~ 3e14) information entries. Further, that allocation is already enough to support 2^80 (~ 1e24) hosts. The current Internet is something like 3e8 hosts, so this is already a very large allocation. Example 2: We could make PI allocations much larger, such as a /32, but then we limit either the size of the network or the number of enterprises that are allowed to participate. Even then the routing issue is intractable using today's technology (~ 4e9 entries). The basic conclusion here is pretty much straightforward: we cannot responsibly make PI allocations without either blowing up the routing subsystem or squandering our hard-fought extra address space. Given this, it follows that we need an architecture that allows us to renumber or multi-home easily. There have been many that have been discussed and I won't re-hash them all here, as this mail is long enough already. Regards, Tony From owen at delong.com Thu Jan 26 00:08:13 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 25 Jan 2006 21:08:13 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <120CA9C1-22E6-46D0-9962-B79B9C8661A5@delong.com> On Jan 25, 2006, at 7:12 AM, Scott Leibrand wrote: > On 01/25/06 at 7:40am -0600, Bill Darte wrote: > >> Of course. Routing protocols are no more an ARIN issue than >> addressing >> policy is an IETF issue. What I ask is...is it likely in the next 15 >> years to have a scalable routing protocol that makes the issue of PI >> addressing of end-sites mute? 25 years? > > Who knows. I've only been *alive* for 25 years, so I can't exactly > predict that far into the future. :) > > In all seriousness, I think PI space will be needed as long as the > Internet runs BGP. I have no idea what the drivers will be for moving > beyond BGP, or when that might happen. It's certainly far enough > away to > have little or no bearing on the current policy discussions, though. > Except to the extent that there seems to be substantial consensus around the idea that we should not create a driver for such a change. I'm not sure I agree with that consensus, but, I think it exists in the community at large. >> Are there no other compelling reasons to need...desire... PI space? > > There may be other reasons related to relative routability of > different > classes of IP space, but since ARIN expressly disclaims > responsibility for > routability, I'm not sure how germane that is to making policy. > And in > any case, I'm pretty sure NSP IPv6 BGP filtering policies will change > significantly as everyone transitions from IPv4 to IPv6. > Until shim6 is real, multihoming is a real and legitimate need for PI. I think shim6 is years away from being real, and, perhaps as little as a decade away from being meaningful as a multihoming solution. Owen From Ed.Lewis at neustar.biz Thu Jan 26 10:58:22 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 26 Jan 2006 10:58:22 -0500 Subject: [ppml] Proposed Change to AC Initial Review Period In-Reply-To: <43D6A83E.2050804@arin.net> References: <43D6A83E.2050804@arin.net> Message-ID: This makes sense to me. But I want to ask for some clarification to make sure. The sentence "The proposed change would allow the AC to meet no more than monthly to perform this task" can be taken to meaning either a) we want to alleviate the AC from having to meet more than once a month b) we want to prevent the AC from meeting more than once a month I think the intent is "a". Is that right? At 17:20 -0500 1/24/06, Member Services wrote: >The ARIN Board of Trustees is soliciting community comment on its intent >to change the initial review period by the Advisory Council of a >submitted policy proposal. The proposed change would remove the current >requirement for an AC review within ten (10) business days from the date >the proposal is posted on the public policy mailing list, and instead >require the review to take place at the next regularly scheduled meeting >of the AC. If the period before the next regularly scheduled meeting is >less than 10 days, then the period would be extended to the subsequent >regularly scheduled meeting, but the period would not be extended beyond >45 days. > >The rationale for this change is that at the end of the review period >the AC is required to take an action. In order to do this it must >convene a meeting. The current criteria could put a burden on the AC as >it could prompt the necessity of having very frequent meetings to >perform this duty. The proposed change would allow the AC to meet no >more than monthly to perform this task. If you have comments regarding >this contemplated Board of Trustees action, please submit them to this >list no later than 5 PM Eastern Time, 3 February 2006. > >Raymond A. Plzak >President and CEO >American Registry for Internet Numbers (ARIN) > >_______________________________________________ >PPML mailing list >PPML at arin.net >http://lists.arin.net/mailman/listinfo/ppml -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... From packetgrrl at gmail.com Thu Jan 26 11:08:31 2006 From: packetgrrl at gmail.com (cja@daydream.com) Date: Thu, 26 Jan 2006 09:08:31 -0700 Subject: [ppml] Proposed Change to AC Initial Review Period In-Reply-To: References: <43D6A83E.2050804@arin.net> Message-ID: Ed, The AC has regularly scheduled meetings. Sometimes because of the 10 day requirement we have to meet just before a regularly scheduled meeting when we could just wait a couple more days and have our regular meeting. We have the regularly scheduled meeting times because it is difficult to get enough of us together at random times. It seemed reasonable that we should use that regular schedule in the review process as well. If we need to meet more than once a month we're willing to do that and have done that. No one is trying to prevent that. Thanks! ---Cathy On 1/26/06, Edward Lewis wrote: > > This makes sense to me. But I want to ask for some clarification to make > sure. > > The sentence "The proposed change would allow the AC to meet no more > than monthly to perform this task" can be taken to meaning either > > a) we want to alleviate the AC from having to meet more than once a month > > b) we want to prevent the AC from meeting more than once a month > > I think the intent is "a". Is that right? > > At 17:20 -0500 1/24/06, Member Services wrote: > >The ARIN Board of Trustees is soliciting community comment on its intent > >to change the initial review period by the Advisory Council of a > >submitted policy proposal. The proposed change would remove the current > >requirement for an AC review within ten (10) business days from the date > >the proposal is posted on the public policy mailing list, and instead > >require the review to take place at the next regularly scheduled meeting > >of the AC. If the period before the next regularly scheduled meeting is > >less than 10 days, then the period would be extended to the subsequent > >regularly scheduled meeting, but the period would not be extended beyond > >45 days. > > > >The rationale for this change is that at the end of the review period > >the AC is required to take an action. In order to do this it must > >convene a meeting. The current criteria could put a burden on the AC as > >it could prompt the necessity of having very frequent meetings to > >perform this duty. The proposed change would allow the AC to meet no > >more than monthly to perform this task. If you have comments regarding > >this contemplated Board of Trustees action, please submit them to this > >list no later than 5 PM Eastern Time, 3 February 2006. > > > >Raymond A. Plzak > >President and CEO > >American Registry for Internet Numbers (ARIN) > > > >_______________________________________________ > >PPML mailing list > >PPML at arin.net > >http://lists.arin.net/mailman/listinfo/ppml > > -- > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward > Lewis +1-571-434-5468 > NeuStar > > Nothin' more exciting than going to the printer to watch the toner > drain... > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ed.Lewis at neustar.biz Thu Jan 26 11:18:42 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 26 Jan 2006 11:18:42 -0500 Subject: [ppml] Proposed Change to AC Initial Review Period In-Reply-To: References: <43D6A83E.2050804@arin.net> Message-ID: That's what I thought, I just wanted to make sure I read it right. I'm certainly for less bureaucracy. At 9:08 -0700 1/26/06, cja at daydream.com wrote: Ed, The AC has regularly scheduled meetings. Sometimes because of the 10 day requirement we have to meet just before a regularly scheduled meeting when we could just wait a couple more days and have our regular meeting. We have the regularly scheduled meeting times because it is difficult to get enough of us together at random times. It seemed reasonable that we should use that regular schedule in the review process as well. If we need to meet more than once a month we're willing to do that and have done that. No one is trying to prevent that. Thanks! ---Cathy On 1/26/06, Edward Lewis < Ed.Lewis at neustar.biz> wrote: This makes sense to me. But I want to ask for some clarification to make sure. The sentence "The proposed change would allow the AC to meet no more than monthly to perform this task" can be taken to meaning either a) we want to alleviate the AC from having to meet more than once a month b) we want to prevent the AC from meeting more than once a month I think the intent is "a". Is that right? At 17:20 -0500 1/24/06, Member Services wrote: >The ARIN Board of Trustees is soliciting community comment on its intent >to change the initial review period by the Advisory Council of a >submitted policy proposal. The proposed change would remove the current >requirement for an AC review within ten (10) business days from the date >the proposal is posted on the public policy mailing list, and instead >require the review to take place at the next regularly scheduled meeting >of the AC. If the period before the next regularly scheduled meeting is >less than 10 days, then the period would be extended to the subsequent >regularly scheduled meeting, but the period would not be extended beyond >45 days. > >The rationale for this change is that at the end of the review period >the AC is required to take an action. In order to do this it must >convene a meeting. The current criteria could put a burden on the AC as >it could prompt the necessity of having very frequent meetings to >perform this duty. The proposed change would allow the AC to meet no >more than monthly to perform this task. If you have comments regarding >this contemplated Board of Trustees action, please submit them to this >list no later than 5 PM Eastern Time, 3 February 2006. > >Raymond A. Plzak >President and CEO >American Registry for Internet Numbers (ARIN) > >_______________________________________________ >PPML mailing list >PPML at arin.net > >http://lists.arin.net/mailman/listinfo/ppml -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -------------- next part -------------- An HTML attachment was scrubbed... URL: From memsvcs at arin.net Thu Jan 26 18:15:17 2006 From: memsvcs at arin.net (Member Services) Date: Thu, 26 Jan 2006 18:15:17 -0500 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy Message-ID: <43D95805.2020608@arin.net> On January 26, 2006, the ARIN Advisory Council concluded its review of proposed policy 'Residential Customer Privacy' and agreed to forward it as a formal proposal for discussion by the community. This proposal is designated Policy Proposal 2006-1: Residential Customer Privacy. The policy proposal text is below and can be found at: http://www.arin.net/policy/proposals/2006_1.html All persons in the community are encouraged to discuss Policy Proposal 2006-1 in the weeks leading to the ARIN Public Policy Meeting in Montreal scheduled for April 10-11, 2006. Both the discussion on the Public Policy Mailing List and at the public policy meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal Name: Residential Customer Privacy Author: Samuel Weiler Proposal type: modify (NRPM sections 4.2.3.7.6 and 6.5.5.1) Policy Term: permanent Policy statement: An organization with downstream residential customers may substitute that organization's name for the customer's name, e.g. 'Private customer - XYZ Network', and the customer's entire address may be replaced with 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. NRPM Section 3.2 on Distributed Information Server Use Requirements (from policy proposal 2003-5) is also updated by striking the words "that includes displaying only the city, state, zip code, and country". Rationale: This policy allows for a residential customer's entire physical address to be suppressed, not just the street name and number. It also removes the US-centric phrases "state" and "zip code" from the NRPM, reflecting ARIN's broader service area. In many cases, a postal code or even a city name can identify few enough individuals, particularly considering the set of those likely to have their own IP assignments, that the intent of policy proposal 2003-3 is constructively defeated. Timetable for implementation: Immediately upon approval. From sleibrand at internap.com Thu Jan 26 19:35:33 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 26 Jan 2006 19:35:33 -0500 (EST) Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: <43D95805.2020608@arin.net> References: <43D95805.2020608@arin.net> Message-ID: I would oppose this policy proposal as written. I would, however, support a policy proposal that states that specific ZIP+4 or full postal codes are not required, but that a 5-digit ZIP code or equivalent (3-character?) postal code would suffice. -Scott On 01/26/06 at 6:15pm -0500, Member Services wrote: > On January 26, 2006, the ARIN Advisory Council concluded its review of > proposed policy 'Residential Customer Privacy' and agreed to forward > it as a formal proposal for discussion by the community. This proposal > is designated Policy Proposal 2006-1: Residential Customer Privacy. The > policy proposal text is below and can be found at: > > http://www.arin.net/policy/proposals/2006_1.html > > All persons in the community are encouraged to discuss Policy Proposal > 2006-1 in the weeks leading to the ARIN Public Policy Meeting in > Montreal scheduled for April 10-11, 2006. Both the discussion on the > Public Policy Mailing List and at the public policy meeting will be used > to determine the community consensus regarding this policy proposal. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > ARIN's Policy Proposal Archive can be found at: > http://www.arin.net/policy/proposals/proposal_archive.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal Name: Residential Customer Privacy > > Author: Samuel Weiler > > Proposal type: modify (NRPM sections 4.2.3.7.6 and 6.5.5.1) > > Policy Term: permanent > > Policy statement: > > An organization with downstream residential customers may > substitute that organization's name for the customer's name, > e.g. 'Private customer - XYZ Network', and the customer's entire > address may be replaced with 'Private Residence'. Each private > downstream residential reassignment must have accurate upstream > Abuse and Technical POCs visible on the WHOIS record for that > block. > > NRPM Section 3.2 on Distributed Information Server Use > Requirements (from policy proposal 2003-5) is also updated by > striking the words "that includes displaying only the city, state, > zip code, and country". > > Rationale: > > This policy allows for a residential customer's entire physical > address to be suppressed, not just the street name and number. It > also removes the US-centric phrases "state" and "zip code" from > the NRPM, reflecting ARIN's broader service area. > > In many cases, a postal code or even a city name can identify few > enough individuals, particularly considering the set of those > likely to have their own IP assignments, that the intent of policy > proposal 2003-3 is constructively defeated. > > Timetable for implementation: Immediately upon approval. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From william at elan.net Thu Jan 26 19:44:21 2006 From: william at elan.net (william(at)elan.net) Date: Thu, 26 Jan 2006 16:44:21 -0800 (PST) Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: <43D95805.2020608@arin.net> References: <43D95805.2020608@arin.net> Message-ID: I oppose this policy proposal. The city and state data is not specific enough as to reveal location of the user, but it is very useful for statistical & geographic analysis purposes. On Thu, 26 Jan 2006, Member Services wrote: > On January 26, 2006, the ARIN Advisory Council concluded its review of > proposed policy 'Residential Customer Privacy' and agreed to forward > it as a formal proposal for discussion by the community. This proposal > is designated Policy Proposal 2006-1: Residential Customer Privacy. The > policy proposal text is below and can be found at: > > http://www.arin.net/policy/proposals/2006_1.html > > All persons in the community are encouraged to discuss Policy Proposal > 2006-1 in the weeks leading to the ARIN Public Policy Meeting in > Montreal scheduled for April 10-11, 2006. Both the discussion on the > Public Policy Mailing List and at the public policy meeting will be used > to determine the community consensus regarding this policy proposal. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > ARIN's Policy Proposal Archive can be found at: > http://www.arin.net/policy/proposals/proposal_archive.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal Name: Residential Customer Privacy > > Author: Samuel Weiler > > Proposal type: modify (NRPM sections 4.2.3.7.6 and 6.5.5.1) > > Policy Term: permanent > > Policy statement: > > An organization with downstream residential customers may > substitute that organization's name for the customer's name, > e.g. 'Private customer - XYZ Network', and the customer's entire > address may be replaced with 'Private Residence'. Each private > downstream residential reassignment must have accurate upstream > Abuse and Technical POCs visible on the WHOIS record for that > block. > > NRPM Section 3.2 on Distributed Information Server Use > Requirements (from policy proposal 2003-5) is also updated by > striking the words "that includes displaying only the city, state, > zip code, and country". > > Rationale: > > This policy allows for a residential customer's entire physical > address to be suppressed, not just the street name and number. It > also removes the US-centric phrases "state" and "zip code" from > the NRPM, reflecting ARIN's broader service area. > > In many cases, a postal code or even a city name can identify few > enough individuals, particularly considering the set of those > likely to have their own IP assignments, that the intent of policy > proposal 2003-3 is constructively defeated. > > Timetable for implementation: Immediately upon approval. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Fri Jan 27 03:33:19 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 27 Jan 2006 00:33:19 -0800 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: <43D95805.2020608@arin.net> References: <43D95805.2020608@arin.net> Message-ID: <91344C45-4085-4252-9D90-6FDF0B125571@delong.com> As stated previously, I oppose this policy as written. I would accept a policy allowing the removal of the last 3 characters of Canadian Postal codes and providing clarification that only 5 digits of US ZIP code are required. Owen On Jan 26, 2006, at 3:15 PM, Member Services wrote: > On January 26, 2006, the ARIN Advisory Council concluded its review of > proposed policy 'Residential Customer Privacy' and agreed to forward > it as a formal proposal for discussion by the community. This proposal > is designated Policy Proposal 2006-1: Residential Customer Privacy. > The > policy proposal text is below and can be found at: > > http://www.arin.net/policy/proposals/2006_1.html > > All persons in the community are encouraged to discuss Policy Proposal > 2006-1 in the weeks leading to the ARIN Public Policy Meeting in > Montreal scheduled for April 10-11, 2006. Both the discussion on the > Public Policy Mailing List and at the public policy meeting will be > used > to determine the community consensus regarding this policy proposal. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > ARIN's Policy Proposal Archive can be found at: > http://www.arin.net/policy/proposals/proposal_archive.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal Name: Residential Customer Privacy > > Author: Samuel Weiler > > Proposal type: modify (NRPM sections 4.2.3.7.6 and 6.5.5.1) > > Policy Term: permanent > > Policy statement: > > An organization with downstream residential customers may > substitute that organization's name for the customer's name, > e.g. 'Private customer - XYZ Network', and the customer's entire > address may be replaced with 'Private Residence'. Each private > downstream residential reassignment must have accurate upstream > Abuse and Technical POCs visible on the WHOIS record for that > block. > > NRPM Section 3.2 on Distributed Information Server Use > Requirements (from policy proposal 2003-5) is also updated by > striking the words "that includes displaying only the city, > state, > zip code, and country". > > Rationale: > > This policy allows for a residential customer's entire physical > address to be suppressed, not just the street name and > number. It > also removes the US-centric phrases "state" and "zip code" from > the NRPM, reflecting ARIN's broader service area. > > In many cases, a postal code or even a city name can identify > few > enough individuals, particularly considering the set of those > likely to have their own IP assignments, that the intent of > policy > proposal 2003-3 is constructively defeated. > > Timetable for implementation: Immediately upon approval. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From sleibrand at internap.com Fri Jan 27 08:05:45 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 27 Jan 2006 08:05:45 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: <43D83093.3070306@tony.li> References: <43D83093.3070306@tony.li> Message-ID: Tony, So what do you think our IPv6 PI policy should be? Similar to our IPv4 PI policy? Or to allow PI allocations, but be more restrictive than the current IPv4 policy? Or to not allow any IPv6 PI allocations at all? And if the latter, how should enterprises multihome currently (before a good multi-IP multihoming technology like shim6 gets developed and deployed)? -Scott On 01/25/06 at 6:14pm -0800, Tony Li wrote: > > > OK, Tony...it's an architecture problem... what's the solution then. What > > architectural change can eliminate the scaling problem posed by an expanding > > PI endsite population.... or is there an alternative to PI that allows > > flexibility of endsites to benignly exchange service providers? > > > Well, the basic problem that we have to confront is that to keep the > routing subsystem scalable, we can only relay a relatively small amount > of information, regardless of the size of the network. Yes, I grant you > that this amount can and will grow slightly over time and that Moore's > law may (or may not) help us out, but any way we look at it routing must > scale about logarithmically or so. > > For that to happen, we need to be able to create topological > abstractions on the network. We need to be able to take a map of the > network, draw a big circle around various parts of it and give > everything in that circle a 'handle' for us to route on. > > Obviously, PI space flies right in the face of this. Every single PI > allocation that is ever made comes at a constant cost to the network and > covers a fixed portion of the network. Unless PI allocations > effectively never happen, any reasonable PI allocation allotment will > quickly cause a routing information explosion. > > Example 1: Suppose that a PI allocation gets a /48. Then the routing > infrastructure needs to support 2^128 / 2^80 = 2^48 (~ 3e14) information > entries. Further, that allocation is already enough to support 2^80 (~ > 1e24) hosts. The current Internet is something like 3e8 hosts, so this > is already a very large allocation. > > Example 2: We could make PI allocations much larger, such as a /32, but > then we limit either the size of the network or the number of > enterprises that are allowed to participate. Even then the routing > issue is intractable using today's technology (~ 4e9 entries). > > The basic conclusion here is pretty much straightforward: we cannot > responsibly make PI allocations without either blowing up the routing > subsystem or squandering our hard-fought extra address space. > > Given this, it follows that we need an architecture that allows us to > renumber or multi-home easily. There have been many that have been > discussed and I won't re-hash them all here, as this mail is long enough > already. > > Regards, > Tony > > From tony.li at tony.li Fri Jan 27 08:13:16 2006 From: tony.li at tony.li (Tony Li) Date: Fri, 27 Jan 2006 05:13:16 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: <43D83093.3070306@tony.li> Message-ID: <43DA1C6C.3090909@tony.li> > So what do you think our IPv6 PI policy should be? Similar to our IPv4 PI > policy? Or to allow PI allocations, but be more restrictive than the > current IPv4 policy? Or to not allow any IPv6 PI allocations at all? > And if the latter, how should enterprises multihome currently (before a > good multi-IP multihoming technology like shim6 gets developed and > deployed)? Scott, It is my very serious and professional opinion that IPv6 is simply not ready for deployment. The lack of a workable routing architecture makes any roll out simply premature and a deterrent to the future deployment of a real solution. Regards, Tony From jb at jbacher.com Fri Jan 27 10:01:02 2006 From: jb at jbacher.com (J Bacher) Date: Fri, 27 Jan 2006 09:01:02 -0600 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: <43D95805.2020608@arin.net> References: <43D95805.2020608@arin.net> Message-ID: <43DA35AE.10401@jbacher.com> Member Services wrote: > On January 26, 2006, the ARIN Advisory Council concluded its review of > proposed policy 'Residential Customer Privacy' and agreed to forward > it as a formal proposal for discussion by the community. This proposal > is designated Policy Proposal 2006-1: Residential Customer Privacy. The > policy proposal text is below and can be found at: > > http://www.arin.net/policy/proposals/2006_1.html > Policy Proposal Name: Residential Customer Privacy > > Author: Samuel Weiler > > Proposal type: modify (NRPM sections 4.2.3.7.6 and 6.5.5.1) > > Policy Term: permanent This is a necessity. A "non-pub, non-listed" ip address is no less important than a telephone number. Individuals are entitled to privacy and, if the ISP is willing to take responsibility, there should be no problem. I support this 100%. From jb at jbacher.com Fri Jan 27 10:06:29 2006 From: jb at jbacher.com (J Bacher) Date: Fri, 27 Jan 2006 09:06:29 -0600 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: References: <43D95805.2020608@arin.net> Message-ID: <43DA36F5.8000005@jbacher.com> william(at)elan.net wrote: > I oppose this policy proposal. The city and state data is not specific > enough as to reveal location of the user, but it is very useful for > statistical & geographic analysis purposes. Privacy shouldn't be compromised because you or others want demographic information. Maybe city and state aren't important to you. I live in a town of 750 and don't grunge my email address. Had I chosen to keep my address information private, the disclosure of city and state to assist nutcases would be a serious problem. From paul at vix.com Fri Jan 27 10:07:32 2006 From: paul at vix.com (Paul Vixie) Date: Fri, 27 Jan 2006 15:07:32 +0000 Subject: [ppml] 2005-1 status In-Reply-To: Your message of "Fri, 27 Jan 2006 05:13:16 PST." <43DA1C6C.3090909@tony.li> References: <43D83093.3070306@tony.li> <43DA1C6C.3090909@tony.li> Message-ID: <20060127150732.A3B0711425@sa.vix.com> tony wrote: # It is my very serious and professional opinion that IPv6 is simply not # ready for deployment. The lack of a workable routing architecture makes # any roll out simply premature and a deterrent to the future deployment # of a real solution. while i feel pretty much the same way, this refrain has been sung at ietf meetings and elsewhere since before the IPng decision was first taken. it is therefore a moot assessment, no matter whether accurate or not. so the question is, given that it's not deployable, how shall we deploy it? paul From billd at cait.wustl.edu Fri Jan 27 12:05:11 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Fri, 27 Jan 2006 11:05:11 -0600 Subject: [ppml] 2005-1 status Message-ID: > > tony wrote: > > # It is my very serious and professional opinion that IPv6 is > simply not # ready for deployment. The lack of a workable > routing architecture makes # any roll out simply premature > and a deterrent to the future deployment # of a real solution. > > while i feel pretty much the same way, this refrain has been > sung at ietf meetings and elsewhere since before the IPng > decision was first taken. it is therefore a moot assessment, > no matter whether accurate or not. > > so the question is, given that it's not deployable, how shall > we deploy it? > > paul I think this is exactly the right perspective. Serious early adopters need to seriously try to deploy this technology and tabulate the concrete and prioritized list of gotchas that make its pervasive debut DOA. If it takes providing PI address blocks to those early interests to early adopt...then so be it. bd From sleibrand at internap.com Fri Jan 27 12:01:10 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 27 Jan 2006 12:01:10 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: On 01/27/06 at 11:05am -0600, Bill Darte wrote: > > > It is my very serious and professional opinion that IPv6 is simply > > > not ready for deployment. The lack of a workable routing > > > architecture makes any roll out simply premature and a deterrent to > > > the future deployment of a real solution. > > > > so the question is, given that it's not deployable, how shall > > we deploy it? > > I think this is exactly the right perspective. Serious early adopters need > to seriously try to deploy this technology and tabulate the concrete and > prioritized list of gotchas that make its pervasive debut DOA. If it takes > providing PI address blocks to those early interests to early adopt...then > so be it. While I'm not sure I agree that IPv6 is DOA or undeployable, I agree with Paul and Bill that deployment is a necessity, given the lack of good alternatives (more NAT, IPv4 titles and markets, etc.). So what do IPv6 skeptics think about IPv6 PI allocations? Should we avoid them entirely? Make them using similar rules to IPv4 PI? Or something else? Do you even care, since you think IPv6 won't work anyway? -Scott From randy at psg.com Fri Jan 27 12:02:24 2006 From: randy at psg.com (Randy Bush) Date: Fri, 27 Jan 2006 09:02:24 -0800 Subject: [ppml] 2005-1 status References: <43D83093.3070306@tony.li> <43DA1C6C.3090909@tony.li> <20060127150732.A3B0711425@sa.vix.com> Message-ID: <17370.21024.239971.607826@roam.psg.com> > so the question is, given that it's not deployable, how shall we > deploy it? google did not give me a url for a manual for snake oil sales techniques. can we borrow from some other field of foisting the unusable on the unsuspecting? rand From paul at vix.com Fri Jan 27 12:54:38 2006 From: paul at vix.com (Paul Vixie) Date: Fri, 27 Jan 2006 17:54:38 +0000 Subject: [ppml] 2005-1 status In-Reply-To: Your message of "Fri, 27 Jan 2006 12:01:10 EST." References: Message-ID: <20060127175438.7BFA411425@sa.vix.com> # > ... Serious early adopters need to seriously try to deploy this technology # > and tabulate the concrete and prioritized list of gotchas ... If it takes # > providing PI address blocks to those early interests to early adopt...then # > so be it. that's what it's going to take. the thing the internet address-consuming community doesn't know, and lacks the discipline and/or will and/or funding to find out, is whether the vast majority of address space consumption will be through access providers (cable, dsl, 3G, mumble) who have no plan to ever route third-party address space. if that turns out to be true, then the "PI problem" will end up having been a gnat on the ass of the elephant, and we'll see neither a run on address space and ASNs, nor a routing table explosion. if that turns out to be false (which is what i have long feared and still expect), then IPv6 is going to create more problems than it solves, have a short useless live, die young, and leave a good looking corpse. no matter whether that assumption be true or false, the address-consuming community has no choice but to deploy IPv6 as-specified. we won't be telling IETF "sorry, nope, come back when you have something routeable". we won't be adopting SHIM6 as our work item. we have to play the cards we were dealt, which means in this case, IPv6 PI space for anyone who qualifies. and the only rules we have for qualification are all based on our IPv4 experiences. so, i support 2005-1 as written. i would also support fine-tuning of it. From dgolding at burtongroup.com Fri Jan 27 12:59:05 2006 From: dgolding at burtongroup.com (Daniel Golding) Date: Fri, 27 Jan 2006 12:59:05 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <17370.21024.239971.607826@roam.psg.com> Message-ID: On 1/27/06 12:02 PM, "Randy Bush" wrote: >> so the question is, given that it's not deployable, how shall we >> deploy it? > > google did not give me a url for a manual for snake oil sales > techniques. can we borrow from some other field of foisting > the unusable on the unsuspecting? > > rand > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml Wrong query. Try this: http://www.google.com/search?client=safari&rls=en&q=used+car+sales+technique s&ie=UTF-8&oe=UTF-8 - Dan From Suzanne_Woolf at isc.org Fri Jan 27 13:22:23 2006 From: Suzanne_Woolf at isc.org (Suzanne Woolf) Date: Fri, 27 Jan 2006 18:22:23 +0000 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: <43DA36F5.8000005@jbacher.com> References: <43D95805.2020608@arin.net> <43DA36F5.8000005@jbacher.com> Message-ID: <20060127182223.GB81886@farside.isc.org> On Fri, Jan 27, 2006 at 09:06:29AM -0600, J Bacher wrote: > william(at)elan.net wrote: > > I oppose this policy proposal. The city and state data is not specific > > enough as to reveal location of the user, but it is very useful for > > statistical & geographic analysis purposes. > > Privacy shouldn't be compromised because you or others want demographic > information. If people want to disclose such information, including for the purpose of aiding research, more power to them. But the argument here isn't about whether people can disclose the information if they want to-- the policy proposal says "may", not "must", about suppressing the details. It's about whether they can choose not to disclose it if they don't want to. Other people's opinions about whether users *should* want to disclose their location information-- because it's for a good cause, or because we don't believe partial information is enough to reveal the user's location, or because it's easier to find them and tell them when their machine has been hijacked and their IP address appears in an attack trace-- are beside the point. I don't think it's up to me or ARIN to judge William's reasons for wanting the data or Jan's reasons for preferring to suppress it. They can argue between themselves about that. The question in front of us is just whether ARIN's rules will allow for both choices or continue to require disclosure a user may not want to make. I have every sympathy with the "research" justification. I've used it myself, and been very disappointed when data I knew would be useful to have could not legally be disclosed to me because it was considered private in the jurisdiction where it was collected. However, that research interest is not more important than a residential user's right to obscure their location from whois should they and their ISP so choose. Suzanne From billd at cait.wustl.edu Fri Jan 27 13:46:30 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Fri, 27 Jan 2006 12:46:30 -0600 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy Message-ID: > > On Fri, Jan 27, 2006 at 09:06:29AM -0600, J Bacher wrote: > > william(at)elan.net wrote: > > > I oppose this policy proposal. The city and state data is not > > > specific enough as to reveal location of the user, but it is very > > > useful for statistical & geographic analysis purposes. > > > > Privacy shouldn't be compromised because you or others want > > demographic > > information. > > If people want to disclose such information, including for > the purpose of aiding research, more power to them. But the > argument here isn't about whether people can disclose the > information if they want to-- the policy proposal says "may", > not "must", about suppressing the details. It's about whether > they can choose not to disclose it if they don't want to. > > Other people's opinions about whether users *should* want to > disclose their location information-- because it's for a good > cause, or because we don't believe partial information is > snip > > Suzanne The proposal also states "must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block." Is this the case now? Assuming that this were NOT the case...that it couldn't/didn't get enforced...would this have any bearing on the advisability of implementing 2006-1 Bill Darte ARIN AC From weiler at tislabs.com Fri Jan 27 16:45:39 2006 From: weiler at tislabs.com (Sam Weiler) Date: Fri, 27 Jan 2006 13:45:39 -0800 (PST) Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Bill Darte wrote: > The proposal also states "must have accurate upstream > Abuse and Technical POCs visible on the WHOIS record for that > block." > > Is this the case now? Assuming that this were NOT the case...that it > couldn't/didn't get enforced...would this have any bearing on the > advisability of implementing 2006-1 That language is in NRPM sections 4.2.3.7.6. and 6.5.5.1. and it was in policy proposal 2003-3. I'm not sure what the policy was before that, but I'd be very curious to know. http://www.arin.net/policy/proposals/2003_3.html Again, 2006-1 does not change the current policy in this regard. -- Sam Weiler From arin-member at quadrix.com Fri Jan 27 14:18:16 2006 From: arin-member at quadrix.com (Bill Van Emburg) Date: Fri, 27 Jan 2006 13:18:16 -0600 Subject: [ppml] PPML Digest, Vol 7, Issue 30 In-Reply-To: References: Message-ID: <43DA71F8.9060707@quadrix.com> I, too, oppose 2006-1 as written, but would support a proposal such as the one outlined below by Scott. -Bill Van Emburg Quadrix Solutions, Inc. > ------------------------------ > > Message: 2 > Date: Thu, 26 Jan 2006 19:35:33 -0500 (EST) > From: Scott Leibrand > Subject: Re: [ppml] Policy Proposal 2006-1: Residential Customer > Privacy > To: ppml at arin.net > Message-ID: > > Content-Type: TEXT/PLAIN; charset=US-ASCII > > I would oppose this policy proposal as written. > > I would, however, support a policy proposal that states that specific > ZIP+4 or full postal codes are not required, but that a 5-digit ZIP > code or equivalent (3-character?) postal code would suffice. > > -Scott > From jb at jbacher.com Fri Jan 27 14:34:58 2006 From: jb at jbacher.com (J Bacher) Date: Fri, 27 Jan 2006 13:34:58 -0600 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: <20060127182223.GB81886@farside.isc.org> References: <43D95805.2020608@arin.net> <43DA36F5.8000005@jbacher.com> <20060127182223.GB81886@farside.isc.org> Message-ID: <43DA75E2.8030101@jbacher.com> Suzanne Woolf wrote: > Other people's opinions about whether users *should* want to disclose > their location information-- because it's for a good cause, or because > we don't believe partial information is enough to reveal the user's > location, or because it's easier to find them and tell them when their > machine has been hijacked and their IP address appears in an attack > trace-- are beside the point. I don't think it's up to me or ARIN to > judge William's reasons for wanting the data or Jan's reasons for > preferring to suppress it. They can argue between themselves about Thanks for an excellent post. I should clarify that I am not for the requirement that residential data be completely private -- just that the option for complete privacy should exist. From jb at jbacher.com Fri Jan 27 14:44:03 2006 From: jb at jbacher.com (J Bacher) Date: Fri, 27 Jan 2006 13:44:03 -0600 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: References: Message-ID: <43DA7803.2000904@jbacher.com> Bill Darte wrote: > The proposal also states "must have accurate upstream > Abuse and Technical POCs visible on the WHOIS record for that > block." > > Is this the case now? Assuming that this were NOT the case...that it > couldn't/didn't get enforced...would this have any bearing on the > advisability of implementing 2006-1 None whatsoever. If a company isn't going to keep its contact information updated, why would we think that it would even SWIP/rwhois new data? And, that it would even care about the policy of it did? From kloch at hotnic.net Sun Jan 29 22:39:04 2006 From: kloch at hotnic.net (Kevin Loch) Date: Sun, 29 Jan 2006 22:39:04 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com> References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> <43D4FC2C.60903@hotnic.net> <031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com> Message-ID: <43DD8A58.9030908@hotnic.net> This is the latest draft for the revision of 2005-1. We are interested in feedback before we submit it as the formal revision. For qualification purposes it is much closer to the original 2005-1. Unlike any previous version assignment size is variable (explained in the justification section). Add new definition in section 6.2 of the NRPM: 6.2.10 Physical Location A distinct physical location is identified by a unique street address within an organization. Different apartment, suite, room, unit or other similar identifiers at the same address for the same organization are not considered unique. Add new subsection in section 6.5 of the NRPM: 6.5.8. Direct assignments to large/multihomed end sites 6.5.8.1. To qualify for a direct assignment, an organization must: a) not be an IPv6 LIR; b) meet at least ONE of the following requirements: 1) Have an IPv4 assignment or allocation directly from an RIR, the IANA or legacy registry 2) Qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect 3) Be currently multihomed using IPv6 to two or more separate LIR's using at least one /48 assigned to them by each LIR. 6.5.8.2. Direct assignment size to large/multihomed end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment. The size of the assignment is based on the number of distinct physical locations where the assignment will be used. The following table will be used to determine the assignment size: +-------------------------+ | Locations | Assignment | +------------+------------+ | 1-13 | /44 | | 14-183 | /40 | | 184-2486 | /36 | | 2487-33688 | /32 | +------------+------------+ For organizations requesting an assignment shorter than /32 the HD ratio method will be used. For the HD ratio the utilization threshold is based on the numbmer of distinct physical locations that will be using IPv6. The HD ratio used will be the same as in section 6.5.2.2. 6.5.8.3. Subsequent Assignment Size An organization may receive an additional assignment when it has grown to include enough distinct physical locations to justify the larger assignment. Where possible, the assignment will be made from an adjacent address block. Justification: In IPv4 policy there are three major types of organizations that addresses are delegated to. o ISP's receive allocations directly from ARIN or from other ISP's o End Users receive assignments from ISP's o "Large" and/or multihomed End Users may receive assignments directly from ARIN. The third category is currently missing from IPv6 policy and this is believed to be severely hindering deployment by those organizations. In IPv6 policy-speak: o LIR's receive allocations directly from ARIN o End Sites receive assignments from LIR's This policy proposes: o "Large" and/or multihomed End Sites receive assignments directly from ARIN. This policy applies to organizations with networks that are large and/or complex enough to justify direct assignments. Like their IPv4 counterparts they do not make assignments to external organizations. They instead assign space internally to their own facilities. Similarly to IPv4 These internal assignments are not submitted to ARIN via swip/rwhois. A IPv6 network is considered eligible if it is multihomed. For transition purposes an organization with an IPv4 assignment or allocation from an RIR (or the legacy RIR) is automatically considered elligible, regardless of whether they were considered an ISP or End User under IPv4 policy. It is expected that the IPv6 only (non transition) requirements will be further refined as experience is gained. Since no /48's are assigned to external organizations, assignment size is determined solely by the number of distinct physical locations to be served (based on the 1 /48 per POP precedent for LIR's). It is expected that almost all assignments will fall between /44-/32. That assignment range has been limited to nibble boundaries to simplify reverse dns. The assignment thresholds for that range were determined using an HD ratio of 0.94 in accordance with 2005-5. A minimum assignment size of /44 is proposed to allow for some growth and flexibility of use for the smallest applicants. /32's are not assigned by default because it would be unnecessarilly wasteful for the vast majority of assignments. - Kevin From tme at multicasttech.com Mon Jan 30 05:54:37 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 30 Jan 2006 05:54:37 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <43DD8A58.9030908@hotnic.net> References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> <43D4FC2C.60903@hotnic.net> <031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com> <43DD8A58.9030908@hotnic.net> Message-ID: So, just to be clear, a site that is multihomed and in one physical location will get a /44 ? Regards Marshall On Jan 29, 2006, at 10:39 PM, Kevin Loch wrote: > This is the latest draft for the revision of 2005-1. We > are interested in feedback before we submit it as the > formal revision. For qualification purposes it is much > closer to the original 2005-1. Unlike any previous version > assignment size is variable (explained in the justification > section). > > Add new definition in section 6.2 of the NRPM: > > 6.2.10 Physical Location > > A distinct physical location is identified by a unique street > address within an organization. Different apartment, suite, > room, > unit or other similar identifiers at the same address for the > same > organization are not considered unique. > > Add new subsection in section 6.5 of the NRPM: > > 6.5.8. Direct assignments to large/multihomed end sites > > 6.5.8.1. To qualify for a direct assignment, an > organization must: > > a) not be an IPv6 LIR; > b) meet at least ONE of the following requirements: > > 1) Have an IPv4 assignment or allocation directly from an > RIR, > the IANA or legacy registry > 2) Qualify for an IPv4 assignment or allocation from ARIN > under > the IPv4 policy currently in effect > 3) Be currently multihomed using IPv6 to two or more separate > LIR's using at least one /48 assigned to them by each LIR. > > 6.5.8.2. Direct assignment size to large/multihomed end sites > > Organizations that meet the direct end site assignment > criteria > are eligible to receive a direct assignment. The size of the > assignment is based on the number of distinct physical > locations > where the assignment will be used. The following table > will be > used to determine the assignment size: > > +-------------------------+ > | Locations | Assignment | > +------------+------------+ > | 1-13 | /44 | > | 14-183 | /40 | > | 184-2486 | /36 | > | 2487-33688 | /32 | > +------------+------------+ > > For organizations requesting an assignment shorter than / > 32 the > HD ratio method will be used. For the HD ratio the > utilization > threshold is based on the numbmer of distinct physical > locations that will be using IPv6. The HD ratio used > will be > the same as in section 6.5.2.2. > > 6.5.8.3. Subsequent Assignment Size > > An organization may receive an additional assignment > when it > has grown to include enough distinct physical locations to > justify the larger assignment. Where possible, the > assignment > will be made from an adjacent address block. > > Justification: > > In IPv4 policy there are three major types of organizations that > addresses are delegated to. > > o ISP's receive allocations directly from ARIN or from other ISP's > o End Users receive assignments from ISP's > o "Large" and/or multihomed End Users may receive assignments > directly > from ARIN. > > The third category is currently missing from IPv6 policy and > this is believed to be severely hindering deployment by those > organizations. In IPv6 policy-speak: > > o LIR's receive allocations directly from ARIN > o End Sites receive assignments from LIR's > > This policy proposes: > > o "Large" and/or multihomed End Sites receive assignments directly > from ARIN. > > This policy applies to organizations with networks that are > large and/or complex enough to justify direct assignments. Like their > IPv4 counterparts they do not make assignments to external > organizations. They instead assign space internally to their own > facilities. Similarly to IPv4 These internal assignments are not > submitted to ARIN via swip/rwhois. > > A IPv6 network is considered eligible if it is multihomed. > For transition purposes an organization with an IPv4 assignment or > allocation from an RIR (or the legacy RIR) is automatically considered > elligible, regardless of whether they were considered an ISP or End > User under IPv4 policy. It is expected that the IPv6 only (non > transition) requirements will be further refined as experience is > gained. > > Since no /48's are assigned to external organizations, assignment size > is determined solely by the number of distinct physical locations > to be > served (based on the 1 /48 per POP precedent for LIR's). It is > expected > that almost all assignments will fall between /44-/32. That assignment > range has been limited to nibble boundaries to simplify reverse dns. > The assignment thresholds for that range were determined using an HD > ratio of 0.94 in accordance with 2005-5. A minimum assignment size of > /44 is proposed to allow for some growth and flexibility of use for > the > smallest applicants. /32's are not assigned by default because it > would > be unnecessarilly wasteful for the vast majority of assignments. > > - Kevin > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From randy at psg.com Mon Jan 30 05:59:38 2006 From: randy at psg.com (Randy Bush) Date: Mon, 30 Jan 2006 02:59:38 -0800 Subject: [ppml] 2005-1 status References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> <43D4FC2C.60903@hotnic.net> <031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com> <43DD8A58.9030908@hotnic.net> Message-ID: <17373.61850.688577.934431@roam.psg.com> > So, just to be clear, a site that is multihomed and in one physical > location will get a /44 ? thanks for asking. this is the bit that confuses me the most. i thought that this was precisely where the /48 break point was intended. i am confused here somewhere. randy From kloch at hotnic.net Mon Jan 30 09:56:31 2006 From: kloch at hotnic.net (Kevin Loch) Date: Mon, 30 Jan 2006 09:56:31 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <17373.61850.688577.934431@roam.psg.com> References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> <43D4FC2C.60903@hotnic.net> <031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com> <43DD8A58.9030908@hotnic.net> <17373.61850.688577.934431@roam.psg.com> Message-ID: <43DE291F.4030101@hotnic.net> Randy Bush wrote: >> So, just to be clear, a site that is multihomed and in one physical >> location will get a /44 ? > > thanks for asking. this is the bit that confuses me the most. > i thought that this was precisely where the /48 break point was > intended. i am confused here somewhere. Using the HD-ratio the utilization threshold for /48 is 1 which means a 47 is justified, upgraded to /44 by nibble alignment. For comparison, IPv4 policy requires only 50% initial utilization, IPv6 LIR policy requires 0% initial utilization and at most 0.3% after a few years. Giving some room to grow helps avoid fragmentation. - Kevin From randy at psg.com Mon Jan 30 10:39:07 2006 From: randy at psg.com (Randy Bush) Date: Mon, 30 Jan 2006 07:39:07 -0800 Subject: [ppml] 2005-1 status References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> <43D4FC2C.60903@hotnic.net> <031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com> <43DD8A58.9030908@hotnic.net> <17373.61850.688577.934431@roam.psg.com> <43DE291F.4030101@hotnic.net> Message-ID: <17374.13083.250518.996959@roam.psg.com> >>> So, just to be clear, a site that is multihomed and in one physical >>> location will get a /44 ? >> thanks for asking. this is the bit that confuses me the most. >> i thought that this was precisely where the /48 break point was >> intended. i am confused here somewhere. > Using the HD-ratio the utilization threshold for /48 is 1 which means a > 47 is justified, upgraded to /44 by nibble alignment. how can you apply an hd ration when you do not know their actual need. whatever it may be, i have this wild guess that it is not for 2^48 hosts. and why not to a /40, for byte alignment? or a /32 for half-word? i don't know what we're smoking here, but i know what we're burning. address space. and it is not an infinite resource. randy From Lee.Howard at stanleyassociates.com Mon Jan 30 11:24:51 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 30 Jan 2006 11:24:51 -0500 Subject: [ppml] 2005-1 status Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4012CB9CD@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Kevin Loch > 6.2.10 Physical Location Geography, not topology? > 6.5.8. Direct assignments to large/multihomed end sites > > 6.5.8.1. To qualify for a direct assignment, an > organization must: Are these ANDs or ORs? > a) not be an IPv6 LIR; > b) meet at least ONE of the following requirements: > > 1) Have an IPv4 assignment or allocation directly > from an RIR, the IANA or legacy registry No justification is necessary? The RIRs required justification, but pre-RIR was classy. > 2) Qualify for an IPv4 assignment or allocation from > ARIN under the IPv4 policy currently in effect In addition to currently-held space, or justifying currently-held space? > 3) Be currently multihomed using IPv6 to two or more separate > LIR's using at least one /48 assigned to them by each LIR. IPv4 policy says "intent to multihome" or something like that. It's all right with me as is. > +-------------------------+ > | Locations | Assignment | > +------------+------------+ > | 1-13 | /44 | > | 14-183 | /40 | > | 184-2486 | /36 | > | 2487-33688 | /32 | > +------------+------------+ > A 13-site organization needs a million subnets? > For organizations requesting an assignment shorter > than /32 the > HD ratio method will be used. For the HD ratio the > utilization > threshold is based on the numbmer of distinct physical > locations that will be using IPv6. The HD ratio > used will be the same as in section 6.5.2.2. I don't understand. Are you counting hosts (Host Density) or sites? > 6.5.8.3. Subsequent Assignment Size > > An organization may receive an additional > assignment when it > has grown to include enough distinct physical locations to > justify the larger assignment. Where possible, the > assignment > will be made from an adjacent address block. Why not use HD-ratio? Or topology? Lee From stephen at sprunk.org Mon Jan 30 14:21:21 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 30 Jan 2006 13:21:21 -0600 Subject: [ppml] 2005-1 status References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com><43D4FC2C.60903@hotnic.net><031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com><43DD8A58.9030908@hotnic.net> <17373.61850.688577.934431@roam.psg.com> Message-ID: <014701c625d2$5ac44590$700016ac@ssprunk> Thus spake "Randy Bush" >> So, just to be clear, a site that is multihomed and in one physical >> location will get a /44 ? > > thanks for asking. this is the bit that confuses me the most. > i thought that this was precisely where the /48 break point was > intended. i am confused here somewhere. Are we really proposing that a leaf organization get a /48 per location? I think the rest of the proposal is a step in the right direction, but I have a hard time rationalizing more than a /48 per single leaf org unless they justify the need for more subnets. Think about it: McDonalds would qualify for a /31 (or so) under this proposal, as much or more than most ISPs. They'd be able to assign a /64 to _every hamburger they sell_, not just the stores. While I'm sure that would be entertaining, is this a reasonable policy direction? 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 tme at multicasttech.com Mon Jan 30 14:41:31 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 30 Jan 2006 14:41:31 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <014701c625d2$5ac44590$700016ac@ssprunk> References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com><43D4FC2C.60903@hotnic.net><031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com><43DD8A58.9030908@hotnic.net> <17373.61850.688577.934431@roam.psg.com> <014701c625d2$5ac44590$700016ac@ssprunk> Message-ID: <8DE2C291-F532-4293-90B9-15E1F340A6F2@multicasttech.com> I would support the proposal in general, but why shouldn't a leaf organization get a /48 ( = a /16 in IPv4) if they don't demonstrate a need for more ? I certainly could be convinced otherwise, but is there a real reason why not ? Regards Marshall On Jan 30, 2006, at 2:21 PM, Stephen Sprunk wrote: > Thus spake "Randy Bush" >>> So, just to be clear, a site that is multihomed and in one physical >>> location will get a /44 ? >> >> thanks for asking. this is the bit that confuses me the most. >> i thought that this was precisely where the /48 break point was >> intended. i am confused here somewhere. > > Are we really proposing that a leaf organization get a /48 per > location? > > I think the rest of the proposal is a step in the right direction, > but I have a hard time rationalizing more than a /48 per single > leaf org unless they justify the need for more subnets. > > Think about it: McDonalds would qualify for a /31 (or so) under > this proposal, as much or more than most ISPs. They'd be able to > assign a /64 to _every hamburger they sell_, not just the stores. > While I'm sure that would be entertaining, is this a reasonable > policy direction? > > 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 packetgrrl at gmail.com Mon Jan 30 14:52:19 2006 From: packetgrrl at gmail.com (cja@daydream.com) Date: Mon, 30 Jan 2006 12:52:19 -0700 Subject: [ppml] 2005-1 status In-Reply-To: <43DD8A58.9030908@hotnic.net> References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> <43D4FC2C.60903@hotnic.net> <031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com> <43DD8A58.9030908@hotnic.net> Message-ID: Kevin, I have a question.. with regard to item Have an IPv4 assignment or allocation directly from an RIR, the IANA or legacy registry Qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect do you really mean an assignment or allocation under ANY policy in effect? If an org has a micro allocation from ARIN of some very small size they should still qualify for a /44? I am not passing any judgement here I am just curious. Thanks ---Cathy On 1/29/06, Kevin Loch wrote: > > This is the latest draft for the revision of 2005-1. We > are interested in feedback before we submit it as the > formal revision. For qualification purposes it is much > closer to the original 2005-1. Unlike any previous version > assignment size is variable (explained in the justification > section). > > Add new definition in section 6.2 of the NRPM: > > 6.2.10 Physical Location > > A distinct physical location is identified by a unique street > address within an organization. Different apartment, suite, room, > unit or other similar identifiers at the same address for the same > organization are not considered unique. > > Add new subsection in section 6.5 of the NRPM: > > 6.5.8. Direct assignments to large/multihomed end sites > > 6.5.8.1. To qualify for a direct assignment, an > organization must: > > a) not be an IPv6 LIR; > b) meet at least ONE of the following requirements: > > 1) Have an IPv4 assignment or allocation directly from an RIR, > the IANA or legacy registry > 2) Qualify for an IPv4 assignment or allocation from ARIN under > the IPv4 policy currently in effect > 3) Be currently multihomed using IPv6 to two or more separate > LIR's using at least one /48 assigned to them by each LIR. > > 6.5.8.2. Direct assignment size to large/multihomed end sites > > Organizations that meet the direct end site assignment criteria > are eligible to receive a direct assignment. The size of the > assignment is based on the number of distinct physical locations > where the assignment will be used. The following table will be > used to determine the assignment size: > > +-------------------------+ > | Locations | Assignment | > +------------+------------+ > | 1-13 | /44 | > | 14-183 | /40 | > | 184-2486 | /36 | > | 2487-33688 | /32 | > +------------+------------+ > > For organizations requesting an assignment shorter than /32 the > HD ratio method will be used. For the HD ratio the utilization > threshold is based on the numbmer of distinct physical > locations that will be using IPv6. The HD ratio used will be > the same as in section 6.5.2.2. > > 6.5.8.3. Subsequent Assignment Size > > An organization may receive an additional assignment when it > has grown to include enough distinct physical locations to > justify the larger assignment. Where possible, the assignment > will be made from an adjacent address block. > > Justification: > > In IPv4 policy there are three major types of organizations that > addresses are delegated to. > > o ISP's receive allocations directly from ARIN or from other ISP's > o End Users receive assignments from ISP's > o "Large" and/or multihomed End Users may receive assignments directly > from ARIN. > > The third category is currently missing from IPv6 policy and > this is believed to be severely hindering deployment by those > organizations. In IPv6 policy-speak: > > o LIR's receive allocations directly from ARIN > o End Sites receive assignments from LIR's > > This policy proposes: > > o "Large" and/or multihomed End Sites receive assignments directly > from ARIN. > > This policy applies to organizations with networks that are > large and/or complex enough to justify direct assignments. Like their > IPv4 counterparts they do not make assignments to external > organizations. They instead assign space internally to their own > facilities. Similarly to IPv4 These internal assignments are not > submitted to ARIN via swip/rwhois. > > A IPv6 network is considered eligible if it is multihomed. > For transition purposes an organization with an IPv4 assignment or > allocation from an RIR (or the legacy RIR) is automatically considered > elligible, regardless of whether they were considered an ISP or End > User under IPv4 policy. It is expected that the IPv6 only (non > transition) requirements will be further refined as experience is > gained. > > Since no /48's are assigned to external organizations, assignment size > is determined solely by the number of distinct physical locations to be > served (based on the 1 /48 per POP precedent for LIR's). It is expected > that almost all assignments will fall between /44-/32. That assignment > range has been limited to nibble boundaries to simplify reverse dns. > The assignment thresholds for that range were determined using an HD > ratio of 0.94 in accordance with 2005-5. A minimum assignment size of > /44 is proposed to allow for some growth and flexibility of use for the > smallest applicants. /32's are not assigned by default because it would > be unnecessarilly wasteful for the vast majority of assignments. > > - Kevin > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.feldman at cnet.com Mon Jan 30 15:11:57 2006 From: steven.feldman at cnet.com (Steve Feldman) Date: Mon, 30 Jan 2006 12:11:57 -0800 Subject: [ppml] 2005-1 status In-Reply-To: <43DD8A58.9030908@hotnic.net> References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> <43D4FC2C.60903@hotnic.net> <031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com> <43DD8A58.9030908@hotnic.net> Message-ID: <5194AA57-0BF6-41AE-83AC-158BFBEE3041@cnet.com> > > 6.5.8.2. Direct assignment size to large/multihomed end sites > > Organizations that meet the direct end site assignment > criteria > are eligible to receive a direct assignment. The size of the > assignment is based on the number of distinct physical > locations > where the assignment will be used. The following table > will be > used to determine the assignment size: > > +-------------------------+ > | Locations | Assignment | > +------------+------------+ > | 1-13 | /44 | > | 14-183 | /40 | > | 184-2486 | /36 | > | 2487-33688 | /32 | > +------------+------------+ > > For organizations requesting an assignment shorter than / > 32 the > HD ratio method will be used. For the HD ratio the > utilization > threshold is based on the numbmer of distinct physical > locations that will be using IPv6. The HD ratio used > will be > the same as in section 6.5.2.2. How would this work for a hypothetical example: Entity X has four distinct physical locations: Locations A and B are interconnected and share upstream providers. Locations C and D are each far away from the others, not interconnected, and may have distinct sets of upstream providers. What would the assignment(s) for these look like? More to the point, if a single /44 is assigned, is the expectation that longer prefixes announced from the various locations would be routable? Steve From kloch at hotnic.net Mon Jan 30 15:49:40 2006 From: kloch at hotnic.net (Kevin Loch) Date: Mon, 30 Jan 2006 15:49:40 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <014701c625d2$5ac44590$700016ac@ssprunk> References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com><43D4FC2C.60903@hotnic.net><031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com><43DD8A58.9030908@hotnic.net> <17373.61850.688577.934431@roam.psg.com> <014701c625d2$5ac44590$700016ac@ssprunk> Message-ID: <43DE7BE4.2000008@hotnic.net> Stephen Sprunk wrote: > Thus spake "Randy Bush" >>> So, just to be clear, a site that is multihomed and in one physical >>> location will get a /44 ? >> thanks for asking. this is the bit that confuses me the most. >> i thought that this was precisely where the /48 break point was >> intended. i am confused here somewhere. > > Are we really proposing that a leaf organization get a /48 per location? My memory of the last meeting is a bit foggy but I distinctly remember that as a suggestion by several people. I think it came out of the "one size does not fit all", and "host counts are stupid, why not count subnets or locations" train of thought. > Think about it: McDonalds would qualify for a /31 (or so) under this > proposal, as much or more than most ISPs. They'd be able to assign a /64 to > _every hamburger they sell_, not just the stores. While I'm sure that would > be entertaining, is this a reasonable policy direction? I'm not privy to how they connect their resturaunts. It is conceivable that each franchise would be responsible for getting internet service on their own. In that case you would have a /48 per restaurant. If The parent corp was providing IPv6 to each resturaunt they could become an LIR, get a /32 and issue /48's to franchisees who are separate organizations. - Kevin From kloch at hotnic.net Mon Jan 30 15:51:25 2006 From: kloch at hotnic.net (Kevin Loch) Date: Mon, 30 Jan 2006 15:51:25 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <5194AA57-0BF6-41AE-83AC-158BFBEE3041@cnet.com> References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> <43D4FC2C.60903@hotnic.net> <031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com> <43DD8A58.9030908@hotnic.net> <5194AA57-0BF6-41AE-83AC-158BFBEE3041@cnet.com> Message-ID: <43DE7C4D.2000909@hotnic.net> Steve Feldman wrote: > How would this work for a hypothetical example: > > Entity X has four distinct physical locations: > Locations A and B are interconnected and share upstream providers. > > Locations C and D are each far away from the others, not > interconnected, and may have distinct sets of upstream providers. > > What would the assignment(s) for these look like? > More to the point, if a single /44 is assigned, is the expectation > that longer prefixes announced from the various locations would > be routable? I believe that is what the folks that suggested a location based scalar were thinking. Whether it would work or not depends on routing policies that aren't really in the scope of RIR policy. - Kevin From kloch at hotnic.net Mon Jan 30 15:55:32 2006 From: kloch at hotnic.net (Kevin Loch) Date: Mon, 30 Jan 2006 15:55:32 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> <43D4FC2C.60903@hotnic.net> <031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com> <43DD8A58.9030908@hotnic.net> Message-ID: <43DE7D44.8030807@hotnic.net> cja at daydream.com wrote: > I have a question.. with regard to item > > Have an IPv4 assignment or allocation directly from an RIR, > the IANA or legacy registry > > Qualify for an IPv4 assignment or allocation from ARIN under > the IPv4 policy currently in effect > > do you really mean an assignment or allocation under ANY policy in > effect? If an org has a micro allocation from ARIN of some very small > size they should still qualify for a /44? I am not passing any > judgement here I am just curious. The main intent was to not require someone to actually request IPv4 if they qualify for it. It was not my intent that micro-allocations would qualify though it appears that they would as currently written. - Kevin From owen at delong.com Mon Jan 30 16:44:17 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 30 Jan 2006 13:44:17 -0800 Subject: [ppml] 2005-1 status In-Reply-To: <43DE7D44.8030807@hotnic.net> References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> <43D4FC2C.60903@hotnic.net> <031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com> <43DD8A58.9030908@hotnic.net> <43DE7D44.8030807@hotnic.net> Message-ID: On Jan 30, 2006, at 12:55 PM, Kevin Loch wrote: > cja at daydream.com wrote: >> I have a question.. with regard to item >> >> Have an IPv4 assignment or allocation directly from an >> RIR, >> the IANA or legacy registry >> >> Qualify for an IPv4 assignment or allocation from ARIN >> under >> the IPv4 policy currently in effect >> >> do you really mean an assignment or allocation under ANY policy in >> effect? If an org has a micro allocation from ARIN of some very >> small >> size they should still qualify for a /44? I am not passing any >> judgement here I am just curious. > > The main intent was to not require someone to actually request IPv4 > if they qualify for it. It was not my intent that micro-allocations > would qualify though it appears that they would as currently written. > If /22 is under 2002-3 is considered microallocation, then, I believe such organizations should absolutely qualify. If we're talking about some other microallocation policy, then, we should be careful about how we word any changes. Owen From steven.feldman at cnet.com Mon Jan 30 16:49:34 2006 From: steven.feldman at cnet.com (Steve Feldman) Date: Mon, 30 Jan 2006 13:49:34 -0800 Subject: [ppml] 2005-1 status In-Reply-To: <43DE7BE4.2000008@hotnic.net> References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com><43D4FC2C.60903@hotnic.net><031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com><43DD8A58.9030908@hotnic.net> <17373.61850.688577.934431@roam.psg.com> <014701c625d2$5ac44590$700016ac@ssprunk> <43DE7BE4.2000008@hotnic.net> Message-ID: <642E5E14-AD1B-4F4B-9C14-5CAC14511DF8@cnet.com> > It is conceivable > that each franchise would be responsible for getting internet > service on > their own. In that case you would have a /48 per restaurant. But would all these restaurants want to multihome? I'm guessing not... Perhaps the policy should be written to explicitly only count multihomed locations when determining the assignment size? Steve From kloch at hotnic.net Mon Jan 30 16:53:10 2006 From: kloch at hotnic.net (Kevin Loch) Date: Mon, 30 Jan 2006 16:53:10 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> <43D4FC2C.60903@hotnic.net> <031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com> <43DD8A58.9030908@hotnic.net> <43DE7D44.8030807@hotnic.net> Message-ID: <43DE8AC6.5050105@hotnic.net> Owen DeLong wrote: >> The main intent was to not require someone to actually request IPv4 >> if they qualify for it. It was not my intent that micro-allocations >> would qualify though it appears that they would as currently written. >> > If /22 is under 2002-3 is considered microallocation, then, I believe > such organizations should absolutely qualify. If we're talking about > some other microallocation policy, then, we should be careful about > how we word any changes. By micro-allocations I was referring to allocations made under section 4.4, which already have a corresponding IPv6 policy in section 6.10. /22,/21,/20 are not referred to as "micro" in the NRPM and were absolutely intended to be included. - Kevin From steven.feldman at cnet.com Mon Jan 30 16:52:17 2006 From: steven.feldman at cnet.com (Steve Feldman) Date: Mon, 30 Jan 2006 13:52:17 -0800 Subject: [ppml] 2005-1 status In-Reply-To: <43DE7C4D.2000909@hotnic.net> References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> <43D4FC2C.60903@hotnic.net> <031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com> <43DD8A58.9030908@hotnic.net> <5194AA57-0BF6-41AE-83AC-158BFBEE3041@cnet.com> <43DE7C4D.2000909@hotnic.net> Message-ID: <9681109B-FF59-4348-8803-BABFB5A84B3F@cnet.com> On Jan 30, 2006, at 12:51 PM, Kevin Loch wrote: > Steve Feldman wrote: >> How would this work for a hypothetical example: >> >> Entity X has four distinct physical locations: >> Locations A and B are interconnected and share upstream >> providers. >> >> Locations C and D are each far away from the others, not >> interconnected, and may have distinct sets of upstream providers. >> >> What would the assignment(s) for these look like? >> More to the point, if a single /44 is assigned, is the expectation >> that longer prefixes announced from the various locations would >> be routable? > > I believe that is what the folks that suggested a location based > scalar > were thinking. Whether it would work or not depends on routing > policies > that aren't really in the scope of RIR policy. Sure. I just want to make sure that this assumption is noted, since the policy as written won't otherwise be terribly useful in cases like this. Steve From william at elan.net Mon Jan 30 16:52:18 2006 From: william at elan.net (william(at)elan.net) Date: Mon, 30 Jan 2006 13:52:18 -0800 (PST) Subject: [ppml] 2005-1 status In-Reply-To: References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com> <43D4FC2C.60903@hotnic.net> <031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com> <43DD8A58.9030908@hotnic.net> <43DE7D44.8030807@hotnic.net> Message-ID: On Mon, 30 Jan 2006, Owen DeLong wrote: >> cja at daydream.com wrote: >>> I have a question.. with regard to item >>> >>> Have an IPv4 assignment or allocation directly from an >>> RIR, >>> the IANA or legacy registry >>> >>> Qualify for an IPv4 assignment or allocation from ARIN >>> under >>> the IPv4 policy currently in effect >>> >>> do you really mean an assignment or allocation under ANY policy in >>> effect? If an org has a micro allocation from ARIN of some very >>> small >>> size they should still qualify for a /44? I am not passing any >>> judgement here I am just curious. >> >> The main intent was to not require someone to actually request IPv4 >> if they qualify for it. It was not my intent that micro-allocations >> would qualify though it appears that they would as currently written. >> > If /22 is under 2002-3 is considered microallocation, then, I believe > such organizations should absolutely qualify. If we're talking about > some other microallocation policy, then, we should be careful about > how we word any changes. Microallocations for exchange points, root/TLD dns servers and similar are already available for IPv6 under different micro-allocation policy, so its not an issue here. The issue that some seems to have raised is in regards to giving ipv6 micro-allocation blocks to those who received legacy class-c blocks when those were readily available. I believe its fair to request these organizations to justify and one of those justification should be if they are in fact using those legacy blocks in multihomed fashion or not. -- William Leibzon Elan Networks william at elan.net From dgolding at burtongroup.com Mon Jan 30 16:54:28 2006 From: dgolding at burtongroup.com (Daniel Golding) Date: Mon, 30 Jan 2006 16:54:28 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <642E5E14-AD1B-4F4B-9C14-5CAC14511DF8@cnet.com> Message-ID: On 1/30/06 4:49 PM, "Steve Feldman" wrote: >> It is conceivable >> that each franchise would be responsible for getting internet >> service on >> their own. In that case you would have a /48 per restaurant. > > But would all these restaurants want to multihome? > I'm guessing not... > > Perhaps the policy should be written to explicitly only count > multihomed locations when determining the assignment size? > Steve > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml In real life, they would use two subnets be restaurant (maybe 3) - one for manager workstation, one for process control, and another as the "/30" for the WAN link. BTW, is the idea to waste /64s for WAN links, or am I missing something? - Dan From stephen at sprunk.org Mon Jan 30 17:45:39 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 30 Jan 2006 16:45:39 -0600 Subject: [ppml] 2005-1 status References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com><43D4FC2C.60903@hotnic.net><031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com><43DD8A58.9030908@hotnic.net> <17373.61850.688577.934431@roam.psg.com><014701c625d2$5ac44590$700016ac@ssprunk> <43DE7BE4.2000008@hotnic.net> Message-ID: <01a101c625ee$e5126530$700016ac@ssprunk> Thus spake "Kevin Loch" > Stephen Sprunk wrote: >> Are we really proposing that a leaf organization get a /48 per location? > > My memory of the last meeting is a bit foggy but I distinctly remember > that as a suggestion by several people. I think it came out of the > "one size does not fit all", and "host counts are stupid, why not > count subnets or locations" train of thought. I agree that one size doesn't fit all, but I think it's more relevant to count the number of subnets than the number of street addresses (or hosts). >> Think about it: McDonalds would qualify for a /31 (or so) under this >> proposal, as much or more than most ISPs. They'd be able to >> assign a /64 to _every hamburger they sell_, not just the stores. >> While I'm sure that would be entertaining, is this a reasonable policy >> direction? > > I'm not privy to how they connect their resturaunts. I'm not either; I just picked a random large company I don't have an NDA with. > It is conceivable that each franchise would be responsible for getting > internet service on their own. In that case you would have a /48 per > restaurant. It is typical (I'm not aware of any exceptions, but I'm sure there is one somewhere) for large chains to provide a private FR/ATM/MPLS network connection to each location, regardless of whether it's owned or a franchise, with multihomed Internet access points at several regional data centers. However, if McD's franchisees were to acquire their own Internet access, they'd almost assuredly be in an ISP's PA space, so they're a moot point. The owned stores (30% of locations) would still be enough for McD's to get an absurdly large PI allocation under this proposal, though. That's what I'm addressing (no pun intended) here: giving McD's a /64 for every burger they sell is excessive (or Starbucks and lattes, etc). Sure, there's a lot of IPv6 space, but do we need to go out of our way to assign it all? > If The parent corp was providing IPv6 to each resturaunt they could > become an LIR, get a /32 and issue /48's to franchisees who are separate > organizations. Good point; if McD's decided to be an ISP, they could easily get PI space under existing policies. Bad choice of example, I now see, but the argument in general is still valid if you ignore franchises and/or if the parent org doesn't want to be an LIR. 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 christopher.morrow at gmail.com Mon Jan 30 21:47:09 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Tue, 31 Jan 2006 02:47:09 +0000 Subject: [ppml] Policy without consensus? In-Reply-To: References: Message-ID: <75cb24520601301847s33c06c45o99fd31c2cd14e5ff@mail.gmail.com> On 1/24/06, Michael.Dillon at btradianz.com wrote: > > so do you gentlemen believe that we should allow unlimited allocation of > > IPv6 PI space to whomever wants to multihome and just consider the > > possible routing table scaling problems to be something that will be > > dealt with later? > > Unless someone presents QUANTITATIVE information demonstrating > a real route scaling problem then I do not believe that there > is such a problem. have you asked a vendor how they plan on scalling to 1M routes in their FIB? what about 2M or 20M ? Generally the answer is 'we dont, cause we cant'... or something equally lame. There is a problem, stop ignoring it. (or rather, there is a problem if you keep doing ipv6 like you do ipv4 as far as 'routing' is concerned) > > Let us not forget that IPv6 route table scaling is > NOT THE SAME AS IPV4 route table scaling. It is a completely > different problem. For one thing, very few ASes will need more > than a single IPv6 allocation. For another thing, there is I don't believe this is the case, every org (ASN) has the potential to require some traffic engineering capabilities. Many org may grow beyond their initial numebring plan (and require a 'costly' renumber or a new allocation). Many orgs (ASN) will be subsumed as businesses consolidate/merge/partner and thus announce more than one IPv6 block per ASN. > a way out for organizations that feel pain. They can use IPv4 > instead. This is an option that did not exist in the IPv4 > Internet. They can use ipv4... for resources that might only have v6 connectivity? or are you assuming that all things 'important' will have both by default? From kloch at hotnic.net Mon Jan 30 23:42:56 2006 From: kloch at hotnic.net (Kevin Loch) Date: Mon, 30 Jan 2006 23:42:56 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <01a101c625ee$e5126530$700016ac@ssprunk> References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com><43D4FC2C.60903@hotnic.net><031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com><43DD8A58.9030908@hotnic.net> <17373.61850.688577.934431@roam.psg.com><014701c625d2$5ac44590$700016ac@ssprunk> <43DE7BE4.2000008@hotnic.net> <01a101c625ee$e5126530$700016ac@ssprunk> Message-ID: <43DEEAD0.5030505@hotnic.net> Stephen Sprunk wrote: > Thus spake "Kevin Loch" >> My memory of the last meeting is a bit foggy but I distinctly remember >> that as a suggestion by several people. I think it came out of the >> "one size does not fit all", and "host counts are stupid, why not >> count subnets or locations" train of thought. > > I agree that one size doesn't fit all, but I think it's more relevant to > count the number of subnets than the number of street addresses (or hosts). Here is an alternative version that starts with default assignment of /48 and allows for more with justification for the extra subnets. I'm not sure if "justify need for additional subnets" is clear enough. What justifies the use of a subnet? Add new subsection in section 6.5 of the NRPM: 6.5.8. Direct assignments to large/complex end sites 6.5.8.1. To qualify for a direct assignment, an organization must: a) not be an IPv6 LIR; and b) meet at least ONE of the following requirements: 1) Have an IPv4 assignment or allocation directly from an RIR, the IANA or legacy registry; or 2) Qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect; or 3) Be currently multihomed using IPv6 to two or more separate LIR's using at least one /48 assigned to them by each LIR. 6.5.8.2. Direct assignment size to large/multihomed end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment. The size of the assignment is /48. Organizations requesting more than a single /48 must provide documentation justifying the need for additional subnets. 6.5.8.3. Subsequent Assignment Size Additional assignments may be made when the need for additional subnets is justified. When possible assignments will be made from an adjacent address block. Justification: In IPv4 policy there are three main types of organizations that addresses are delegated to. o ISP's receive allocations directly from ARIN or from other ISP's o End Users receive assignments from ISP's o Large and/or multihomed End Users receive assignments directly from ARIN. The third category is currently missing from IPv6 policy and this is believed to be severely hindering deployment by those organizations. In IPv6 policy-speak: o LIR's receive allocations directly from ARIN o End Sites receive assignments from LIR's This policy proposes: o Large and/or multihomed End Sites receive assignments directly from ARIN. This policy applies to organizations with networks that are large and/or complex enough to justify direct assignments. Like their IPv4 counterparts they do not make assignments to external organizations. They instead assign space internally to their own facilities. Similarly to IPv4 These internal assignments are not submitted to ARIN via swip/rwhois. A IPv6 network is considered eligible if it is multihomed. For transition purposes an organization with an IPv4 assignment or allocation from an RIR (or the legacy RIR) is automatically considered elligible, regardless of whether they were considered an ISP or End User under IPv4 policy. It is expected that the IPv6 only (non transition) requirements will be further refined as experience is gained. - Kevin From randy at psg.com Tue Jan 31 01:31:26 2006 From: randy at psg.com (Randy Bush) Date: Mon, 30 Jan 2006 22:31:26 -0800 Subject: [ppml] Policy without consensus? References: <75cb24520601301847s33c06c45o99fd31c2cd14e5ff@mail.gmail.com> Message-ID: <17375.1086.66218.538655@roam.psg.com> > have you asked a vendor how they plan on scalling to 1M routes in > their FIB? what about 2M or 20M ? Generally the answer is 'we dont, > cause we cant'... or something equally lame. or "of course we can." but don't expect anything but smoke if you further ask if they have actually tested with serious levels of churn. randy From Michael.Dillon at btradianz.com Tue Jan 31 04:42:21 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 31 Jan 2006 09:42:21 +0000 Subject: [ppml] 2005-1 status In-Reply-To: <014701c625d2$5ac44590$700016ac@ssprunk> Message-ID: > Think about it: McDonalds would qualify for a /31 (or so) under this > proposal, as much or more than most ISPs. They'd be able to assign a /64 to > _every hamburger they sell_, not just the stores. While I'm sure that would > be entertaining, is this a reasonable policy direction? I thought that IPv6 policy already specifies that addresses are to be used for Internet infrastructure. In that case the only way Macdonalds could assign an address per hamburger would be to embed a network device within the sandwich. I think it is highly unlikely that network devices containing poisonous materials would ever be embedded within edible products. So then, where in 2005-01 does it override the existing policy and allow assigning addresses for uses other than network infrastructure? --Michael Dillon From Michael.Dillon at btradianz.com Tue Jan 31 04:51:24 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 31 Jan 2006 09:51:24 +0000 Subject: [ppml] Policy without information? In-Reply-To: <75cb24520601301847s33c06c45o99fd31c2cd14e5ff@mail.gmail.com> Message-ID: > > Unless someone presents QUANTITATIVE information demonstrating > > a real route scaling problem then I do not believe that there > > is such a problem. > > have you asked a vendor how they plan on scalling to 1M routes in > their FIB? what about 2M or 20M ? This is an excellent question. I wonder why we are considering making policy without first sending a letter to the major vendors asking them for their public comments on the route scaling problem. This is an area in which we don't have to fly blind. Let's ask ARIN staff to send an open letter to the major vendors and ask for their answers prior to making any policy decision on v6 PI addressing. --Michael Dillon From packetgrrl at gmail.com Tue Jan 31 09:19:53 2006 From: packetgrrl at gmail.com (cja@daydream.com) Date: Tue, 31 Jan 2006 07:19:53 -0700 Subject: [ppml] 2005-1 status In-Reply-To: References: <014701c625d2$5ac44590$700016ac@ssprunk> Message-ID: Michael, I believe that MacDonald's already has poisonous materials in their hamburgers so some network devices may not be a problem :-) Note that the real problem with the MacDonald's scenerio is the reclaimation of the addresses once the hamburger is eaten and of course the health problems from eating the hamburger in the first place. ---Cathy On 1/31/06, Michael.Dillon at btradianz.com wrote: > > > Think about it: McDonalds would qualify for a /31 (or so) under this > > proposal, as much or more than most ISPs. They'd be able to assign a > /64 to > > _every hamburger they sell_, not just the stores. While I'm sure that > would > > be entertaining, is this a reasonable policy direction? > > I thought that IPv6 policy already specifies that addresses > are to be used for Internet infrastructure. In that case > the only way Macdonalds could assign an address per hamburger > would be to embed a network device within the sandwich. I think > it is highly unlikely that network devices containing poisonous > materials would ever be embedded within edible products. > > So then, where in 2005-01 does it override the existing > policy and allow assigning addresses for uses other than > network infrastructure? > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at sprunk.org Tue Jan 31 09:58:44 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 31 Jan 2006 08:58:44 -0600 Subject: [ppml] 2005-1 status References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com><43D4FC2C.60903@hotnic.net><031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com><43DD8A58.9030908@hotnic.net> <17373.61850.688577.934431@roam.psg.com><014701c625d2$5ac44590$700016ac@ssprunk><43DE7BE4.2000008@hotnic.net><01a101c625ee$e5126530$700016ac@ssprunk> <43DEEAD0.5030505@hotnic.net> Message-ID: <001701c62676$d5560a60$730016ac@ssprunk> Thus spake "Kevin Loch" > Stephen Sprunk wrote: >> I agree that one size doesn't fit all, but I think it's more relevant to >> count the number of subnets than the number of street addresses >> (or hosts). > > Here is an alternative version that starts with default assignment of > /48 and allows for more with justification for the extra subnets. I have a couple minor wording changes below, but I'd support your text as-is if needed. > I'm not sure if "justify need for additional subnets" is clear enough. > What justifies the use of a subnet? I'm content to leave that to ARIN's staff's discrection unless others believe that more direction is required. > 6.5.8.2. Direct assignment size to large/multihomed end sites > > Organizations that meet the direct end site assignment criteria > are eligible to receive a direct assignment. The size of the > assignment is /48. Organizations requesting more than a single > /48 must provide documentation justifying the need for > additional subnets. Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment. The minimum size of the assignment is /48. Organizations requesting a larger assignment or a second (or more) assignment must provide documentation justifying the need for additional subnets. > 6.5.8.3. Subsequent Assignment Size > > Additional assignments may be made when the need for additional > subnets is justified. When possible assignments will be made > from an adjacent address block. Additional assignments may be made when the need for additional subnets is justified. When possible, additional assignments will be made from an adjacent address block. If an adjacent block is not available, organizations may request to trade their prior smaller assignment(s) for a single larger one, with a transition period of six months to renumber. I think we also need to state somewhere that allocations under this policy should be from a block designated for that purpose, so that ISPs that wish to filter on prefix length know to use /48 as the limit for this part of the IPv6 space. I don't know if we need to use a different block from microallocations. 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 stephen at sprunk.org Tue Jan 31 10:20:49 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 31 Jan 2006 09:20:49 -0600 Subject: [ppml] 2005-1 status References: Message-ID: <002501c62679$eb010a10$730016ac@ssprunk> Thus spake >> Think about it: McDonalds would qualify for a /31 (or so) under this >> proposal, as much or more than most ISPs. They'd be able to >> assign a /64 to _every hamburger they sell_, not just the stores. >> While I'm sure that would be entertaining, is this a reasonable policy >> direction? > > I thought that IPv6 policy already specifies that addresses are to be > used for Internet infrastructure. In that case the only way > Macdonalds could assign an address per hamburger would be to > embed a network device within the sandwich. I think it is highly > unlikely that network devices containing poisonous materials would > ever be embedded within edible products. > > So then, where in 2005-01 does it override the existing > policy and allow assigning addresses for uses other than > network infrastructure? Policies say what justifies an assignment of various sizes; AFAIK ARIN has no way of enforcing how those addresses are used once they're assigned unless more are requested. An organization that receives _tens of thousands_ of times the subnets they need is unlikely to need more later, so forget controlling what they do with them after that... The proposal I was responsing to would have justified giving McD's a /31 (or so) based on the number of street addresses when they probably could barely justify a /47 of PA space from a LIR. Numbering their network infrastructure would make no perceptible dent in 2^33 /64s, hence my jest about using the rest to number their burgers. 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 George.Kuzmowycz at aipso.com Tue Jan 31 13:42:35 2006 From: George.Kuzmowycz at aipso.com (George Kuzmowycz) Date: Tue, 31 Jan 2006 13:42:35 -0500 Subject: [ppml] 2005-1 status Message-ID: >>> Kevin Loch 01/30/2006 11:42:56 PM >>> Stephen Sprunk wrote: > Thus spake "Kevin Loch" >> My memory of the last meeting is a bit foggy but I distinctly remember >> that as a suggestion by several people. I think it came out of the >> "one size does not fit all", and "host counts are stupid, why not >> count subnets or locations" train of thought. > > I agree that one size doesn't fit all, but I think it's more relevant to > count the number of subnets than the number of street addresses (or hosts). Here is an alternative version that starts with default assignment of /48 and allows for more with justification for the extra subnets. I'm not sure if "justify need for additional subnets" is clear enough. What justifies the use of a subnet? Add new subsection in section 6.5 of the NRPM: 6.5.8. Direct assignments to large/complex end sites >>> Please forgive me if I'm not doing this "correctly", but even though I've lurked on this list for a while I have never participated in any policy development processes. What I see distinctly under-represented here is the corporate/enterprise IT view, and as a result I think the vagueness of the "large/complex" will lead to problems. In my view, the direction this policy is taking will lead to even a lower rate of corporate IPv6 adoption than the pessimists here think. In today's environment, an organization does not have to be particularly "large" or "complex" to have legitimate need for PI space and real multi-provider multi-homing. A policy which makes that more difficult than it is today is doomed. Keep in mind, please, that network architecture decisions in the real world are increasingly not being made on the basis of technical (i.e. protocol-level or routing-policy-level) factors. Network architecture decisions are being driven by what can be justified to compliance officers, internal auditors, third-party review (audit or otherwise), data security officers, etc. These may be people who know just enough about networking to pass a CISSP or CISA or CIA exam but have no idea what BGP is. There are many, many organizations that are large enough to have an IT staff and an internal audit or compliance staff but not large enough or old enough to have a legacy /16. Many of these organizations, publicly, maybe are only a couple of /30's, but behind that could easily be a /20's or a /19's worth of devices. Under current policy, the only way to get PI space for such an organization is to renumber to non-1918 space or to stretch the truth with ARIN (which seems to be the nudge-nudge-wink-wink sort of advice that one occasionally gets). Yet to an IT Director or above, who asks why we can have telephone number portability but not IP address portability, what's the answer? I saw this come up on the list a bit around a week ago, but have the feeling that the provider community, which dominates this process, isn't listening. Policies which are predicated on providers' statements (as I've seen here) of what an AS "needs" without listening to what those ASes want and why don't make for a sustainable business model, IMO. It's not that we (the customers) don't trust you, it's that in today's regulatory/business environment we no longer are permitted to trust you. If I don't have a solid plan for what to do quickly and painlessly to switch ISP's, I lose my job or our customers or both. For better or for worse, PI space and multi-homing are the answer du jour. Off to don my Nomex. From dougm at nist.gov Tue Jan 31 13:56:09 2006 From: dougm at nist.gov (Doug Montgomery) Date: Tue, 31 Jan 2006 13:56:09 -0500 Subject: [ppml] 2005-1 status Message-ID: <43DFB2C9.2070305@nist.gov> > Message: 3 > > Date: Tue, 31 Jan 2006 09:42:21 +0000 > > From: Michael.Dillon at btradianz.com > > Subject: Re: [ppml] 2005-1 status > > To: ppml at arin.net > > Message-ID: > > > > > > Content-Type: text/plain; charset="US-ASCII" > > >> >> Think about it: McDonalds would qualify for a /31 (or so) under this >> >> proposal, as much or more than most ISPs. They'd be able to assign a > > /64 to >> >> _every hamburger they sell_, not just the stores. While I'm sure that > > would >> >> be entertaining, is this a reasonable policy direction? > > > > I thought that IPv6 policy already specifies that addresses > > are to be used for Internet infrastructure. In that case > > the only way Macdonalds could assign an address per hamburger > > would be to embed a network device within the sandwich. I think > > it is highly unlikely that network devices containing poisonous > > materials would ever be embedded within edible products. > > > > So then, where in 2005-01 does it override the existing > > policy and allow assigning addresses for uses other than > > network infrastructure? > > > > --Michael Dillon While I will not argue if we are more or less disposable or networkable than hamburgers, I have become aware of plans to assign valid IPv6 addresses to all US Gov employees, contractors, etc as part of the HSPD-12 process. http://www.smart.gov/iab/documents/PACS.pdf "The Federal Government has defined the GUID as a mechanism to enable issuance and acceptance of physical access credentials beyond federal agency participation. The GUID is defined as an IPv6 address and is anticipated to become the standard for credential numbering in federally managed PACS." While I am not sure that this is a good idea, either from the HSPD-12 perspective or the IPv6 perspective, it is a proposed plan. If this plan goes forward, I would assume I would want PI space for such a use, independent of my qualifications for network infrastructure. Are there ARIN policies, existing or proposed, that would support the allocation of IPv6 addresses for such uses? dougm From iggy at merit.edu Tue Jan 31 15:03:35 2006 From: iggy at merit.edu (Glenn Wiltse) Date: Tue, 31 Jan 2006 15:03:35 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: <002501c62679$eb010a10$730016ac@ssprunk> References: <002501c62679$eb010a10$730016ac@ssprunk> Message-ID: If I'm not mistaken the current IPv6 policy allows a LIR to give a /48 to each end site. If a owner of a McD franchise (or whatever) asked a LIR for IPv6 space, a LIR may likely just give that endsite a /48. So, I don't undestand why you think the entire McD business could not justify a need for more then a /47. Glenn Wiltse On Tue, 31 Jan 2006, Stephen Sprunk wrote: > The proposal I was responsing to would have justified giving McD's a /31 (or > so) based on the number of street addresses when they probably could barely > justify a /47 of PA space from a LIR. Numbering their network > infrastructure would make no perceptible dent in 2^33 /64s, hence my jest > about using the rest to number their burgers. From owen at delong.com Tue Jan 31 15:10:38 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 31 Jan 2006 12:10:38 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: > Please forgive me if I'm not doing this "correctly", but even though > I've lurked on this list for a while I have never participated in any > policy development processes. > You're doing just fine on the process. > What I see distinctly under-represented here is the > corporate/enterprise IT view, and as a result I think the vagueness of > the "large/complex" will lead to problems. In my view, the direction > this policy is taking will lead to even a lower rate of corporate IPv6 > adoption than the pessimists here think. In today's environment, an > organization does not have to be particularly "large" or "complex" to > have legitimate need for PI space and real multi-provider multi-homing. > A policy which makes that more difficult than it is today is doomed. > The current IPv6 policy is that there is no such thing as PI space, so, currently, it is impossible. This policy is an attempt to make it easier, but, we still have to compromise with the portion of the ARIN constituency that believes fully opening this up will cause an uncontrolled explosion of the global routing table which will melt down the internet. Their concerns are, in my opinion, overstated, but, not without merit. > Keep in mind, please, that network architecture decisions in the real > world are increasingly not being made on the basis of technical (i.e. > protocol-level or routing-policy-level) factors. Network architecture > decisions are being driven by what can be justified to compliance > officers, internal auditors, third-party review (audit or otherwise), > data security officers, etc. These may be people who know just enough > about networking to pass a CISSP or CISA or CIA exam but have no idea > what BGP is. There are many, many organizations that are large enough to > have an IT staff and an internal audit or compliance staff but not large > enough or old enough to have a legacy /16. Many of these organizations, > publicly, maybe are only a couple of /30's, but behind that could easily > be a /20's or a /19's worth of devices. Under current policy, the only > way to get PI space for such an organization is to renumber to non-1918 > space or to stretch the truth with ARIN (which seems to be the > nudge-nudge-wink-wink sort of advice that one occasionally gets). Yet to > an IT Director or above, who asks why we can have telephone number > portability but not IP address portability, what's the answer? > Well, the first answer is that the structure of the internet is quite different than the structure of the telephone network. The telephone network differs in the following meaningful ways: + The telephone network is a switched virtual circuit network. Routing decisions are made once per call at the time of call origination. The internet is a packet switched network. The routing decisions are made independently on a packet by packet basis at each router along the way. + In the telephone network, there is a level of indirection that doesn't exist in the IP world, at least not yet. Your "portable" telephone number is not the number which is used to route the call. Instead, that number is looked up in a global database (SS7) to determine the actual destination. The call is then routed to that destination. In the internet, the destination IP address is used both to identify the end recipient, and, for all routing decisions along the way. > I saw this come up on the list a bit around a week ago, but have the > feeling that the provider community, which dominates this process, isn't > listening. Policies which are predicated on providers' statements (as > I've seen here) of what an AS "needs" without listening to what those > ASes want and why don't make for a sustainable business model, IMO. It's > not that we (the customers) don't trust you, it's that in today's > regulatory/business environment we no longer are permitted to trust you. > If I don't have a solid plan for what to do quickly and painlessly to > switch ISP's, I lose my job or our customers or both. For better or for > worse, PI space and multi-homing are the answer du jour. > Both constituencies are somewhat represented. I do agree with you that the end-user constituency is underrepresented compared to the provider constituency. However, both sides have legitimate concerns, and, I believe both sides do, by and large, understand the needs of the other. The real task here is to find the compromise between the two sides that makes the internet most useful for the largest portion of the constituency. On one side, if we do allow PI addressing to get out of hand, current routing technology cannot scale to support it, and, the internet will be incapable of maintaining a routing infrastructure. A non-functional internet or one in which some significant portion of addresses are unreachable or unstable does not serve the end user or provider constituencies. This is the extreme of one side of this issue, and, the source of most of the anti-PI statements. On the other side, if we do not allow PI addressing at all, then there is a significant portion of the end-user constituency that is not well served. This is the opposite extreme, and, one of the reasons that there is a policy proposal to try and change this fact. The IETF intent was that there would be no PI space issued in IPv6 to anyone other than providers. I believe that intent was flawed and that is one of the reasons I wrote the first version of this policy and have continued working with Kevin and Lea and the list on improving it. > Off to don my Nomex. > Hopefully you won't get too many flames. I, for one, as one of the policy authors, appreciate your comments. 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 owen at delong.com Tue Jan 31 15:14:38 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 31 Jan 2006 12:14:38 -0800 Subject: [ppml] 2005-1 status In-Reply-To: <43DFB2C9.2070305@nist.gov> References: <43DFB2C9.2070305@nist.gov> Message-ID: <812554FFAABA27B14971E36F@imac-en0.delong.sj.ca.us> I would assume that in such a case, it would be a separate namespace from the internet IPv6 addresses. If they want to use 128 bit integers, let them do so, no problem for us, but, if they want to reserve network infrastructure numbers from PI blocks to number humans, well, that's just not a good idea in my opinion. Owen --On January 31, 2006 1:56:09 PM -0500 Doug Montgomery wrote: >> Message: 3 >> > Date: Tue, 31 Jan 2006 09:42:21 +0000 >> > From: Michael.Dillon at btradianz.com >> > Subject: Re: [ppml] 2005-1 status >> > To: ppml at arin.net >> > Message-ID: >> > > > com> >> > >> > Content-Type: text/plain; charset="US-ASCII" >> > >>> >> Think about it: McDonalds would qualify for a /31 (or so) under this >>> >> proposal, as much or more than most ISPs. They'd be able to assign a >> > /64 to >>> >> _every hamburger they sell_, not just the stores. While I'm sure >>> >> that >> > would >>> >> be entertaining, is this a reasonable policy direction? >> > >> > I thought that IPv6 policy already specifies that addresses >> > are to be used for Internet infrastructure. In that case >> > the only way Macdonalds could assign an address per hamburger >> > would be to embed a network device within the sandwich. I think >> > it is highly unlikely that network devices containing poisonous >> > materials would ever be embedded within edible products. >> > >> > So then, where in 2005-01 does it override the existing >> > policy and allow assigning addresses for uses other than >> > network infrastructure? >> > >> > --Michael Dillon > > > While I will not argue if we are more or less disposable or networkable > than hamburgers, I have become aware of plans to assign valid IPv6 > addresses to all US Gov employees, contractors, etc as part of the > HSPD-12 process. > > http://www.smart.gov/iab/documents/PACS.pdf > > "The Federal Government has defined the GUID as a mechanism to enable > issuance and acceptance of physical access credentials beyond federal > agency participation. The GUID is defined as an IPv6 address and is > anticipated to become the standard for credential numbering in federally > managed PACS." > > While I am not sure that this is a good idea, either from the HSPD-12 > perspective or the IPv6 perspective, it is a proposed plan. > > If this plan goes forward, I would assume I would want PI space for such > a use, independent of my qualifications for network infrastructure. > > Are there ARIN policies, existing or proposed, that would support the > allocation of IPv6 addresses for such uses? > > dougm > > _______________________________________________ > 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 kloch at hotnic.net Tue Jan 31 23:44:01 2006 From: kloch at hotnic.net (Kevin Loch) Date: Tue, 31 Jan 2006 23:44:01 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <001701c62676$d5560a60$730016ac@ssprunk> References: <01D35E77-55CA-4280-82D2-35F3663308AC@multicasttech.com><43D4FC2C.60903@hotnic.net><031AB986-C94B-4F34-B120-BFB258CBAD7E@delong.com><43DD8A58.9030908@hotnic.net> <17373.61850.688577.934431@roam.psg.com><014701c625d2$5ac44590$700016ac@ssprunk><43DE7BE4.2000008@hotnic.net><01a101c625ee$e5126530$700016ac@ssprunk> <43DEEAD0.5030505@hotnic.net> <001701c62676$d5560a60$730016ac@ssprunk> Message-ID: <43E03C91.3010904@hotnic.net> Stephen Sprunk wrote: > I think we also need to state somewhere that allocations under this > policy should be from a block designated for that purpose, so that ISPs > that wish to filter on prefix length know to use /48 as the limit for > this part of the IPv6 space. I don't know if we need to use a different > block from microallocations. I recommend they be kept as separate from other assignments/allocations including micro-assignments as possible. Future advances in routing architecture may allow many more of these being assigned than what is imaginable today. Might as well just put them in a tiny part of a /16 by themselves until you need to use the rest of the /16. Start with a /32 reserved for this and populate sparsely like we appear to do for micro-assignments. - Kevin