From sob at academ.com Tue Dec 1 00:25:54 2009 From: sob at academ.com (Stan Barber) Date: Mon, 30 Nov 2009 23:25:54 -0600 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <040DE541-C865-4898-9696-BEB2BAAC9B90@delong.com> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <040DE541-C865-4898-9696-BEB2BAAC9B90@delong.com> Message-ID: <4B14A8E2.5020800@academ.com> Owen, How real is the risk of being audited? I am not asking that flippantly. I just wonder if ARIN has ever audited and if so, what was the reason? Was it because of bad SWIP information? Owen DeLong wrote: > I believe that the resource review policy would preserve the > need for ISPs to keep SWIPs up to date or risk having their > resources audited. > > Owen > > On Nov 30, 2009, at 2:22 PM, Danny McPherson wrote: > >> >> I'd like to know what folks here are thinking regarding >> IPv6 and SWIPs. In particular, a primary driver for SWIPs >> today is to enable justification of additional addresses >> (when the time comes). SWIP data is clearly invaluable to >> network operations and security folks, as well as law >> enforcement, when investigating or dealing with various >> incidents (not to mention many other uses, as many of you >> well know). >> >> I suspect that with such large IPv6 allocations, the need >> to keep SWIP/(rwhois) data up to date will diminish, severely >> hindering folks that use SWIP data on a regular basis. >> >> Furthermore, while development of an RPKI is underway, it >> really only deals with certification of routed number spaces >> (as currently specified). While I _think we don't want all >> subsequent assignment/allocation data in the RPKI, I'm worried >> we won't have it anywhere with IPv6 -- or in many different >> places and formats. >> >> I suspect at least a BCP (some form, some where) and some >> community guidance is in order along these lines (i.e., >> SWIP-esque data is a must to some reasonable level of >> granularity), I'd like to see what folks here are thinking >> along these lines.. >> >> If I've missed this discussion here (or in other forums) >> references welcome, a cursory search yields nothing expressly >> related to this topic. >> >> Thanks in advance, >> >> -danny >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jcurran at arin.net Tue Dec 1 06:53:15 2009 From: jcurran at arin.net (John Curran) Date: Tue, 1 Dec 2009 06:53:15 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B14A8E2.5020800@academ.com> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <040DE541-C865-4898-9696-BEB2BAAC9B90@delong.com> <4B14A8E2.5020800@academ.com> Message-ID: <2C7B54B5-3261-4691-A7C1-A5165A1532F4@arin.net> On Dec 1, 2009, at 12:25 AM, Stan Barber wrote: > Owen, > > How real is the risk of being audited? > > I am not asking that flippantly. I just wonder if ARIN has ever audited and if so, what was the reason? Was it because of bad SWIP information? Stan - The resource review policy is relatively new, but ARIN has indeed been making use of when we see strong indication of fraudulent activities or related misappropriation of number resources. While in theory resource review could be performed for any reason (including lax updates to SWIP information), it has been our practice to only make use of it where that the community is potentially being deprived of the use of numbering resources. /John John Curran President and CEO ARIN From michael.dillon at bt.com Tue Dec 1 06:57:23 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 1 Dec 2009 11:57:23 -0000 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <5AB64AFF-C7E9-4699-A45B-F0561EB4B192@tcb.net> Message-ID: <28E139F46D45AF49A31950F88C497458044FE712@E03MVZ2-UKDY.domain1.systemhost.net> > I suspect that with such large IPv6 allocations, the need to > keep SWIP/(rwhois) data up to date will diminish, severely > hindering folks that use SWIP data on a regular basis. I think that a good way to counter this would be to provide an easy to use, standard way, for providers to report this information. The current SWIP system is not the way forward. A better architecture would be for every provider to run their own server which provides an rwhois-like service to lookup the status of the provider's prefixes. This service should allow for richer information to be provided than just assigned/unassigned. This provides the possibilities for providers to cooperate under the auspices of some other organization like MAAWG and agree to provide each other certain status information. For instance they could flag an address as a former SPAM source that was dealt with, or a botnet infestation that was cleaned, or any other status information that is useful to share. ARIN's role would be to produce the open-source software package to run this service, to define a minimum set of status to be reported, and to provide a mirroring service. In this way, the ISP's responsibility is to record the status in their database and to make sure that their status reporting server has access to the database. People can then query the ISP's server directly, or ARIN's mirror, or a 3rd party mirror at their liberty. In addition to lookups, the server should provide support for mirroring, i.e. it should be possible to query for all updates since a certain time, and get a batch feed of the changes for the ARIN mirror. Included in the minimum status information to be reported, should be the identity and contact information for the people who are charged with managing the network which uses particular address range. This should never be assumed to be the party to whom the addresses were assigned, but should by default be the ISP who owns the allocation. Rather than overloading the existing whois data with multiple meanings, this new service should make a serious effort to separate things so that the current status of an address block is reported clearly and unambiguously. And the protocol used for this should be extensible, for instance don't use a yes/no value for "assigned", but use a 3 digit status code with value 000 meaning unused, 001 meaning assigned, and all the rest of the values open for definition in future. And don't return a single code, but return a list of codes so that you can have either "001," or "001,202" meaning assigned and blocked for non-payment. REST may be the best protocol to choose for this status reporting. We have the opportunity here to fix the whois system and replace it with something that makes sense for the long haul, and get rid of the legacy of identifying system users to justify DARPA funding. --Michael Dillon From michael.dillon at bt.com Tue Dec 1 07:01:47 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 1 Dec 2009 12:01:47 -0000 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <2C7B54B5-3261-4691-A7C1-A5165A1532F4@arin.net> Message-ID: <28E139F46D45AF49A31950F88C497458044FE731@E03MVZ2-UKDY.domain1.systemhost.net> > While in theory resource review could be performed for any > reason (including lax updates to SWIP information), it has > been our practice to only make use of it where that the > community is potentially being deprived of the use of > numbering resources. Sounds like you are following the old maxim "You'll catch more flies with honey than with vinegar" and reserving the use of vinegar for the outrageous offenders. As it should be. I think that where there is non-compliance with ARIN rules, it is most often because the rules are confusing and the systems that one must be compliant with are hard to use. A better action would be to talk to people, find out what barriers are leading to non-compliance, and work to remove or minimize those barriers. --Michael Dillon From tedm at ipinc.net Tue Dec 1 11:33:01 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 01 Dec 2009 08:33:01 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> Message-ID: <4B15453D.2070309@ipinc.net> Danny McPherson wrote: > I'd like to know what folks here are thinking regarding > IPv6 and SWIPs. In particular, a primary driver for SWIPs > today is to enable justification of additional addresses > (when the time comes). SWIP data is clearly invaluable to > network operations and security folks, as well as law > enforcement, when investigating or dealing with various > incidents (not to mention many other uses, as many of you > well know). > > I suspect that with such large IPv6 allocations, the need > to keep SWIP/(rwhois) data up to date will diminish, severely > hindering folks that use SWIP data on a regular basis. > I think it would be foolish to assume this. You bought into this naieve notion that SWIP data is mainly of benefit to OTHER people, promulgated by all the bonehead privacy-terrorists out there who think that a SWIP filed on them will let the identity thieves steal them blind. In reality, SWIPs aren't for the rest of the Internet, they help make YOUR job easier. If you don't file SWIP data or run RWhois on your subnets, then the only SWIP entry that will exist for your subnet that's assigned by the RIR is going to be the one that the RIR inserted when they gave you your IPv6 assignment. Thus, any time one of the orgs that you assigned subnets to goes and honks-off ME, well then YOU are going to get my complaint. If YOU want to waste all your time handling these complaints well then I don't give a rat's ass, but if you DON'T -handle- the complaint and your customer continues honking me off, well then I'm going to block YOUR ENTIRE BLOCK - because since you didn't file a SWIP how the hell am I going to know what part of your assigned numbers does this org have access to that is honking me off? From my point of view, your ENTIRE block is suspect, not just the piece that you assigned to Wonkulating Gronkulators. So, for LIRS that want to pee all over themselves, well then don't file SWIPS. In fact I ENCOURAGE IT STRONGLY because then all I have to do is null-route your ENTIRE AS, I don't even have to waste CPU cycles blocking just the obnoxious traffic from Wonkulating. > > If I've missed this discussion here (or in other forums) > references welcome, a cursory search yields nothing expressly > related to this topic. > Probably because of the same reason that a cursory search won't find any discussions about the pros and cons of staring straight into the sun for an hour at high noon. Ted > Thanks in advance, > > -danny > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From baptista at publicroot.org Tue Dec 1 12:04:25 2009 From: baptista at publicroot.org (Joe Baptista) Date: Tue, 1 Dec 2009 12:04:25 -0500 Subject: [arin-ppml] Apology requested from Christopher Mettin and the Gymnasium Querfurt High School Message-ID: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> Dear Christopher and ARIN community: I am requesting a public apology from you Christopher Mettin and your organization the Gymnasium Querfurt High School for calling me an Internet terrorist, a liar and other libelous, slanderous and defamatory statements made by you in a public forum against me. Also Christopher please do not jump the gun and make this decision on your own. Kindly consult your supervisor and principle with respect to my request and take the time to show them my request as well as the statements made by you on behalf of your school against me. For the record I will now respond to the allegations made against me by Mr. Mettin. 1) I am not an "Internet terrorist". This claim by Mr. Mettin below is not only false but seriously libelous, slanderous and defamatory. 2) I was never an employee of the Public-Root. I was a consultant since 2003. And I was not fired. I walked out along with other consultants because of the criminal activity uncovered by me - being mainly the embezzlement of funds, money laundering and tax evasion by senior executive staff. 3) I never attacked Christopher's Gymnasium Querfurt High School. This claim is also false, libelous, slanderous and defamatory. I did attempt to email senior staff and also called by phone but was unable to get in touch with anyone except Mr. Mettin. I therefore have no idea if school staff know what Mr. Mettin is up to as I have been unable to contact a responsible adult at the school. 4) Mr. Mettin's claims that the PublicRoot Consortium does not exist are false. The PublicRoot Consortium is organized as an unincorporated trust in Canada. 5) Mr. Mettin's claims below that his schools only involvement with the people who run the INAIC.com web site was to be "assigned a (top-level) domain by a company affiliated with the Public Root Ltd." is false. The top-level domain the Gymnasium Querfurt High School purchased from them is GQNET - a copy of the whois for this domain is attached at the end of this message as Appendix A. But as members here have pointed out Mr. Mettin's forgot to mention that the Gymnasium Querfurt High School also sells TLDs for these shell companies and non existent organizations. 6) Mr. Mettin's claims that my actions resulted in the shut down of a company are partially true. My actions resulted in the business failure of at least three companies and the investigation of a number of individuals for criminal acts being tax evasion and money laundering. Some individuals involved in these investigations have settled with the Dutch tax authorities. We also had the full support of the Turkish Government and SITA, as well as a number of other influential people, organization and countries. That support evaporated when I when public and blew the whistle. As a result of my actions fewer people ended up loosing their money in this scam which was my intention. 7) Mr. Mettin's claims that I lie are also false, libelous, slanderous and defamatory. regards joe baptista On Sat, Nov 28, 2009 at 8:55 PM, Christopher Mettin wrote: > ARIN Community, > > The following message was sent recently to the ARIN mailing list by an > Internet terrorist known as Joe Baptista. > > >OK - before someone end up donating addresses and gets involved in a fraud > - I think it's time for a little >backgrounder on Christopher Mettin. > > > >http://bit.ly/87Yjir > > > >What Chris needs are a few blocks of /24 to setup a root system based on > what I know of him. Thats what I think >he is going on about - that they > need fixed IP. About the only protocol widely used still requiring fixed IP > >for the root cache. > > > >Be careful I have been unable to confirm what he is doing is even > authorized by the school. If you feel so >inclined to provide /24 blocks to > them - make sure a responsible adult from the school signs on the dotted > >line, takes responsibility and absolves you of any legal liability. > > > >I do however support his initial point. These are only numbers and ARIN > RIPE APNIC et. al. are making a killing >for just providing a database > function - the rest as far as I can see is mainly hype and make work > projects. I >think thats been mentioned before. > > A few months ago my school has been attacked by this guy. He did already > make an entire company shut down. His best weapons are lies. > > All that started when he was fired by the Public Root in 2005. We have been > assigned a domain by a company affiliated with the Public Root Ltd. and so > we became a major target to him. He sends his emails from a domain > publishing a website of a "PublicRoot Consortium" which does not exist. The > contact address of this consortium is a private home in an Ontarian suburb. > Sending emails using this domain he tries to make people believe he is an > official employee of the Public Root. > > The IP addresses shall be in no way used with any root system. > > For further reference on Joe Baptista, see > http://inaic.com/index.php?p=news-25-08-2008. > > Sincerely yours, > Christopher Mettin > Gymnasium Querfurt High School > > APPENDIX A: whois -h whois.inaic.net GQNET Corporate TLD (cTLD): .GQNET TLD Status: Active TLD Register Date: 13-05-2009 TLD Updated: 29-05-2009 TLD Expire Date: 13-05-2010 Preferred Domain Name Registry: GQnet ( http://gqbc-online.com ) TLD Registrant: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Administrative contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Technical contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Billing contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Servers: TLD Server1: tld1.public-root.net - IPV4: 84.22.100.6 TLD Server2: tld2.public-root.net - IPV4: 57.67.193.188 TLD Server3: tld3.public-root.net - IPV4: 199.5.156.122 By submitting a Global TLD WHOIS query you agree to use this data only for lawful purposes. Under no circumstances will you use this data to: (1) Allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail, telephone, or facsimile; or: (2) Enable high volume, automated, electronic processes against the INAIC or its data systems and networks. The compilation, repackaging, dissemination or other use of this data is expressly prohibited without the prior written consent of the INAIC. The INAIC reserves the right to revoke access to the Global TLD WHOIS Database in its sole discretion, including without limitation, for excessive querying of the Global TLD WHOIS Database or for failure to otherwise abide by this policy. TLD Registrants are responsible for the information maintained in the directory services database.The INAIC does not guarantee the accuracy of the information maintained in the Global TLD WHOIS Database. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmettin at gqbc-online.com Tue Dec 1 12:28:24 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Tue, 1 Dec 2009 18:28:24 +0100 Subject: [arin-ppml] Apology requested from Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> Message-ID: Everything I said about Joe Baptista entirely true and confirmed by evidences and statements by several other people. I hereby request to dismiss Joe Baptista from the ARIN mailing list for the falsification of documents and the miss-identification as employee of the Public Root, a registered British company (see his email address for that). We received a dozen emails a day in September from Joe Baptista, I see no point why this should not be called spamming. The clarify, we did not buy a TLD that we know won't ever be accessible by everyone (except all Internet users queried the Public Root for DNS resolution). The TLD was given to us for educational purposes and in return to open the TLD registration to other people on our site. Further, Public Root, as a British company, and INAIC, a New York-based company, exist and full-fill the service they offer. Their TLD and root services are widely known as alternative, even Wikipedia has a section about them on their alternative roots articles. So far this cannot be called a scam, rather Joe Baptista is the spam ignoring Canadian court orders. For all the times this global network shall exist, the World shall have knowledge about the activities of the Internet terrorist Joe Baptista. Sources: http://inaic.com/index.php?p=internet-terror http://whocalled.us/lookup/4169126551 From: publicroot.info at gmail.com [mailto:publicroot.info at gmail.com] On Behalf Of Joe Baptista Sent: Tuesday, December 01, 2009 6:04 PM To: Christopher Mettin Cc: arin-ppml at arin.net Subject: Apology requested from Christopher Mettin and the Gymnasium Querfurt High School Dear Christopher and ARIN community: I am requesting a public apology from you Christopher Mettin and your organization the Gymnasium Querfurt High School for calling me an Internet terrorist, a liar and other libelous, slanderous and defamatory statements made by you in a public forum against me. Also Christopher please do not jump the gun and make this decision on your own. Kindly consult your supervisor and principle with respect to my request and take the time to show them my request as well as the statements made by you on behalf of your school against me. For the record I will now respond to the allegations made against me by Mr. Mettin. 1) I am not an "Internet terrorist". This claim by Mr. Mettin below is not only false but seriously libelous, slanderous and defamatory. 2) I was never an employee of the Public-Root. I was a consultant since 2003. And I was not fired. I walked out along with other consultants because of the criminal activity uncovered by me - being mainly the embezzlement of funds, money laundering and tax evasion by senior executive staff. 3) I never attacked Christopher's Gymnasium Querfurt High School. This claim is also false, libelous, slanderous and defamatory. I did attempt to email senior staff and also called by phone but was unable to get in touch with anyone except Mr. Mettin. I therefore have no idea if school staff know what Mr. Mettin is up to as I have been unable to contact a responsible adult at the school. 4) Mr. Mettin's claims that the PublicRoot Consortium does not exist are false. The PublicRoot Consortium is organized as an unincorporated trust in Canada. 5) Mr. Mettin's claims below that his schools only involvement with the people who run the INAIC.com web site was to be "assigned a (top-level) domain by a company affiliated with the Public Root Ltd." is false. The top-level domain the Gymnasium Querfurt High School purchased from them is GQNET - a copy of the whois for this domain is attached at the end of this message as Appendix A. But as members here have pointed out Mr. Mettin's forgot to mention that the Gymnasium Querfurt High School also sells TLDs for these shell companies and non existent organizations. 6) Mr. Mettin's claims that my actions resulted in the shut down of a company are partially true. My actions resulted in the business failure of at least three companies and the investigation of a number of individuals for criminal acts being tax evasion and money laundering. Some individuals involved in these investigations have settled with the Dutch tax authorities. We also had the full support of the Turkish Government and SITA, as well as a number of other influential people, organization and countries. That support evaporated when I when public and blew the whistle. As a result of my actions fewer people ended up loosing their money in this scam which was my intention. 7) Mr. Mettin's claims that I lie are also false, libelous, slanderous and defamatory. regards joe baptista On Sat, Nov 28, 2009 at 8:55 PM, Christopher Mettin wrote: ARIN Community, The following message was sent recently to the ARIN mailing list by an Internet terrorist known as Joe Baptista. >OK - before someone end up donating addresses and gets involved in a fraud - I think it's time for a little >backgrounder on Christopher Mettin. > >http://bit.ly/87Yjir > >What Chris needs are a few blocks of /24 to setup a root system based on what I know of him. Thats what I think >he is going on about - that they need fixed IP. About the only protocol widely used still requiring fixed IP >for the root cache. > >Be careful I have been unable to confirm what he is doing is even authorized by the school. If you feel so >inclined to provide /24 blocks to them - make sure a responsible adult from the school signs on the dotted >line, takes responsibility and absolves you of any legal liability. > >I do however support his initial point. These are only numbers and ARIN RIPE APNIC et. al. are making a killing >for just providing a database function - the rest as far as I can see is mainly hype and make work projects. I >think thats been mentioned before. A few months ago my school has been attacked by this guy. He did already make an entire company shut down. His best weapons are lies. All that started when he was fired by the Public Root in 2005. We have been assigned a domain by a company affiliated with the Public Root Ltd. and so we became a major target to him. He sends his emails from a domain publishing a website of a "PublicRoot Consortium" which does not exist. The contact address of this consortium is a private home in an Ontarian suburb. Sending emails using this domain he tries to make people believe he is an official employee of the Public Root. The IP addresses shall be in no way used with any root system. For further reference on Joe Baptista, see http://inaic.com/index.php?p=news-25-08-2008. Sincerely yours, Christopher Mettin Gymnasium Querfurt High School APPENDIX A: whois -h whois.inaic.net GQNET Corporate TLD (cTLD): .GQNET TLD Status: Active TLD Register Date: 13-05-2009 TLD Updated: 29-05-2009 TLD Expire Date: 13-05-2010 Preferred Domain Name Registry: GQnet ( http://gqbc-online.com ) TLD Registrant: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Administrative contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Technical contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Billing contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Servers: TLD Server1: tld1.public-root.net - IPV4: 84.22.100.6 TLD Server2: tld2.public-root.net - IPV4: 57.67.193.188 TLD Server3: tld3.public-root.net - IPV4: 199.5.156.122 By submitting a Global TLD WHOIS query you agree to use this data only for lawful purposes. Under no circumstances will you use this data to: (1) Allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail, telephone, or facsimile; or: (2) Enable high volume, automated, electronic processes against the INAIC or its data systems and networks. The compilation, repackaging, dissemination or other use of this data is expressly prohibited without the prior written consent of the INAIC. The INAIC reserves the right to revoke access to the Global TLD WHOIS Database in its sole discretion, including without limitation, for excessive querying of the Global TLD WHOIS Database or for failure to otherwise abide by this policy. TLD Registrants are responsible for the information maintained in the directory services database.The INAIC does not guarantee the accuracy of the information maintained in the Global TLD WHOIS Database. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbanks at giantcomm.net Tue Dec 1 12:31:20 2009 From: kbanks at giantcomm.net (Kyle Banks) Date: Tue, 1 Dec 2009 11:31:20 -0600 Subject: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School In-Reply-To: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> Message-ID: <021c01ca72ac$18f37430$3501a8c0@macc173.net> Good Night.. What did I miss over this weekend. I'm gonna have to look back now you've got my interest. K. Vincent Banks Service/Technical Representative Giant Communications 785-362-9331 EXT. 108 kbanks at giantcomm.net -- Blessed is he who expects nothing, for he shall never be disappointed--Benjamin Franklin _____ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Joe Baptista Sent: Tuesday, December 01, 2009 11:04 AM To: Christopher Mettin Cc: arin-ppml at arin.net Subject: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School Dear Christopher and ARIN community: I am requesting a public apology from you Christopher Mettin and your organization the Gymnasium Querfurt High School for calling me an Internet terrorist, a liar and other libelous, slanderous and defamatory statements made by you in a public forum against me. Also Christopher please do not jump the gun and make this decision on your own. Kindly consult your supervisor and principle with respect to my request and take the time to show them my request as well as the statements made by you on behalf of your school against me. For the record I will now respond to the allegations made against me by Mr. Mettin. 1) I am not an "Internet terrorist". This claim by Mr. Mettin below is not only false but seriously libelous, slanderous and defamatory. 2) I was never an employee of the Public-Root. I was a consultant since 2003. And I was not fired. I walked out along with other consultants because of the criminal activity uncovered by me - being mainly the embezzlement of funds, money laundering and tax evasion by senior executive staff. 3) I never attacked Christopher's Gymnasium Querfurt High School. This claim is also false, libelous, slanderous and defamatory. I did attempt to email senior staff and also called by phone but was unable to get in touch with anyone except Mr. Mettin. I therefore have no idea if school staff know what Mr. Mettin is up to as I have been unable to contact a responsible adult at the school. 4) Mr. Mettin's claims that the PublicRoot Consortium does not exist are false. The PublicRoot Consortium is organized as an unincorporated trust in Canada. 5) Mr. Mettin's claims below that his schools only involvement with the people who run the INAIC.com web site was to be "assigned a (top-level) domain by a company affiliated with the Public Root Ltd." is false. The top-level domain the Gymnasium Querfurt High School purchased from them is GQNET - a copy of the whois for this domain is attached at the end of this message as Appendix A. But as members here have pointed out Mr. Mettin's forgot to mention that the Gymnasium Querfurt High School also sells TLDs for these shell companies and non existent organizations. 6) Mr. Mettin's claims that my actions resulted in the shut down of a company are partially true. My actions resulted in the business failure of at least three companies and the investigation of a number of individuals for criminal acts being tax evasion and money laundering. Some individuals involved in these investigations have settled with the Dutch tax authorities. We also had the full support of the Turkish Government and SITA, as well as a number of other influential people, organization and countries. That support evaporated when I when public and blew the whistle. As a result of my actions fewer people ended up loosing their money in this scam which was my intention. 7) Mr. Mettin's claims that I lie are also false, libelous, slanderous and defamatory. regards joe baptista On Sat, Nov 28, 2009 at 8:55 PM, Christopher Mettin wrote: ARIN Community, The following message was sent recently to the ARIN mailing list by an Internet terrorist known as Joe Baptista. >OK - before someone end up donating addresses and gets involved in a fraud - I think it's time for a little >backgrounder on Christopher Mettin. > >http://bit.ly/87Yjir > >What Chris needs are a few blocks of /24 to setup a root system based on what I know of him. Thats what I think >he is going on about - that they need fixed IP. About the only protocol widely used still requiring fixed IP >for the root cache. > >Be careful I have been unable to confirm what he is doing is even authorized by the school. If you feel so >inclined to provide /24 blocks to them - make sure a responsible adult from the school signs on the dotted >line, takes responsibility and absolves you of any legal liability. > >I do however support his initial point. These are only numbers and ARIN RIPE APNIC et. al. are making a killing >for just providing a database function - the rest as far as I can see is mainly hype and make work projects. I >think thats been mentioned before. A few months ago my school has been attacked by this guy. He did already make an entire company shut down. His best weapons are lies. All that started when he was fired by the Public Root in 2005. We have been assigned a domain by a company affiliated with the Public Root Ltd. and so we became a major target to him. He sends his emails from a domain publishing a website of a "PublicRoot Consortium" which does not exist. The contact address of this consortium is a private home in an Ontarian suburb. Sending emails using this domain he tries to make people believe he is an official employee of the Public Root. The IP addresses shall be in no way used with any root system. For further reference on Joe Baptista, see http://inaic.com/index.php?p=news-25-08-2008. Sincerely yours, Christopher Mettin Gymnasium Querfurt High School APPENDIX A: whois -h whois.inaic.net GQNET Corporate TLD (cTLD): .GQNET TLD Status: Active TLD Register Date: 13-05-2009 TLD Updated: 29-05-2009 TLD Expire Date: 13-05-2010 Preferred Domain Name Registry: GQnet ( http://gqbc-online.com ) TLD Registrant: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Administrative contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Technical contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Billing contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Servers: TLD Server1: tld1.public-root.net - IPV4: 84.22.100.6 TLD Server2: tld2.public-root.net - IPV4: 57.67.193.188 TLD Server3: tld3.public-root.net - IPV4: 199.5.156.122 By submitting a Global TLD WHOIS query you agree to use this data only for lawful purposes. Under no circumstances will you use this data to: (1) Allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail, telephone, or facsimile; or: (2) Enable high volume, automated, electronic processes against the INAIC or its data systems and networks. The compilation, repackaging, dissemination or other use of this data is expressly prohibited without the prior written consent of the INAIC. The INAIC reserves the right to revoke access to the Global TLD WHOIS Database in its sole discretion, including without limitation, for excessive querying of the Global TLD WHOIS Database or for failure to otherwise abide by this policy. TLD Registrants are responsible for the information maintained in the directory services database.The INAIC does not guarantee the accuracy of the information maintained in the Global TLD WHOIS Database. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbanks at giantcomm.net Tue Dec 1 12:43:23 2009 From: kbanks at giantcomm.net (Kyle Banks) Date: Tue, 1 Dec 2009 11:43:23 -0600 Subject: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School In-Reply-To: References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> Message-ID: <022d01ca72ad$c7b4bd20$3501a8c0@macc173.net> "the miss-identification as employee of the Public Root, a registered British company (see his email address for that)." I do not feel that he misidentified himself, See point 2 of his request for an apology 2) I was never an employee of the Public-Root. I was a consultant since 2003. And I was not fired. I walked out along with other consultants because of the criminal activity uncovered by me - being mainly the embezzlement of funds, money laundering and tax evasion by senior executive staff As for his E-mail address, being employed by an ISP that provides E-mail hosting, I know first hand that anyone, anywhere can request whatever username they would like for an E-mail address (providing the limitations of the policies set forth by the provider.) There are, however, limitations on domains that used, or squatted on I.E. anycelebrityname.com usually can't be acquired by just any user, without providing identification/ authorization to act on that celebrity's behalf. And in the words of Forest Gump "that's all I really got to say about that" K. Vincent Banks Service/Technical Representative Giant Communications 785-362-9331 EXT. 108 kbanks at giantcomm.net -- Blessed is he who expects nothing, for he shall never be disappointed--Benjamin Franklin _____ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Christopher Mettin Sent: Tuesday, December 01, 2009 11:28 AM To: 'Joe Baptista'; arin-ppml at arin.net Subject: Re: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School Everything I said about Joe Baptista entirely true and confirmed by evidences and statements by several other people. I hereby request to dismiss Joe Baptista from the ARIN mailing list for the falsification of documents and the miss-identification as employee of the Public Root, a registered British company (see his email address for that). We received a dozen emails a day in September from Joe Baptista, I see no point why this should not be called spamming. The clarify, we did not buy a TLD that we know won't ever be accessible by everyone (except all Internet users queried the Public Root for DNS resolution). The TLD was given to us for educational purposes and in return to open the TLD registration to other people on our site. Further, Public Root, as a British company, and INAIC, a New York-based company, exist and full-fill the service they offer. Their TLD and root services are widely known as alternative, even Wikipedia has a section about them on their alternative roots articles. So far this cannot be called a scam, rather Joe Baptista is the spam ignoring Canadian court orders. For all the times this global network shall exist, the World shall have knowledge about the activities of the Internet terrorist Joe Baptista. Sources: http://inaic.com/index.php?p=internet-terror http://whocalled.us/lookup/4169126551 From: publicroot.info at gmail.com [mailto:publicroot.info at gmail.com] On Behalf Of Joe Baptista Sent: Tuesday, December 01, 2009 6:04 PM To: Christopher Mettin Cc: arin-ppml at arin.net Subject: Apology requested from Christopher Mettin and the Gymnasium Querfurt High School Dear Christopher and ARIN community: I am requesting a public apology from you Christopher Mettin and your organization the Gymnasium Querfurt High School for calling me an Internet terrorist, a liar and other libelous, slanderous and defamatory statements made by you in a public forum against me. Also Christopher please do not jump the gun and make this decision on your own. Kindly consult your supervisor and principle with respect to my request and take the time to show them my request as well as the statements made by you on behalf of your school against me. For the record I will now respond to the allegations made against me by Mr. Mettin. 1) I am not an "Internet terrorist". This claim by Mr. Mettin below is not only false but seriously libelous, slanderous and defamatory. 2) I was never an employee of the Public-Root. I was a consultant since 2003. And I was not fired. I walked out along with other consultants because of the criminal activity uncovered by me - being mainly the embezzlement of funds, money laundering and tax evasion by senior executive staff. 3) I never attacked Christopher's Gymnasium Querfurt High School. This claim is also false, libelous, slanderous and defamatory. I did attempt to email senior staff and also called by phone but was unable to get in touch with anyone except Mr. Mettin. I therefore have no idea if school staff know what Mr. Mettin is up to as I have been unable to contact a responsible adult at the school. 4) Mr. Mettin's claims that the PublicRoot Consortium does not exist are false. The PublicRoot Consortium is organized as an unincorporated trust in Canada. 5) Mr. Mettin's claims below that his schools only involvement with the people who run the INAIC.com web site was to be "assigned a (top-level) domain by a company affiliated with the Public Root Ltd." is false. The top-level domain the Gymnasium Querfurt High School purchased from them is GQNET - a copy of the whois for this domain is attached at the end of this message as Appendix A. But as members here have pointed out Mr. Mettin's forgot to mention that the Gymnasium Querfurt High School also sells TLDs for these shell companies and non existent organizations. 6) Mr. Mettin's claims that my actions resulted in the shut down of a company are partially true. My actions resulted in the business failure of at least three companies and the investigation of a number of individuals for criminal acts being tax evasion and money laundering. Some individuals involved in these investigations have settled with the Dutch tax authorities. We also had the full support of the Turkish Government and SITA, as well as a number of other influential people, organization and countries. That support evaporated when I when public and blew the whistle. As a result of my actions fewer people ended up loosing their money in this scam which was my intention. 7) Mr. Mettin's claims that I lie are also false, libelous, slanderous and defamatory. regards joe baptista On Sat, Nov 28, 2009 at 8:55 PM, Christopher Mettin wrote: ARIN Community, The following message was sent recently to the ARIN mailing list by an Internet terrorist known as Joe Baptista. >OK - before someone end up donating addresses and gets involved in a fraud - I think it's time for a little >backgrounder on Christopher Mettin. > >http://bit.ly/87Yjir > >What Chris needs are a few blocks of /24 to setup a root system based on what I know of him. Thats what I think >he is going on about - that they need fixed IP. About the only protocol widely used still requiring fixed IP >for the root cache. > >Be careful I have been unable to confirm what he is doing is even authorized by the school. If you feel so >inclined to provide /24 blocks to them - make sure a responsible adult from the school signs on the dotted >line, takes responsibility and absolves you of any legal liability. > >I do however support his initial point. These are only numbers and ARIN RIPE APNIC et. al. are making a killing >for just providing a database function - the rest as far as I can see is mainly hype and make work projects. I >think thats been mentioned before. A few months ago my school has been attacked by this guy. He did already make an entire company shut down. His best weapons are lies. All that started when he was fired by the Public Root in 2005. We have been assigned a domain by a company affiliated with the Public Root Ltd. and so we became a major target to him. He sends his emails from a domain publishing a website of a "PublicRoot Consortium" which does not exist. The contact address of this consortium is a private home in an Ontarian suburb. Sending emails using this domain he tries to make people believe he is an official employee of the Public Root. The IP addresses shall be in no way used with any root system. For further reference on Joe Baptista, see http://inaic.com/index.php?p=news-25-08-2008. Sincerely yours, Christopher Mettin Gymnasium Querfurt High School APPENDIX A: whois -h whois.inaic.net GQNET Corporate TLD (cTLD): .GQNET TLD Status: Active TLD Register Date: 13-05-2009 TLD Updated: 29-05-2009 TLD Expire Date: 13-05-2010 Preferred Domain Name Registry: GQnet ( http://gqbc-online.com ) TLD Registrant: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Administrative contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Technical contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Billing contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Servers: TLD Server1: tld1.public-root.net - IPV4: 84.22.100.6 TLD Server2: tld2.public-root.net - IPV4: 57.67.193.188 TLD Server3: tld3.public-root.net - IPV4: 199.5.156.122 By submitting a Global TLD WHOIS query you agree to use this data only for lawful purposes. Under no circumstances will you use this data to: (1) Allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail, telephone, or facsimile; or: (2) Enable high volume, automated, electronic processes against the INAIC or its data systems and networks. The compilation, repackaging, dissemination or other use of this data is expressly prohibited without the prior written consent of the INAIC. The INAIC reserves the right to revoke access to the Global TLD WHOIS Database in its sole discretion, including without limitation, for excessive querying of the Global TLD WHOIS Database or for failure to otherwise abide by this policy. TLD Registrants are responsible for the information maintained in the directory services database.The INAIC does not guarantee the accuracy of the information maintained in the Global TLD WHOIS Database. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Dec 1 12:57:23 2009 From: bill at herrin.us (William Herrin) Date: Tue, 1 Dec 2009 12:57:23 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B15453D.2070309@ipinc.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> Message-ID: <3c3e3fca0912010957m46189afdw7c07ae49cceeb760@mail.gmail.com> On Tue, Dec 1, 2009 at 11:33 AM, Ted Mittelstaedt wrote: >> If I've missed this discussion here (or in other forums) >> references welcome, a cursory search yields nothing expressly >> related to this topic. > > Probably because of the same reason that a cursory search > won't find any discussions about the pros and cons of > staring straight into the sun for an hour at high noon. Ted, Historically speaking, that's how ship captains navigated with early sextants. Over time they ended up with one more or less dead eye which was only useful for staring into the sun. The eye patch wasn't because he lost it in a fight. I wouldn't personally want to try it, but not everything that seems like it would be absurd in all cases actually is. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Tue Dec 1 13:07:21 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 01 Dec 2009 10:07:21 -0800 Subject: [arin-ppml] Apology requested from Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> Message-ID: <4B155B59.6070606@ipinc.net> Joe and Christopher, It was only fun to watch until you guys started breaking the furniture. Ted Joe Baptista wrote: > > Dear Christopher and ARIN community: > > I am requesting a public apology from you Christopher Mettin and your > organization the Gymnasium Querfurt High School for calling me an > Internet terrorist, a liar and other libelous, slanderous and defamatory > statements made by you in a public forum against me. > > Also Christopher please do not jump the gun and make this decision on > your own. Kindly consult your supervisor and principle with respect to > my request and take the time to show them my request as well as the > statements made by you on behalf of your school against me. > > For the record I will now respond to the allegations made against me by > Mr. Mettin. > > 1) I am not an "Internet terrorist". This claim by Mr. Mettin below is > not only false but seriously libelous, slanderous and defamatory. > > 2) I was never an employee of the Public-Root. I was a consultant since > 2003. And I was not fired. I walked out along with other consultants > because of the criminal activity uncovered by me - being mainly the > embezzlement of funds, money laundering and tax evasion by senior > executive staff. > > 3) I never attacked Christopher's Gymnasium Querfurt High School. This > claim is also false, libelous, slanderous and defamatory. I did attempt > to email senior staff and also called by phone but was unable to get in > touch with anyone except Mr. Mettin. I therefore have no idea if school > staff know what Mr. Mettin is up to as I have been unable to contact a > responsible adult at the school. > > 4) Mr. Mettin's claims that the PublicRoot Consortium does not exist are > false. The PublicRoot Consortium is organized as an unincorporated trust > in Canada. > > 5) Mr. Mettin's claims below that his schools only involvement with the > people who run the INAIC.com web site was to be "assigned a (top-level) > domain by a company affiliated with the Public Root Ltd." is false. The > top-level domain the Gymnasium Querfurt High School purchased from them > is GQNET - a copy of the whois for this domain is attached at the end of > this message as Appendix A. > > But as members here have pointed out Mr. Mettin's forgot to mention that > the Gymnasium Querfurt High School also sells TLDs for these shell > companies and non existent organizations. > > 6) Mr. Mettin's claims that my actions resulted in the shut down of a > company are partially true. My actions resulted in the business failure > of at least three companies and the investigation of a number of > individuals for criminal acts being tax evasion and money laundering. > Some individuals involved in these investigations have settled with the > Dutch tax authorities. > > We also had the full support of the Turkish Government and SITA, as well > as a number of other influential people, organization and countries. > That support evaporated when I when public and blew the whistle. > > As a result of my actions fewer people ended up loosing their money in > this scam which was my intention. > > 7) Mr. Mettin's claims that I lie are also false, libelous, slanderous > and defamatory. > > regards > joe baptista > > On Sat, Nov 28, 2009 at 8:55 PM, Christopher Mettin > > wrote: > > ARIN Community, > > The following message was sent recently to the ARIN mailing list by an > Internet terrorist known as Joe Baptista. > > >OK - before someone end up donating addresses and gets involved in > a fraud > - I think it's time for a little >backgrounder on Christopher Mettin. > > > >http://bit.ly/87Yjir > > > >What Chris needs are a few blocks of /24 to setup a root system > based on > what I know of him. Thats what I think >he is going on about - that they > need fixed IP. About the only protocol widely used still requiring > fixed IP > >for the root cache. > > > >Be careful I have been unable to confirm what he is doing is even > authorized by the school. If you feel so >inclined to provide /24 > blocks to > them - make sure a responsible adult from the school signs on the dotted > >line, takes responsibility and absolves you of any legal liability. > > > >I do however support his initial point. These are only numbers and > ARIN > RIPE APNIC et. al. are making a killing >for just providing a database > function - the rest as far as I can see is mainly hype and make work > projects. I >think thats been mentioned before. > > A few months ago my school has been attacked by this guy. He did already > make an entire company shut down. His best weapons are lies. > > All that started when he was fired by the Public Root in 2005. We > have been > assigned a domain by a company affiliated with the Public Root Ltd. > and so > we became a major target to him. He sends his emails from a domain > publishing a website of a "PublicRoot Consortium" which does not > exist. The > contact address of this consortium is a private home in an Ontarian > suburb. > Sending emails using this domain he tries to make people believe he > is an > official employee of the Public Root. > > The IP addresses shall be in no way used with any root system. > > For further reference on Joe Baptista, see > http://inaic.com/index.php?p=news-25-08-2008. > > Sincerely yours, > Christopher Mettin > Gymnasium Querfurt High School > > > > APPENDIX A: whois -h whois.inaic.net GQNET > > Corporate TLD (cTLD): .GQNET > TLD Status: Active > TLD Register Date: 13-05-2009 > TLD Updated: 29-05-2009 > TLD Expire Date: 13-05-2010 > Preferred Domain Name Registry: GQnet ( http://gqbc-online.com ) > > TLD Registrant: > Name: Christopher Mettin > Company name: Gymnasium Querfurt High School > Address: An der Geistpromenade 29 > City: Quefurt > State: > Zip: 06268 > Country: Germany > Phone: +49.347.712.2226 > Cell phone: > Fax: +49.347.712.8826 > Email: cmettin at gqbc-online.com > > TLD Administrative contact: > Name: Christopher Mettin > Company name: Gymnasium Querfurt High School > Address: An der Geistpromenade 29 > City: Quefurt > State: > Zip: 06268 > Country: Germany > Phone: +49.347.712.2226 > Cell phone: > Fax: +49.347.712.8826 > Email: cmettin at gqbc-online.com > > TLD Technical contact: > Name: Christopher Mettin > Company name: Gymnasium Querfurt High School > Address: An der Geistpromenade 29 > City: Quefurt > State: > Zip: 06268 > Country: Germany > Phone: +49.347.712.2226 > Cell phone: > Fax: +49.347.712.8826 > Email: cmettin at gqbc-online.com > > TLD Billing contact: > Name: Christopher Mettin > Company name: Gymnasium Querfurt High School > Address: An der Geistpromenade 29 > City: Quefurt > State: > Zip: 06268 > Country: Germany > Phone: +49.347.712.2226 > Cell phone: > Fax: +49.347.712.8826 > Email: cmettin at gqbc-online.com > > TLD Servers: > TLD Server1: tld1.public-root.net - > IPV4: 84.22.100.6 > TLD Server2: tld2.public-root.net - > IPV4: 57.67.193.188 > TLD Server3: tld3.public-root.net - > IPV4: 199.5.156.122 > > By submitting a Global TLD WHOIS query you agree to use this data only > for lawful purposes. Under no circumstances will you use this data to: > (1) Allow, enable, or otherwise support the transmission of mass > unsolicited, commercial advertising or solicitations via e-mail, > telephone, or facsimile; or: (2) Enable high volume, automated, > electronic processes against the INAIC or its data systems and networks. > The compilation, repackaging, dissemination or other use of this data is > expressly prohibited without the prior written consent of the INAIC. The > INAIC reserves the right to revoke access to the Global TLD WHOIS > Database in its sole discretion, including without limitation, for > excessive querying of the Global TLD WHOIS Database or for failure to > otherwise abide by this policy. > > TLD Registrants are responsible for the information maintained in the > directory services database.The INAIC does not guarantee the accuracy of > the information maintained in the Global TLD WHOIS Database. > > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From kbanks at giantcomm.net Tue Dec 1 13:10:02 2009 From: kbanks at giantcomm.net (Kyle Banks) Date: Tue, 1 Dec 2009 12:10:02 -0600 Subject: [arin-ppml] Apology requested from Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: <4B155B59.6070606@ipinc.net> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <4B155B59.6070606@ipinc.net> Message-ID: <024001ca72b1$80ae87e0$3501a8c0@macc173.net> Ted, Literally laughed out loud at that one... its all fun and games until somebody loses an eye.. K. Vincent Banks Service/Technical Representative Giant Communications 785-362-9331 EXT. 108 kbanks at giantcomm.net -- Blessed is he who expects nothing, for he shall never be disappointed--Benjamin Franklin -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Tuesday, December 01, 2009 12:07 PM To: Joe Baptista Cc: Christopher Mettin; arin-ppml at arin.net Subject: Re: [arin-ppml] Apology requested from Christopher Mettin and the Gymnasium Querfurt High School Joe and Christopher, It was only fun to watch until you guys started breaking the furniture. Ted Joe Baptista wrote: > > Dear Christopher and ARIN community: > > I am requesting a public apology from you Christopher Mettin and your > organization the Gymnasium Querfurt High School for calling me an > Internet terrorist, a liar and other libelous, slanderous and defamatory > statements made by you in a public forum against me. > > Also Christopher please do not jump the gun and make this decision on > your own. Kindly consult your supervisor and principle with respect to > my request and take the time to show them my request as well as the > statements made by you on behalf of your school against me. > > For the record I will now respond to the allegations made against me by > Mr. Mettin. > > 1) I am not an "Internet terrorist". This claim by Mr. Mettin below is > not only false but seriously libelous, slanderous and defamatory. > > 2) I was never an employee of the Public-Root. I was a consultant since > 2003. And I was not fired. I walked out along with other consultants > because of the criminal activity uncovered by me - being mainly the > embezzlement of funds, money laundering and tax evasion by senior > executive staff. > > 3) I never attacked Christopher's Gymnasium Querfurt High School. This > claim is also false, libelous, slanderous and defamatory. I did attempt > to email senior staff and also called by phone but was unable to get in > touch with anyone except Mr. Mettin. I therefore have no idea if school > staff know what Mr. Mettin is up to as I have been unable to contact a > responsible adult at the school. > > 4) Mr. Mettin's claims that the PublicRoot Consortium does not exist are > false. The PublicRoot Consortium is organized as an unincorporated trust > in Canada. > > 5) Mr. Mettin's claims below that his schools only involvement with the > people who run the INAIC.com web site was to be "assigned a (top-level) > domain by a company affiliated with the Public Root Ltd." is false. The > top-level domain the Gymnasium Querfurt High School purchased from them > is GQNET - a copy of the whois for this domain is attached at the end of > this message as Appendix A. > > But as members here have pointed out Mr. Mettin's forgot to mention that > the Gymnasium Querfurt High School also sells TLDs for these shell > companies and non existent organizations. > > 6) Mr. Mettin's claims that my actions resulted in the shut down of a > company are partially true. My actions resulted in the business failure > of at least three companies and the investigation of a number of > individuals for criminal acts being tax evasion and money laundering. > Some individuals involved in these investigations have settled with the > Dutch tax authorities. > > We also had the full support of the Turkish Government and SITA, as well > as a number of other influential people, organization and countries. > That support evaporated when I when public and blew the whistle. > > As a result of my actions fewer people ended up loosing their money in > this scam which was my intention. > > 7) Mr. Mettin's claims that I lie are also false, libelous, slanderous > and defamatory. > > regards > joe baptista > > On Sat, Nov 28, 2009 at 8:55 PM, Christopher Mettin > > wrote: > > ARIN Community, > > The following message was sent recently to the ARIN mailing list by an > Internet terrorist known as Joe Baptista. > > >OK - before someone end up donating addresses and gets involved in > a fraud > - I think it's time for a little >backgrounder on Christopher Mettin. > > > >http://bit.ly/87Yjir > > > >What Chris needs are a few blocks of /24 to setup a root system > based on > what I know of him. Thats what I think >he is going on about - that they > need fixed IP. About the only protocol widely used still requiring > fixed IP > >for the root cache. > > > >Be careful I have been unable to confirm what he is doing is even > authorized by the school. If you feel so >inclined to provide /24 > blocks to > them - make sure a responsible adult from the school signs on the dotted > >line, takes responsibility and absolves you of any legal liability. > > > >I do however support his initial point. These are only numbers and > ARIN > RIPE APNIC et. al. are making a killing >for just providing a database > function - the rest as far as I can see is mainly hype and make work > projects. I >think thats been mentioned before. > > A few months ago my school has been attacked by this guy. He did already > make an entire company shut down. His best weapons are lies. > > All that started when he was fired by the Public Root in 2005. We > have been > assigned a domain by a company affiliated with the Public Root Ltd. > and so > we became a major target to him. He sends his emails from a domain > publishing a website of a "PublicRoot Consortium" which does not > exist. The > contact address of this consortium is a private home in an Ontarian > suburb. > Sending emails using this domain he tries to make people believe he > is an > official employee of the Public Root. > > The IP addresses shall be in no way used with any root system. > > For further reference on Joe Baptista, see > http://inaic.com/index.php?p=news-25-08-2008. > > Sincerely yours, > Christopher Mettin > Gymnasium Querfurt High School > > > > APPENDIX A: whois -h whois.inaic.net GQNET > > Corporate TLD (cTLD): .GQNET > TLD Status: Active > TLD Register Date: 13-05-2009 > TLD Updated: 29-05-2009 > TLD Expire Date: 13-05-2010 > Preferred Domain Name Registry: GQnet ( http://gqbc-online.com ) > > TLD Registrant: > Name: Christopher Mettin > Company name: Gymnasium Querfurt High School > Address: An der Geistpromenade 29 > City: Quefurt > State: > Zip: 06268 > Country: Germany > Phone: +49.347.712.2226 > Cell phone: > Fax: +49.347.712.8826 > Email: cmettin at gqbc-online.com > > TLD Administrative contact: > Name: Christopher Mettin > Company name: Gymnasium Querfurt High School > Address: An der Geistpromenade 29 > City: Quefurt > State: > Zip: 06268 > Country: Germany > Phone: +49.347.712.2226 > Cell phone: > Fax: +49.347.712.8826 > Email: cmettin at gqbc-online.com > > TLD Technical contact: > Name: Christopher Mettin > Company name: Gymnasium Querfurt High School > Address: An der Geistpromenade 29 > City: Quefurt > State: > Zip: 06268 > Country: Germany > Phone: +49.347.712.2226 > Cell phone: > Fax: +49.347.712.8826 > Email: cmettin at gqbc-online.com > > TLD Billing contact: > Name: Christopher Mettin > Company name: Gymnasium Querfurt High School > Address: An der Geistpromenade 29 > City: Quefurt > State: > Zip: 06268 > Country: Germany > Phone: +49.347.712.2226 > Cell phone: > Fax: +49.347.712.8826 > Email: cmettin at gqbc-online.com > > TLD Servers: > TLD Server1: tld1.public-root.net - > IPV4: 84.22.100.6 > TLD Server2: tld2.public-root.net - > IPV4: 57.67.193.188 > TLD Server3: tld3.public-root.net - > IPV4: 199.5.156.122 > > By submitting a Global TLD WHOIS query you agree to use this data only > for lawful purposes. Under no circumstances will you use this data to: > (1) Allow, enable, or otherwise support the transmission of mass > unsolicited, commercial advertising or solicitations via e-mail, > telephone, or facsimile; or: (2) Enable high volume, automated, > electronic processes against the INAIC or its data systems and networks. > The compilation, repackaging, dissemination or other use of this data is > expressly prohibited without the prior written consent of the INAIC. The > INAIC reserves the right to revoke access to the Global TLD WHOIS > Database in its sole discretion, including without limitation, for > excessive querying of the Global TLD WHOIS Database or for failure to > otherwise abide by this policy. > > TLD Registrants are responsible for the information maintained in the > directory services database.The INAIC does not guarantee the accuracy of > the information maintained in the Global TLD WHOIS Database. > > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From farmer at umn.edu Tue Dec 1 13:11:56 2009 From: farmer at umn.edu (David Farmer) Date: Tue, 01 Dec 2009 12:11:56 -0600 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out - Last Call In-Reply-To: <4B0C074D.9020608@arin.net> References: <4B0C074D.9020608@arin.net> Message-ID: <4B15080C.28232.1D4A9DEF@farmer.umn.edu> Now that the Thanksgiving holiday has passed here in the US, I would like to remind everyone that there is an important pice of policy business on the table for PPML. Draft Policy 2009-8: Equitable IPv4 Run-Out is in Last Call. Three of the last four Draft Policies had little or no Last Call comments; two hand no comments, one had one comment, and the forth policy had 10 comments from 5 individuals. As one of the AC shepards for this proposal I would appreciate any Last Call comments you may have on this Draft Policy, even if it is simply that you support the policy as written. The text of this Draft Policy changed significantly from the version discussed on the floor at Dearborn, so please take a moment and read it carefully including the Rationale. Thank you, And finally in the spirit of the upcoming holidays; Best wishes to you and yours; Peace on Earth, and; THE UNIVERSAL ADOPTION OF IPv6. :) On 24 Nov 2009 Member Services wrote: > The ARIN Advisory Council (AC) met on 19 November and decided to > send a revised version of the following draft policy to last call: > > Draft Policy 2009-8: Equitable IPv4 Run-Out > > Feedback is encouraged during this last call period. All comments should > be provided to the Public Policy Mailing List. This last call will > expire on 10 December 2009. After last call the AC will conduct their > last call review. > > The draft policy text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy 2009-8 > Equitable IPv4 Run-Out > > Version/Date: 24 November 2009 > > Policy statement: > > Rename NRPM 4.2.4.3; > > 4.2.4.3 Subscriber Members Less Than One Year > > Replace NRPM 4.2.4.4 with; > > 4.2.4.4 Subscriber Members After One Year > > After an organization has been a subscriber member of ARIN for one year, > they may choose to request up to a 12 month supply of IP addresses. > > When ARIN receives its last /8, by IANA implementing section 10.4.2.2, > the length of supply that an organization may request will be reduced. > An organization may choose to request up to a 3 month supply of IP > addresses. > > This reduction does not apply to resources received via section 8.3. An > organization receiving a transfer under section 8.3 may continue to > request up to a 12 month supply of IP addresses. > > Rationale: > > This policy is intended to ensure an equitable distribution of IPv4 > resources as run-out of the ARIN free pool occurs. This is achieved by > changing section 4.2.4.4 of the NRPM to reduce the length of supply of > IPv4 resources that may be requested when the IANA free pool runs-out. > Equity is accomplished by reducing the window that an advantage or > disadvantage can exist between competitors, that will be created when > one competitor receives a final allocation just before run-out and > another competitor does not. > > Further this policy ensures equity between incumbent resource holders > and new entrants by providing the same length of supply for each as the > ARIN free pool runs out. This eliminates a potential bias toward > incumbent resource holders that is created as a result of ARIN free pool > run-out interacting with resource allocation slow start for new entrants > in current policy. > > This policy is similar to ideas in RIPE policy proposal 2009-03 > (http://www.ripe.net/ripe/policies/proposals/2009-03.html), and has been > adapted by discussion and for use within the ARIN region. > > This policy is intended to be independent of other policies or proposals > to reserve address space for IPv6 transition or other purposes. It is > not intended to limit Transfers to Specified Recipients per section 8.3 > of the NRPM. > > This draft contains the elements that there seems to have been the > largest consensus for on the floor of ARIN XXIV Public Policy Meeting in > Dearborn, Michigan. Further, there was a strong preference that no > changes be triggered until IANA free pool run-out. > > Timetable for implementation: Immediate =============================================== David Farmer Email:farmer at umn.edu Office of Information Technology Networking & Telecomunication Services University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 =============================================== From cmettin at gqbc-online.com Tue Dec 1 13:11:27 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Tue, 1 Dec 2009 19:11:27 +0100 Subject: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School In-Reply-To: <022d01ca72ad$c7b4bd20$3501a8c0@macc173.net> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <022d01ca72ad$c7b4bd20$3501a8c0@macc173.net> Message-ID: >I do not feel that he misidentified himself, See point 2 of his request for an apology He was fired in 2005, whatever he worked as for INAIC. > There are, however, limitations on domains that used, or squatted on I.E. anycelebrityname.com usually can't > be acquired by just any user, without providing identification/ authorization to act on that celebrity's behalf. But anyone can register any domain. And according to the domain WHOIS, he registered the domain himself: Domain ID:D107958839-LROR Domain Name:PUBLICROOT.ORG Created On:25-Oct-2005 19:00:01 UTC Last Updated On:20-Oct-2009 01:50:41 UTC Expiration Date:25-Oct-2010 19:00:01 UTC Sponsoring Registrar:GoDaddy.com, Inc. (R91-LROR) Status:CLIENT DELETE PROHIBITED Status:CLIENT RENEW PROHIBITED Status:CLIENT TRANSFER PROHIBITED Status:CLIENT UPDATE PROHIBITED Registrant ID:GODA-014857820 Registrant Name:Joe Baptista Registrant Organization:The Public Root Consortium Registrant Street1:5921 Agean Drive Registrant Street2: Registrant Street3: Registrant City:Mississauga Registrant State/Province:Ontario Registrant Postal Code:L5M 6Y3 Registrant Country:CA Registrant Phone:+1.2025171593 Registrant Phone Ext.: Registrant FAX:+1.5094790084 Registrant FAX Ext.: Registrant Email:baptista at publicroot.org So if he was just a consultant, why does he own the domain of the company he worked for. That makes me believe he this is not the official domain of the Public Root. From: Kyle Banks [mailto:kbanks at giantcomm.net] Sent: Tuesday, December 01, 2009 6:43 PM To: 'Christopher Mettin'; 'Joe Baptista'; arin-ppml at arin.net Subject: RE: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School "the miss-identification as employee of the Public Root, a registered British company (see his email address for that)." I do not feel that he misidentified himself, See point 2 of his request for an apology 2) I was never an employee of the Public-Root. I was a consultant since 2003. And I was not fired. I walked out along with other consultants because of the criminal activity uncovered by me - being mainly the embezzlement of funds, money laundering and tax evasion by senior executive staff As for his E-mail address, being employed by an ISP that provides E-mail hosting, I know first hand that anyone, anywhere can request whatever username they would like for an E-mail address (providing the limitations of the policies set forth by the provider.) There are, however, limitations on domains that used, or squatted on I.E. anycelebrityname.com usually can't be acquired by just any user, without providing identification/ authorization to act on that celebrity's behalf. And in the words of Forest Gump "that's all I really got to say about that" K. Vincent Banks Service/Technical Representative Giant Communications 785-362-9331 EXT. 108 kbanks at giantcomm.net -- Blessed is he who expects nothing, for he shall never be disappointed--Benjamin Franklin _____ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Christopher Mettin Sent: Tuesday, December 01, 2009 11:28 AM To: 'Joe Baptista'; arin-ppml at arin.net Subject: Re: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School Everything I said about Joe Baptista entirely true and confirmed by evidences and statements by several other people. I hereby request to dismiss Joe Baptista from the ARIN mailing list for the falsification of documents and the miss-identification as employee of the Public Root, a registered British company (see his email address for that). We received a dozen emails a day in September from Joe Baptista, I see no point why this should not be called spamming. The clarify, we did not buy a TLD that we know won't ever be accessible by everyone (except all Internet users queried the Public Root for DNS resolution). The TLD was given to us for educational purposes and in return to open the TLD registration to other people on our site. Further, Public Root, as a British company, and INAIC, a New York-based company, exist and full-fill the service they offer. Their TLD and root services are widely known as alternative, even Wikipedia has a section about them on their alternative roots articles. So far this cannot be called a scam, rather Joe Baptista is the spam ignoring Canadian court orders. For all the times this global network shall exist, the World shall have knowledge about the activities of the Internet terrorist Joe Baptista. Sources: http://inaic.com/index.php?p=internet-terror http://whocalled.us/lookup/4169126551 From: publicroot.info at gmail.com [mailto:publicroot.info at gmail.com] On Behalf Of Joe Baptista Sent: Tuesday, December 01, 2009 6:04 PM To: Christopher Mettin Cc: arin-ppml at arin.net Subject: Apology requested from Christopher Mettin and the Gymnasium Querfurt High School Dear Christopher and ARIN community: I am requesting a public apology from you Christopher Mettin and your organization the Gymnasium Querfurt High School for calling me an Internet terrorist, a liar and other libelous, slanderous and defamatory statements made by you in a public forum against me. Also Christopher please do not jump the gun and make this decision on your own. Kindly consult your supervisor and principle with respect to my request and take the time to show them my request as well as the statements made by you on behalf of your school against me. For the record I will now respond to the allegations made against me by Mr. Mettin. 1) I am not an "Internet terrorist". This claim by Mr. Mettin below is not only false but seriously libelous, slanderous and defamatory. 2) I was never an employee of the Public-Root. I was a consultant since 2003. And I was not fired. I walked out along with other consultants because of the criminal activity uncovered by me - being mainly the embezzlement of funds, money laundering and tax evasion by senior executive staff. 3) I never attacked Christopher's Gymnasium Querfurt High School. This claim is also false, libelous, slanderous and defamatory. I did attempt to email senior staff and also called by phone but was unable to get in touch with anyone except Mr. Mettin. I therefore have no idea if school staff know what Mr. Mettin is up to as I have been unable to contact a responsible adult at the school. 4) Mr. Mettin's claims that the PublicRoot Consortium does not exist are false. The PublicRoot Consortium is organized as an unincorporated trust in Canada. 5) Mr. Mettin's claims below that his schools only involvement with the people who run the INAIC.com web site was to be "assigned a (top-level) domain by a company affiliated with the Public Root Ltd." is false. The top-level domain the Gymnasium Querfurt High School purchased from them is GQNET - a copy of the whois for this domain is attached at the end of this message as Appendix A. But as members here have pointed out Mr. Mettin's forgot to mention that the Gymnasium Querfurt High School also sells TLDs for these shell companies and non existent organizations. 6) Mr. Mettin's claims that my actions resulted in the shut down of a company are partially true. My actions resulted in the business failure of at least three companies and the investigation of a number of individuals for criminal acts being tax evasion and money laundering. Some individuals involved in these investigations have settled with the Dutch tax authorities. We also had the full support of the Turkish Government and SITA, as well as a number of other influential people, organization and countries. That support evaporated when I when public and blew the whistle. As a result of my actions fewer people ended up loosing their money in this scam which was my intention. 7) Mr. Mettin's claims that I lie are also false, libelous, slanderous and defamatory. regards joe baptista On Sat, Nov 28, 2009 at 8:55 PM, Christopher Mettin wrote: ARIN Community, The following message was sent recently to the ARIN mailing list by an Internet terrorist known as Joe Baptista. >OK - before someone end up donating addresses and gets involved in a fraud - I think it's time for a little >backgrounder on Christopher Mettin. > >http://bit.ly/87Yjir > >What Chris needs are a few blocks of /24 to setup a root system based on what I know of him. Thats what I think >he is going on about - that they need fixed IP. About the only protocol widely used still requiring fixed IP >for the root cache. > >Be careful I have been unable to confirm what he is doing is even authorized by the school. If you feel so >inclined to provide /24 blocks to them - make sure a responsible adult from the school signs on the dotted >line, takes responsibility and absolves you of any legal liability. > >I do however support his initial point. These are only numbers and ARIN RIPE APNIC et. al. are making a killing >for just providing a database function - the rest as far as I can see is mainly hype and make work projects. I >think thats been mentioned before. A few months ago my school has been attacked by this guy. He did already make an entire company shut down. His best weapons are lies. All that started when he was fired by the Public Root in 2005. We have been assigned a domain by a company affiliated with the Public Root Ltd. and so we became a major target to him. He sends his emails from a domain publishing a website of a "PublicRoot Consortium" which does not exist. The contact address of this consortium is a private home in an Ontarian suburb. Sending emails using this domain he tries to make people believe he is an official employee of the Public Root. The IP addresses shall be in no way used with any root system. For further reference on Joe Baptista, see http://inaic.com/index.php?p=news-25-08-2008. Sincerely yours, Christopher Mettin Gymnasium Querfurt High School APPENDIX A: whois -h whois.inaic.net GQNET Corporate TLD (cTLD): .GQNET TLD Status: Active TLD Register Date: 13-05-2009 TLD Updated: 29-05-2009 TLD Expire Date: 13-05-2010 Preferred Domain Name Registry: GQnet ( http://gqbc-online.com ) TLD Registrant: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Administrative contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Technical contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Billing contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Servers: TLD Server1: tld1.public-root.net - IPV4: 84.22.100.6 TLD Server2: tld2.public-root.net - IPV4: 57.67.193.188 TLD Server3: tld3.public-root.net - IPV4: 199.5.156.122 By submitting a Global TLD WHOIS query you agree to use this data only for lawful purposes. Under no circumstances will you use this data to: (1) Allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail, telephone, or facsimile; or: (2) Enable high volume, automated, electronic processes against the INAIC or its data systems and networks. The compilation, repackaging, dissemination or other use of this data is expressly prohibited without the prior written consent of the INAIC. The INAIC reserves the right to revoke access to the Global TLD WHOIS Database in its sole discretion, including without limitation, for excessive querying of the Global TLD WHOIS Database or for failure to otherwise abide by this policy. TLD Registrants are responsible for the information maintained in the directory services database.The INAIC does not guarantee the accuracy of the information maintained in the Global TLD WHOIS Database. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Tue Dec 1 13:22:53 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 01 Dec 2009 10:22:53 -0800 Subject: [arin-ppml] Apology requested from Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: <024001ca72b1$80ae87e0$3501a8c0@macc173.net> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <4B155B59.6070606@ipinc.net> <024001ca72b1$80ae87e0$3501a8c0@macc173.net> Message-ID: <4B155EFD.4010201@ipinc.net> Kyle Banks wrote: > Ted, > Literally laughed out loud at that one... its all fun and games until > somebody loses an eye.. > At least that's what Ralphie's mother told him.... Ted (you have to have seen The Christmas Story to get that one) > > K. Vincent Banks > Service/Technical Representative > Giant Communications > 785-362-9331 EXT. 108 > kbanks at giantcomm.net > > > -- Blessed is he who expects nothing, for he shall never be > disappointed--Benjamin Franklin > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Tuesday, December 01, 2009 12:07 PM > To: Joe Baptista > Cc: Christopher Mettin; arin-ppml at arin.net > Subject: Re: [arin-ppml] Apology requested from Christopher Mettin and the > Gymnasium Querfurt High School > > Joe and Christopher, > > It was only fun to watch until you guys started breaking the furniture. > > Ted > > Joe Baptista wrote: >> Dear Christopher and ARIN community: >> >> I am requesting a public apology from you Christopher Mettin and your >> organization the Gymnasium Querfurt High School for calling me an >> Internet terrorist, a liar and other libelous, slanderous and defamatory >> statements made by you in a public forum against me. >> >> Also Christopher please do not jump the gun and make this decision on >> your own. Kindly consult your supervisor and principle with respect to >> my request and take the time to show them my request as well as the >> statements made by you on behalf of your school against me. >> >> For the record I will now respond to the allegations made against me by >> Mr. Mettin. >> >> 1) I am not an "Internet terrorist". This claim by Mr. Mettin below is >> not only false but seriously libelous, slanderous and defamatory. >> >> 2) I was never an employee of the Public-Root. I was a consultant since >> 2003. And I was not fired. I walked out along with other consultants >> because of the criminal activity uncovered by me - being mainly the >> embezzlement of funds, money laundering and tax evasion by senior >> executive staff. >> >> 3) I never attacked Christopher's Gymnasium Querfurt High School. This >> claim is also false, libelous, slanderous and defamatory. I did attempt >> to email senior staff and also called by phone but was unable to get in >> touch with anyone except Mr. Mettin. I therefore have no idea if school >> staff know what Mr. Mettin is up to as I have been unable to contact a >> responsible adult at the school. >> >> 4) Mr. Mettin's claims that the PublicRoot Consortium does not exist are >> false. The PublicRoot Consortium is organized as an unincorporated trust >> in Canada. >> >> 5) Mr. Mettin's claims below that his schools only involvement with the >> people who run the INAIC.com web site was to be "assigned a (top-level) >> domain by a company affiliated with the Public Root Ltd." is false. The >> top-level domain the Gymnasium Querfurt High School purchased from them >> is GQNET - a copy of the whois for this domain is attached at the end of >> this message as Appendix A. >> >> But as members here have pointed out Mr. Mettin's forgot to mention that >> the Gymnasium Querfurt High School also sells TLDs for these shell >> companies and non existent organizations. >> >> 6) Mr. Mettin's claims that my actions resulted in the shut down of a >> company are partially true. My actions resulted in the business failure >> of at least three companies and the investigation of a number of >> individuals for criminal acts being tax evasion and money laundering. >> Some individuals involved in these investigations have settled with the >> Dutch tax authorities. >> >> We also had the full support of the Turkish Government and SITA, as well >> as a number of other influential people, organization and countries. >> That support evaporated when I when public and blew the whistle. >> >> As a result of my actions fewer people ended up loosing their money in >> this scam which was my intention. >> >> 7) Mr. Mettin's claims that I lie are also false, libelous, slanderous >> and defamatory. >> >> regards >> joe baptista >> >> On Sat, Nov 28, 2009 at 8:55 PM, Christopher Mettin >> > wrote: >> >> ARIN Community, >> >> The following message was sent recently to the ARIN mailing list by an >> Internet terrorist known as Joe Baptista. >> >> >OK - before someone end up donating addresses and gets involved in >> a fraud >> - I think it's time for a little >backgrounder on Christopher Mettin. >> > >> >http://bit.ly/87Yjir >> > >> >What Chris needs are a few blocks of /24 to setup a root system >> based on >> what I know of him. Thats what I think >he is going on about - that > they >> need fixed IP. About the only protocol widely used still requiring >> fixed IP >> >for the root cache. >> > >> >Be careful I have been unable to confirm what he is doing is even >> authorized by the school. If you feel so >inclined to provide /24 >> blocks to >> them - make sure a responsible adult from the school signs on the > dotted >> >line, takes responsibility and absolves you of any legal liability. >> > >> >I do however support his initial point. These are only numbers and >> ARIN >> RIPE APNIC et. al. are making a killing >for just providing a database >> function - the rest as far as I can see is mainly hype and make work >> projects. I >think thats been mentioned before. >> >> A few months ago my school has been attacked by this guy. He did > already >> make an entire company shut down. His best weapons are lies. >> >> All that started when he was fired by the Public Root in 2005. We >> have been >> assigned a domain by a company affiliated with the Public Root Ltd. >> and so >> we became a major target to him. He sends his emails from a domain >> publishing a website of a "PublicRoot Consortium" which does not >> exist. The >> contact address of this consortium is a private home in an Ontarian >> suburb. >> Sending emails using this domain he tries to make people believe he >> is an >> official employee of the Public Root. >> >> The IP addresses shall be in no way used with any root system. >> >> For further reference on Joe Baptista, see >> http://inaic.com/index.php?p=news-25-08-2008. >> >> Sincerely yours, >> Christopher Mettin >> Gymnasium Querfurt High School >> >> >> >> APPENDIX A: whois -h whois.inaic.net GQNET >> >> Corporate TLD (cTLD): .GQNET >> TLD Status: Active >> TLD Register Date: 13-05-2009 >> TLD Updated: 29-05-2009 >> TLD Expire Date: 13-05-2010 >> Preferred Domain Name Registry: GQnet ( http://gqbc-online.com ) >> >> TLD Registrant: >> Name: Christopher Mettin >> Company name: Gymnasium Querfurt High School >> Address: An der Geistpromenade 29 >> City: Quefurt >> State: >> Zip: 06268 >> Country: Germany >> Phone: +49.347.712.2226 >> Cell phone: >> Fax: +49.347.712.8826 >> Email: cmettin at gqbc-online.com >> >> TLD Administrative contact: >> Name: Christopher Mettin >> Company name: Gymnasium Querfurt High School >> Address: An der Geistpromenade 29 >> City: Quefurt >> State: >> Zip: 06268 >> Country: Germany >> Phone: +49.347.712.2226 >> Cell phone: >> Fax: +49.347.712.8826 >> Email: cmettin at gqbc-online.com >> >> TLD Technical contact: >> Name: Christopher Mettin >> Company name: Gymnasium Querfurt High School >> Address: An der Geistpromenade 29 >> City: Quefurt >> State: >> Zip: 06268 >> Country: Germany >> Phone: +49.347.712.2226 >> Cell phone: >> Fax: +49.347.712.8826 >> Email: cmettin at gqbc-online.com >> >> TLD Billing contact: >> Name: Christopher Mettin >> Company name: Gymnasium Querfurt High School >> Address: An der Geistpromenade 29 >> City: Quefurt >> State: >> Zip: 06268 >> Country: Germany >> Phone: +49.347.712.2226 >> Cell phone: >> Fax: +49.347.712.8826 >> Email: cmettin at gqbc-online.com >> >> TLD Servers: >> TLD Server1: tld1.public-root.net - >> IPV4: 84.22.100.6 >> TLD Server2: tld2.public-root.net - >> IPV4: 57.67.193.188 >> TLD Server3: tld3.public-root.net - >> IPV4: 199.5.156.122 >> >> By submitting a Global TLD WHOIS query you agree to use this data only >> for lawful purposes. Under no circumstances will you use this data to: >> (1) Allow, enable, or otherwise support the transmission of mass >> unsolicited, commercial advertising or solicitations via e-mail, >> telephone, or facsimile; or: (2) Enable high volume, automated, >> electronic processes against the INAIC or its data systems and networks. >> The compilation, repackaging, dissemination or other use of this data is >> expressly prohibited without the prior written consent of the INAIC. The >> INAIC reserves the right to revoke access to the Global TLD WHOIS >> Database in its sole discretion, including without limitation, for >> excessive querying of the Global TLD WHOIS Database or for failure to >> otherwise abide by this policy. >> >> TLD Registrants are responsible for the information maintained in the >> directory services database.The INAIC does not guarantee the accuracy of >> the information maintained in the Global TLD WHOIS Database. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From geneb at deltasoft.com Tue Dec 1 13:24:40 2009 From: geneb at deltasoft.com (Gene Buckle) Date: Tue, 1 Dec 2009 10:24:40 -0800 (PST) Subject: [arin-ppml] Apology requested from Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: <4B155B59.6070606@ipinc.net> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <4B155B59.6070606@ipinc.net> Message-ID: On Tue, 1 Dec 2009, Ted Mittelstaedt wrote: > Joe and Christopher, > > It was only fun to watch until you guys started breaking the furniture. > > Ted > Oh I don't know. This is the most entertaining nonsense I've seen in _ages_. All this needs is one or two old-time Net.Kooks to stick their oars in. *laughs* I have to admit though, "internet terrorist" is absurd in the extreme. :) g. From walter.keen at rainierconnect.net Tue Dec 1 13:23:39 2009 From: walter.keen at rainierconnect.net (Walter Keen) Date: Tue, 01 Dec 2009 10:23:39 -0800 Subject: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School In-Reply-To: References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <022d01ca72ad$c7b4bd20$3501a8c0@macc173.net> Message-ID: <4B155F2B.50104@rainierconnect.net> An HTML attachment was scrubbed... URL: From JBallerini at copsmonitoring.com Tue Dec 1 13:30:08 2009 From: JBallerini at copsmonitoring.com (John Ballerini) Date: Tue, 01 Dec 2009 13:30:08 -0500 Subject: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School In-Reply-To: References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <4B155B59.6070606@ipinc.net> Message-ID: <4B151A6002000093000180C5@copsmonitoring.com> lol...I needed some comic relief today....ARIN rules......I'm just a 2 plus year member with an ASN...but I monitor the ongoings for the relevant stuff...but this is almost as good as a pay-per-view show...lmao...go get 'em... >>> Gene Buckle 12/1/2009 1:24 PM >>> On Tue, 1 Dec 2009, Ted Mittelstaedt wrote: > Joe and Christopher, > > It was only fun to watch until you guys started breaking the furniture. > > Ted > Oh I don't know. This is the most entertaining nonsense I've seen in _ages_. All this needs is one or two old-time Net.Kooks to stick their oars in. *laughs* I have to admit though, "internet terrorist" is absurd in the extreme. :) g. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danny at tcb.net Tue Dec 1 13:33:07 2009 From: danny at tcb.net (Danny McPherson) Date: Tue, 1 Dec 2009 11:33:07 -0700 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B15453D.2070309@ipinc.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> Message-ID: <1BF286A2-3699-464B-AD26-35F7D3CBFD42@tcb.net> On Dec 1, 2009, at 9:33 AM, Ted Mittelstaedt wrote: > > I think it would be foolish to assume this. You bought into > this naieve notion that SWIP data is mainly of benefit to OTHER people, > promulgated by all the bonehead privacy-terrorists out there who think > that a SWIP filed on them will let the identity thieves steal > them blind. No, I'm assuming people are lazy. You seem to be more optimistic. It had nothing to do with identity thieves, the bar is much lower there.. > In reality, SWIPs aren't for the rest of the Internet, they help > make YOUR job easier. ... > So, for LIRS that want to pee all over themselves, well > then don't file SWIPS. In fact I ENCOURAGE IT STRONGLY because > then all I have to do is null-route your ENTIRE AS, I don't even > have to waste CPU cycles blocking just the obnoxious traffic > from Wonkulating. Right, you'll do this until someone that YOUR customers wants to reach is blocked, and then YOU will remove YOUR senseless null route... But that's a local policy decision, to each their own... > Probably because of the same reason that a cursory search > won't find any discussions about the pros and cons of > staring straight into the sun for an hour at high noon. I suspect I could find a discussion on that, actually.. At least part of your response was worth reading, -danny From cmettin at gqbc-online.com Tue Dec 1 13:30:41 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Tue, 1 Dec 2009 19:30:41 +0100 Subject: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <022d01ca72ad$c7b4bd20$3501a8c0@macc173.net> <4B155F2B.50104@rainierconnect.net> Message-ID: The actual domain of the Public Root is public-root.com. So they wouldn't need any publicroot.org. And considering that there is a difference between the Public Root (Ltd.) and PublicRoot Consortium, whatever a consortium is, and the fact that there are sold WHOIS information on there and the contact mail address shown on this website is a private home address, I would say that last one is a little basement project by Joe Baptista. This website says also that the Public Root was created in 2005 what is not true, it existed already in the 1990s and is working with INAIC since 2004. So the real domain public-root.com has been already registered for years before this faked site showed up on the web. From: Walter Keen [mailto:walter.keen at rainierconnect.net] Sent: Tuesday, December 01, 2009 7:24 PM To: Christopher Mettin Cc: 'Kyle Banks'; arin-ppml at arin.net Subject: Re: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School Not sure about other areas of the world, but in the US, it is quite common to: Have a consultant come in to do a assessment/design of an internal or public network, including registering domains, because the client simply doesn't understand or doesn't want to do it themselves. (Not sure if this is the case, as I don't really know much about public root at all) It's also quite common here for, when people (consultants or employees) walk out after uncovering illegal activities, for the company to consider them 'fired' under whatever policy they feel justified using. I can also speak from personal experience that almost all consultants I've dealt with get an internal email address, if nothing else for security reasons. Why send information to your consultant and have it go off to some other mail server when it may contain sensitive information. That's my .02 on the subject. I don't think there's really any proof of misrepresentation, from my point of view, all of it could be explained by typical consulting work and a disgruntled company. Now where's that ignore thread option...... Christopher Mettin wrote: >I do not feel that he misidentified himself, See point 2 of his request for an apology He was fired in 2005, whatever he worked as for INAIC. > There are, however, limitations on domains that used, or squatted on I.E. anycelebrityname.com usually can't > be acquired by just any user, without providing identification/ authorization to act on that celebrity's behalf. But anyone can register any domain. And according to the domain WHOIS, he registered the domain himself: Domain ID:D107958839-LROR Domain Name:PUBLICROOT.ORG Created On:25-Oct-2005 19:00:01 UTC Last Updated On:20-Oct-2009 01:50:41 UTC Expiration Date:25-Oct-2010 19:00:01 UTC Sponsoring Registrar:GoDaddy.com, Inc. (R91-LROR) Status:CLIENT DELETE PROHIBITED Status:CLIENT RENEW PROHIBITED Status:CLIENT TRANSFER PROHIBITED Status:CLIENT UPDATE PROHIBITED Registrant ID:GODA-014857820 Registrant Name:Joe Baptista Registrant Organization:The Public Root Consortium Registrant Street1:5921 Agean Drive Registrant Street2: Registrant Street3: Registrant City:Mississauga Registrant State/Province:Ontario Registrant Postal Code:L5M 6Y3 Registrant Country:CA Registrant Phone:+1.2025171593 Registrant Phone Ext.: Registrant FAX:+1.5094790084 Registrant FAX Ext.: Registrant Email:baptista at publicroot.org So if he was just a consultant, why does he own the domain of the company he worked for. That makes me believe he this is not the official domain of the Public Root. From: Kyle Banks [mailto:kbanks at giantcomm.net] Sent: Tuesday, December 01, 2009 6:43 PM To: 'Christopher Mettin'; 'Joe Baptista'; arin-ppml at arin.net Subject: RE: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School "the miss-identification as employee of the Public Root, a registered British company (see his email address for that)." I do not feel that he misidentified himself, See point 2 of his request for an apology 2) I was never an employee of the Public-Root. I was a consultant since 2003. And I was not fired. I walked out along with other consultants because of the criminal activity uncovered by me - being mainly the embezzlement of funds, money laundering and tax evasion by senior executive staff As for his E-mail address, being employed by an ISP that provides E-mail hosting, I know first hand that anyone, anywhere can request whatever username they would like for an E-mail address (providing the limitations of the policies set forth by the provider.) There are, however, limitations on domains that used, or squatted on I.E. anycelebrityname.com usually can't be acquired by just any user, without providing identification/ authorization to act on that celebrity's behalf. And in the words of Forest Gump "that's all I really got to say about that" K. Vincent Banks Service/Technical Representative Giant Communications 785-362-9331 EXT. 108 kbanks at giantcomm.net -- Blessed is he who expects nothing, for he shall never be disappointed--Benjamin Franklin _____ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Christopher Mettin Sent: Tuesday, December 01, 2009 11:28 AM To: 'Joe Baptista'; arin-ppml at arin.net Subject: Re: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School Everything I said about Joe Baptista entirely true and confirmed by evidences and statements by several other people. I hereby request to dismiss Joe Baptista from the ARIN mailing list for the falsification of documents and the miss-identification as employee of the Public Root, a registered British company (see his email address for that). We received a dozen emails a day in September from Joe Baptista, I see no point why this should not be called spamming. The clarify, we did not buy a TLD that we know won't ever be accessible by everyone (except all Internet users queried the Public Root for DNS resolution). The TLD was given to us for educational purposes and in return to open the TLD registration to other people on our site. Further, Public Root, as a British company, and INAIC, a New York-based company, exist and full-fill the service they offer. Their TLD and root services are widely known as alternative, even Wikipedia has a section about them on their alternative roots articles. So far this cannot be called a scam, rather Joe Baptista is the spam ignoring Canadian court orders. For all the times this global network shall exist, the World shall have knowledge about the activities of the Internet terrorist Joe Baptista. Sources: http://inaic.com/index.php?p=internet-terror http://whocalled.us/lookup/4169126551 From: publicroot.info at gmail.com [mailto:publicroot.info at gmail.com] On Behalf Of Joe Baptista Sent: Tuesday, December 01, 2009 6:04 PM To: Christopher Mettin Cc: arin-ppml at arin.net Subject: Apology requested from Christopher Mettin and the Gymnasium Querfurt High School Dear Christopher and ARIN community: I am requesting a public apology from you Christopher Mettin and your organization the Gymnasium Querfurt High School for calling me an Internet terrorist, a liar and other libelous, slanderous and defamatory statements made by you in a public forum against me. Also Christopher please do not jump the gun and make this decision on your own. Kindly consult your supervisor and principle with respect to my request and take the time to show them my request as well as the statements made by you on behalf of your school against me. For the record I will now respond to the allegations made against me by Mr. Mettin. 1) I am not an "Internet terrorist". This claim by Mr. Mettin below is not only false but seriously libelous, slanderous and defamatory. 2) I was never an employee of the Public-Root. I was a consultant since 2003. And I was not fired. I walked out along with other consultants because of the criminal activity uncovered by me - being mainly the embezzlement of funds, money laundering and tax evasion by senior executive staff. 3) I never attacked Christopher's Gymnasium Querfurt High School. This claim is also false, libelous, slanderous and defamatory. I did attempt to email senior staff and also called by phone but was unable to get in touch with anyone except Mr. Mettin. I therefore have no idea if school staff know what Mr. Mettin is up to as I have been unable to contact a responsible adult at the school. 4) Mr. Mettin's claims that the PublicRoot Consortium does not exist are false. The PublicRoot Consortium is organized as an unincorporated trust in Canada. 5) Mr. Mettin's claims below that his schools only involvement with the people who run the INAIC.com web site was to be "assigned a (top-level) domain by a company affiliated with the Public Root Ltd." is false. The top-level domain the Gymnasium Querfurt High School purchased from them is GQNET - a copy of the whois for this domain is attached at the end of this message as Appendix A. But as members here have pointed out Mr. Mettin's forgot to mention that the Gymnasium Querfurt High School also sells TLDs for these shell companies and non existent organizations. 6) Mr. Mettin's claims that my actions resulted in the shut down of a company are partially true. My actions resulted in the business failure of at least three companies and the investigation of a number of individuals for criminal acts being tax evasion and money laundering. Some individuals involved in these investigations have settled with the Dutch tax authorities. We also had the full support of the Turkish Government and SITA, as well as a number of other influential people, organization and countries. That support evaporated when I when public and blew the whistle. As a result of my actions fewer people ended up loosing their money in this scam which was my intention. 7) Mr. Mettin's claims that I lie are also false, libelous, slanderous and defamatory. regards joe baptista On Sat, Nov 28, 2009 at 8:55 PM, Christopher Mettin wrote: ARIN Community, The following message was sent recently to the ARIN mailing list by an Internet terrorist known as Joe Baptista. >OK - before someone end up donating addresses and gets involved in a fraud - I think it's time for a little >backgrounder on Christopher Mettin. > >http://bit.ly/87Yjir > >What Chris needs are a few blocks of /24 to setup a root system based on what I know of him. Thats what I think >he is going on about - that they need fixed IP. About the only protocol widely used still requiring fixed IP >for the root cache. > >Be careful I have been unable to confirm what he is doing is even authorized by the school. If you feel so >inclined to provide /24 blocks to them - make sure a responsible adult from the school signs on the dotted >line, takes responsibility and absolves you of any legal liability. > >I do however support his initial point. These are only numbers and ARIN RIPE APNIC et. al. are making a killing >for just providing a database function - the rest as far as I can see is mainly hype and make work projects. I >think thats been mentioned before. A few months ago my school has been attacked by this guy. He did already make an entire company shut down. His best weapons are lies. All that started when he was fired by the Public Root in 2005. We have been assigned a domain by a company affiliated with the Public Root Ltd. and so we became a major target to him. He sends his emails from a domain publishing a website of a "PublicRoot Consortium" which does not exist. The contact address of this consortium is a private home in an Ontarian suburb. Sending emails using this domain he tries to make people believe he is an official employee of the Public Root. The IP addresses shall be in no way used with any root system. For further reference on Joe Baptista, see http://inaic.com/index.php?p=news-25-08-2008. Sincerely yours, Christopher Mettin Gymnasium Querfurt High School APPENDIX A: whois -h whois.inaic.net GQNET Corporate TLD (cTLD): .GQNET TLD Status: Active TLD Register Date: 13-05-2009 TLD Updated: 29-05-2009 TLD Expire Date: 13-05-2010 Preferred Domain Name Registry: GQnet ( http://gqbc-online.com ) TLD Registrant: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Administrative contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Technical contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Billing contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Servers: TLD Server1: tld1.public-root.net - IPV4: 84.22.100.6 TLD Server2: tld2.public-root.net - IPV4: 57.67.193.188 TLD Server3: tld3.public-root.net - IPV4: 199.5.156.122 By submitting a Global TLD WHOIS query you agree to use this data only for lawful purposes. Under no circumstances will you use this data to: (1) Allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail, telephone, or facsimile; or: (2) Enable high volume, automated, electronic processes against the INAIC or its data systems and networks. The compilation, repackaging, dissemination or other use of this data is expressly prohibited without the prior written consent of the INAIC. The INAIC reserves the right to revoke access to the Global TLD WHOIS Database in its sole discretion, including without limitation, for excessive querying of the Global TLD WHOIS Database or for failure to otherwise abide by this policy. TLD Registrants are responsible for the information maintained in the directory services database.The INAIC does not guarantee the accuracy of the information maintained in the Global TLD WHOIS Database. _____ _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- Walter Keen Network Technician Rainier Connect (o) 360-832-4024 (c) 253-302-0194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cengel at sponsordirect.com Tue Dec 1 13:34:01 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Tue, 1 Dec 2009 13:34:01 -0500 Subject: [arin-ppml] Continuation: Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations In-Reply-To: Message-ID: Christopher, As has already been pointed out by others on the list, even were you to obtain an IP address range from ARIN or some other entity it would do you no good without the cooperation of your local ISP. Your ISP would need to route/advertise that IP address in order for you to have any connectivity to it. IF your project is legitimate and you are unable for whatever reason to get a static IP address assignment from your ISP might I suggest a simpler solution for your project might be to get authorization of funds from your school-board (or community organization) to rent a Virtual Private Server at a reputable hosting company (you may even find one willing to provide a discount for educational institutions) and use that as a point of connection. You could then install VPN software on that hosted server that supports PPTP connections and use private address space over those tunnels for connectivity with your peer classrooms. You may run into some complications with FW's or conflicting private address space that you have to work out but it'll probably be an easier route for you. Christopher Engel From kbanks at giantcomm.net Tue Dec 1 13:39:17 2009 From: kbanks at giantcomm.net (Kyle Banks) Date: Tue, 1 Dec 2009 12:39:17 -0600 Subject: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School In-Reply-To: References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <022d01ca72ad$c7b4bd20$3501a8c0@macc173.net> Message-ID: <024f01ca72b5$96e6de00$3501a8c0@macc173.net> Anyone can register Domains to a certain extent.I have several customers, who have the company I work for to handle the domain registration portion of their website. But not the hosting. Sometimes saves some confusion, sometimes strictly because they're lazy. 9 times out of 10 I register the domain to the company I work for, but every now and then I'll slip up while going through the motions and put my contact information on the whois information. As far as his name being on the who is, Looking at it, its showing to expire next year and not allow renewal or transfer, so I believe the registrant has caught their error in allowing this registration and corrected it. As far as the username in his Email account about anyone can set up a Gmail account for instance "info.gqbc.online" is currently available to be used through Gmail (by no means am I going to use this email address, or instructing anyone to do likewise, in an attempt to falsify their identity or affiliation with gqbc-online) just simply showing that with the lax policies used by many email providers namely the larger ones I.E. Gmail, Hotmail, Yahoo, ETC. it is rather simple for someone to establish an Email address that could be seen as an affiliate to an entirely separate organization. Hence the reason, Our company requires official emails not be sent from any "Free Email Provider" Again.. Just my .02 K. Vincent Banks Service/Technical Representative Giant Communications 785-362-9331 EXT. 108 kbanks at giantcomm.net -- Blessed is he who expects nothing, for he shall never be disappointed--Benjamin Franklin _____ From: Christopher Mettin [mailto:cmettin at gqbc-online.com] Sent: Tuesday, December 01, 2009 12:11 PM To: 'Kyle Banks'; arin-ppml at arin.net Subject: RE: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School >I do not feel that he misidentified himself, See point 2 of his request for an apology He was fired in 2005, whatever he worked as for INAIC. > There are, however, limitations on domains that used, or squatted on I.E. anycelebrityname.com usually can't > be acquired by just any user, without providing identification/ authorization to act on that celebrity's behalf. But anyone can register any domain. And according to the domain WHOIS, he registered the domain himself: Domain ID:D107958839-LROR Domain Name:PUBLICROOT.ORG Created On:25-Oct-2005 19:00:01 UTC Last Updated On:20-Oct-2009 01:50:41 UTC Expiration Date:25-Oct-2010 19:00:01 UTC Sponsoring Registrar:GoDaddy.com, Inc. (R91-LROR) Status:CLIENT DELETE PROHIBITED Status:CLIENT RENEW PROHIBITED Status:CLIENT TRANSFER PROHIBITED Status:CLIENT UPDATE PROHIBITED Registrant ID:GODA-014857820 Registrant Name:Joe Baptista Registrant Organization:The Public Root Consortium Registrant Street1:5921 Agean Drive Registrant Street2: Registrant Street3: Registrant City:Mississauga Registrant State/Province:Ontario Registrant Postal Code:L5M 6Y3 Registrant Country:CA Registrant Phone:+1.2025171593 Registrant Phone Ext.: Registrant FAX:+1.5094790084 Registrant FAX Ext.: Registrant Email:baptista at publicroot.org So if he was just a consultant, why does he own the domain of the company he worked for. That makes me believe he this is not the official domain of the Public Root. From: Kyle Banks [mailto:kbanks at giantcomm.net] Sent: Tuesday, December 01, 2009 6:43 PM To: 'Christopher Mettin'; 'Joe Baptista'; arin-ppml at arin.net Subject: RE: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School "the miss-identification as employee of the Public Root, a registered British company (see his email address for that)." I do not feel that he misidentified himself, See point 2 of his request for an apology 2) I was never an employee of the Public-Root. I was a consultant since 2003. And I was not fired. I walked out along with other consultants because of the criminal activity uncovered by me - being mainly the embezzlement of funds, money laundering and tax evasion by senior executive staff As for his E-mail address, being employed by an ISP that provides E-mail hosting, I know first hand that anyone, anywhere can request whatever username they would like for an E-mail address (providing the limitations of the policies set forth by the provider.) There are, however, limitations on domains that used, or squatted on I.E. anycelebrityname.com usually can't be acquired by just any user, without providing identification/ authorization to act on that celebrity's behalf. And in the words of Forest Gump "that's all I really got to say about that" K. Vincent Banks Service/Technical Representative Giant Communications 785-362-9331 EXT. 108 kbanks at giantcomm.net -- Blessed is he who expects nothing, for he shall never be disappointed--Benjamin Franklin _____ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Christopher Mettin Sent: Tuesday, December 01, 2009 11:28 AM To: 'Joe Baptista'; arin-ppml at arin.net Subject: Re: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School Everything I said about Joe Baptista entirely true and confirmed by evidences and statements by several other people. I hereby request to dismiss Joe Baptista from the ARIN mailing list for the falsification of documents and the miss-identification as employee of the Public Root, a registered British company (see his email address for that). We received a dozen emails a day in September from Joe Baptista, I see no point why this should not be called spamming. The clarify, we did not buy a TLD that we know won't ever be accessible by everyone (except all Internet users queried the Public Root for DNS resolution). The TLD was given to us for educational purposes and in return to open the TLD registration to other people on our site. Further, Public Root, as a British company, and INAIC, a New York-based company, exist and full-fill the service they offer. Their TLD and root services are widely known as alternative, even Wikipedia has a section about them on their alternative roots articles. So far this cannot be called a scam, rather Joe Baptista is the spam ignoring Canadian court orders. For all the times this global network shall exist, the World shall have knowledge about the activities of the Internet terrorist Joe Baptista. Sources: http://inaic.com/index.php?p=internet-terror http://whocalled.us/lookup/4169126551 From: publicroot.info at gmail.com [mailto:publicroot.info at gmail.com] On Behalf Of Joe Baptista Sent: Tuesday, December 01, 2009 6:04 PM To: Christopher Mettin Cc: arin-ppml at arin.net Subject: Apology requested from Christopher Mettin and the Gymnasium Querfurt High School Dear Christopher and ARIN community: I am requesting a public apology from you Christopher Mettin and your organization the Gymnasium Querfurt High School for calling me an Internet terrorist, a liar and other libelous, slanderous and defamatory statements made by you in a public forum against me. Also Christopher please do not jump the gun and make this decision on your own. Kindly consult your supervisor and principle with respect to my request and take the time to show them my request as well as the statements made by you on behalf of your school against me. For the record I will now respond to the allegations made against me by Mr. Mettin. 1) I am not an "Internet terrorist". This claim by Mr. Mettin below is not only false but seriously libelous, slanderous and defamatory. 2) I was never an employee of the Public-Root. I was a consultant since 2003. And I was not fired. I walked out along with other consultants because of the criminal activity uncovered by me - being mainly the embezzlement of funds, money laundering and tax evasion by senior executive staff. 3) I never attacked Christopher's Gymnasium Querfurt High School. This claim is also false, libelous, slanderous and defamatory. I did attempt to email senior staff and also called by phone but was unable to get in touch with anyone except Mr. Mettin. I therefore have no idea if school staff know what Mr. Mettin is up to as I have been unable to contact a responsible adult at the school. 4) Mr. Mettin's claims that the PublicRoot Consortium does not exist are false. The PublicRoot Consortium is organized as an unincorporated trust in Canada. 5) Mr. Mettin's claims below that his schools only involvement with the people who run the INAIC.com web site was to be "assigned a (top-level) domain by a company affiliated with the Public Root Ltd." is false. The top-level domain the Gymnasium Querfurt High School purchased from them is GQNET - a copy of the whois for this domain is attached at the end of this message as Appendix A. But as members here have pointed out Mr. Mettin's forgot to mention that the Gymnasium Querfurt High School also sells TLDs for these shell companies and non existent organizations. 6) Mr. Mettin's claims that my actions resulted in the shut down of a company are partially true. My actions resulted in the business failure of at least three companies and the investigation of a number of individuals for criminal acts being tax evasion and money laundering. Some individuals involved in these investigations have settled with the Dutch tax authorities. We also had the full support of the Turkish Government and SITA, as well as a number of other influential people, organization and countries. That support evaporated when I when public and blew the whistle. As a result of my actions fewer people ended up loosing their money in this scam which was my intention. 7) Mr. Mettin's claims that I lie are also false, libelous, slanderous and defamatory. regards joe baptista On Sat, Nov 28, 2009 at 8:55 PM, Christopher Mettin wrote: ARIN Community, The following message was sent recently to the ARIN mailing list by an Internet terrorist known as Joe Baptista. >OK - before someone end up donating addresses and gets involved in a fraud - I think it's time for a little >backgrounder on Christopher Mettin. > >http://bit.ly/87Yjir > >What Chris needs are a few blocks of /24 to setup a root system based on what I know of him. Thats what I think >he is going on about - that they need fixed IP. About the only protocol widely used still requiring fixed IP >for the root cache. > >Be careful I have been unable to confirm what he is doing is even authorized by the school. If you feel so >inclined to provide /24 blocks to them - make sure a responsible adult from the school signs on the dotted >line, takes responsibility and absolves you of any legal liability. > >I do however support his initial point. These are only numbers and ARIN RIPE APNIC et. al. are making a killing >for just providing a database function - the rest as far as I can see is mainly hype and make work projects. I >think thats been mentioned before. A few months ago my school has been attacked by this guy. He did already make an entire company shut down. His best weapons are lies. All that started when he was fired by the Public Root in 2005. We have been assigned a domain by a company affiliated with the Public Root Ltd. and so we became a major target to him. He sends his emails from a domain publishing a website of a "PublicRoot Consortium" which does not exist. The contact address of this consortium is a private home in an Ontarian suburb. Sending emails using this domain he tries to make people believe he is an official employee of the Public Root. The IP addresses shall be in no way used with any root system. For further reference on Joe Baptista, see http://inaic.com/index.php?p=news-25-08-2008. Sincerely yours, Christopher Mettin Gymnasium Querfurt High School APPENDIX A: whois -h whois.inaic.net GQNET Corporate TLD (cTLD): .GQNET TLD Status: Active TLD Register Date: 13-05-2009 TLD Updated: 29-05-2009 TLD Expire Date: 13-05-2010 Preferred Domain Name Registry: GQnet ( http://gqbc-online.com ) TLD Registrant: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Administrative contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Technical contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Billing contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Servers: TLD Server1: tld1.public-root.net - IPV4: 84.22.100.6 TLD Server2: tld2.public-root.net - IPV4: 57.67.193.188 TLD Server3: tld3.public-root.net - IPV4: 199.5.156.122 By submitting a Global TLD WHOIS query you agree to use this data only for lawful purposes. Under no circumstances will you use this data to: (1) Allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail, telephone, or facsimile; or: (2) Enable high volume, automated, electronic processes against the INAIC or its data systems and networks. The compilation, repackaging, dissemination or other use of this data is expressly prohibited without the prior written consent of the INAIC. The INAIC reserves the right to revoke access to the Global TLD WHOIS Database in its sole discretion, including without limitation, for excessive querying of the Global TLD WHOIS Database or for failure to otherwise abide by this policy. TLD Registrants are responsible for the information maintained in the directory services database.The INAIC does not guarantee the accuracy of the information maintained in the Global TLD WHOIS Database. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danny at tcb.net Tue Dec 1 13:40:37 2009 From: danny at tcb.net (Danny McPherson) Date: Tue, 1 Dec 2009 11:40:37 -0700 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <29173.1259635466@marajade.sandelman.ca> References: <5AB64AFF-C7E9-4699-A45B-F0561EB4B192@tcb.net> <29173.1259635466@marajade.sandelman.ca> Message-ID: <4B9DD941-7F18-458E-BA50-849701887D2E@tcb.net> On Nov 30, 2009, at 7:44 PM, Michael Richardson wrote: > > Uhm, I guess I really disagree. > Maybe to operators that do not take support calls (in particular support > calls from other ISPs), then the "primary driver for SWIPs today is to > enable justification of additional addresses". > > But, to the rest of us, SWIP data is not just "clearly invaluable", it's > critical to all manner of internal and external support, both for > enterprises (me), and ISPs (sometimes me). > > But, certainly if it's the case that updating SWIP data is just a chore > necessary to get more address space, that certainly explains why some > ISPs (near me) have little interest in keeping it update, or in doing > proper reverse DNS. Yep, your points above make good sense. I mostly agree with your later examples as well.. Thanks for he feedback -danny From baptista at publicroot.org Tue Dec 1 13:42:50 2009 From: baptista at publicroot.org (Joe Baptista) Date: Tue, 1 Dec 2009 13:42:50 -0500 Subject: [arin-ppml] Apology requested from Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> Message-ID: <874c02a20912011042r5ef66066jbdaa18dbd7ab3b6d@mail.gmail.com> Once again I am forced to respond to allegations against me by Christopher Mettin a representative of the Gymnasium Querfurt High School. On Tue, Dec 1, 2009 at 12:28 PM, Christopher Mettin wrote: > Everything I said about Joe Baptista entirely true and confirmed by > evidences and statements by several other people. > Produce those statement and evidence and evidence you claim to have. > I hereby request to dismiss Joe Baptista from the ARIN mailing list for the > falsification of documents and the miss-identification as employee of the > Public Root, a registered British company (see his email address for that). > There has been no document falsification by me nor have I ever claimed to be an employee of the Public Root. The claim I was an employee of the alleged British company was made by Mr. Mettin and not myself. Mr. Mettin has claimed I falsified documents. This is a most serious claim which is of course false, libelous, scandalous and defamatory. Mr. Mettin kindly produce these documents you claim are false. Furthermore the British company Mr. Mettin refers to above no longer exists. It's registration was revoked by the Companies House registrar in England. We received a dozen emails a day in September from Joe Baptista, I see no > point why this should not be called spamming. > This is also a false claim by Mr. Mettin. I never sent dozens of emails a day in September. Maybe at most 10 to 15 messages in total all of which were correspondence with Mr. Mettin in which he was responding to my emails. If Mr. Mettin wishes to challenge this I can produce all the emails I sent and received. > > > The clarify, we did not buy a TLD that we know won?t ever be accessible by > everyone (except all Internet users queried the Public Root for DNS > resolution). The TLD was given to us for educational purposes and in return > to open the TLD registration to other people on our site. > That is exactly what I said - with the exception that I was under the impression you had purchased it. I did not know you were "given" the domain for education purposes. Non the less you are a TLD reseller as I and others here have accurately pointed out and you have already confirmed. > > > Further, Public Root, as a British company, and INAIC, a New York-based > company, exist and full-fill the service they offer. > They don't exist. This is another false claim. Nor is INAIC a New York based company. As per my prior post the INAIC organization is incorporated in the Netherlands and as their Chief Executive Officer Mr. Martijn Burger has confirmed in writing the INAIC organization has no association with the INAIC.com websites. which see reference: http://bit.ly/61Anot Furthermore the only association INAIC has with New York is a false postal address at the Rockefeller Center given on their contact page at: http://inaic.com/index.php?p=contact Anyone wishing to confirm this may send some old fashioned snail mail to the address and I guarantee it will be returned back to you as undeliverable. And as mentioned above the Public Root registration in England was revoked by the British government. So non of these companies are operation - at least in the legal or commercial sense. Their TLD and root services are widely known as alternative, even Wikipedia > has a section about them on their alternative roots articles. So far this > cannot be called a scam, rather Joe Baptista is the spam ignoring Canadian > court orders. > Again a very false, libelous, slanderous and defamatory claim. There is no Canadian court order against me that I have ignored. > > > For all the times this global network shall exist, the World shall have > knowledge about the activities of the Internet terrorist Joe Baptista. > In other words Christopher you'll continue to repeat the libel and slander they have made against me. No need for further reply from me and I consider this matter here closed. My apologies to the members here for all the unnecessary OT. regards joe baptista > > > Sources: http://inaic.com/index.php?p=internet-terror > > http://whocalled.us/lookup/4169126551 > > > > > > *From:* publicroot.info at gmail.com [mailto:publicroot.info at gmail.com] *On > Behalf Of *Joe Baptista > *Sent:* Tuesday, December 01, 2009 6:04 PM > > *To:* Christopher Mettin > *Cc:* arin-ppml at arin.net > *Subject:* Apology requested from Christopher Mettin and the Gymnasium > Querfurt High School > > > > > Dear Christopher and ARIN community: > > I am requesting a public apology from you Christopher Mettin and your > organization the Gymnasium Querfurt High School for calling me an Internet > terrorist, a liar and other libelous, slanderous and defamatory statements > made by you in a public forum against me. > > Also Christopher please do not jump the gun and make this decision on your > own. Kindly consult your supervisor and principle with respect to my request > and take the time to show them my request as well as the statements made by > you on behalf of your school against me. > > For the record I will now respond to the allegations made against me by Mr. > Mettin. > > 1) I am not an "Internet terrorist". This claim by Mr. Mettin below is not > only false but seriously libelous, slanderous and defamatory. > > 2) I was never an employee of the Public-Root. I was a consultant since > 2003. And I was not fired. I walked out along with other consultants because > of the criminal activity uncovered by me - being mainly the embezzlement of > funds, money laundering and tax evasion by senior executive staff. > > 3) I never attacked Christopher's Gymnasium Querfurt High School. This > claim is also false, libelous, slanderous and defamatory. I did attempt to > email senior staff and also called by phone but was unable to get in touch > with anyone except Mr. Mettin. I therefore have no idea if school staff know > what Mr. Mettin is up to as I have been unable to contact a responsible > adult at the school. > > 4) Mr. Mettin's claims that the PublicRoot Consortium does not exist are > false. The PublicRoot Consortium is organized as an unincorporated trust in > Canada. > > 5) Mr. Mettin's claims below that his schools only involvement with the > people who run the INAIC.com web site was to be "assigned a (top-level) > domain by a company affiliated with the Public Root Ltd." is false. The > top-level domain the Gymnasium Querfurt High School purchased from them is > GQNET - a copy of the whois for this domain is attached at the end of this > message as Appendix A. > > But as members here have pointed out Mr. Mettin's forgot to mention that > the Gymnasium Querfurt High School also sells TLDs for these shell companies > and non existent organizations. > > 6) Mr. Mettin's claims that my actions resulted in the shut down of a > company are partially true. My actions resulted in the business failure of > at least three companies and the investigation of a number of individuals > for criminal acts being tax evasion and money laundering. Some individuals > involved in these investigations have settled with the Dutch tax > authorities. > > We also had the full support of the Turkish Government and SITA, as well as > a number of other influential people, organization and countries. That > support evaporated when I when public and blew the whistle. > > As a result of my actions fewer people ended up loosing their money in this > scam which was my intention. > > 7) Mr. Mettin's claims that I lie are also false, libelous, slanderous and > defamatory. > > regards > joe baptista > > On Sat, Nov 28, 2009 at 8:55 PM, Christopher Mettin < > cmettin at gqbc-online.com> wrote: > > ARIN Community, > > The following message was sent recently to the ARIN mailing list by an > Internet terrorist known as Joe Baptista. > > >OK - before someone end up donating addresses and gets involved in a fraud > - I think it's time for a little >backgrounder on Christopher Mettin. > > > >http://bit.ly/87Yjir > > > >What Chris needs are a few blocks of /24 to setup a root system based on > what I know of him. Thats what I think >he is going on about - that they > need fixed IP. About the only protocol widely used still requiring fixed IP > >for the root cache. > > > >Be careful I have been unable to confirm what he is doing is even > authorized by the school. If you feel so >inclined to provide /24 blocks to > them - make sure a responsible adult from the school signs on the dotted > >line, takes responsibility and absolves you of any legal liability. > > > >I do however support his initial point. These are only numbers and ARIN > RIPE APNIC et. al. are making a killing >for just providing a database > function - the rest as far as I can see is mainly hype and make work > projects. I >think thats been mentioned before. > > A few months ago my school has been attacked by this guy. He did already > make an entire company shut down. His best weapons are lies. > > All that started when he was fired by the Public Root in 2005. We have been > assigned a domain by a company affiliated with the Public Root Ltd. and so > we became a major target to him. He sends his emails from a domain > publishing a website of a "PublicRoot Consortium" which does not exist. The > contact address of this consortium is a private home in an Ontarian suburb. > Sending emails using this domain he tries to make people believe he is an > official employee of the Public Root. > > The IP addresses shall be in no way used with any root system. > > For further reference on Joe Baptista, see > http://inaic.com/index.php?p=news-25-08-2008. > > Sincerely yours, > > Christopher Mettin > Gymnasium Querfurt High School > > > > > > > APPENDIX A: whois -h whois.inaic.net GQNET > > Corporate TLD (cTLD): .GQNET > TLD Status: Active > TLD Register Date: 13-05-2009 > TLD Updated: 29-05-2009 > TLD Expire Date: 13-05-2010 > Preferred Domain Name Registry: GQnet ( http://gqbc-online.com ) > > TLD Registrant: > Name: Christopher Mettin > Company name: Gymnasium Querfurt High School > Address: An der Geistpromenade 29 > City: Quefurt > State: > Zip: 06268 > Country: Germany > Phone: +49.347.712.2226 > Cell phone: > Fax: +49.347.712.8826 > Email: cmettin at gqbc-online.com > > TLD Administrative contact: > Name: Christopher Mettin > Company name: Gymnasium Querfurt High School > Address: An der Geistpromenade 29 > City: Quefurt > State: > Zip: 06268 > Country: Germany > Phone: +49.347.712.2226 > Cell phone: > Fax: +49.347.712.8826 > Email: cmettin at gqbc-online.com > > TLD Technical contact: > Name: Christopher Mettin > Company name: Gymnasium Querfurt High School > Address: An der Geistpromenade 29 > City: Quefurt > State: > Zip: 06268 > Country: Germany > Phone: +49.347.712.2226 > Cell phone: > Fax: +49.347.712.8826 > Email: cmettin at gqbc-online.com > > TLD Billing contact: > Name: Christopher Mettin > Company name: Gymnasium Querfurt High School > Address: An der Geistpromenade 29 > City: Quefurt > State: > Zip: 06268 > Country: Germany > Phone: +49.347.712.2226 > Cell phone: > Fax: +49.347.712.8826 > Email: cmettin at gqbc-online.com > > TLD Servers: > TLD Server1: tld1.public-root.net - IPV4: 84.22.100.6 > TLD Server2: tld2.public-root.net - IPV4: 57.67.193.188 > TLD Server3: tld3.public-root.net - IPV4: 199.5.156.122 > > By submitting a Global TLD WHOIS query you agree to use this data only for > lawful purposes. Under no circumstances will you use this data to: (1) > Allow, enable, or otherwise support the transmission of mass unsolicited, > commercial advertising or solicitations via e-mail, telephone, or facsimile; > or: (2) Enable high volume, automated, electronic processes against the > INAIC or its data systems and networks. The compilation, repackaging, > dissemination or other use of this data is expressly prohibited without the > prior written consent of the INAIC. The INAIC reserves the right to revoke > access to the Global TLD WHOIS Database in its sole discretion, including > without limitation, for excessive querying of the Global TLD WHOIS Database > or for failure to otherwise abide by this policy. > > TLD Registrants are responsible for the information maintained in the > directory services database.The INAIC does not guarantee the accuracy of the > information maintained in the Global TLD WHOIS Database. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel at arneill-py.sacramento.ca.us Tue Dec 1 13:30:36 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 1 Dec 2009 10:30:36 -0800 Subject: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School In-Reply-To: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> Message-ID: <4C1746A1D20C3148B6434776DFFF06C5055742@newserver.arneill-py.local> Dear Joe, I'm looking for a little extra cash and I was wondering if there is a bounty on your head ;-) Come on, no real terrorist can be without a sizeable bounty. Seriously now, you should not be feeding the troll. You know better than this. Someone from, arin-ppml please ban cmettin at gqbc-online.com from the mailing list? There is such thing as troll management; it's been entertaining but as most of us I am busy and if I start ignoring every troll in the world I won't have time to do anything else. Michel. From kbanks at giantcomm.net Tue Dec 1 13:43:30 2009 From: kbanks at giantcomm.net (Kyle Banks) Date: Tue, 1 Dec 2009 12:43:30 -0600 Subject: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School In-Reply-To: References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <022d01ca72ad$c7b4bd20$3501a8c0@macc173.net> <4B155F2B.50104@rainierconnect.net> Message-ID: <025a01ca72b6$2e6b2ab0$3501a8c0@macc173.net> FYI on Consortium (WIKI) A consortium is an association of two or more individuals, companies, organizations or governments (or any combination of these entities) with the objective of participating in a common activity or pooling their resources for achieving a common goal. K. Vincent Banks Service/Technical Representative Giant Communications 785-362-9331 EXT. 108 kbanks at giantcomm.net -- Blessed is he who expects nothing, for he shall never be disappointed--Benjamin Franklin _____ From: Christopher Mettin [mailto:cmettin at gqbc-online.com] Sent: Tuesday, December 01, 2009 12:31 PM To: arin-ppml at arin.net; kbanks at giantcomm.net Subject: RE: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School The actual domain of the Public Root is public-root.com. So they wouldn't need any publicroot.org. And considering that there is a difference between the Public Root (Ltd.) and PublicRoot Consortium, whatever a consortium is, and the fact that there are sold WHOIS information on there and the contact mail address shown on this website is a private home address, I would say that last one is a little basement project by Joe Baptista. This website says also that the Public Root was created in 2005 what is not true, it existed already in the 1990s and is working with INAIC since 2004. So the real domain public-root.com has been already registered for years before this faked site showed up on the web. From: Walter Keen [mailto:walter.keen at rainierconnect.net] Sent: Tuesday, December 01, 2009 7:24 PM To: Christopher Mettin Cc: 'Kyle Banks'; arin-ppml at arin.net Subject: Re: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School Not sure about other areas of the world, but in the US, it is quite common to: Have a consultant come in to do a assessment/design of an internal or public network, including registering domains, because the client simply doesn't understand or doesn't want to do it themselves. (Not sure if this is the case, as I don't really know much about public root at all) It's also quite common here for, when people (consultants or employees) walk out after uncovering illegal activities, for the company to consider them 'fired' under whatever policy they feel justified using. I can also speak from personal experience that almost all consultants I've dealt with get an internal email address, if nothing else for security reasons. Why send information to your consultant and have it go off to some other mail server when it may contain sensitive information. That's my .02 on the subject. I don't think there's really any proof of misrepresentation, from my point of view, all of it could be explained by typical consulting work and a disgruntled company. Now where's that ignore thread option...... Christopher Mettin wrote: >I do not feel that he misidentified himself, See point 2 of his request for an apology He was fired in 2005, whatever he worked as for INAIC. > There are, however, limitations on domains that used, or squatted on I.E. anycelebrityname.com usually can't > be acquired by just any user, without providing identification/ authorization to act on that celebrity's behalf. But anyone can register any domain. And according to the domain WHOIS, he registered the domain himself: Domain ID:D107958839-LROR Domain Name:PUBLICROOT.ORG Created On:25-Oct-2005 19:00:01 UTC Last Updated On:20-Oct-2009 01:50:41 UTC Expiration Date:25-Oct-2010 19:00:01 UTC Sponsoring Registrar:GoDaddy.com, Inc. (R91-LROR) Status:CLIENT DELETE PROHIBITED Status:CLIENT RENEW PROHIBITED Status:CLIENT TRANSFER PROHIBITED Status:CLIENT UPDATE PROHIBITED Registrant ID:GODA-014857820 Registrant Name:Joe Baptista Registrant Organization:The Public Root Consortium Registrant Street1:5921 Agean Drive Registrant Street2: Registrant Street3: Registrant City:Mississauga Registrant State/Province:Ontario Registrant Postal Code:L5M 6Y3 Registrant Country:CA Registrant Phone:+1.2025171593 Registrant Phone Ext.: Registrant FAX:+1.5094790084 Registrant FAX Ext.: Registrant Email:baptista at publicroot.org So if he was just a consultant, why does he own the domain of the company he worked for. That makes me believe he this is not the official domain of the Public Root. From: Kyle Banks [mailto:kbanks at giantcomm.net] Sent: Tuesday, December 01, 2009 6:43 PM To: 'Christopher Mettin'; 'Joe Baptista'; arin-ppml at arin.net Subject: RE: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School "the miss-identification as employee of the Public Root, a registered British company (see his email address for that)." I do not feel that he misidentified himself, See point 2 of his request for an apology 2) I was never an employee of the Public-Root. I was a consultant since 2003. And I was not fired. I walked out along with other consultants because of the criminal activity uncovered by me - being mainly the embezzlement of funds, money laundering and tax evasion by senior executive staff As for his E-mail address, being employed by an ISP that provides E-mail hosting, I know first hand that anyone, anywhere can request whatever username they would like for an E-mail address (providing the limitations of the policies set forth by the provider.) There are, however, limitations on domains that used, or squatted on I.E. anycelebrityname.com usually can't be acquired by just any user, without providing identification/ authorization to act on that celebrity's behalf. And in the words of Forest Gump "that's all I really got to say about that" K. Vincent Banks Service/Technical Representative Giant Communications 785-362-9331 EXT. 108 kbanks at giantcomm.net -- Blessed is he who expects nothing, for he shall never be disappointed--Benjamin Franklin _____ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Christopher Mettin Sent: Tuesday, December 01, 2009 11:28 AM To: 'Joe Baptista'; arin-ppml at arin.net Subject: Re: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School Everything I said about Joe Baptista entirely true and confirmed by evidences and statements by several other people. I hereby request to dismiss Joe Baptista from the ARIN mailing list for the falsification of documents and the miss-identification as employee of the Public Root, a registered British company (see his email address for that). We received a dozen emails a day in September from Joe Baptista, I see no point why this should not be called spamming. The clarify, we did not buy a TLD that we know won't ever be accessible by everyone (except all Internet users queried the Public Root for DNS resolution). The TLD was given to us for educational purposes and in return to open the TLD registration to other people on our site. Further, Public Root, as a British company, and INAIC, a New York-based company, exist and full-fill the service they offer. Their TLD and root services are widely known as alternative, even Wikipedia has a section about them on their alternative roots articles. So far this cannot be called a scam, rather Joe Baptista is the spam ignoring Canadian court orders. For all the times this global network shall exist, the World shall have knowledge about the activities of the Internet terrorist Joe Baptista. Sources: http://inaic.com/index.php?p=internet-terror http://whocalled.us/lookup/4169126551 From: publicroot.info at gmail.com [mailto:publicroot.info at gmail.com] On Behalf Of Joe Baptista Sent: Tuesday, December 01, 2009 6:04 PM To: Christopher Mettin Cc: arin-ppml at arin.net Subject: Apology requested from Christopher Mettin and the Gymnasium Querfurt High School Dear Christopher and ARIN community: I am requesting a public apology from you Christopher Mettin and your organization the Gymnasium Querfurt High School for calling me an Internet terrorist, a liar and other libelous, slanderous and defamatory statements made by you in a public forum against me. Also Christopher please do not jump the gun and make this decision on your own. Kindly consult your supervisor and principle with respect to my request and take the time to show them my request as well as the statements made by you on behalf of your school against me. For the record I will now respond to the allegations made against me by Mr. Mettin. 1) I am not an "Internet terrorist". This claim by Mr. Mettin below is not only false but seriously libelous, slanderous and defamatory. 2) I was never an employee of the Public-Root. I was a consultant since 2003. And I was not fired. I walked out along with other consultants because of the criminal activity uncovered by me - being mainly the embezzlement of funds, money laundering and tax evasion by senior executive staff. 3) I never attacked Christopher's Gymnasium Querfurt High School. This claim is also false, libelous, slanderous and defamatory. I did attempt to email senior staff and also called by phone but was unable to get in touch with anyone except Mr. Mettin. I therefore have no idea if school staff know what Mr. Mettin is up to as I have been unable to contact a responsible adult at the school. 4) Mr. Mettin's claims that the PublicRoot Consortium does not exist are false. The PublicRoot Consortium is organized as an unincorporated trust in Canada. 5) Mr. Mettin's claims below that his schools only involvement with the people who run the INAIC.com web site was to be "assigned a (top-level) domain by a company affiliated with the Public Root Ltd." is false. The top-level domain the Gymnasium Querfurt High School purchased from them is GQNET - a copy of the whois for this domain is attached at the end of this message as Appendix A. But as members here have pointed out Mr. Mettin's forgot to mention that the Gymnasium Querfurt High School also sells TLDs for these shell companies and non existent organizations. 6) Mr. Mettin's claims that my actions resulted in the shut down of a company are partially true. My actions resulted in the business failure of at least three companies and the investigation of a number of individuals for criminal acts being tax evasion and money laundering. Some individuals involved in these investigations have settled with the Dutch tax authorities. We also had the full support of the Turkish Government and SITA, as well as a number of other influential people, organization and countries. That support evaporated when I when public and blew the whistle. As a result of my actions fewer people ended up loosing their money in this scam which was my intention. 7) Mr. Mettin's claims that I lie are also false, libelous, slanderous and defamatory. regards joe baptista On Sat, Nov 28, 2009 at 8:55 PM, Christopher Mettin wrote: ARIN Community, The following message was sent recently to the ARIN mailing list by an Internet terrorist known as Joe Baptista. >OK - before someone end up donating addresses and gets involved in a fraud - I think it's time for a little >backgrounder on Christopher Mettin. > >http://bit.ly/87Yjir > >What Chris needs are a few blocks of /24 to setup a root system based on what I know of him. Thats what I think >he is going on about - that they need fixed IP. About the only protocol widely used still requiring fixed IP >for the root cache. > >Be careful I have been unable to confirm what he is doing is even authorized by the school. If you feel so >inclined to provide /24 blocks to them - make sure a responsible adult from the school signs on the dotted >line, takes responsibility and absolves you of any legal liability. > >I do however support his initial point. These are only numbers and ARIN RIPE APNIC et. al. are making a killing >for just providing a database function - the rest as far as I can see is mainly hype and make work projects. I >think thats been mentioned before. A few months ago my school has been attacked by this guy. He did already make an entire company shut down. His best weapons are lies. All that started when he was fired by the Public Root in 2005. We have been assigned a domain by a company affiliated with the Public Root Ltd. and so we became a major target to him. He sends his emails from a domain publishing a website of a "PublicRoot Consortium" which does not exist. The contact address of this consortium is a private home in an Ontarian suburb. Sending emails using this domain he tries to make people believe he is an official employee of the Public Root. The IP addresses shall be in no way used with any root system. For further reference on Joe Baptista, see http://inaic.com/index.php?p=news-25-08-2008. Sincerely yours, Christopher Mettin Gymnasium Querfurt High School APPENDIX A: whois -h whois.inaic.net GQNET Corporate TLD (cTLD): .GQNET TLD Status: Active TLD Register Date: 13-05-2009 TLD Updated: 29-05-2009 TLD Expire Date: 13-05-2010 Preferred Domain Name Registry: GQnet ( http://gqbc-online.com ) TLD Registrant: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Administrative contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Technical contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Billing contact: Name: Christopher Mettin Company name: Gymnasium Querfurt High School Address: An der Geistpromenade 29 City: Quefurt State: Zip: 06268 Country: Germany Phone: +49.347.712.2226 Cell phone: Fax: +49.347.712.8826 Email: cmettin at gqbc-online.com TLD Servers: TLD Server1: tld1.public-root.net - IPV4: 84.22.100.6 TLD Server2: tld2.public-root.net - IPV4: 57.67.193.188 TLD Server3: tld3.public-root.net - IPV4: 199.5.156.122 By submitting a Global TLD WHOIS query you agree to use this data only for lawful purposes. Under no circumstances will you use this data to: (1) Allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail, telephone, or facsimile; or: (2) Enable high volume, automated, electronic processes against the INAIC or its data systems and networks. The compilation, repackaging, dissemination or other use of this data is expressly prohibited without the prior written consent of the INAIC. The INAIC reserves the right to revoke access to the Global TLD WHOIS Database in its sole discretion, including without limitation, for excessive querying of the Global TLD WHOIS Database or for failure to otherwise abide by this policy. TLD Registrants are responsible for the information maintained in the directory services database.The INAIC does not guarantee the accuracy of the information maintained in the Global TLD WHOIS Database. _____ _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- Walter Keen Network Technician Rainier Connect (o) 360-832-4024 (c) 253-302-0194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From geneb at deltasoft.com Tue Dec 1 13:47:48 2009 From: geneb at deltasoft.com (Gene Buckle) Date: Tue, 1 Dec 2009 10:47:48 -0800 (PST) Subject: [arin-ppml] Apology requested from Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: <874c02a20912011042r5ef66066jbdaa18dbd7ab3b6d@mail.gmail.com> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <874c02a20912011042r5ef66066jbdaa18dbd7ab3b6d@mail.gmail.com> Message-ID: > > Mr. Mettin has claimed I falsified documents. This is a most serious claim > which is of course false, libelous, scandalous and defamatory. Mr. Mettin > kindly produce these documents you claim are false. > Translation: "Moooooom! Chris is picking on me again! Make him stop!" g. From sethm at rollernet.us Tue Dec 1 14:05:22 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 01 Dec 2009 11:05:22 -0800 Subject: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School In-Reply-To: <4C1746A1D20C3148B6434776DFFF06C5055742@newserver.arneill-py.local> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <4C1746A1D20C3148B6434776DFFF06C5055742@newserver.arneill-py.local> Message-ID: <4B1568F2.4050604@rollernet.us> Michel Py wrote: > Dear Joe, > > I'm looking for a little extra cash and I was wondering if there is a > bounty on your head ;-) > Come on, no real terrorist can be without a sizeable bounty. > > Seriously now, you should not be feeding the troll. You know better than > this. > > Someone from, arin-ppml please ban cmettin at gqbc-online.com from the > mailing list? There is such thing as troll management; it's been > entertaining but as most of us I am busy and if I start ignoring every > troll in the world I won't have time to do anything else. > I was going to suggest the same thing right before 4 of my Sprint circuits dropped, then I got busy. Seriously. Get him off the list yesterday. This isn't the kind of audience I should expect to have to micro-manage killing threads and posters. And for those who need a reminder of the AUP here: "Specifically Prohibited Activities The following activities are specifically prohibited on any ARIN mailing list: 1. Statements that include foul language, personal character attacks, or show disrespect for other participants, including ARIN. 2. Statements that are slanderous or libelous, including making defamatory and untrue accusations of criminal conduct. 3. Product marketing. 4. Use or distribution of others' comments or e-mail addresses for any purpose other than to discuss relevant issues pertaining to approved topics. 5. Posts which interfere with the customary communications on the list. 6. Postings by fictional or non-identifiable names and addresses. 7. Posting knowingly false or fictitious statements. 8. Actions, that while not described specifically here, are similar to the conduct described." https://www.arin.net/participate/mailing_lists/aup.html ~Seth From rudi.daniel at gmail.com Tue Dec 1 14:07:00 2009 From: rudi.daniel at gmail.com (RudOlph Daniel) Date: Tue, 1 Dec 2009 14:07:00 -0500 Subject: [arin-ppml] SWIPs & IPv6 Message-ID: <8aeeaff60912011107r10d0956cxd80a1bf66d1ef6a3@mail.gmail.com> Maybe its timely for a SWIP/rWHOIS review? I think there is a great deal to be said for establishing whether SWIP is going to become burdensome with IPv6 allocations and consider whether a different architect eg *("run their own server which provides an rwhois-like service to lookup the status of the provider's prefixes"..M.Dillon)* is going to be advantageous. RD I believe that the resource review policy would preserve the > need for ISPs to keep SWIPs up to date or risk having their > resources audited. > > Owen > > On Nov 30, 2009, at 2:22 PM, Danny McPherson wrote: > > > > > I'd like to know what folks here are thinking regarding > > IPv6 and SWIPs. In particular, a primary driver for SWIPs > > today is to enable justification of additional addresses > > (when the time comes). SWIP data is clearly invaluable to > > network operations and security folks, as well as law > > enforcement, when investigating or dealing with various > > incidents (not to mention many other uses, as many of you > > well know). > > > > I suspect that with such large IPv6 allocations, the need > > to keep SWIP/(rwhois) data up to date will diminish, severely > > hindering folks that use SWIP data on a regular basis. > > > > Furthermore, while development of an RPKI is underway, it > > really only deals with certification of routed number spaces > > (as currently specified). While I _think we don't want all > > subsequent assignment/allocation data in the RPKI, I'm worried > > we won't have it anywhere with IPv6 -- or in many different > > places and formats. > > > > I suspect at least a BCP (some form, some where) and some > > community guidance is in order along these lines (i.e., > > SWIP-esque data is a must to some reasonable level of > > granularity), I'd like to see what folks here are thinking > > along these lines.. > > > > If I've missed this discussion here (or in other forums) > > references welcome, a cursory search yields nothing expressly > > related to this topic. > > > > Thanks in advance, > > > > -danny > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > ------------------------------ > > Message: 2 > Date: Mon, 30 Nov 2009 23:25:54 -0600 > From: Stan Barber > To: Owen DeLong > Cc: arin ppml > Subject: Re: [arin-ppml] SWIPs & IPv6 > Message-ID: <4B14A8E2.5020800 at academ.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Owen, > > How real is the risk of being audited? > > I am not asking that flippantly. I just wonder if ARIN has ever audited > and if so, what was the reason? Was it because of bad SWIP information? > > Owen DeLong wrote: > > I believe that the resource review policy would preserve the > > need for ISPs to keep SWIPs up to date or risk having their > > resources audited. > > > > Owen > > > > On Nov 30, 2009, at 2:22 PM, Danny McPherson wrote: > > > >> > >> I'd like to know what folks here are thinking regarding > >> IPv6 and SWIPs. In particular, a primary driver for SWIPs > >> today is to enable justification of additional addresses > >> (when the time comes). SWIP data is clearly invaluable to > >> network operations and security folks, as well as law > >> enforcement, when investigating or dealing with various > >> incidents (not to mention many other uses, as many of you > >> well know). > >> > >> I suspect that with such large IPv6 allocations, the need > >> to keep SWIP/(rwhois) data up to date will diminish, severely > >> hindering folks that use SWIP data on a regular basis. > >> > >> Furthermore, while development of an RPKI is underway, it > >> really only deals with certification of routed number spaces > >> (as currently specified). While I _think we don't want all > >> subsequent assignment/allocation data in the RPKI, I'm worried > >> we won't have it anywhere with IPv6 -- or in many different > >> places and formats. > >> > >> I suspect at least a BCP (some form, some where) and some > >> community guidance is in order along these lines (i.e., > >> SWIP-esque data is a must to some reasonable level of > >> granularity), I'd like to see what folks here are thinking > >> along these lines.. > >> > >> If I've missed this discussion here (or in other forums) > >> references welcome, a cursory search yields nothing expressly > >> related to this topic. > >> > >> Thanks in advance, > >> > >> -danny > >> > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > ------------------------------ > > Message: 3 > Date: Tue, 1 Dec 2009 06:53:15 -0500 > From: John Curran > To: Stan Barber > Cc: arin ppml > Subject: Re: [arin-ppml] SWIPs & IPv6 > Message-ID: <2C7B54B5-3261-4691-A7C1-A5165A1532F4 at arin.net> > Content-Type: text/plain; charset="us-ascii" > > On Dec 1, 2009, at 12:25 AM, Stan Barber wrote: > > > Owen, > > > > How real is the risk of being audited? > > > > I am not asking that flippantly. I just wonder if ARIN has ever audited > and if so, what was the reason? Was it because of bad SWIP information? > > Stan - > > The resource review policy is relatively new, but ARIN has indeed been > making use of when we see strong indication of fraudulent activities or > related misappropriation of number resources. > > While in theory resource review could be performed for any reason > (including lax updates to SWIP information), it has been our practice to > only make use of it where that the community is potentially being deprived > of the use of numbering resources. > > /John > > John Curran > President and CEO > ARIN > > > > > ------------------------------ > > Message: 4 > Date: Tue, 1 Dec 2009 11:57:23 -0000 > From: > To: > Subject: Re: [arin-ppml] SWIPs & IPv6 > Message-ID: > < > 28E139F46D45AF49A31950F88C497458044FE712 at E03MVZ2-UKDY.domain1.systemhost.net > > > > Content-Type: text/plain; charset="us-ascii" > > > I suspect that with such large IPv6 allocations, the need to > > keep SWIP/(rwhois) data up to date will diminish, severely > > hindering folks that use SWIP data on a regular basis. > > I think that a good way to counter this would be to provide > an easy to use, standard way, for providers to report this > information. The current SWIP system is not the way forward. > > A better architecture would be for every provider to run > their own server which provides an rwhois-like service to > lookup the status of the provider's prefixes. This service > should allow for richer information to be provided than > just assigned/unassigned. This provides the possibilities > for providers to cooperate under the auspices of some other > organization like MAAWG and agree to provide each other > certain status information. For instance they could flag > an address as a former SPAM source that was dealt with, or > a botnet infestation that was cleaned, or any other status > information that is useful to share. > > ARIN's role would be to produce the open-source software > package to run this service, to define a minimum set of status > to be reported, and to provide a mirroring service. In this > way, the ISP's responsibility is to record the status in > their database and to make sure that their status reporting > server has access to the database. People can then query > the ISP's server directly, or ARIN's mirror, or a 3rd party > mirror at their liberty. > > In addition to lookups, the server should provide support for > mirroring, i.e. it should be possible to query for all updates > since a certain time, and get a batch feed of the changes for > the ARIN mirror. > > Included in the minimum status information to be reported, > should be the identity and contact information for the people > who are charged with managing the network which uses > particular address range. This should never be assumed to > be the party to whom the addresses were assigned, but should > by default be the ISP who owns the allocation. Rather than > overloading the existing whois data with multiple meanings, > this new service should make a serious effort to separate > things so that the current status of an address block is > reported clearly and unambiguously. And the protocol used > for this should be extensible, for instance don't use a > yes/no value for "assigned", but use a 3 digit status code > with value 000 meaning unused, 001 meaning assigned, and > all the rest of the values open for definition in future. > And don't return a single code, but return a list of codes > so that you can have either "001," or "001,202" meaning > assigned and blocked for non-payment. REST may be the best > protocol to choose for this status reporting. > > We have the opportunity here to fix the whois system and > replace it with something that makes sense for the long > haul, and get rid of the legacy of identifying system > users to justify DARPA funding. > > --Michael Dillon > > > ------------------------------ > > Message: 5 > Date: Tue, 1 Dec 2009 12:01:47 -0000 > From: > To: > Subject: Re: [arin-ppml] SWIPs & IPv6 > Message-ID: > < > 28E139F46D45AF49A31950F88C497458044FE731 at E03MVZ2-UKDY.domain1.systemhost.net > > > > Content-Type: text/plain; charset="us-ascii" > > > While in theory resource review could be performed for any > > reason (including lax updates to SWIP information), it has > > been our practice to only make use of it where that the > > community is potentially being deprived of the use of > > numbering resources. > > Sounds like you are following the old maxim "You'll catch > more flies with honey than with vinegar" and reserving the > use of vinegar for the outrageous offenders. As it should be. > > I think that where there is non-compliance with ARIN > rules, it is most often because the rules are confusing > and the systems that one must be compliant with are > hard to use. A better action would be to talk to people, > find out what barriers are leading to non-compliance, > and work to remove or minimize those barriers. > > --Michael Dillon > > > ------------------------------ > > Message: 6 > Date: Tue, 01 Dec 2009 08:33:01 -0800 > From: Ted Mittelstaedt > To: Danny McPherson > Cc: arin ppml > Subject: Re: [arin-ppml] SWIPs & IPv6 > Message-ID: <4B15453D.2070309 at ipinc.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Danny McPherson wrote: > > I'd like to know what folks here are thinking regarding > > IPv6 and SWIPs. In particular, a primary driver for SWIPs > > today is to enable justification of additional addresses > > (when the time comes). SWIP data is clearly invaluable to > > network operations and security folks, as well as law > > enforcement, when investigating or dealing with various > > incidents (not to mention many other uses, as many of you > > well know). > > > > I suspect that with such large IPv6 allocations, the need > > to keep SWIP/(rwhois) data up to date will diminish, severely > > hindering folks that use SWIP data on a regular basis. > > > > I think it would be foolish to assume this. You bought into > this naieve notion that SWIP data is mainly of benefit to OTHER people, > promulgated by all the bonehead privacy-terrorists out there who think > that a SWIP filed on them will let the identity thieves steal > them blind. > > In reality, SWIPs aren't for the rest of the Internet, they help > make YOUR job easier. > > If you don't file SWIP data or run RWhois on your subnets, then > the only SWIP > entry that will exist for your subnet that's assigned by the RIR is > going to be the one that the RIR inserted when they gave > you your IPv6 assignment. Thus, any time one of the orgs > that you assigned subnets to goes and honks-off ME, well > then YOU are going to get my complaint. > > If YOU want to waste all your time handling these complaints > well then I don't give a rat's ass, but if you DON'T -handle- the > complaint and your customer continues honking me off, well then I'm > going to block YOUR ENTIRE BLOCK - because since you didn't > file a SWIP how the hell am I going to know what part of > your assigned numbers does this org have access to that > is honking me off? From my point of view, your ENTIRE block is > suspect, not just the piece that you assigned to Wonkulating > Gronkulators. > > So, for LIRS that want to pee all over themselves, well > then don't file SWIPS. In fact I ENCOURAGE IT STRONGLY because > then all I have to do is null-route your ENTIRE AS, I don't even > have to waste CPU cycles blocking just the obnoxious traffic > from Wonkulating. > > > > > If I've missed this discussion here (or in other forums) > > references welcome, a cursory search yields nothing expressly > > related to this topic. > > > > Probably because of the same reason that a cursory search > won't find any discussions about the pros and cons of > staring straight into the sun for an hour at high noon. > > Ted > > > Thanks in advance, > > > > -danny > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 54, Issue 1 > **************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmettin at gqbc-online.com Tue Dec 1 14:04:17 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Tue, 1 Dec 2009 20:04:17 +0100 Subject: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School In-Reply-To: <4C1746A1D20C3148B6434776DFFF06C5055742@newserver.arneill-py.local> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <4C1746A1D20C3148B6434776DFFF06C5055742@newserver.arneill-py.local> Message-ID: He has a bounty, just deposit him at a Canadian prison and they gonna pay you the bounty. I don't know why but it just makes him feel good if other people feel bad. This is some psychological disease, I guess. And most terrorists just act on the same basics. Why doesn't he remove himself from the mailing list, I did not come to make a comment on the new policy yet and I would like to do so any time. -----Original Message----- From: Michel Py [mailto:michel at arneill-py.sacramento.ca.us] Sent: Tuesday, December 01, 2009 7:31 PM To: Joe Baptista Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School Dear Joe, I'm looking for a little extra cash and I was wondering if there is a bounty on your head ;-) Come on, no real terrorist can be without a sizeable bounty. Seriously now, you should not be feeding the troll. You know better than this. Someone from, arin-ppml please ban cmettin at gqbc-online.com from the mailing list? There is such thing as troll management; it's been entertaining but as most of us I am busy and if I start ignoring every troll in the world I won't have time to do anything else. Michel. From Brian.Mort at arvig.com Tue Dec 1 13:49:15 2009 From: Brian.Mort at arvig.com (Brian Mort) Date: Tue, 01 Dec 2009 12:49:15 -0600 Subject: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School In-Reply-To: References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <874c02a20912011042r5ef66066jbdaa18dbd7ab3b6d@mail.gmail.com> Message-ID: <4B1510CA.ED14.0087.0@arvig.com> Stop touching me! Brian Mort Network Engineer Arvig Communication Systems brian.mort at arvig.com (218) 346-8231 >>> Gene Buckle 12/1/2009 12:47 PM >>> > > Mr. Mettin has claimed I falsified documents. This is a most serious claim > which is of course false, libelous, scandalous and defamatory. Mr. Mettin > kindly produce these documents you claim are false. > Translation: "Moooooom! Chris is picking on me again! Make him stop!" g. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From sob at academ.com Tue Dec 1 13:47:44 2009 From: sob at academ.com (Stan Barber) Date: Tue, 01 Dec 2009 12:47:44 -0600 Subject: [arin-ppml] ARIN Audits (was SWIPs & IPv6) Message-ID: <87d69953e79e207cafc2bf6e93aea4d9@academ.com> John Curran writes: >Stan - > > The resource review policy is relatively new, but ARIN has indeed been > >making use of when we see strong indication of fraudulent activities or > >related misappropriation of number resources. > > While in theory resource review could be performed for any reason > >(including lax updates to SWIP information), it has been our practice to > >only make use of it where that the community is potentially being deprived > >of the use of numbering resources. Thanks, John. Are these activities documented somewhere for community review? I am just trying to understand the criteria that would warrant such a review. I think I understand what you mean by "fraudulent activities or related misappropriation of number resources," but have a concrete example or two would help crystallize it for me. For example, would a history of bad record keeping (inaccurate SWIPs or Rwhois entries that usage that may have initially been correct, but has subsequently not been properly maintained) meet the criteria? I would guess that it would not since it is more negligent than fraudulent. Of course, rampant negligence of an entity that holds a large bank of numbering resources and continues to ask for more would meet the criteria of potentially depriving the community of the use of numbering resources. That alone must not be enough since there are holders of Class A and B space that might be better utilized if returned for reallocation. Is it also safe to assume that this only relates to space that ARIN itself has allocated and not to space allocated before the RIR infrastructure was on-line? [Aside to others: I really have always been interested in this stuff, but only recently have been able to get re-engaged in ARIN activities, so please bear with me while I get some of the questions I have longing to ask on the table. I apologize in advance if this is self-indulgent and distracting.] STAN From JBallerini at copsmonitoring.com Tue Dec 1 14:15:11 2009 From: JBallerini at copsmonitoring.com (John Ballerini) Date: Tue, 01 Dec 2009 14:15:11 -0500 Subject: [arin-ppml] Apology requested from Christopher Mettinand theGymnasium Querfurt High School In-Reply-To: <4B1510CA.ED14.0087.0@arvig.com> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <874c02a20912011042r5ef66066jbdaa18dbd7ab3b6d@mail.gmail.com> <4B1510CA.ED14.0087.0@arvig.com> Message-ID: <4B1524EF02000093000180F5@copsmonitoring.com> Wait till your fathers come home.... >>> "Brian Mort" 12/1/2009 1:49 PM >>> Stop touching me! Brian Mort Network Engineer Arvig Communication Systems brian.mort at arvig.com (218) 346-8231 >>> Gene Buckle 12/1/2009 12:47 PM >>> > > Mr. Mettin has claimed I falsified documents. This is a most serious claim > which is of course false, libelous, scandalous and defamatory. Mr. Mettin > kindly produce these documents you claim are false. > Translation: "Moooooom! Chris is picking on me again! Make him stop!" g. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Tue Dec 1 14:18:27 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 01 Dec 2009 11:18:27 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <1BF286A2-3699-464B-AD26-35F7D3CBFD42@tcb.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <1BF286A2-3699-464B-AD26-35F7D3CBFD42@tcb.net> Message-ID: <4B156C03.1090204@ipinc.net> Danny McPherson wrote: > On Dec 1, 2009, at 9:33 AM, Ted Mittelstaedt wrote: >> I think it would be foolish to assume this. You bought into >> this naieve notion that SWIP data is mainly of benefit to OTHER people, >> promulgated by all the bonehead privacy-terrorists out there who think >> that a SWIP filed on them will let the identity thieves steal >> them blind. > > No, I'm assuming people are lazy. You seem to be more > optimistic. It had nothing to do with identity thieves, > the bar is much lower there.. > >> In reality, SWIPs aren't for the rest of the Internet, they help >> make YOUR job easier. > > ... > >> So, for LIRS that want to pee all over themselves, well >> then don't file SWIPS. In fact I ENCOURAGE IT STRONGLY because >> then all I have to do is null-route your ENTIRE AS, I don't even >> have to waste CPU cycles blocking just the obnoxious traffic >> from Wonkulating. > > Right, you'll do this until someone that YOUR customers > wants to reach is blocked, and then YOU will remove YOUR > senseless null route... Nope, that's not the way things work on the Internet and there are many examples. If I'm large then I can do as I please, for example when Verizon.net instituted "call backs" in e-mail it pissed off a lot of customers, and some left, but Verizon ignored their complaints and so everyone else on the Internet ended up having to make sure their e-mail systems were compatible. If I'm small then I can do as I please as well unless the other network I don't like is large, like a Google or some such. If my network is getting attacked by a smaller subnet then all my customers are affected - if I block that network, then only one or 2 of my customers might notice, and if they leave me and go elsewhere, then I no longer have ANY incentive to stop blocking the remote network. You see, when running an ISP you always have to sacrifice the needs of the few for the needs of the many, that's ISP operations 101. Otherwise you end up pissing off the majority of your customers and they all leave, then your out of business. This is why for example that Comcast limits speed on file sharing - they know that they would lose a few customers, but the majority would just grumble but give in to it. Trust me I've seen this before, and there are always two sides. If I null-route you and it affects one of my customers who wants to reach one of your customers, and I dig in my heels and refuse to rescind my null route, and you dig in your heels and refuse to reign in the abuser on your network who is attacking me, then that leaves only one choice to your customer and my customer - one of them will have to quit service with one of us if they want to connect with each other. Assuming no workaround is available, then our customers will talk amongst themselves and jointly decide which one of them will quit service. And I have found that if I have good reasons for instituting my block, and make absolutely sure that my customer clearly understands them, that I have a 50% chance that I'll win, and retain my customer, and you will lose. And, if you don't take the time to carefully outline your position to your customer, and just give them the usual BS explanations, then my chance of winning easily jumps to 80% or more. But that's a local policy decision, > to each their own... > Exactly. I have plenty of documented instances like the collapse of AGIS, and the behavior of my customers, that more than satisfactorily prove to me that other networks that engage in irresponsible behavior have no power to put us out of business. It's only when I act irresponsibly that I'm threatened. Such as NOT giving you the chance to shut down your customer who was causing trouble. But, if I GIVE you the chance, and you DON'T do it, then -I- and responsible, -YOU- are not, and I'm going to win the majority of our battles. Meaning that over time your going to end up with all the crappy customers who like to beat you over the head with ultimatums, I will end up with the good customers who want a tight ship. Sorry you don't like this, but this is how the world really works. Ted >> Probably because of the same reason that a cursory search >> won't find any discussions about the pros and cons of >> staring straight into the sun for an hour at high noon. > > I suspect I could find a discussion on that, actually.. > > At least part of your response was worth reading, > > -danny > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From kbanks at giantcomm.net Tue Dec 1 14:18:49 2009 From: kbanks at giantcomm.net (Kyle Banks) Date: Tue, 1 Dec 2009 13:18:49 -0600 Subject: [arin-ppml] Apology requested from Christopher Mettinand theGymnasium Querfurt High School In-Reply-To: <4B1524EF02000093000180F5@copsmonitoring.com> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com><874c02a20912011042r5ef66066jbdaa18dbd7ab3b6d@mail.gmail.com><4B1510CA.ED14.0087.0@arvig.com> <4B1524EF02000093000180F5@copsmonitoring.com> Message-ID: <028801ca72bb$1d0ccf30$3501a8c0@macc173.net> Mom- He won't stop looking at me. . Don't make me pull this car over. K. Vincent Banks Service/Technical Representative Giant Communications 785-362-9331 EXT. 108 kbanks at giantcomm.net -- Blessed is he who expects nothing, for he shall never be disappointed--Benjamin Franklin _____ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Ballerini Sent: Tuesday, December 01, 2009 1:15 PM To: arin-ppml at arin.net; Brian Mort; Gene Buckle Subject: Re: [arin-ppml] Apology requested from Christopher Mettinand theGymnasium Querfurt High School Wait till your fathers come home.... >>> "Brian Mort" 12/1/2009 1:49 PM >>> Stop touching me! Brian Mort Network Engineer Arvig Communication Systems brian.mort at arvig.com (218) 346-8231 >>> Gene Buckle 12/1/2009 12:47 PM >>> > > Mr. Mettin has claimed I falsified documents. This is a most serious claim > which is of course false, libelous, scandalous and defamatory. Mr. Mettin > kindly produce these documents you claim are false. > Translation: "Moooooom! Chris is picking on me again! Make him stop!" g. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From baptista at publicroot.org Tue Dec 1 14:19:21 2009 From: baptista at publicroot.org (Joe Baptista) Date: Tue, 1 Dec 2009 14:19:21 -0500 Subject: [arin-ppml] Apology requested from Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <4B155B59.6070606@ipinc.net> Message-ID: <874c02a20912011119r4d78aa4ah32382321341a701@mail.gmail.com> Interesting you should mention the subject of Net.Kook On Tue, Dec 1, 2009 at 1:24 PM, Gene Buckle wrote: > > Oh I don't know. This is the most entertaining nonsense I've seen in > _ages_. All this needs is one or two old-time Net.Kooks to stick their oars > in. *laughs* > In fact I was elected a Net.Kook many moons ago. Possibly as far back as 1995 mainly for my beliefs that the Internet was dangerous place - i.e. security issues, privacy issues, and could be used for warfare. As time passed and my concerns became a reality the mantel of net.kook seems to have faded away. A bit unfortunate since I always considered the title something of a novelty. > > I have to admit though, "internet terrorist" is absurd in the extreme. :) > Yes - of course it is - but to the uneducated border guard in a 9/11 world a potential inconvenience. Most of the claims they have made against me are not only absurd - they are unreal. I have in my collection correspondence and audio recordings in which they claim I'm an alien. Thats alien as in extraterrestrial. The first libelous and slanderous allegation against me was that I was importing heroin into Germany and a deranged drug addict. Check it out: http://bit.ly/5hRxns That allegation was retracted when they discovered I was traveling back to the Netherlands where I think libel and slander is a quasi criminal matter. You can check out their apology at the following URL: http://bit.ly/8MDC9C As you can see they also asked me for an apology - non was given. Maybe it's time for another visit to the Netherlands to wrap things up. cheers joe baptista -------------- next part -------------- An HTML attachment was scrubbed... URL: From baptista at publicroot.org Tue Dec 1 14:23:06 2009 From: baptista at publicroot.org (Joe Baptista) Date: Tue, 1 Dec 2009 14:23:06 -0500 Subject: [arin-ppml] Apology requested from Christopher Mettin and theGymnasium Querfurt High School In-Reply-To: <4C1746A1D20C3148B6434776DFFF06C5055742@newserver.arneill-py.local> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <4C1746A1D20C3148B6434776DFFF06C5055742@newserver.arneill-py.local> Message-ID: <874c02a20912011123i2b9ea01fnfc966100403f51ac@mail.gmail.com> On Tue, Dec 1, 2009 at 1:30 PM, Michel Py < michel at arneill-py.sacramento.ca.us> wrote: > Dear Joe, > > I'm looking for a little extra cash and I was wondering if there is a > bounty on your head ;-) > Come on, no real terrorist can be without a sizeable bounty. > No .. not that I'm aware of. > > Seriously now, you should not be feeding the troll. You know better than > this. > I agree. Thats why I waited until the boys here had their fun with Chris before I asked for the apology. cheers joe baptista -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.daniel at gmail.com Tue Dec 1 14:31:07 2009 From: rudi.daniel at gmail.com (RudOlph Daniel) Date: Tue, 1 Dec 2009 14:31:07 -0500 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out - Last Call Message-ID: <8aeeaff60912011131r4e1ba6c6q3cf2346d4feea154@mail.gmail.com> I support this policy as below RD > Draft Policy 2009-8: Equitable IPv4 Run-Out is in Last Call. > > Draft Policy 2009-8: Equitable IPv4 Run-Out > > > > Feedback is encouraged during this last call period. All comments should > > be provided to the Public Policy Mailing List. This last call will > > expire on 10 December 2009. After last call the AC will conduct their > > last call review. > > > > The draft policy text is below and available at: > > https://www.arin.net/policy/proposals/ > > > > The ARIN Policy Development Process is available at: > > https://www.arin.net/policy/pdp.html > > > > Regards, > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > > > Draft Policy 2009-8 > > Equitable IPv4 Run-Out > > > > Version/Date: 24 November 2009 > > > > Policy statement: > > > > Rename NRPM 4.2.4.3; > > > > 4.2.4.3 Subscriber Members Less Than One Year > > > > Replace NRPM 4.2.4.4 with; > > > > 4.2.4.4 Subscriber Members After One Year > > > > After an organization has been a subscriber member of ARIN for one year, > > they may choose to request up to a 12 month supply of IP addresses. > > > > When ARIN receives its last /8, by IANA implementing section 10.4.2.2, > > the length of supply that an organization may request will be reduced. > > An organization may choose to request up to a 3 month supply of IP > > addresses. > > > > This reduction does not apply to resources received via section 8.3. An > > organization receiving a transfer under section 8.3 may continue to > > request up to a 12 month supply of IP addresses. > > > > Rationale: > > > > This policy is intended to ensure an equitable distribution of IPv4 > > resources as run-out of the ARIN free pool occurs. This is achieved by > > changing section 4.2.4.4 of the NRPM to reduce the length of supply of > > IPv4 resources that may be requested when the IANA free pool runs-out. > > Equity is accomplished by reducing the window that an advantage or > > disadvantage can exist between competitors, that will be created when > > one competitor receives a final allocation just before run-out and > > another competitor does not. > > > > Further this policy ensures equity between incumbent resource holders > > and new entrants by providing the same length of supply for each as the > > ARIN free pool runs out. This eliminates a potential bias toward > > incumbent resource holders that is created as a result of ARIN free pool > > run-out interacting with resource allocation slow start for new entrants > > in current policy. > > > > This policy is similar to ideas in RIPE policy proposal 2009-03 > > (http://www.ripe.net/ripe/policies/proposals/2009-03.html), and has been > > adapted by discussion and for use within the ARIN region. > > > > This policy is intended to be independent of other policies or proposals > > to reserve address space for IPv6 transition or other purposes. It is > > not intended to limit Transfers to Specified Recipients per section 8.3 > > of the NRPM. > > > > This draft contains the elements that there seems to have been the > > largest consensus for on the floor of ARIN XXIV Public Policy Meeting in > > Dearborn, Michigan. Further, there was a strong preference that no > > changes be triggered until IANA free pool run-out. > > > > Timetable for implementation: Immediate > > > =============================================== > David Farmer Email:farmer at umn.edu > Office of Information Technology > Networking & Telecomunication Services > University of Minnesota Phone: 612-626-0815 > 2218 University Ave SE Cell: 612-812-9952 > Minneapolis, MN 55414-3029 FAX: 612-626-1818 > =============================================== > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 54, Issue 4 > **************************************** > -- Rudi Daniel Independent Consultants http://www.svgpso.org http://danielcharles.weebly.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances at motivity.ca Tue Dec 1 14:33:09 2009 From: vances at motivity.ca (Vance Shipley) Date: Tue, 1 Dec 2009 14:33:09 -0500 Subject: [arin-ppml] Apology requested from Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <4B155B59.6070606@ipinc.net> Message-ID: <20091201193308.GG63795@h216-235-12-172.host.egate.net> You've already got an original net.kook! http://www.tranquileye.com/magic/magic_stuff/Toronto_Net_loons.htm On Tue, Dec 01, 2009 at 10:24:40AM -0800, Gene Buckle wrote: } All this needs is one or two old-time Net.Kooks to } stick their oars in. *laughs* -- -Vance From bjohnson at drtel.com Tue Dec 1 14:42:54 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Tue, 1 Dec 2009 13:42:54 -0600 Subject: [arin-ppml] RE: Apology requested from Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: <4B155B59.6070606@ipinc.net> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <4B155B59.6070606@ipinc.net> Message-ID: <29A54911243620478FF59F00EBB12F4701B2753A@ex01.drtel.lan> I'm confused. Shouldn't Christopher be talking to someone at RIPE-NCC? Even though he is on some kind of "US territory", it is within the RIPE region, isn't it? It also seems that he doesn't understand the basic operation of a RIR. He believes he is purchasing addresses and that ARIN "sells" address space. Am I reading him wrong? - Brian > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Tuesday, December 01, 2009 12:07 PM > To: Joe Baptista > Cc: Christopher Mettin; arin-ppml at arin.net > Subject: Re: [arin-ppml] Apology requested from Christopher Mettin and > the Gymnasium Querfurt High School > > Joe and Christopher, > > It was only fun to watch until you guys started breaking the > furniture. > > Ted > > Joe Baptista wrote: > > > > Dear Christopher and ARIN community: > > > > I am requesting a public apology from you Christopher Mettin and your > > organization the Gymnasium Querfurt High School for calling me an > > Internet terrorist, a liar and other libelous, slanderous and > defamatory > > statements made by you in a public forum against me. > > > > Also Christopher please do not jump the gun and make this decision on > > your own. Kindly consult your supervisor and principle with respect > to > > my request and take the time to show them my request as well as the > > statements made by you on behalf of your school against me. > > > > For the record I will now respond to the allegations made against me > by > > Mr. Mettin. > > > > 1) I am not an "Internet terrorist". This claim by Mr. Mettin below > is > > not only false but seriously libelous, slanderous and defamatory. > > > > 2) I was never an employee of the Public-Root. I was a consultant > since > > 2003. And I was not fired. I walked out along with other consultants > > because of the criminal activity uncovered by me - being mainly the > > embezzlement of funds, money laundering and tax evasion by senior > > executive staff. > > > > 3) I never attacked Christopher's Gymnasium Querfurt High School. > This > > claim is also false, libelous, slanderous and defamatory. I did > attempt > > to email senior staff and also called by phone but was unable to get > in > > touch with anyone except Mr. Mettin. I therefore have no idea if > school > > staff know what Mr. Mettin is up to as I have been unable to contact > a > > responsible adult at the school. > > > > 4) Mr. Mettin's claims that the PublicRoot Consortium does not exist > are > > false. The PublicRoot Consortium is organized as an unincorporated > trust > > in Canada. > > > > 5) Mr. Mettin's claims below that his schools only involvement with > the > > people who run the INAIC.com web site was to be "assigned a (top- > level) > > domain by a company affiliated with the Public Root Ltd." is false. > The > > top-level domain the Gymnasium Querfurt High School purchased from > them > > is GQNET - a copy of the whois for this domain is attached at the end > of > > this message as Appendix A. > > > > But as members here have pointed out Mr. Mettin's forgot to mention > that > > the Gymnasium Querfurt High School also sells TLDs for these shell > > companies and non existent organizations. > > > > 6) Mr. Mettin's claims that my actions resulted in the shut down of a > > company are partially true. My actions resulted in the business > failure > > of at least three companies and the investigation of a number of > > individuals for criminal acts being tax evasion and money laundering. > > Some individuals involved in these investigations have settled with > the > > Dutch tax authorities. > > > > We also had the full support of the Turkish Government and SITA, as > well > > as a number of other influential people, organization and countries. > > That support evaporated when I when public and blew the whistle. > > > > As a result of my actions fewer people ended up loosing their money > in > > this scam which was my intention. > > > > 7) Mr. Mettin's claims that I lie are also false, libelous, > slanderous > > and defamatory. > > > > regards > > joe baptista > > > > On Sat, Nov 28, 2009 at 8:55 PM, Christopher Mettin > > > wrote: > > > > ARIN Community, > > > > The following message was sent recently to the ARIN mailing list > by an > > Internet terrorist known as Joe Baptista. > > > > >OK - before someone end up donating addresses and gets involved > in > > a fraud > > - I think it's time for a little >backgrounder on Christopher > Mettin. > > > > > >http://bit.ly/87Yjir > > > > > >What Chris needs are a few blocks of /24 to setup a root system > > based on > > what I know of him. Thats what I think >he is going on about - > that they > > need fixed IP. About the only protocol widely used still > requiring > > fixed IP > > >for the root cache. > > > > > >Be careful I have been unable to confirm what he is doing is > even > > authorized by the school. If you feel so >inclined to provide /24 > > blocks to > > them - make sure a responsible adult from the school signs on the > dotted > > >line, takes responsibility and absolves you of any legal > liability. > > > > > >I do however support his initial point. These are only numbers > and > > ARIN > > RIPE APNIC et. al. are making a killing >for just providing a > database > > function - the rest as far as I can see is mainly hype and make > work > > projects. I >think thats been mentioned before. > > > > A few months ago my school has been attacked by this guy. He did > already > > make an entire company shut down. His best weapons are lies. > > > > All that started when he was fired by the Public Root in 2005. We > > have been > > assigned a domain by a company affiliated with the Public Root > Ltd. > > and so > > we became a major target to him. He sends his emails from a > domain > > publishing a website of a "PublicRoot Consortium" which does not > > exist. The > > contact address of this consortium is a private home in an > Ontarian > > suburb. > > Sending emails using this domain he tries to make people believe > he > > is an > > official employee of the Public Root. > > > > The IP addresses shall be in no way used with any root system. > > > > For further reference on Joe Baptista, see > > http://inaic.com/index.php?p=news-25-08-2008. > > > > Sincerely yours, > > Christopher Mettin > > Gymnasium Querfurt High School > > > > > > > > APPENDIX A: whois -h whois.inaic.net GQNET > > > > Corporate TLD (cTLD): .GQNET > > TLD Status: Active > > TLD Register Date: 13-05-2009 > > TLD Updated: 29-05-2009 > > TLD Expire Date: 13-05-2010 > > Preferred Domain Name Registry: GQnet ( http://gqbc-online.com ) > > > > TLD Registrant: > > Name: Christopher Mettin > > Company name: Gymnasium Querfurt High School > > Address: An der Geistpromenade 29 > > City: Quefurt > > State: > > Zip: 06268 > > Country: Germany > > Phone: +49.347.712.2226 > > Cell phone: > > Fax: +49.347.712.8826 > > Email: cmettin at gqbc-online.com > > > > TLD Administrative contact: > > Name: Christopher Mettin > > Company name: Gymnasium Querfurt High School > > Address: An der Geistpromenade 29 > > City: Quefurt > > State: > > Zip: 06268 > > Country: Germany > > Phone: +49.347.712.2226 > > Cell phone: > > Fax: +49.347.712.8826 > > Email: cmettin at gqbc-online.com > > > > TLD Technical contact: > > Name: Christopher Mettin > > Company name: Gymnasium Querfurt High School > > Address: An der Geistpromenade 29 > > City: Quefurt > > State: > > Zip: 06268 > > Country: Germany > > Phone: +49.347.712.2226 > > Cell phone: > > Fax: +49.347.712.8826 > > Email: cmettin at gqbc-online.com > > > > TLD Billing contact: > > Name: Christopher Mettin > > Company name: Gymnasium Querfurt High School > > Address: An der Geistpromenade 29 > > City: Quefurt > > State: > > Zip: 06268 > > Country: Germany > > Phone: +49.347.712.2226 > > Cell phone: > > Fax: +49.347.712.8826 > > Email: cmettin at gqbc-online.com > > > > TLD Servers: > > TLD Server1: tld1.public-root.net > - > > IPV4: 84.22.100.6 > > TLD Server2: tld2.public-root.net > - > > IPV4: 57.67.193.188 > > TLD Server3: tld3.public-root.net > - > > IPV4: 199.5.156.122 > > > > By submitting a Global TLD WHOIS query you agree to use this data > only > > for lawful purposes. Under no circumstances will you use this data > to: > > (1) Allow, enable, or otherwise support the transmission of mass > > unsolicited, commercial advertising or solicitations via e-mail, > > telephone, or facsimile; or: (2) Enable high volume, automated, > > electronic processes against the INAIC or its data systems and > networks. > > The compilation, repackaging, dissemination or other use of this data > is > > expressly prohibited without the prior written consent of the INAIC. > The > > INAIC reserves the right to revoke access to the Global TLD WHOIS > > Database in its sole discretion, including without limitation, for > > excessive querying of the Global TLD WHOIS Database or for failure to > > otherwise abide by this policy. > > > > TLD Registrants are responsible for the information maintained in the > > directory services database.The INAIC does not guarantee the accuracy > of > > the information maintained in the Global TLD WHOIS Database. > > > > > > --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jcurran at arin.net Tue Dec 1 15:10:29 2009 From: jcurran at arin.net (John Curran) Date: Tue, 1 Dec 2009 15:10:29 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B15453D.2070309@ipinc.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> Message-ID: On Dec 1, 2009, at 11:33 AM, Ted Mittelstaedt wrote: > ... > So, for LIRS that want to pee all over themselves, well > then don't file SWIPS. In fact I ENCOURAGE IT STRONGLY because > then all I have to do is null-route your ENTIRE AS, I don't even > have to waste CPU cycles blocking just the obnoxious traffic > from Wonkulating. Ted - Under this philosophical approach, what would ARIN's responsibilities be with respect to an organization which files no SWIP's and runs no rwhois service? More specifically, if an organization is willing to accept the incident/security response obligations implied by not showing sub-delegations, is that "acceptable" until/unless the organization needs to show utilization for an additional address block? (If so, wouldn't it be best to update the NRPM to reflect this "optionality" of SWIPs/rwhois data?) /John John Curran President and CEO ARIN From cmettin at gqbc-online.com Tue Dec 1 15:22:23 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Tue, 1 Dec 2009 21:22:23 +0100 Subject: [arin-ppml] RE: Apology requested from Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: <29A54911243620478FF59F00EBB12F4701B2753A@ex01.drtel.lan> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <4B155B59.6070606@ipinc.net> <29A54911243620478FF59F00EBB12F4701B2753A@ex01.drtel.lan> Message-ID: Well, to me charging a fee for a service is like selling a good. There actually is no difference, just another way to express the same idea. But to remain politically correct, ARIN is not selling IP addresses, they are allocating them to people against a fee. So that's the same with AOL charging a fee for the usage of their greeting card service, they are not selling ecards! As it seems the ground GQHS is on is its own region since no one (even not RIPE) feels responsible. Maybe I should ask IANA whether we can become our own RIR since the need / geographical size ratio appears to be the same as in any other RIR region. But I would like to try to amend the policy though, to make educational institutions eligible for a free allocation in the ARIN region, since we will open a new campus in Michigan (a state in ARIN's region) next year. Hope that answers all of your questions, Brian. -----Original Message----- From: Brian Johnson [mailto:bjohnson at drtel.com] Sent: Tuesday, December 01, 2009 8:43 PM To: arin-ppml at arin.net Subject: [arin-ppml] RE: Apology requested from Christopher Mettin and the Gymnasium Querfurt High School I'm confused. Shouldn't Christopher be talking to someone at RIPE-NCC? Even though he is on some kind of "US territory", it is within the RIPE region, isn't it? It also seems that he doesn't understand the basic operation of a RIR. He believes he is purchasing addresses and that ARIN "sells" address space. Am I reading him wrong? - Brian > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Tuesday, December 01, 2009 12:07 PM > To: Joe Baptista > Cc: Christopher Mettin; arin-ppml at arin.net > Subject: Re: [arin-ppml] Apology requested from Christopher Mettin and > the Gymnasium Querfurt High School > > Joe and Christopher, > > It was only fun to watch until you guys started breaking the > furniture. > > Ted > > Joe Baptista wrote: > > > > Dear Christopher and ARIN community: > > > > I am requesting a public apology from you Christopher Mettin and your > > organization the Gymnasium Querfurt High School for calling me an > > Internet terrorist, a liar and other libelous, slanderous and > defamatory > > statements made by you in a public forum against me. > > > > Also Christopher please do not jump the gun and make this decision on > > your own. Kindly consult your supervisor and principle with respect > to > > my request and take the time to show them my request as well as the > > statements made by you on behalf of your school against me. > > > > For the record I will now respond to the allegations made against me > by > > Mr. Mettin. > > > > 1) I am not an "Internet terrorist". This claim by Mr. Mettin below > is > > not only false but seriously libelous, slanderous and defamatory. > > > > 2) I was never an employee of the Public-Root. I was a consultant > since > > 2003. And I was not fired. I walked out along with other consultants > > because of the criminal activity uncovered by me - being mainly the > > embezzlement of funds, money laundering and tax evasion by senior > > executive staff. > > > > 3) I never attacked Christopher's Gymnasium Querfurt High School. > This > > claim is also false, libelous, slanderous and defamatory. I did > attempt > > to email senior staff and also called by phone but was unable to get > in > > touch with anyone except Mr. Mettin. I therefore have no idea if > school > > staff know what Mr. Mettin is up to as I have been unable to contact > a > > responsible adult at the school. > > > > 4) Mr. Mettin's claims that the PublicRoot Consortium does not exist > are > > false. The PublicRoot Consortium is organized as an unincorporated > trust > > in Canada. > > > > 5) Mr. Mettin's claims below that his schools only involvement with > the > > people who run the INAIC.com web site was to be "assigned a (top- > level) > > domain by a company affiliated with the Public Root Ltd." is false. > The > > top-level domain the Gymnasium Querfurt High School purchased from > them > > is GQNET - a copy of the whois for this domain is attached at the end > of > > this message as Appendix A. > > > > But as members here have pointed out Mr. Mettin's forgot to mention > that > > the Gymnasium Querfurt High School also sells TLDs for these shell > > companies and non existent organizations. > > > > 6) Mr. Mettin's claims that my actions resulted in the shut down of a > > company are partially true. My actions resulted in the business > failure > > of at least three companies and the investigation of a number of > > individuals for criminal acts being tax evasion and money laundering. > > Some individuals involved in these investigations have settled with > the > > Dutch tax authorities. > > > > We also had the full support of the Turkish Government and SITA, as > well > > as a number of other influential people, organization and countries. > > That support evaporated when I when public and blew the whistle. > > > > As a result of my actions fewer people ended up loosing their money > in > > this scam which was my intention. > > > > 7) Mr. Mettin's claims that I lie are also false, libelous, > slanderous > > and defamatory. > > > > regards > > joe baptista > > > > On Sat, Nov 28, 2009 at 8:55 PM, Christopher Mettin > > > wrote: > > > > ARIN Community, > > > > The following message was sent recently to the ARIN mailing list > by an > > Internet terrorist known as Joe Baptista. > > > > >OK - before someone end up donating addresses and gets involved > in > > a fraud > > - I think it's time for a little >backgrounder on Christopher > Mettin. > > > > > >http://bit.ly/87Yjir > > > > > >What Chris needs are a few blocks of /24 to setup a root system > > based on > > what I know of him. Thats what I think >he is going on about - > that they > > need fixed IP. About the only protocol widely used still > requiring > > fixed IP > > >for the root cache. > > > > > >Be careful I have been unable to confirm what he is doing is > even > > authorized by the school. If you feel so >inclined to provide /24 > > blocks to > > them - make sure a responsible adult from the school signs on the > dotted > > >line, takes responsibility and absolves you of any legal > liability. > > > > > >I do however support his initial point. These are only numbers > and > > ARIN > > RIPE APNIC et. al. are making a killing >for just providing a > database > > function - the rest as far as I can see is mainly hype and make > work > > projects. I >think thats been mentioned before. > > > > A few months ago my school has been attacked by this guy. He did > already > > make an entire company shut down. His best weapons are lies. > > > > All that started when he was fired by the Public Root in 2005. We > > have been > > assigned a domain by a company affiliated with the Public Root > Ltd. > > and so > > we became a major target to him. He sends his emails from a > domain > > publishing a website of a "PublicRoot Consortium" which does not > > exist. The > > contact address of this consortium is a private home in an > Ontarian > > suburb. > > Sending emails using this domain he tries to make people believe > he > > is an > > official employee of the Public Root. > > > > The IP addresses shall be in no way used with any root system. > > > > For further reference on Joe Baptista, see > > http://inaic.com/index.php?p=news-25-08-2008. > > > > Sincerely yours, > > Christopher Mettin > > Gymnasium Querfurt High School > > > > > > > > APPENDIX A: whois -h whois.inaic.net GQNET > > > > Corporate TLD (cTLD): .GQNET > > TLD Status: Active > > TLD Register Date: 13-05-2009 > > TLD Updated: 29-05-2009 > > TLD Expire Date: 13-05-2010 > > Preferred Domain Name Registry: GQnet ( http://gqbc-online.com ) > > > > TLD Registrant: > > Name: Christopher Mettin > > Company name: Gymnasium Querfurt High School > > Address: An der Geistpromenade 29 > > City: Quefurt > > State: > > Zip: 06268 > > Country: Germany > > Phone: +49.347.712.2226 > > Cell phone: > > Fax: +49.347.712.8826 > > Email: cmettin at gqbc-online.com > > > > TLD Administrative contact: > > Name: Christopher Mettin > > Company name: Gymnasium Querfurt High School > > Address: An der Geistpromenade 29 > > City: Quefurt > > State: > > Zip: 06268 > > Country: Germany > > Phone: +49.347.712.2226 > > Cell phone: > > Fax: +49.347.712.8826 > > Email: cmettin at gqbc-online.com > > > > TLD Technical contact: > > Name: Christopher Mettin > > Company name: Gymnasium Querfurt High School > > Address: An der Geistpromenade 29 > > City: Quefurt > > State: > > Zip: 06268 > > Country: Germany > > Phone: +49.347.712.2226 > > Cell phone: > > Fax: +49.347.712.8826 > > Email: cmettin at gqbc-online.com > > > > TLD Billing contact: > > Name: Christopher Mettin > > Company name: Gymnasium Querfurt High School > > Address: An der Geistpromenade 29 > > City: Quefurt > > State: > > Zip: 06268 > > Country: Germany > > Phone: +49.347.712.2226 > > Cell phone: > > Fax: +49.347.712.8826 > > Email: cmettin at gqbc-online.com > > > > TLD Servers: > > TLD Server1: tld1.public-root.net > - > > IPV4: 84.22.100.6 > > TLD Server2: tld2.public-root.net > - > > IPV4: 57.67.193.188 > > TLD Server3: tld3.public-root.net > - > > IPV4: 199.5.156.122 > > > > By submitting a Global TLD WHOIS query you agree to use this data > only > > for lawful purposes. Under no circumstances will you use this data > to: > > (1) Allow, enable, or otherwise support the transmission of mass > > unsolicited, commercial advertising or solicitations via e-mail, > > telephone, or facsimile; or: (2) Enable high volume, automated, > > electronic processes against the INAIC or its data systems and > networks. > > The compilation, repackaging, dissemination or other use of this data > is > > expressly prohibited without the prior written consent of the INAIC. > The > > INAIC reserves the right to revoke access to the Global TLD WHOIS > > Database in its sole discretion, including without limitation, for > > excessive querying of the Global TLD WHOIS Database or for failure to > > otherwise abide by this policy. > > > > TLD Registrants are responsible for the information maintained in the > > directory services database.The INAIC does not guarantee the accuracy > of > > the information maintained in the Global TLD WHOIS Database. > > > > > > --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mcr at sandelman.ca Tue Dec 1 15:44:21 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 01 Dec 2009 15:44:21 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> Message-ID: <26209.1259700261@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "John" == John Curran writes: >> ... So, for LIRS that want to pee all over themselves, well then >> don't file SWIPS. In fact I ENCOURAGE IT STRONGLY because then >> all I have to do is null-route your ENTIRE AS, I don't even have >> to waste CPU cycles blocking just the obnoxious traffic from >> Wonkulating. John> Ted - John> Under this philosophical approach, what would ARIN's John> responsibilities be with respect to an organization which John> files no SWIP's and runs no rwhois service? ARIN already clearly delegates to them, so that's done. John> More specifically, if an organization is willing to accept the John> incident/security response obligations implied by not showing John> sub-delegations, is that "acceptable" until/unless the John> organization needs to show utilization for an additional John> address block? (If so, wouldn't it be best to update the NRPM John> to reflect this "optionality" of SWIPs/rwhois data?) If an organization wants to be responsible for their customers' camel porn, then... they can call themselves (content-responsible) enterprises rather than (common-carrier) ISPs. I guess it's a feature of IPv6 that it enables organizations to not be network neutral, if they do not call themselves networks! (I wish that .net had been delegated to IANA/ARIN back in the early 1990s.. No ASN/-ARIN handle, no foo.net...) - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSxWAI4CLcPvd0N1lAQKcUQgAo0mpoyQJfNiG18JvLtp88pcMlwSBTqWf +Wri8NmD/irn7dUoPv1JcyqcBKK6iTuLeGvnzIeb657lukD078iuXwoAnW40PlqR rwcY2tekDG6lt4VOyz3KWGxUm0D3TjkmJkxvNZfVsqHt6LaCzGzCuE0PZ5weWIwP NjIXgjonS1QPk/sUyiHRTD2PiywSMSyE1/CUi7ctsBv2QxTWNsTas9oouwo3nSgb boV2FFSa0XXsE+9R1WUhM89kuNLmZROZAU2V4pMQuZWj3LSvBpBtpnylAXhd/s7E bdX+jZeE2kdzvXGsaTD7VOJRrBw/bWp88IdeOZwa1WyazoQ3xEXSbQ== =/HUM -----END PGP SIGNATURE----- From bmanning at vacation.karoshi.com Tue Dec 1 15:46:20 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 1 Dec 2009 20:46:20 +0000 Subject: [arin-ppml] RE: Apology requested from Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <4B155B59.6070606@ipinc.net> <29A54911243620478FF59F00EBB12F4701B2753A@ex01.drtel.lan> Message-ID: <20091201204620.GA2478@vacation.karoshi.com.> On Tue, Dec 01, 2009 at 09:22:23PM +0100, Christopher Mettin wrote: > > As it seems the ground GQHS is on is its own region since no one (even not > RIPE) feels responsible. Maybe I should ask IANA whether we can become our > own RIR since the need / geographical size ratio appears to be the same as > in any other RIR region. But I would like to try to amend the policy though, > to make educational institutions eligible for a free allocation in the ARIN > region, since we will open a new campus in Michigan (a state in ARIN's > region) next year. > becoming an RIR doesn't really equate to ratios per se. just saying. now as to opening campuses elsewhere - this sounds like you are potentially becoming invested in enough infrastructure that your requests for address space might become more credible. if you buy the routers and circuits to hook up your campuses into a private network, then establish peering with one or more ISPs, you have a credible case for PI space. as John Curran mentioned - you are more than welcome to participate in policy discussions here. and as others have mentioned, there is text on the table that might meet your needs - or as Michael Dillion has done, offered next text that may be considered as a policy in its own right. I suspect however, that unless the new campus in Michigan is the lead operational entity for your new institutional network that Johns observation about being qualified for address space under existing ARIN policy is sound. If I may offer a suggestion; I would develop a somewhat thicker skin and refrain from insinuations/accusations about anyones ethical or moral integrity or others claims of same about oneself on this list. It will not help when you try to persaude others of the value of your arguments in a policy discussion. Please respect the AUP of this list. --bill From cengel at sponsordirect.com Tue Dec 1 16:09:32 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Tue, 1 Dec 2009 16:09:32 -0500 Subject: [arin-ppml] Apology requested from Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: Message-ID: > Most of the claims they have made against me are not only absurd - they are unreal. > > I have in my collection correspondence and audio recordings in which they claim I'm an alien. > Thats alien as in extraterrestrial. Clearly that shows thier loss of touch with reality. EVERYONE on the internet knows that the aliens are merely a front for the Knights Templar except for a brief period in '99 when they were a front for Cthulhu. Christopher Engel From mueller at syr.edu Tue Dec 1 16:35:59 2009 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 1 Dec 2009 16:35:59 -0500 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out - Last Call In-Reply-To: <4B15080C.28232.1D4A9DEF@farmer.umn.edu> References: <4B0C074D.9020608@arin.net> <4B15080C.28232.1D4A9DEF@farmer.umn.edu> Message-ID: <75822E125BCB994F8446858C4B19F0D79AB7356A@SUEX07-MBX-04.ad.syr.edu> I support Draft Policy 2009-8 Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org > > Draft Policy 2009-8: Equitable IPv4 Run-Out is in Last Call. > > Three of the last four Draft Policies had little or no Last Call > comments; two hand no comments, one had one comment, > and the forth policy had 10 comments from 5 individuals. > > As one of the AC shepards for this proposal I would appreciate > any Last Call comments you may have on this Draft Policy, > even if it is simply that you support the policy as written. > > The text of this Draft Policy changed significantly from the > version discussed on the floor at Dearborn, so please take a > moment and read it carefully including the Rationale. > > Thank you, > > And finally in the spirit of the upcoming holidays; > > Best wishes to you and yours; > Peace on Earth, and; > THE UNIVERSAL ADOPTION OF IPv6. :) > > > On 24 Nov 2009 Member Services wrote: > > > The ARIN Advisory Council (AC) met on 19 November and decided to > > send a revised version of the following draft policy to last call: > > > > Draft Policy 2009-8: Equitable IPv4 Run-Out > > > > Feedback is encouraged during this last call period. All > comments should > > be provided to the Public Policy Mailing List. This last call will > > expire on 10 December 2009. After last call the AC will > conduct their > > last call review. > > > > The draft policy text is below and available at: > > https://www.arin.net/policy/proposals/ > > > > The ARIN Policy Development Process is available at: > > https://www.arin.net/policy/pdp.html > > > > Regards, > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > > > Draft Policy 2009-8 > > Equitable IPv4 Run-Out > > > > Version/Date: 24 November 2009 > > > > Policy statement: > > > > Rename NRPM 4.2.4.3; > > > > 4.2.4.3 Subscriber Members Less Than One Year > > > > Replace NRPM 4.2.4.4 with; > > > > 4.2.4.4 Subscriber Members After One Year > > > > After an organization has been a subscriber member of ARIN > for one year, > > they may choose to request up to a 12 month supply of IP addresses. > > > > When ARIN receives its last /8, by IANA implementing > section 10.4.2.2, > > the length of supply that an organization may request will > be reduced. > > An organization may choose to request up to a 3 month supply of IP > > addresses. > > > > This reduction does not apply to resources received via > section 8.3. An > > organization receiving a transfer under section 8.3 may continue to > > request up to a 12 month supply of IP addresses. > > > > Rationale: > > > > This policy is intended to ensure an equitable distribution of IPv4 > > resources as run-out of the ARIN free pool occurs. This is > achieved by > > changing section 4.2.4.4 of the NRPM to reduce the length > of supply of > > IPv4 resources that may be requested when the IANA free > pool runs-out. > > Equity is accomplished by reducing the window that an advantage or > > disadvantage can exist between competitors, that will be > created when > > one competitor receives a final allocation just before run-out and > > another competitor does not. > > > > Further this policy ensures equity between incumbent > resource holders > > and new entrants by providing the same length of supply for > each as the > > ARIN free pool runs out. This eliminates a potential bias toward > > incumbent resource holders that is created as a result of > ARIN free pool > > run-out interacting with resource allocation slow start for > new entrants > > in current policy. > > > > This policy is similar to ideas in RIPE policy proposal 2009-03 > > (http://www.ripe.net/ripe/policies/proposals/2009-03.html), > and has been > > adapted by discussion and for use within the ARIN region. > > > > This policy is intended to be independent of other policies > or proposals > > to reserve address space for IPv6 transition or other > purposes. It is > > not intended to limit Transfers to Specified Recipients per > section 8.3 > > of the NRPM. > > > > This draft contains the elements that there seems to have been the > > largest consensus for on the floor of ARIN XXIV Public > Policy Meeting in > > Dearborn, Michigan. Further, there was a strong preference that no > > changes be triggered until IANA free pool run-out. > > > > Timetable for implementation: Immediate > > > =============================================== > David Farmer Email:farmer at umn.edu > Office of Information Technology > Networking & Telecomunication Services > University of Minnesota Phone: 612-626-0815 > 2218 University Ave SE Cell: 612-812-9952 > Minneapolis, MN 55414-3029 FAX: 612-626-1818 > =============================================== > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From tedm at ipinc.net Tue Dec 1 16:36:14 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 01 Dec 2009 13:36:14 -0800 Subject: [arin-ppml] Apology requested from Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: References: Message-ID: <4B158C4E.8010503@ipinc.net> Chris Engel wrote: > >> Most of the claims they have made against me are not only absurd - they are unreal. >> >> I have in my collection correspondence and audio recordings in which they claim I'm an alien. > Thats alien as in extraterrestrial. > > Clearly that shows thier loss of touch with reality. EVERYONE on the internet knows that the aliens are merely a front for the Knights Templar except for a brief period in '99 when they were a front for Cthulhu. > Wasn't that during the "all your base are belong to us" period? Ted > > Christopher Engel > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From marty at akamai.com Tue Dec 1 16:43:09 2009 From: marty at akamai.com (Martin Hannigan) Date: Tue, 1 Dec 2009 16:43:09 -0500 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out - Last Call In-Reply-To: <4B0C074D.9020608@arin.net> References: <4B0C074D.9020608@arin.net> Message-ID: I support this policy as written. -M< On Nov 24, 2009, at 11:18 AM, Member Services wrote: > The ARIN Advisory Council (AC) met on 19 November and decided to > send a revised version of the following draft policy to last call: > > Draft Policy 2009-8: Equitable IPv4 Run-Out > > Feedback is encouraged during this last call period. All comments > should > be provided to the Public Policy Mailing List. This last call will > expire on 10 December 2009. After last call the AC will conduct their > last call review. > > The draft policy text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy 2009-8 > Equitable IPv4 Run-Out > > Version/Date: 24 November 2009 > > Policy statement: > > Rename NRPM 4.2.4.3; > > 4.2.4.3 Subscriber Members Less Than One Year > > Replace NRPM 4.2.4.4 with; > > 4.2.4.4 Subscriber Members After One Year > > After an organization has been a subscriber member of ARIN for one > year, > they may choose to request up to a 12 month supply of IP addresses. > > When ARIN receives its last /8, by IANA implementing section 10.4.2.2, > the length of supply that an organization may request will be reduced. > An organization may choose to request up to a 3 month supply of IP > addresses. > > This reduction does not apply to resources received via section 8.3. > An > organization receiving a transfer under section 8.3 may continue to > request up to a 12 month supply of IP addresses. > > Rationale: > > This policy is intended to ensure an equitable distribution of IPv4 > resources as run-out of the ARIN free pool occurs. This is achieved by > changing section 4.2.4.4 of the NRPM to reduce the length of supply of > IPv4 resources that may be requested when the IANA free pool runs-out. > Equity is accomplished by reducing the window that an advantage or > disadvantage can exist between competitors, that will be created when > one competitor receives a final allocation just before run-out and > another competitor does not. > > Further this policy ensures equity between incumbent resource holders > and new entrants by providing the same length of supply for each as > the > ARIN free pool runs out. This eliminates a potential bias toward > incumbent resource holders that is created as a result of ARIN free > pool > run-out interacting with resource allocation slow start for new > entrants > in current policy. > > This policy is similar to ideas in RIPE policy proposal 2009-03 > (http://www.ripe.net/ripe/policies/proposals/2009-03.html), and has > been > adapted by discussion and for use within the ARIN region. > > This policy is intended to be independent of other policies or > proposals > to reserve address space for IPv6 transition or other purposes. It is > not intended to limit Transfers to Specified Recipients per section > 8.3 > of the NRPM. > > This draft contains the elements that there seems to have been the > largest consensus for on the floor of ARIN XXIV Public Policy > Meeting in > Dearborn, Michigan. Further, there was a strong preference that no > changes be triggered until IANA free pool run-out. > > Timetable for implementation: Immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From craig.finseth at state.mn.us Tue Dec 1 16:39:25 2009 From: craig.finseth at state.mn.us (Craig Finseth) Date: Tue, 1 Dec 2009 15:39:25 -0600 Subject: [arin-ppml] Apology requested from Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: <4B158C4E.8010503@ipinc.net> (message from Ted Mittelstaedt on Tue, 01 Dec 2009 13:36:14 -0800) References: <4B158C4E.8010503@ipinc.net> Message-ID: <200912012139.nB1LdPAb004802@inana.itg.state.mn.us> > Clearly that shows thier loss of touch with reality. EVERYONE on > the internet knows that the aliens are merely a front for the > Knights Templar except for a brief period in '99 when they were a > front for Cthulhu. Wasn't that during the "all your base are belong to us" period? No, all the bases always belonged to Cthulhu: we're just borrowing them. And, FWIW, Cthulhu him/her/itself is an alien alreay. Just a very tired one that you hope doesn't wake up (:-). Craig From sweeny at indiana.edu Tue Dec 1 16:55:55 2009 From: sweeny at indiana.edu (Brent Sweeny) Date: Tue, 01 Dec 2009 16:55:55 -0500 Subject: [arin-ppml] state educational networks In-Reply-To: References: Message-ID: <4B1590EB.7020801@indiana.edu> The question of statewide education networks has come up and been briefly addressed with regard to Minnesota; in fact, most of the states have them to some extent: thirty-nine (of 50, not 51 ;) ) of them are connected to the Internet2 network as "Sponsored Education Research Groups" (see http://k20.internet2.edu/about/segp). I'm certainly prejudiced, but I think they do a good job and usually provide better support than available commercial alternatives, who have different goals. Also, as indicated WRT Minnesota coverage varies, so contact the particular network for specifics. Since Michigan has also been mentioned in connection with GQHS, I should mention that the MERIT network does a great job of providing network connectivity to K-20 (and others) in the state of Michigan and there's no need to (claim to) reinvent that wheel. As far as I could see, GQHS would in Michigan as elsewhere have little or no justification for becoming any sort of *IR. I hope that information is helpful. Brent Sweeny, Indiana University From mksmith at adhost.com Tue Dec 1 16:58:39 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 1 Dec 2009 13:58:39 -0800 Subject: [arin-ppml] RE: Apology requestedfrom Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <4B155B59.6070606@ipinc.net><29A54911243620478FF59F00EBB12F4701B2753A@ex01.drtel.lan> Message-ID: <17838240D9A5544AAA5FF95F8D520316071DEA6E@ad-exh01.adhost.lan> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Christopher Mettin > Sent: Tuesday, December 01, 2009 12:22 PM > To: 'Brian Johnson'; arin-ppml at arin.net > Subject: Re: [arin-ppml] RE: Apology > requestedfrom Christopher Mettin and the Gymnasium Querfurt High School > > Well, to me charging a fee for a service is like selling a good. There > actually is no difference, just another way to express the same idea. > But to > remain politically correct, ARIN is not selling IP addresses, they are > allocating them to people against a fee. So that's the same with AOL > charging a fee for the usage of their greeting card service, they are > not > selling ecards! Wow, remind me to contact Cisco and let them know there is no difference between selling me a 6500 and a SmartNet contract. You should look at the difference between CAPEX and OPEX. > > As it seems the ground GQHS is on is its own region since no one (even > not > RIPE) feels responsible. Maybe I should ask IANA whether we can become > our > own RIR since the need / geographical size ratio appears to be the same > as > in any other RIR region. If you feel you meet the criteria then you should. > But I would like to try to amend the policy > though, > to make educational institutions eligible for a free allocation in the > ARIN > region, since we will open a new campus in Michigan (a state in ARIN's > region) next year. > > Hope that answers all of your questions, Brian. You should look through the archives for non-profit and education. You will find that the devil is in the details, and that the ARIN membership is very specific about defining organizations. You might be an educational institution, you might not. Also, right now you are not a member of the ARIN region, so this is really moot. When you are in Michigan give it another go. Regards, Mike -- Michael K. Smith - CISSP, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From tedm at ipinc.net Tue Dec 1 17:12:14 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 01 Dec 2009 14:12:14 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> Message-ID: <4B1594BE.1070004@ipinc.net> John Curran wrote: > On Dec 1, 2009, at 11:33 AM, Ted Mittelstaedt wrote: >> ... So, for LIRS that want to pee all over themselves, well then >> don't file SWIPS. In fact I ENCOURAGE IT STRONGLY because then all >> I have to do is null-route your ENTIRE AS, I don't even have to >> waste CPU cycles blocking just the obnoxious traffic from >> Wonkulating. > > Ted - > > Under this philosophical approach, what would ARIN's responsibilities > be with respect to an organization which files no SWIP's and runs no > rwhois service? > My $0.02 is that the current obligations are nothing. (assuming the org never again requests more numbering) > More specifically, if an organization is willing to accept the > incident/security response obligations implied by not showing > sub-delegations, is that "acceptable" until/unless the organization > needs to show utilization for an additional address block? (If so, > wouldn't it be best to update the NRPM to reflect this "optionality" > of SWIPs/rwhois data?) > Well, I come from the camp that would like to push ARIN to take a more activist role. Keep in mind that if all ARIN continues to do in the future is hand out IPv6, that once the Internet shifts over to IPv6 that ARIN isn't really going to have very much work to do other than maintaining the SWIPs, it's not like they won't have the time to do this. I frankly feel that the Internet is so critical to so many things nowadays that having LESS centralized world regulation over it is a Very Bad Thing. My original post on this topic was aimed at the 'anti-whois' crowd because I felt that the post from Danny on the 30th was a recycling of the old "well if nobody is filing SWIPS then I'm not going to so let's get rid of them" argument. I have seen that logic before and I thought I recognized it again, and I have to say that I believe my guess was right considering Danny's highly negative reaction to my pointing out the foolishness of not making SWIP data available. I know that the fundamental basis of the 'anti-whois' crowd is pure selfishness, it's the "I got my customers and you ain't gonna get 'em" and the ONLY argument that resonates with that primitive mindset is another appeal to selfish-self interest. Thus Danny's reaction when I pointed out that NOT filing SWIPS or Rwhois, -AND- NOT taking the responsibility for the results of NOT filing SWIPS or Rwhois (ie: doing the extra work of handling complaints, etc.) is that your going to irritate the rest of us and we will eventually get sick of your crap and cut you off. In the absence of global Internet leadership my feeling is that local country governments are going to move in to fill the void, and the Internet will move into a "Feudal" period where each country will enforce it's own laws on the part of the Internet that touches it's citizens. I suspect if that were to happen (and I think it would) you would have things like the Government of Saudi Arabia issuing arrest warrants for networking administrators of Verizon because some citizen in SA was looking at nudie pictures on a Verizon server that are legal in the US. Things could get very very ugly if this happened. Right now most of the world's governments are in serious denial about how much the Internet infrastructure affects their societies, and because of this are not exerting their authority much, and most Internet administrators seem to be under the impression things will stay this way. History suggests otherwise, however - just look at regulation of the radio frequency spectrum after the invention of radio, for example. The suggestion of adjusting the NRPM to reflect this optionality is a regressive "deregulation" move that I feel is moving in the opposite direction than what should really be happening. I'd rather see much more activist regulation of SWIPs and rwhois on sub-delegations, as I think that if the RIRs were very militant about enforcing the validity of the data in the whois/rwhois system, that this would convince the world's governments to refrain from issuing a bunch of contradictory regulations. Would you rather see each government require orgs to register SWIP equivalents with their own registries? Because that's probably what will happen if the RIRs let the Whois/Rwhois system go to pot. Ted > /John > > John Curran President and CEO ARIN > From geneb at deltasoft.com Tue Dec 1 17:12:58 2009 From: geneb at deltasoft.com (Gene Buckle) Date: Tue, 1 Dec 2009 14:12:58 -0800 (PST) Subject: [arin-ppml] Apology requested from Christopher Mettin and the Gymnasium Querfurt High School In-Reply-To: <20091201193308.GG63795@h216-235-12-172.host.egate.net> References: <874c02a20912010904w72cbe681o4a7ec7436080ac47@mail.gmail.com> <4B155B59.6070606@ipinc.net> <20091201193308.GG63795@h216-235-12-172.host.egate.net> Message-ID: On Tue, 1 Dec 2009, Vance Shipley wrote: > You've already got an original net.kook! > > http://www.tranquileye.com/magic/magic_stuff/Toronto_Net_loons.htm > <4chan> Taht iz teh awesum!!!1111!!! *snickers* g. From tedm at ipinc.net Tue Dec 1 17:15:21 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 01 Dec 2009 14:15:21 -0800 Subject: [arin-ppml] ARIN Audits (was SWIPs & IPv6) In-Reply-To: <87d69953e79e207cafc2bf6e93aea4d9@academ.com> References: <87d69953e79e207cafc2bf6e93aea4d9@academ.com> Message-ID: <4B159579.9090802@ipinc.net> Stan Barber wrote: > John Curran writes: >> Stan - >> >> The resource review policy is relatively new, but ARIN has indeed been >> >making use of when we see strong indication of fraudulent activities or >> >related misappropriation of number resources. >> >> While in theory resource review could be performed for any reason >> >(including lax updates to SWIP information), it has been our practice to >> >only make use of it where that the community is potentially being deprived >> >of the use of numbering resources. > > Thanks, John. > > Are these activities documented somewhere for community review? I am just > trying to understand the criteria that would warrant such a review. I think > I understand what you mean by "fraudulent activities or related > misappropriation of number resources," but have a concrete example or two > would help crystallize it for me. > > For example, would a history of bad record keeping (inaccurate SWIPs or > Rwhois entries that usage that may have initially been correct, but has > subsequently not been properly maintained) meet the criteria? I would guess > that it would not since it is more negligent than fraudulent. Of course, > rampant negligence of an entity that holds a large bank of numbering > resources and continues to ask for more would meet the criteria of > potentially depriving the community of the use of numbering resources. That > alone must not be enough since there are holders of Class A and B space > that might be better utilized if returned for reallocation. > > Is it also safe to assume that this only relates to space that ARIN itself > has allocated and not to space allocated before the RIR infrastructure was > on-line? > > [Aside to others: I really have always been interested in this stuff, but > only recently have been able to get re-engaged in ARIN activities, so > please bear with me while I get some of the questions I have longing to ask > on the table. I apologize in advance if this is self-indulgent and > distracting.] > > STAN > Stan, this kind of question is kind of like asking the local police department what their criminal profiling criteria is. My hope is that if ARIN chooses to answer you, that they do so privately. Ted > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From marty at akamai.com Tue Dec 1 17:56:16 2009 From: marty at akamai.com (Martin Hannigan) Date: Tue, 1 Dec 2009 17:56:16 -0500 Subject: [arin-ppml] ARIN Audits (was SWIPs & IPv6) In-Reply-To: <4B159579.9090802@ipinc.net> References: <87d69953e79e207cafc2bf6e93aea4d9@academ.com> <4B159579.9090802@ipinc.net> Message-ID: On Dec 1, 2009, at 5:15 PM, Ted Mittelstaedt wrote: [ clip ] > > > Stan, this kind of question is kind of like asking the local police > department what their criminal profiling criteria is. My hope is that > if ARIN chooses to answer you, that they do so privately. > > Ted > My accountants know what will flag me for an IRS audit. My attorney knows what will inflame a judge. There's nothing wrong with having some published triggers for audits. It's a deterrent to bad actors in my humble opinion and could help guide people towards doing things right i.e. "not having updated swip data .." or "too many subsequent requests in a short period.." etc. -M< From kkargel at polartel.com Tue Dec 1 18:01:37 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 1 Dec 2009 17:01:37 -0600 Subject: [arin-ppml] ARIN Audits (was SWIPs & IPv6) In-Reply-To: <4B159579.9090802@ipinc.net> References: <87d69953e79e207cafc2bf6e93aea4d9@academ.com> <4B159579.9090802@ipinc.net> Message-ID: <8695009A81378E48879980039EEDAD2869DCBF45@MAIL1.polartel.local> > > Stan, this kind of question is kind of like asking the local police > department what their criminal profiling criteria is. My hope is that > if ARIN chooses to answer you, that they do so privately. > > Ted Sorry Ted, I have to disagree on this one. One of the things I love about ARIN is the transparency. Let's publish everything and we don't have to wonder. If one has to keep something hidden then there must be something wrong with it. This isn't a trade secret, we're not in competition. From farmer at umn.edu Tue Dec 1 18:32:08 2009 From: farmer at umn.edu (David Farmer) Date: Tue, 01 Dec 2009 17:32:08 -0600 Subject: [arin-ppml] ARIN Audits (was SWIPs & IPv6) In-Reply-To: References: <87d69953e79e207cafc2bf6e93aea4d9@academ.com> <4B159579.9090802@ipinc.net> Message-ID: <4B15A778.6050502@umn.edu> Martin Hannigan wrote: > > On Dec 1, 2009, at 5:15 PM, Ted Mittelstaedt wrote: > > > [ clip ] >> >> >> Stan, this kind of question is kind of like asking the local police >> department what their criminal profiling criteria is. My hope is that >> if ARIN chooses to answer you, that they do so privately. >> >> Ted >> > > > My accountants know what will flag me for an IRS audit. My attorney > knows what will inflame a judge. Realize that is one of the many things you are paying them for, their expert opinion on those issues and where the boundaries are, and what is over line and what is not. > There's nothing wrong with having some > published triggers for audits. It's a deterrent to bad actors in my > humble opinion and could help guide people towards doing things right > i.e. "not having updated swip data .." or "too many subsequent requests > in a short period.." etc. Yes, there is published standards for the items you mention above and ARIN should do the same. However, if it was as simple as following the published standards you really wouldn't need an accountant or a lawyer, we all know its not that simple. Also, as John pointed out the resource review policy is relatively new. The tax code and the legal system have many decades and even centuries of precedents to base things on, I think a little patience is in order on this one. If the NRPM ever gets as bad as the US tax code, then maybe we should just unplug the Internet. ;) > -M< > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From marty at akamai.com Tue Dec 1 18:38:01 2009 From: marty at akamai.com (Martin Hannigan) Date: Tue, 1 Dec 2009 18:38:01 -0500 Subject: [arin-ppml] ARIN Audits (was SWIPs & IPv6) In-Reply-To: <4B15A778.6050502@umn.edu> References: <87d69953e79e207cafc2bf6e93aea4d9@academ.com> <4B159579.9090802@ipinc.net> <4B15A778.6050502@umn.edu> Message-ID: On Dec 1, 2009, at 6:32 PM, David Farmer wrote: > Martin Hannigan wrote: > > > > On Dec 1, 2009, at 5:15 PM, Ted Mittelstaedt wrote: > > > > > > [ clip ] > >> > >> > >> Stan, this kind of question is kind of like asking the local police > >> department what their criminal profiling criteria is. My hope is > that > >> if ARIN chooses to answer you, that they do so privately. > >> > >> Ted > >> > > > > > > My accountants know what will flag me for an IRS audit. My attorney > > knows what will inflame a judge. > > Realize that is one of the many things you are paying them for, their > expert opinion on those issues and where the boundaries are, and > what is > over line and what is not. > David, I think most of us realize a lot more than you give us credit for. Why should I have to pay someone to help me navigate the ARIN NRPM? In fact, it's already complicated enough that people _do_ pay others to help them navigate it. Food for thought. Best Regards, -M< From danny at tcb.net Tue Dec 1 18:38:38 2009 From: danny at tcb.net (Danny McPherson) Date: Tue, 1 Dec 2009 16:38:38 -0700 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B156C03.1090204@ipinc.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <1BF286A2-3699-464B-AD26-35F7D3CBFD42@tcb.net> <4B156C03.1090204@ipinc.net> Message-ID: On Dec 1, 2009, at 12:18 PM, Ted Mittelstaedt wrote: > > Nope, that's not the way things work on the Internet and there > are many examples. If I'm large then I can do as I please, for > example when Verizon.net instituted "call backs" in e-mail it > pissed off a lot of customers, and some left, but Verizon ignored > their complaints and so everyone else on the Internet ended up > having to make sure their e-mail systems were compatible. I was referring to YOU, not Verizon :-) > If I'm small then I can do as I please as well unless the > other network I don't like is large, like a Google or some such. Precisely my point (but far from what I'd intended to glean from my original query), glad you grok it.. > Sorry you don't like this, but this is how the world really > works. Thanks for your sharing your perspective of operational mastery, guess I should get a bit more experience before asking questions ;-) -danny From danny at tcb.net Tue Dec 1 18:48:25 2009 From: danny at tcb.net (Danny McPherson) Date: Tue, 1 Dec 2009 16:48:25 -0700 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B1594BE.1070004@ipinc.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> Message-ID: <4201421D-9940-4EF2-90FB-EC0657515B1C@tcb.net> On Dec 1, 2009, at 3:12 PM, Ted Mittelstaedt wrote: > > My original post on this topic was aimed at the 'anti-whois' crowd because I felt that the post from Danny on the 30th was a recycling of > the old "well if nobody is filing SWIPS then I'm not going to so let's > get rid of them" argument. I have seen that logic before and I thought I > recognized it again, and I have to say that I believe my guess was > right considering Danny's highly negative reaction to my pointing > out the foolishness of not making SWIP data available. For the record, you're mistaken, I had zero opinion on this topic beyond trying to understand what the issues were. I've gleaned a few useful insights (e.g., the abuse desk to the ISP that didn't create the SWIPs). As for my "highly negative reaction", I actually thought your response comical - but you senselessly diluted your point trying to be clever. I've heard your opinion, I'd like to continue to hear form other folks as well.. Kind regards, -danny From mysidia at gmail.com Tue Dec 1 19:17:10 2009 From: mysidia at gmail.com (James Hess) Date: Tue, 1 Dec 2009 18:17:10 -0600 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out - Last Call In-Reply-To: <4B0C074D.9020608@arin.net> References: <4B0C074D.9020608@arin.net> Message-ID: <6eb799ab0912011617i7cf23418t8d0926e7fd96c66@mail.gmail.com> On Tue, Nov 24, 2009 at 10:18 AM, Member Services wrote: > The ARIN Advisory Council (AC) met on 19 November and decided to > send a revised version of the following draft policy to last call: > > ?Draft Policy 2009-8: Equitable IPv4 Run-Out I support the policy as written. It is a small step in the direction of smoothing the run-out, so that the time of exhaustion will be more predictable. I believe it is a safe step in the right direction. -- -J From scottleibrand at gmail.com Tue Dec 1 18:57:51 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 01 Dec 2009 15:57:51 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4201421D-9940-4EF2-90FB-EC0657515B1C@tcb.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> <4201421D-9940-4EF2-90FB-EC0657515B1C@tcb.net> Message-ID: <4B15AD7F.40700@gmail.com> Danny McPherson wrote: > I've gleaned a > few useful insights (e.g., the abuse desk to the ISP that didn't > create the SWIPs). > > I've heard your opinion, I'd like to continue to hear form other > folks as well.. As others have mentioned, SWIP/rwhois is valuable for lots of reasons. Some, but by no means all, of those benefits accrue to the party maintaining the data. There are significant externalities (benefits to other parties), so it makes sense for us to encourage maintenance of accurate WHOIS data. One way we do that today, tying additional ISP assignments to accurate WHOIS data, will become less of an incentive when additional assignments are few and far between. I think it remains to be seen whether the other benefits are sufficient to maintain a sufficient level of participation in keeping data up-to-date, but with the delegation-of-responsibility benefits already outlined, and some possible tie-ins with routing data (rpki etc.), I think we have a good chance of success. We should keep an eye out for stale data, though, so we can discuss additional incentives if the existing ones prove insufficient. -Scott From scottleibrand at gmail.com Tue Dec 1 20:37:19 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 01 Dec 2009 17:37:19 -0800 Subject: [arin-ppml] Post-exhaustion IPv4 policy (Proposal 97. Waiting List for Unmet IPv4 Requests) In-Reply-To: <3c3e3fca0910291617p1e135dadoa0480203bbbf702a@mail.gmail.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0D048.7080608@gmail.com> <3c3e3fca0910221503y115d6d8du5f0a4a41d6ff7f16@mail.gmail.com> <4AE0D906.60105@gmail.com> <3c3e3fca0910221525v546aa3c9l461c5469c3ab5aa3@mail.gmail.com> <4AEA1C00.30408@gmail.com> <3c3e3fca0910291617p1e135dadoa0480203bbbf702a@mail.gmail.com> Message-ID: <4B15C4CF.7060301@gmail.com> William Herrin wrote: > On Thu, Oct 29, 2009 at 6:49 PM, Scott Leibrand wrote: > >> William Herrin wrote: >> >>> On Thu, Oct 22, 2009 at 6:13 PM, Scott Leibrand >>> wrote: >>> >>>> "Repeated requests, in a manner that would >>>> circumvent 4.1.6, are not allowed." The idea, of course, is to give ARIN >>>> staff leeway to use their excellent fraud detection skills, combined with >>>> operational procedures that can be adjusted as needed. >>>> >>>> >>> Staff will be making such decisions under intense scrutiny. Any >>> judgment they're forced to exercise will tend to be the most lenient >>> the policy allows. Which is to say: no restriction on repeat requests >>> at all. >>> >>> Giving staff discretion can be a good thing if done with appropriate >>> checks, but you also have to give them a policy vehicle that validates >>> and reinforces that discretion. In other words, it's better to say, >>> "You can have 1 a day but staff can waive the requirement" than "you >>> can have as many as you want but staff can limit you to 1 a day." >>> >>> >> Understood. Do you have any specific suggestions as to how we could modify >> proposal 97 to codify a restriction, while still giving staff leeway to make >> exception for anyone who is clearly not trying to bend any rules? >> > > Tough question. How about something like a 1-year waiting period > between requests but the BoT is empowered to waive the waiting period > by majority vote for any individual requests they deem meritorious by > whatever criteria. Of course waiving the waiting period doesn't grant > the request; it just means that staff can consider it before the > waiting period expires. Bill, I'm just now coming back to this and taking another hard look at it. What if I change that sentence to read: Repeated requests, in a manner that would circumvent 4.1.6, are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document an unforeseen change in circumstances since their last request. I chose 3 months because it looks like 2009-8 is going to change 4.2.4.4 from 12 months to 3 months upon IANA exhaustion. Thoughts? -Scott From mcr at sandelman.ca Tue Dec 1 21:22:43 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 01 Dec 2009 21:22:43 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B1594BE.1070004@ipinc.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> Message-ID: <14500.1259720563@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Ted" == Ted Mittelstaedt writes: >> More specifically, if an organization is willing to accept the >> incident/security response obligations implied by not showing >> sub-delegations, is that "acceptable" until/unless the >> organization needs to show utilization for an additional address >> block? (If so, wouldn't it be best to update the NRPM to reflect >> this "optionality" of SWIPs/rwhois data?) >> Ted> Well, I come from the camp that would like to push ARIN to take Ted> a more activist role. Keep in mind that if all ARIN continues Ted> to do in the future is hand out IPv6, that once the Internet Ted> shifts over to IPv6 that ARIN isn't really going to have very Ted> much work to do other than maintaining the SWIPs, it's not like Ted> they won't have the time to do this. I frankly feel that the Ted> Internet is so critical to so many things nowadays that having Ted> LESS centralized world regulation over it is a Very Bad Thing. So, not just handing out IPv6, but running a RPKI (the thing that anchors SIDR certificates...) as well. It's totally different technical work, but it's structurally similar to what happens now. But consider what happens if you do not update your SWIP data... your routing certificate expires, and you go offline! {I agree with Ted's analysis about feudal situation} Consider what the "feudal" governments could do with the above kind of power? - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSxXPcYCLcPvd0N1lAQIoHwf+OKCCfTBCCBpu7GpmiiwJkyLOd18ad6CE BmYKd4rupnhYOzcLbhJNLpNfoUdzR065H6tKNNXC8Jti2SiD6W23hAq/30xan3HM KCJLlWsTyHcZU/S7g1secWbbjlOQOqpz3iaMiH1JWMC58/PQHRpPmKWrQxImE7iT wAgZl8RxriTZGmxQRIxDhTWbvQ8jR8w1Oxgql/F8VllR78bDz1qE0C95a59tSzcN hP6vF6d59663LK4Q2SMdhgpYe+8grFq851SaaD7WFxqnj8+YEXJQjmoGrCwuvw2d KKcAT7Y/9i/rFRSdOqBCTDMRNy8+cgH0bGIMvpkU/DfCBBwnZxZLfA== =4YKR -----END PGP SIGNATURE----- From baptista at publicroot.org Tue Dec 1 22:25:58 2009 From: baptista at publicroot.org (Joe Baptista) Date: Tue, 1 Dec 2009 22:25:58 -0500 Subject: [arin-ppml] I ask the members of this list to please not ban Christopher Mettin Message-ID: <874c02a20912011925o5a0812d6jb6a3a74232843052@mail.gmail.com> There has been discussion concerning the banning Christopher Mettin, the representative of the Gymnasium Querfurt High School, from participating on this list. I ask the members who proposed banning Christopher or support the action to please kindly withdraw their requests. Gentlemen, Ladies ... we all remember what it was like to be young. Jubilation, revolution and beer. I believe Chris deserves a second chance. I can gurantee he has calmed down. He is in private communication with me. He is very angry and so far has threatened to disconnect my twitter account. He may accomplish this - he managed to disconnect my wordpress account. But the point is he is directing his anger at me privately where it belongs and it's my pleasure to make that possible. Psychiatry 101. I also don't think Chris is in any way a scammer. I consider him just another victim of Herman Xennt. He's a kid who is trying to make a difference and he is stuck in a farce. One of our members mentioned this story reads like a screen play. If you only knew. Many people have their life ssaving in this farce - many others their reputations. Right now I'm trying to encourage Chris to pick up the phone and call Martijn Burger the chair of INAIC and get his facts straight. I don't think he wants to do that. Sometimes it is hard to hear the truth when one has put their schools reputation on the line. Can you imagine how the poor boy feels. In any case those here knights of usenet will be happy to know the troll has been captured and I'll feed him privately from now on saving you the bother. And if the troll escapes we'll all be the first to know. But seriously - I think Chris has learned his lesson. A few of you have jabbed him in a very good natured and kindly way. And I appreciate the kindness everyone has shown Chris less the jabs. But this is a teenager and teenagers feel those jabs a lot more harshly then us ol farts and even some of the adults here. Am I right? I think Chris is ready to follow the rules. He is a bright kid and he has good ideas. It's also nice to have young people involved and interested in what we do here. Am I right? I think he is capable of making good contributions to the issues discussed here. So please I beg you all kindly let Chris stay. We all make mistakes in life and forgiveness is divine. Am I right? submitted with respect to the ARIN Community joe baptista -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Tue Dec 1 22:58:20 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 01 Dec 2009 19:58:20 -0800 Subject: [arin-ppml] Professionalism Message-ID: <4B15E5DC.3080109@gmail.com> Many thanks to all of you who have shown such a high degree of professionalism in your recent responses on this list. It's gratifying to see so many people willing to help out a complete stranger with unorthodox ideas, and remain so professional even in the face of personal attacks. It's not always fun to read, but I'm glad to see how resilient this community is. Thanks again, Scott From spiffnolee at yahoo.com Wed Dec 2 10:28:07 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Wed, 2 Dec 2009 07:28:07 -0800 (PST) Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B1594BE.1070004@ipinc.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> Message-ID: <499382.63505.qm@web63302.mail.re1.yahoo.com> John Curran wrote: > > Under this philosophical approach, what would ARIN's responsibilities > >be with respect to an organization which files no SWIP's and runs no > > rwhois service? Ted responded: > My $0.02 is that the current obligations are nothing. (assuming the org > never again requests more numbering) "No obligation" might mean not accepting requests to change POC data, or update ip6.arpa records, or maintaining their PPML subscription, or honoring their vote for Board and AC, or maintaining the uniqueness of their allocation, or retaining their WHOIS entry. How far should ARIN not go? Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Wed Dec 2 13:53:24 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 02 Dec 2009 10:53:24 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4201421D-9940-4EF2-90FB-EC0657515B1C@tcb.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> <4201421D-9940-4EF2-90FB-EC0657515B1C@tcb.net> Message-ID: <4B16B7A4.6080901@ipinc.net> Danny McPherson wrote: > On Dec 1, 2009, at 3:12 PM, Ted Mittelstaedt wrote: >> My original post on this topic was aimed at the 'anti-whois' crowd because I felt that the post from Danny on the 30th was a recycling of >> the old "well if nobody is filing SWIPS then I'm not going to so let's >> get rid of them" argument. I have seen that logic before and I thought I >> recognized it again, and I have to say that I believe my guess was >> right considering Danny's highly negative reaction to my pointing >> out the foolishness of not making SWIP data available. > > For the record, you're mistaken, I had zero opinion on this topic > beyond trying to understand what the issues were. Danny, I apologize for assuming that you had an iron in the fire on this. The last time this topic came up on the list the original poster definitely had an axe to grind. > I've gleaned a > few useful insights (e.g., the abuse desk to the ISP that didn't > create the SWIPs). > > As for my "highly negative reaction", I actually thought your > response comical - but you senselessly diluted your point trying > to be clever. > Well, it isn't "my" point, as many other administrators act similarly to what I described. But, keep in mind that if you honestly have no POV either way on this issue then of course your going to think it's diluted, just as the man watching an arrow fly by, aimed at some other target, thinks "Oh that's kind of interesting" I'm not aiming at you, I'm aiming at the people who want to get rid of the whois database, and institute the same kind of butchery to it that the DNS registrars have permitted to domain name contacts (ie: so-called "privacy" listings that do nothing other than to allow criminals to hide themselves) Ted > I've heard your opinion, I'd like to continue to hear form other > folks as well.. > > Kind regards, > > -danny > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jcurran at arin.net Wed Dec 2 14:09:11 2009 From: jcurran at arin.net (John Curran) Date: Wed, 2 Dec 2009 14:09:11 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B16B7A4.6080901@ipinc.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> <4201421D-9940-4EF2-90FB-EC0657515B1C@tcb.net> <4B16B7A4.6080901@ipinc.net> Message-ID: <0AD286C1-F912-4C34-B0BF-B1E900FF7D4C@arin.net> Ted - So do you believe that ISP's will maintain their IPv6 delegations with the same level of accuracy as IPv4 today, and if not, do you think the loss of this data will impact operations? /John On Dec 2, 2009, at 10:53 AM, Ted Mittelstaedt wrote: > Danny McPherson wrote: >> On Dec 1, 2009, at 3:12 PM, Ted Mittelstaedt wrote: >>> My original post on this topic was aimed at the 'anti-whois' crowd because I felt that the post from Danny on the 30th was a recycling of >>> the old "well if nobody is filing SWIPS then I'm not going to so let's >>> get rid of them" argument. I have seen that logic before and I thought I >>> recognized it again, and I have to say that I believe my guess was >>> right considering Danny's highly negative reaction to my pointing >>> out the foolishness of not making SWIP data available. >> For the record, you're mistaken, I had zero opinion on this topic beyond trying to understand what the issues were. > > Danny, I apologize for assuming that you had an iron in the > fire on this. The last time this topic came up on the list > the original poster definitely had an axe to grind. From sob at academ.com Wed Dec 2 14:41:39 2009 From: sob at academ.com (Stan Barber) Date: Wed, 02 Dec 2009 13:41:39 -0600 Subject: [arin-ppml] ARIN Audits Message-ID: You write: >...the resource review policy is relatively new...I think a little >patience is in order on this one. I apologize. I was not intending to imply I was impatient. I was trying to seek clarity. Perhaps there needs to be a proposal to refine the resource review policy to help drive clarity. If so, is this not the place to discuss things like this? Would it help to make a straw man proposal to drive such a discussion? From kkargel at polartel.com Wed Dec 2 14:42:47 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 2 Dec 2009 13:42:47 -0600 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B16B7A4.6080901@ipinc.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> <4201421D-9940-4EF2-90FB-EC0657515B1C@tcb.net> <4B16B7A4.6080901@ipinc.net> Message-ID: <8695009A81378E48879980039EEDAD287B279F5E@MAIL1.polartel.local> I disagreed with Ted yesterday so naturally I have to agree with him strongly today. We need whois data that allows us to get in touch with a real person in short order. More than a few times in my time as an internet professional I have had to contact network administrators whose networks were interfering with mine, whether it was incorrect BGP, rogue malfunctioning network interfaces, botnet or other infestations, or any number of other issues. Most of the incidents were innocent, normal malfunctions or human error. A couple were due to malicious actions by enduser/customers. In any case when these things happen waiting days for a response from an anonymized and infrequently checked email is not an acceptable solution. Some times one needs a name and a telephone number. In some cases having to contact the top level provider and then work my way down through a series of book keepers to get to a network operator has extended problem times. I am not saying IPv6 info will be any better than IPv4 info, but I hope it will not be worse. Kevin > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Wednesday, December 02, 2009 12:53 PM > To: Danny McPherson > Cc: arin ppml > Subject: Re: [arin-ppml] SWIPs & IPv6 > > Danny McPherson wrote: > > On Dec 1, 2009, at 3:12 PM, Ted Mittelstaedt wrote: > >> My original post on this topic was aimed at the 'anti-whois' crowd > because I felt that the post from Danny on the 30th was a recycling of > >> the old "well if nobody is filing SWIPS then I'm not going to so let's > >> get rid of them" argument. I have seen that logic before and I thought > I > >> recognized it again, and I have to say that I believe my guess was > >> right considering Danny's highly negative reaction to my pointing > >> out the foolishness of not making SWIP data available. > > > > For the record, you're mistaken, I had zero opinion on this topic > > beyond trying to understand what the issues were. > > Danny, I apologize for assuming that you had an iron in the > fire on this. The last time this topic came up on the list > the original poster definitely had an axe to grind. > > > I've gleaned a > > few useful insights (e.g., the abuse desk to the ISP that didn't > > create the SWIPs). > > > > As for my "highly negative reaction", I actually thought your > > response comical - but you senselessly diluted your point trying > > to be clever. > > > > Well, it isn't "my" point, as many other administrators act similarly to > what I described. But, keep in mind that if you honestly have no POV > either way on this issue then of course your going to think it's > diluted, just as the man watching an arrow fly by, aimed at some > other target, thinks "Oh that's kind of interesting" > > I'm not aiming at you, I'm aiming at the people who want to get > rid of the whois database, and institute the same kind of > butchery to it that the DNS registrars have permitted to domain name > contacts (ie: so-called "privacy" listings that do nothing other than to > allow criminals to hide themselves) > > Ted > > > I've heard your opinion, I'd like to continue to hear form other > > folks as well.. > > > > Kind regards, > > > > -danny > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From sob at academ.com Wed Dec 2 14:44:04 2009 From: sob at academ.com (Stan Barber) Date: Wed, 02 Dec 2009 13:44:04 -0600 Subject: [arin-ppml] ARIN Audits (was SWIPs & IPv6) In-Reply-To: <4B159579.9090802@ipinc.net> References: <87d69953e79e207cafc2bf6e93aea4d9@academ.com> <4B159579.9090802@ipinc.net> Message-ID: On 4:15 pm 12/01/09 Ted Mittelstaedt wrote: > Stan, this kind of question is kind of like asking the local police > department what their criminal profiling criteria is. My hope is that > if ARIN chooses to answer you, that they do so privately. > > Ted Oh. I didn't know that. I am trying to find a clear message what is adequate and what is not. I am not trying to reveal any secret stuff. From tedm at ipinc.net Wed Dec 2 15:43:51 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 02 Dec 2009 12:43:51 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <499382.63505.qm@web63302.mail.re1.yahoo.com> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> <499382.63505.qm@web63302.mail.re1.yahoo.com> Message-ID: <4B16D187.6060104@ipinc.net> Lee Howard wrote: > > > John Curran wrote: > > > Under this philosophical approach, what would ARIN's responsibilities > > >be with respect to an organization which files no SWIP's and runs no > > > rwhois service? > > Ted responded: > > My $0.02 is that the current obligations are nothing. (assuming the org > > never again requests more numbering) > > "No obligation" might mean not accepting requests to change POC data, > or update ip6.arpa records, or maintaining their PPML subscription, or > honoring their vote for Board and AC, or maintaining the uniqueness of > their allocation, or retaining their WHOIS entry. How far should ARIN > not go? > > Lee > I was speaking of obligations with respect to SWIPS. If the org continues to pay it's yearly fee then that is what continues to guarantee uniqueness of their allocation. THe problem is that (in my opinion) the language in the RSA on maintaining the accuracy of the Whois/RWhois data is far too "loose" Here's the relevant section: https://www.arin.net/resources/agreements/rsa.pdf 5b Applicant is responsible for the timely and accurate maintenance of directory services data (WHOIS), as well as data concerning any organization to which it further sub-delegates number resources. The problem as I see it is that this is so vague as to create a huge loophole. Suppose the org starts out in year 2010 with an IPv4 allocation that is 80% full. Over the next decade they move their customers to IPv6, and they move more of their new customers to IPv4 NAT, so over the decade utilization of that IPv4 block falls to 60%. Now, obviously there's going to be a lot of shifting around of use WITHIN the IPv4 block they have - but lets say that the org has a lot of admins in it that make mistakes and over the years the SWIPS get more and more stale and obsolete. Now, the problem here is that the org isn't DELIBERATELY going out and violating section 5b, it's just accumulated mistakes. At what point does ARIN state the org is in violation of section 5b? When the error rate is .01%? A strict reading of the RSA would say that this would be the point - but no court in the land would uphold civil action by ARIN against the org since it's not a reasonable error rate - GAAP and GAS allow something like a .2% error rate for corporate accounting filings, for example. So, the question becomes, at what point does the error rate no longer be "timely and accurate"? Since this isn't accounting data, it's WHOIS data, would GAAP/GAS even apply in a legal sense? And the larger question is, what constitutes "maintenance of directory services data...data concerning any organization to which it further sub-delegates" What if a sub-delegate org makes the ISP sign a form for the ISP to act as the sub-delegates "agent", so the ISP replaces the sub-delegate SWIP with one of it's own? Under the law the ISP that does this is considered "part" of the org so they can substitute SWIP data with their own and remain within the "data concerning any organization to which it further sub-delegates" rule I think - yes that's skating a bit on thin ice, but I've seen that argument used here before. And furthermore, reread Section 5b, there's a gigantic loophole in it that most people miss. The way the section is worded, all the org has to do is make sub-delegation information available to ARIN, and NOT to the WHOIS database - the phrase "as well as" creates 2 clauses within that section, they are: Applicant is responsible for the timely and accurate maintenance of directory services data (WHOIS), Applicant is responsible for the timely and accurate maintenance of data concerning any organization to which it further sub-delegates number resources. [to the holder of the RSA< ie: ARIN] To eliminate THAT loophole the section should be rewritten something like: Responsibility for Directory Services Data. Applicant is responsible for the timely and accurate maintenance of data within the directory service (WHOIS), including but not limited to it's POC's, any organization to which it further sub-delegates number resources, and other WHOIS data as applicable... (Obviously you would probably want to check with your lawyers as to their opinion, but I think they would agree that section 5b is rather weaker than the rest of the RSA) Ted From tedm at ipinc.net Wed Dec 2 16:47:21 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 02 Dec 2009 13:47:21 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <0AD286C1-F912-4C34-B0BF-B1E900FF7D4C@arin.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> <4201421D-9940-4EF2-90FB-EC0657515B1C@tcb.net> <4B16B7A4.6080901@ipinc.net> <0AD286C1-F912-4C34-B0BF-B1E900FF7D4C@arin.net> Message-ID: <4B16E069.8080209@ipinc.net> John Curran wrote: > Ted - > > So do you believe that ISP's will maintain their IPv6 delegations > with the same level of accuracy as IPv4 today, It depends. ISP's that see value in SWIP/Rwhois data would likely be including that in RFP's for stuff like new IP management software, etc. those would probably be continuing to be as accurate as they always have been. I think most large ISP's (ie: national or global in size) are already in this boat and I don't think they will change much. I'm not sure how many small/medium ISPs out there are using commercial IP management software, and of the ones who are, how many of those would be willing to pressure their vendor for a new version that supports IPv6 and SWIP filing. For the ones who aren't using the commercial software, the most common/popular free IP Address management software out there in use is IPPlan, and this does NOT support IPv6 and almost certainly NEVER will. IPPlan can be set to generate SWIPS. The only free replacement out there that supports IPv6 is HaCI and it does not auto-generate SWIPS. I think also a lot of ISP's are still using a spreadsheet and manually filing SWIPS, those are the ones most likely not to remain accurate. And of course, the ISP's deliberately thwarting the Whois database already (to protect spammers and other criminals) are going to continue to do as they have always done. > and if not, do you > think the loss of this data will impact operations? > I think it's far more important that whatever POC is listed in the WHOIS database as responsible for a particular IP range, be responsive to e-mail complaints from other admins of other networks. It's actually worse from an operations P.O.V. if a sub-delegate POC isn't responsive, than if the sub-delegate entry doesn't even exist, and the parent IS responsive. I realise ARIN has a lot of concerns of utilization but I think most ISPs are more concerned with getting a response from a responsible party in the Whois database, rather than how well-utilized a particular parent block is. Ted > /John > > On Dec 2, 2009, at 10:53 AM, Ted Mittelstaedt wrote: > >> Danny McPherson wrote: >>> On Dec 1, 2009, at 3:12 PM, Ted Mittelstaedt wrote: >>>> My original post on this topic was aimed at the 'anti-whois' >>>> crowd because I felt that the post from Danny on the 30th was a >>>> recycling of the old "well if nobody is filing SWIPS then I'm >>>> not going to so let's get rid of them" argument. I have seen >>>> that logic before and I thought I recognized it again, and I >>>> have to say that I believe my guess was right considering >>>> Danny's highly negative reaction to my pointing out the >>>> foolishness of not making SWIP data available. >>> For the record, you're mistaken, I had zero opinion on this topic >>> beyond trying to understand what the issues were. >> Danny, I apologize for assuming that you had an iron in the fire on >> this. The last time this topic came up on the list the original >> poster definitely had an axe to grind. > From tedm at ipinc.net Wed Dec 2 18:04:36 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 02 Dec 2009 15:04:36 -0800 Subject: [arin-ppml] ARIN Audits (was SWIPs & IPv6) In-Reply-To: References: <87d69953e79e207cafc2bf6e93aea4d9@academ.com> <4B159579.9090802@ipinc.net> <4B15A778.6050502@umn.edu> Message-ID: <4B16F284.7000603@ipinc.net> Martin Hannigan wrote: > > On Dec 1, 2009, at 6:32 PM, David Farmer wrote: > >> Martin Hannigan wrote: >> > >> > On Dec 1, 2009, at 5:15 PM, Ted Mittelstaedt wrote: >> > >> > >> > [ clip ] >> >> >> >> >> >> Stan, this kind of question is kind of like asking the local police >> >> department what their criminal profiling criteria is. My hope is that >> >> if ARIN chooses to answer you, that they do so privately. >> >> >> >> Ted >> >> >> > >> > >> > My accountants know what will flag me for an IRS audit. My attorney >> > knows what will inflame a judge. >> >> Realize that is one of the many things you are paying them for, their >> expert opinion on those issues and where the boundaries are, and what is >> over line and what is not. >> > > > David, > > I think most of us realize a lot more than you give us credit for. Why > should I have to pay someone to help me navigate the ARIN NRPM? Do you pay a lawyer to help you navigate a credit card signup contract? A new car loan? An apartment lease contract? I don't know, perhaps people should - those are all far more complex than your typical business contract, at least the ones I've signed! And the other party holding the contract is far and away more inimical (epically those credit card contracts, Oy vey!) Ted In fact, > it's already complicated enough that people _do_ pay others to help them > navigate it. Food for thought. > > Best Regards, > > -M< > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From charles at office.tcsn.net Wed Dec 2 17:50:41 2009 From: charles at office.tcsn.net (Charles O'Hern) Date: Wed, 02 Dec 2009 14:50:41 -0800 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out - Last Call In-Reply-To: <4B15080C.28232.1D4A9DEF@farmer.umn.edu> References: <4B0C074D.9020608@arin.net> <4B15080C.28232.1D4A9DEF@farmer.umn.edu> Message-ID: <4B16EF41.70803@office.tcsn.net> I support the policy wording in its current revision. David Farmer wrote: > Now that the Thanksgiving holiday has passed here in the US, > I would like to remind everyone that there is an important pice > of policy business on the table for PPML. > > Draft Policy 2009-8: Equitable IPv4 Run-Out is in Last Call. > > Three of the last four Draft Policies had little or no Last Call > comments; two hand no comments, one had one comment, > and the forth policy had 10 comments from 5 individuals. > > As one of the AC shepards for this proposal I would appreciate > any Last Call comments you may have on this Draft Policy, > even if it is simply that you support the policy as written. > > The text of this Draft Policy changed significantly from the > version discussed on the floor at Dearborn, so please take a > moment and read it carefully including the Rationale. > > Thank you, > > And finally in the spirit of the upcoming holidays; > > Best wishes to you and yours; > Peace on Earth, and; > THE UNIVERSAL ADOPTION OF IPv6. :) > > > On 24 Nov 2009 Member Services wrote: > > >> The ARIN Advisory Council (AC) met on 19 November and decided to >> send a revised version of the following draft policy to last call: >> >> Draft Policy 2009-8: Equitable IPv4 Run-Out >> >> Feedback is encouraged during this last call period. All comments should >> be provided to the Public Policy Mailing List. This last call will >> expire on 10 December 2009. After last call the AC will conduct their >> last call review. >> >> The draft policy text is below and available at: >> https://www.arin.net/policy/proposals/ >> >> The ARIN Policy Development Process is available at: >> https://www.arin.net/policy/pdp.html >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Draft Policy 2009-8 >> Equitable IPv4 Run-Out >> >> Version/Date: 24 November 2009 >> >> Policy statement: >> >> Rename NRPM 4.2.4.3; >> >> 4.2.4.3 Subscriber Members Less Than One Year >> >> Replace NRPM 4.2.4.4 with; >> >> 4.2.4.4 Subscriber Members After One Year >> >> After an organization has been a subscriber member of ARIN for one year, >> they may choose to request up to a 12 month supply of IP addresses. >> >> When ARIN receives its last /8, by IANA implementing section 10.4.2.2, >> the length of supply that an organization may request will be reduced. >> An organization may choose to request up to a 3 month supply of IP >> addresses. >> >> This reduction does not apply to resources received via section 8.3. An >> organization receiving a transfer under section 8.3 may continue to >> request up to a 12 month supply of IP addresses. >> >> Rationale: >> >> This policy is intended to ensure an equitable distribution of IPv4 >> resources as run-out of the ARIN free pool occurs. This is achieved by >> changing section 4.2.4.4 of the NRPM to reduce the length of supply of >> IPv4 resources that may be requested when the IANA free pool runs-out. >> Equity is accomplished by reducing the window that an advantage or >> disadvantage can exist between competitors, that will be created when >> one competitor receives a final allocation just before run-out and >> another competitor does not. >> >> Further this policy ensures equity between incumbent resource holders >> and new entrants by providing the same length of supply for each as the >> ARIN free pool runs out. This eliminates a potential bias toward >> incumbent resource holders that is created as a result of ARIN free pool >> run-out interacting with resource allocation slow start for new entrants >> in current policy. >> >> This policy is similar to ideas in RIPE policy proposal 2009-03 >> (http://www.ripe.net/ripe/policies/proposals/2009-03.html), and has been >> adapted by discussion and for use within the ARIN region. >> >> This policy is intended to be independent of other policies or proposals >> to reserve address space for IPv6 transition or other purposes. It is >> not intended to limit Transfers to Specified Recipients per section 8.3 >> of the NRPM. >> >> This draft contains the elements that there seems to have been the >> largest consensus for on the floor of ARIN XXIV Public Policy Meeting in >> Dearborn, Michigan. Further, there was a strong preference that no >> changes be triggered until IANA free pool run-out. >> >> Timetable for implementation: Immediate >> > > > =============================================== > David Farmer Email:farmer at umn.edu > Office of Information Technology > Networking & Telecomunication Services > University of Minnesota Phone: 612-626-0815 > 2218 University Ave SE Cell: 612-812-9952 > Minneapolis, MN 55414-3029 FAX: 612-626-1818 > =============================================== > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From michael.dillon at bt.com Thu Dec 3 04:00:34 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 3 Dec 2009 09:00:34 -0000 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <8695009A81378E48879980039EEDAD287B279F5E@MAIL1.polartel.local> Message-ID: <28E139F46D45AF49A31950F88C497458045BC30B@E03MVZ2-UKDY.domain1.systemhost.net> > I disagreed with Ted yesterday so naturally I have to agree > with him strongly today. We need whois data that allows us > to get in touch with a real person in short order. Now I'm confused. If we need "network contact" data that quickly gets you in communication with people who are ready, willing and able to act on your communications, then why do you call it "whois" data? Whois data is vague, ill-defined, out of date, and misleading. We will get further ahead if we drop the discussion of whois, and improvements to whois, and start from the needs of network operators and others. I see a strong need from many parties to know the identity of address block users. Some people want this just to do long term pattern analyses of network abuse. I also see a strong need for accurate and up-to-date contact information that leads directly to people who are ready, willing and able to act. However, I don't confuse the two. If a published directory identifies Joe Bloe of Outer Hoboken as the address block user, it does not follow that people should contact Joe Bloe. I'd like to see clear separation of these things so that people are not surprised to see Chicagoland Hosting Center NOC as the contact for Joe Bloe in Hoboken. Ask for identity info and you get one thing. Ask for network admin contact and you get another. > In any case when these things happen waiting days for a > response from an anonymized and infrequently checked email is > not an acceptable solution. Some times one needs a name and > a telephone number. Agreed. The info needs to be up to date which is why I propose that the recipients of a network allocation should run a server that allows you to query for this contact info. It is more likely that an organization will keep its own databases up to date. ARIN could then either mirror these databases entirely without human intervention or it could refer queries to the appropriate server based on the IP address, rather like an HTTP redirect. > In some cases having to contact the top level provider and > then work my way down through a series of book keepers to get > to a network operator has extended problem times. It would be quicker if the "working your way down" was handled by the query tool responding to "redirect" messages from the directory server. > I am not saying IPv6 info will be any better than IPv4 info, > but I hope it will not be worse. I'm certain that it will be worse, unless we build something modern to replace the whois hack from the ARPANET days. --Michael Dillon From michael.dillon at bt.com Thu Dec 3 04:09:25 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 3 Dec 2009 09:09:25 -0000 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B16D187.6060104@ipinc.net> Message-ID: <28E139F46D45AF49A31950F88C497458045BC333@E03MVZ2-UKDY.domain1.systemhost.net> > Now, the problem here is that the org isn't DELIBERATELY > going out and violating section 5b, it's just accumulated > mistakes. At what point does ARIN state the org is in > violation of section 5b? Why throw vinegar at people? You'll get further ahead by honeying them up with help to reduce the mistakes. If ARIN states that an org is in violation, the organization could sue ARIN, and obtain a court order preventing ARIN from taking any further action until the lawsuit is completed and the courts have decided who is at fault. ARIN needs to focus on education and on removing barriers. In order to remove barriers, ARIN needs a better process for publishing a contact directory, and better tools for ISPs to use. This is not like the current work of providing an alternative to emailed SWIPs, because people do not have a big investment in IPv6 tools. This is an opportunity for ARIN and the community to design something right and to implement it well. In particular, if it is open source, then many companies can contribute to it. > And the larger question is, what constitutes "maintenance of > directory services data...data concerning any organization to > which it further sub-delegates" This would be easier to define and audit if both orgs are running the same directory server which can be queried to test any criteria that you want. Wordsmithing the RSA will not solve any problems, just make the problems get into the courts sooner. Do we want to fix the problem or do we want to hit people over the head with brickbats? --Michael Dillon From mueller at syr.edu Thu Dec 3 10:37:58 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 3 Dec 2009 10:37:58 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B16B7A4.6080901@ipinc.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> <4201421D-9940-4EF2-90FB-EC0657515B1C@tcb.net> <4B16B7A4.6080901@ipinc.net> Message-ID: <75822E125BCB994F8446858C4B19F0D79EFB299E@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > I'm not aiming at you, I'm aiming at the people who want to get > rid of the whois database, and institute the same kind of > butchery to it that the DNS registrars have permitted to domain name > contacts (ie: so-called "privacy" listings that do nothing other than to > allow criminals to hide themselves) This is a typically unbalanced and exaggerated claim. There are legitimate privacy concerns regarding access to contact and address data, including shielding people from cyber-criminals and spammers, and there are legal issues regarding the display of that data when natural persons (i.e., not incorporated organizations) are involved. Revelation of the data shielded by these so-called privacy services is notoriously easy to obtain, basically you just have to ask for it, be a real entity and have some legitimate purpose. All of these constraints are absent, of course, from anonymous, web-based whois interfaces. The idea that people can abuse the internet (correct, of course) must always be balanced by the equally valid observation that people can and do abuse unrestricted access to sensitive data. The implication that only criminals use DNS privacy protection services is obviously false, unless you believe that about 30% of all domain name registrants are criminals and that the numerous reputable individuals I could cite, including newspaper reporters and small businesspeople, are also criminals. The expectation that WHOIS/SWIP issues can be discussed independently of data protection rules and norms is a fantasy. I know Ted is a lost cause on this issue and don't frankly care; but I hope the rest of this list is a bit more mature and not populated by people who think that their convenience as technical administrators trumps any and every human rights concern. Beyond that, to avoid the practically useless kinds of ideological debates in which Ted revels, I'd propose restricting any further discussion of this to specific proposals and operational guidelines. You can't know whether there is a legitimate privacy and/or security issue unless we are discussing real proposals in real contexts. --MM From kkargel at polartel.com Thu Dec 3 10:54:01 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 3 Dec 2009 09:54:01 -0600 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D79EFB299E@SUEX07-MBX-04.ad.syr.edu> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> <4201421D-9940-4EF2-90FB-EC0657515B1C@tcb.net> <4B16B7A4.6080901@ipinc.net> <75822E125BCB994F8446858C4B19F0D79EFB299E@SUEX07-MBX-04.ad.syr.edu> Message-ID: <8695009A81378E48879980039EEDAD287B279F69@MAIL1.polartel.local> Milton, Just as when you go physically go out in public you reduce your privacy, people can take your picture, publish your whereabouts, write newspaper articles about what you are doing, make not of your car license plate, tell others what it is.. just so when you conduct public business on the internet you lose some aspects of privacy. When your network interacts with other networks you have an obligation to be reachable and contactable by those other networks. If you don't want people to see you, if you don't want to play nicely then stay home, pull your networks inside your own borders and stop interacting with the world. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Milton L Mueller > Sent: Thursday, December 03, 2009 9:38 AM > To: Danny McPherson > Cc: arin ppml > Subject: Re: [arin-ppml] SWIPs & IPv6 > > > > -----Original Message----- > > I'm not aiming at you, I'm aiming at the people who want to get > > rid of the whois database, and institute the same kind of > > butchery to it that the DNS registrars have permitted to domain name > > contacts (ie: so-called "privacy" listings that do nothing other than to > > allow criminals to hide themselves) > > This is a typically unbalanced and exaggerated claim. There are legitimate > privacy concerns regarding access to contact and address data, including > shielding people from cyber-criminals and spammers, and there are legal > issues regarding the display of that data when natural persons (i.e., not > incorporated organizations) are involved. > > Revelation of the data shielded by these so-called privacy services is > notoriously easy to obtain, basically you just have to ask for it, be a > real entity and have some legitimate purpose. All of these constraints are > absent, of course, from anonymous, web-based whois interfaces. The idea > that people can abuse the internet (correct, of course) must always be > balanced by the equally valid observation that people can and do abuse > unrestricted access to sensitive data. > > The implication that only criminals use DNS privacy protection services is > obviously false, unless you believe that about 30% of all domain name > registrants are criminals and that the numerous reputable individuals I > could cite, including newspaper reporters and small businesspeople, are > also criminals. > > The expectation that WHOIS/SWIP issues can be discussed independently of > data protection rules and norms is a fantasy. I know Ted is a lost cause > on this issue and don't frankly care; but I hope the rest of this list is > a bit more mature and not populated by people who think that their > convenience as technical administrators trumps any and every human rights > concern. > > Beyond that, to avoid the practically useless kinds of ideological debates > in which Ted revels, I'd propose restricting any further discussion of > this to specific proposals and operational guidelines. You can't know > whether there is a legitimate privacy and/or security issue unless we are > discussing real proposals in real contexts. > > --MM > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From tvest at eyeconomics.com Thu Dec 3 11:55:14 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Thu, 3 Dec 2009 11:55:14 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D79EFB299E@SUEX07-MBX-04.ad.syr.edu> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> <4201421D-9940-4EF2-90FB-EC0657515B1C@tcb.net> <4B16B7A4.6080901@ipinc.net> <75822E125BCB994F8446858C4B19F0D79EFB299E@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Dec 3, 2009, at 10:37 AM, Milton L Mueller wrote: > >> -----Original Message----- >> I'm not aiming at you, I'm aiming at the people who want to get >> rid of the whois database, and institute the same kind of >> butchery to it that the DNS registrars have permitted to domain name >> contacts (ie: so-called "privacy" listings that do nothing other >> than to >> allow criminals to hide themselves) > > This is a typically unbalanced and exaggerated claim. There are > legitimate privacy concerns regarding access to contact and address > data, including shielding people from cyber-criminals and spammers, > and there are legal issues regarding the display of that data when > natural persons (i.e., not incorporated organizations) are involved. > > Revelation of the data shielded by these so-called privacy services > is notoriously easy to obtain, basically you just have to ask for > it, be a real entity and have some legitimate purpose. All of these > constraints are absent, of course, from anonymous, web-based whois > interfaces. The idea that people can abuse the internet (correct, of > course) must always be balanced by the equally valid observation > that people can and do abuse unrestricted access to sensitive data. > > The implication that only criminals use DNS privacy protection > services is obviously false, unless you believe that about 30% of > all domain name registrants are criminals and that the numerous > reputable individuals I could cite, including newspaper reporters > and small businesspeople, are also criminals. > > The expectation that WHOIS/SWIP issues can be discussed > independently of data protection rules and norms is a fantasy. I > know Ted is a lost cause on this issue and don't frankly care; but I > hope the rest of this list is a bit more mature and not populated by > people who think that their convenience as technical administrators > trumps any and every human rights concern. > > Beyond that, to avoid the practically useless kinds of ideological > debates in which Ted revels, I'd propose restricting any further > discussion of this to specific proposals and operational guidelines. > You can't know whether there is a legitimate privacy and/or security > issue unless we are discussing real proposals in real contexts. > > --MM Sigh. Is it really so hard to send a message to this list without accusing someone of ideological transgressions? Since you've raised this issue yet again (c.f., June 10 ~ Aug. 31 2009), perhaps now you'll be willing to share with us your view of the proper balance between "legitimate" privacy concerns and "convenience" of technical administration? Rephrasing the two queries that went unanswered last time: 1. Would you say that the proper balance between these two opposing goals is reflected in current DNS whois arrangements? Is that the kind of balance that you would advocate as a goal for protocol number- related registration data and its public presentation ala whois? 2. Are the "legitimate privacy concerns" of artificial persons (i.e., corporations) different from the "legitimate privacy concerns" of natural persons? If so, how -- and how should the differences be reflected in rotocol number-related registration data and whois? Thanks, TV From mueller at syr.edu Thu Dec 3 12:10:27 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 3 Dec 2009 12:10:27 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> <4201421D-9940-4EF2-90FB-EC0657515B1C@tcb.net> <4B16B7A4.6080901@ipinc.net> <75822E125BCB994F8446858C4B19F0D79EFB299E@SUEX07-MBX-04.ad.syr.edu> Message-ID: <75822E125BCB994F8446858C4B19F0D79EFB7A14@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > From: tvest at eyeconomics.com [mailto:tvest at eyeconomics.com] > > Since you've raised this issue yet again (c.f., June 10 ~ Aug. 31 > 2009), perhaps now you'll be willing to share with us your > view of the proper balance between "legitimate" privacy concerns and > "convenience" of technical administration? Rephrasing the two queries that went > unanswered last time: Tom: Privacy norms, standards and laws are well known and not that hard to apply to this case. Here is a link to a boilerplate explanation of basic data protection principles: http://www.recordsmanagement.ed.ac.uk/InfoStaff/DPstaff/DPPrinciples.htm Respectful suggestion: do some homework on how this issue gets handled before wading into a policy arena with global human rights implications. > 1. Would you say that the proper balance between these two opposing > goals is reflected in current DNS whois arrangements? Absolutely not. (And you know perfectly well that I've answered this question, not only on this list, but in lengthy scholarly articles, and in years of work on DNS Whois Working Groups and Task Forces.) It would be very easy for DNS Whois to contain the requisite technical information needed for both law enforcement and technical management without providing indiscriminate public access to anyone and everyone, for any purpose. The only reason this doesn't happen: DNS Whois arrangements have been hijacked by trademark protection firms, LEAs too lazy to get the proper authorizations, and by companies that collect and sell the data for various and sundry purposes. See data protection principle #2 for my opinion about that. > 2. Are the "legitimate privacy concerns" of artificial > persons (i.e., > corporations) different from the "legitimate privacy concerns" of > natural persons? Sigh. Overlooking your complete ignorance of applicable law, I will simply answer yes. The distinction is well-established in law, not to mention common sense. Yes, Tom, there are differences between the privacy rights and legal norms applicable to publicly registered corporate entities and flesh and blood persons and their homes and personal property. > If so, how -- and how should the differences be > reflected in rotocol number-related registration data and whois? Yes, of course the differences should be reflected. How? Not that hard, but as I said in my last message, let's debate specific arrangements and proposals, not ideology. --MM From cengel at sponsordirect.com Thu Dec 3 12:19:52 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Thu, 3 Dec 2009 12:19:52 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: Message-ID: I'm probably going to get blasted for this, but speaking on the Enterprise side of things there are fairly understandable reasons why Enterprise Admins might want to avoid public disclosure of their contact information and why they sometimes put in contact information that isn't well monitored..... and why they might choose to utilize services like the privacy listings Domain Registrars provide. Just like any other information it can be used for both legitimate and illegitimate purposes. That sort of information can be used to facilitate social engineering attacks, to SPAM the contacts themselves or mined to create targeted sales lists for telemarketing services that cater to Tech related industries. Frankly, it's been my experience that the volume and frequency of illegitimate use of this information far outweighs the legitimate use of it. I'll grant though that when it IS legitimately needed the importance of it being available (IMO) far outweighs the negatives of it being out there..... and frankly there are other avenues to obtain that sort of data. We keep our contact info public, but I can understand why many others don't want to .... and not because they are criminals or spammers....making THEIR data public they get to experience the downsides of that, but rarely the upsides... it's when they need the OTHER guys data that they see the importance. Frankly, I'm not convinced of the utility of WHOIS information in catching criminals/spammers. Being who they are, those people almost never use their own systems to do their dirty work and they don't generally give out legitimate contact information that can be easily traced to them.... and in cases where they do it's usually because they are operating out of jurisdictions where it doesn't matter because the local authorities won't do anything about it (heck sometimes the guys doing it ARE the local authorities). The dynamic is pretty much the same as it is outside of cyberspace where you almost never see criminals (at least the less stupid ones) use cars or guns that are actually registered to them in the commission of their crimes. The real utility of accurate contact information, I think comes not in dealing with people who are actually committing malicious acts but rather those who may have innocently misconfigured their systems or may have been compromised by hackers and who's resources are being used without their knowledge. So while maintaining accurate contact info is important, I can see why their is a legitimate desire (by people who aren't doing anything wrong) to have their info shielded as well. Gatekeeping services to such information are not inherently bad... as long as the gatekeepers themselves are responsive to legitimate requests for such info in a timely fashion. Christopher Engel From cengel at sponsordirect.com Thu Dec 3 13:38:57 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Thu, 3 Dec 2009 13:38:57 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: Message-ID: I believe that Milton makes an excellent point below. The important issue, I believe, is NOT that the general public be able to determine who ACTUALY owns a particular address block or domain. The important issue is being able to report a problem with a particular domain/address block to some-one who can take appropriate action upon it. Looking at the analogy of cars on a road is probably rather appropriate in this case. Roads are a public shared resource just like the internet. In order to be able to put a car on the road (at least in the US) it needs to registered with your state DMV and needs to have a visible license plate on it. Note that the ONLY thing that is publicaly revealed when your car is on the road is that License Plate #... not the owners Name, Address, Phone #, etc. The public can NOT simply goto the DMV and get the corresponding Contact Info for a License Plate #. The reasons for that are obvious.... a stalker or abusive ex-boyfriend knows the car thier intended victem is driving.... if they are able to get a home address/phone # from that publicaly availble license plate #, thier ability to carry out abuse is greatly enhanced. The hazards for providing contact information for the actual owners of a domain/IP block are not that different. What you CAN do is report that License Plate # to the Police/DMV when there is a problem with that car (say it knocked over your fence and then drove off) and THEY can take action that is neccesary to address the problem. In cases where you have a legitimate need for the actual contact information (say you need to know who to sue for damaging your property) THEY will provide it for you if your requirement for it is determined to be legitimate. They act as gate-keepers for that information. In cases where you feel those gate-keepers are not providing such information when there is legitimate cause you can petition the courts for redress. I really see no issue with an ISP or other Agent acting as the POC or Gatekeeper for an individual block/domain holders information. The problem occurs when that ISP/Agent is not themselves responsive when there is a legitimate need to resolve an issue that the address holder is causing. In our real world example, the Police/DMV have dual responsibilties.... they are responsible to protect the privacy of the vehicle owner.... but also responsible to protect the rights of individuals who that vehicle may have infringed upon... they are equaly accountable to both. In essence, they have no horse in the race themselves. In the case of the ISP/Registrar/Agent the person who's identity they are protecting is thier customer so they have a vested interest in being biased toward thier interests. Perhaps that is part of the issue here. ..... Milton L Mueller writes: "This is a typically unbalanced and exaggerated claim. There are legitimate privacy concerns regarding access to contact and address data, including shielding people from cyber-criminals and spammers, and there are legal issues regarding the display of that data when natural persons (i.e., not incorporated organizations) are involved. Revelation of the data shielded by these so-called privacy services is notoriously easy to obtain, basically you just have to ask for it, be a real entity and have some legitimate purpose. All of these constraints are absent, of course, from anonymous, web-based whois interfaces. The idea that people can abuse the internet (correct, of course) must always be balanced by the equally valid observation that people can and do abuse unrestricted access to sensitive data. The implication that only criminals use DNS privacy protection services is obviously false, unless you believe that about 30% of all domain name registrants are criminals and that the numerous reputable individuals I could cite, including newspaper reporters and small businesspeople, are also criminals. The expectation that WHOIS/SWIP issues can be discussed independently of data protection rules and norms is a fantasy. I know Ted is a lost cause on this issue and don't frankly care; but I hope the rest of this list is a bit more mature and not populated by people who think that their convenience as technical administrators trumps any and every human rights concern. Beyond that, to avoid the practically useless kinds of ideological debates in which Ted revels, I'd propose restricting any further discussion of this to specific proposals and operational guidelines. You can't know whether there is a legitimate privacy and/or security issue unless we are discussing real proposals in real contexts. --MM " From kkargel at polartel.com Thu Dec 3 13:39:57 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 3 Dec 2009 12:39:57 -0600 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: Message-ID: <8695009A81378E48879980039EEDAD287B279F70@MAIL1.polartel.local> So then is it being suggested that ARIN act as a gatekeeper and keep legitimate information behind a wall, and when needed that information is needed it can be requested by a legitimate party from ARIN but not directly exposed to the public? Would ARIN require and verify the information? I would be willing to support such a proposal. Having the proper information one step away would be superior to having the information obfuscated as it currently is in many instances. I would still like to see the transparency of top level company information be transparent and public, but I would accept technical POC and other contact information being secured with ARIN as custodian. From tedm at ipinc.net Thu Dec 3 13:40:57 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 03 Dec 2009 10:40:57 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: Message-ID: <4B180639.4070206@ipinc.net> Chris Engel wrote: > I'm probably going to get blasted for this, but speaking on the > Enterprise side of things there are fairly understandable reasons why > Enterprise Admins might want to avoid public disclosure of their > contact information and why they sometimes put in contact information > that isn't well monitored..... That is why ARIN allows Role accounts. hostmaster at wonkulatinggronkulators.com reveals nothing to the public about the personal data of the admin. There is such a thing as a public and a private persona. That is why many (if not most) actors have stage names. Many authors also use pen names. There's plenty of legal precedent for doing this and there is no legal or contractural requirement in the RSA to NOT use a public persona in your POC data. The only requirement is that it is accurate. Meaning that if I send an e-mail to hostmaster at wonkulatinggronkulators.com that it gets to the actual person - maybe Sally Sue - who is responsible. Nothing compels Sally Sue in her response to me to identify herself as anything other than an androgynous hostmaster at wonkulatinggronkulators.com, or publish her personal phone number, etc. Enterprise admins that simply use stale or non-monitored contact info are just lazy asses, IMHO, and their orgs should be sued in civil court for violation of the RSA if they don't clean up their act after being prompted to do so. > and why they might choose to utilize > services like the privacy listings Domain Registrars provide. > There is no difference between an org running a Role account that does not identify any specific person in the org (or the actual org itself) and paying some 3rd party company to do it for them. That is not what is at issue here. As long as the 3rd party that is acting as the org's agent is responsive, there isn't a problem IMHO. > Just like any other information it can be used for both legitimate > and illegitimate purposes. That sort of information can be used to > facilitate social engineering attacks, to SPAM the contacts > themselves or mined to create targeted sales lists for telemarketing > services that cater to Tech related industries. Frankly, it's been my > experience that the volume and frequency of illegitimate use of this > information far outweighs the legitimate use of it. Each to his own, that's not been my experience. My personal domain names have my real address on them. My public website has my Resume with real address and phone number and picture. Google my name and you come up with 65K hits, and there's not a lot of people out there with the same name as me. And, I'm no stranger to honking people off. Yet, nobody has shown up at my door with the proverbial axe to murder me yet, so I have to say that based on my OWN experience, these "fairly understandable reasons" and similar phrases like that which people use to self-justify making themselves hard to reach don't hold water. It was also well known (at least in the SF world) that the famous author Issac Asimov maintained his real telephone number in the NY telephone directory, his real NY address, and so on, and HE never got bothered EITHER. (he did get some interesting phone calls from time to time, though) If it was good enough for him, it's good enough for me. > I'll grant though > that when it IS legitimately needed the importance of it being > available (IMO) far outweighs the negatives of it being out > there..... and frankly there are other avenues to obtain that sort of > data. We keep our contact info public, but I can understand why many > others don't want to .... and not because they are criminals or > spammers....making THEIR data public they get to experience the > downsides of that, but rarely the upsides... it's when they need the > OTHER guys data that they see the importance. > > Frankly, I'm not convinced of the utility of WHOIS information in > catching criminals/spammers. Being who they are, those people almost > never use their own systems to do their dirty work and they don't > generally give out legitimate contact information that can be easily > traced to them.... and in cases where they do it's usually because > they are operating out of jurisdictions where it doesn't matter > because the local authorities won't do anything about it (heck > sometimes the guys doing it ARE the local authorities). The dynamic > is pretty much the same as it is outside of cyberspace where you > almost never see criminals (at least the less stupid ones) use cars > or guns that are actually registered to them in the commission of > their crimes. > It's not in CATCHING them that this data is valuable, it's in MITIGATING the damage they are doing. If your goal in life is to make things difficult for shoplifters, when you see a shoplifter in a store are you going to mention it to the owner of the store or confront the shoplifter directly? Who has more motivation here to shut down the shoplifter? > The real utility of accurate contact information, I think comes not > in dealing with people who are actually committing malicious acts but > rather those who may have innocently misconfigured their systems or > may have been compromised by hackers and who's resources are being > used without their knowledge. > That is important, too. > So while maintaining accurate contact info is important, I can see > why their is a legitimate desire (by people who aren't doing anything > wrong) to have their info shielded as well. Gatekeeping services to > such information are not inherently bad... as long as the gatekeepers > themselves are responsive to legitimate requests for such info in a > timely fashion. > I'll say it again, there is no difference between an org running a Role account that does not identify any specific person in the org (or the actual org itself) and paying some 3rd party company to do it for them. That is not what is at issue here, and never HAS been the issue. The issue is orgs that deliberately put in bogus info in the Whois database, or orgs that have stale info in there that they don't update, specifically because they think this enhances their "privacy" Ted > > > > Christopher Engel _______________________________________________ > PPML You are receiving this message because you are subscribed to the > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or > manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml Please contact > info at arin.net if you experience any issues. From lar at mwtcorp.net Thu Dec 3 13:31:06 2009 From: lar at mwtcorp.net (lar at mwtcorp.net) Date: Thu, 03 Dec 2009 11:31:06 -0700 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <8695009A81378E48879980039EEDAD287B279F69@MAIL1.polartel.local> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> <4201421D-9940-4EF2-90FB-EC0657515B1C@tcb.net> <4B16B7A4.6080901@ipinc.net> <75822E125BCB994F8446858C4B19F0D79EFB299E@SUEX07-MBX-04.ad.syr.edu> <8695009A81378E48879980039EEDAD287B279F69@MAIL1.polartel.local> Message-ID: Would you object if a locality required you to wear your Name, Address and home phone number on your outer jacket if you were out in public? We are talking about other people's privacy so let's not be too quick to pooh-pooh their concerns. You know, even paranoids have enemies. Larry Kevin Kargel wrote: > Milton, > > Just as when you go physically go out in public you reduce your privacy, >people can take your picture, publish your whereabouts, write newspaper >articles about what you are doing, make not of your car license plate, tell >others what it is.. just so when you conduct public business on the >internet you lose some aspects of privacy. > > When your network interacts with other networks you have an obligation to >be reachable and contactable by those other networks. > > If you don't want people to see you, if you don't want to play nicely then >stay home, pull your networks inside your own borders and stop interacting >with the world. > > Larry Ash Network Administrator Mountain West Telephone 400 East 1st St. Casper, WY 82601 Office 307 233-8387 From tvest at eyeconomics.com Thu Dec 3 13:50:20 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Thu, 3 Dec 2009 13:50:20 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D79EFB7A14@SUEX07-MBX-04.ad.syr.edu> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> <4201421D-9940-4EF2-90FB-EC0657515B1C@tcb.net> <4B16B7A4.6080901@ipinc.net> <75822E125BCB994F8446858C4B19F0D79EFB299E@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D79EFB7A14@SUEX07-MBX-04.ad.syr.edu> Message-ID: <35E5D7C3-DB2C-42A7-9BD1-219BE9F976F3@eyeconomics.com> On Dec 3, 2009, at 12:10 PM, Milton L Mueller wrote: > >> -----Original Message----- >> From: tvest at eyeconomics.com [mailto:tvest at eyeconomics.com] >> >> Since you've raised this issue yet again (c.f., June 10 ~ Aug. 31 >> 2009), perhaps now you'll be willing to share with us your >> view of the proper balance between "legitimate" privacy concerns and >> "convenience" of technical administration? Rephrasing the two >> queries that went >> unanswered last time: > > Tom: > > Privacy norms, standards and laws are well known and not that hard > to apply to this case. > Here is a link to a boilerplate explanation of basic data protection > principles: > http://www.recordsmanagement.ed.ac.uk/InfoStaff/DPstaff/DPPrinciples.htm > Respectful suggestion: do some homework on how this issue gets > handled before wading into a policy arena with global human rights > implications. Hi Milton, Thanks for the respectful suggestion. I will take it under advisement. However, I would respectfully suggest that providing more substantive answers here would be useful both to you (if your goal is, in fact, to help inform number resource policies), as well as to those list members who are not likely to go off and do a lot of homework on this issue. >> 1. Would you say that the proper balance between these two opposing >> goals is reflected in current DNS whois arrangements? > > Absolutely not. (And you know perfectly well that I've answered this > question, not only on this list, but in lengthy scholarly articles, > and in years of work on DNS Whois Working Groups and Task Forces.) > > It would be very easy for DNS Whois to contain the requisite > technical information needed for both law enforcement and technical > management without providing indiscriminate public access to anyone > and everyone, for any purpose. Okay, in that case I call: 1. Could you suggest how, exactly, a registration/whois system can be both very accurate, very reliable, and very easy for technical administrators to access (when justified) for real-time network management requirements*, while at the same time satisfying the the legitimate* privacy concerns of the individuals and institutions who are represented in that registration data? 2. Could you also suggest how those conditions that are accurately deemed to be legitimate*, required*, etc. by both groups might be sustained over time? Specifically, if revelation of whois inaccuracies is generally only possible as a result of outages or other "events" that require technical administrator action, and discovery of correct whois information in such cases is generally only possible through legal mechanisms (warrants, subpoenas, lawsuits, registry disaccreditations, etc.) which do not operate at time scales that are consistent with real-time network management, what method(s) would you propose for reconciling this critical mismatch? 3. Finally (and if appropriate), could you also suggest how those conditions might be preserved in an environment of competitive commercial provision of registration and whois services? Specifically, what mechanisms would you recommend to encourage registration and whois service providers to maintain the proper level of investment in and ongoing support for this secondary, non profit-making function? What mechanisms would you advocate to assure that individual commercial registration and whois service providers resist the temptation to differentiate themselves by cutting their whois-related support and/or by relaxing their whois-related customer requirements? Since (3) presumes that you advocate the competitive provision of registration and whois services, with at least some competitors being private/not-governmental entities, please disregard this question if this presumption is inaccurate. > The only reason this doesn't happen: DNS Whois arrangements have > been hijacked by trademark protection firms, LEAs too lazy to get > the proper authorizations, and by companies that collect and sell > the data for various and sundry purposes. See data protection > principle #2 for my opinion about that. If I'm interpreting your reference correctly, data protection principle #2 reads: "Personal data shall be obtained only for one or more specified and lawful purposes, and shall not be further processed in any manner incompatible with that purpose or those purposes." If we stipulate for the moment that we're only talking about protocol number whois as used for legitimate technical administrative purposes that are consistent with the law, then the relevance of data protection principle #2 is still ambiguous. One justification for open public whois is that public scrutiny provides a kind of continuous distributed error detection and correction mechanism, which helps to maintain whois completeness and accuracy in between those critical moments when technical-administrative action is both legal and justified -- and at which points the belated discovery of whois inaccuracies can have the most adverse consequences. Is it your view that the very existence and/or maintenance of accurate personal data should be subject to a different, higher standard than the standard suggested by data protection principle #2? >> 2. Are the "legitimate privacy concerns" of artificial >> persons (i.e., >> corporations) different from the "legitimate privacy concerns" of >> natural persons? > > Sigh. Overlooking your complete ignorance of applicable law, I will > simply answer yes. > The distinction is well-established in law, not to mention common > sense. Yes, Tom, there are differences between the privacy rights > and legal norms applicable to publicly registered corporate entities > and flesh and blood persons and their homes and personal property. Ignoring the insult, I'll just observe again that a less clever but more substantive response would have probably been more useful, to you and everyone else. >> If so, how -- and how should the differences be >> reflected in rotocol number-related registration data and whois? > > Yes, of course the differences should be reflected. How? Not that > hard, but as I said in my last message, let's debate specific > arrangements and proposals, not ideology. Excellent. Here's your chance to debate specifics. It's good to know that it won't be that hard... Thanks, TV From tvest at eyeconomics.com Thu Dec 3 14:05:43 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Thu, 3 Dec 2009 14:05:43 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: Message-ID: Hi Chris, The same license plate analogy was discussed on the RIPE policy list about six months ago: >> On 23 Jul 2009, at 13:14, tvest at eyeconomics.com wrote: >> There is almost certainly some sort of clearing house role for the >> RIRs in any address space matrket: authenticating the seller's >> "title" to the space, maintaining up to date registry info and so >> on. However this doesn't have to record prices. For instance the >> DMV doesn't care what someone pays for a car. They do want to know >> who owns it. > > That's true, but then you don't go to the DMV volutarily. You go > because: > > 1. you are required by law to obtain a special token that indicates > that your vehicle are bona fide -- a token that is clearly visible > to everyone you interact with at all times. > 2. guys with the authority to mete out real consequences are > constantly cruising around, looking specifically for missing or out- > of-date tokens. > 3. Every driver is aware of (2); some people may occasionally try to > get by without registering, and bad guys know generally don't try to > register stolen vehicles, but everyone is aware that the LEA risk is > real. > > In the Internet context, not only is each of the above false; in > each case the opposite is true. So, I would suggest that one cannot really embrace the license plate parallel unless you also want to embrace all that goes along with it, i.e., substantial investment in a large, widely distributed rule enforcement system with real power to mete out punishment, which is constantly if somewhat thinly and randomly monitoring everyone on the road... TV On Dec 3, 2009, at 1:38 PM, Chris Engel wrote: > I believe that Milton makes an excellent point below. The important > issue, I believe, is NOT that the general public be able to > determine who ACTUALY owns a particular address block or domain. The > important issue is being able to report a problem with a particular > domain/address block to some-one who can take appropriate action > upon it. > > Looking at the analogy of cars on a road is probably rather > appropriate in this case. Roads are a public shared resource just > like the internet. In order to be able to put a car on the road (at > least in the US) it needs to registered with your state DMV and > needs to have a visible license plate on it. Note that the ONLY > thing that is publicaly revealed when your car is on the road is > that License Plate #... not the owners Name, Address, Phone #, etc. > The public can NOT simply goto the DMV and get the corresponding > Contact Info for a License Plate #. > > The reasons for that are obvious.... a stalker or abusive ex- > boyfriend knows the car thier intended victem is driving.... if they > are able to get a home address/phone # from that publicaly availble > license plate #, thier ability to carry out abuse is greatly > enhanced. The hazards for providing contact information for the > actual owners of a domain/IP block are not that different. > > What you CAN do is report that License Plate # to the Police/DMV > when there is a problem with that car (say it knocked over your > fence and then drove off) and THEY can take action that is neccesary > to address the problem. In cases where you have a legitimate need > for the actual contact information (say you need to know who to sue > for damaging your property) THEY will provide it for you if your > requirement for it is determined to be legitimate. They act as gate- > keepers for that information. In cases where you feel those gate- > keepers are not providing such information when there is legitimate > cause you can petition the courts for redress. > > I really see no issue with an ISP or other Agent acting as the POC > or Gatekeeper for an individual block/domain holders information. > The problem occurs when that ISP/Agent is not themselves responsive > when there is a legitimate need to resolve an issue that the address > holder is causing. In our real world example, the Police/DMV have > dual responsibilties.... they are responsible to protect the privacy > of the vehicle owner.... but also responsible to protect the rights > of individuals who that vehicle may have infringed upon... they are > equaly accountable to both. In essence, they have no horse in the > race themselves. In the case of the ISP/Registrar/Agent the person > who's identity they are protecting is thier customer so they have a > vested interest in being biased toward thier interests. Perhaps that > is part of the issue here. > > > ..... > Milton L Mueller writes: > > "This is a typically unbalanced and exaggerated claim. There are > legitimate privacy concerns regarding access to contact and address > data, including shielding people from cyber-criminals and spammers, > and there are legal issues regarding the display of that data when > natural persons (i.e., not incorporated organizations) are involved. > > Revelation of the data shielded by these so-called privacy services > is notoriously easy to obtain, basically you just have to ask for > it, be a real entity and have some legitimate purpose. All of these > constraints are absent, of course, from anonymous, web-based whois > interfaces. The idea that people can abuse the internet (correct, of > course) must always be balanced by the equally valid observation > that people can and do abuse unrestricted access to sensitive data. > > The implication that only criminals use DNS privacy protection > services is obviously false, unless you believe that about 30% of > all domain name registrants are criminals and that the numerous > reputable individuals I could cite, including newspaper reporters > and small businesspeople, are also criminals. > > The expectation that WHOIS/SWIP issues can be discussed > independently of data protection rules and norms is a fantasy. I > know Ted is a lost cause on this issue and don't frankly care; but I > hope the rest of this list is a bit more mature and not populated by > people who think that their convenience as technical administrators > trumps any and every human rights concern. > > Beyond that, to avoid the practically useless kinds of ideological > debates in which Ted revels, I'd propose restricting any further > discussion of this to specific proposals and operational guidelines. > You can't know whether there is a legitimate privacy and/or security > issue unless we are discussing real proposals in real contexts. > > --MM " > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mcr at sandelman.ca Thu Dec 3 14:08:15 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 03 Dec 2009 14:08:15 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <0AD286C1-F912-4C34-B0BF-B1E900FF7D4C@arin.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> <4201421D-9940-4EF2-90FB-EC0657515B1C@tcb.net> <4B16B7A4.6080901@ipinc.net> <0AD286C1-F912-4C34-B0BF-B1E900FF7D4C@arin.net> Message-ID: <8951.1259867295@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "John" == John Curran writes: John> So do you believe that ISP's will maintain their IPv6 John> delegations with the same level of accuracy as IPv4 today, and John> if not, do you think the loss of this data will impact John> operations? I hope/believe that ISPs will do a lot more delegations in IPv6 than they do with IPv4. The cable/DSL operator that does DHCP/PPP right now, and gives out dynamic IPv4s, will "give out" (quotes because it may sometimes be autoconfigured) static IPv6s, and more often than not, will also give out subnets. In IPv4 land, you can easily just create pools of addresses and not worry too much about who gets what. (except for auditing later on, which is what logs are for). In IPv6 land, it will be database driven, and so rwhois-like service will be easier. Furthermore, in IPv4 land, doing a delegation with a SWIP and reverse DNS is an "exception" --- something you do for the small number of "business"-type connections, and at some ISPs, this is a manual or semi-manual process. In IPv6 land, this process will be regular, and will be automated. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSxgMmoCLcPvd0N1lAQItUAf8CpBxuo673Wp3m7Mr4fJeaImoCnd+MPqJ iMYJZLmvNVv0J7T4n3BOcjLl6ZVierTrrqIdP6KIudP5ZVf4tUKlRwUwmHzDJ4Bn 9TSUWTuYFJDs5g1VqizvsErlCb8KCdL0OsnxjOwMoCMa+QuB8fa9MiqxN0j22Ppw 3vMlYJ26FUXPBEZN1KQx+U2iUwxMGNi2IeDhDIIZNt+iQ20qEGvjMP+EosBEHTNb XBXRz6/HFRXcDeBXvsgLil605+fqkGT+AYJ5UJoYvnZ782VA3PS4JXhiBz66Ncaf bAd3WBlt0gFDI4Ce/Gv96232/StibTNHWY9mm+w/BEl2YK4KLbMhgA== =f8ic -----END PGP SIGNATURE----- From tedm at ipinc.net Thu Dec 3 14:23:13 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 03 Dec 2009 11:23:13 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: Message-ID: <4B181021.9050706@ipinc.net> Chris Engel wrote: > I believe that Milton makes an excellent point below. >> Beyond that, to avoid the practically useless kinds of ideological >> debates in which Ted revels, I'd propose restricting any further >> discussion of this to specific proposals and operational guidelines. >> You can't know whether there is a legitimate privacy and/or security >> issue unless we are discussing real proposals in real contexts. > Chris, your playing a dangerous game in holding Milton's posts up as an example. As long as your echoing him, he likes you. But the second you disagree with him, he will go after you. Your engaging in an ideological debate, here, and your NOT restricting your discussion to a specific proposal - so, your already going someplace that Milton told you not to go to, although he probably doesn't yet regard your posts as one of the "useless kinds" of debates. ;-) Just don't be surprised when he decides he doesn't like what your saying and turns around and bites your hand. Ted From tedm at ipinc.net Thu Dec 3 14:27:06 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 03 Dec 2009 11:27:06 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: Message-ID: <4B18110A.2070107@ipinc.net> tvest at eyeconomics.com wrote: > Hi Chris, > > The same license plate analogy was discussed on the RIPE policy list > about six months ago: > >>> On 23 Jul 2009, at 13:14, tvest at eyeconomics.com wrote: > >>> There is almost certainly some sort of clearing house role for the >>> RIRs in any address space matrket: authenticating the seller's >>> "title" to the space, maintaining up to date registry info and so on. >>> However this doesn't have to record prices. For instance the DMV >>> doesn't care what someone pays for a car. They do want to know who >>> owns it. >> >> That's true, but then you don't go to the DMV volutarily. You go because: >> >> 1. you are required by law to obtain a special token that indicates >> that your vehicle are bona fide -- a token that is clearly visible to >> everyone you interact with at all times. >> 2. guys with the authority to mete out real consequences are >> constantly cruising around, looking specifically for missing or >> out-of-date tokens. >> 3. Every driver is aware of (2); some people may occasionally try to >> get by without registering, and bad guys know generally don't try to >> register stolen vehicles, but everyone is aware that the LEA risk is >> real. >> >> In the Internet context, not only is each of the above false; in each >> case the opposite is true. > > > So, I would suggest that one cannot really embrace the license plate > parallel unless you also want to embrace all that goes along with it, Not only that, but in actual fact it's ridiculously easy to get license plate data from the DMV. All you have to do is go down to the county, pay $200 for a business license, list your occupation as "mass marketer" then take that to the DMV and they will happily sell you their entire database of license plate numbers and names and addresses. Ted From kkargel at polartel.com Thu Dec 3 14:50:24 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 3 Dec 2009 13:50:24 -0600 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> <4B15453D.2070309@ipinc.net> <4B1594BE.1070004@ipinc.net> <4201421D-9940-4EF2-90FB-EC0657515B1C@tcb.net> <4B16B7A4.6080901@ipinc.net> <75822E125BCB994F8446858C4B19F0D79EFB299E@SUEX07-MBX-04.ad.syr.edu> <8695009A81378E48879980039EEDAD287B279F69@MAIL1.polartel.local> Message-ID: <8695009A81378E48879980039EEDAD287B279F78@MAIL1.polartel.local> Actually most often while on company business I do exactly that. There is a corporate name tag that has my name, my company address and phone number. Do you hide your identity while on business? I will even happily give you my contact info below.. with very minor digging I am sure you could duplicate it. Many others here do not hide their corporate identity while on the list. I notice Larry Ash included contact info in his signature. Best regards, Kevin Kargel Polar Communications,110 4th Street East,Park River, ND 58270 Tel: (701)284-7221 kkargel at polartel.com or sysadmin at polarcomm.com > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of lar at mwtcorp.net > Sent: Thursday, December 03, 2009 12:31 PM > To: 'arin ppml' > Subject: [arin-ppml] SWIPs & IPv6 > > Would you object if a locality required you to > wear your Name, Address and home phone number on your > outer jacket if you were out in public? > > We are talking about other people's privacy so let's not > be too quick to pooh-pooh their concerns. You know, even > paranoids have enemies. > > > Larry > > Kevin Kargel wrote: > > Milton, > > > > Just as when you go physically go out in public you reduce your privacy, > >people can take your picture, publish your whereabouts, write newspaper > >articles about what you are doing, make not of your car license plate, > tell > >others what it is.. just so when you conduct public business on the > >internet you lose some aspects of privacy. > > > > When your network interacts with other networks you have an obligation > to > >be reachable and contactable by those other networks. > > > > If you don't want people to see you, if you don't want to play nicely > then > >stay home, pull your networks inside your own borders and stop > interacting > >with the world. > > > > > Larry Ash > Network Administrator > Mountain West Telephone > 400 East 1st St. > Casper, WY 82601 > Office 307 233-8387 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mueller at syr.edu Thu Dec 3 15:15:46 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 3 Dec 2009 15:15:46 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: Message-ID: <75822E125BCB994F8446858C4B19F0D79EFB7A18@SUEX07-MBX-04.ad.syr.edu> Tom, there's a logical fallacy in your attempt to avoid the drivers license (DL) analogy: you have assumed that defeating the analogy justifies the existing system, in which anyone has access to potentially sensitive contact information. But it doesn't. Even if you undermine the analogy (and I don't agree you have) you are failing to deal with the critical point behind it: people can abuse access to information just as much as they can abuse the resources. If anonymous use of Internet resources can cause problems, so can anonymous access to important information about the internet. Why is this even controversial? I wonder why you are so keen to resist this point? If an auto license could be costlessly mapped to personal contact info, we all know that there would be serious abuses due to road rage, stalking, theft, etc. The simple fact is that we can have road system accountability without allowing people to go to an open, public database and, without any trace of their action or any authorization, look up the name and home address of any car they encountered on the road. Nothing you've said undermines the salience of that fact. To repeat, I am utterly baffled by your need to deny that this is an issue. What value do you think you are defending? If it is the crazy idea that open Whois creates a peer production commons in which all of global society contributes to the accuracy of Whois data, then someone needs to wake you up. A great deal of the inaccuracy or indirection associated with Whois data is caused by people's awareness that it is open and public and any goofball can download it and do all kinds of things with it. The privacy services mentioned earlier are a market response to that fact; inaccurate or disguised data is another. If the system doesn't protect people's legitimate needs for data security they will do what they can on their own. If you want accuracy, you must deliver security and more restricted usage/appropriation of the data. That is an inherent, unavoiable tradeoff in any system of data collection and retrieval. Further, your attempt to undermine the DL analogy doesn't even work. You are not required by law, but you are required by the operation of the Internet to obtain a unique identifier, either an IP address from an identifiable provider, or a domain name, or both. You are required to get an ORGID if you get IP addresses. You may need to register with a national regulator as an ISP. Organizations and people (not just "guys") with the ability to mete out real consequences are cruising around - both the ISPs and the LEAs and other civil litigants who you may wrong. There are legal mechanisms for reuqesting confidential account information, wiretapping phones, data surveillance, etc. Talk to a brand protection service if you want to know how systematic and automated private monitoring has become; I can point you to a few. Indeed, you are far more visible on the internet than you are on the road. Your third point is meaningless and doesn't distinguish the two situations at all. I am as interested in preserving the autonomy and self-regulatory nature of the Internet as anyone on this list. When you fail to see the abuses and problems caused by creating completely open databases with anonymous retrieval, you are doing that cause a great disservice. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org From cengel at sponsordirect.com Thu Dec 3 15:29:04 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Thu, 3 Dec 2009 15:29:04 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <8695009A81378E48879980039EEDAD287B279F70@MAIL1.polartel.local> Message-ID: Kevin, I am assuming (perhaps incorrectly) that ARIN's real interest in having accurate contact information for the sub-delegates of a block is to have some means of investigating whether the justifications for IP-Address space assignments that the top level block holder (i.e. the ISP) requests are legitimately justified? I mean ARIN's core mission is not the police the internet and make sure no-one setup an open relay right? I can see how ARIN staff certainly need access to the legitimate contact info of the actual sub-delegates for the purpose of determining address space justification... and can be held accountable for the legitimate use of that information. However, I would see no need for that information to actualy be made public to meet that end....and ARIN should probably decline to reveal such information absent a Court Order. The need to be able to communicate with parties responsible for a particular address block by the general public when there is a problem originating with that address block is genuine and useful but I would posit that it is an entirely seperate issue from the one described above and may not even fall within the scope of ARIN's core responsibilty. I would posit that it really properly falls within the responsibilty of the individual ISP's to be responsible for how their sub-delegates use the services provided to them....and to be responsible for addressing any abuses caused by those services. Exactly HOW they go about achieving that end should probably be left upto them. Essentialy I see it as a chain of responsibilty. ARIN is responsible for dealing out top level block assignments and for making sure that those assignments can be traced to the entities who hold them... and I see no issue with ARIN having a requirement that THOSE entities publish contact information for reporting abuse/problems. The top level block holder (ISP) is responsible for the registration of the sub-delegates who use it's services.... and it really should be upto them to best determine how to facilitate that. If it fails in meeting that basic responsibility I'm assuming it COULD be held legaly responsible by any parties damaged by that.... which should be plenty of incentive to institute an effective means of dealing with such problems (at least in countries where the rule of law has some weight). Likewise the sub-delegate (i.e. Company/Organization) is responsible for tracking the activity of the individual end-users/machines that use it's network space and any problems they might be accountable for....if the sub-delegate fails in that responsibility, they certainly could be held legaly accountable... but it really is best left upto them to determine the method for doing so. As a Network Admin, I support the use of a public WHOIS service...As I said, my company makes it's info public.... but I'd rather see that as an encouraged option rather then a required mandate...and I can certainly understand why some individuals/organizations would legitimately want to have a gate-keeper obfuscate that information for them. Christopher Engel -----Original Message----- From: Kevin Kargel [mailto:kkargel at polartel.com] Sent: Thursday, December 03, 2009 1:40 PM To: Chris Engel; 'arin-ppml at arin.net' Subject: RE: [arin-ppml] SWIPs & IPv6 So then is it being suggested that ARIN act as a gatekeeper and keep legitimate information behind a wall, and when needed that information is needed it can be requested by a legitimate party from ARIN but not directly exposed to the public? Would ARIN require and verify the information? I would be willing to support such a proposal. Having the proper information one step away would be superior to having the information obfuscated as it currently is in many instances. I would still like to see the transparency of top level company information be transparent and public, but I would accept technical POC and other contact information being secured with ARIN as custodian. From tvest at eyeconomics.com Thu Dec 3 15:38:38 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Thu, 3 Dec 2009 15:38:38 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D79EFB7A18@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D79EFB7A18@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Dec 3, 2009, at 3:15 PM, Milton L Mueller wrote: > Tom, > there's a logical fallacy in your attempt to avoid the drivers > license (DL) analogy: you have assumed that defeating the analogy > justifies the existing system, in which anyone has access to > potentially sensitive contact information. Hi Milton, Is there some reason that you ignored the questions in the message that I sent *before* I responded to Chris' driver's license analogy? It seems to have founds its way safely to the ppml archive: http://lists.arin.net/pipermail/arin-ppml/2009-December/015680.html On the outside chance that you didn't receive the message, I've copied it again below. I'm assuming here that you're not planning to "defeat" my questions by simply ignoring them...? I think that defeating them in the more conventional way (i.e., by answering them) would be more constructive. As you may note, the questions that I posed to you have nothing in particular to do with specific institutions, past, present, or imaginary. They have to do with properly defined functions of an Internet protocol number resource registry, and the source(s) of incentives and disincentives that might make it possible for a properly functioning registry to be sustainable over time (a) based solely on voluntary participation, and/or (b) in an environment of competitive registration service delivery. I look forward to your responses. TV >> Tom: >> >> Privacy norms, standards and laws are well known and not that hard >> to apply to this case. >> Here is a link to a boilerplate explanation of basic data >> protection principles: >> http://www.recordsmanagement.ed.ac.uk/InfoStaff/DPstaff/DPPrinciples.htm >> Respectful suggestion: do some homework on how this issue gets >> handled before wading into a policy arena with global human rights >> implications. > > Hi Milton, > > Thanks for the respectful suggestion. I will take it under advisement. > > However, I would respectfully suggest that providing more > substantive answers here would be useful both to you (if your goal > is, in fact, to help inform number resource policies), as well as to > those list members who are not likely to go off and do a lot of > homework on this issue. > >>> 1. Would you say that the proper balance between these two opposing >>> goals is reflected in current DNS whois arrangements? >> >> Absolutely not. (And you know perfectly well that I've answered >> this question, not only on this list, but in lengthy scholarly >> articles, and in years of work on DNS Whois Working Groups and Task >> Forces.) >> >> It would be very easy for DNS Whois to contain the requisite >> technical information needed for both law enforcement and technical >> management without providing indiscriminate public access to anyone >> and everyone, for any purpose. > > Okay, in that case I call: > > 1. Could you suggest how, exactly, a registration/whois system can > be both very accurate, very reliable, and very easy for technical > administrators to access (when justified) for real-time network > management requirements*, while at the same time satisfying the the > legitimate* privacy concerns of the individuals and institutions who > are represented in that registration data? > > 2. Could you also suggest how those conditions that are accurately > deemed to be legitimate*, required*, etc. by both groups might be > sustained over time? Specifically, if revelation of whois > inaccuracies is generally only possible as a result of outages or > other "events" that require technical administrator action, and > discovery of correct whois information in such cases is generally > only possible through legal mechanisms (warrants, subpoenas, > lawsuits, registry disaccreditations, etc.) which do not operate at > time scales that are consistent with real-time network management, > what method(s) would you propose for reconciling this critical > mismatch? > > 3. Finally (and if appropriate), could you also suggest how those > conditions might be preserved in an environment of competitive > commercial provision of registration and whois services? > Specifically, what mechanisms would you recommend to encourage > registration and whois service providers to maintain the proper > level of investment in and ongoing support for this secondary, non > profit-making function? What mechanisms would you advocate to assure > that individual commercial registration and whois service providers > resist the temptation to differentiate themselves by cutting their > whois-related support and/or by relaxing their whois-related > customer requirements? > > Since (3) presumes that you advocate the competitive provision of > registration and whois services, with at least some competitors > being private/not-governmental entities, please disregard this > question if this presumption is inaccurate. > >> The only reason this doesn't happen: DNS Whois arrangements have >> been hijacked by trademark protection firms, LEAs too lazy to get >> the proper authorizations, and by companies that collect and sell >> the data for various and sundry purposes. See data protection >> principle #2 for my opinion about that. > > If I'm interpreting your reference correctly, data protection > principle #2 reads: > "Personal data shall be obtained only for one or more specified and > lawful purposes, and shall not be further processed in any manner > incompatible with that purpose or those purposes." > > If we stipulate for the moment that we're only talking about > protocol number whois as used for legitimate technical > administrative purposes that are consistent with the law, then the > relevance of data protection principle #2 is still ambiguous. One > justification for open public whois is that public scrutiny provides > a kind of continuous distributed error detection and correction > mechanism, which helps to maintain whois completeness and accuracy > in between those critical moments when technical-administrative > action is both legal and justified -- and at which points the > belated discovery of whois inaccuracies can have the most adverse > consequences. > > Is it your view that the very existence and/or maintenance of > accurate personal data should be subject to a different, higher > standard than the standard suggested by data protection principle #2? > >>> 2. Are the "legitimate privacy concerns" of artificial >>> persons (i.e., >>> corporations) different from the "legitimate privacy concerns" of >>> natural persons? >> >> Sigh. Overlooking your complete ignorance of applicable law, I will >> simply answer yes. >> The distinction is well-established in law, not to mention common >> sense. Yes, Tom, there are differences between the privacy rights >> and legal norms applicable to publicly registered corporate >> entities and flesh and blood persons and their homes and personal >> property. > > Ignoring the insult, I'll just observe again that a less clever but > more substantive response would have probably been more useful, to > you and everyone else. > >>> If so, how -- and how should the differences be >>> reflected in rotocol number-related registration data and whois? >> >> Yes, of course the differences should be reflected. How? Not that >> hard, but as I said in my last message, let's debate specific >> arrangements and proposals, not ideology. > > Excellent. Here's your chance to debate specifics. > > It's good to know that it won't be that hard... > > Thanks, > > TV From bill at herrin.us Thu Dec 3 16:01:54 2009 From: bill at herrin.us (William Herrin) Date: Thu, 3 Dec 2009 16:01:54 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: <8695009A81378E48879980039EEDAD287B279F70@MAIL1.polartel.local> Message-ID: <3c3e3fca0912031301h7db77905of29d07599890f160@mail.gmail.com> On Thu, Dec 3, 2009 at 3:29 PM, Chris Engel wrote: > I mean ARIN's core mission is not the police the internet > and make sure no-one setup an open relay right? Chris, No more than ARIN's core missing is to set Internet routing policy. Facilitating communication between end-user networks is not number resource policy. I have no particular objection to expanding ARIN's core mission to include it. I'd probably even vote for doing so. But until then I think discussion of SWIP policy predicated on factors other than resource justification is out of order. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From stephen at sprunk.org Thu Dec 3 17:14:42 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 03 Dec 2009 16:14:42 -0600 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B18110A.2070107@ipinc.net> References: <4B18110A.2070107@ipinc.net> Message-ID: <4B183852.4050902@sprunk.org> Ted Mittelstaedt wrote: > Not only that, but in actual fact it's ridiculously easy to get > license plate data from the DMV. All you have to do is go down to the > county, pay $200 for a business license, list your occupation as "mass > marketer" then take that to the DMV and they will happily sell you > their entire database of license plate numbers and names and addresses. Well, I don't think we want to make things easier for spammers, which is what that parallel suggests... More relevant to the intended use of WHOIS, one can send a letter to my state's DOT asking for the registrant of a particular license plate number, and they will reply with the requested informoation at no cost. One has to state they have a "compelling need" (to satisfy state law), but there is no requirement to say what that need actually is, so it's a no-op. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From kkargel at polartel.com Thu Dec 3 17:39:53 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 3 Dec 2009 16:39:53 -0600 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B183852.4050902@sprunk.org> References: <4B18110A.2070107@ipinc.net> <4B183852.4050902@sprunk.org> Message-ID: <8695009A81378E48879980039EEDAD287B279F81@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Stephen Sprunk > Sent: Thursday, December 03, 2009 4:15 PM > To: Ted Mittelstaedt > Cc: Chris Engel; 'arin-ppml at arin.net' > Subject: Re: [arin-ppml] SWIPs & IPv6 > > Ted Mittelstaedt wrote: > > Not only that, but in actual fact it's ridiculously easy to get > > license plate data from the DMV. All you have to do is go down to the > > county, pay $200 for a business license, list your occupation as "mass > > marketer" then take that to the DMV and they will happily sell you > > their entire database of license plate numbers and names and addresses. > > Well, I don't think we want to make things easier for spammers, which is > what that parallel suggests... > > More relevant to the intended use of WHOIS, one can send a letter to my > state's DOT asking for the registrant of a particular license plate > number, and they will reply with the requested informoation at no cost. > One has to state they have a "compelling need" (to satisfy state law), > but there is no requirement to say what that need actually is, so it's a > no-op. > > S > > -- > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking The solution for this, as has been suggested in other messages, would be to modify the ARIN mission statement to include facilitating communications between registrants, then allow registrants the option of hiding contact information but making it available to authenticated requests from members. This would of course break should a member abuse the privilege. Those of you who like new laws would possibly be satisfied by an enforceable AUP. I suspect though that changes of this magnitude are best discussed on lists other than ppml. From tedm at ipinc.net Thu Dec 3 18:03:26 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 03 Dec 2009 15:03:26 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <28E139F46D45AF49A31950F88C497458045BC333@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458045BC333@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B1843BE.908@ipinc.net> michael.dillon at bt.com wrote: > >> Now, the problem here is that the org isn't DELIBERATELY >> going out and violating section 5b, it's just accumulated >> mistakes. At what point does ARIN state the org is in >> violation of section 5b? > > Why throw vinegar at people? You'll get further ahead by > honeying them up with help to reduce the mistakes. If ARIN > states that an org is in violation, the organization could > sue ARIN, and obtain a court order preventing ARIN from taking > any further action until the lawsuit is completed and the > courts have decided who is at fault. > I think you read my sentence a bit wrong, I was not meaning ARIN identify a specific org, I was using "the org" as a noun. Poor wordsmithing on my part. ARIN should state at what point is that if an org crosses it, it's no longer acceptable error. > ARIN needs to focus on education and on removing barriers. > In order to remove barriers, ARIN needs a better process > for publishing a contact directory, and better tools for > ISPs to use. > > This is not like the current work of providing an alternative > to emailed SWIPs, because people do not have a big investment > in IPv6 tools. This is an opportunity for ARIN and the community > to design something right and to implement it well. > In particular, if it is open source, then many companies > can contribute to it. > >> And the larger question is, what constitutes "maintenance of >> directory services data...data concerning any organization to >> which it further sub-delegates" > > This would be easier to define and audit if both orgs are > running the same directory server which can be queried to > test any criteria that you want. > I think that the Rwhois server code should serve as a guide. What's the biggest problem with the "reference" Rwhois server that was written and published that does pretty much exactly what your talking about? I'll tell you, it's the inputting and management of the data. If they had released that server with a webinterface that made it easy as pie for a grunt to just pound in the data, then it would have taken over SWIPS and whois by now and this discussion wouldn't even be happening. Unfortunately the entire focus was on the server logic and internal query logic, and database, and the interface to get data in and out of it sucks rocks. If ARIN decides to go in this direction again, I would like to see them produce an add-on interface to HaCi, which already implements the GUI front-end, and IP management stuff, for both IPv4 and IPv6. > Wordsmithing the RSA will not solve any problems, just make > the problems get into the courts sooner. > What it would do is enhance ARIN's hand when it DOES get into the courts. And who cares how soon or not the problem gets into the courts, are we all playing The Delaying Game here? Chuck Barris retired years ago. > Do we want to fix the problem or do we want to hit people > over the head with brickbats? > How bout we speak softly and carry a big brickbat? ;-) Ted > --Michael Dillon > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From cengel at sponsordirect.com Thu Dec 3 18:13:54 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Thu, 3 Dec 2009 18:13:54 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: Message-ID: Ted, I supported what Milton posted because I happaned to aggree with the point he was making not because I was trying to score points with him. I'm sure there are any number of other issues that he and I will disagree on and he is more then welcome to come after me like a pit bull on them if he so desires. The privacy restrictions that the DMV might operate under vary wildly from state to state....and yes I will conceede that there are MANY states that are woefully lacking in that regard. Perhaps I should have been more explicit on which states the analogy would be accurate under and which it wouldn't. Anyway, what I see is 2 seperate and distinct needs here... ARIN in it's role as a numbers registry (presumably) needs to know the ACTUAL entities who are using an IP address block and what it is being used for. It needs to do this (I presume) in order to independantly verify the justification for the request of an additional assignment.....and likely contact info of the ISP's NOC is not sufficient for that purpose given that it would be the ISP's request that was being verified. You, as Joe Public, really don't need to know WHO holds a particular address block....you just need to know what that address block is and how to go about reporting problems caused by it. You don't really need to know who that entity is to accomplish that...just where to report the issue. The point where you would need to know the actual identity of the block holder is likely the point at which law enforcment or the courts should be getting involved anyway. Note, I personaly think there is value in a public WHOIS directory and don't mind participating in it myself.... but it's not like I work for Salman Rushdie's publisher or anything like that. The many people who I annoy generaly aren't going to do anything more harsh then tell me I'm a moron. I CAN see organizations that do have legitimate privacy concerns about something like WHOIS. Christopher Engel From tedm at ipinc.net Thu Dec 3 18:20:26 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 03 Dec 2009 15:20:26 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <3c3e3fca0912031301h7db77905of29d07599890f160@mail.gmail.com> References: <8695009A81378E48879980039EEDAD287B279F70@MAIL1.polartel.local> <3c3e3fca0912031301h7db77905of29d07599890f160@mail.gmail.com> Message-ID: <4B1847BA.9090606@ipinc.net> William Herrin wrote: > On Thu, Dec 3, 2009 at 3:29 PM, Chris Engel wrote: >> I mean ARIN's core mission is not the police the internet >> and make sure no-one setup an open relay right? > > Chris, > > No more than ARIN's core missing is to set Internet routing policy. > > Facilitating communication between end-user networks is not number > resource policy. I have no particular objection to expanding ARIN's > core mission to include it. I'd probably even vote for doing so. But > until then I think discussion of SWIP policy predicated on factors > other than resource justification is out of order. > William, ARIN's mission IS ALSO to guarantee uniqueness of the allocated resources. There is no way to justify to an applicant that the space they are getting is globally unique unless a PUBLIC database is available that lists all assigned IP number resources. That's what the WHOIS database is. Nobody would continue to pay money to ARIN unless they had proof that that uniqueness is being maintained in a manner that they can use to settle disputes between another entity that is claiming their resources. If you obtain IP numbering from ARIN and ARIN does not publically list the database, I can come to your upstream and claim that the numbers ARIN assigned to you actually belong to me, and that your squatting on them. If the WHOIS database is either private, or widely acknowledged by everyone to be stuffed full of bogus data, then your upstream cannot go to it and verify that your telling the truth and I'm a lying sack of monkey dung. So I do not see how you can make this claim that facilitating communication between registrants is not a number resource policy. Clearly, it is integral to maintaining a trusted registry. And as for facilitating communication between END-USER networks, well the exact same issue applies on disputes between end-user networks fighting over each other's numbering. Ultimately it's paramount that the RIR is seen as a completely unbiased, and impartial entity. Public disclosure is therefore called for. If ARIN says that Wonkulating Gronkulators has supplied justification allowing it to obtain an IPv4 /8, then why should the rest of us believe this is true unless we can go to the list of IP addresses and see for ourselves that Wonkulating does indeed have the requisite utilization. The same issues exist for IPv6 as well, it's just that the large orgs that make multiple IPv6 netblock requests will be much fewer than under IPv4. But your still going to have people trying to make trouble for each other in an IPv6 world by making bogus claims over each other's numbering, so the RIRs are going to continue to have to be viewed as an unbiased "last word" in who has what, and that will only be possible with a verifiable public whois. Ted From tedm at ipinc.net Thu Dec 3 18:52:37 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 03 Dec 2009 15:52:37 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: Message-ID: <4B184F45.2050805@ipinc.net> Chris Engel wrote: > Ted, > > I supported what Milton posted because I happaned to aggree with the > point he was making not because I was trying to score points with > him. I'm sure there are any number of other issues that he and I will > disagree on and he is more then welcome to come after me like a pit > bull on them if he so desires. > > The privacy restrictions that the DMV might operate under vary wildly > from state to state....and yes I will conceede that there are MANY > states that are woefully lacking in that regard. Perhaps I should > have been more explicit on which states the analogy would be accurate > under and which it wouldn't. > > Anyway, what I see is 2 seperate and distinct needs here... > > ARIN in it's role as a numbers registry (presumably) needs to know > the ACTUAL entities who are using an IP address block and what it is > being used for. It needs to do this (I presume) in order to > independantly verify the justification for the request of an > additional assignment.....and likely contact info of the ISP's NOC is > not sufficient for that purpose given that it would be the ISP's > request that was being verified. > > You, as Joe Public, really don't need to know WHO holds a particular > address block....you just need to know what that address block is and > how to go about reporting problems caused by it. You don't really > need to know who that entity is to accomplish that...just where to > report the issue. The point where you would need to know the actual > identity of the block holder is likely the point at which law > enforcment or the courts should be getting involved anyway. > > Note, I personaly think there is value in a public WHOIS directory > and don't mind participating in it myself.... but it's not like I > work for Salman Rushdie's publisher or anything like that. Nobody is holding a gun to anyone's head and telling them they HAVE to go get on to the Internet and request a big block of IP addressing. If you choose to be private, you can just not do that. It's also interesting to note that the notorious celebrities like Rushdie quite often DON'T choose to hide (and in fact do the exact opposite, Rushdie has been on plenty of British tabloids, and has had a string of supermodel girlfriends, etc.) Ted From michael.dillon at bt.com Thu Dec 3 20:39:31 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 4 Dec 2009 01:39:31 -0000 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C49745804616909@E03MVZ2-UKDY.domain1.systemhost.net> > I'm probably going to get blasted for this, but speaking on > the Enterprise side of things there are fairly understandable > reasons why Enterprise Admins might want to avoid public > disclosure of their contact information and why they > sometimes put in contact information that isn't well > monitored..... Whatever the reasons, they boil down to the fact that this enterprise admin is not ready, willing and able to act on communications about network operational issues. Network Operators and ARIN should say to such admins "We don't want your contact data. While you are ignoring the emails, who is looking after your network? That is who we want to be able to contact.". It is possible to test whether or not someone is ready, willing and able to act on communications by trying to contact them. An audit process, if you will. But there is no point in doing any kind of testing or auditing and no point in even attempting to keep the directory data clean unless we have established the principle that we only want contact data for those ready, willing and able to act. And we want 100% coverage of the allocated address space with such contacts. We don't want to chase up the hierarchy looking for a contact, we want the directory to give us the right contact, first time, every time. Any hierarchical lookup needs to be automatic. > Frankly, it's been my experience > that the volume and frequency of illegitimate use of this > information far outweighs the legitimate use of it. That's because our design mixes up identity information and contact information. We would like to have some identity information for assignees, but we don't need any contact info for them. No email addresses, no postal addresses, no phone numbers. There is never any need for us to contact these people. On the other hand, any organization that gets allocations or assignments from ARIN, needs to either maintain a NOC staffed with someone ready, willing and able to act on communication, or delegate that function to some other organization for specific address blocks. We shouldn't care who these people are, i.e. their identity is not relevant. But we do want to know how to contact them. NOC email address, NOC phone number, NOC IM account, NOC twitter account, NOC web page, NOC Facebook account, etc. ARIN can police the top level of this, i.e. the organizations that get resources directly from ARIN. The rest of it could potentially be policed by an audit process that would correct contact data by replacing inactive contacts with the contact for the larger aggregate. > Frankly, I'm not convinced of the utility of WHOIS > information in catching criminals/spammers. Being who they > are, those people almost never use their own systems to do > their dirty work and they don't generally give out legitimate > contact information that can be easily traced to them.... and > in cases where they do it's usually because they are > operating out of jurisdictions where it doesn't matter > because the local authorities won't do anything about it > (heck sometimes the guys doing it ARE the local authorities). This isn't terribly important. The bad guys leave clues and some people find these clues to be useful in an investigation. I think it is reasonable to request identity info for all assignees as long as that identity is not sufficient to help deranged people knock on someone's door, or competitors to get an easy customer list. Both these issues mostly impact the small end of the scale, i.e. individual subscribers, and small businesses. Once you get to businesses with multiple offices then listing XYZ Pharmaceuticals, Milwaukee is not going to ease the way for a competitor to steal the account. > The real utility of accurate contact information, I think > comes not in dealing with people who are actually committing > malicious acts but rather those who may have innocently > misconfigured their systems or may have been compromised by > hackers and who's resources are being used without their knowledge. And if you contact XYZ organization's ISP, they will have that accurate customer contact info in their customer file, and can take care of the problem because they are ready, willing and able to act. > So while maintaining accurate contact info is important, I > can see why their is a legitimate desire (by people who > aren't doing anything wrong) to have their info shielded as > well. Let's say that your teenage daughter uses some VOIP or file transfer tool that makes direct connections, thus disclosing her IP address to the recipient. And let's say that the recipient is a male predator looking for vulnerable teenage girls. He looks up the IP address, finds your name and phone number on it, and using other means which are readily available he gets your home address. At 3 am the next morning, he snips your phone line, cuts your power, breaks a window, and climbs into your daughter's bedroom with chloroform at the ready. You aren't doing anything wrong so there is no legitimate reason for you to have your info shielded, is there? Fact is that we should be asking "Who has a need to know?" and "How much do they need to know?". --Michael Dillon From michael.dillon at bt.com Thu Dec 3 20:49:09 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 4 Dec 2009 01:49:09 -0000 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C4974580461690A@E03MVZ2-UKDY.domain1.systemhost.net> > I am assuming (perhaps incorrectly) that ARIN's real interest > in having accurate contact information for the sub-delegates > of a block is to have some means of investigating whether the > justifications for IP-Address space assignments that the top > level block holder (i.e. the ISP) requests are legitimately > justified? Then you assume incorrectly. ARIN does not publish data because they need that data. We are discussing what data should be published in a public directory. That is entirely separate from the data that ARIN needs. They can and do request all kinds of data from applicants and that data is kept secret under NDA, and is also not available to most ARIN employees due to a chinese wall that they have in place. > Essentialy I see it as a chain of responsibilty. I see it as a hierarchy created by a chain of relationships. And I see no need to centralize everything the way that RIPE does and the way that SWIP used to do. --Michael Dillon From jcurran at arin.net Thu Dec 3 21:41:51 2009 From: jcurran at arin.net (John Curran) Date: Thu, 3 Dec 2009 21:41:51 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: Message-ID: <4B9F0A0D-2194-43F0-8EAD-63D1E4C28FBC@arin.net> On Dec 3, 2009, at 3:13 PM, Chris Engel wrote: > ... > You, as Joe Public, really don't need to know WHO holds a particular address block....you just need to know what that address block is and how to go about reporting problems caused by it. You don't really need to know who that entity is to accomplish that...just where to report the issue. The point where you would need to know the actual identity of the block holder is likely the point at which law enforcment or the courts should be getting involved anyway. Chris - There's several reasons that have been cited in the past for having to know the holder of a block, and while that includes the law enforcement angle, there's also abuse & copyright mitigation, operational attack response, and end-to-end network problem diagnosis. I haven't been running a network personally in a few years, so I don't know the extent to which these are still valid but mention them for consideration. Also, it's important to note that it is not going to be one contact that you need, as address allocation is hierarchical in nature. So, if network contacts aren't publicly visible, what we're really saying that you get the contact for the master block, and ask them for the contact for their sub-delegation, then contact that entity to repeat as necessary until you get the contact for the end-user assignment. This could indeed could be workable, but that likely depends on the timeliness that is needed in response. Interesting issues to consider, /John John Curran President and CEO ARIN From mueller at syr.edu Fri Dec 4 10:38:37 2009 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 4 Dec 2009 10:38:37 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <28E139F46D45AF49A31950F88C49745804616909@E03MVZ2-UKDY.domain1.systemhost.net> References: , <28E139F46D45AF49A31950F88C49745804616909@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <75822E125BCB994F8446858C4B19F0D79F0A7692@SUEX07-MBX-04.ad.syr.edu> ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com [michael.dillon at bt.com] >Fact is that we should be asking "Who has a > need to know?" and "How much do they need to know?". Exactly. thanks for a reasonable consideration of this factor So, in constructing a new SWIPS, or translation of old (ipv4) to new (ipv6) SWIPS or Whois policy, it makes sense to apply the basic DP Principle #2 and carefully define the purpose of the information being collected, and then try to align information collection and publication to that which is necessary to fulfill that purpose. That's all I am saying. From mueller at syr.edu Fri Dec 4 10:55:16 2009 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 4 Dec 2009 10:55:16 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B1847BA.9090606@ipinc.net> References: <8695009A81378E48879980039EEDAD287B279F70@MAIL1.polartel.local> <3c3e3fca0912031301h7db77905of29d07599890f160@mail.gmail.com>, <4B1847BA.9090606@ipinc.net> Message-ID: <75822E125BCB994F8446858C4B19F0D79F0A7693@SUEX07-MBX-04.ad.syr.edu> Ted Many of the points you make below are perfectly reasonable. To the extent that the RIR functions as a title agency for number resources (what you call "guaranteed uniqueness"), it does provide a public service and some aspects of the title claim need to be made public. The issue is what specific data elements, made available to whom, under what circumstances? If the purpose of the data is authentication of an exclusivity claim to a number block, then we need to identify which organizational or personal identity information needs to be associated with the registry record and we also need to define reasonable access policies to fulfill those purposes. To say that we are presented with a radically dichotomous choice between no record/no access and indiscriminate public access for any purpose at any time does not follow, either logically or operationally. In the original question raised by D. Macpherson, the issue was subdelegations of large blocks of IPv6. Obviously, the RIR system can "know" and verify that a block has been exclusively delegated to ISP X without knowing who ISP X's customers are and which blocks have been subdelegated. If those subdelegations start moving their blocks to another ISP, then the records do need to reflect that. The point is, thes problems and debates are resolvable if we stick to clearly defined purposes. --MM ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt [tedm at ipinc.net] Sent: Thursday, December 03, 2009 6:20 PM To: William Herrin Cc: Chris Engel; arin-ppml at arin.net Subject: Re: [arin-ppml] SWIPs & IPv6 William Herrin wrote: > On Thu, Dec 3, 2009 at 3:29 PM, Chris Engel wrote: >> I mean ARIN's core mission is not the police the internet >> and make sure no-one setup an open relay right? > > Chris, > > No more than ARIN's core missing is to set Internet routing policy. > > Facilitating communication between end-user networks is not number > resource policy. I have no particular objection to expanding ARIN's > core mission to include it. I'd probably even vote for doing so. But > until then I think discussion of SWIP policy predicated on factors > other than resource justification is out of order. > William, ARIN's mission IS ALSO to guarantee uniqueness of the allocated resources. There is no way to justify to an applicant that the space they are getting is globally unique unless a PUBLIC database is available that lists all assigned IP number resources. That's what the WHOIS database is. Nobody would continue to pay money to ARIN unless they had proof that that uniqueness is being maintained in a manner that they can use to settle disputes between another entity that is claiming their resources. If you obtain IP numbering from ARIN and ARIN does not publically list the database, I can come to your upstream and claim that the numbers ARIN assigned to you actually belong to me, and that your squatting on them. If the WHOIS database is either private, or widely acknowledged by everyone to be stuffed full of bogus data, then your upstream cannot go to it and verify that your telling the truth and I'm a lying sack of monkey dung. So I do not see how you can make this claim that facilitating communication between registrants is not a number resource policy. Clearly, it is integral to maintaining a trusted registry. And as for facilitating communication between END-USER networks, well the exact same issue applies on disputes between end-user networks fighting over each other's numbering. Ultimately it's paramount that the RIR is seen as a completely unbiased, and impartial entity. Public disclosure is therefore called for. If ARIN says that Wonkulating Gronkulators has supplied justification allowing it to obtain an IPv4 /8, then why should the rest of us believe this is true unless we can go to the list of IP addresses and see for ourselves that Wonkulating does indeed have the requisite utilization. The same issues exist for IPv6 as well, it's just that the large orgs that make multiple IPv6 netblock requests will be much fewer than under IPv4. But your still going to have people trying to make trouble for each other in an IPv6 world by making bogus claims over each other's numbering, so the RIRs are going to continue to have to be viewed as an unbiased "last word" in who has what, and that will only be possible with a verifiable public whois. Ted _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From mueller at syr.edu Fri Dec 4 10:55:43 2009 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 4 Dec 2009 10:55:43 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B9F0A0D-2194-43F0-8EAD-63D1E4C28FBC@arin.net> References: , <4B9F0A0D-2194-43F0-8EAD-63D1E4C28FBC@arin.net> Message-ID: <75822E125BCB994F8446858C4B19F0D79F0A7694@SUEX07-MBX-04.ad.syr.edu> This is precisely what I fear. An expansive definition of the RIRs role can easily make them enforcement arms of the copyright industry . RIRs should serve a very narrow purpose and any additional loading of functions onto them must come from laws enacted by representative legislators subject t constitutional constraints, not by little bands of engineers trying to be "helpful" ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of John Curran [jcurran at arin.net] Chris - There's several reasons that have been cited in the past for having to know the holder of a block, and while that includes the law enforcement angle, there's also abuse & copyright mitigation, operational attack response, and end-to-end network problem diagnosis. I haven't been running a network personally in a few years, so I don't know the extent to which these are still valid but mention them for consideration. From spiffnolee at yahoo.com Fri Dec 4 12:36:52 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Fri, 4 Dec 2009 09:36:52 -0800 (PST) Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D79F0A7694@SUEX07-MBX-04.ad.syr.edu> References: , <4B9F0A0D-2194-43F0-8EAD-63D1E4C28FBC@arin.net> <75822E125BCB994F8446858C4B19F0D79F0A7694@SUEX07-MBX-04.ad.syr.edu> Message-ID: <638797.96440.qm@web63302.mail.re1.yahoo.com> The parameters for ARIN's operations should be broader than "the minimum required by law." One of the most interesting debates in this community was the meeting discussion of Policy Proposal 2005-2: Directory Services Overhaul. https://www.arin.net/participate/meetings/reports/ARIN_XV/ppm_minutes_day2.html It seemed that as we began the topic during the meeting, the community was leaning toward privacy. We had input from some members of our community, who are also members of several governments' agencies, which I think persuaded the community. That was almost five years ago, and certainly opinions may change. Debate is good; informed debate is even better. So, take ten minutes to read the minutes from ARIN XV on 2005-2. Lee ________________________________ From: Milton L Mueller To: John Curran ; Chris Engel Cc: "arin-ppml at arin.net" Sent: Fri, December 4, 2009 10:55:43 AM Subject: Re: [arin-ppml] SWIPs & IPv6 This is precisely what I fear. An expansive definition of the RIRs role can easily make them enforcement arms of the copyright industry . RIRs should serve a very narrow purpose and any additional loading of functions onto them must come from laws enacted by representative legislators subject t constitutional constraints, not by little bands of engineers trying to be "helpful" ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of John Curran [jcurran at arin.net] Chris - There's several reasons that have been cited in the past for having to know the holder of a block, and while that includes the law enforcement angle, there's also abuse & copyright mitigation, operational attack response, and end-to-end network problem diagnosis. I haven't been running a network personally in a few years, so I don't know the extent to which these are still valid but mention them for consideration. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cengel at sponsordirect.com Fri Dec 4 12:52:36 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Fri, 4 Dec 2009 12:52:36 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B9F0A0D-2194-43F0-8EAD-63D1E4C28FBC@arin.net> Message-ID: John, I'm not saying that Joe Public doesn't need contact information for a particular address block.... they don't need to know WHO they are contacting. For the purposes of anything that would need to be handled in a timely fashion (e.g. getting flooded with packets from a misconfigured router), all they would need is the phone number and a contact e-mail for who-ever can act technicaly on that information. They don't need to know the actual IDENTITY of the sub-delegate. The only legitimate reason why THEY, not ARIN, would need to know the IDENTITY of the block holder would be the kind of stuff (lawsuits or criminal investigations) that doesn't neccesitate a timely response and which would appropriately involve the Courts anyway. More explicitly here is what WHOIS asks you to provide...... Block-Holder org: (required) street: (required) city: (only optional for non-US) state: (only optional for non-US) zipcode: (only optional for non-US) cntry: (required) maint: (required) Technical Contact nichandl: (optional, if a user handle is not currently assigned; required if assigned) lname: (required) fname: (required) mname: (optional) org: (required) street: (required) city: (only optional for non-US) state: (only optional for non-US) zipcode: (only optional for non-US) cntry: (required) phne: (required) mbox: (optional) Here is what Joe Public ACTUALY needs to know in order to deal with any of the issues you mentioned.... Technical Contact Phone #: Technical Contact E-mail: Hopefully the difference is blatantly obvious. Furthermore for alot of sub-delegates (particularly under IPv6) it would actually make more sense to list their ISP's NOC under the Technical Contact info. Most small enterprises (and certainly private individuals) DON'T have NOC's and DON'T have 24/7 staffing. So what are you going to do if the problem you need resolved is happening at 2:00 AM on Saturday??? Do you expect people to list thier private cell phone #'s on a publicly accessable WHOIS lookup? Are you going to require anyone that has a sub assignment of more then 8 static IP's to have 24/7 coverage themselves?? (Even under IPv6). I believe people need to think this through a little bit more. Most organizations and individuals who contract for an assignment of an IP address block through an ISP aren't going to have much problem with the ISP having thier contact info... including even after hours/emergency contact info. They know who thier ISP is and they know how the ISP will be using that info.... but to have that info published publicly for anyone to look up for any purposes.... alot of people are going to be hesitant about that. Your best bet for getting people to voluntarly comply is to assure them that any information they provide will only be divulged on a need to know basis and only then only the minimum information neccesary for the task. Let them use thier ISP's or other trusted agents as Gatekeepers for thier info where appropriate. Christopher Engel -----Original Message----- From: John Curran [mailto:jcurran at arin.net] Sent: Thursday, December 03, 2009 9:42 PM To: Chris Engel Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] SWIPs & IPv6 On Dec 3, 2009, at 3:13 PM, Chris Engel wrote: > ... > You, as Joe Public, really don't need to know WHO holds a particular > address block....you just need to know what that address block is and > how to go about reporting problems caused by it. You don't really need > to know who that entity is to accomplish that...just where to report > the issue. The point where you would need to know the actual identity > of the block holder is likely the point at which law enforcment or the > courts should be getting involved anyway. Chris - There's several reasons that have been cited in the past for having to know the holder of a block, and while that includes the law enforcement angle, there's also abuse & copyright mitigation, operational attack response, and end-to-end network problem diagnosis. I haven't been running a network personally in a few years, so I don't know the extent to which these are still valid but mention them for consideration. Also, it's important to note that it is not going to be one contact that you need, as address allocation is hierarchical in nature. So, if network contacts aren't publicly visible, what we're really saying that you get the contact for the master block, and ask them for the contact for their sub-delegation, then contact that entity to repeat as necessary until you get the contact for the end-user assignment. This could indeed could be workable, but that likely depends on the timeliness that is needed in response. Interesting issues to consider, /John John Curran President and CEO ARIN From kkargel at polartel.com Fri Dec 4 13:39:36 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 4 Dec 2009 12:39:36 -0600 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: <4B9F0A0D-2194-43F0-8EAD-63D1E4C28FBC@arin.net> Message-ID: <8695009A81378E48879980039EEDAD287B279F93@MAIL1.polartel.local> > Your best bet for getting people to voluntarly comply is to assure them > that any information they provide will only be divulged on a need to know > basis and only then only the minimum information neccesary for the task. > Let them use thier ISP's or other trusted agents as Gatekeepers for thier > info where appropriate. I have no problem with the Tech contact not being an individual, in fact so long as it is responsive I would prefer it to be a role account. Having individual contact info for Joe Geek does me no good if he is on vacation sunning on a beach in Bermuda or laid up with H1N1. I also have no problem with the contact being a gatekeeper, so long as it is reasonably proximate to a responsive cognizant office. What I would have a problem with would be if the contact were a registrar who could relay to the LIR who would relay to the top ISP who would relay to the secondary ISP who would relay to the company who would relay to the tech staff. That could present unacceptable timeliness. From jradel at vantage.com Fri Dec 4 13:56:38 2009 From: jradel at vantage.com (Jon Radel) Date: Fri, 04 Dec 2009 13:56:38 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <8695009A81378E48879980039EEDAD287B279F93@MAIL1.polartel.local> References: <4B9F0A0D-2194-43F0-8EAD-63D1E4C28FBC@arin.net> <8695009A81378E48879980039EEDAD287B279F93@MAIL1.polartel.local> Message-ID: <4B195B66.20300@vantage.com> Kevin Kargel wrote: > What I would have a problem with would be if the contact were a registrar who could relay to the LIR who would relay to the top ISP who would relay to the secondary ISP who would relay to the company who would relay to the tech staff. That could present unacceptable timeliness. > Though it can be hard to get the balance right. If you go all the way down to the company you sometimes end up talking to people who have no background to comprehend what is going on. I remember one surreal conversation with a contact who never did manage to move beyond the "who are you and where did you get my number" stage to deal with the "one of the PCs in your address block has a worm that's sending documents off the disk to all the addresses it can find and you might not want everyone getting these rather interesting documents about your paving bids to local governments that are popping out on my end" stage. I suspect a call from her ISP would have been a touch more comprehensible to her. --Jon Radel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3303 bytes Desc: S/MIME Cryptographic Signature URL: From tedm at ipinc.net Fri Dec 4 14:08:12 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 04 Dec 2009 11:08:12 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <28E139F46D45AF49A31950F88C49745804616909@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745804616909@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B195E1C.40100@ipinc.net> michael.dillon at bt.com wrote: > > Let's say that your teenage daughter uses some VOIP or file > transfer tool that makes direct connections, thus disclosing > her IP address to the recipient. And let's say that the > recipient is a male predator looking for vulnerable teenage > girls. He looks up the IP address, finds your name and phone > number on it, and using other means which are readily available > he gets your home address. At 3 am the next morning, he snips > your phone line, cuts your power, breaks a window, and climbs > into your daughter's bedroom with chloroform at the ready. Sorry but I can't resist shooting fish here Why is he cutting your phone line when he's going to chloroform her, thus trying to be silent enough not to wake up anyone who would try calling 911? Why are you not running into her room and wacking him on the head instead of tap tap tapping away on the phone? Why aren't you picking up your cell phone which is on the charger on the nightstand and calling 911? Why is he wasting time fooling with all this whois nonsense on the Internet when he can just drive around until he sees a yellow school bus and then follow one of those teenagers home? Why is it necessary for people to generate these outlandish and nonsensical analogies that anyone with a half a brain can blow holes into, to try to support some point about supposed whois privacy? Why do I even bother asking when I know the answer already - BECAUSE THE WHOIS PRIVACY POINT IS HOGWASH IN THE FIRST PLACE and the people pushing it cannot come up with a legitimate example so they make up silly ones. Ted From gtb at slac.stanford.edu Fri Dec 4 14:40:48 2009 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Fri, 4 Dec 2009 11:40:48 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B195E1C.40100@ipinc.net> References: <28E139F46D45AF49A31950F88C49745804616909@E03MVZ2-UKDY.domain1.systemhost.net> <4B195E1C.40100@ipinc.net> Message-ID: <6F51B50ECF32084788B9B3A8469A71B52917D541DB@EXCHCLUSTER1-02.win.slac.stanford.edu> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > Sent: Friday, December 04, 2009 11:08 AM > To: michael.dillon at bt.com > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] SWIPs & IPv6 > .... > Why do I even bother asking > when I know the answer already - BECAUSE THE WHOIS PRIVACY POINT > IS HOGWASH IN THE FIRST PLACE and the people pushing it > cannot come up with a legitimate example so they make up > silly ones. If you use the example of your local county property database, those records have a very clearly defined method of how to have individuals removed. In many jurisdictions one must show that you are at physical risk of injury or death (battered spouse, judge with death threats, etc.), and that removal is the least impactful way to protect those individuals. Avoiding protest marches in front of the home does not qualify. It is a high bar (although since these are often local decisions, the bar almost certainly is not at a constant height across the jurisdictions). There may very well be good reasons to not have accurate WHOIS data available. But I have yet to see a compelling argument that involves the equivalent of protecting the battered spouse. Gary From kkargel at polartel.com Fri Dec 4 14:53:57 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 4 Dec 2009 13:53:57 -0600 Subject: [arin-ppml] FW: SWIPs & IPv6 Message-ID: <8695009A81378E48879980039EEDAD287B279F9C@MAIL1.polartel.local> > Why is it necessary for people to generate these outlandish > and nonsensical analogies that anyone with a half a brain can > blow holes into, to try to support some point > about supposed whois privacy? Why do I even bother asking > when I know the answer already - BECAUSE THE WHOIS PRIVACY POINT > IS HOGWASH IN THE FIRST PLACE and the people pushing it > cannot come up with a legitimate example so they make up > silly ones. > > Ted Again Ted has a point, however non-pc it is presented. I would be interested to hear about how many brick and mortar businesses survive when they delist their phone number, take themselves out of the phone book, remove all advertising so nobody can contact them, and take all the signage off their store front. From michael.dillon at bt.com Fri Dec 4 17:25:29 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 4 Dec 2009 22:25:29 -0000 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B195E1C.40100@ipinc.net> Message-ID: <28E139F46D45AF49A31950F88C497458046174FC@E03MVZ2-UKDY.domain1.systemhost.net> > Why is he wasting time fooling with all this whois nonsense > on the Internet when he can just drive around until he sees a > yellow school bus and then follow one of those teenagers home? Because he doesn't want just any victim, he wants your daughter because his intent is to get revenge for something that you said on the Internet. > Why is it necessary for people to generate these outlandish > and nonsensical analogies that anyone with a half a brain can > blow holes into, Whoa there. Mentally deranged people don't have half a brain left after damaging it with angel dust and other chemicals. Also, you can only blow holes into specific instances. We have to consider the whole population of the ARIN region and statistically, there are a certain percentage of people who do go out and do this kind of stuff. We should make sure that we do not facilitate their misdeeds in any way. > Why do I even bother asking when I know the > answer already - BECAUSE THE WHOIS PRIVACY POINT IS HOGWASH > IN THE FIRST PLACE and the people pushing it cannot come up > with a legitimate example so they make up silly ones. This is not a silly example. You offended someone, they obtained your IP address from their web server logs or wherever, then they looked up your details in whois, went to your home and assaulted your family. The whois directory is a critical link in this chain, and many of us believe that ARIN should not be forcing ISPs to publish information that individuals do not want to have published. This is already a principle of ARIN policy with the private residence stuff, but many of us feel that it could be done in a more consistent and useful way. --Michael Dillon From warren at wholesaleinternet.com Fri Dec 4 17:40:38 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Fri, 4 Dec 2009 16:40:38 -0600 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <28E139F46D45AF49A31950F88C497458046174FC@E03MVZ2-UKDY.domain1.systemhost.net> References: <4B195E1C.40100@ipinc.net> <28E139F46D45AF49A31950F88C497458046174FC@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <0E041D6B93BA4925B510919769384C75@johnsonvhjjf8v> >From a business privacy standpoint, I would rather not have to publish the names of my customers who request their Ips be SWIPed. > Why do I even bother asking when I know the answer already - BECAUSE > THE WHOIS PRIVACY POINT IS HOGWASH IN THE FIRST PLACE and the people > pushing it cannot come up with a legitimate example so they make up > silly ones. This is not a silly example. You offended someone, they obtained your IP address from their web server logs or wherever, then they looked up your details in whois, went to your home and assaulted your family. The whois directory is a critical link in this chain, and many of us believe that ARIN should not be forcing ISPs to publish information that individuals do not want to have published. This is already a principle of ARIN policy with the private residence stuff, but many of us feel that it could be done in a more consistent and useful way. --Michael Dillon _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Fri Dec 4 19:13:34 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 04 Dec 2009 16:13:34 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <28E139F46D45AF49A31950F88C497458046174FC@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458046174FC@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B19A5AE.3070706@ipinc.net> michael.dillon at bt.com wrote: >> Why is he wasting time fooling with all this whois nonsense >> on the Internet when he can just drive around until he sees a >> yellow school bus and then follow one of those teenagers home? > > Because he doesn't want just any victim, he wants your daughter > because his intent is to get revenge for something that you > said on the Internet. > >> Why is it necessary for people to generate these outlandish >> and nonsensical analogies that anyone with a half a brain can >> blow holes into, > > Whoa there. Mentally deranged people don't have half a brain > left after damaging it with angel dust and other chemicals. > Also, you can only blow holes into specific instances. We have > to consider the whole population of the ARIN region and > statistically, there are a certain percentage of people who > do go out and do this kind of stuff. We should make sure that > we do not facilitate their misdeeds in any way. > >> Why do I even bother asking when I know the >> answer already - BECAUSE THE WHOIS PRIVACY POINT IS HOGWASH >> IN THE FIRST PLACE and the people pushing it cannot come up >> with a legitimate example so they make up silly ones. > > This is not a silly example. You offended someone, they obtained > your IP address from their web server logs or wherever, then > they looked up your details in whois, went to your home and > assaulted your family. The whois directory is a critical link > in this chain, and many of us believe that ARIN should not be > forcing ISPs to publish information that individuals do not > want to have published. As I have said before nobody is holding a gun to anyone's head and forcing them to be online. Despite reports to the contrary it is in fact possible to live life WITHOUT logging into the Internet. I know, I know, pretty revolutionary stuff, but there ARE actual real people out there who have never logged in. And no, they are NOT destitute! By contrast it really isn't possible to live modern life WITHOUT owning and driving an automobile. Thus the license plate analogies. > This is already a principle of ARIN > policy with the private residence stuff, OK so you create this example then shoot it down?!?! > but many of us feel > that it could be done in a more consistent and useful way. > Could it possibly be that residential customers who don't want to be published in WHOIS go use their money to buy service from an ISP that doesn't publish residential listings per ARIN's existing allowable policy? What your doing here is working out an example only applicable to private individuals and trying to apply it to organizations and businesses. Ted From owen at delong.com Fri Dec 4 21:46:22 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 4 Dec 2009 18:46:22 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <4B19A5AE.3070706@ipinc.net> References: <28E139F46D45AF49A31950F88C497458046174FC@E03MVZ2-UKDY.domain1.systemhost.net> <4B19A5AE.3070706@ipinc.net> Message-ID: The claims that ISPs are forced to maintain contact information for individuals is bunk anyway. 1. There is a residential privacy provision already in whois. 2. Most individuals don't get blocks large enough to require SWIP. Finally, if you need a large block and don't want to register as an individual, getting a legal fictitious name, or, creating a corporation is a relatively simple thing to do. That, combined with an address at a mail receiving service (such as Mailboxes etc. used to do before they became UPS) allows you to register without need to expose your residential address. However, internet addresses are a public commons resource. If you want to be granted the exclusive registration of a significant portion of said public commons, then, in exchange, you accept certain responsibilities, one of which is maintaining a way to contact you about network-related issues that includes a valid postal, email, and telephone contact point. This is a completely legitimate trade-off and I do not see a need to change it. The information should remain transparent and open. Owen From jcurran at arin.net Fri Dec 4 22:53:45 2009 From: jcurran at arin.net (John Curran) Date: Fri, 4 Dec 2009 22:53:45 -0500 Subject: [arin-ppml] Christopher Mettin Message-ID: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> Acting on the recommendation of the ARIN Mailing List AUP Committee, Christopher Mettin has been sent formal notice to cease defamatory posting to ARIN's mailing lists, and that even a single additional post of such nature may result in the immediate loss of his posting privileges. FYI, /John John Curran President and CEO ARIN From woodrow at csail.mit.edu Fri Dec 4 23:07:28 2009 From: woodrow at csail.mit.edu (Stephen Woodrow) Date: Fri, 4 Dec 2009 23:07:28 -0500 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out - Last Call In-Reply-To: <4B0C074D.9020608@arin.net> References: <4B0C074D.9020608@arin.net> Message-ID: May I suggest a clarification of the language here: > This reduction does not apply to resources received via section 8.3. An > organization receiving a transfer under section 8.3 may continue to > request up to a 12 month supply of IP addresses. To me, the first sentence is perfectly clear, while the second sentence adds confusion due to the fact that a request may be for 3 or 12 months, depending on the state of the IANA free pool. Can the second sentence be deleted or otherwise adjusted to reflect the intent as clearly described in the rationale below? > Rationale: ... > This policy is intended to be independent of other policies or proposals > to reserve address space for IPv6 transition or other purposes. It is > not intended to limit Transfers to Specified Recipients per section 8.3 > of the NRPM. Otherwise, I support this draft. --Steve From farmer at umn.edu Sat Dec 5 00:46:34 2009 From: farmer at umn.edu (David Farmer) Date: Fri, 04 Dec 2009 23:46:34 -0600 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out - Last Call In-Reply-To: References: <4B0C074D.9020608@arin.net> Message-ID: <4B19F3BA.2090004@umn.edu> Stephen Woodrow wrote: > May I suggest a clarification of the language here: > >> This reduction does not apply to resources received via section 8.3. An >> organization receiving a transfer under section 8.3 may continue to >> request up to a 12 month supply of IP addresses. > > To me, the first sentence is perfectly clear, while the second > sentence adds confusion due to the fact that a request may be for 3 or > 12 months, depending on the state of the IANA free pool. Can the > second sentence be deleted or otherwise adjusted to reflect the intent > as clearly described in the rationale below? The two sentences in question were taken directly from the original Draft Policy that was reviewed by staff and presented at ARIN XXIV. So this part of the text hasn't changed since Dearborn. But, it did get moved around a little though. Personally, I think it is clear, but I wrote it. So, I'm probably not the best judge. What do others think? Just to be clear on the intent, this relates to Transfers to Specified Recipients per NRPM section 8.3. In current policy without the addition of 2009-8, a recipient of a transfer can receive up to a 12 month supply of IP addresses. The intended result with 2009-8 applied is for a recipient of a transfer to continue to receive up to a 12 month supply a 12 month supply of IP addresses. The reduction to a 3 month supply is intended only for allocations from the ARIN free pool, not transfers. >> Rationale: > ... >> This policy is intended to be independent of other policies or proposals >> to reserve address space for IPv6 transition or other purposes. It is >> not intended to limit Transfers to Specified Recipients per section 8.3 >> of the NRPM. > > Otherwise, I support this draft. > > --Steve Thanks for the feedback, I really appreciate it. So, now I need additional feedback from others on the clarity of this part of the text. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From michel at arneill-py.sacramento.ca.us Sat Dec 5 01:06:01 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 4 Dec 2009 22:06:01 -0800 Subject: [arin-ppml] Christopher Mettin In-Reply-To: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> Message-ID: <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> > John Curran wrote: > Acting on the recommendation of the ARIN Mailing List AUP Committee, > Christopher Mettin has been sent formal notice to cease defamatory posting > to ARIN's mailing lists, and that even a single additional post of such > nature may result in the immediate loss of his posting privileges. Thank you John. As the original poster calling for action, I have to commend ARIN for coming to a resolution in a timely matter. Unlike say (cough) some other organization I also happen to subscribe to their mailing list and that takes months of mostly useless debate before anything comes up. I thought I would add my $0.02: I have been accused myself of trolling; sometimes I have been very controversial. For the record, and although I have supported Joe on this matter, he has been in hot waters for the same reasons as well. That being said, I encourage the reader to evaluate the fine line between: a) "IPv6 is a failure" and b) "John Curran is an Internet terrorist" Whether a) is acceptable as a mailing list topic is debatable. Time is of the essence, and a statement that would have been widely seen as politically incorrect a few years ago suddenly becomes an uncomfortable, unwanted but nevertheless more prevalent every day reality check. Note that I am not saying that such controversial topics are a good use of bandwidth for the arin-ppml mailing list though; just suggesting that a flare of controversy from time to time may be desirable and/or appropriate. As of b): unless John suddenly pops of on the FBI most wanted list with a multimillion dollar bounty on his head, this is not an acceptable mailing list topic. Michel. From woodrow at csail.mit.edu Sat Dec 5 02:49:36 2009 From: woodrow at csail.mit.edu (Stephen Woodrow) Date: Sat, 5 Dec 2009 02:49:36 -0500 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out - Last Call In-Reply-To: <4B19F3BA.2090004@umn.edu> References: <4B0C074D.9020608@arin.net> <4B19F3BA.2090004@umn.edu> Message-ID: On Sat, Dec 5, 2009 at 12:46 AM, David Farmer wrote: > Stephen Woodrow wrote: >> >> May I suggest a clarification of the language here: >> >>> This reduction does not apply to resources received via section 8.3. An >>> organization receiving a transfer under section 8.3 may continue to >>> request up to a 12 month supply of IP addresses. >> >> To me, the first sentence is perfectly clear, while the second >> sentence adds confusion due to the fact that a request may be for 3 or >> 12 months, depending on the state of the IANA free pool. Can the >> second sentence be deleted or otherwise adjusted to reflect the intent >> as clearly described in the rationale below? > > The two sentences in question were taken directly from the original Draft > Policy that was reviewed by staff and presented at ARIN XXIV. ?So this part > of the text hasn't changed since Dearborn. ?But, it did get moved around a > little though. > > Personally, I think it is clear, but I wrote it. ?So, I'm probably not the > best judge. ?What do others think? > > Just to be clear on the intent, this relates to Transfers to Specified > Recipients per NRPM section 8.3. In current policy without the addition of > 2009-8, a recipient of a transfer can receive up to a 12 month supply of IP > addresses. The intended result with 2009-8 applied is for a recipient of a > transfer to continue to receive up to a 12 month supply a 12 month supply of > IP addresses. ?The reduction to a 3 month supply is intended only for > allocations from the ARIN free pool, not transfers. Ah, my apologies --?I believe I misunderstood section 8.3. I gather the key text in 8.3 is "...under current ARIN policies.", which in this case would include section 4.2.4.4. Thus, this statement in 2009-8 is necessary to avoid limiting transfers to the equivalent of a 3-month supply. Thanks. No further clarification is required. --Steve From owen at delong.com Sat Dec 5 08:09:39 2009 From: owen at delong.com (Owen DeLong) Date: Sat, 5 Dec 2009 05:09:39 -0800 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out - Last Call In-Reply-To: <4B19F3BA.2090004@umn.edu> References: <4B0C074D.9020608@arin.net> <4B19F3BA.2090004@umn.edu> Message-ID: In general I see removing the second sentence as a no-op. I don't think it adds nor do I think it removes clarity in either case. Having said that, unnecessary text is just that, and, if removing it is a no-op, it is unnecessary text. Owen On Dec 4, 2009, at 9:46 PM, David Farmer wrote: > Stephen Woodrow wrote: >> May I suggest a clarification of the language here: >>> This reduction does not apply to resources received via section >>> 8.3. An >>> organization receiving a transfer under section 8.3 may continue to >>> request up to a 12 month supply of IP addresses. >> To me, the first sentence is perfectly clear, while the second >> sentence adds confusion due to the fact that a request may be for 3 >> or >> 12 months, depending on the state of the IANA free pool. Can the >> second sentence be deleted or otherwise adjusted to reflect the >> intent >> as clearly described in the rationale below? > > The two sentences in question were taken directly from the original > Draft Policy that was reviewed by staff and presented at ARIN XXIV. > So this part of the text hasn't changed since Dearborn. But, it did > get moved around a little though. > > Personally, I think it is clear, but I wrote it. So, I'm probably > not the best judge. What do others think? > > Just to be clear on the intent, this relates to Transfers to > Specified Recipients per NRPM section 8.3. In current policy without > the addition of 2009-8, a recipient of a transfer can receive up to > a 12 month supply of IP addresses. The intended result with 2009-8 > applied is for a recipient of a transfer to continue to receive up > to a 12 month supply a 12 month supply of IP addresses. The > reduction to a 3 month supply is intended only for allocations from > the ARIN free pool, not transfers. > > >>> Rationale: >> ... >>> This policy is intended to be independent of other policies or >>> proposals >>> to reserve address space for IPv6 transition or other purposes. It >>> is >>> not intended to limit Transfers to Specified Recipients per >>> section 8.3 >>> of the NRPM. >> Otherwise, I support this draft. >> --Steve > > Thanks for the feedback, I really appreciate it. > > So, now I need additional feedback from others on the clarity of > this part of the text. > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mueller at syr.edu Sat Dec 5 16:08:05 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 5 Dec 2009 16:08:05 -0500 Subject: [arin-ppml] Christopher Mettin In-Reply-To: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> Message-ID: <75822E125BCB994F8446858C4B19F0D79F0A769F@SUEX07-MBX-04.ad.syr.edu> Frankly I don't understand this. The behavior of Baptista and Mettin was exactly symmetrical and I am having trouble understanding why you would single out one and not the other. And am quite sure that I will receive (privately) defamatory responses from Baptista for saying this openly (except that I filter him, so it won't matter). ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of John Curran [jcurran at arin.net] Sent: Friday, December 04, 2009 10:53 PM To: arin ppml Subject: [arin-ppml] Christopher Mettin Acting on the recommendation of the ARIN Mailing List AUP Committee, Christopher Mettin has been sent formal notice to cease defamatory posting to ARIN's mailing lists, and that even a single additional post of such nature may result in the immediate loss of his posting privileges. FYI, /John John Curran President and CEO ARIN _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From mueller at syr.edu Sat Dec 5 16:11:55 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 5 Dec 2009 16:11:55 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <638797.96440.qm@web63302.mail.re1.yahoo.com> References: , <4B9F0A0D-2194-43F0-8EAD-63D1E4C28FBC@arin.net> <75822E125BCB994F8446858C4B19F0D79F0A7694@SUEX07-MBX-04.ad.syr.edu>, <638797.96440.qm@web63302.mail.re1.yahoo.com> Message-ID: <75822E125BCB994F8446858C4B19F0D79F0A76A0@SUEX07-MBX-04.ad.syr.edu> Thanks, Lee, I will take a look at that. But note that I have been through a similar debate on the DNS side, and the more I learned about the LEA position the more I realized that standard protections and procedures should apply. Indeed, I have discussed this with several LEAs in Europe who will admit (privately) that they use Whois to avoid legal constraints and that doing so has no justification other than their own convenience and that open access to the information is often abused or leads to abuse by third parties. ________________________________________ From: Lee Howard [spiffnolee at yahoo.com] > The parameters for ARIN's operations should be broader than "the minimum required by law." We One of the most interesting debates in this community was the meeting discussion of Policy Proposal 2005-2: Directory Services Overhaul. https://www.arin.net/participate/meetings/reports/ARIN_XV/ppm_minutes_day2.html It seemed that as we began the topic during the meeting, the community was leaning toward privacy. We had input from some members of our community, who are also members of several governments' agencies, which I think persuaded the community. That was almost five years ago, and certainly opinions may change. Debate is good; informed debate is even better. So, take ten minutes to read the minutes from ARIN XV on 2005-2. Lee ________________________________ From: Milton L Mueller To: John Curran ; Chris Engel Cc: "arin-ppml at arin.net" Sent: Fri, December 4, 2009 10:55:43 AM Subject: Re: [arin-ppml] SWIPs & IPv6 This is precisely what I fear. An expansive definition of the RIRs role can easily make them enforcement arms of the copyright industry . RIRs should serve a very narrow purpose and any additional loading of functions onto them must come from laws enacted by representative legislators subject t constitutional constraints, not by little bands of engineers trying to be "helpful" ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of John Curran [jcurran at arin.net] Chris - There's several reasons that have been cited in the past for having to know the holder of a block, and while that includes the law enforcement angle, there's also abuse & copyright mitigation, operational attack response, and end-to-end network problem diagnosis. I haven't been running a network personally in a few years, so I don't know the extent to which these are still valid but mention them for consideration. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From mueller at syr.edu Sat Dec 5 16:18:12 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 5 Dec 2009 16:18:12 -0500 Subject: [arin-ppml] FW: SWIPs & IPv6 In-Reply-To: <8695009A81378E48879980039EEDAD287B279F9C@MAIL1.polartel.local> References: <8695009A81378E48879980039EEDAD287B279F9C@MAIL1.polartel.local> Message-ID: <75822E125BCB994F8446858C4B19F0D79F0A76A1@SUEX07-MBX-04.ad.syr.edu> Notice how silly the discussion has become. We are no longer discussing the purpose of the data collected, what data is needed to fulfill that purpose, and the development of a reasonable access policy, but a false dichotomy between total, indisciriminate open access and someone cutting themselves off from all contact. totally irrelevant. ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel [kkargel at polartel.com] Again Ted has a point, however non-pc it is presented. I would be interested to hear about how many brick and mortar businesses survive when they delist their phone number, take themselves out of the phone book, remove all advertising so nobody can contact them, and take all the signage off their store front. From mueller at syr.edu Sat Dec 5 16:31:07 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 5 Dec 2009 16:31:07 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: <28E139F46D45AF49A31950F88C497458046174FC@E03MVZ2-UKDY.domain1.systemhost.net> <4B19A5AE.3070706@ipinc.net>, Message-ID: <75822E125BCB994F8446858C4B19F0D79F0A76A2@SUEX07-MBX-04.ad.syr.edu> Owen There is no law, regulation or constitutional provision that declares Internet addresses to be a "public commons resource." Indeed, your statements indicate that you may not have the clearest grasp of what you are saying theoretically (do you mean "public good" or "commons" and if you mean commons, do you mean "open access commons" or not?). FYI, IP addresses are both rival in consumption and excludable, which means that they fail both tests of a public good and need not be regulated as a commons. And even if they were, there is no logical, technical or operational linkage between the resource management regime and the alleged requirement to make all information about all users completely public for all purposes. To say that using IP addresses entails certain responsibilities is true. But we are debating what those responsibilities are or should be., You do not answer that question by begging it. Can we PLEASE attempt to discuss ways to solve the problems Danny MacPherson brought up? I can't even remember clearly what they were. ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong [owen at delong.com] Sent: Friday, December 04, 2009 9:46 PM To: Ted Mittelstaedt Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] SWIPs & IPv6 The claims that ISPs are forced to maintain contact information for individuals is bunk anyway. 1. There is a residential privacy provision already in whois. 2. Most individuals don't get blocks large enough to require SWIP. Finally, if you need a large block and don't want to register as an individual, getting a legal fictitious name, or, creating a corporation is a relatively simple thing to do. That, combined with an address at a mail receiving service (such as Mailboxes etc. used to do before they became UPS) allows you to register without need to expose your residential address. However, internet addresses are a public commons resource. If you want to be granted the exclusive registration of a significant portion of said public commons, then, in exchange, you accept certain r esponsibilities, one of which is maintaining a way to contact you about network-related issues that includes a valid postal, email, and telephone contact point. This is a completely legitimate trade-off and I do not see a need to change it. The information should remain transparent and open. Owen _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From mysidia at gmail.com Sat Dec 5 17:00:00 2009 From: mysidia at gmail.com (James Hess) Date: Sat, 5 Dec 2009 16:00:00 -0600 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D79EFB7A18@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D79EFB7A18@SUEX07-MBX-04.ad.syr.edu> Message-ID: <6eb799ab0912051400g62889a7fv24e709d8039bad74@mail.gmail.com> On Thu, Dec 3, 2009 at 2:15 PM, Milton L Mueller wrote: >[...] If an auto license could be costlessly mapped to personal contact info, we all know that there would be serious abuses due to road rage, stalking, theft, etc. However, IP assignments with ARIN are not mapped to personal info. They are mapped to CONTACTS for a business organization. This is a person, a business address, and business phone number. You will see things like e.g. Microsoft: "One Redmond Way, WA, 98052". This is not someone's home address. Publishing this does not pose any stalking risk. This type of information is public record already; every business will have some sort of registration on file with the government. In most states/countries, this type of public record can be freely viewed for businesses, without paying any fees. By definition, the organization determines what contact information to publish. They don't have to publish THE sensitive contact information. They can choose to publish the contact that is not sensitive, or "Get the address that they are allowed to publish without privacy concerns" They just have to publish A valid contact information for suitably reaching a responsible individual, for each resource. This is different from mapping an AUTO license to a Home Address, or Home Phone number. Contacts for ARIN resources are (generally) not chosen to be home addresses or home phone numbers. If all else fails, they can open a PO Box, if they are concerned. Provided they check it frequently, _allowing contacts_ and communications regarding their resources by providing information that can be used to reliably contact them, while releasing only "safe" information is the internet resource recipient's problem and expense to solve. -- -J From farmer at umn.edu Sat Dec 5 17:21:34 2009 From: farmer at umn.edu (David Farmer) Date: Sat, 05 Dec 2009 16:21:34 -0600 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out - Last Call In-Reply-To: References: <4B0C074D.9020608@arin.net> <4B19F3BA.2090004@umn.edu> Message-ID: <4B1ADCEE.7070402@umn.edu> Stephen Woodrow wrote: > On Sat, Dec 5, 2009 at 12:46 AM, David Farmer wrote: >> Stephen Woodrow wrote: >>> May I suggest a clarification of the language here: >>> >>>> This reduction does not apply to resources received via section 8.3. An >>>> organization receiving a transfer under section 8.3 may continue to >>>> request up to a 12 month supply of IP addresses. >>> To me, the first sentence is perfectly clear, while the second >>> sentence adds confusion due to the fact that a request may be for 3 or >>> 12 months, depending on the state of the IANA free pool. Can the >>> second sentence be deleted or otherwise adjusted to reflect the intent >>> as clearly described in the rationale below? >> The two sentences in question were taken directly from the original Draft >> Policy that was reviewed by staff and presented at ARIN XXIV. So this part >> of the text hasn't changed since Dearborn. But, it did get moved around a >> little though. >> >> Personally, I think it is clear, but I wrote it. So, I'm probably not the >> best judge. What do others think? >> >> Just to be clear on the intent, this relates to Transfers to Specified >> Recipients per NRPM section 8.3. In current policy without the addition of >> 2009-8, a recipient of a transfer can receive up to a 12 month supply of IP >> addresses. The intended result with 2009-8 applied is for a recipient of a >> transfer to continue to receive up to a 12 month supply a 12 month supply of >> IP addresses. The reduction to a 3 month supply is intended only for >> allocations from the ARIN free pool, not transfers. > > Ah, my apologies -- I believe I misunderstood section 8.3. I gather > the key text in 8.3 is "...under current ARIN policies.", which in > this case would include section 4.2.4.4. Thus, this statement in > 2009-8 is necessary to avoid limiting transfers to the equivalent of a > 3-month supply. Yes that is the key part of 8.3 and the reason that this is included in this policy. I believe the first sentence accomplishes the intent. I added to second sentence to abundantly clear that for transfers you can continue to receive up to a 12 month supply. So does the second sentence clarify things or only confuse them? I agree with Owen that from a policy point of view the second sentence is a no-op. However, I believe the second sentence helps clarify the intended result. One could surmise that this thread is a result of the second sentence have the intended effect. > Thanks. No further clarification is required. > > --Steve Thanks -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From mysidia at gmail.com Sat Dec 5 17:44:47 2009 From: mysidia at gmail.com (James Hess) Date: Sat, 5 Dec 2009 16:44:47 -0600 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out - Last Call In-Reply-To: References: <4B0C074D.9020608@arin.net> <4B19F3BA.2090004@umn.edu> Message-ID: <6eb799ab0912051444h2ccfc38jf3c52c340a1b3428@mail.gmail.com> On Sat, Dec 5, 2009 at 7:09 AM, Owen DeLong wrote: > In general I see removing the second sentence as a no-op. ?I don't think it > adds nor do I think it removes clarity in either case. > Having said that, unnecessary text is just that, and, if removing it is a > no-op, it is unnecessary text. However, that doesn't mean it's unnecessary. Also: I wonder what should happen if an organization should receive some resources via section 8.3 transfer and then later that year request some resources not by transfer? "An organization receiving a transfer under section 8.3 may continue to request up to a 12 month supply of IP addresses." Taken on its own, someone could interpret this to mean their receipt of addresses in the past now entitles them to request a 12 month supply of addresses to be allocated by ARIN, instead of the reduced 3 month amount. Also, if 8.3 were later revised, so it became more complicated, or a later revision to 8.3 says "18 month supply" instead of "12 month supply" for transfers. Now a change to this policy would be required as well So I do see a case for revising the exact language for 4.2.4.4. Such as: "This reduction applies only to resources received directly from ARIN. The size of a transfer that an organization may justify and receive receive under section 8.3 is not restricted by this section." -- -J From farmer at umn.edu Sat Dec 5 18:32:38 2009 From: farmer at umn.edu (David Farmer) Date: Sat, 05 Dec 2009 17:32:38 -0600 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out - Last Call In-Reply-To: <6eb799ab0912051444h2ccfc38jf3c52c340a1b3428@mail.gmail.com> References: <4B0C074D.9020608@arin.net> <4B19F3BA.2090004@umn.edu> <6eb799ab0912051444h2ccfc38jf3c52c340a1b3428@mail.gmail.com> Message-ID: <4B1AED96.9070505@umn.edu> James Hess wrote: > On Sat, Dec 5, 2009 at 7:09 AM, Owen DeLong wrote: >> In general I see removing the second sentence as a no-op. I don't think it >> adds nor do I think it removes clarity in either case. >> Having said that, unnecessary text is just that, and, if removing it is a >> no-op, it is unnecessary text. > > However, that doesn't mean it's unnecessary. Also: I wonder what > should happen if an organization should receive some resources via > section 8.3 transfer and then later that year request some resources > not by transfer? > > "An organization receiving a transfer under section 8.3 may continue > to request up to a 12 month supply of IP addresses." > > Taken on its own, someone could interpret this to mean their receipt > of addresses in the past now entitles them to request a 12 month > supply of addresses to be allocated by ARIN, instead of the reduced > 3 month amount. > > > Also, if 8.3 were later revised, so it became more complicated, or > a later revision to 8.3 says "18 month supply" instead of "12 > month supply" for transfers. > Now a change to this policy would be required as well > > So I do see a case for revising the exact language for 4.2.4.4. > Such as: > > "This reduction applies only to resources received directly from ARIN. > The size of a transfer that an organization may justify and receive > receive under section 8.3 is not restricted by this section." I like the first part of your suggestion. However, I believe the second part completely removes the current limit of a 12 month supply for transfers, which I can't support and I know a number of other people would oppose as well. I'm going to think about changes to the text, but I would like some more opinions on this issue. A number of people have said they support the text as written. So, I would like to see more feedback before making any changes the text. > -- > -J Thanks -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From jcurran at arin.net Sat Dec 5 18:51:18 2009 From: jcurran at arin.net (John Curran) Date: Sat, 5 Dec 2009 18:51:18 -0500 Subject: [arin-ppml] Christopher Mettin In-Reply-To: <75822E125BCB994F8446858C4B19F0D79F0A769F@SUEX07-MBX-04.ad.syr.edu> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <75822E125BCB994F8446858C4B19F0D79F0A769F@SUEX07-MBX-04.ad.syr.edu> Message-ID: <78C93E81-AEFA-4957-B828-1B41B73B9526@arin.net> On Dec 5, 2009, at 1:08 PM, Milton L Mueller wrote: > Frankly I don't understand this. > The behavior of Baptista and Mettin was exactly symmetrical and I am having trouble understanding why you would single out one and not the other. Milton - If you have a complaint about a violation of the PPML AUP, please follow the procedure provided here and it will be reviewed by the ARIN Mailing List AUP Committee. Thanks! /John John Curran President and CEO ARIN From fred at cisco.com Sat Dec 5 22:50:02 2009 From: fred at cisco.com (Fred Baker) Date: Sun, 6 Dec 2009 14:50:02 +1100 Subject: [arin-ppml] Christopher Mettin In-Reply-To: <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> Message-ID: <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> On Dec 5, 2009, at 5:06 PM, Michel Py wrote: > a) "IPv6 is a failure" > ... > Whether a) is acceptable as a mailing list topic is debatable. Time is > of the essence, and a statement that would have been widely seen as > politically incorrect a few years ago suddenly becomes an > uncomfortable, > unwanted but nevertheless more prevalent every day reality check. I agree that it is an important reality check. That said, I think that IPv6 has been since 1996 a solution developed in expectation of a problem. That problem has been creeping up on us (some networks have been having issues with addressing for quite a while, others are starting to now, but the generality remains at this point a prediction with a date). People generally don't do things that cost them money until they see something resembling ROI, and folks on this list and in other places have seriously questioned the ROI. In my opinion, IPv6 will have been demonstrated a failure if (a) the IPv4 address space doesn't run out or (b) when it does, IPv6 turns out to not be an adequate solution. It will have been an adequate solution (perhaps *just* adequate, but adequate) if it gets deployed widely and as a result it becomes more straightforward for operators (ISP and enterprise) to run their networks. It will have been inadequate if in the long run if we see sustained use of complex work-arounds - 6to4, Teredo, ISATAP, 6rd, ds-lite, IPv4/IPv6 CGN, IPv4/IPv4 CGN, IPv4 A+P hacks, and so on - instead of IPv6 deployment. I personally would include LISP in that category, although that could be over-reaching. I very much support IPv6 native deployment. My reason for supporting it is not that I think IPv6 is the greatest possible thing; in fact I explicitly and publicly reserved judgement on that for a long time. My reason for supporting it is that I think that, of the available solutions, in the 3-5 year timeframe it is the least opex/capex approach to the issues the industry is facing with addresses. IPv4/ IPv4 CGN is something we deploy now in many of the Internet's hinterlands; I observe that folks there don't talk about being "on the Internet", but talk about the number of hops between them and the Internet. The economic growth is where folks can easily deploy new applications, and IPv4/IPv4 CGN is a major hurdle to that. The other work-arounds I mentioned are useful as temporary steps to IPv6 deployment, giving folks the ability to deliver services using IPv6 while transforming their networks at a rate that makes sense to them. But it is additional complexity and as a result additional opex/capex. The holy grail of minimized opex/capex to be found in relative operational simplicity, and that is IMHO to be found in a uniform contiguous address space. I have heard it said that the problem with the weather is that everyone complains about it but nobody does anything about it. It seems like we are very happy to increase operational complexity and complain about the costs, but we go a long way out of our way to avoid actually solving the issues. It's time to do a real analysis of the costs and pick a strategic direction. In my mind, IPv6 is the only approach on the table that has a hope of reducing costs. From owen at delong.com Sun Dec 6 00:45:10 2009 From: owen at delong.com (Owen DeLong) Date: Sat, 5 Dec 2009 21:45:10 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D79F0A76A2@SUEX07-MBX-04.ad.syr.edu> References: <28E139F46D45AF49A31950F88C497458046174FC@E03MVZ2-UKDY.domain1.systemhost.net> <4B19A5AE.3070706@ipinc.net>, <75822E125BCB994F8446858C4B19F0D79F0A76A2@SUEX07-MBX-04.ad.syr.edu> Message-ID: <11ACE6AC-A6DC-4DB2-B6D3-3AE237E0762B@delong.com> Milton, Perhaps I did not use an exactly correct term to meet your particular sophistry requirements. However, internet addresses are a resource which has been placed in the trust of the RIR system for distribution in the best interests of the internet community as defined by that community. To me, that is as much a form of public commons as anything else. I thought I made my position clear on the subject at hand, but, since you apparently did not understand, I'll clarify further: 1. If you receive more than a trivial amount of IP number resources, you have the responsibility to make valid reliable contact data available to those users of the internet who may need to contact you in the event that systems claiming to be within your network are sending harmful or undesired traffic into their networks. (Note, that anyone with an internet connection fits in the scope of this definition in my opinion, so, placing the data in whois seems perfectly reasonable since you cannot generally access whois data without an internet connection). 2. You have the responsibility not to emit harmful traffic in general. 3. You have the responsibility not to emit undesired traffic towards networks that have informed you that they do not want your traffic. 4. You have the responsibility to respond to attempts to communicate with you via the contact information you have published, and, to act in a reasonable fashion to resolve issues brought to your attention through that contact. Now, since the next obvious question is the definition of a trivial amount of IP number resources, I'll clarify my thoughts on that subject as well: 1. If you possess more than zero ASNs, you have a non-trivial amount of IP number resources. 2. If you possess any RIR-direct allocations or assignments, you have a non-trivial amount of IP number resources. 3. If you possess more than 8 globally unique IPv4, you have a non- trivial amount of IP number resources. 4. If you possess more than a /60 of IPv6 addresses (either a contiguous /60 or some combination of longer prefixes totaling an equivalent amount of address space), you have a non-trivial amount of IP number resources. As I stated, the residential privacy concerns expressed by other posters, including Michael Dillon, are bogus because the current policy allows the data for those resource holders to be sufficiently obscured as to protect them. Further, most of the other concerns expressed are trivially addressed as I suggested below, by the organization in question getting a legitimate registered fictitious name or creating a corporation and using a mail receiving service for their address to do business with ARIN. Sure, there are costs associated with this, just as there is a fee for having your POTS telephone number unlisted. This allows resource holders to decide how much their privacy is worth to them. I would think you would be the last person to have a problem with such a mechanism. Owen On Dec 5, 2009, at 1:31 PM, Milton L Mueller wrote: > Owen > There is no law, regulation or constitutional provision that > declares Internet addresses to be a "public commons resource." > Indeed, your statements indicate that you may not have the clearest > grasp of what you are saying theoretically (do you mean "public > good" or "commons" and if you mean commons, do you mean "open access > commons" or not?). FYI, IP addresses are both rival in consumption > and excludable, which means that they fail both tests of a public > good and need not be regulated as a commons. > > And even if they were, there is no logical, technical or operational > linkage between the resource management regime and the alleged > requirement to make all information about all users completely > public for all purposes. > > To say that using IP addresses entails certain responsibilities is > true. But we are debating what those responsibilities are or should > be., You do not answer that question by begging it. > > Can we PLEASE attempt to discuss ways to solve the problems Danny > MacPherson brought up? I can't even remember clearly what they were. > ________________________________________ > From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong [owen at delong.com] > Sent: Friday, December 04, 2009 9:46 PM > To: Ted Mittelstaedt > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] SWIPs & IPv6 > > The claims that ISPs are forced to maintain contact information for > individuals is bunk > anyway. > > 1. There is a residential privacy provision already in whois. > > 2. Most individuals don't get blocks large enough to require > SWIP. > > Finally, if you need a large block and don't want to register as an > individual, getting > a legal fictitious name, or, creating a corporation is a relatively > simple thing to do. > That, combined with an address at a mail receiving service (such as > Mailboxes > etc. used to do before they became UPS) allows you to register without > need > to expose your residential address. > > However, internet addresses are a public commons resource. If you > want to be > granted the exclusive registration of a significant portion of said > public commons, > then, in exchange, you accept certain r > esponsibilities, one of which > is maintaining > a way to contact you about network-related issues that includes a > valid postal, > email, and telephone contact point. > > This is a completely legitimate trade-off and I do not see a need to > change it. > > The information should remain transparent and open. > > Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From tvest at eyeconomics.com Sun Dec 6 10:43:06 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Sun, 6 Dec 2009 10:43:06 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D79F0A76A0@SUEX07-MBX-04.ad.syr.edu> References: , <4B9F0A0D-2194-43F0-8EAD-63D1E4C28FBC@arin.net> <75822E125BCB994F8446858C4B19F0D79F0A7694@SUEX07-MBX-04.ad.syr.edu>, <638797.96440.qm@web63302.mail.re1.yahoo.com> <75822E125BCB994F8446858C4B19F0D79F0A76A0@SUEX07-MBX-04.ad.syr.edu> Message-ID: <3C6D77EE-DEDF-4D48-ACBC-E27B4E39B489@eyeconomics.com> On Dec 5, 2009, at 4:11 PM, Milton L Mueller wrote: > Thanks, Lee, I will take a look at that. But note that I have been > through a similar debate on the DNS side, and the more I learned > about the LEA position the more I realized that standard protections > and procedures should apply. Indeed, I have discussed this with > several LEAs in Europe who will admit (privately) that they use > Whois to avoid legal constraints and that doing so has no > justification other than their own convenience and that open access > to the information is often abused or leads to abuse by third parties. Given your very well-known, lopsided hard-line position on privacy matters, this claim defies all credibility. It's literally impossible to imagine some credible LEA insider glibly confessing this to you. However, its quite easy to imagine you exercising your equally well- known authorial license by selectively summarizing some description of LEA practices down to "unjustified evasion of legal constraints, just because it's easy." The real problem is the act of *misuse* of identifying information, and not the legal status or identity of the party misusing it, or the particulars of how the misused information was come by. And given that, your demand for what boils down to the imposition of prior restraint on an essential component of Internet technical coordination represents a strange, if predictable, departure from your otherwise panglossian insistence that post-facto individual legal remedies are always and everywhere sufficient to handle any unfortunate side- effects of private market behavior. Why don't you counsel those alleging "whois abuse" to simply address their grievances to the courts, the same way that you counsel victims of abusive private sector practices or the exercise of anticompetitive market power to take it to the judge? List members may find the contrast between what you're advocating here and what you advocated in the run-up to the privatization of DNS illumInating. In your October 1997 CATO Institute Briefing Paper, "Internet Domain Names: Privatization, Competition, and Freedom of Expression," you write: > The Burden of Proof on Applicants for Domain Names > > Some people have suggested that domain name applicants be required > to demonstrate that they have a basis for requesting a particular > domain name. Further questions then arise. What information should > be supplied? Who should evaluate the information? What basis or > criteria should be used? > > Those questions are helpful but need to be reframed. The answers to > them can come only from the policies name registries adopt to > prevent name speculation and to control the secondary market for > names. Name speculation is a form of arbitrage. Speculators attempt > to exploit the gap between the price of registering a name and the > higher value of that name to some other potential user. Name > speculation thus provides a clear signal that the primary > distributor of name registrations is not exploiting the full > economic value of its name resources. > > The best long-term solution to this problem is privatization of name > registration and expansion of TLD space. It is in the rational self- > interest of commercial registries to manage name resources actively > rather than passively. Just as airlines or movie theater owners do > not allow aggregators and wholesalers to buy up all available seats > and resell them to end users, so it seems unlikely that private, > profit-motivated name registries would allow speculators, rather > than themselves, to exploit the full economic value of their > namespace. As the namespace becomes privatized and commercialized, > it seems likely that more active monitoring of who is applying for > names and why would take place. Administrative policies such as this > are much preferable to intellectual property law as a solution to > problems of name speculation. > Full text here: http://www.cato.org/pub_display.php?pub_id=1473&full=1 This little nugget is full of telling observations -- from your unique "theory of speculation" to your predictions about how privatization and competition would influence the policy-setting behavior of commercial domain registries. I'm guessing that you'd still stand by these recommendations, even knowing that one consequence of their implementation has been the permanent elimination of DNS whois as an effective mechanism for inter-domain technical coordination, but feel free to surprise me. Arguably, history has demonstrated that DNS whois was, in fact, expendable. However, that's only because the underlying/parallel inetnum whois provided a sufficient if not superior mechanism for most technical coordination requirements. The whois functions provided by the RIRs are different in kind than DNS whois, and for those functions there is no plausible substitute -- or at least none that can be provided by voluntary private action. So, for the present discussion, I would highlight the last two sentences of this passage, and ask Milton why "administrative policies" such as the ones that make inetnum-related whois viable should not be preferred over the imposition of legally (i.e., nationally) mandated compulsory address resource registration, which is likely to be the only alternative? I know you're not big on actually answering practical, policy-relevant questions in any substantive way. That's your prerogative. But I'll keep asking them anyway, if only to remind other readers of your long-standing disinclination to put any of your own ideas to any meaningful, real-world test. TV From mueller at syr.edu Sun Dec 6 15:22:00 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 6 Dec 2009 15:22:00 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <3C6D77EE-DEDF-4D48-ACBC-E27B4E39B489@eyeconomics.com> References: , <4B9F0A0D-2194-43F0-8EAD-63D1E4C28FBC@arin.net> <75822E125BCB994F8446858C4B19F0D79F0A7694@SUEX07-MBX-04.ad.syr.edu>, <638797.96440.qm@web63302.mail.re1.yahoo.com> <75822E125BCB994F8446858C4B19F0D79F0A76A0@SUEX07-MBX-04.ad.syr.edu> <3C6D77EE-DEDF-4D48-ACBC-E27B4E39B489@eyeconomics.com> Message-ID: <75822E125BCB994F8446858C4B19F0D79EFB7A1B@SUEX07-MBX-04.ad.syr.edu> > Given your very well-known, lopsided hard-line position on privacy > matters, this claim defies all credibility. It's literally > impossible to imagine some credible LEA insider glibly confessing > this to you. As usual, you stereotype me and are factually wrong. I am not a "privacy hard liner" relative to, say, some of the dedicated privacy rights groups; I've had many interesting debates with privacy groups about the tension between freedom of information, freedom of expression, accountability and data protection/privacy. Moreover, it's really not nice to call me a liar about conversations I have had with LEA people in the course of my work on Whois WGs and CERT conferences in Europe and elsewhere; I wouldn't claims that if it wasn't pertinent and true - and those folks wouldn't say it to me if they didn't want that info to get out somehow. Quite apart from that assertion, I will say that there are even discernable differences on this issue within the U.S. Justice Dept.; e.g., between the FTC and the FBI; the former's position in favor of distinguishing between treatment of natural persons and legal persons is a matter of public record. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org From mueller at syr.edu Sun Dec 6 15:30:55 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 6 Dec 2009 15:30:55 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <6eb799ab0912051400g62889a7fv24e709d8039bad74@mail.gmail.com> References: <75822E125BCB994F8446858C4B19F0D79EFB7A18@SUEX07-MBX-04.ad.syr.edu> <6eb799ab0912051400g62889a7fv24e709d8039bad74@mail.gmail.com> Message-ID: <75822E125BCB994F8446858C4B19F0D79EFB7A1C@SUEX07-MBX-04.ad.syr.edu> James: > However, IP assignments with ARIN are not mapped to personal info. > They are mapped to CONTACTS for a business organization. This is a > person, a business address, and business phone number. Nothing wrong with that. Again, the essential issue to me is: what is the purpose of the data collected? What data is required to fulfill that purpose? How can we limit the data collected to that which is required for that purpose? > You will see things like e.g. Microsoft: "One Redmond > Way, WA, 98052". > This is not someone's home address. Publishing this does not pose > any stalking risk. I never said it did. > This type of information is public record already; every business > will have some sort of registration on file with the government. In > most states/countries, this type of public record can be freely > viewed for businesses, without paying any fees. Of course; that is the distinction between "natural persons" and "legal persons" we have already been discussing. We are, however, also now talking about the use of the organizational contact as an intermediary for law enforcement. Again, no inherent problem with that, but just an insistence that due process be followed. Indiscriminate, at-will downloading of any and all information about entities using Internet resources is not necessarily good. --MM From mueller at syr.edu Sun Dec 6 15:41:59 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 6 Dec 2009 15:41:59 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <11ACE6AC-A6DC-4DB2-B6D3-3AE237E0762B@delong.com> References: <28E139F46D45AF49A31950F88C497458046174FC@E03MVZ2-UKDY.domain1.systemhost.net> <4B19A5AE.3070706@ipinc.net>, <75822E125BCB994F8446858C4B19F0D79F0A76A2@SUEX07-MBX-04.ad.syr.edu> <11ACE6AC-A6DC-4DB2-B6D3-3AE237E0762B@delong.com> Message-ID: <75822E125BCB994F8446858C4B19F0D79EFB7A1D@SUEX07-MBX-04.ad.syr.edu> Owen No, you did not make your position clear. And however much you resent it, my question forced you to greatly clarify your position, which has led to a significant improvement in the quality of discourse - or could, if you'd stop being defensive, and actually try to benefit from over a centi=ury of research on regulatory systems and political economy which already deals with issues such as public interest obligations, the distinction btween "commons," public goods, public interest regulation and the like. What you call sophistry I call precision. Just be aware that words like "commons" actually have meanings and if you're going to invoke them to prove something you ought to know what they mean. Your post below is a big advance over the earlier one: you have moved from making a simplistic claim that the status of number resources as a "public commons resource" (a nonexistent category in institutional economics) gives you a blanket right to impose any data disclosure requirements you wish, to a vastly more qualified and intelligent list of conditions regarding the matching of grants and obligations. I'll go over those claims more carefully as the conversation proceeds, if there is time. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Sunday, December 06, 2009 12:45 AM > To: Milton L Mueller > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] SWIPs & IPv6 > > Milton, > > Perhaps I did not use an exactly correct term to meet your > particular > sophistry requirements. > > However, internet addresses are a resource which has been placed in > the trust of the RIR > system for distribution in the best interests of the internet > community as defined by that > community. To me, that is as much a form of public commons as > anything else. > > I thought I made my position clear on the subject at hand, > but, since > you apparently did > not understand, I'll clarify further: > > 1. If you receive more than a trivial amount of IP number > resources, > you have the > responsibility to make valid reliable contact data > available to those > users of the > internet who may need to contact you in the event that systems > claiming to be > within your network are sending harmful or undesired > traffic into > their networks. > (Note, that anyone with an internet connection fits in > the scope of > this definition > in my opinion, so, placing the data in whois seems perfectly > reasonable since > you cannot generally access whois data without an > internet connection). > > 2. You have the responsibility not to emit harmful traffic > in general. > > 3. You have the responsibility not to emit undesired > traffic towards > networks that > have informed you that they do not want your traffic. > > 4. You have the responsibility to respond to attempts to > communicate > with you via > the contact information you have published, and, to act in a > reasonable fashion > to resolve issues brought to your attention through > that contact. > > Now, since the next obvious question is the definition of a trivial > amount of IP number > resources, I'll clarify my thoughts on that subject as well: > > 1. If you possess more than zero ASNs, you have a > non-trivial amount > of IP number > resources. > > 2. If you possess any RIR-direct allocations or > assignments, you have > a non-trivial > amount of IP number resources. > > 3. If you possess more than 8 globally unique IPv4, you > have a non- > trivial amount > of IP number resources. > > 4. If you possess more than a /60 of IPv6 addresses (either a > contiguous /60 or > some combination of longer prefixes totaling an > equivalent amount of > address > space), you have a non-trivial amount of IP number resources. > > As I stated, the residential privacy concerns expressed by other > posters, including Michael > Dillon, are bogus because the current policy allows the data > for those > resource holders > to be sufficiently obscured as to protect them. > > Further, most of the other concerns expressed are trivially > addressed > as I suggested > below, by the organization in question getting a legitimate > registered > fictitious name > or creating a corporation and using a mail receiving service > for their > address to do > business with ARIN. > > Sure, there are costs associated with this, just as there is > a fee for > having your > POTS telephone number unlisted. This allows resource holders to > decide how > much their privacy is worth to them. I would think you would be the > last person > to have a problem with such a mechanism. > > Owen > > On Dec 5, 2009, at 1:31 PM, Milton L Mueller wrote: > > > Owen > > There is no law, regulation or constitutional provision that > > declares Internet addresses to be a "public commons resource." > > Indeed, your statements indicate that you may not have the > clearest > > grasp of what you are saying theoretically (do you mean "public > > good" or "commons" and if you mean commons, do you mean > "open access > > commons" or not?). FYI, IP addresses are both rival in consumption > > and excludable, which means that they fail both tests of a public > > good and need not be regulated as a commons. > > > > And even if they were, there is no logical, technical or > operational > > linkage between the resource management regime and the alleged > > requirement to make all information about all users completely > > public for all purposes. > > > > To say that using IP addresses entails certain responsibilities is > > true. But we are debating what those responsibilities are > or should > > be., You do not answer that question by begging it. > > > > Can we PLEASE attempt to discuss ways to solve the problems Danny > > MacPherson brought up? I can't even remember clearly what they were. > > ________________________________________ > > From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On > > Behalf Of Owen DeLong [owen at delong.com] > > Sent: Friday, December 04, 2009 9:46 PM > > To: Ted Mittelstaedt > > Cc: arin-ppml at arin.net > > Subject: Re: [arin-ppml] SWIPs & IPv6 > > > > The claims that ISPs are forced to maintain contact information for > > individuals is bunk > > anyway. > > > > 1. There is a residential privacy provision already in whois. > > > > 2. Most individuals don't get blocks large enough to require > > SWIP. > > > > Finally, if you need a large block and don't want to register as an > > individual, getting > > a legal fictitious name, or, creating a corporation is a relatively > > simple thing to do. > > That, combined with an address at a mail receiving service (such as > > Mailboxes > > etc. used to do before they became UPS) allows you to > register without > > need > > to expose your residential address. > > > > However, internet addresses are a public commons resource. If you > > want to be > > granted the exclusive registration of a significant portion of said > > public commons, > > then, in exchange, you accept certain r > > esponsibilities, one of which > > is maintaining > > a way to contact you about network-related issues that includes a > > valid postal, > > email, and telephone contact point. > > > > This is a completely legitimate trade-off and I do not see a need to > > change it. > > > > The information should remain transparent and open. > > > > Owen > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > From tvest at eyeconomics.com Sun Dec 6 16:04:01 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Sun, 6 Dec 2009 16:04:01 -0500 Subject: [arin-ppml] Whois doesn't violate privacy, people do (was: SWIPs & IPv6) In-Reply-To: <3C6D77EE-DEDF-4D48-ACBC-E27B4E39B489@eyeconomics.com> References: , <4B9F0A0D-2194-43F0-8EAD-63D1E4C28FBC@arin.net> <75822E125BCB994F8446858C4B19F0D79F0A7694@SUEX07-MBX-04.ad.syr.edu>, <638797.96440.qm@web63302.mail.re1.yahoo.com> <75822E125BCB994F8446858C4B19F0D79F0A76A0@SUEX07-MBX-04.ad.syr.edu> <3C6D77EE-DEDF-4D48-ACBC-E27B4E39B489@eyeconomics.com> Message-ID: <586686EB-231D-4A25-A478-3FA7835AAE5B@eyeconomics.com> Hi Milton, Since you elected once again to ignore (or in this case delete) the substantive, policy relevant questions that I posed to you, I decided to resend them one more time, under a subject line that better illuminates the inconsistency and weakness in your reasoning about whois as compared to other real, potential, and imagined threats to privacy. Would still welcome a substantive response or two... TV On Dec 5, 2009, at 4:11 PM, Milton L Mueller wrote: > Thanks, Lee, I will take a look at that. But note that I have been > through a similar debate on the DNS side, and the more I learned > about the LEA position the more I realized that standard protections > and procedures should apply. Indeed, I have discussed this with > several LEAs in Europe who will admit (privately) that they use > Whois to avoid legal constraints and that doing so has no > justification other than their own convenience and that open access > to the information is often abused or leads to abuse by third parties. The real problem is the act of *misuse* of identifying information, and not the legal status or identity of the party misusing it, or the particulars of how the misused information was come by. And given that, your demand for what boils down to the imposition of prior restraint on an essential component of Internet technical coordination represents a strange, if predictable, departure from your otherwise panglossian insistence that post-facto individual legal remedies are always and everywhere sufficient to handle any unfortunate side- effects of private market behavior. Why don't you counsel those alleging "whois abuse" to simply address their grievances to the courts, the same way that you counsel victims of abusive private sector practices or the exercise of anticompetitive market power to take it to the judge? >>> In other words, Whois doesn't violate privacy; the policies and administrative practices that sustain whois as a viable mechanism for technical coordination don't violate privacy; *people* who misuse whois violate privacy. Why should List members may find the contrast between what you're advocating here and what you advocated in the run-up to the privatization of DNS illumInating. In your October 1997 CATO Institute Briefing Paper, "Internet Domain Names: Privatization, Competition, and Freedom of Expression," you write: > The Burden of Proof on Applicants for Domain Names > > Some people have suggested that domain name applicants be required > to demonstrate that they have a basis for requesting a particular > domain name. Further questions then arise. What information should > be supplied? Who should evaluate the information? What basis or > criteria should be used? > > Those questions are helpful but need to be reframed. The answers to > them can come only from the policies name registries adopt to > prevent name speculation and to control the secondary market for > names. Name speculation is a form of arbitrage. Speculators attempt > to exploit the gap between the price of registering a name and the > higher value of that name to some other potential user. Name > speculation thus provides a clear signal that the primary > distributor of name registrations is not exploiting the full > economic value of its name resources. > > The best long-term solution to this problem is privatization of name > registration and expansion of TLD space. It is in the rational self- > interest of commercial registries to manage name resources actively > rather than passively. Just as airlines or movie theater owners do > not allow aggregators and wholesalers to buy up all available seats > and resell them to end users, so it seems unlikely that private, > profit-motivated name registries would allow speculators, rather > than themselves, to exploit the full economic value of their > namespace. As the namespace becomes privatized and commercialized, > it seems likely that more active monitoring of who is applying for > names and why would take place. Administrative policies such as this > are much preferable to intellectual property law as a solution to > problems of name speculation. > Full text here: http://www.cato.org/pub_display.php?pub_id=1473&full=1 This little nugget is full of telling observations -- from your unique "theory of speculation" to your predictions about how privatization and competition would influence the policy-setting behavior of commercial domain registries. I'm guessing that you'd still stand by these recommendations, even knowing that one consequence of their implementation has been the permanent elimination of DNS whois as an effective mechanism for inter-domain technical coordination, but feel free to surprise me. Arguably, history has demonstrated that DNS whois was, in fact, expendable. However, that's only because the underlying/parallel inetnum whois provided a sufficient if not superior mechanism for most technical coordination requirements. The whois functions provided by the RIRs are different in kind than DNS whois, and for those functions there is no plausible substitute -- or at least none that can be provided by voluntary private action. So, for the present discussion, I would highlight the last two sentences of this passage, and ask Milton why "administrative policies" such as the ones that make inetnum-related whois viable should not be preferred over the imposition of legally (i.e., nationally) mandated compulsory address resource registration, which is likely to be the only alternative? I know you're not big on actually answering practical, policy-relevant questions in any substantive way. That's your prerogative. But I'll keep asking them anyway, if only to remind other readers of your long-standing disinclination to put any of your own ideas to any meaningful, real-world test. TV Begin forwarded message: > From: tvest at eyeconomics.com > Date: December 3, 2009 3:38:38 PM EST > To: Milton L Mueller > Cc: "arin-ppml at arin.net (arin-ppml at arin.net)" > Subject: Re: [arin-ppml] SWIPs & IPv6 > > > On Dec 3, 2009, at 3:15 PM, Milton L Mueller wrote: > >> Tom, >> there's a logical fallacy in your attempt to avoid the drivers >> license (DL) analogy: you have assumed that defeating the analogy >> justifies the existing system, in which anyone has access to >> potentially sensitive contact information. > > Hi Milton, > > Is there some reason that you ignored the questions in the message > that I sent *before* I responded to Chris' driver's license analogy? > It seems to have founds its way safely to the ppml archive: > > http://lists.arin.net/pipermail/arin-ppml/2009-December/015680.html > > On the outside chance that you didn't receive the message, I've > copied it again below. > > I'm assuming here that you're not planning to "defeat" my questions > by simply ignoring them...? > I think that defeating them in the more conventional way (i.e., by > answering them) would be more constructive. > > As you may note, the questions that I posed to you have nothing in > particular to do with specific institutions, past, present, or > imaginary. They have to do with properly defined functions of an > Internet protocol number resource registry, and the source(s) of > incentives and disincentives that might make it possible for a > properly functioning registry to be sustainable over time (a) based > solely on voluntary participation, and/or (b) in an environment of > competitive registration service delivery. > > I look forward to your responses. > > TV > > >>> Tom: >>> >>> Privacy norms, standards and laws are well known and not that hard >>> to apply to this case. >>> Here is a link to a boilerplate explanation of basic data >>> protection principles: >>> http://www.recordsmanagement.ed.ac.uk/InfoStaff/DPstaff/DPPrinciples.htm >>> Respectful suggestion: do some homework on how this issue gets >>> handled before wading into a policy arena with global human rights >>> implications. >> >> Hi Milton, >> >> Thanks for the respectful suggestion. I will take it under >> advisement. >> >> However, I would respectfully suggest that providing more >> substantive answers here would be useful both to you (if your goal >> is, in fact, to help inform number resource policies), as well as >> to those list members who are not likely to go off and do a lot of >> homework on this issue. >> >>>> 1. Would you say that the proper balance between these two opposing >>>> goals is reflected in current DNS whois arrangements? >>> >>> Absolutely not. (And you know perfectly well that I've answered >>> this question, not only on this list, but in lengthy scholarly >>> articles, and in years of work on DNS Whois Working Groups and >>> Task Forces.) >>> >>> It would be very easy for DNS Whois to contain the requisite >>> technical information needed for both law enforcement and >>> technical management without providing indiscriminate public >>> access to anyone and everyone, for any purpose. >> >> Okay, in that case I call: >> >> 1. Could you suggest how, exactly, a registration/whois system can >> be both very accurate, very reliable, and very easy for technical >> administrators to access (when justified) for real-time network >> management requirements*, while at the same time satisfying the the >> legitimate* privacy concerns of the individuals and institutions >> who are represented in that registration data? >> >> 2. Could you also suggest how those conditions that are accurately >> deemed to be legitimate*, required*, etc. by both groups might be >> sustained over time? Specifically, if revelation of whois >> inaccuracies is generally only possible as a result of outages or >> other "events" that require technical administrator action, and >> discovery of correct whois information in such cases is generally >> only possible through legal mechanisms (warrants, subpoenas, >> lawsuits, registry disaccreditations, etc.) which do not operate at >> time scales that are consistent with real-time network management, >> what method(s) would you propose for reconciling this critical >> mismatch? >> >> 3. Finally (and if appropriate), could you also suggest how those >> conditions might be preserved in an environment of competitive >> commercial provision of registration and whois services? >> Specifically, what mechanisms would you recommend to encourage >> registration and whois service providers to maintain the proper >> level of investment in and ongoing support for this secondary, non >> profit-making function? What mechanisms would you advocate to >> assure that individual commercial registration and whois service >> providers resist the temptation to differentiate themselves by >> cutting their whois-related support and/or by relaxing their whois- >> related customer requirements? >> >> Since (3) presumes that you advocate the competitive provision of >> registration and whois services, with at least some competitors >> being private/not-governmental entities, please disregard this >> question if this presumption is inaccurate. >> >>> The only reason this doesn't happen: DNS Whois arrangements have >>> been hijacked by trademark protection firms, LEAs too lazy to get >>> the proper authorizations, and by companies that collect and sell >>> the data for various and sundry purposes. See data protection >>> principle #2 for my opinion about that. >> >> If I'm interpreting your reference correctly, data protection >> principle #2 reads: >> "Personal data shall be obtained only for one or more specified and >> lawful purposes, and shall not be further processed in any manner >> incompatible with that purpose or those purposes." >> >> If we stipulate for the moment that we're only talking about >> protocol number whois as used for legitimate technical >> administrative purposes that are consistent with the law, then the >> relevance of data protection principle #2 is still ambiguous. One >> justification for open public whois is that public scrutiny >> provides a kind of continuous distributed error detection and >> correction mechanism, which helps to maintain whois completeness >> and accuracy in between those critical moments when technical- >> administrative action is both legal and justified -- and at which >> points the belated discovery of whois inaccuracies can have the >> most adverse consequences. >> >> Is it your view that the very existence and/or maintenance of >> accurate personal data should be subject to a different, higher >> standard than the standard suggested by data protection principle #2? >> >>>> 2. Are the "legitimate privacy concerns" of artificial >>>> persons (i.e., >>>> corporations) different from the "legitimate privacy concerns" of >>>> natural persons? >>> >>> Sigh. Overlooking your complete ignorance of applicable law, I >>> will simply answer yes. >>> The distinction is well-established in law, not to mention common >>> sense. Yes, Tom, there are differences between the privacy rights >>> and legal norms applicable to publicly registered corporate >>> entities and flesh and blood persons and their homes and personal >>> property. >> >> Ignoring the insult, I'll just observe again that a less clever but >> more substantive response would have probably been more useful, to >> you and everyone else. >> >>>> If so, how -- and how should the differences be >>>> reflected in rotocol number-related registration data and whois? >>> >>> Yes, of course the differences should be reflected. How? Not that >>> hard, but as I said in my last message, let's debate specific >>> arrangements and proposals, not ideology. >> >> Excellent. Here's your chance to debate specifics. >> >> It's good to know that it won't be that hard... >> >> Thanks, >> >> TV From mysidia at gmail.com Sun Dec 6 17:06:51 2009 From: mysidia at gmail.com (James Hess) Date: Sun, 6 Dec 2009 16:06:51 -0600 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D79EFB7A1C@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D79EFB7A18@SUEX07-MBX-04.ad.syr.edu> <6eb799ab0912051400g62889a7fv24e709d8039bad74@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D79EFB7A1C@SUEX07-MBX-04.ad.syr.edu> Message-ID: <6eb799ab0912061406nad506e1uc4df2314bd808347@mail.gmail.com> On Sun, Dec 6, 2009 at 2:30 PM, Milton L Mueller wrote: > James: > Nothing wrong with that. Again, the essential issue to me is: what is the purpose of the data collected? What data is required to fulfill that purpose? How can we limit the data collected to that which is required for that purpose? There are many purposes for the data in the IP and AS number WHOIS registries. There are obvious purposes that exist today, and there may be other purposes for the data in the future. It is not clear that there is any benefit in trying to limit the data collected. Although, substantial disadvantages can be forseen, such as not being able to contact the user of a resource, and being forced to take more drastic actions, in response to abuse/issues, if an error is made in limiting data too much. > We are, however, also now talking about the use of the organizational contact >as an intermediary for law enforcement. Again, no inherent problem with that, >but just an insistence that due process be followed. Indiscriminate, at-will >downloading of any and all information about entities using Internet resources is >not necessarily good. > --MM It's also not necessarily bad. There is also, no such thing as official "Internet Law enforcement"; it's not an "intermediary" for law enforcement, in many cases, WHOIS information may be about all you've got. Internet resources extend past national borders. Law enforcement cannot be relied upon to solve internet connectivity issues, and cannot provide real-world contact information that might be required to resolve some issues. Law enforcement is no replacement for being able to KNOW who your neighbor is, and their neighbor is, etc, etc, in any case. Internet is not like the real world -- without a WHOIS database, you don't know where your neighbor physically exists, you can't just walk across the street, and knock on their door to ask them to turn down the stereo. You may need contact information for organizations utilizing IP resources in Asia, to address abuses or connectivity issues, just as much as you need a contact for an organization in the US. If they leave their radio on too loud, you can hear them just as loudly from Asia, as from in the US, and without detailed WHOIS info, you have no way of asking them to turn it off. So it's best that WHOIS collect contact info as specific and reliable as possible, there is no room for seeking to "limit information"; that's a bad thing. At least E-mail address, Phone number, and Physical address, at bare minimum. -- -J From michel at arneill-py.sacramento.ca.us Sun Dec 6 20:11:59 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 6 Dec 2009 17:11:59 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> Message-ID: <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> Fred, I am a bit surprised you swallowed that bait; the IPv6 camp should be desperate to send people of your caliber feeding controversies from me. But I'll bite! I changed the subject; "IPv6 is a failure" is too provocative and it is too early to make this determination yet. I hope you will agree that the current state of IPv6 is "non-deployment". >> Michel Py wrote: "IPv6 is a failure" ..[snip].. and a statement >> that would have been widely seen as politically incorrect a few >> years ago suddenly becomes an uncomfortable, unwanted but >> nevertheless more prevalent every day reality check. > Fred Baker wrote: > I agree that it is an important reality check. That said, I > think that IPv6 has been since 1996 a solution developed in > expectation of a problem. Unfortunately, only for some parts. This statement is valid for the larger address space solving the expected problem of IPv4 shortage (and to a lesser extent the problem of very large ISPs being too big for 10.0.0.0/8 and even larger-than-class-A spaces). Some other parts of IPv6 are either a solution looking for a problem, an undelivered promise, or vendors trying to have it their way despite what the consumer base says. - Solution looking for a problem: let's look at autoconfiguration: first, it's not new to IPv6; we had that with IPX. Second, it addresses a problem that ceased to be one for a long time: DHCP is working and is available on any $20 cheesy "router". Third, it's not much of a solution: if it was, there would be no need for DHCPv6. - Undelivered promise: routing table aggregation. If any IPv6 multihoming solution (except like doing exactly the same as IPv4) was working, the RIRs would not have already adopted policies allocating PI addresses to non-LIR entities. - Vendors trying to have it their way: I understand this is not the forum to debate my pet peeves with Cisco, but I will use a recent real-world example: Two weeks ago, I deployed a new customer network. Small; a handful of remote sites. The routing protocol I used (and it was my call to make) is EIGRP, because RIP and IGRP sucks and OSPF is too complex for the customer. Where's EIGRP for IPv6? Maybe you could hint someone at Cisco (evil grin) that instead of IPv6 with OSPFv6, the customers will keep running IPv4 with EIGRP? Unfortunately, the IPv6 marketing is still using outdated arguments. The bottom line is: the only real problem that IPv6 solves today is the predicted shortage of IPv4 addresses. Some aspects of IPv6 are indeed superior to IPv4, but not worth the increased complexity and cost. And we mostly agree (see below) that in the end it's just a matter of big bucks. > People generally don't do things that cost them money until they see > something resembling ROI, and folks on this list and in other places > have seriously questioned the ROI. With some good reasons. > In my opinion, IPv6 will have been demonstrated a failure if (a) the > IPv4 address space doesn't run out or (b) when it does, IPv6 turns out > to not be an adequate solution. It will have been an adequate solution > perhaps *just* adequate, but adequate) if it gets deployed widely and > as a result it becomes more straightforward for operators (ISP and > enterprise) to run their networks. It will have been inadequate if in > the long run if we see sustained use of complex work-arounds - 6to4, > Teredo, ISATAP, 6rd, ds-lite, IPv4/IPv6 CGN, IPv4/IPv4 CGN, IPv4 A+P > hacks, and so on - instead of IPv6 deployment. I agree with what's above. Unfortunately, there are so many workarounds already that nobody really believes that they will be quickly eliminated should native IPv6 deployment occur. We all have in our respective closets a few skeletons of temporary-only-for-3-days-I-swear ugly hacks that are still there 5 or 10 years after the fact. In other words: we don't even have a clean start, and a large number of unproven hacks does not appear any better than double NAT. > The holy grail of minimized opex/capex to be found in relative > operational simplicity, and that is IMHO to be found in a uniform > contiguous address space. I agree with that too, but IPv6 brings a whole lot of new complexities, one of the major no-nos being multiple addresses per host. Talk about operational simplicity. Between two evils none of which is clearly a lesser one, people will keep with the one currently in place. > In my mind, IPv6 is the only approach on the > table that has a hope of reducing costs. So far, it seems that not too many new people are believing in this hope, and that more of those who used to believe it have become disconnected from their previous faith. As of being the only solution on the table, it is. Double-NAT is temporary-only-for-3-days-I-swear, right? I would entertain that IPv4+ (which would be a backwards-compatible IPv4 with the only difference being an extended address space) would be much more popular as a solution if it was on the table. Question: how many years after the last IPv4 block gets allocated to the RIRs do we wait until we feel it is time to make that call? Michel. From tvest at eyeconomics.com Sun Dec 6 20:15:59 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Sun, 6 Dec 2009 20:15:59 -0500 Subject: [arin-ppml] Whois doesn't violate privacy, people do (was~ whois misuse innuendo) In-Reply-To: <75822E125BCB994F8446858C4B19F0D79EFB7A1B@SUEX07-MBX-04.ad.syr.edu> References: , <4B9F0A0D-2194-43F0-8EAD-63D1E4C28FBC@arin.net> <75822E125BCB994F8446858C4B19F0D79F0A7694@SUEX07-MBX-04.ad.syr.edu>, <638797.96440.qm@web63302.mail.re1.yahoo.com> <75822E125BCB994F8446858C4B19F0D79F0A76A0@SUEX07-MBX-04.ad.syr.edu> <3C6D77EE-DEDF-4D48-ACBC-E27B4E39B489@eyeconomics.com> <75822E125BCB994F8446858C4B19F0D79EFB7A1B@SUEX07-MBX-04.ad.syr.edu> Message-ID: <63D85ED5-C484-4606-BBA8-9768234931F3@eyeconomics.com> On Dec 6, 2009, at 3:22 PM, Milton L Mueller wrote: >> Given your very well-known, lopsided hard-line position on privacy >> matters, this claim defies all credibility. It's literally >> impossible to imagine some credible LEA insider glibly confessing >> this to you. > > As usual, you stereotype me and are factually wrong. The facts that you claim would make me wrong are not in evidence, because so far you have consistently refused to provide them. I encourage you to reveal the error of my assertions for all to see, by clarifying your full position on privacy as it relates to the matter at hand. > I am not a "privacy hard liner" relative to, say, some of the > dedicated privacy rights groups; I've had many interesting debates > with privacy groups about the tension between freedom of > information, freedom of expression, accountability and data > protection/privacy. As long as you refuse to clarify your own position on privacy -- and fully, i.e., not by merely obliquely claiming that your views are somewhat less extreme that the most extreme pro-privacy position that anyone could possibly imagine -- then you should expect to spend a lot of time rebutting others' assumptions about your actual position, motives, etc. Practically speaking, until you make your own position clear, you don't have one -- at least not one that merits consideration, much less "respectful treatment." > Moreover, it's really not nice to call me a liar about conversations > I have had with LEA people in the course of my work on Whois WGs and > CERT conferences in Europe and elsewhere; I never called you a liar; I suggested that you are prone to re- presenting facts in summary forms that are strongly shaped by your own prior views, on this and other subjects. Perhaps the distinction is not so easy for others to discern, given the fact that you deleted the rest of my remarks. For those who missed them the first time: >> ... glibly confessing this to you. However, it's quite easy to >> imagine you exercising your equally well-known authorial license by >> selectively summarizing some description of LEA practices down to >> "unjustified evasion of legal constraints, just because it's easy." Of course, if you still insist that this interpretation is inflammatory and/or factually incorrect, you could always produce a transcript -- anonymized, if necessary -- of the verbatim conversations in which these confessions were made...? Perhaps someone else was also witness to these exchanges, someone who could corroborate the substance of your account/transcript without revealing the identity of your confidential informant(s)? > I wouldn't claims that if it wasn't pertinent and true - and those > folks wouldn't say it to me if they didn't want that info to get out > somehow. Given the degree to which much of the machinery of state was captured and run over the last decade by individuals who were philosophically inclined to treat opportunities to disgrace, disable, and/or starve "the beast" as an added feature or perk of their (invariably brief, transient) public sector experience, this is not entirely implausible. But even granting that such statements were made to you, in strict confidence, why should anyone else grant them any more credence that they might give, e.g., to the handful of critics of banking oversight employed by the Fed and the SEC -- people who until quite recently spent much of their time claiming that the financial sector would just automagically guide itself if only the heavy hand of government regulation would be lifted? (note: I'm not going to debate this point further on list; would suggest that anyone wanting to take me to task on this point do so privately) > Quite apart from that assertion, I will say that there are even > discernable differences on this issue within the U.S. Justice Dept.; > e.g., between the FTC and the FBI; the former's position in favor of > distinguishing between treatment of natural persons and legal > persons is a matter of public record. Now this last point almost sounds like the promise of something (at least potentially) informative... Would you care to share with us exactly how the FTC and FBI differ in their interpretation of the privacy rights of individuals/natural persons vs. corporations and other "juridical persons" -- and how that distinction informs your own views and/or the distinction as you fell it should be applied in this particular context? I do hope that this is not something resting on Fourth or Fifth Amendment rights, which are definitionally orthogonal to IP addresses... Looking forward to your responses, TV From fred at cisco.com Mon Dec 7 01:19:41 2009 From: fred at cisco.com (Fred Baker) Date: Mon, 7 Dec 2009 17:19:41 +1100 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> Message-ID: <0E89882F-C9D1-4311-93A5-36BE5AE61925@cisco.com> On Dec 7, 2009, at 12:11 PM, Michel Py wrote: > I would entertain that IPv4+ (which would be a backwards-compatible > IPv4 > with the only difference being an extended address space) would be > much > more popular as a solution if it was on the table. It would make a lot of sense. How, precisely, would you achieve that? Recall that the problem there isn't a failure in the design of IPv6; it's that IPv4 was not designed to have an extensible address. Roughly translated into the King's English, that means "you can't get there from here in a reliable fashion." The obvious solution would be to put a source and destination AS number in options in the IPv4 packet, and in the presence of such a thing route to the remote AS before attempting to interpret the address. That's essentially what Jim Fleming proposed in his IPv8 model, but he did so in a non-backward compatible way. The question I'll ask is how one proposes to actually deploy this in a backward compatible fashion. Think "Windows 95" and all that. From bill at herrin.us Mon Dec 7 02:07:10 2009 From: bill at herrin.us (William Herrin) Date: Mon, 7 Dec 2009 02:07:10 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <0E89882F-C9D1-4311-93A5-36BE5AE61925@cisco.com> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> <0E89882F-C9D1-4311-93A5-36BE5AE61925@cisco.com> Message-ID: <3c3e3fca0912062307w139688e5j2b8a76fc23e55022@mail.gmail.com> On Mon, Dec 7, 2009 at 1:19 AM, Fred Baker wrote: > On Dec 7, 2009, at 12:11 PM, Michel Py wrote: > >> I would entertain that IPv4+ (which would be a backwards-compatible IPv4 >> with the only difference being an extended address space) would be much >> more popular as a solution if it was on the table. > > It would make a lot of sense. How, precisely, would you achieve that? Recall > that the problem there isn't a failure in the design of IPv6; it's that IPv4 > was not designed to have an extensible address. Fred, http://bill.herrin.us/network/ipxl.html Not saying it should be done; just saying it could be done. > Roughly translated into the > King's English, that means "you can't get there from here in a reliable > fashion." "You can't get there from here" originated with "Which Way to Millinocket?" which is set in Maine and intended to be delivered in a thick New England accent. Not exactly King's English. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joelja at bogus.com Mon Dec 7 02:13:49 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 06 Dec 2009 23:13:49 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <0E89882F-C9D1-4311-93A5-36BE5AE61925@cisco.com> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> <0E89882F-C9D1-4311-93A5-36BE5AE61925@cisco.com> Message-ID: <4B1CAB2D.10605@bogus.com> Fred Baker wrote: > > On Dec 7, 2009, at 12:11 PM, Michel Py wrote: > >> I would entertain that IPv4+ (which would be a backwards-compatible IPv4 >> with the only difference being an extended address space) would be much >> more popular as a solution if it was on the table. > > It would make a lot of sense. How, precisely, would you achieve that? > Recall that the problem there isn't a failure in the design of IPv6; > it's that IPv4 was not designed to have an extensible address. Roughly > translated into the King's English, that means "you can't get there from > here in a reliable fashion." "I can't get to v6 due to legacy hosts" holds true for anything else that requires stack changes on legacy hosts... legacy hosts aren't going to do a+p subidivision for example. the legacy devices have to age out of the network be replaced or supported within their legacy scope. windows xp will never use v6 nameservers, that's ok the world will move on. > The obvious solution would be to put a source and destination AS number > in options in the IPv4 packet, and in the presence of such a thing route > to the remote AS before attempting to interpret the address. That's > essentially what Jim Fleming proposed in his IPv8 model, but he did so > in a non-backward compatible way. The question I'll ask is how one > proposes to actually deploy this in a backward compatible fashion. Think > "Windows 95" and all that. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From michael.dillon at bt.com Mon Dec 7 06:10:11 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 7 Dec 2009 11:10:11 -0000 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458046AA0DC@E03MVZ2-UKDY.domain1.systemhost.net> > However, internet addresses are a public commons resource. > If you want to be granted the exclusive registration of a > significant portion of said public commons, then, in > exchange, you accept certain responsibilities, one of which > is maintaining a way to contact you about network-related > issues that includes a valid postal, email, and telephone > contact point. This is all fine and good if the address assignee is ready willing and able to act when receiving communications about network-related issues, but for the vast majority of assignees who have no inhouse networking expertise, it makes more sense to have their network provider's contact information there. There is still a way to contact the assignee since the network operator, who has a business relationship with the assignee, can relay messages or trade contact info between the contacter and contactee. > This is a completely legitimate trade-off and I do not see a > need to change it. > > The information should remain transparent and open. The only information that should be transparent and open is information that we NEED TO KNOW. --Michael Dillon From michael.dillon at bt.com Mon Dec 7 06:25:50 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 7 Dec 2009 11:25:50 -0000 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <6eb799ab0912051400g62889a7fv24e709d8039bad74@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C497458046AA12D@E03MVZ2-UKDY.domain1.systemhost.net> > However, IP assignments with ARIN are not mapped to personal info. > They are mapped to CONTACTS for a business organization. > This is a person, a business address, and business phone number. Then you would support an ARIN policy that says something like: WHOIS directory data MUST NOT include any personal information except the name of a person who is a contact point for an organization. Where IP addresses are assigned to individuals the WHOIS directory MUST NOT contain more than the indication that this is not an organisation. > By definition, the organization determines what contact > information to publish. > They don't have to publish THE sensitive contact information. They > can choose to publish the contact that is not sensitive, or "Get > the address that they are allowed to publish without privacy concerns" That is only true for organizations that have direct relationships with ARIN. If an organisation is the customer of an ISP, they do not have this option which is why the whois directory is polluted with so much useless data. > They just have to publish A valid contact information for > suitably reaching a responsible individual, for each resource. What does "valid" mean? Does it perhaps mean that the contact information is for people who are READY, WILLING AND ABLE TO ACT on received communications? Or something else? > If all else fails, they can open a PO Box, if they are concerned. > Provided they check it frequently, _allowing contacts_ and > communications regarding their resources by providing > information that can be used to reliably contact them, while > releasing only > "safe" information is the internet resource recipient's > problem and expense to solve. Given that ARIN's policymaking process is open, don't you think that it is better to NOT make a policy where we advise people to register a fictitious name and open a P/O box? --Michael Dillon From michael.dillon at bt.com Mon Dec 7 06:44:06 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 7 Dec 2009 11:44:06 -0000 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <11ACE6AC-A6DC-4DB2-B6D3-3AE237E0762B@delong.com> Message-ID: <28E139F46D45AF49A31950F88C497458046AA18E@E03MVZ2-UKDY.domain1.systemhost.net> > As I stated, the residential privacy concerns expressed by > other posters, including Michael Dillon, are bogus because > the current policy allows the data for those resource holders > to be sufficiently obscured as to protect them. "Allows for" is not good enough. The policy needs to make it mandatory that useless contact data MUST NOT be published in the ARIN whois database. If there is not a 24/7 network operations NOC at the other end of the contact info, then it MUST NOT be in the whois directory, period! > Further, most of the other concerns expressed are trivially > addressed as I suggested below, by the organization in > question getting a legitimate registered fictitious name or > creating a corporation and using a mail receiving service for > their address to do business with ARIN. > > Sure, there are costs associated with this, just as there is > a fee for having your POTS telephone number unlisted. This > allows resource holders to decide how much their privacy is > worth to them. I would think you would be the last person to > have a problem with such a mechanism. I don't think that you really understand who these organizations in question really are. Imagine an ISP that runs a data centre. They sell colocated servers. ACME Inc. buys a bunch of them, and gets a consultant to rig them up with Virtuozzo so that they can sell VPS servers. Widjits Inc, then rents a VPS and gets a consultant to set up a control panel package. Thingamajig Design Inc, then rents a web server package bundled with 10 domains. They then sell a web site design service to Gewgaws Inc. on one of those domains. The website that is supplied is for a shopping cart e-store. Gewgaws Inc. then offers a service to all and sundry whereby they can offer their miscellaneous overstock goods for sale on the e-store and Gewgaws will also run an Ebay auction for the items if desired. Now one of Gewgaws customers has recently had some products rejected by Ebay so they take their products to Gewgaws, for listing just on Gewgaws shop and start a SPAM campaign to drive business to them. You would really like to contact Gewgaws to take these pirate DVDs off their site but the problem is that there is nobody technical at Gewgaws, in fact the two owners are the only people there, and they spend most of their time in their high-school classes and after-school basketball. Thingamajig also has nobody there except the college student who works weekends on designing websites. Widjits Inc. is another one-man band who works evenings at Macdonalds. Now ACME does have a technical guy working there, but he won't do anything without orders from his boss because it is his first job after graduating from journalism school. Now tell me, what is wrong with keeping all of these organizatons out of the whois directory except for the ISP who got the allocation from ARIN. That ISP is in a better position to track something down this chain to the end, and if they can't do it by phoning/emailing, they can always pull the plug. Simples! --Michael Dillon From jcurran at arin.net Mon Dec 7 09:10:06 2009 From: jcurran at arin.net (John Curran) Date: Mon, 7 Dec 2009 09:10:06 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <28E139F46D45AF49A31950F88C497458046AA18E@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458046AA18E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <3A18AE5F-79F2-4AF2-9748-18BC9779328A@arin.net> On Dec 7, 2009, at 6:44 AM, michael.dillon at bt.com wrote: > Now tell me, what is wrong with keeping all of > these organizatons out of the whois directory > except for the ISP who got the allocation from > ARIN. That ISP is in a better position to track > something down this chain to the end, and if they > can't do it by phoning/emailing, they can always > pull the plug. Simples! Michael - Excellent use case. I'd like to add another for comparison: A big ISP (BigI) runs a US nationwide network, and sells transit services to other ISPs and hosting companies. BigI has an ARIN allocation. AcmeISP (AcmeI) uses BigI as their primary transit for IPv4, and received their initial block from BigI although success means that AcmeI may soon meet the requirements for their own ARIN allocation. In the meantime, AcmeI serves a number of clients in the city, including a small hosting company (HostingCo) that focuses on retail web sites. HostingCo runs some dedicated servers in AcmeI's main POP, and resells them integrated with software for small businesses. One of those servers is rented to CorporationX and turns out, for reasons unknown, to be hosting the command&control server for a very large botnet, and as such, it needs to be taken down asap to mitigate untold damage being done out on the network. BigI has the ARIN allocation, but wants to insure that the SWIP for AcmeI is quite visible in WHOIS, as BigI's business model doesn't include handling customer support for content liability for AcmeI, and in fact, AcmeI has agreed by contract to be reachable for network operations purposes. In fact, AcmeI has the very same provisions in their contract with HostingCo, and HostingCo has (at least in theory) a person reachable via cell for handling their server issues. AcmeI also wants to make sure that HostingCo's subdelegation is very visible to the community, so that the first call goes to the party which is most likely to be able to solve the problem. There's probably dozens of potential use cases, but I wanted to provide one that explains why the ISP getting the allocation often wants the SWIP data to be publicly visible. /John John Curran President and CEO ARIN From michael.dillon at bt.com Mon Dec 7 10:10:21 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 7 Dec 2009 15:10:21 -0000 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <3A18AE5F-79F2-4AF2-9748-18BC9779328A@arin.net> Message-ID: <28E139F46D45AF49A31950F88C497458046AA59B@E03MVZ2-UKDY.domain1.systemhost.net> > and in fact, AcmeI has agreed by > contract to be reachable for network operations purposes. In > fact, AcmeI has the very same provisions in their contract > with HostingCo, and HostingCo has (at least in theory) a > person reachable via cell for handling their server issues. > AcmeI also wants to make sure that HostingCo's subdelegation > is very visible to the community, so that the first call goes > to the party which is most likely to be able to solve the problem. In this use case, the chain of contractual relationships apparently does include a promise to provide contact data for someone who is READY, WILLING AND ABLE to act on communications received. This means that their contact information is useful for the purpose of resolving network issues. It should also mean that if the operator of the whois directory contacted one of these people to verify that they are indeed READY WILLING AND ABLE to act, then the contactee should confirm this. In this way, the whois directory operator could ensure data cleanliness and accept the entry. I don't believe that the operator of the whois directory should accept any entry that someone wants to put in there. We need a policy that give everyone clarity. --Michael Dillon From cengel at sponsordirect.com Mon Dec 7 12:14:32 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Mon, 7 Dec 2009 12:14:32 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: Message-ID: In the security world, the principle of "least privilege" is a well established best practice. That is, granting the minimum level of access/functionality/data in order to achieve a given task. I do not believe it is an unreasonable position to hold forth that ARIN should adhere to that best practice in regards to requirements for WHOIS. So let me put forth the question.... What is the legitimate NEED for publicly accessible WHOIS lookup that can be accessed anonymously and that has no gate-keeping functionality inherent to it? The one LEGITIMATE case that I've heard put forth is that a particular IP block is causing problems for another network by misdirecting traffic to it or directing unwanted traffic to it. The idea being that if the affected networks can lookup the contact information for the IP block that is causing the problem and they can inform them of the issue so it can be resolved (assuming that the owner of the IP block is cooperative). Since the problem is ongoing, timeliness of contact is an issue and placing barriers to obtain that contact would be an unacceptable negative. I can see the legitimacy of that claim. However, in that case, can anyone tell me why you would need anything OTHER then a technical contact phone number & e-mail ??? Note that this is far less information then what is currently collected and published through SWIPS/WHOIS. How would knowing the legal name of the block-holder help you resolve that issue?? If they've already provided you with a contact e-mail and phone number ?? How would knowing their physical street address help? Does anyone contend that sending snail mail is more TIMELY then making a phone call or sending an e-mail? I don't even see that knowing the real name of the technical contact would help...if you had their e-mail & phone #. Furthermore, I would posit that in MANY cases it actually makes more sense for an organization to list their ISP's NOC in that contact section. The ISP may not be authorized to take action to solve the problem (outside of their function in dealing with actual abuse) but they are FAR more likely to have a help desk that is monitored 24/7/365 then most small/medium organizations. Furthermore the organization MAY be willing to provide their ISP (or other trusted agent) with an escalation and emergency contact list which might include contact information (including home & private cell phone numbers) that they would generally NOT be comfortable with publishing publicly. Can anyone put forward a case why the general public would legitimately NEED any information beyond technical contact & e-mail? If so I would like to hear it. The only cases I can think of where the other information would be NEEDED would be ones where timeliness was NOT an issue...or where the entity requesting the information could be pre-vetted and authorized to access such info (such as legitimate LEA's). For instance, ARIN staff might need that other info to vet justification for IP space assignment.... but as has been pointed out to me ARIN staff already has mechanisms for collecting and using privileged private information for such purposes....why would THIS information need to be treated as PUBLIC intead of private for ARIN staff to perform such duties? I can see where a private individual/organization might want to file suit or make a criminal complaint against a block-holder for damaging/interrupting their network. However the private individual/organization has no ENFORCEMENT authority on their own. They are already going to the courts/LEA's that do have such authority for a redress of their grievances... having the courts/LEA's order the release of that privileged information would not be out of the scope of the functions they are ALREADY seeking from it. I can see where in exceptional circumstances LEA's might require timely access to such information.... however ALL LEA's have access to the Courts for expedited subpoenas where timeliness is an issue...and frankly it would be a very rare case (I would think) that an LEA could legitimately claim exigent circumstances for IP address info. Furthermore, denying the GENERAL PUBLIC access to ANONYMOUSLY lookup such data IN NO WAY precludes legitimate LEA's from having ready access to such data, even absent subpoenas. There is no particular reason whe LEA's couldn't be vetted in advance and given private access to a lookup database containing more complete info. LEA's are (in theory at least) known entities who use such data for the legitimate pursuit of their duties. Pretty much all have data handling policies governing what they do with the data they collect associated with their duties... and (in theory at least) have mechanisms in place to hold them publicly accountable for the adherence to those policies. NONE of that holds true for an anonymous user of the general public. In short, the only data that I see that might be REQUIRED without JUSTIFICATION is technical contact phone number & e-mail. I don't see how requiring a person that wants more then that to provide appropriate justification for it is unreasonable. Christopher Engel From cengel at sponsordirect.com Mon Dec 7 13:08:54 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Mon, 7 Dec 2009 13:08:54 -0500 Subject: [arin-ppml] (no subject) In-Reply-To: Message-ID: John Curran wrote: " and in fact, AcmeI has agreed by contract to be reachable for network operations purposes. In fact, AcmeI has the very same provisions in their contract with HostingCo, and HostingCo has (at least in theory) a person reachable via cell for handling their server issues. AcmeI also wants to make sure that HostingCo's subdelegation is very visible to the community, so that the first call goes to the party which is most likely to be able to solve the problem. " John, obviously it's in the ISP's interest to do as little work there as possible, in order to reduce thier operating costs. On the other side of the coin, one of the reasons why customers choose one service provider over another is the level and type of services they provide to thier customers. I would think that who's information goes in the technical contact field would be something to be worked out individualy between the block-holder and thier service provider(s) at each level in the chain. Since there is no "one size fits all" solution that would cover well all (or even a majority) individual cases. In EITHER case, however, I am still curious as to WHY anything more then Technical Contact Phone # & E-mail is REQUIRED to be published in order to achieve the desired end? Currently SWIPS/WHOIS collects and publishes far more information then that, does it not? None of which would be neccessary or particularly useful for the purpose of getting in touch with some-one that can act upon the technical issues at question. I mean how is it neccesary/useful for some-one to know that Block X is owned by ACME Corp at 123 South Main Street, if the entity who is ACTUALY responsible for handling technical issues for them is Computer Consultants, Inc ? I would think that the information that would be required to address the issue would be... IP Address #: x.x.x.x Tech Contact E-mail: abuse at ComputerConsultants.com Tech Contact Phone: 1-555-555-5555 Why is there a need to publish anything more then that? Christopher Engel From warren at wholesaleinternet.com Mon Dec 7 13:32:29 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Mon, 7 Dec 2009 12:32:29 -0600 Subject: [arin-ppml] (no subject) In-Reply-To: References: Message-ID: <29756CA699484850BE8780CE3CC1F846@johnsonvhjjf8v> Moving into a more private system signals a shift from the grass-roots, free-love philosophy (that has been the cornerstone of the movement) to a more private, closed, profit-driven/motivated system. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Engel Sent: Monday, December 07, 2009 12:09 PM To: 'arin-ppml at arin.net' Subject: Re: [arin-ppml] (no subject) John Curran wrote: " and in fact, AcmeI has agreed by contract to be reachable for network operations purposes. In fact, AcmeI has the very same provisions in their contract with HostingCo, and HostingCo has (at least in theory) a person reachable via cell for handling their server issues. AcmeI also wants to make sure that HostingCo's subdelegation is very visible to the community, so that the first call goes to the party which is most likely to be able to solve the problem. " John, obviously it's in the ISP's interest to do as little work there as possible, in order to reduce thier operating costs. On the other side of the coin, one of the reasons why customers choose one service provider over another is the level and type of services they provide to thier customers. I would think that who's information goes in the technical contact field would be something to be worked out individualy between the block-holder and thier service provider(s) at each level in the chain. Since there is no "one size fits all" solution that would cover well all (or even a majority) individual cases. In EITHER case, however, I am still curious as to WHY anything more then Technical Contact Phone # & E-mail is REQUIRED to be published in order to achieve the desired end? Currently SWIPS/WHOIS collects and publishes far more information then that, does it not? None of which would be neccessary or particularly useful for the purpose of getting in touch with some-one that can act upon the technical issues at question. I mean how is it neccesary/useful for some-one to know that Block X is owned by ACME Corp at 123 South Main Street, if the entity who is ACTUALY responsible for handling technical issues for them is Computer Consultants, Inc ? I would think that the information that would be required to address the issue would be... IP Address #: x.x.x.x Tech Contact E-mail: abuse at ComputerConsultants.com Tech Contact Phone: 1-555-555-5555 Why is there a need to publish anything more then that? Christopher Engel _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From bill at herrin.us Mon Dec 7 13:57:44 2009 From: bill at herrin.us (William Herrin) Date: Mon, 7 Dec 2009 13:57:44 -0500 Subject: [arin-ppml] (no subject) In-Reply-To: References: Message-ID: <3c3e3fca0912071057q7b2555f0w70a2fbe742eca0d8@mail.gmail.com> On Mon, Dec 7, 2009 at 1:08 PM, Chris Engel wrote: > I mean how is it neccesary/useful for some-one to know >that Block X is owned by ACME Corp at 123 South Main >Street, if the entity who is ACTUALY responsible for handling >technical issues for them is Computer Consultants, Inc ? > > I would think that the information that would be required >to address the issue would be... > > IP Address #: x.x.x.x > Tech Contact E-mail: ?abuse at ComputerConsultants.com > Tech Contact Phone: 1-555-555-5555 > > Why is there a need to publish anything more then that? So you can serve them with legal papers. So that an ISP who suspects its competitor of fraud can spot-check the competitor's SWIP records against the local business listings and give ARIN a real complaint. -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tvest at eyeconomics.com Mon Dec 7 14:30:15 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Mon, 7 Dec 2009 14:30:15 -0500 Subject: [arin-ppml] (no subject) In-Reply-To: <29756CA699484850BE8780CE3CC1F846@johnsonvhjjf8v> References: <29756CA699484850BE8780CE3CC1F846@johnsonvhjjf8v> Message-ID: <36A8218C-21B0-4B5A-A0C7-0058A32FAD31@eyeconomics.com> Hi Warren, Other, perhaps more practical ways of looking at it: The default public/open availability of comprehensive whois information for the institutions controlling number resources represents a kind of distributed mechanism for whois data error detection and correction. Assuming that the practical needs that justify the creation and maintenance of a comprehensive registration/ whois service also justify the maintenance of *accurate* (and complete, and timely) registration/whois information, and consequently that the only alternative to satisfying that need via a distributed feedback mechanism is a mechanism that delivers/preserves the same accuracy levels through purely internal (RIR staff administered) efforts, then the arrangement with many eyes contributing is likely to be much more cost effective, i.e., to provide the same benefits at a much lower cost to ARIN members. One might also consider the merits of this "distributed management" approach to maintaining whois as a useful mechanism for preserving the openness and transparency of ARIN policy outcomes. The more that such (by current convention, "public") contact information remains publicly accessible, the less ARIN members have to rely on ARIN staff to produce summary answers to sensitive policy questions using non- sharable/non-disclosable member data. In a world where virtually every important institution is at the center of a permanent debate between defenders of "x is generally good" and partisans of "x is hopelessly corrupt" -- with the vast majority of stakeholders likely to be in the "trust but verify" center -- seems like it would be prudent to weigh the costs and benefits very carefully before eliminating the public data resources that make such independent analysis/verification efforts possible. TV On Dec 7, 2009, at 1:32 PM, Warren Johnson wrote: > Moving into a more private system signals a shift from the grass- > roots, > free-love philosophy (that has been the cornerstone of the movement) > to a > more private, closed, profit-driven/motivated system. > > > > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On > Behalf Of Chris Engel > Sent: Monday, December 07, 2009 12:09 PM > To: 'arin-ppml at arin.net' > Subject: Re: [arin-ppml] (no subject) > > > John Curran wrote: > > " and in fact, AcmeI has agreed by contract to be reachable for > network > operations purposes. In fact, AcmeI has the very same provisions in > their > contract with HostingCo, and HostingCo has (at least in theory) a > person > reachable via cell for handling their server issues. AcmeI also > wants to > make sure that HostingCo's subdelegation is very visible to the > community, > so that the first call goes to the party which is most likely to be > able to > solve the problem. " > > > John, obviously it's in the ISP's interest to do as little work > there as > possible, in order to reduce thier operating costs. On the other > side of the > coin, one of the reasons why customers choose one service provider > over > another is the level and type of services they provide to thier > customers. I > would think that who's information goes in the technical contact > field would > be something to be worked out individualy between the block-holder > and thier > service provider(s) at each level in the chain. Since there is no > "one size > fits all" solution that would cover well all (or even a majority) > individual > cases. In EITHER case, however, I am still curious as to WHY > anything more > then Technical Contact Phone # & E-mail is REQUIRED to be published > in order > to achieve the desired end? > > Currently SWIPS/WHOIS collects and publishes far more information > then that, > does it not? None of which would be neccessary or particularly > useful for > the purpose of getting in touch with some-one that can act upon the > technical issues at question. > > I mean how is it neccesary/useful for some-one to know that Block X > is owned > by ACME Corp at 123 South Main Street, if the entity who is ACTUALY > responsible for handling technical issues for them is Computer > Consultants, > Inc ? > > I would think that the information that would be required to address > the > issue would be... > > IP Address #: x.x.x.x > Tech Contact E-mail: abuse at ComputerConsultants.com Tech Contact > Phone: > 1-555-555-5555 > > Why is there a need to publish anything more then that? > > > > > > Christopher Engel > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the > ARIN Public > Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From cengel at sponsordirect.com Mon Dec 7 14:49:13 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Mon, 7 Dec 2009 14:49:13 -0500 Subject: [arin-ppml] (no subject) In-Reply-To: <3c3e3fca0912071057q7b2555f0w70a2fbe742eca0d8@mail.gmail.com> Message-ID: Bill, In each of those cases, there is no need for timeliness of access for that information and there is an appropriate venue for providing justification to get access to that information in a non-time sensitive manner. In the case of serving an entity with legal papers, why would it NOT be appropriate to expect the plaintiff to petition the courts for an order to reveal the identity of the person you want to serve? THAT is the burden placed upon plaintiffs when wishing to serve posters on individual forums/sites, holders of e-mail addresses or individual IP address holders (rather then holders of a static block) is it not? Why should the burden be ANY less in this instance? Why, practically, should holding 9 IP's rather then 7 change the requirements for that burden In terms of "checking up on competitors"..... A large part of justification for IP space also has to do with expected upcoming projects.... do you propose that ARIN should also publish organizations future business plans (which would normally be covered by NDA's) for their competitors to "check up" on them as well? ARIN, who has no vested interest in which ISP an individual customer uses already has the capacity to investigate fraud. Why would you vest that responsibility with competitor(s) who would have a vested interest in throwing as many hurdles in front of their competition as possible and who may have serious motivation to misuse such information? Which would be more likely an ISP using such information to justify an honest complaint of fraud on the part of a competitor or to create a targeted sales list to try to steal the competitors customers? ARIN's staff has both the capacity and the responsibility to investigate fraud as well as the means for doing something about it and lacks any motivation to use that information for other purposes. An ISP has little real capacity or responsibility to investigate a competitor and lacks the tools to do anything about it other then to ask ARIN to investigate....but has a great deal of motivation to use it for other purposes, does it not? Christopher Engel -----Original Message----- From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Monday, December 07, 2009 1:58 PM To: Chris Engel Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] (no subject) On Mon, Dec 7, 2009 at 1:08 PM, Chris Engel wrote: > I mean how is it neccesary/useful for some-one to know >that Block X is owned by ACME Corp at 123 South Main >Street, if the entity who is ACTUALY responsible for handling technical >issues for them is Computer Consultants, Inc ? > > I would think that the information that would be required >to address the issue would be... > > IP Address #: x.x.x.x > Tech Contact E-mail: abuse at ComputerConsultants.com > Tech Contact Phone: 1-555-555-5555 > > Why is there a need to publish anything more then that? So you can serve them with legal papers. So that an ISP who suspects its competitor of fraud can spot-check the competitor's SWIP records against the local business listings and give ARIN a real complaint. -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Mon Dec 7 15:04:31 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 07 Dec 2009 12:04:31 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <28E139F46D45AF49A31950F88C497458046AA18E@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458046AA18E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B1D5FCF.6090100@ipinc.net> michael.dillon at bt.com wrote: >> As I stated, the residential privacy concerns expressed by >> other posters, including Michael Dillon, are bogus because >> the current policy allows the data for those resource holders >> to be sufficiently obscured as to protect them. > > "Allows for" is not good enough. The policy needs to make it > mandatory that useless contact data MUST NOT be published in > the ARIN whois database. It already is, Michael. The RSA that anyone getting numbering signs has a requirement that WHOIS data be accurate. The definition of the technical POC is that of the go-to guy for when there are problems. Thus, if an address assignor publishes useless data in the POC then they are in violation of the RSA. > If there is not a 24/7 network > operations NOC at the other end of the contact info, then > it MUST NOT be in the whois directory, period! > That is ridiculous. I very much doubt that the majority of assignors have a NOC that's staffed 24x7 by the people who can take care of this stuff. To give you a real-life example, our largest feed is TW Telecom. They have an 800 number in Denver that is staffed 24x7. But I have called it a few times late at night to complain about spamming in progress that originates from IP numbers of one of their other customers who is forging one of our customer e-mail addresses (thus our customer's mailbox is getting stuffed with backscatter) and I get the old bullcrap of "we'll take a trouble ticket but the guy that handles this won't be in until Monday morning" Your diluting your point with this 24x7 stuff. >> Further, most of the other concerns expressed are trivially >> addressed as I suggested below, by the organization in >> question getting a legitimate registered fictitious name or >> creating a corporation and using a mail receiving service for >> their address to do business with ARIN. >> >> Sure, there are costs associated with this, just as there is >> a fee for having your POTS telephone number unlisted. This >> allows resource holders to decide how much their privacy is >> worth to them. I would think you would be the last person to >> have a problem with such a mechanism. > > I don't think that you really understand who these > organizations in question really are. Imagine an > ISP that runs a data centre. They sell colocated > servers. ACME Inc. buys a bunch of them, and gets > a consultant to rig them up with Virtuozzo so that > they can sell VPS servers. Widjits Inc, then rents > a VPS and gets a consultant to set up a control panel > package. Thingamajig Design Inc, then rents a web > server package bundled with 10 domains. They then > sell a web site design service to Gewgaws Inc. on > one of those domains. The website that is supplied > is for a shopping cart e-store. Gewgaws Inc. then > offers a service to all and sundry whereby they > can offer their miscellaneous overstock goods for > sale on the e-store and Gewgaws will also run an > Ebay auction for the items if desired. Now one > of Gewgaws customers has recently had some products > rejected by Ebay so they take their products to > Gewgaws, for listing just on Gewgaws shop and > start a SPAM campaign to drive business to them. > > You would really like to contact Gewgaws to take > these pirate DVDs off their site but the problem > is that there is nobody technical at Gewgaws, in > fact the two owners are the only people there, > and they spend most of their time in their > high-school classes and after-school basketball. > Thingamajig also has nobody there except the > college student who works weekends on designing > websites. Widjits Inc. is another one-man band > who works evenings at Macdonalds. Now ACME does > have a technical guy working there, but he won't > do anything without orders from his boss because > it is his first job after graduating from journalism > school. > > Now tell me, what is wrong with keeping all of > these organizatons out of the whois directory > except for the ISP who got the allocation from > ARIN. That ISP is in a better position to track > something down this chain to the end, and if they > can't do it by phoning/emailing, they can always > pull the plug. Simples! > What is wrong is that the two owners of Gewgaws who spend most of their time in their high-school classes and after-school basketball DON'T WANT THEIR UPSTREAMS BOTHERED BY THIS STUFF. They WANT your complaint to be mailed TO THEM, they don't want it languishing in some in-box at the ISP who doesn't know who the hell they are - why should that ISP know anyway, he doesn't know ACME's customer list anyway. If you mail to the basketball players and they ignore you, then Thingamajig Design Inc. is probably the only ones in that mass of org names who knows who they are, and so you do the normal thing of going up the chain to the next more responsible party which is Thingamajig Design Inc., and you mail them. If Thingamajig Design Inc. is incompetent enough to think that they can get away with ignoring you, then when you go up the chain once more and Widjits Inc. then the college student at Thingamajig Design Inc. will suddenly get a real-life lesson. As will the basketball players who own Gewgaws Ted From owen at delong.com Mon Dec 7 14:59:09 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Dec 2009 11:59:09 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: Message-ID: <666E12FF-A72D-41AC-9615-7B9F7AF7CE46@delong.com> On Dec 7, 2009, at 9:14 AM, Chris Engel wrote: > > In the security world, the principle of "least privilege" is a well > established best practice. That is, granting the minimum level of > access/functionality/data in order to achieve a given task. I do not > believe it is an unreasonable position to hold forth that ARIN > should adhere to that best practice in regards to requirements for > WHOIS. > It is. WHOIS is not a security oriented service. WHOIS is a public disclosure service, intended to as part of an open public records process around IP number resource policy, distribution, etc. It makes little more sense to apply "least privilege" to whois than it would to apply it to property ownership records or other public records. > So let me put forth the question.... What is the legitimate NEED for > publicly accessible WHOIS lookup that can be accessed anonymously > and that has no gate-keeping functionality inherent to it? > It doesn't necessarily have to be anonymous, but, it should be publicly accessible. > The one LEGITIMATE case that I've heard put forth is that a > particular IP block is causing problems for another network by > misdirecting traffic to it or directing unwanted traffic to it. The > idea being that if the affected networks can lookup the contact > information for the IP block that is causing the problem and they > can inform them of the issue so it can be resolved (assuming that > the owner of the IP block is cooperative). Since the problem is > ongoing, timeliness of contact is an issue and placing barriers to > obtain that contact would be an unacceptable negative. I can see the > legitimacy of that claim. However, in that case, can anyone tell me > why you would need anything OTHER then a technical contact phone > number & e-mail ??? > In the event that the contact is uncooperative, the postal address gives you a starting point for legal service. > Note that this is far less information then what is currently > collected and published through SWIPS/WHOIS. > Um, not really... The additional data (other than the resource data itself) is the postal address and the name of the person or role (both of which I think are legitimate and useful as well). > How would knowing the legal name of the block-holder help you > resolve that issue?? If they've already provided you with a contact > e-mail and phone number ?? How would knowing their physical street > address help? Does anyone contend that sending snail mail is more > TIMELY then making a phone call or sending an e-mail? I don't even > see that knowing the real name of the technical contact would > help...if you had their e-mail & phone #. > I content that snail mail addresses are needed for the next step if they are uncooperative, as is the legal name of the block holder. Further, there is a public disclosure interest in knowing who is holding non-trivial amounts of IP number resources. This is one of the reasons that the database contains Technical _AND_ Administrative contacts. The administrative contact is, at least theoretically, there because there are legitimate non-technical reasons to contact a network. Abuse is not the only use case for WHOIS, just one of them. > Furthermore, I would posit that in MANY cases it actually makes more > sense for an organization to list their ISP's NOC in that contact > section. The ISP may not be authorized to take action to solve the > problem (outside of their function in dealing with actual abuse) but > they are FAR more likely to have a help desk that is monitored > 24/7/365 then most small/medium organizations. Furthermore the > organization MAY be willing to provide their ISP (or other trusted > agent) with an escalation and emergency contact list which might > include contact information (including home & private cell phone > numbers) that they would generally NOT be comfortable with > publishing publicly. > It might for the abuse use case, but, for the public disclosure interest, it is useful to know who actually holds the block, not which provider. > Can anyone put forward a case why the general public would > legitimately NEED any information beyond technical contact & e-mail? > If so I would like to hear it. > Because IP number resources are a public resource administered by the RIRs in trust for the public. Owen From tedm at ipinc.net Mon Dec 7 15:20:27 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 07 Dec 2009 12:20:27 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <75822E125BCB994F8446858C4B19F0D79EFB7A1C@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D79EFB7A18@SUEX07-MBX-04.ad.syr.edu> <6eb799ab0912051400g62889a7fv24e709d8039bad74@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D79EFB7A1C@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4B1D638B.3010803@ipinc.net> Milton L Mueller wrote: > James: > >> However, IP assignments with ARIN are not mapped to personal >> info. They are mapped to CONTACTS for a business organization. >> This is a person, a business address, and business phone number. > > Nothing wrong with that. Again, the essential issue to me is: what is > the purpose of the data collected? What data is required to fulfill > that purpose? so far so good > How can we limit the data collected to that which is > required for that purpose? > Bzzzzzt!!! Wrong wrong wrong. It is not YOUR right nor responsibility nor is it the right or responsibility of ARIN or this community to tell any ISP that wants to file a SWIP that lists the real-life name and contact info for a sub-assignor that they aren't allowed to do this. At least, it surely isn't right now. I may be a dyed-in-the-wool liberal but I'm not that stupid, the day that we allow CINO's * using this sort of reasoning to control discourse, is the day we lose all our freedoms to government. You slipped up, Milton. So far you were arguing that ISP's who WANT to limit SWIP data should be allowed to do so. But, your mask has slipped for everyone to see, as you mistakenly used the phrase "we limit" which stated what your REAL goal is - which is to start telling everyone what to do, what data they can and can't list. Your "we" in this context is you, yourself, Milton. It certainly isn't "I" or anyone else here that doesn't agree with you on this issue. You forget that YOU are seeking to CHANGE the status-quo, which is that SWIP data that discloses accurate contact data must be supplied, thus the burden of showing any benefits to the change is on YOU, it is NOT on US who are seeking to LEAVE THE STATUS QUO ALONE. From your posting it seems to me that this is a power trip/control issue with you, that it's all about controlling stuff, controlling what is in SWIPs, controlling who are the "chosen ones" with the rights to access what is in the WHOIS database. Your seeking to greatly complicate a simple database with a lot of unneeded access-control stuff that only makes it easier for wrongdoers to manipulate to hide themselves. For people who have real need to conceal themselves, the old "Universal Exports" dodge used by 007 and the CIA is always available, but even such a dodge only worked because it had Moneypenny RESPONDING. For the rest of them, nobody's going to care if they manufacture SWIP names out of thin air, as long as they publish an e-mail address and phone number that goes to a real human who is in control of the netblock, and once more, RESPONDS. Ted * CINO: Conservative In Name Only From owen at delong.com Mon Dec 7 15:18:42 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Dec 2009 12:18:42 -0800 Subject: [arin-ppml] (no subject) In-Reply-To: References: Message-ID: <9A9681E6-A6E7-444B-9CBF-C2F5BDC66574@delong.com> > Why, practically, should holding 9 IP's rather then 7 change the > requirements for that burden > Because you have to draw the line somewhere, and, 8 is where the line is currently drawn in IPv4. Realistically, <=8 IPs covers the vast majority of residential IPv4 needs and a great many small businesses as well. When you start using more than 8 globally unique IPv4 addresses, the likelihood that you are running a substantial network and/or publicly reachable servers, etc. goes up dramatically. > In terms of "checking up on competitors"..... A large part of > justification for IP space also has to do with expected upcoming > projects.... do you propose that ARIN should also publish > organizations future business plans (which would normally be covered > by NDA's) for their competitors to "check up" on them as well? > Clearly there are limits and points of diminishing return. Disclosing allocations of non-trivial amounts of IP resources to the community is an entirely reasonable thing and provides a good measure of check and balance capability without being overly burdensome or invasive. Publishing NDA information about future business plans is obviously both invasive and unlikely to significantly improve the audit capabilities in question. > ARIN, who has no vested interest in which ISP an individual customer > uses already has the capacity to investigate fraud. Why would you > vest that responsibility with competitor(s) who would have a vested > interest in throwing as many hurdles in front of their competition > as possible and who may have serious motivation to misuse such > information? > ARIN has very limited resources to identify and investigate fraud. Nobody is vesting competitors with responsibility to investigate fraud, but, some of us are saying that public disclosure of IP number resource distribution does aid in additional public scrutiny which can provide better input to help ARIN target their resources in a manner to provide the greatest public benefit. > Which would be more likely an ISP using such information to justify > an honest complaint of fraud on the part of a competitor or to > create a targeted sales list to try to steal the competitors > customers? ARIN's staff has both the capacity and the > responsibility to investigate fraud as well as the means for doing > something about it and lacks any motivation to use that information > for other purposes. An ISP has little real capacity or > responsibility to investigate a competitor and lacks the tools to do > anything about it other then to ask ARIN to investigate....but has a > great deal of motivation to use it for other purposes, does it not? > The former is more likely. The latter is a violation of the WHOIS AUP. Being able to use the whois data for an ISPs customers as a contrast with information from other sources can, in many cases, significantly improve the quality of the fraud reports ARIN receives. Owen > > Christopher Engel > > -----Original Message----- > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of > William Herrin > Sent: Monday, December 07, 2009 1:58 PM > To: Chris Engel > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] (no subject) > > > On Mon, Dec 7, 2009 at 1:08 PM, Chris Engel > wrote: >> I mean how is it neccesary/useful for some-one to know >> that Block X is owned by ACME Corp at 123 South Main >> Street, if the entity who is ACTUALY responsible for handling >> technical >> issues for them is Computer Consultants, Inc ? >> >> I would think that the information that would be required >> to address the issue would be... >> >> IP Address #: x.x.x.x >> Tech Contact E-mail: abuse at ComputerConsultants.com >> Tech Contact Phone: 1-555-555-5555 >> >> Why is there a need to publish anything more then that? > > So you can serve them with legal papers. > > So that an ISP who suspects its competitor of fraud can spot-check > the competitor's SWIP records against the local business listings > and give ARIN a real complaint. > > > > -- > > William D. Herrin ................ herrin at dirtside.com > bill at herrin.us 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Mon Dec 7 15:59:38 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 07 Dec 2009 12:59:38 -0800 Subject: [arin-ppml] (no subject) In-Reply-To: References: Message-ID: <4B1D6CBA.6030505@ipinc.net> Chris Engel wrote: > Bill, > > In each of those cases, there is no need for timeliness of access for > that information and there is an appropriate venue for providing > justification to get access to that information in a non-time > sensitive manner. > > In the case of serving an entity with legal papers, why would it NOT > be appropriate to expect the plaintiff to petition the courts for an > order to reveal the identity of the person you want to serve? The courts are already clogged and do not want even more work piled on them that is not important. They would like to stick to issuing disclosure orders to people who have actually had thousands of dollars removed from their bank accounts via fraud and are suing, and really don't want to have to do this for people who are complaining that their e-mail box has a lot of spam in it. > THAT is > the burden placed upon plaintiffs when wishing to serve posters on > individual forums/sites, holders of e-mail addresses or individual IP > address holders (rather then holders of a static block) is it not? > Why should the burden be ANY less in this instance? > For the same reason that the burden to the cop of proving you were speeding is NOT "beyond a reasonable doubt" when he writes you a ticket. The courts have recognized that there is a class of complaints that is not serious enough to warrant innocent-before-proven-guilty, proof-beyond-a-reasonable-doubt, jury trials, and all the other trappings of justice that we are accustomed to in criminal trials. This is where SWIP data is, is right in this realm. > Why, practically, should holding 9 IP's rather then 7 change the > requirements for that burden > > In terms of "checking up on competitors"..... A large part of > justification for IP space also has to do with expected upcoming > projects.... do you propose that ARIN should also publish > organizations future business plans (which would normally be covered > by NDA's) for their competitors to "check up" on them as well? > > ARIN, who has no vested interest in which ISP an individual customer > uses already has the capacity to investigate fraud. Why would you > vest that responsibility with competitor(s) who would have a vested > interest in throwing as many hurdles in front of their competition as > possible and who may have serious motivation to misuse such > information? > In which case the ISP can retaliate with the same games that the competitor is engaging in. For example, Verizon and Comcast found this out. Originally, Comcast sold only cable TV, and then they moved into selling Internet connectivity later. Verizon at that time sold voiceline services and Internet DSL. Then, Comcast moved into voice services. Verizon rightly regarded this as a violation of the mutual non-aggression pact, and dropped 3 billion into FIOS TV in retaliation. End result: neither gained market share. For what Comcast gained in voice, they lost in TV sales to FIOS TV. Ultimately, both Verizon and Comcast suffered billions of dollars in lost money since both had to build out networks - Comcast had to build out a voice network, Verizon had to build out a TV network. This is why these sorts of predatory maneuvers only work in the movies. > Which would be more likely an ISP using such information to justify > an honest complaint of fraud on the part of a competitor or to create > a targeted sales list to try to steal the competitors customers? The fraud complaint is far more likely. As I explained, the ISP creating a targeted sales list to go raiding is itself going to get raided. More of a concern, though, is the ISP going raiding is diverting attention from it's own customers, and is more likely to lose them as a result. > ARIN's staff has both the capacity and the responsibility to > investigate fraud as well as the means for doing something about it > and lacks any motivation to use that information for other purposes. > An ISP has little real capacity or responsibility to investigate a > competitor and lacks the tools to do anything about it other then to > ask ARIN to investigate....but has a great deal of motivation to use > it for other purposes, does it not? > I refer you to Aesop's fable "The Goatherd and the Wild Goats" to understand some things about business that I believe you are not familiar with. Ted > > Christopher Engel > > -----Original Message----- From: wherrin at gmail.com > [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Monday, > December 07, 2009 1:58 PM To: Chris Engel Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] (no subject) > > > On Mon, Dec 7, 2009 at 1:08 PM, Chris Engel > wrote: >> I mean how is it neccesary/useful for some-one to know that Block X >> is owned by ACME Corp at 123 South Main Street, if the entity who >> is ACTUALY responsible for handling technical issues for them is >> Computer Consultants, Inc ? >> >> I would think that the information that would be required to >> address the issue would be... >> >> IP Address #: x.x.x.x Tech Contact E-mail: >> abuse at ComputerConsultants.com Tech Contact Phone: 1-555-555-5555 >> >> Why is there a need to publish anything more then that? > > So you can serve them with legal papers. > > So that an ISP who suspects its competitor of fraud can spot-check > the competitor's SWIP records against the local business listings and > give ARIN a real complaint. > > > > -- > > William D. Herrin ................ herrin at dirtside.com > bill at herrin.us 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ PPML You are > receiving this message because you are subscribed to the ARIN Public > Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your > mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml Please contact > info at arin.net if you experience any issues. From cengel at sponsordirect.com Mon Dec 7 16:25:31 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Mon, 7 Dec 2009 16:25:31 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <666E12FF-A72D-41AC-9615-7B9F7AF7CE46@delong.com> Message-ID: Owen, Owen Delong wrote: "It is. WHOIS is not a security oriented service. WHOIS is a public disclosure service, intended to as part of an open public records process around IP number resource policy, distribution, etc. It makes little more sense to apply "least privilege" to whois than it would to apply it to property ownership records or other public records. " - This strikes me as a bit of a circular argument. You are essentially saying it's public because it's public. Doesn't really tell me WHY it should be public. "I content that snail mail addresses are needed for the next step if they are uncooperative, as is the legal name of the block holder." - At that point you are going to the Courts and/or Law Enforcment anyways. If you have sufficient justification to bring suit against that legal entity (or file a criminal complaint) then you should have sufficient justification to petition the courts for disclosure of their information. At that point you are no longer in the "timely resolution" phase of things, you are in the "due process" phase of things. I don't see why it would be an undue burden to require you to petition the courts for that if you are already going to them for a redress of grievances. Certainly, that is the case for many other virtual identity information (e-mail addresses, dynamically assigned IP addresses, forum names, individual website owners, etc). "The former is more likely. The latter is a violation of the WHOIS AUP." - Practically speaking, the ENFORCEMENT mechanisms for that policy are what? Those are anonymous public lookups and they happen all the time. It's all well and good to publish a policy but if your ability to enforce it for all practical purposes is next to nil....then the policy itself is worthless and might as well not exist. In some respects, I think this speaks directly to the issue at hand. Is ARIN really prepared to invest the resources to investigate the accuracy of ALL the information supplied by ALL the sub-delegations of IP address block space? Are they going to investigate that the name supplied by every sub-delegate is actually their real Legal Name? Are they going to investigate that the physical street address given for an entity is accurate. Are they even going to check the phone number and contact e-mail, and make sure that they are answered by a real person and not an auto-responder. If so....how often are they going to audit each one to make sure that it is still upto date? If they are unable to verify one or more pieces of such information... what enforcement mechanism will exist? In order to see any significant improvement in INVOLUNTARY compliance with WHOIS lookups over the present ALL that is going to have to be significantly beefed up..... and I imagine it will also invoke considerable ill will on the part of those being subject to such regulations. On the other hand, if you wish to increase VOLUNTARY compliance with WHOIS listing.... something that WON'T necessitate vast ENFORCEMENT resources, then the way to do so is to address the concerns of some of the people who are choosing to avoid participating in that system. Whether you like it or not, think it is stupid or not....one of those concerns is PRIVACY. In this day and age people (and organizations) are demanding more control over their own information.... how much of it is revealed, to whom and under what circumstances and justifications and whether records of such requests are available. Like it or not, this is a growing trend that will only increase. If you want people to VOLUNTARILY participate in such systems you can provide them with mechanisms for addressing their concerns.... otherwise be prepared to hire an army of virtual cops to ENFORCE compliance with your mandate. As I see it, those are your two options. Christopher Engel From tedm at ipinc.net Mon Dec 7 16:30:12 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 07 Dec 2009 13:30:12 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> Message-ID: <4B1D73E4.7060009@ipinc.net> Michel Py wrote: > Fred, > > I am a bit surprised you swallowed that bait; the IPv6 camp should be > desperate to send people of your caliber feeding controversies from me. > But I'll bite! I changed the subject; "IPv6 is a failure" is too > provocative and it is too early to make this determination yet. I hope > you will agree that the current state of IPv6 is "non-deployment". > > >>> Michel Py wrote: "IPv6 is a failure" ..[snip].. and a statement >>> that would have been widely seen as politically incorrect a few >>> years ago suddenly becomes an uncomfortable, unwanted but >>> nevertheless more prevalent every day reality check. > >> Fred Baker wrote: >> I agree that it is an important reality check. That said, I >> think that IPv6 has been since 1996 a solution developed in >> expectation of a problem. > > Unfortunately, only for some parts. This statement is valid for the > larger address space solving the expected problem of IPv4 shortage (and > to a lesser extent the problem of very large ISPs being too big for > 10.0.0.0/8 and even larger-than-class-A spaces). Some other parts of > IPv6 are either a solution looking for a problem, an undelivered > promise, or vendors trying to have it their way despite what the > consumer base says. > > - Solution looking for a problem: let's look at autoconfiguration: > first, it's not new to IPv6; we had that with IPX. Second, it addresses > a problem that ceased to be one for a long time: DHCP is working and is > available on any $20 cheesy "router". Third, it's not much of a > solution: if it was, there would be no need for DHCPv6. > > - Undelivered promise: routing table aggregation. If any IPv6 > multihoming solution (except like doing exactly the same as IPv4) was > working, the RIRs would not have already adopted policies allocating PI > addresses to non-LIR entities. > > - Vendors trying to have it their way: I understand this is not the > forum to debate my pet peeves with Cisco, but I will use a recent > real-world example: > Two weeks ago, I deployed a new customer network. Small; a handful of > remote sites. The routing protocol I used (and it was my call to make) > is EIGRP, because RIP and IGRP sucks and OSPF is too complex for the > customer. Where's EIGRP for IPv6? Maybe you could hint someone at Cisco > (evil grin) that instead of IPv6 with OSPFv6, the customers will keep > running IPv4 with EIGRP? > OSPF is not too complex, I've used it (on Cisco gear) for networks as small as having only 5 routers. The main use of EIGRP is to lock people in to Cisco gear, that's why Cisco pushes it. And in any case, since you admitted this is your call, your customer didn't obviously care what you used as long as it worked. > > Unfortunately, the IPv6 marketing is still using outdated arguments. The > bottom line is: the only real problem that IPv6 solves today is the > predicted shortage of IPv4 addresses. Some aspects of IPv6 are indeed > superior to IPv4, but not worth the increased complexity and cost. And > we mostly agree (see below) that in the end it's just a matter of big > bucks. > > >> People generally don't do things that cost them money until they see >> something resembling ROI, and folks on this list and in other places >> have seriously questioned the ROI. > > With some good reasons. > > >> In my opinion, IPv6 will have been demonstrated a failure if (a) the >> IPv4 address space doesn't run out or (b) when it does, IPv6 turns out >> to not be an adequate solution. It will have been an adequate solution >> perhaps *just* adequate, but adequate) if it gets deployed widely and >> as a result it becomes more straightforward for operators (ISP and >> enterprise) to run their networks. It will have been inadequate if in >> the long run if we see sustained use of complex work-arounds - 6to4, >> Teredo, ISATAP, 6rd, ds-lite, IPv4/IPv6 CGN, IPv4/IPv4 CGN, IPv4 A+P >> hacks, and so on - instead of IPv6 deployment. > > I agree with what's above. Unfortunately, there are so many workarounds > already that nobody really believes that they will be quickly eliminated > should native IPv6 deployment occur. We all have in our respective > closets a few skeletons of temporary-only-for-3-days-I-swear ugly hacks > that are still there 5 or 10 years after the fact. In other words: we > don't even have a clean start, and a large number of unproven hacks does > not appear any better than double NAT. > > >> The holy grail of minimized opex/capex to be found in relative >> operational simplicity, and that is IMHO to be found in a uniform >> contiguous address space. > > I agree with that too, but IPv6 brings a whole lot of new complexities, > one of the major no-nos being multiple addresses per host. Talk about > operational simplicity. Between two evils none of which is clearly a > lesser one, people will keep with the one currently in place. > > >> In my mind, IPv6 is the only approach on the >> table that has a hope of reducing costs. > > So far, it seems that not too many new people are believing in this > hope, and that more of those who used to believe it have become > disconnected from their previous faith. > > As of being the only solution on the table, it is. Double-NAT is > temporary-only-for-3-days-I-swear, right? > > I would entertain that IPv4+ (which would be a backwards-compatible IPv4 > with the only difference being an extended address space) would be much > more popular as a solution if it was on the table. > > Question: how many years after the last IPv4 block gets allocated to the > RIRs do we wait until we feel it is time to make that call? > It's really not "our" call to make. I frankly find a level of unreality in most discussions of IPv6 switchover on this list because so few bring up the real issue - Microsoft Windows. I well remember the time period 1993-1996 when most corporate networks started switching from IPX to TCP/IP. Windows for Workgroups with it's TCP/IP add-on support was just like Windows XP with it's IPv6 add-on support. Windows 95 is like Vista with IPv6 support with one huge, gigantic, grand-canyon difference - Win95 was immensely preferable to WFW 3.11, however Vista is NOT immensely preferable to XP. Most corporate shops I knew about - and I was working as a corporate network admin until '98 - fell over themselves in the rush to get rid of Windows 3.1 and WFW 3.11 and replace it with Windows 95. Holy baloney, don't any of you guys remember the old 16-bit NDIS hack? To support real-mode NDIS 2 network drivers in Windows 95? Or the gigantic number of drivers for old cruddy hardware that Microsoft stuffed into Win95 just because they were afraid that some fool with their Okidata 95 dot-matrix-printer might not get it to work under Win95 and go badmouthing the new OS to their friend? I mean, come on! It was only 14 years ago, not THAT long ago!! Win95 got a level of acceptance that has almost never been equaled before or since in the computer industry. Standards in Win95 - like TCP/IP - that most people didn't give a rat's ass about in pre-Win95 days - suddenly occupied front-and-center. It's no surprise that the explosion in interest in the Internet dated from that time. Today, though, Vista bombed hard, and it's too early to see what Win 7 will do - but I frankly don't see a huge reason to switch to it, and I have both Win XP and Win 7 at home and in the office. And seriously, folks, does everyone here understand that Microsoft will be releasing security updates and patches to XP Professional until 4/8/2014? That is almost 5 years from now. You can be sure that XP will be a significant number of installed seats on the Internet until then, and as long as it is, IPv6 isn't going to be widely deployed. As for IPv4+, or whatever alternative you dream up, unless you have MS buy-in, then you can just forget it. And MS is backing IPv6 Ted > Michel. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bill at herrin.us Mon Dec 7 16:43:36 2009 From: bill at herrin.us (William Herrin) Date: Mon, 7 Dec 2009 16:43:36 -0500 Subject: [arin-ppml] (no subject) In-Reply-To: References: <3c3e3fca0912071057q7b2555f0w70a2fbe742eca0d8@mail.gmail.com> Message-ID: <3c3e3fca0912071343k2d988791m646af0f9c8000d39@mail.gmail.com> On Mon, Dec 7, 2009 at 2:49 PM, Chris Engel wrote: > Why, practically, should holding 9 IP's rather then 7 change > the requirements for that burden It shouldn't. It also shouldn't be a text template email process. But it's enough of a nuisance to change it and nobody's beating down the door clamoring for improvement. My own viewpoint is that depending on how you look at it, holding IP addresses is either the same as owning a house or its the same as leasing an attachment on a power pole in a public right-of-way. In both cases, the public has a reasonable interest in and a reasonable right to know who the responsible legal entity is in detail. The ISPs have fought hard to avoid legal liability for user behavior. Disclosure is a reasonable price for that privilege. But that's strictly an opinion. I'm not interested in arguing about it and won't oppose policy either way. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From farmer at umn.edu Mon Dec 7 16:57:48 2009 From: farmer at umn.edu (David Farmer) Date: Mon, 07 Dec 2009 15:57:48 -0600 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B1D73E4.7060009@ipinc.net> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> <4B1D73E4.7060009@ipinc.net> Message-ID: <4B1D7A5C.2090502@umn.edu> Ted Mittelstaedt wrote: ... > Today, though, Vista bombed hard, and it's too early to see what Win 7 > will do - but I frankly don't see a huge reason to switch to it, and > I have both Win XP and Win 7 at home and in the office. And seriously, > folks, does everyone here understand that Microsoft will be releasing > security updates and patches to XP Professional until 4/8/2014? That > is almost 5 years from now. You can be sure that XP will be a > significant number of installed seats on the Internet until then, and > as long as it is, IPv6 isn't going to be widely deployed. > > As for IPv4+, or whatever alternative you dream up, unless you have MS > buy-in, then you can just forget it. And MS is backing IPv6 > > Ted AMEN!!!, +1, You got it man! FYI, look up DriectAccess in Windows7 and Windows Server 2008 R2. It is an IPv6 always on automated built-in VPN solution, for getting you back to your corporate support mother-ship. If the corporate desktop and laptop support people buy in to it, and the security people don't have a cow, IPv6 will take off in the corporate world. Yes, that is a big IF, but VPN is a big support and user headache and if this really makes that go away. Watch out, IPv6 may be coming to your office sooner then you might think. It is way to early to say for sure, I wouldn't necessarily be betting the farm on it, but I'm not sure I'd be betting against it either. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From spiffnolee at yahoo.com Mon Dec 7 17:08:46 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Mon, 7 Dec 2009 14:08:46 -0800 (PST) Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B1D73E4.7060009@ipinc.net> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> <4B1D73E4.7060009@ipinc.net> Message-ID: <923169.52385.qm@web63305.mail.re1.yahoo.com> Ted Mittelstaedt wrote: > does everyone here understand that Microsoft will be releasing > security updates and patches to XP Professional until 4/8/2014? Any chance they'll patch DNS to support IPv6? > You can be sure that XP will be a significant number of installed > seats on the Internet until then, and as long as it is, IPv6 isn't > going to be widely deployed. I use this site to judge number of seats: http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=10 Windows 7 already has 4% share. WinXP was end-of-sale June 2008. It will have been EOL for six years by 2014, which is longer than the typical life of a PC, and new PCs will have Windows 7. I don't know for how long it will be "significant," but no OS older than six years has even a tenth of a percent share. WinXP can run dual stack (but not IPv6-only), and so should not be a significant inhibitor to IPv6. Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Dec 7 17:07:38 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Dec 2009 14:07:38 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B1D7A5C.2090502@umn.edu> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> <4B1D73E4.7060009@ipinc.net> <4B1D7A5C.2090502@umn.edu> Message-ID: <80BC7E60-4521-49C5-9BE9-E56172224E14@delong.com> On Dec 7, 2009, at 1:57 PM, David Farmer wrote: > Ted Mittelstaedt wrote: > > ... > >> Today, though, Vista bombed hard, and it's too early to see what >> Win 7 >> will do - but I frankly don't see a huge reason to switch to it, and >> I have both Win XP and Win 7 at home and in the office. And >> seriously, >> folks, does everyone here understand that Microsoft will be >> releasing security updates and patches to XP Professional until >> 4/8/2014? That >> is almost 5 years from now. You can be sure that XP will be a >> significant number of installed seats on the Internet until then, and >> as long as it is, IPv6 isn't going to be widely deployed. >> As for IPv4+, or whatever alternative you dream up, unless you have >> MS >> buy-in, then you can just forget it. And MS is backing IPv6 >> Ted > > AMEN!!!, +1, You got it man! > 1. The lack of IPv6-only name resolution is not a significant barrier to IPv6 deployment. It would be a significant barrier to IPv4 removal. 2. If M$ is going to be releasing patches to XP until 2014, then, why would you assume those patches will never include a patch that enables DNS resolution from an IPv6 nameserver? In reality, this is only really an issue if you are attempting to deploy an XP system in an IPv6-only environment. As long as you deploy it in an IPv4 only or a dual-stack environment and provide it at least one IPv4-based resolver, things will work with IPv6. Owen From tedm at ipinc.net Mon Dec 7 17:49:22 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 07 Dec 2009 14:49:22 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <80BC7E60-4521-49C5-9BE9-E56172224E14@delong.com> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> <4B1D73E4.7060009@ipinc.net> <4B1D7A5C.2090502@umn.edu> <80BC7E60-4521-49C5-9BE9-E56172224E14@delong.com> Message-ID: <4B1D8672.4000908@ipinc.net> Owen DeLong wrote: > > On Dec 7, 2009, at 1:57 PM, David Farmer wrote: > >> Ted Mittelstaedt wrote: >> >> ... >> >>> Today, though, Vista bombed hard, and it's too early to see what Win 7 >>> will do - but I frankly don't see a huge reason to switch to it, and >>> I have both Win XP and Win 7 at home and in the office. And seriously, >>> folks, does everyone here understand that Microsoft will be releasing >>> security updates and patches to XP Professional until 4/8/2014? That >>> is almost 5 years from now. You can be sure that XP will be a >>> significant number of installed seats on the Internet until then, and >>> as long as it is, IPv6 isn't going to be widely deployed. >>> As for IPv4+, or whatever alternative you dream up, unless you have MS >>> buy-in, then you can just forget it. And MS is backing IPv6 >>> Ted >> >> AMEN!!!, +1, You got it man! >> > 1. The lack of IPv6-only name resolution is not a significant barrier to > IPv6 deployment. It would be a significant barrier to IPv4 removal. > > 2. If M$ is going to be releasing patches to XP until 2014, then, why would > you assume those patches will never include a patch that enables > DNS resolution from an IPv6 nameserver? > > In reality, this is only really an issue if you are attempting to deploy > an XP > system in an IPv6-only environment. As long as you deploy it in an IPv4 > only > or a dual-stack environment and provide it at least one IPv4-based > resolver, > things will work with IPv6. > I think this is wishful thinking. It was certainly very possible to dual-stack IPX and IP and for a few years people did - but most admins hated it - and pressured Novell to adopt IP and abandon IPX. Novell of course did not want to do that as it would unlock customers from NetWare - with the result that admins basically gave up on NetWare and went to Windows NT Server. (of course there were other reasons too) Dual-stack is a problem in the corporate world because you have increased training costs. Admins switched internal networks to IP last time because the Internet pushed them to do it. Likely they will want to wait until significant IPv6 is deployed on the Internet before switching internal networks to IPv6 this time, and nothing on the Internet is doing the pushing to IPv6, which is why I think it will be a longer time coming. Don't forget most corps are on licensing agreements with MS that give them rights to run ANY PRIOR version of Windows in addition to the corporate one. Regardless of whether XP is available on pre-loads or not, many corps. will be buying Vista systems them loading XP images on them for some time. Ted From farmer at umn.edu Mon Dec 7 18:07:27 2009 From: farmer at umn.edu (David Farmer) Date: Mon, 07 Dec 2009 17:07:27 -0600 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <80BC7E60-4521-49C5-9BE9-E56172224E14@delong.com> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> <4B1D73E4.7060009@ipinc.net> <4B1D7A5C.2090502@umn.edu> <80BC7E60-4521-49C5-9BE9-E56172224E14@delong.com> Message-ID: <4B1D8AAF.6030406@umn.edu> Owen DeLong wrote: > > On Dec 7, 2009, at 1:57 PM, David Farmer wrote: > >> Ted Mittelstaedt wrote: >> >> ... >> >>> Today, though, Vista bombed hard, and it's too early to see what Win 7 >>> will do - but I frankly don't see a huge reason to switch to it, and >>> I have both Win XP and Win 7 at home and in the office. And seriously, >>> folks, does everyone here understand that Microsoft will be releasing >>> security updates and patches to XP Professional until 4/8/2014? That >>> is almost 5 years from now. You can be sure that XP will be a >>> significant number of installed seats on the Internet until then, and >>> as long as it is, IPv6 isn't going to be widely deployed. >>> As for IPv4+, or whatever alternative you dream up, unless you have MS >>> buy-in, then you can just forget it. And MS is backing IPv6 >>> Ted >> >> AMEN!!!, +1, You got it man! Sorry, I guess I should have been a little more clear the AMEN was for the last part of Ted's statement, "unless you have MS buy-in, then you can just forget it. And MS is backing IPv6." > 1. The lack of IPv6-only name resolution is not a significant barrier to > IPv6 deployment. It would be a significant barrier to IPv4 removal. > > 2. If M$ is going to be releasing patches to XP until 2014, then, why would > you assume those patches will never include a patch that enables > DNS resolution from an IPv6 nameserver? > > In reality, this is only really an issue if you are attempting to deploy > an XP > system in an IPv6-only environment. As long as you deploy it in an IPv4 > only > or a dual-stack environment and provide it at least one IPv4-based > resolver, > things will work with IPv6. I completely agree, XP shouldn't really hamper IPv6 adoption, it just won't be much of a driver for it. I have IPv6 running on my XP desktops. It works OK. It would be nice if it did IPv6 for DNS transports, but it is not required in a dual-stack world. I only includes the earlier part because I wanted to mention DirectAccess and though it could very well be a driver for Windows 7 and IPv6 adoption. If you support networks for MS types you might want to look at DirectAccess. My MS types are already pushing hard for us (the Network people) and the security people to support DirectAccess. > Owen > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From owen at delong.com Mon Dec 7 18:34:14 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Dec 2009 15:34:14 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B1D8672.4000908@ipinc.net> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> <4B1D73E4.7060009@ipinc.net> <4B1D7A5C.2090502@umn.edu> <80BC7E60-4521-49C5-9BE9-E56172224E14@delong.com> <4B1D8672.4000908@ipinc.net> Message-ID: On Dec 7, 2009, at 2:49 PM, Ted Mittelstaedt wrote: > Owen DeLong wrote: >> On Dec 7, 2009, at 1:57 PM, David Farmer wrote: >>> Ted Mittelstaedt wrote: >>> >>> ... >>> >>>> Today, though, Vista bombed hard, and it's too early to see what >>>> Win 7 >>>> will do - but I frankly don't see a huge reason to switch to it, >>>> and >>>> I have both Win XP and Win 7 at home and in the office. And >>>> seriously, >>>> folks, does everyone here understand that Microsoft will be >>>> releasing security updates and patches to XP Professional until >>>> 4/8/2014? That >>>> is almost 5 years from now. You can be sure that XP will be a >>>> significant number of installed seats on the Internet until then, >>>> and >>>> as long as it is, IPv6 isn't going to be widely deployed. >>>> As for IPv4+, or whatever alternative you dream up, unless you >>>> have MS >>>> buy-in, then you can just forget it. And MS is backing IPv6 >>>> Ted >>> >>> AMEN!!!, +1, You got it man! >>> >> 1. The lack of IPv6-only name resolution is not a significant >> barrier to >> IPv6 deployment. It would be a significant barrier to IPv4 >> removal. >> 2. If M$ is going to be releasing patches to XP until 2014, then, >> why would >> you assume those patches will never include a patch that enables >> DNS resolution from an IPv6 nameserver? >> In reality, this is only really an issue if you are attempting to >> deploy an XP >> system in an IPv6-only environment. As long as you deploy it in an >> IPv4 only >> or a dual-stack environment and provide it at least one IPv4-based >> resolver, >> things will work with IPv6. > > I think this is wishful thinking. It was certainly very possible to > dual-stack IPX and IP and for a few years people did - but most admins > hated it - and pressured Novell to adopt IP and abandon IPX. Novell > of course did not want to do that as it would unlock customers from > NetWare - with the result that admins basically gave up on NetWare > and went to Windows NT Server. (of course there were other reasons > too) > > Dual-stack is a problem in the corporate world because you have > increased training costs. Admins switched internal networks to > IP last time because the Internet pushed them to do it. Likely > they will want to wait until significant IPv6 is deployed on the > Internet before switching internal networks to IPv6 this time, and > nothing on the Internet is doing the pushing to IPv6, which is why > I think it will be a longer time coming. > I don't really see this as a problem. Getting desktops over to dual stack really is last priority in my book. The important thing is getting servers and content providers dual-stacked, because, the first systems that will get forced to IPv6-only will be those that come on-line after IPv4 runout. Likely the bulk of those will be end-users of some form or other. > Don't forget most corps are on licensing agreements with MS that give > them rights to run ANY PRIOR version of Windows in addition to the > corporate one. Regardless of whether XP is available on pre-loads > or not, many corps. will be buying Vista systems them loading XP > images on them for some time. > Again, I really don't see this as a problem. Enterprise Desktop deployment of IPv6 really is last priority and for those enterprises that don't undertake to get it done in time, they are the ones that will suffer the impacts. Owen From farmer at umn.edu Mon Dec 7 18:58:29 2009 From: farmer at umn.edu (David Farmer) Date: Mon, 07 Dec 2009 17:58:29 -0600 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B1D8672.4000908@ipinc.net> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> <4B1D73E4.7060009@ipinc.net> <4B1D7A5C.2090502@umn.edu> <80BC7E60-4521-49C5-9BE9-E56172224E14@delong.com> <4B1D8672.4000908@ipinc.net> Message-ID: <4B1D96A5.1070402@umn.edu> Ted Mittelstaedt wrote: > Owen DeLong wrote: >> >> On Dec 7, 2009, at 1:57 PM, David Farmer wrote: >> >>> Ted Mittelstaedt wrote: >>> >>> ... >>> >>>> Today, though, Vista bombed hard, and it's too early to see what Win 7 >>>> will do - but I frankly don't see a huge reason to switch to it, and >>>> I have both Win XP and Win 7 at home and in the office. And seriously, >>>> folks, does everyone here understand that Microsoft will be >>>> releasing security updates and patches to XP Professional until >>>> 4/8/2014? That >>>> is almost 5 years from now. You can be sure that XP will be a >>>> significant number of installed seats on the Internet until then, and >>>> as long as it is, IPv6 isn't going to be widely deployed. >>>> As for IPv4+, or whatever alternative you dream up, unless you have MS >>>> buy-in, then you can just forget it. And MS is backing IPv6 >>>> Ted >>> >>> AMEN!!!, +1, You got it man! >>> >> 1. The lack of IPv6-only name resolution is not a significant barrier to >> IPv6 deployment. It would be a significant barrier to IPv4 removal. >> >> 2. If M$ is going to be releasing patches to XP until 2014, then, why >> would >> you assume those patches will never include a patch that enables >> DNS resolution from an IPv6 nameserver? >> >> In reality, this is only really an issue if you are attempting to >> deploy an XP >> system in an IPv6-only environment. As long as you deploy it in an >> IPv4 only >> or a dual-stack environment and provide it at least one IPv4-based >> resolver, >> things will work with IPv6. >> > > I think this is wishful thinking. It was certainly very possible to > dual-stack IPX and IP and for a few years people did - but most admins > hated it - and pressured Novell to adopt IP and abandon IPX. Novell > of course did not want to do that as it would unlock customers from > NetWare - with the result that admins basically gave up on NetWare > and went to Windows NT Server. (of course there were other reasons too) > > Dual-stack is a problem in the corporate world because you have > increased training costs. Admins switched internal networks to > IP last time because the Internet pushed them to do it. Likely > they will want to wait until significant IPv6 is deployed on the > Internet before switching internal networks to IPv6 this time, and > nothing on the Internet is doing the pushing to IPv6, which is why > I think it will be a longer time coming. > > Don't forget most corps are on licensing agreements with MS that give > them rights to run ANY PRIOR version of Windows in addition to the > corporate one. Regardless of whether XP is available on pre-loads > or not, many corps. will be buying Vista systems them loading XP > images on them for some time. > > Ted You are correct, dual-stack will only last for so long. The conversion from SNA, IPX and AppleTalk were all multiple years long, I'm not sure SNA is completely gone on my network yet, it is going to be the same for IPv4. I'm keeping my eye on v4-over-v6 solutions, virtualizing IPv4 over IPv6 in the enterprise network, maybe even ISP networks too. Basically turning IPv4 into an application over the IPv6 network much in the same way the VoIP has turned the voice PSTN network into an application of the IP network. There should be v4-over-v6 solutions available in a year or so, I hope. Which should be about right on time for me. Put it another way, so far IPv6 has been a second class citizen of the Internet, tunneled, etc... We are moving toward where in the next few years, I think IPv4 and IPv6 will become equal citizens on the Internet. Then in 3 to 5 years, maybe even sooner, IPv4 is going to become the second class "legacy" protocol. IPv4 is going to be around a long time, probably until 2040 or longer, hey SNA, IPX, and AppleTalk are sill around in places. And there are tons of SYNC and ASYNC serial converters to connect all kind of legacy building and process control systems and other long-term legacy application to current IP Networks. We have 20 and 30 year old building controllers connected that way for monitoring. Legacy systems can last a long time, just adapt and assimilate them. So some body just needs to make a NDIS stack shim that would make v4-over-v6 work for XP. This isn't any harder than the few dozed VPN shims that already exist today for XP, so I'm confident that someone will do it even if MS doesn't. It would probably make someone a nice little business for a few years, if MS doesn't squash them like a bug by coming out with there version of it a few months later. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From michael.dillon at bt.com Mon Dec 7 19:24:19 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 8 Dec 2009 00:24:19 -0000 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <666E12FF-A72D-41AC-9615-7B9F7AF7CE46@delong.com> Message-ID: <28E139F46D45AF49A31950F88C497458046AA90C@E03MVZ2-UKDY.domain1.systemhost.net> > Further, there is a public disclosure interest in knowing who > is holding non-trivial amounts of IP number resources. And in IPv6 only a /32 or shorter prefix is non-trivial. > Because IP number resources are a public resource > administered by the RIRs in trust for the public. That only justifies why we give the RIRs copious amounts of data under an NDA signed by the RIR and protected within the RIR so that only resource analysts can see this data. This does not jsutify a public directory. --Michael Dillon From michel at arneill-py.sacramento.ca.us Mon Dec 7 23:21:16 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 7 Dec 2009 20:21:16 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <0E89882F-C9D1-4311-93A5-36BE5AE61925@cisco.com> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> <0E89882F-C9D1-4311-93A5-36BE5AE61925@cisco.com> Message-ID: <4C1746A1D20C3148B6434776DFFF06C5055771@newserver.arneill-py.local> Fred, [In-line] >> Michel Py wrote: >> I would entertain that IPv4+ (which would be a backwards-compatible >> IPv4 with the only difference being an extended address space) would >> be much more popular as a solution if it was on the table. > Fred Baker wrote: > The obvious solution would be to put a source and destination AS > number in options in the IPv4 packet, and in the presence of such > a thing route to the remote AS before attempting to interpret the > address. I think the routing part of it does not matter. Remember: the goal here is to simplify adapting host software to the larger address space. > Recall that the problem there isn't a failure in the design of IPv6; > it's that IPv4 was not designed to have an extensible address. Ack that. > It would make a lot of sense. How, precisely, would you achieve that? With NAT, we already have a (crippled) 64-bit address space. Inside IP + Outside IP. Here are the design goals of IPlg: - Make the transition as simple and as cheap as possible for everyone. The only thing to achieve is a larger address space. Protocol enhancements shall be implemented only if they make the transition simpler. - Some rewriting will be required to use the full address space. As much as possible, that rewriting should be limited to using a 128-bit address instead of a 32-bit address. - Single stack (that is what I call backwards compatible); the IPlg stack must be able to handle both IPv4 and IPlg addresses. The IPlg stack replaces the IPv4 stack. - The critical part of IPlg is the IPv4 <-> IPlg NAT. The IPng address structure must be designed with this in mind, not as the most efficient or the most elegant. More specifically the IPlg address space will embed NAT hints, such as including both the public/outside and private/inside IPv4 addresses of a host behind a public/RFC1918 NAT device. There is a one-to-one mapping between an IPv4 and an IPlg address. The IPlg address space is a 128-bit address; for the transition phases, the IPv4 <-> IPlg NAT mechanism is based on a 64 bit unique identifier computed from 32bit-outside-address + 32bit-inside-address. In other words: the IPlg address space is to be designed primarily as a migration mechanism. The core of this migration is a workable and simple NAT between the two address spaces. We are designing workable NAT, not a new protocol. IPv4 -> IPlg: The edge/source IPlg router builds a source IPlg address with both the inside (possibly RFC1918) and the outside (public) addresses. The destination address is computed with the inside bits set to 0 (*), as they are not know. Both are valid IPlg address. When the returns traffic comes, the router remembers the mapping, strip the extra bits, and sends back to the IPv4 host. The egde/destination IPlg router understands that the destination address is from an IPv4-only host because the "inside bits" are all 0 and forwards to the right host based on manual rules (*). IPlg -> IPv4: The IPlg of the IPv4 host is to be used as the destination address by the originating host. (*) Some fancy NAT hints may come in here. 3 phases: - Compatible/test: production traffic is IPv4 to IPv4 only. Essentially the extra bits are padded with zeroes. The goal of this phase is to allow the deployment of the stack on routers/on the backbone. During this phase, a packet can cross both IPv4 and IPlg routers; when receiving a packet from an IPv4 router/host, the IPlg router pads the extra bits with zeroes. When sending an IPlg packet to an IPv4 router/host, the IPlg router strips the extra bits. This phase ends when the community is confident that the IPlg stack has been deployed. Obviously this will take many years during which RIRs will allocate IPlg addresses for tests. The IPlg block derived from the IPv4 address is automatically assigned to the IPv4 recepient. - Transition: IPv4 to IPlg translation shall occur only at the edge router, for those still using that W95 PC in 2020. The core shall handle only IPng traffic. - Decommission: we're all old and retired, we declare IPv4 is gone. Michel. From owen at delong.com Tue Dec 8 10:05:26 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Dec 2009 07:05:26 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <28E139F46D45AF49A31950F88C497458046AA90C@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458046AA90C@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <2BE6C691-0DFC-49E6-922E-90D4F4CC5866@delong.com> On Dec 7, 2009, at 4:24 PM, wrote: > >> Further, there is a public disclosure interest in knowing who >> is holding non-trivial amounts of IP number resources. > > And in IPv6 only a /32 or shorter prefix is non-trivial. > No. The boundary should be much longer than that. At least /48, probably at least /56, and, I don't think /60 would be unreasonable. >> Because IP number resources are a public resource >> administered by the RIRs in trust for the public. > > That only justifies why we give the RIRs copious amounts > of data under an NDA signed by the RIR and protected > within the RIR so that only resource analysts can see > this data. > Huh? > This does not jsutify a public directory. > We should agree to disagree at this point. Owen From tedm at ipinc.net Tue Dec 8 13:42:27 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 08 Dec 2009 10:42:27 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> <4B1D73E4.7060009@ipinc.net> <4B1D7A5C.2090502@umn.edu> <80BC7E60-4521-49C5-9BE9-E56172224E14@delong.com> <4B1D8672.4000908@ipinc.net> Message-ID: <4B1E9E13.8020900@ipinc.net> Owen DeLong wrote: > > On Dec 7, 2009, at 2:49 PM, Ted Mittelstaedt wrote: > >> Owen DeLong wrote: >>> On Dec 7, 2009, at 1:57 PM, David Farmer wrote: >>>> Ted Mittelstaedt wrote: >>>> >>>> ... >>>> >>>>> Today, though, Vista bombed hard, and it's too early to see what Win 7 >>>>> will do - but I frankly don't see a huge reason to switch to it, and >>>>> I have both Win XP and Win 7 at home and in the office. And >>>>> seriously, >>>>> folks, does everyone here understand that Microsoft will be >>>>> releasing security updates and patches to XP Professional until >>>>> 4/8/2014? That >>>>> is almost 5 years from now. You can be sure that XP will be a >>>>> significant number of installed seats on the Internet until then, and >>>>> as long as it is, IPv6 isn't going to be widely deployed. >>>>> As for IPv4+, or whatever alternative you dream up, unless you have MS >>>>> buy-in, then you can just forget it. And MS is backing IPv6 >>>>> Ted >>>> >>>> AMEN!!!, +1, You got it man! >>>> >>> 1. The lack of IPv6-only name resolution is not a significant barrier to >>> IPv6 deployment. It would be a significant barrier to IPv4 removal. >>> 2. If M$ is going to be releasing patches to XP until 2014, then, why >>> would >>> you assume those patches will never include a patch that enables >>> DNS resolution from an IPv6 nameserver? >>> In reality, this is only really an issue if you are attempting to >>> deploy an XP >>> system in an IPv6-only environment. As long as you deploy it in an >>> IPv4 only >>> or a dual-stack environment and provide it at least one IPv4-based >>> resolver, >>> things will work with IPv6. >> >> I think this is wishful thinking. It was certainly very possible to >> dual-stack IPX and IP and for a few years people did - but most admins >> hated it - and pressured Novell to adopt IP and abandon IPX. Novell >> of course did not want to do that as it would unlock customers from >> NetWare - with the result that admins basically gave up on NetWare >> and went to Windows NT Server. (of course there were other reasons too) >> >> Dual-stack is a problem in the corporate world because you have >> increased training costs. Admins switched internal networks to >> IP last time because the Internet pushed them to do it. Likely >> they will want to wait until significant IPv6 is deployed on the >> Internet before switching internal networks to IPv6 this time, and >> nothing on the Internet is doing the pushing to IPv6, which is why >> I think it will be a longer time coming. >> > I don't really see this as a problem. Getting desktops over to dual stack > really is last priority in my book. The important thing is getting servers > and content providers dual-stacked, because, the first systems that will > get forced to IPv6-only will be those that come on-line after IPv4 runout. > Likely the bulk of those will be end-users of some form or other. > Owen, there's a disconnect here - the people coming online post-IPv4 runout are not necessarily the people with brand new shiny Windows 7 and Windows Vista desktops that CAN speak IPv6. More likely they are the XP users in the third world. I agree that content providers NEED to be dual-stacked first, but what I am saying is that this time around, NOTHING is really acting as a driver for IPv6 deployment, (except IPv4 runout) and there are a LOT of things that are obstacles to IPv6. One of the big ones is XP. It is not that MS released IPv6 for XP missing DNS lookups. It is that MS released IPv6 -after the fact- because that REMOVED the onus on all of the 3rd party software developers to make sure their network applications worked in IPv6 environments. So, if your a commercial software developer and you certified that your stuff ran on XP, because IPv6 is an add-on for XP, you don't have to fix anything that breaks when your customers load the MS IPv6 add-on. Instead you can simply tell your customers that they have to buy the new version of your software that you released last year that is certified on Vista and Win 7 if they want to run IPv6. We have a number of customers, mixed XP/Vista/W7 environments, where they have legacy apps that break under Vista/W7. Their solution is to just use XP on user desktops that run those apps. Someday, maybe a few years from now after the recession is over, they might think about updating to newer versions of those apps. But, they likely won't until 2014 because those apps are extremely expensive, and there's a lot of labor in updating since the app vendors "thoughtfully" changed database layouts within the app, as well as screen interfaces, etc. Naturally, the app vendors want these customers to spend money updating, and so whenever there is a problem in the app, these customers are told upgrade and that problem will be fixed, even though the problem wouldn't really be fixed by upgrading, so essentially there's no support from the app vendor anymore (despite service contracts, etc.) and because of that these customers aren't going to deviate from their standard XP loads by loading the IPv6 add-on. And, until they are all Vista they won't even think of turning on IPv6 on any of their servers, and until they do that, they aren't going to run IPv6 internally, or connect to the IPv6 Internet, etc. This is what I mean when I say that XP serves as a drag on IPv6 deployment. Now I realize that these example customers aren't limiting content providers on the Internet from running dual-stack. But until the users are IPv6, many content providers won't feel the incentive to dual-stack, which I guess is just another way of saying that the biggest drag on IPv6 deployment is that IPv4 still works fine. The real truth of the matter is that we are lucky that Microsoft, Google, and the other large players who affect the Internet are all united behind IPv6, and all have enough time and labor invested in it that they are doing their part to bring it around. But, it's just going to take a lot more time to get to the tipping point I think than people realize. Ted From matthew at matthew.at Tue Dec 8 14:01:59 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 08 Dec 2009 11:01:59 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B1E9E13.8020900@ipinc.net> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> <4B1D73E4.7060009@ipinc.net> <4B1D7A5C.2090502@umn.edu> <80BC7E60-4521-49C5-9BE9-E56172224E14@delong.com> <4B1D8672.4000908@ipinc.net> <4B1E9E13.8020900@ipinc.net> Message-ID: <4B1EA2A7.9050204@matthew.at> Ted Mittelstaedt wrote: > > I agree that content providers NEED to be dual-stacked first,... And where will they be getting the IPv4 for that side of "dual-stacked" from after runout? And if that's via a mechanism that actually works well enough, then why would we need IPv6? Matthew Kaufman From Alain_Durand at cable.comcast.com Tue Dec 8 14:29:00 2009 From: Alain_Durand at cable.comcast.com (Durand, Alain) Date: Tue, 08 Dec 2009 14:29:00 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B1EA2A7.9050204@matthew.at> Message-ID: On 12/8/09 2:01 PM, "Matthew Kaufman" wrote: > Ted Mittelstaedt wrote: >> > >> > I agree that content providers NEED to be dual-stacked first,... > And where will they be getting the IPv4 for that side of "dual-stacked" > from after runout? > > ===> This is where a technology like dual-stack lite comes to play. See > http://www.ietf.org/id/draft-ietf-softwire-dual-stack-lite-02.txt > > And if that's via a mechanism that actually works well enough, then why > would we need IPv6? > > ===> Because a packet that flows natively over IPv6 is a packet that does not > have to go through the IPv4 NAT infrastructure. > In other words, the more v6 traffic, the less we spend on NATs. > > - Alain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From terry.l.davis at boeing.com Tue Dec 8 15:23:58 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Tue, 8 Dec 2009 12:23:58 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: <4B1EA2A7.9050204@matthew.at> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF55127B082C@XCH-NW-05V.nw.nos.boeing.com> It is interesting that we are now finally worried about the root causes of the v6 "non-deployment". Some of us have been worrying this for years... To me it comes down to a few points: - Cost of conversion! We need a truly seamless v4 to v6 interface to reduce implementation costs and risks. As it is, every year that goes by without v6 implementation increases its implementation cost and conversion risks; thus adding more resistance every year to conversion. - We need to get IPv6 addresses in the hands of the developers; especially the small greenfields. Perhaps our past address allocation policies just might have something to do with the problem. In the mid 80's to early 90's, an email request with almost zero justification would get 50 or 100 class Cs or a class B without regards to the size of the entity or what industry it was part of. Are we still too restrictive for the greenfields and new technology developers? - The vendors all need to show, advertise, and evangelize that their v6 products coexist harmlessly with existing v4 infrastructures so that a network owning organization (agency, enterprise, etc) will see no risk in adding v6 support to their networks. - New products and new product versions need to support both v4 and v6 seamlessly. A few folks have the right idea but not enough. Take care Terry ________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Durand, Alain Sent: Tuesday, December 08, 2009 11:29 AM To: matthew at matthew.at; Ted Mittelstaedt Cc: arin ppml Subject: Re: [arin-ppml] The non-deployment of IPv6 On 12/8/09 2:01 PM, "Matthew Kaufman" wrote: Ted Mittelstaedt wrote: > > I agree that content providers NEED to be dual-stacked first,... And where will they be getting the IPv4 for that side of "dual-stacked" from after runout? ===> This is where a technology like dual-stack lite comes to play. See http://www.ietf.org/id/draft-ietf-softwire-dual-stack-lite-02.txt And if that's via a mechanism that actually works well enough, then why would we need IPv6? ===> Because a packet that flows natively over IPv6 is a packet that does not have to go through the IPv4 NAT infrastructure. In other words, the more v6 traffic, the less we spend on NATs. - Alain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Tue Dec 8 16:51:24 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 08 Dec 2009 13:51:24 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B082C@XCH-NW-05V.nw.nos.boeing.com> References: <4B1EA2A7.9050204@matthew.at> <0267B5481DCC474D8088BF4A25C7F1DF55127B082C@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <4B1ECA5C.6090303@matthew.at> Davis, Terry L wrote: > > > - We need to get IPv6 addresses in the hands of the developers; > especially the small greenfields. Perhaps our past address allocation > policies just might have something to do with the problem. In the mid > 80?s to early 90?s, an email request with almost zero justification > would get 50 or 100 class Cs or a class B without regards to the size > of the entity or what industry it was part of. Are we still too > restrictive for the greenfields and new technology developers? > I would say yes. I have an experimental wireless backbone network spanning a fair bit of the Monterey Bay area. It runs IPv4 using pre-ARIN PI space I don't need to pay for, as I was an "early adopter" of IPv4. Renumbering of sites that are hours away at the tops of mountaintops with no out-of-band access isn't pleasant, so I like having the PI space. There's no equivalent way to get routeable IPv6 space for early adopters of IPv6, which seems crazy as there's so much more of it. Fortunately there's no need for IPv6 experimenters the way there was a need with IPv4, as there's a big established ISP industry rolling it out and they'll handle all of that this time around. Which probably explains why my transit provider(s) don't offer it yet. Matthew Kaufman From owen at delong.com Tue Dec 8 17:07:05 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Dec 2009 14:07:05 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B1ECA5C.6090303@matthew.at> References: <4B1EA2A7.9050204@matthew.at> <0267B5481DCC474D8088BF4A25C7F1DF55127B082C@XCH-NW-05V.nw.nos.boeing.com> <4B1ECA5C.6090303@matthew.at> Message-ID: <9D4D5859-4F93-4054-81BC-8AFA5CB34BC1@delong.com> On Dec 8, 2009, at 1:51 PM, Matthew Kaufman wrote: > Davis, Terry L wrote: >> >> >> - We need to get IPv6 addresses in the hands of the developers; >> especially the small greenfields. Perhaps our past address >> allocation policies just might have something to do with the >> problem. In the mid 80?s to early 90?s, an email request with >> almost zero justification would get 50 or 100 class Cs or a class B >> without regards to the size of the entity or what industry it was >> part of. Are we still too restrictive for the greenfields and new >> technology developers? >> > I would say yes. I have an experimental wireless backbone network > spanning a fair bit of the Monterey Bay area. It runs IPv4 using pre- > ARIN PI space I don't need to pay for, as I was an "early adopter" > of IPv4. Renumbering of sites that are hours away at the tops of > mountaintops with no out-of-band access isn't pleasant, so I like > having the PI space. > > There's no equivalent way to get routeable IPv6 space for early > adopters of IPv6, which seems crazy as there's so much more of it. > There is a somewhat equivalent way, but, it's not free. It was significantly reduced a couple of years ago, and, less reduced now, but, it's still reasonably cost effective. The details are at https://www.arin.net/fees/fee_schedule.html The policies are pretty liberal, and, if you have an existing IPv4 ISP block under RSA or LRSA, then, you get IPv6 on request, no questions asked (a /32 at that). If you're an end-user, you need to show that you're multihomed, but, that gets you a /48 for $1250 up front and the $100/year that you're already paying takes care of the rest. > Fortunately there's no need for IPv6 experimenters the way there was > a need with IPv4, as there's a big established ISP industry rolling > it out and they'll handle all of that this time around. Which > probably explains why my transit provider(s) don't offer it yet. > Either get better transit providers, or, prod them into providing IPv6 support. I'm doing quite well with my PI IPv6 space and my transit providers are routing it just fine. Owen From tedm at ipinc.net Tue Dec 8 20:40:12 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 08 Dec 2009 17:40:12 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B1ECA5C.6090303@matthew.at> References: <4B1EA2A7.9050204@matthew.at> <0267B5481DCC474D8088BF4A25C7F1DF55127B082C@XCH-NW-05V.nw.nos.boeing.com> <4B1ECA5C.6090303@matthew.at> Message-ID: <4B1EFFFC.4040301@ipinc.net> Matthew Kaufman wrote: > > Fortunately there's no need for IPv6 experimenters the way there was a > need with IPv4, as there's a big established ISP industry rolling it out > and they'll handle all of that this time around. Which probably explains > why my transit provider(s) don't offer it yet. > Have you asked them about IPv6? More importantly, have you asked them to ask THEIR upstream providers about native IPv6 since they probably have given you the (likely valid) excuse that none of their upstreams supply it yet, so they can't offer it. Ted From matthew at matthew.at Tue Dec 8 20:42:13 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 08 Dec 2009 17:42:13 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B1EFFFC.4040301@ipinc.net> References: <4B1EA2A7.9050204@matthew.at> <0267B5481DCC474D8088BF4A25C7F1DF55127B082C@XCH-NW-05V.nw.nos.boeing.com> <4B1ECA5C.6090303@matthew.at> <4B1EFFFC.4040301@ipinc.net> Message-ID: <4B1F0075.1080405@matthew.at> Ted Mittelstaedt wrote: > Matthew Kaufman wrote: > >> >> Fortunately there's no need for IPv6 experimenters the way there was >> a need with IPv4, as there's a big established ISP industry rolling >> it out and they'll handle all of that this time around. Which >> probably explains why my transit provider(s) don't offer it yet. >> > > Have you asked them about IPv6? More importantly, have you asked them > to ask THEIR upstream providers about native IPv6 since they probably > have given you the (likely valid) excuse that none of their upstreams > supply it yet, so they can't offer it. Yes, at least the last time I talked to each (Abovenet, who was my upstream until I sold that ISP a few weeks ago and Cogent, who really wanted to be an upstream) they couldn't supply it. Matthew Kaufman From tedm at ipinc.net Tue Dec 8 20:56:02 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 08 Dec 2009 17:56:02 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B1F0075.1080405@matthew.at> References: <4B1EA2A7.9050204@matthew.at> <0267B5481DCC474D8088BF4A25C7F1DF55127B082C@XCH-NW-05V.nw.nos.boeing.com> <4B1ECA5C.6090303@matthew.at> <4B1EFFFC.4040301@ipinc.net> <4B1F0075.1080405@matthew.at> Message-ID: <4B1F03B2.50205@ipinc.net> Matthew Kaufman wrote: > Ted Mittelstaedt wrote: >> Matthew Kaufman wrote: >> >>> >>> Fortunately there's no need for IPv6 experimenters the way there was >>> a need with IPv4, as there's a big established ISP industry rolling >>> it out and they'll handle all of that this time around. Which >>> probably explains why my transit provider(s) don't offer it yet. >>> >> >> Have you asked them about IPv6? More importantly, have you asked them >> to ask THEIR upstream providers about native IPv6 since they probably >> have given you the (likely valid) excuse that none of their upstreams >> supply it yet, so they can't offer it. > Yes, at least the last time I talked to each (Abovenet, who was my > upstream until I sold that ISP a few weeks ago and Cogent, who really > wanted to be an upstream) they couldn't supply it. > abovenet is most definitely interconnected with at least one transit AS who IS running IPv6 natively, so you need to translate "couldn't" to "is choosing not to for whatever reason" I'd find it very hard to believe that abovenet is not running current enough JunOS or IOS (or whatever) to support IPv6 on their routers to where they actually "couldn't" I think that we all really ought to agree that 2010 is the year that ISP's stop accepting the "I can't" excuse from their upstreams when they ask about IPv6 and insist on being told the real truth on why the upstream isn't doing it. A transit AS would have to have an extremely gnarly backbone that actually "couldn't" run it. I mean, even stuff that you fish out of the Dumpsters behind the better ISP's can run IPv6 now. Ted From tedm at ipinc.net Tue Dec 8 21:11:52 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 08 Dec 2009 18:11:52 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B1EA2A7.9050204@matthew.at> References: <2A7965F9-33CD-4820-8E0B-D59AE7083175@arin.net> <4C1746A1D20C3148B6434776DFFF06C5055762@newserver.arneill-py.local> <744E906B-416B-4CF7-A62D-F9208EC75123@cisco.com> <4C1746A1D20C3148B6434776DFFF06C505576A@newserver.arneill-py.local> <4B1D73E4.7060009@ipinc.net> <4B1D7A5C.2090502@umn.edu> <80BC7E60-4521-49C5-9BE9-E56172224E14@delong.com> <4B1D8672.4000908@ipinc.net> <4B1E9E13.8020900@ipinc.net> <4B1EA2A7.9050204@matthew.at> Message-ID: <4B1F0768.1020607@ipinc.net> Matthew Kaufman wrote: > Ted Mittelstaedt wrote: >> >> I agree that content providers NEED to be dual-stacked first,... > And where will they be getting the IPv4 for that side of "dual-stacked" > from after runout? > For all we love and enjoy bantering around the term IPv4-runout as though it is going to be some seminal event that will shake the foundations of the Internet, in reality the actual process is an ongoing event that merely will make IPv4 more and more expensive for those who need it. In essence runout has already started - if you don't believe this statement, I invite you to attempt to obtain a /8 from an RIR and see what they say - even if you provide adequate justification (as some networks, like the cellular net, could easily do) > And if that's via a mechanism that actually works well enough, then why > would we need IPv6? > Muh ha ha ha haaaa! Ted > Matthew Kaufman From tedm at ipinc.net Tue Dec 8 21:18:46 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 08 Dec 2009 18:18:46 -0800 Subject: [arin-ppml] Why would we need IPv6? Message-ID: <4B1F0906.3070608@ipinc.net> Hopefully my crude plagiarism will give you a laugh: http://www.ipinc.net/IPv4.GIF Ted From joelja at bogus.com Tue Dec 8 21:23:01 2009 From: joelja at bogus.com (joel jaeggli) Date: Tue, 08 Dec 2009 20:23:01 -0600 Subject: [arin-ppml] The non-deployment of IPv6 Message-ID: <4B1F0768.1020607@ipinc.net> The moment when scarcity became obvious is way back in the early 90s. We've been opperating under scarcity for so long that few remeber what it was like before that. The internet that we built since 1992 was built under a scarcity regieme. Ted Mittelstaedt wrote: >Matthew Kaufman wrote: >> Ted Mittelstaedt wrote: >>> >>> I agree that content providers NEED to be dual-stacked first,... >> And where will they be getting the IPv4 for that side of "dual-stacked" >> from after runout? >> > >For all we love and enjoy bantering around the term IPv4-runout as >though it is going to be some seminal event that will shake the >foundations of the Internet, in reality the actual process is >an ongoing event that merely will make IPv4 more and more expensive >for those who need it. > >In essence runout has already started - if you don't believe this >statement, I invite you to attempt to obtain a /8 from an RIR and >see what they say - even if you provide adequate justification >(as some networks, like the cellular net, could easily do) > >> And if that's via a mechanism that actually works well enough, then why >> would we need IPv6? >> > >Muh ha ha ha haaaa! > >Ted > >> Matthew Kaufman > >_______________________________________________ >PPML >You are receiving this message because you are subscribed to >the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. > From sethm at rollernet.us Wed Dec 9 00:47:46 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 08 Dec 2009 21:47:46 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B1F03B2.50205@ipinc.net> References: <4B1EA2A7.9050204@matthew.at> <0267B5481DCC474D8088BF4A25C7F1DF55127B082C@XCH-NW-05V.nw.nos.boeing.com> <4B1ECA5C.6090303@matthew.at> <4B1EFFFC.4040301@ipinc.net> <4B1F0075.1080405@matthew.at> <4B1F03B2.50205@ipinc.net> Message-ID: <4B1F3A02.9030307@rollernet.us> Ted Mittelstaedt wrote: > > I think that we all really ought to agree that 2010 is the year > that ISP's stop accepting the "I can't" excuse from their upstreams when > they ask about IPv6 and insist on being told the real truth on why > the upstream isn't doing it. A transit AS would have to have an > extremely gnarly backbone that actually "couldn't" run it. I mean, even > stuff that you fish out of the Dumpsters behind the better ISP's can run > IPv6 now. > Believe me, I tried really, really hard with Verizon. When I turned down my SAVVIS circuit for other reasons, I mentioned that native IPv6 could have persuaded me to keep it anyway. I keep checking with Sprint from time to time (hi, Wes) to see if/when I can convert my tunnel to native. ~Seth From warren at wholesaleinternet.com Wed Dec 9 01:10:30 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Wed, 9 Dec 2009 00:10:30 -0600 Subject: [arin-ppml] Why would we need IPv6? In-Reply-To: <4B1F0906.3070608@ipinc.net> References: <4B1F0906.3070608@ipinc.net> Message-ID: <9F47912DF95B4816992C57472BC0F2F3@johnsonvhjjf8v> A better cartoon: Show a bunch of business people looking over their right shoulder and down the road at a town named "Success". A road sign says "Success 982 miles". On the business people feet are shoes that don't look comfortable to walk in and are already almost worn out from walking. In front of them is an auction stage with that ipv4 Volkswagon bus on it, looking all beat up and everyone is bidding a lot of money to get that Volkswagon bus because even though it's expensive it's a more attractive option than walking to "Success". You might even add a bus stop on the corner that says "IPv6" with a map indicating that it'll probably be another 20 stops (years) before the bus makes it from the bus stop to "Success". And while the IPv6 bus is nice and comfy and cheap, it still doesn't get you there before the party is over. :-) -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Tuesday, December 08, 2009 8:19 PM To: arin ppml Subject: [arin-ppml] Why would we need IPv6? Hopefully my crude plagiarism will give you a laugh: http://www.ipinc.net/IPv4.GIF Ted _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From cengel at sponsordirect.com Wed Dec 9 10:16:50 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Wed, 9 Dec 2009 10:16:50 -0500 Subject: [arin-ppml] The non-deployment of IPv6 Message-ID: Well, speaking for myself and the Enterprise I manage..... I see absolutely no reason to do IPv6 at the present time. There is no benefit to it and a fairly decent cost. Furthermore the paradigm is sufficiently different that it's not like it's a seemless transition from v4. If they had just taken 4 and tacked on a few more octets but made no other changes as to how it worked, that might be a bit of a different story. No surprise that many Enterprises aren't rusing to adopt. The key question for an Enterprise Admin is do you have control over the hardware and networks on which the services you provide depend? If the answer to that is ....yes.... then looking to switch to v6 really makes no sense. The point at which you need to do something about v6 is when you are going to start getting external traffic (SMTP, HTTP, etc.) from v6 only users... or when your own users are going to start to want to access v6 only sites. That, I imagine is still a fair ways off. When that happens what the Enterprise Admin is most likely to look at doing is layering in support for those functions in a way that requires the MINIMUM neccesary changes to thier existing infrastructure. I imagine that will be some variety of v4 to v6 gateway services or something like that. A few years down the road, if some-one is building a new network from the ground up I could see them maybe deciding to go v6 native. However, for existing networks...as long as there are robust v4 to v6 solutions available....and I imagine there will be due to demand.... I can't see any reason to switch away from v4 native for the forseeable future. Chris Engel From jcurran at arin.net Wed Dec 9 10:38:23 2009 From: jcurran at arin.net (John Curran) Date: Wed, 9 Dec 2009 10:38:23 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: Message-ID: Chris - By "doing IPv6", do you mean for your internal network, desktops, and servers? Or do you mean for your public-facing web and mail servers? /John John Curran President and CEO ARIN On Dec 9, 2009, at 10:16 AM, Chris Engel wrote: > > Well, speaking for myself and the Enterprise I manage..... I see absolutely no reason to do IPv6 at the present time. There is no benefit to it and a fairly decent cost. Furthermore the paradigm is sufficiently different that it's not like it's a seemless transition from v4. If they had just taken 4 and tacked on a few more octets but made no other changes as to how it worked, that might be a bit of a different story. No surprise that many Enterprises aren't rusing to adopt. The key question for an Enterprise Admin is do you have control over the hardware and networks on which the services you provide depend? If the answer to that is ....yes.... then looking to switch to v6 really makes no sense. > The point at which you need to do something about v6 is when you are going to start getting external traffic (SMTP, HTTP, etc.) from v6 only users... or when your own users are going to start to want to access v6 only sites. That, I imagine is still a fair ways off. > > When that happens what the Enterprise Admin is most likely to look at doing is layering in support for those functions in a way that requires the MINIMUM neccesary changes to thier existing infrastructure. I imagine that will be some variety of v4 to v6 gateway services or something like that. A few years down the road, if some-one is building a new network from the ground up I could see them maybe deciding to go v6 native. However, for existing networks...as long as there are robust v4 to v6 solutions available....and I imagine there will be due to demand.... I can't see any reason to switch away from v4 native for the forseeable future. > > > Chris Engel > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Wed Dec 9 11:02:12 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Dec 2009 08:02:12 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: Message-ID: <4F8F5DEB-BDBA-49A9-9ADA-B8E98D39CFBB@delong.com> On Dec 9, 2009, at 7:16 AM, Chris Engel wrote: > > Well, speaking for myself and the Enterprise I manage..... I see absolutely no reason to do IPv6 at the present time. There is no benefit to it and a fairly decent cost. Furthermore the paradigm is sufficiently different that it's not like it's a seemless transition from v4. If they had just taken 4 and tacked on a few more octets but made no other changes as to how it worked, that might be a bit of a different story. No surprise that many Enterprises aren't rusing to adopt. The key question for an Enterprise Admin is do you have control over the hardware and networks on which the services you provide depend? If the answer to that is ....yes.... then looking to switch to v6 really makes no sense. Yep... In general, the enterprise desktop will be the last group of users to migrate to dual-stack. Probably not doing so until forced to by IPv6-only desirable content, or, by running out of IPv4 addressing resources within the enterprise. That's OK. The big push right now really needs to be ISP backbones (quickest conversion, really, and the simplest at this point) and Content providers (also relatively easy). If those two groups get to dual-stack before runout, then, most of the rest will be a non-issue as they can migrate at their leisure without much systemic impact. > The point at which you need to do something about v6 is when you are going to start getting external traffic (SMTP, HTTP, etc.) from v6 only users... or when your own users are going to start to want to access v6 only sites. That, I imagine is still a fair ways off. > It's probably about 3 years away at this point, realistically. I wouldn't count on it being any further off, and, it could be as close as 2 years, but, I think that's unlikely. > When that happens what the Enterprise Admin is most likely to look at doing is layering in support for those functions in a way that requires the MINIMUM neccesary changes to thier existing infrastructure. I imagine that will be some variety of v4 to v6 gateway services or something like that. A few years down the road, if some-one is building a new network from the ground up I could see them maybe deciding to go v6 native. However, for existing networks...as long as there are robust v4 to v6 solutions available....and I imagine there will be due to demand.... I can't see any reason to switch away from v4 native for the forseeable future. > There's nothing wrong with this approach. I think that in general, the IPv6 push has done a poor job of focusing on the critical early points of conversion, and, many people still seem to have the misperception that this is a migration to IPv6 rather than the addition of IPv6 capabilities to the IPv4 network. Owen From Keith at jcc.com Wed Dec 9 11:36:04 2009 From: Keith at jcc.com (Keith W. Hare) Date: Wed, 9 Dec 2009 11:36:04 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: Message-ID: >From my viewpoint as a small network, the obstacles to implementing IPv6 are: 1. Finding firewall (or whatever vendors are calling it today) equipment that supports IPv6 2. Finding an upstream that supports IPv6 As you jump up and down and yell that there are lots of network hardware vendors that support IPv6, take a few minutes and see if you can find where on their web sites and spec sheets they document IPv6 support. For a firewall, I need something in the $5,000 range, so I don't have a dedicated sales person. Every time I go out and start looking at equipment in that ball park, I get really frustrated, because the vendors don't think IPv6 support is important enough to document clearly, in large print. I do have a small Linksys/Cisco router with some IPv6 support (Thanks for the recommendation Ted) that I'm using as a gateway. It would allow me to set up an IPv6 tunnel to a tunnel broker someplace. However, I see no point in doing this until I get a firewall that supports IPv6. I periodically ask my sales rep for my current upstream (Windstream) about IPv6. As yet, she has not gotten any information about Windstream's IPv6 plans. I recently talked to a sales rep for TimeWarner Business and asked about IPv6. He didn't admit to knowing anything about IPv6 support. From discussions on this list, I know TimeWarner is working on IPv6, but the local guy doesn't know about it. I contend that until IPv6 is important enough that IPv6 support is in big print in the spec sheets and on the outside of the boxes, there isn't going to be a demand for IPv6. In answer to John Curran's question about internal versus external, I would start with IPv6 internally on servers and a couple of desktops then when I understood IPv6 well enough, I'd deploy it externally on web servers, DNS servers, etc. This order is the opposite of what many might do, but since we are database consultants, our internal network is primarily used for software development and testing. Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From cengel at sponsordirect.com Wed Dec 9 11:37:12 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Wed, 9 Dec 2009 11:37:12 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: , Message-ID: John, Both. Public facing servers in the Enterprise are generaly NAT'd behind a firewall and running on Private IP space in a DMZ anyways (that's our setup and it's pretty typical of what I've seen). So even if we were to scale up to the point where we needed more external IP space and v6 was all that was available.... the only thing we would need to do....and would likely make sense to do would be to find a perimeter device that could handle v6 to v4 NATing to support those extra external v6 IP's on it's public interface (and that's assuming I need to scale beyond my current space in the first place). In other words, why would I want to try to re-invent the wheel when I don't need to, it net's me no functional advantage for my purposes and comes at considerable cost ?? The killer question is will we be able to find robust v4 to v6 solutions when the time comes when we need to get traffic from v6 only external users or sending traffic to v6 only sites. I am assuming the answer to that question will be.... yes.....since when the time comes there is going to be a huge demand for them. If the answer to that question turns out not to be true....then I could see the need to look at dual-stacking inside the perimeter. Chris Engel ________________________________________ From: John Curran [jcurran at arin.net] Sent: Wednesday, December 09, 2009 10:38 AM To: Chris Engel Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] The non-deployment of IPv6 Chris - By "doing IPv6", do you mean for your internal network, desktops, and servers? Or do you mean for your public-facing web and mail servers? /John John Curran President and CEO ARIN On Dec 9, 2009, at 10:16 AM, Chris Engel wrote: > > Well, speaking for myself and the Enterprise I manage..... I see absolutely no reason to do IPv6 at the present time. There is no benefit to it and a fairly decent cost. Furthermore the paradigm is sufficiently different that it's not like it's a seemless transition from v4. If they had just taken 4 and tacked on a few more octets but made no other changes as to how it worked, that might be a bit of a different story. No surprise that many Enterprises aren't rusing to adopt. The key question for an Enterprise Admin is do you have control over the hardware and networks on which the services you provide depend? If the answer to that is ....yes.... then looking to switch to v6 really makes no sense. > The point at which you need to do something about v6 is when you are going to start getting external traffic (SMTP, HTTP, etc.) from v6 only users... or when your own users are going to start to want to access v6 only sites. That, I imagine is still a fair ways off. > > When that happens what the Enterprise Admin is most likely to look at doing is layering in support for those functions in a way that requires the MINIMUM neccesary changes to thier existing infrastructure. I imagine that will be some variety of v4 to v6 gateway services or something like that. A few years down the road, if some-one is building a new network from the ground up I could see them maybe deciding to go v6 native. However, for existing networks...as long as there are robust v4 to v6 solutions available....and I imagine there will be due to demand.... I can't see any reason to switch away from v4 native for the forseeable future. > > > Chris Engel > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jcurran at arin.net Wed Dec 9 15:39:21 2009 From: jcurran at arin.net (John Curran) Date: Wed, 9 Dec 2009 15:39:21 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: , Message-ID: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> On Dec 9, 2009, at 11:37 AM, Chris Engel wrote: > John, > > Both. Public facing servers in the Enterprise are generaly NAT'd behind a firewall and running on Private IP space in a DMZ anyways (that's our setup and it's pretty typical of what I've seen). So even if we were to scale up to the point where we needed more external IP space and v6 was all that was available.... the only thing we would need to do....and would likely make sense to do would be to find a perimeter device that could handle v6 to v4 NATing to support those extra external v6 IP's on it's public interface (and that's assuming I need to scale beyond my current space in the first place). In other words, why would I want to try to re-invent the wheel when I don't need to, it net's me no functional advantage for my purposes and comes at considerable cost ?? I agree that you don't want to reinvent the wheel. My question is whether you'd consider getting that IPv6 address configured for your public mail and email servers sooner rather than later. The principle reason is that others could easily need that IPv6 access to your public servers well before your own internal community realizes it. /John John Curran President and CEO ARIN From ptimmins at clearrate.com Wed Dec 9 15:31:36 2009 From: ptimmins at clearrate.com (Paul G. Timmins) Date: Wed, 9 Dec 2009 15:31:36 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B1F3A02.9030307@rollernet.us> References: <4B1EA2A7.9050204@matthew.at> <0267B5481DCC474D8088BF4A25C7F1DF55127B082C@XCH-NW-05V.nw.nos.boeing.com> <4B1ECA5C.6090303@matthew.at><4B1EFFFC.4040301@ipinc.net> <4B1F0075.1080405@matthew.at><4B1F03B2.50205@ipinc.net> <4B1F3A02.9030307@rollernet.us> Message-ID: I have IPv6 though Verizon Business. If you need some contacts, let me know. Note that they use GRE tunnels, and they're using some sort of broken juniper gear with MTU issues. -Paul -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Seth Mattinen Sent: Wednesday, December 09, 2009 12:48 AM To: arin ppml Subject: Re: [arin-ppml] The non-deployment of IPv6 Ted Mittelstaedt wrote: > > I think that we all really ought to agree that 2010 is the year > that ISP's stop accepting the "I can't" excuse from their upstreams when > they ask about IPv6 and insist on being told the real truth on why > the upstream isn't doing it. A transit AS would have to have an > extremely gnarly backbone that actually "couldn't" run it. I mean, even > stuff that you fish out of the Dumpsters behind the better ISP's can run > IPv6 now. > Believe me, I tried really, really hard with Verizon. When I turned down my SAVVIS circuit for other reasons, I mentioned that native IPv6 could have persuaded me to keep it anyway. I keep checking with Sprint from time to time (hi, Wes) to see if/when I can convert my tunnel to native. ~Seth _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Wed Dec 9 15:51:56 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 09 Dec 2009 12:51:56 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: Message-ID: <4B200DEC.60200@ipinc.net> Chris Engel wrote: > Well, speaking for myself and the Enterprise I manage..... I see > absolutely no reason to do IPv6 at the present time. There is no > benefit to it and a fairly decent cost. Chris, It's pretty common for people on this list to throw a lot of generalizations around, and cost is a favorite. Understand that I'm not picking on you here since a lot of other orgs are saying the same thing, but for the sake of example would you be willing to list the specifics of what you found would be costly for your org to support it? Typically what stops orgs from deploying is specific problems, not general ones, and unless we talk specifics the discussion turns into more of a philosophical discussion about what's right, and nothing gets solved. With my org our main cost was labor, that is yours truly labor hours. All the equipment we use supports it, the labor part was in creating and testing configuration changes, and I did that in between doing my real work. (you might argue that IS my real work, also, heh heh) And I still have work to do, our DNS servers are overdue for software upgrades that I keep meaning to set aside time for, but have not yet done. Ted From sethm at rollernet.us Wed Dec 9 16:07:24 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 09 Dec 2009 13:07:24 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: <4B1EA2A7.9050204@matthew.at> <0267B5481DCC474D8088BF4A25C7F1DF55127B082C@XCH-NW-05V.nw.nos.boeing.com> <4B1ECA5C.6090303@matthew.at><4B1EFFFC.4040301@ipinc.net> <4B1F0075.1080405@matthew.at><4B1F03B2.50205@ipinc.net> <4B1F3A02.9030307@rollernet.us> Message-ID: <4B20118C.4040406@rollernet.us> Paul G. Timmins wrote: > I have IPv6 though Verizon Business. If you need some contacts, let me > know. > > Note that they use GRE tunnels, and they're using some sort of broken > juniper gear with MTU issues. > They can do native dual stack now. I don't remember where I've shared this before, but here's my sad IPv6 story, start at the bottom: http://www.rollernet.us/wordpress/category/ipv6/ My opinion is that until turning up complete IPv6 connectivity is as easy as IPv4 that we won't see IPv6 take off. Unless you're lucky to have all clued providers, IPv6 is a massive time sink to get basic access. ~Seth From cengel at sponsordirect.com Wed Dec 9 16:48:49 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Wed, 9 Dec 2009 16:48:49 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> References: , , <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> Message-ID: Well, If the time estimates I've seen put forward here are accurate....and I see no reason to assume they wouldn't be.... then it'll be 2-3 years minimum before we see anyone out there that can ONLY do IPv6. In that time frame I'd be looking for the same sort of solution for public facing servers in the DMZ as I would for the rest of my network....namely some sort of v4 to v6 gateway service that would act as a proxy for my 4 machines and allow them to communicate with IPv6 hosts. I don't imagine it would be particulary difficult to grab a small IPv6 allocation if I needed it for that purpose... so no rush there..... and the longer I wait, the more choices I'm likely to have for v4 to v6 solutions....and the less costly they will be. Frankly at this point I don't even know if my ISP's are offering support for v6 services in my area. Chris ________________________________________ From: John Curran [jcurran at arin.net] Sent: Wednesday, December 09, 2009 3:39 PM To: Chris Engel Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] The non-deployment of IPv6 On Dec 9, 2009, at 11:37 AM, Chris Engel wrote: > John, > > Both. Public facing servers in the Enterprise are generaly NAT'd behind a firewall and running on Private IP space in a DMZ anyways (that's our setup and it's pretty typical of what I've seen). So even if we were to scale up to the point where we needed more external IP space and v6 was all that was available.... the only thing we would need to do....and would likely make sense to do would be to find a perimeter device that could handle v6 to v4 NATing to support those extra external v6 IP's on it's public interface (and that's assuming I need to scale beyond my current space in the first place). In other words, why would I want to try to re-invent the wheel when I don't need to, it net's me no functional advantage for my purposes and comes at considerable cost ?? I agree that you don't want to reinvent the wheel. My question is whether you'd consider getting that IPv6 address configured for your public mail and email servers sooner rather than later. The principle reason is that others could easily need that IPv6 access to your public servers well before your own internal community realizes it. /John John Curran President and CEO ARIN From cengel at sponsordirect.com Wed Dec 9 17:19:25 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Wed, 9 Dec 2009 17:19:25 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B200DEC.60200@ipinc.net> References: , <4B200DEC.60200@ipinc.net> Message-ID: Ted, If we are talking about switching our network infrastructure to native IPv6, even just the cost of figuring out the cost is not insignificant. Off the top of my head, I would need to factor in: 1) Hardware, OS and Software compatability .... and we have stuff ranging anywhere from brand new in beta to more then 10 years old currently in service. 2) Procedural Changes ..... have to figure out what current operating procedures would be no longer functional under IPv6 and how much work it would take to update them. 3) Contractual & Compliance Issues.... have to figure if any of the changes to our standard operating procedures mandated by such a change would have contractual or compliance side effects...and how to go about mitigating them. This would probably involve some consultation with Legal... and thier time AIN'T cheap. 4) Training & Productivity.... have to figure out what sort of training staff that would be impacted by the change in procedures might need...and also maybe the effect on productivity as staff ramped up thier learning curves. 5) Implimentation.... the actual cost of obtaining and configuring the IPv6 network(s). Now for all that cost/effort.....what EXACTLY am I supposed to be gaining in terms of benefits out of IPv6? It's not hard to see why we aren't jumping at IPv6. I'm certain at some point I'll have to support some connectivity to it. I'm hoping that I can achieve that by simply layering on a service here or there over our existing infrastructure. In other words, augmenting rather then supplanting our existing infrastructure....and that would be the most cost effective way to go. Heck, considering the costs...for ALOT of Enterprises I could even see them saying...." you know what...it's cheaper to NOT be able to connect to the 5% of the internet that is IPv6 only for the next 5 years then it is worry about incurring this." I'm pretty sure be those won't be the only options, though .... I have a feeling that there will be ALOT of v4 to v6 & v6 to v4 gateway service type solutions around in a few years time....as the demand for that is simply going to be too profitable to ignore. Chris Engel ________________________________________ From: Ted Mittelstaedt [tedm at ipinc.net] Sent: Wednesday, December 09, 2009 3:51 PM To: Chris Engel Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] The non-deployment of IPv6 Chris Engel wrote: > Well, speaking for myself and the Enterprise I manage..... I see > absolutely no reason to do IPv6 at the present time. There is no > benefit to it and a fairly decent cost. Chris, It's pretty common for people on this list to throw a lot of generalizations around, and cost is a favorite. Understand that I'm not picking on you here since a lot of other orgs are saying the same thing, but for the sake of example would you be willing to list the specifics of what you found would be costly for your org to support it? Typically what stops orgs from deploying is specific problems, not general ones, and unless we talk specifics the discussion turns into more of a philosophical discussion about what's right, and nothing gets solved. With my org our main cost was labor, that is yours truly labor hours. All the equipment we use supports it, the labor part was in creating and testing configuration changes, and I did that in between doing my real work. (you might argue that IS my real work, also, heh heh) And I still have work to do, our DNS servers are overdue for software upgrades that I keep meaning to set aside time for, but have not yet done. Ted From bill at herrin.us Wed Dec 9 17:48:10 2009 From: bill at herrin.us (William Herrin) Date: Wed, 9 Dec 2009 17:48:10 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: <4B200DEC.60200@ipinc.net> Message-ID: <3c3e3fca0912091448j68b8126dp356f6ccb9a40c7d2@mail.gmail.com> On Wed, Dec 9, 2009 at 5:19 PM, Chris Engel wrote: > 1) Hardware, OS and Software compatability .... and we have stuff ranging anywhere from brand new in beta to more then 10 years old currently in service. > > 2) Procedural Changes ..... have to figure out what current operating procedures would be no longer functional under IPv6 and how much work it would take to update them. > > 3) Contractual & Compliance Issues.... have to figure if any of the changes to our standard operating procedures mandated by such a change would have contractual or compliance side effects...and how to go about mitigating them. This would probably involve some consultation with Legal... and thier time AIN'T cheap. > > 4) Training & Productivity.... have to figure out what sort of training staff that would be impacted by the change in procedures might need...and also maybe the effect on productivity as staff ramped up thier learning curves. > > 5) Implimentation.... the actual cost of obtaining and configuring the IPv6 network(s). Chris, Unfortunately, you also have to factor in performance impact costs. Applications will attempt to connect with IPv6 first if it's believed to be available. They'll fall back to IPv4 addresses the same way they fall back to a second or third IPv4 address now: after a connect time out that is application-dependent but defaults to two or three minutes. This happens to your PCs as soon as they acquire an IPv6 address and it happens to remote clients contacting your servers as soon as you publish a AAAA DNS record. Unless you find that that the IPv6 network and your connection to it is as reliable or more reliable than your IPv4 access from day #1, that has an impact on your system performance which you will have to evaluate. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jcurran at arin.net Wed Dec 9 18:43:07 2009 From: jcurran at arin.net (John Curran) Date: Wed, 9 Dec 2009 18:43:07 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> Message-ID: <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> On Dec 9, 2009, at 4:48 PM, Chris Engel wrote: > > Well, > > If the time estimates I've seen put forward here are accurate....and I see no reason to assume they wouldn't be.... then it'll be 2-3 years minimum before we see anyone out there that can ONLY do IPv6. I agree that looks like a lot of time, but there's quite a few assumptions in such an estimate and it could move up very quickly. Additionally, there will be an increasing number of clients which will attempt to connect via IPv6 *first*, so you actually are impacting your performance if you don't do IPv6 soon. > In that time frame I'd be looking for the same sort of solution for public facing servers in the DMZ as I would for the rest of my network....namely some sort of v4 to v6 gateway service that would act as a proxy for my 4 machines and allow them to communicate with IPv6 hosts. Does your present firewall device support IPv6 NAT today? In discussion this situation with other organizations, I'm generally finding that routers, firewalls, and load-balancers aren't what are not what breaks, but instead their tools such as help-desk system and configuration generators which simply don't know IPv6. Finding these issues is a great reason to experiment with at least one public facing IPv6 server sooner rather than later. /John From farmer at umn.edu Wed Dec 9 19:01:03 2009 From: farmer at umn.edu (David Farmer) Date: Wed, 09 Dec 2009 18:01:03 -0600 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out - Last Call In-Reply-To: <4B15080C.28232.1D4A9DEF@farmer.umn.edu> References: <4B0C074D.9020608@arin.net> <4B15080C.28232.1D4A9DEF@farmer.umn.edu> Message-ID: <4B203A3F.8090402@umn.edu> I want to remind everyone that tomorrow is the formal end of the Last Call period for 2009-8. So far, I count 13 total posts by 8 different people. By my interpretation of the posts, 6 people said they support the Draft Policy, none opposed it, and Owen and I as AC members haven't publicly stated a position. Of those, 7 posts by 4 people have made comments regarding possible clarifications to the text. Overall, I only see lukewarm support for changing the text. Without stronger support for changing the text, I'm reluctant to recommend to the rest of the AC that we change the text at this point in the process. Therefore, if you oppose this Draft Policy or believe it is important to change the text please speak up, ASAP. Thank you for your participation. David Farmer wrote: > Now that the Thanksgiving holiday has passed here in the US, > I would like to remind everyone that there is an important pice > of policy business on the table for PPML. > > Draft Policy 2009-8: Equitable IPv4 Run-Out is in Last Call. > > Three of the last four Draft Policies had little or no Last Call > comments; two hand no comments, one had one comment, > and the forth policy had 10 comments from 5 individuals. > > As one of the AC shepards for this proposal I would appreciate > any Last Call comments you may have on this Draft Policy, > even if it is simply that you support the policy as written. > > The text of this Draft Policy changed significantly from the > version discussed on the floor at Dearborn, so please take a > moment and read it carefully including the Rationale. > > Thank you, > > And finally in the spirit of the upcoming holidays; > > Best wishes to you and yours; > Peace on Earth, and; > THE UNIVERSAL ADOPTION OF IPv6. :) > > > On 24 Nov 2009 Member Services wrote: > >> The ARIN Advisory Council (AC) met on 19 November and decided to >> send a revised version of the following draft policy to last call: >> >> Draft Policy 2009-8: Equitable IPv4 Run-Out >> >> Feedback is encouraged during this last call period. All comments should >> be provided to the Public Policy Mailing List. This last call will >> expire on 10 December 2009. After last call the AC will conduct their >> last call review. >> >> The draft policy text is below and available at: >> https://www.arin.net/policy/proposals/ >> >> The ARIN Policy Development Process is available at: >> https://www.arin.net/policy/pdp.html >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Draft Policy 2009-8 >> Equitable IPv4 Run-Out >> >> Version/Date: 24 November 2009 >> >> Policy statement: >> >> Rename NRPM 4.2.4.3; >> >> 4.2.4.3 Subscriber Members Less Than One Year >> >> Replace NRPM 4.2.4.4 with; >> >> 4.2.4.4 Subscriber Members After One Year >> >> After an organization has been a subscriber member of ARIN for one year, >> they may choose to request up to a 12 month supply of IP addresses. >> >> When ARIN receives its last /8, by IANA implementing section 10.4.2.2, >> the length of supply that an organization may request will be reduced. >> An organization may choose to request up to a 3 month supply of IP >> addresses. >> >> This reduction does not apply to resources received via section 8.3. An >> organization receiving a transfer under section 8.3 may continue to >> request up to a 12 month supply of IP addresses. >> >> Rationale: >> >> This policy is intended to ensure an equitable distribution of IPv4 >> resources as run-out of the ARIN free pool occurs. This is achieved by >> changing section 4.2.4.4 of the NRPM to reduce the length of supply of >> IPv4 resources that may be requested when the IANA free pool runs-out. >> Equity is accomplished by reducing the window that an advantage or >> disadvantage can exist between competitors, that will be created when >> one competitor receives a final allocation just before run-out and >> another competitor does not. >> >> Further this policy ensures equity between incumbent resource holders >> and new entrants by providing the same length of supply for each as the >> ARIN free pool runs out. This eliminates a potential bias toward >> incumbent resource holders that is created as a result of ARIN free pool >> run-out interacting with resource allocation slow start for new entrants >> in current policy. >> >> This policy is similar to ideas in RIPE policy proposal 2009-03 >> (http://www.ripe.net/ripe/policies/proposals/2009-03.html), and has been >> adapted by discussion and for use within the ARIN region. >> >> This policy is intended to be independent of other policies or proposals >> to reserve address space for IPv6 transition or other purposes. It is >> not intended to limit Transfers to Specified Recipients per section 8.3 >> of the NRPM. >> >> This draft contains the elements that there seems to have been the >> largest consensus for on the floor of ARIN XXIV Public Policy Meeting in >> Dearborn, Michigan. Further, there was a strong preference that no >> changes be triggered until IANA free pool run-out. >> >> Timetable for implementation: Immediate -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From sfoster at zillow.com Wed Dec 9 19:25:09 2009 From: sfoster at zillow.com (Shane Foster) Date: Wed, 9 Dec 2009 19:25:09 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> References: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> Message-ID: I'm with a small content provider. At the moment, I don't see us moving any of our sites to IPv6 until multihoming is realistic option. The costs aren't an issue, the code changes and config updates are relatively minor, but lack of multihoming options for sites that only need an IPv4 /24 to advertise is a blocker. I see that there are some new (this year) Shim6 RFCs from the IETF. Seems unlikely that there will be any real solutions until that effort is finally dropped. Thanks, Shane -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Wednesday, December 09, 2009 3:43 PM To: Chris Engel Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] The non-deployment of IPv6 On Dec 9, 2009, at 4:48 PM, Chris Engel wrote: > > Well, > > If the time estimates I've seen put forward here are accurate....and I see no reason to assume they wouldn't be.... then it'll be 2-3 years minimum before we see anyone out there that can ONLY do IPv6. I agree that looks like a lot of time, but there's quite a few assumptions in such an estimate and it could move up very quickly. Additionally, there will be an increasing number of clients which will attempt to connect via IPv6 *first*, so you actually are impacting your performance if you don't do IPv6 soon. > In that time frame I'd be looking for the same sort of solution for public facing servers in the DMZ as I would for the rest of my network....namely some sort of v4 to v6 gateway service that would act as a proxy for my 4 machines and allow them to communicate with IPv6 hosts. Does your present firewall device support IPv6 NAT today? In discussion this situation with other organizations, I'm generally finding that routers, firewalls, and load-balancers aren't what are not what breaks, but instead their tools such as help-desk system and configuration generators which simply don't know IPv6. Finding these issues is a great reason to experiment with at least one public facing IPv6 server sooner rather than later. /John _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From Vaughn at SwiftSystems.com Wed Dec 9 20:02:12 2009 From: Vaughn at SwiftSystems.com (VAUGHN THURMAN - SWIFT SYSTEMS INC) Date: Wed, 9 Dec 2009 20:02:12 -0500 Subject: [arin-ppml] The non-deployment of IPv6 - The Economic Factor In-Reply-To: <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> References: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> Message-ID: <00ea01ca7934$68582d70$39088850$@com> John, I must agree with your assertion that we have risks not yet considered in the systems space. I wear dual hats and so besides running a regional ISP/Data Center, I spun off a software company a few years back to focus on a task management and workflow application that we had originally built for in-house use. We have a particularly savvy and very high-end customer on that task management software (http://www.JobTraQ.com if anyone cares). They seem NOT to be feeling the pinch lately at all. And thus, because unlike much of the world they have extensive free capital and human resources to play with right now, they are already running IPV6 dual stack in their test and staging environments, in some of their training labs, and on a careful few of the developer and business analyst's stations from where same access their test and staging system. They can turn IPv6 off if they find anything wrong and need to press on, but it has effectively helped them alert their vendors (like us) ahead of some non-desirable moment of crisis. We only had two minor issues, but we were completely blindsided by them both. One issue was that we couldn't handle the longer string in a place where we audited and then stored successful (and unsuccessful) logins along with remote users IP address. The other issue was in a security report for displaying the same data back to the system administrator. The things is, it is pretty hard to log in if you are trying to save a big old IPv6 address into a field with space for only 15 characters as part of that process (since that is where the web server goes cross-eyed and begins looking for the corner in a round room). Anyway, as a result of this, we have decided to deploy IPv6 on a limited scale in the same dual stack modus so that we don't have to experience that red faced feeling again. With that said, I would like to briefly pontificate on a related topic and set it up by first quoting myself: "... And thus, because unlike much of the world they have extensive free capital and human resources to play with right now,,..." This (*The Economic Factor*) should not be underestimated as one of the more significant root causes of IPv6's purported "non-deployment" as discussed recently on this list. Were this 1999, with dot com crazed investors drooling out large blobs of cash on demand, then Cisco (and I guess Juniper too) would have already had six record quarters as every network tech unpacked his new toys and enabled IPv6 just so he could say that he had on his resume, etc. Same applies at the "of course we do" well funded backbone providers. See here it is: One thing that will almost always vault the lowly ROI-calculating-tactician into the irrefutable and overarching command position above the normally elevated strategist is this... a limited budget. "Sounds good, but not today. We don't have the money." Conversation over. I am so NOT a big government person, that this is almost astounding for me to say, but this may be one of those situations where government's aid is actually needed. Unless some entity is able to push down the cost of deployment by mandating it upon themselves (fear shudders through me britches as I ponder the risks of saying this, and then finding they mandate it for me - must be a hypocrite). In this economy, and without a large scale reference case complete with interoperability studies, etc. there is a daunting chasm that the capitalists and entrepreneurs are just not ready to cross yet in order to get to IPv6. Their capes are still tattered from the current and hopefully waning battles against the dark forces of commoditization, economic slumber, and comfort in the current state of "so who is out of gas [IPv4}? My car [ISP] is still moving". Make sense? I think we have an economic problem here. How many software vendors are going to get blindsided because they don't have a customer like we did to test ahead of us? How many ISP's will slide under the edge of the universe when the IPv4 run out crushes them for resources they don't have? Will they turn to the banks to help them capitalize the switchover costs? Where is the ROI? Are we doing this so that we can access new revenues, (which is bankable) or isn't this really just a tad more like the Y2K thing? Spend, spend, spend, stop, do we survive? Whew, then now we can go back to work right? I don't have an easy answer to all of this, but thought it should be raised. We may as a group need to start asking for some help, or figuring out how to at least get a working group up and running that leads vendors rushing in hoping to be the first to get the stamp of approval (and thus the ROI of being first to announce "ready for IPv6 Interop", or "certified by X", etc). Without a powerful economic incentive (sponsor, reference case, marketing advantage, etc.) being provided in advance we are assuring the likelihood of a painful transition - not at the time of our own choosing. I don't mean to suggest that vendors can't do IPv6 today. I am suggesting that they can't do it well yet, and that as a result nobody wants to be first if there is nobody really waiting to reward them for success. I also kind of agree with the "why didn't we just add some octets to IPv4" statement, because the greatest capital spend is not on gear, it is on the daunting task of becoming organizationally competent at something so very different than the last rev. At the end, we are all bright and capable, it's really a resource question. Can we afford to do this? Critical mass has to be generated and all of the incentives will arrive, but the core question is how can we create these incentives BEFORE the run-out, and in this economy? Best, ~Vaughn -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Wednesday, December 09, 2009 6:43 PM To: Chris Engel Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] The non-deployment of IPv6 On Dec 9, 2009, at 4:48 PM, Chris Engel wrote: > > Well, > > If the time estimates I've seen put forward here are accurate....and I see no reason to assume they wouldn't be.... then it'll be 2-3 years minimum before we see anyone out there that can ONLY do IPv6. I agree that looks like a lot of time, but there's quite a few assumptions in such an estimate and it could move up very quickly. Additionally, there will be an increasing number of clients which will attempt to connect via IPv6 *first*, so you actually are impacting your performance if you don't do IPv6 soon. > In that time frame I'd be looking for the same sort of solution for public facing servers in the DMZ as I would for the rest of my network....namely some sort of v4 to v6 gateway service that would act as a proxy for my 4 machines and allow them to communicate with IPv6 hosts. Does your present firewall device support IPv6 NAT today? In discussion this situation with other organizations, I'm generally finding that routers, firewalls, and load-balancers aren't what are not what breaks, but instead their tools such as help-desk system and configuration generators which simply don't know IPv6. Finding these issues is a great reason to experiment with at least one public facing IPv6 server sooner rather than later. /John _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From scottleibrand at gmail.com Wed Dec 9 20:16:43 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 9 Dec 2009 19:16:43 -0600 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> Message-ID: <825E90F5-F61B-4471-80B4-E8A9BDFB35DF@gmail.com> Shane, What are your IPv6 multihoming needs? Would it be sufficient to be able to announce one or more provider-allocated /48s in BGP? If so, that should work, today, in the same way as announcing an IPv4 PA /24. Scott On Dec 9, 2009, at 6:25 PM, "Shane Foster" wrote: > I'm with a small content provider. > > At the moment, I don't see us moving any of our sites to IPv6 until > multihoming is realistic option. > The costs aren't an issue, the code changes and config updates are > relatively minor, but lack of multihoming options for sites that only > need an IPv4 /24 to advertise is a blocker. > > I see that there are some new (this year) Shim6 RFCs from the IETF. > Seems unlikely that there will be any real solutions until that effort > is finally dropped. > > Thanks, > Shane > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On > Behalf Of John Curran > Sent: Wednesday, December 09, 2009 3:43 PM > To: Chris Engel > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] The non-deployment of IPv6 > > On Dec 9, 2009, at 4:48 PM, Chris Engel wrote: >> >> Well, >> >> If the time estimates I've seen put forward here are >> accurate....and I > see no reason to assume they wouldn't be.... then it'll be 2-3 years > minimum before we see anyone out there that can ONLY do IPv6. > > I agree that looks like a lot of time, but there's quite a few > assumptions in such an estimate and it could move up very quickly. > Additionally, there will be an increasing number of clients which will > attempt to connect via IPv6 *first*, so you actually are impacting > your > performance if you don't do IPv6 soon. > >> In that time frame I'd be looking for the same sort of solution for > public facing servers in the DMZ as I would for the rest of my > network....namely some sort of v4 to v6 gateway service that would act > as a proxy for my 4 machines and allow them to communicate with IPv6 > hosts. > > Does your present firewall device support IPv6 NAT today? In > discussion this situation with other organizations, I'm generally > finding that routers, firewalls, and load-balancers aren't what are > not > what breaks, but instead their tools such as help-desk system and > configuration generators which simply don't know IPv6. Finding these > issues is a great reason to experiment with at least one public facing > IPv6 server sooner rather than later. > > /John > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mysidia at gmail.com Wed Dec 9 20:37:43 2009 From: mysidia at gmail.com (James Hess) Date: Wed, 9 Dec 2009 19:37:43 -0600 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: References: Message-ID: <6eb799ab0912091737t1ce5d789jbe5e85bd1728abea@mail.gmail.com> On Mon, Dec 7, 2009 at 11:14 AM, Chris Engel wrote: > Publication of the address and multiple contacts provides a last resort if all other contact info is outdated and useless; it provides enough information to write a letter. Mailing address might also be used for less-urgent requests, or notices, such as ones of a legal nature. It also allows you to follow-up an e-mail conversation with a verifiable written record to all contacts (via certified mail), which might be required in some circumstances. > In the security world, the principle of "least privilege" is a well established best practice. That is, granting the minimum level of access/functionality/data in order to achieve a given task. I do not believe it is an unreasonable position to hold forth that ARIN should adhere to that best practice in regards to requirements for WHOIS. Least privilege is not always the right answer, sometimes trying to follow least privilege can result in an even less secure practice, than implementing the practices people would expect. It's not reasonable that ARIN should restrict public information simply to pursue idealogical goals such as "least privilege"; ARIN's best practice and core principle is good stewardship -- not least privilege. "Least privilege" not a well-established best practice; it's a general guiding principle. Least privilege is not either definable nor possible to enforce, as such it's not a practice that ANYONE actually implements. Least privilege is impossible because we do not know a-priori what all legitimate uses of the information are, and we cannot know in advance the valid times when it will be called up. Least privilege would insist that attempting to use WHOIS on an IP would always return access denied, until the very moment you _needed_ the information at that very moment, for a legitimate purpose. If WHOIS followed least privilege, you would have to call ARIN, prove you have a legitimate need to lookup that record, by sending them logs or proof of abuse, or other documents proving the need. After they thoroughly verified your need, they would then tell you which WHOIS fields you can request to see, and then, upon the request (with paperwork properly filed and approved, fees paid, etc), you would have 1 hour to perform a lookup that record one time from an IP address you specified. If it only takes you 5 minutes to lookup the record, then Least Privilege was violated, since you were given 45 minutes you didn't need. In addition, you could only request the item of contact information you are using. If you plan to e-mail the contact, you don't get the phone number. If you later need the phone number, you will have to prove the e-mail contact didn't work, and start the request all over again (more fees, wait 24 hours, etc) Actually, wait, no, that also violates least privilege: You don't see an e-mail address or phone number, _ever_. ARIN provides you a web form for sending an e-mail to a contact whose name you will not be told. Any attempt to reveal your own name or address in the e-mail will be censored, by blanking out that portion of the email. If you need to call them, ARIN proxies your call to the contact, so you never see the contact's phone number. An operator listens in and bleeps out any attempt by either side to reveal contact information (which could compromise their own privacy). Also, since you don't need the privilege of hearing their real voice, ARIN uses technology to disguise both callers' voices from each other, and filters any background noise that might reveal details about their location. If you need to send them a physical mail, you address it to ARIN c/o the recipient's POC handle, and ARIN forwards the text of the message, after removing return address, and analysing its contents to make sure you didn't accidentally reveal your identity. If you need to go visit them physically, you pay ARIN to send a van, in which you are escorted blindfolded, restrained to the organization's contact address by armed guards. After you are done talking with the contact (both of you are blindfolded for the conversation), you are escorted back to your place of business. These methods respect least privilege and are "best practice" in that regard. > So let me put forth the question.... What is the legitimate NEED for publicly accessible WHOIS lookup that can be accessed anonymously and that has no gate-keeping functionality inherent to it? > The WHOIS specification has no gate-keeping functionality inherent to it. But I expect ARIN could implement gate-keeping functionality on its WHOIS servers, for example, by rate limiting the amount of different records that can be viewed by a single IP address within a certain amount of time to a "reasonable" number -- -J From michel at arneill-py.sacramento.ca.us Thu Dec 10 04:08:20 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 10 Dec 2009 01:08:20 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> References: , <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> Message-ID: <4C1746A1D20C3148B6434776DFFF06C505578C@newserver.arneill-py.local> > Chris Engel wrote: > [snip] What Chris wrote recently is representative of the current corporate IT thinking, IMHO. Put bluntly, here's what it is: if someone tries to reach me over IPv6, fails, and their IPv6 -> IPv4 "gateway" also fails, they won't be in business long enough to interest me in the first place. > John Curran wrote: > The principle reason is that others could easily need that IPv6 access to > your public servers well before your own internal community realizes it. Hmmm I don't see how this could happen any time soon. Could you post a real-life scenario? Type of business, and more important who/where would need access and would not even have the basic cheesy double-NAT IPv4 or IPv6 transition mechanism good enough to hit the public email servers? Also, given the predicted small amount of IPv6 email traffic compared to IPv4, I would consider hosting an email relay somewhere in an IPv6-enabled colo rather than an infrastructure update. Michel. From craig.finseth at state.mn.us Thu Dec 10 08:05:02 2009 From: craig.finseth at state.mn.us (Craig Finseth) Date: Thu, 10 Dec 2009 07:05:02 -0600 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: (message from Chris Engel on Wed, 9 Dec 2009 17:19:25 -0500) References: , <4B200DEC.60200@ipinc.net> Message-ID: <200912101305.nBAD52qf024441@inana.itg.state.mn.us> If we are talking about switching our network infrastructure to native IPv6, even just the cost of figuring out the cost is not insignificant. Off the top of my head, I would need to factor in: ... Now for all that cost/effort.....what EXACTLY am I supposed to be gaining in terms of benefits out of IPv6? You get to stay in the game. Without such investment, you're out. Craig From farmer at umn.edu Thu Dec 10 08:05:19 2009 From: farmer at umn.edu (David Farmer) Date: Thu, 10 Dec 2009 07:05:19 -0600 Subject: [arin-ppml] The non-deployment of IPv6 - The Economic Factor In-Reply-To: <00ea01ca7934$68582d70$39088850$@com> References: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> <00ea01ca7934$68582d70$39088850$@com> Message-ID: <4B20F20F.7080300@umn.edu> VAUGHN THURMAN - SWIFT SYSTEMS INC wrote: > I am so NOT a big government person, that this is almost astounding for me > to say, but this may be one of those situations where government's aid is > actually needed. Unless some entity is able to push down the cost of > deployment by mandating it upon themselves (fear shudders through me > britches as I ponder the risks of saying this, and then finding they mandate > it for me - must be a hypocrite). Funny you should say this; This morning, the US Federal Government released its final rule for Federal Acquisition Regulation (FAR) relating to IPv6. It isn't a push down to everyone, but it is a push down to all the vendors of the Federal Government. I haven't read the whole thing yet, I can only digest so much government-speak in a singe dose. I'm going to definitely have to read this in several different sittings to prevent indigestion, lapsing into unconsciousness, or permanent brain damage. :-) Read at you own risk. :-() http://edocket.access.gpo.gov/2009/E9-28931.htm -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From Lee at dilkie.com Thu Dec 10 08:25:51 2009 From: Lee at dilkie.com (Lee Dilkie) Date: Thu, 10 Dec 2009 08:25:51 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> Message-ID: <4B20F6DF.9000300@dilkie.com> Don't you essentially *have* multi-homing if you are dual-stack? If you are multi-homed on IPv4, you don't really need it on IPv6, do you? If an IPv6 route is unavailable, the connection will be established on IPv4. Multi-homing IPv6 will matter once IPv6-only networks get rolled out and I don't see that happening for some time yet. -lee Shane Foster wrote: > I'm with a small content provider. > > At the moment, I don't see us moving any of our sites to IPv6 until > multihoming is realistic option. > The costs aren't an issue, the code changes and config updates are > relatively minor, but lack of multihoming options for sites that only > need an IPv4 /24 to advertise is a blocker. > > I see that there are some new (this year) Shim6 RFCs from the IETF. > Seems unlikely that there will be any real solutions until that effort > is finally dropped. > > Thanks, > Shane > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of John Curran > Sent: Wednesday, December 09, 2009 3:43 PM > To: Chris Engel > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] The non-deployment of IPv6 > > On Dec 9, 2009, at 4:48 PM, Chris Engel wrote: > >> Well, >> >> If the time estimates I've seen put forward here are accurate....and I >> > see no reason to assume they wouldn't be.... then it'll be 2-3 years > minimum before we see anyone out there that can ONLY do IPv6. > > I agree that looks like a lot of time, but there's quite a few > assumptions in such an estimate and it could move up very quickly. > Additionally, there will be an increasing number of clients which will > attempt to connect via IPv6 *first*, so you actually are impacting your > performance if you don't do IPv6 soon. > > >> In that time frame I'd be looking for the same sort of solution for >> > public facing servers in the DMZ as I would for the rest of my > network....namely some sort of v4 to v6 gateway service that would act > as a proxy for my 4 machines and allow them to communicate with IPv6 > hosts. > > Does your present firewall device support IPv6 NAT today? In > discussion this situation with other organizations, I'm generally > finding that routers, firewalls, and load-balancers aren't what are not > what breaks, but instead their tools such as help-desk system and > configuration generators which simply don't know IPv6. Finding these > issues is a great reason to experiment with at least one public facing > IPv6 server sooner rather than later. > > /John > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From alh-ietf at tndh.net Thu Dec 10 18:29:27 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 10 Dec 2009 15:29:27 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> Message-ID: <04b501ca79f0$9dafb350$d90f19f0$@net> Why do you say multi-homing is unrealistic? Do ARIN policies keep you from getting a PI /48? If so that needs to be fixed. If not, your complaint would appear to be an artificial justification for delaying. Tony > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Shane Foster > Sent: Wednesday, December 09, 2009 4:25 PM > To: John Curran; Chris Engel > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] The non-deployment of IPv6 > > I'm with a small content provider. > > At the moment, I don't see us moving any of our sites to IPv6 until > multihoming is realistic option. > The costs aren't an issue, the code changes and config updates are > relatively minor, but lack of multihoming options for sites that only > need an IPv4 /24 to advertise is a blocker. > > I see that there are some new (this year) Shim6 RFCs from the IETF. > Seems unlikely that there will be any real solutions until that effort > is finally dropped. > > Thanks, > Shane > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of John Curran > Sent: Wednesday, December 09, 2009 3:43 PM > To: Chris Engel > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] The non-deployment of IPv6 > > On Dec 9, 2009, at 4:48 PM, Chris Engel wrote: > > > > Well, > > > > If the time estimates I've seen put forward here are accurate....and > I > see no reason to assume they wouldn't be.... then it'll be 2-3 years > minimum before we see anyone out there that can ONLY do IPv6. > > I agree that looks like a lot of time, but there's quite a few > assumptions in such an estimate and it could move up very quickly. > Additionally, there will be an increasing number of clients which will > attempt to connect via IPv6 *first*, so you actually are impacting your > performance if you don't do IPv6 soon. > > > In that time frame I'd be looking for the same sort of solution for > public facing servers in the DMZ as I would for the rest of my > network....namely some sort of v4 to v6 gateway service that would act > as a proxy for my 4 machines and allow them to communicate with IPv6 > hosts. > > Does your present firewall device support IPv6 NAT today? In > discussion this situation with other organizations, I'm generally > finding that routers, firewalls, and load-balancers aren't what are not > what breaks, but instead their tools such as help-desk system and > configuration generators which simply don't know IPv6. Finding these > issues is a great reason to experiment with at least one public facing > IPv6 server sooner rather than later. > > /John > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From spiffnolee at yahoo.com Thu Dec 10 19:24:06 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Thu, 10 Dec 2009 16:24:06 -0800 (PST) Subject: [arin-ppml] The non-deployment of IPv6 Message-ID: <172481.38603.qm@web63302.mail.re1.yahoo.com> Keith Hare said: > 1. Finding firewall (or whatever vendors are calling it today) > equipment that supports IPv6 >From www.getipv6.info click "IPv6 Deployment and Migration Planning," then "Device Support." http://jitc.fhu.disa.mil/apl/ipv6.html#security http://www.ipv6-to-standard.org/index.php > 2. Finding an upstream that supports IPv6 >From www.getipv6.info click "IPv6 Deployment and Migration Planning," then "Providers Currently Selling IPv6 Transit." > The killer question is will we be able to find robust v4 to v6 > solutions when the time comes when we need to get traffic from > v6 only external users or sending traffic to v6 only sites. I am > assuming the answer to that question will be.... yes.....since when > the time comes there is going to be a huge demand for them. I'm very skeptical. Stateless NAT46/64 means a 1:1 mapping of addresses, which doesn't help after IPv4 is unavailable. Stateful NAT46 isn't even on the table at IETF yet. Doubtful we'll have a product in time. No equipment vendors say they'll have one-to- many address family translation by EOY 2011. > The point at which you need to do something about v6 is when you > are going to start getting external traffic (SMTP, HTTP, etc.) from > v6 only users... or when your own users are going to start to want > to access v6 only sites. As an enterprise network operator, do you support a VPN for remote employees? Once they can't get a global IPv4 address, if they change ISPs they'll either be behind IPv6 or large-scale NAT (i.e., NAT444). Will your VPN work? > lots of network hardware vendors that support IPv6, take a few > minutes and see if you can find where on their web sites and spec > sheets they document IPv6 support. I went to the websites of half a dozen large network equipment makers and searched for "IPv6." AdTran should be embarrassed, but otherwise, there are hits at all of them. You can complain about features that are late in coming in some edge platforms, but nearly everything will at least allow an IPv6 address now. Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at ibctech.ca Fri Dec 11 09:33:43 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 11 Dec 2009 09:33:43 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B20F6DF.9000300@dilkie.com> References: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> <4B20F6DF.9000300@dilkie.com> Message-ID: <4B225847.3030702@ibctech.ca> Lee Dilkie wrote: > Don't you essentially *have* multi-homing if you are dual-stack? No. Multi-homing != dual stack. Dual stack can be as simple as having a link local v6 address on your machine without even being able to see any other v6 devices on the network. > If you > are multi-homed on IPv4, you don't really need it on IPv6, do you? Yes, you do (imho). The two are mutually exclusive, even if all of your IPv6 transits are over v4 tunnels, redundant paths will better protect you from having your v6 prefixes fall off the earth. > If an > IPv6 route is unavailable, the connection will be established on IPv4. ...and the time-out value in some applications (such as my preferred SSH client for Windows) to fall-over to v4 can become frustrating. For a content provider, the time for a browser to switch to v4 when the providers internal v6 is unreachable could be potentially disasterous. > Multi-homing IPv6 will matter once IPv6-only networks get rolled out and > I don't see that happening for some time yet. I disagree completely. The same mentality that is applied to v4 resiliency should be applied all the same to v6. Not only that, it is extremely easy to v6 multi-home, as there are several very large ISPs who offer *free* peering/transit over tunnels that you can use in conjunction with your existing providers. [plug: he.net]. Steve From michael.dillon at bt.com Fri Dec 11 09:45:18 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 11 Dec 2009 14:45:18 -0000 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B225847.3030702@ibctech.ca> Message-ID: <28E139F46D45AF49A31950F88C497458047BBC85@E03MVZ2-UKDY.domain1.systemhost.net> > > Multi-homing IPv6 will matter once IPv6-only networks get > rolled out > > and I don't see that happening for some time yet. > > I disagree completely. The same mentality that is applied to > v4 resiliency should be applied all the same to v6. Not only > that, it is extremely easy to v6 multi-home, as there are > several very large ISPs who offer *free* peering/transit over > tunnels that you can use in conjunction with your existing > providers. [plug: he.net]. In addition, IPv6-only networks are already rolled out. The is one very well-known instance of an IPv6-only network run by Google who will provide peering access to certain Google apps only on IPv6. Yes, we are in the early days of IPv6 rollout, but it is already rolled out and carrying more traffic than the IPv4 Internet did in the late 1990s. Like any exponential growth curve, it looks very flat in the early stages, but within a couple of years we will reach an inflection point driven by IPv4 runout, and the growth curve will gain a lot more visibility. Note that it is not the actual IPv4 runout event that will drive up IPv6 usage, but the fact that all major ISPs are targeting that time period for ramping up the stuff that they are currently running in labs and in limited trials to gain experience with IPv6. People have been working at this for a couple of years now, knowing that sometime in 2011 they will have to support IPv6 for real. A nice exit strategy for a smaller ISP would be to develop their support for IPv6 early, including all the operational support systems and applications, databases, and training of 1st level support people. Chances are one or more of the largest ISPs will run into problems with some part of their IPv6 deployment, and the small ISP could sell the business to the larger one simply on the basis of "been there, done that, and we can help you get the T-shirt too". --Michael Dillon From Keith at jcc.com Fri Dec 11 09:53:17 2009 From: Keith at jcc.com (Keith W. Hare) Date: Fri, 11 Dec 2009 09:53:17 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <172481.38603.qm@web63302.mail.re1.yahoo.com> References: <172481.38603.qm@web63302.mail.re1.yahoo.com> Message-ID: Lee Howard said >Keith Hare said: >> 1. Finding firewall (or whatever vendors are calling it today) >> equipment that supports IPv6 > >From www.getipv6.info click "IPv6 Deployment and Migration Planning," >then "Device Support." >http://jitc.fhu.disa.mil/apl/ipv6.html#security >http://www.ipv6-to-standard.org/index.php Yep, did that. Then I went to the vendor web sites. It's been a while since I looked at the Fortinet web site, but last I looked, I couldn't find ANYTHING on the Fortinet web site that said IPv6. And, the current version of FortiOS is V4 or so. Does V4 have all of the features in the V3.0 that was certified? Probably, but how do I figure that out? I looked at the Juniper Networks web site earlier this week. Based on a suggestion from Owen, I looked at a Juniper SRX box that would be about what I need. The info for the SRX box doesn't anything about IPv6 support. However it does say that the SRX box runs JUNOS, and I finally found another web page that describes the IPv6 standards supported by JUNOS. So that implies that the SRX boxes support IPv6, I guess. That's my point (beef, soapbox, etc.). The vendors that support IPv6 don't think IPv6 is important enough to mention it in the spec sheets for each piece of equipment where it would be easy to find. The information, if it is available, is hidden off in some dusty corner. >> 2. Finding an upstream that supports IPv6 > >From www.getipv6.info click "IPv6 Deployment and Migration Planning," >then "Providers Currently Selling IPv6 Transit." None of the Providers on this list are anywhere close to me, so I would either need to get some sort of long dedicated link or work with an IPv6 tunnel broker. That answer is easy -- I know where the web page is to set up an account with a pretty good, pretty cheap tunnel broker. My real point is that from discussions on this list, I know that one of my local vendors is working on IPv6 somewhere. However, the local sales rep doesn't admit to knowing anything about it. Most of the rest of Lee's response was to comments from some other message. Keith > >> The killer question is will we be able to find robust v4 to v6 >> solutions when the time comes when we need to get traffic from >> v6 only external users or sending traffic to v6 only sites. I am >> assuming the answer to that question will be.... yes.....since when >> the time comes there is going to be a huge demand for them. > >I'm very skeptical. Stateless NAT46/64 means a 1:1 mapping of >addresses, which doesn't help after IPv4 is unavailable. Stateful >NAT46 isn't even on the table at IETF yet. Doubtful we'll have a >product in time. No equipment vendors say they'll have one-to- >many address family translation by EOY 2011. > >> The point at which you need to do something about v6 is when you >> are going to start getting external traffic (SMTP, HTTP, etc.) from >> v6 only users... or when your own users are going to start to want >> to access v6 only sites. > >As an enterprise network operator, do you support a VPN for >remote employees? Once they can't get a global IPv4 address, if >they change ISPs they'll either be behind IPv6 or large-scale NAT >(i.e., NAT444). Will your VPN work? > >> lots of network hardware vendors that support IPv6, take a few >> minutes and see if you can find where on their web sites and spec >> sheets they document IPv6 support. > >I went to the websites of half a dozen large network equipment >makers and searched for "IPv6." AdTran should be embarrassed, >but otherwise, there are hits at all of them. You can complain >about features that are late in coming in some edge platforms, but >nearly everything will at least allow an IPv6 address now. > >Lee From steve at ibctech.ca Fri Dec 11 10:04:42 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 11 Dec 2009 10:04:42 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <28E139F46D45AF49A31950F88C497458047BBC85@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458047BBC85@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B225F8A.1060204@ibctech.ca> michael.dillon at bt.com wrote: > A nice exit strategy for a smaller ISP would be to develop > their support for IPv6 early, including all the operational > support systems and applications, databases, and training > of 1st level support people. Chances are one or more of the > largest ISPs will run into problems with some part of their > IPv6 deployment, and the small ISP could sell the business > to the larger one simply on the basis of "been there, done that, > and we can help you get the T-shirt too". That's the exit strategy that I've enveloped for the small ISP I work for, and the exact personal 'contracting' philosophy I came up with that led me to jump on the v6 bandwagon in 2007. Steve From Lee at Dilkie.com Fri Dec 11 10:22:17 2009 From: Lee at Dilkie.com (Lee Dilkie) Date: Fri, 11 Dec 2009 10:22:17 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B225847.3030702@ibctech.ca> References: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> <4B20F6DF.9000300@dilkie.com> <4B225847.3030702@ibctech.ca> Message-ID: <4B2263A9.2070801@Dilkie.com> Steve Bertrand wrote: > Lee Dilkie wrote: > >> Don't you essentially *have* multi-homing if you are dual-stack? >> > > No. Multi-homing != dual stack. Dual stack can be as simple as having a > link local v6 address on your machine without even being able to see any > other v6 devices on the network. > Baloney. A link local address isn't routeable and if that's all that you have bound to an interface, then you don't have IPv6 nor will the stack attempt to make any connections over IPv6. "Multi-homing", the term, refers to multiple methods to access the same network resource. By that definition, dual-stack suffices. Whether it'll survive a physical outage is another matter. > >> If you >> are multi-homed on IPv4, you don't really need it on IPv6, do you? >> > > Yes, you do (imho). The two are mutually exclusive, even if all of your > IPv6 transits are over v4 tunnels, redundant paths will better protect > you from having your v6 prefixes fall off the earth. > And if they do? So what? Your IPv4 connection will be used with no loss of service. Isn't that what you are looking for? > >> If an >> IPv6 route is unavailable, the connection will be established on IPv4. >> > > ...and the time-out value in some applications (such as my preferred SSH > client for Windows) to fall-over to v4 can become frustrating. For a > content provider, the time for a browser to switch to v4 when the > providers internal v6 is unreachable could be potentially disasterous. > I don't disagree that the timeouts can be annoying when there's a problem in the IPv6 route. So then, start by enabling it on smtp? Machines are patient and don't mind the 30 second timeout and will happily retry on IPv4. >> Multi-homing IPv6 will matter once IPv6-only networks get rolled out and >> I don't see that happening for some time yet. >> > > I disagree completely. The same mentality that is applied to v4 > resiliency should be applied all the same to v6. Not only that, it is > extremely easy to v6 multi-home, as there are several very large ISPs > who offer *free* peering/transit over tunnels that you can use in > conjunction with your existing providers. [plug: he.net]. > Got it, you don't want to roll out IPv6 and you need excuses to defend your position. Fine by me. -lee From steve at ibctech.ca Fri Dec 11 10:59:05 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 11 Dec 2009 10:59:05 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B2263A9.2070801@Dilkie.com> References: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> <4B20F6DF.9000300@dilkie.com> <4B225847.3030702@ibctech.ca> <4B2263A9.2070801@Dilkie.com> Message-ID: <4B226C49.4050208@ibctech.ca> Lee Dilkie wrote: > > Steve Bertrand wrote: >> Lee Dilkie wrote: >> >>> Don't you essentially *have* multi-homing if you are dual-stack? >>> >> No. Multi-homing != dual stack. Dual stack can be as simple as having a >> link local v6 address on your machine without even being able to see any >> other v6 devices on the network. >> > Baloney. A link local address isn't routeable and if that's all that you > have bound to an interface, then you don't have IPv6 nor will the stack > attempt to make any connections over IPv6. what? If I have only a link local address, then I most certainly DO have IPv6, and I can also tell my SSH client to talk to the machine beside me using only link-local if I tell it the neighbours address: cohiba% ifconfig fxp0: flags=8843 mtu 1500 options=b inet6 fe80::207:e9ff:febe:43f%fxp0 prefixlen 64 scopeid 0x1 inet 208.70.104.4 netmask 0xffffff80 broadcast 208.70.104.127 ether 00:07:e9:be:04:3f test% ifconfig de0: flags=8843 mtu 1500 inet6 fe80::2c0:f0ff:fe30:b41f%de0 prefixlen 64 scopeid 0x1 inet 208.70.104.13 netmask 0xffffff80 broadcast 208.70.104.127 ether 00:c0:f0:30:b4:1f cohiba% ssh -l steve fe80::2c0:f0ff:fe30:b41f%fxp0 The authenticity of host 'fe80::2c0:f0ff:fe30:b41f%fxp0 (fe80::2c0:f0ff:fe30:b41f%fxp0)' can't be established. DSA key fingerprint is 24:a1:72:d8:3d:91:0e:c5:33:38:a2:af:9b:16:62:e1. Are you sure you want to continue connecting (yes/no)? I didn't say that link-local was routable. All I said was that having a simple link-local address tells you that the machine you are on is indeed 'dual-stack'. > "Multi-homing", the term, refers to multiple methods to access the same > network resource. By that definition, dual-stack suffices. Whether it'll > survive a physical outage is another matter. Well, I always thought that when referring to "Multi-homing" on an ARIN mailing list, most members would consider this in the context of: 2.7. Multihomed An organization is multihomed if it receives full-time connectivity from more than one ISP and has one or more routing prefixes announced by at least two of its upstream ISPs. ...over a *single* protocol. >>> If you >>> are multi-homed on IPv4, you don't really need it on IPv6, do you? >>> >> Yes, you do (imho). The two are mutually exclusive, even if all of your >> IPv6 transits are over v4 tunnels, redundant paths will better protect >> you from having your v6 prefixes fall off the earth. >> > And if they do? So what? Your IPv4 connection will be used with no loss > of service. Isn't that what you are looking for? No, what I am looking for is per-protocol redundancy. Switching back and forth between v4 and v6 is not the type of redundancy that I am after at all. It *is* a loss of service to me if I lose IPv6 connectivity. I have clients that connect via IPv6, and some of my own services are v6 only. >> >>> If an >>> IPv6 route is unavailable, the connection will be established on IPv4. >>> >> ...and the time-out value in some applications (such as my preferred SSH >> client for Windows) to fall-over to v4 can become frustrating. For a >> content provider, the time for a browser to switch to v4 when the >> providers internal v6 is unreachable could be potentially disasterous. >> > I don't disagree that the timeouts can be annoying when there's a > problem in the IPv6 route. So then, start by enabling it on smtp? > Machines are patient and don't mind the 30 second timeout and will > happily retry on IPv4. Done. SMTP was the first user-facing service that I had converted. > >>> Multi-homing IPv6 will matter once IPv6-only networks get rolled out and >>> I don't see that happening for some time yet. >>> >> I disagree completely. The same mentality that is applied to v4 >> resiliency should be applied all the same to v6. Not only that, it is >> extremely easy to v6 multi-home, as there are several very large ISPs >> who offer *free* peering/transit over tunnels that you can use in >> conjunction with your existing providers. [plug: he.net]. >> > Got it, you don't want to roll out IPv6 and you need excuses to defend > your position. Fine by me. ? I'm confused ;) Steve From spiffnolee at yahoo.com Fri Dec 11 12:23:41 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Fri, 11 Dec 2009 09:23:41 -0800 (PST) Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: <172481.38603.qm@web63302.mail.re1.yahoo.com> Message-ID: <576594.40848.qm@web63303.mail.re1.yahoo.com> > It's been a while since I looked at the Fortinet web site, but last > I looked, I couldn't find ANYTHING on the Fortinet web site that > said IPv6. I can't find anything on the Fortinet web site. No feature descriptions of any kind. But I downloaded the FortiOS 4.0 Administrator's Guide, and searched within it for "IPv6" and got dozens of hits. One of them was http://docs.fortinet.com/fgt/archives/3.0/techdocs/IPv6_support_Tech_Note_01-30007-82573-20081003.pdf which might suit your needs. I think the problem may be in where you're looking for feature descriptions. The 2-page marketing glossy doesn't mention IPv6, but also doesn't mention OSPF or multicast. Ditto Juniper, or CheckPoint, or Cisco, or iptables. To get information on what features are supported, you have to read the release notes or documentation. Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Fri Dec 11 14:18:17 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 11 Dec 2009 11:18:17 -0800 Subject: [arin-ppml] The non-deployment of IPv6 - The Economic Factor In-Reply-To: <00ea01ca7934$68582d70$39088850$@com> References: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> <00ea01ca7934$68582d70$39088850$@com> Message-ID: <4B229AF9.1060207@ipinc.net> VAUGHN THURMAN - SWIFT SYSTEMS INC wrote: > John, > > I must agree with your assertion that we have risks not yet considered in > the systems space. > > I wear dual hats and so besides running a regional ISP/Data Center, I spun > off a software company a few years back to focus on a task management and > workflow application that we had originally built for in-house use. > > We have a particularly savvy and very high-end customer on that task > management software (http://www.JobTraQ.com if anyone cares). They seem NOT > to be feeling the pinch lately at all. And thus, because unlike much of the > world they have extensive free capital and human resources to play with > right now, they are already running IPV6 dual stack in their test and > staging environments, in some of their training labs, and on a careful few > of the developer and business analyst's stations from where same access > their test and staging system. They can turn IPv6 off if they find anything > wrong and need to press on, but it has effectively helped them alert their > vendors (like us) ahead of some non-desirable moment of crisis. We only had > two minor issues, but we were completely blindsided by them both. One issue > was that we couldn't handle the longer string in a place where we audited > and then stored successful (and unsuccessful) logins along with remote users > IP address. The other issue was in a security report for displaying the > same data back to the system administrator. The things is, it is pretty > hard to log in if you are trying to save a big old IPv6 address into a field > with space for only 15 characters as part of that process (since that is > where the web server goes cross-eyed and begins looking for the corner in a > round room). > > Anyway, as a result of this, we have decided to deploy IPv6 on a limited > scale in the same dual stack modus so that we don't have to experience that > red faced feeling again. > > With that said, I would like to briefly pontificate on a related topic and > set it up by first quoting myself: "... And thus, because unlike much of > the world they have extensive free capital and human resources to play with > right now,,..." > > This (*The Economic Factor*) should not be underestimated as one of the more > significant root causes of IPv6's purported "non-deployment" as discussed > recently on this list. Were this 1999, with dot com crazed investors > drooling out large blobs of cash on demand, then Cisco (and I guess Juniper > too) would have already had six record quarters as every network tech > unpacked his new toys and enabled IPv6 just so he could say that he had on > his resume, etc. Same applies at the "of course we do" well funded backbone > providers. > > See here it is: One thing that will almost always vault the lowly > ROI-calculating-tactician into the irrefutable and overarching command > position above the normally elevated strategist is this... a limited budget. > "Sounds good, but not today. We don't have the money." Conversation over. > > I am so NOT a big government person, that this is almost astounding for me > to say, but this may be one of those situations where government's aid is > actually needed. Unless some entity is able to push down the cost of > deployment by mandating it upon themselves (fear shudders through me > britches as I ponder the risks of saying this, and then finding they mandate > it for me - must be a hypocrite). In this economy, and without a large > scale reference case complete with interoperability studies, etc. there is a > daunting chasm that the capitalists and entrepreneurs are just not ready to > cross yet in order to get to IPv6. Their capes are still tattered from the > current and hopefully waning battles against the dark forces of > commoditization, economic slumber, and comfort in the current state of "so > who is out of gas [IPv4}? My car [ISP] is still moving". > > Make sense? > It does to me. But to add to the pontificating, don't forget that 20 years ago the computer industry was a young, hobby market in combination with a glass tower market - the glass tower types had DoD, Visa and MC, and the hobby types had everything else. Today the computer biz is a commodity market and we are watching the last rattling dying gasps of most of the ivory tower types. The end of Sun Microsystems should have proved that to anyone. The Internet biz is going through much the same thing. My observation is that the days of the elevated strategist being in the command position in the computer and Internet biz are over. This is what happened to the automotive business a half century ago and we have been hearing the screams of the elevated strategist types bitching that the "bean counters" have wrecked and are wrecking GM/Chrysler/Olds/Toyota/Ford/etc. ever since. Of course, the venture capitalists and their elevated strategist cronies are still out there - and much like the planet of Magrathea faded from memory after the Galactic Empire collapsed, with it's accountants in cryogenic state, ready to come out when the economy improved, those VC's and their puppets will rise again - but it isn't going to ever be in the computer or Internet business. It might be somewhere in the health business, but that market is commodity too. > I think we have an economic problem here. How many software vendors are > going to get blindsided because they don't have a customer like we did to > test ahead of us? How many ISP's will slide under the edge of the universe > when the IPv4 run out crushes them for resources they don't have? Will they > turn to the banks to help them capitalize the switchover costs? Where is > the ROI? Are we doing this so that we can access new revenues, (which is > bankable) or isn't this really just a tad more like the Y2K thing? Spend, > spend, spend, stop, do we survive? Whew, then now we can go back to work > right? > > I don't have an easy answer to all of this, but thought it should be raised. > We may as a group need to start asking for some help, or figuring out how to > at least get a working group up and running that leads vendors rushing in > hoping to be the first to get the stamp of approval (and thus the ROI of > being first to announce "ready for IPv6 Interop", or "certified by X", etc). > Without a powerful economic incentive (sponsor, reference case, marketing > advantage, etc.) being provided in advance we are assuring the likelihood of > a painful transition - not at the time of our own choosing. > All that stuff has been tried already, and shot down by the ROI-calculating-tacticians. There is an IPv6 certification already, vendor outreach has been done. The problem is the task is just too big for anyone - which is exactly what happens in a commodity market. Look at the switchover of the automobile from gas to electric. We finally have the battery technology today (LiIon) to build a car that has the same range as a gas burner. But it's taking a lot of work to switch over and there's been some false starts. > I don't mean to suggest that vendors can't do IPv6 today. I am suggesting > that they can't do it well yet, and that as a result nobody wants to be > first if there is nobody really waiting to reward them for success. > > I also kind of agree with the "why didn't we just add some octets to IPv4" > statement, because the greatest capital spend is not on gear, it is on the > daunting task of becoming organizationally competent at something so very > different than the last rev. At the end, we are all bright and capable, > it's really a resource question. Can we afford to do this? Critical mass > has to be generated and all of the incentives will arrive, but the core > question is how can we create these incentives BEFORE the run-out, and in > this economy? > The US television industry struggled with that same question on the switchover from regular def analog transmission to hi-def digital. They finally threw in the towel and had the government force the issue. The global automobile industry is struggling with those same questions with the gas to electric switchover - and the assumption of control over GM and Chrysler by the US federal government is going to end up forcing that issue in the US, and other governments in other countries are going to force it with their automakers, too. The ROI-calculating-tacticians, AKA beancounters, aren't going to go to IPv6 unless forced to. The best thought I can come up with is that if enough of us early IPv6 adopters switch, then when crunch comes and businesses start going under because the beancounters have put off conversion for too long, then the government won't feel compelled to start propping them up with tax money. But I suspect that the opposite will happen and the governments will end up involved. Ted > > > Best, > ~Vaughn > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of John Curran > Sent: Wednesday, December 09, 2009 6:43 PM > To: Chris Engel > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] The non-deployment of IPv6 > > On Dec 9, 2009, at 4:48 PM, Chris Engel wrote: >> Well, >> >> If the time estimates I've seen put forward here are accurate....and I see > no reason to assume they wouldn't be.... then it'll be 2-3 years minimum > before we see anyone out there that can ONLY do IPv6. > > I agree that looks like a lot of time, but there's quite a few assumptions > in such an estimate and it could move up very quickly. Additionally, there > will be an increasing number of clients which will attempt to connect via > IPv6 *first*, so you actually are impacting your performance if you don't do > IPv6 soon. > >> In that time frame I'd be looking for the same sort of solution for public > facing servers in the DMZ as I would for the rest of my network....namely > some sort of v4 to v6 gateway service that would act as a proxy for my 4 > machines and allow them to communicate with IPv6 hosts. > > Does your present firewall device support IPv6 NAT today? In discussion > this situation with other organizations, I'm generally finding that routers, > firewalls, and load-balancers aren't what are not what breaks, but instead > their tools such as help-desk system and configuration generators which > simply don't know IPv6. Finding these issues is a great reason to > experiment with at least one public facing IPv6 server sooner rather than > later. > > /John > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From michael.dillon at bt.com Fri Dec 11 14:29:09 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 11 Dec 2009 19:29:09 -0000 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458047BBF57@E03MVZ2-UKDY.domain1.systemhost.net> > It's been a while since I looked at the Fortinet web site, > but last I looked, I couldn't find ANYTHING on the Fortinet > web site that said IPv6. And, the current version of FortiOS > is V4 or so. Does V4 have all of the features in the V3.0 > that was certified? Probably, but how do I figure that out? It's that kind of lazy attitude that has got us into the mess that we are in today. Everybody is just waiting for the other guy to act first instead of showing some leadership. I went to the Fortinet site and in only a few seconds I found this URL: There is a nice box there where you can type in your question. In fact, let me make it easy for you and give you some text to use. We are interested in Fortinet's firewall products but are disturbed by the fact that we can find no information on IPv6 support. Given that IPv6 traffic on the Internet already exceeds the total Internet traffic from 10 years ago, we can't consider buying any network software or equipment that does not support IPv6. In particular we have two questions that we would like answered: Do you have IPv6 support under development which we can use as a trial customer? What is your roadmap for IPv6 support in your products? > That's my point (beef, soapbox, etc.). The vendors that > support IPv6 don't think IPv6 is important enough to mention > it in the spec sheets for each piece of equipment where it > would be easy to find. The information, if it is available, > is hidden off in some dusty corner. That is because the product is not launched yet to the open market but still undergoing trials and testing. Or maybe its still in development. Vendors generally do not advertise stuff unless you can purchase it right now and they have all their ducks in a row, documentation, telephone support people trained, etc. If customers will not talk to the vendors and let them know that they need IPv6 support, then the vendors don't even know that a market need exists. > My real point is that from discussions on this list, I know > that one of my local vendors is working on IPv6 somewhere. > However, the local sales rep doesn't admit to knowing > anything about it. Maybe that's because you haven't asked this sales rep a point blank question. -What kind of IPv6 service could your company offer me today? -It seems that you don't know the answer. When can you get back to me with more information currently available IPv6 service as well as your roadmap for IPv6? -Can you put me in touch with your supervisor please? -Hello, customer support? I was talking to one of your sales reps in Woebegone named Frank Lee Dumm, and he refused to get me some information about your services. I wonder if you can put me in touch with someone in sales who knows about your roadmap for IPv6 services, that is spelled eye-pee-vee-six. Thank you. The fact is that every vendor who currently supplies products connected to IPv4 networking is also currently working on IPv6 products, with a few exceptions who will shortly no longer be in business. Do you want to rely on a vendor who will not be in business next year? I thought not. So, phone and write letters and emails and cajole people and escalate it up through the vendor company looking for someone who will explain their IPv6 roadmap. If you don't get answers, then stop doing business with them, and consider dumping their stuff on Ebay and replacing it with products from a RESPONSIVE vendor. The network business is a tough one and it doesn't help you when your vendors won't work in partnership with you, so weed out the bad ones and support the good ones. In 2011 there will be a reckoning and a lot of companies will go out of business or be acquired, which may amount to much the same thing. Don't wait until the last moment to find yourself a sheltered spot against the coming storm. --Michael Dillon From michael.dillon at bt.com Fri Dec 11 14:34:56 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 11 Dec 2009 19:34:56 -0000 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <576594.40848.qm@web63303.mail.re1.yahoo.com> Message-ID: <28E139F46D45AF49A31950F88C497458047BBF59@E03MVZ2-UKDY.domain1.systemhost.net> I can't find anything on the Fortinet web site. No feature > descriptions of any kind. But I downloaded the FortiOS 4.0 > Administrator's Guide, and searched within it for "IPv6" and > got dozens of hits. One of them was > http://docs.fortinet.com/fgt/archives/3.0/techdocs/IPv6_suppor t_Tech_Note_01-30007-82573-20081003.pdf > which might suit your needs. I added a link to that technote on the IPv6 Firewalls page at . If anyone else out there knows of IPv6 products or information that should be on the wiki, please register and edit the appropriate pages. --Michael Dillon From tedm at ipinc.net Fri Dec 11 16:08:16 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 11 Dec 2009 13:08:16 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <28E139F46D45AF49A31950F88C497458047BBF59@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458047BBF59@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B22B4C0.4030709@ipinc.net> michael.dillon at bt.com wrote: > If anyone else out there knows of IPv6 products or information that > should be on the wiki, please register and edit the appropriate pages. > I also just made a few entries to this page. Ted From farmer at umn.edu Fri Dec 11 21:23:06 2009 From: farmer at umn.edu (David Farmer) Date: Fri, 11 Dec 2009 20:23:06 -0600 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised In-Reply-To: <4B06D427.1080905@arin.net> References: <4B06D427.1080905@arin.net> Message-ID: <4B22FE8A.6090806@umn.edu> The AC will be voting to abandon or accept this proposal 103 and the related proposal 104 on to its docket late next week. I concur with other comments to the effect that the AC would either abandon both proposals or merge them and accept them on to the docked as a single piece of work. So I'm dealing with them both in this email. There hasn't been any posts on either of these proposals since before Thanksgiving. So, as one of the shepherds I though I would summarize what I've seen so far, then maybe make a few comments, and see if anyone has any comments before the AC votes next week. So, if you have opinions or arguments at to why the AC should or should NOT put this proposal on its docket you should express them soon. ---- Regarding Proposal 103: 31 total posts, 12 individuals, 7 in support, 2 opposed, 22 posts furthering the discussion and not explicitly supporting or opposing Regarding Proposal 104: 5 total posts, 4 individuals, 1 in support, 1 oppose, 3 furthering the discussion and not explicitly supporting or opposing No warranty on those totals, I might have screw up my hatch marks, but it should be close. ---- Personally, I find the proposal intriguing. I believe this proposal provides a bold and creative solution to several current problems in ARIN's IPv6 policies. However, at the same time this proposal has several issues; (FYI, These are my own words, but some of the ideas are borrowed from discussions with others, including private discussions) - Needs Basis First and probably most important from my personal point of view, I don't see a needs basis in this policy, even in the classful IPv4 days you had to demonstrate need to get a Class B, or Class A; I believe that you had to demonstrate a need for more than 256 host and/or multiple subnets to get a Class B, and more than 256 subnets or have a large scale backbone to get a Class A. I may not have that exactly right but there was a criteria. If there wasn't then the first 126 allocation would have been for Class As and then next 16,000+ allocations would have been for Class Bs leaving only Class C and we would have exhausted IPv4 long ago. So, I believe this proposal would need some kind of needs basis. Maybe something as simple as, to get a /32 provide a creditable business plan for more than 200 sites in two years, and for a /40 more than 1 site, for a /48 a site with more than 256 host, and anyone my request a /56. I'd need to think about what you should need to qualify for a /24, but I believe it must be more than the ability to write a $100,000 check every year. Maybe, 10,000+ sites assigned within a current /32 or creditable business plan for more that 20,000 sites within 2 years. Need ("operational need", not need as in "I want") is a basic tenet of RFC 2050, if we walk away from that we will have big problems. That said we definitely need to change our current IPv4-style thinking on the subject of need for IPv6. And, to be honest I'm not sure anyone truly understands the full implications of HD-ratios long-term. But, that doesn't mean throwing out the baby out with the bathwater. - This could encourage the Big Guys to filter the little guys, by maybe making it to easy for them to do so. - As a result, this could encourage the smaller guys to try to get bigger blocks than they really need in order to justify having a routing slot and not being filtered. Think this threw a little, by making filtering this easy based on size, if there isn't some kind of needs based justification, and there is a pricing scheme like described then wouldn't we end up with something like you need to pay for a /32 for anyone to accept your route as a serious player. If you can't afford $10,000 they go away you have to be my customer. - Mergers and Acquisitions Getting people to properly report mergers and acquisitions seems hard enough now. Requiring the single block per size per organization, and therefore renumbering, seems like an additional disincentive to proper reporting. Leading to more bad registry data, less transparency to what is really going on, and possibly degrading operational response. - This would make ARIN's IPv6 policies way different than all the other RIRs. William partially answered this; paraphrasing his answer, maybe we shouldn't shift the whole world all at once. There might be an advantage for one RIR to go down this road first. Somebody going first makes sense to me, backing out if it turns out to be a bad idea. But, what if the rest of the world thinks it is a bad idea and has no intention to follow to begin with? Should we still go down this road anyway? - 6.10.1 Micro-allocations for Critical Infrastructure are not moot and should be preserved, this allows network operators to create special filtering rule, if they wish, for these Critical Infrastructures. It seems prudent to keep some special ranges such as these. Maybe they should be renamed to Critical Infrastructure Allocations. The term micro-allocations probably doesn't fit anymore, but they are still Critical Infrastructure. However, I agree that 6.10.2 Micro-allocations for Internal Infrastructure should probably be deprecated. - These changes are very radical. It is at least very difficult, if not impossible, to predict what the real outcome of these policy changes will be. I believe this will fix some of the issues we have today, but I'm not sure we will not just replace those problems with bigger or more intractable ones. Are there some incremental steps we can take toward this vision, without jumping off the cliff into a brave but unknown new world? How about creating PI /40 allocations for small providers and PI /40 assignments for large multi-site end-users, and blessing providers to make similar PA assignments. In Dearborn we couldn't get consensus to change the 200 customer in two year justification required to get a /32. And there is nothing explicit for larger multi-site end users either. A /40 seems to fit the bill. In the Internet2 world we assigned GigaPOPs /40s out of the Internet2 /32, it worked well. Especially, in the early day of IPv6, when people still believed in tighter providers based aggregation for IPv6. Think of GigaPOPs as regional cooperative providers aggregating end-sites into the national member owned Internet2 backbone. This isn't so radical, and if the rest of the world doesn't follow it still might be a good idea anyway. ---- One last reminder; If you have opinions or arguments why the AC should or should not put this proposal on its docket you should speak up by the middle of next week. Thank you for your participation. Member Services wrote: > The proposal originator submitted a revised version of the proposal. > > The AC will review this proposal at their next regularly scheduled > meeting and decide how to utilize the proposal. Their decision will be > announced to the PPML. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 103: Change IPv6 Allocation Process > > Proposal Originator: William Herrin > > Proposal Version: 1.1 > > Date: 20 November 2009 > > Proposal type: new > > Policy term: permanent. > > Policy statement: > > Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4, > 6.5.1-6.5.5, 6.5.8, 6.7, 6.10 > > Strike NRPM 6.3.5 sentence 2. > > Strike "/NIR" from NRPM section 6.5.6. > > In section 6.9 strike NRPM "/LIR" at the end of paragraph 1 and all of > paragraph 2. > > Replace 6.2.5 as follows: > > 6.2.5 Allocate and Assign > > For the purposes of NRPM section 6, allocate and assign are > synonymous. Both terms describe any or all use identified in section > 2.5. > > Replace 6.3.4 paragraph 4 with: > > Further, RIRs should apply allocation practices that minimize route > disaggregation. > > Replace 6.5.7 with: > > 6.5.7. Existing IPv6 address space holders > > Organizations that received IPv6 allocations under the previous IPv6 > address policy are entitled to either retain those allocations as is > or trade them in for an allocation under 6.5.9. Where the prefix > length of such registrations differs from the standard lengths in > 6.5.9.1, it shall count as a registration of the next longer length. > > The above notwithstanding, ARIN is authorized to standardize the > prefix lengths within these previously-allocated address pools in a > manner approaching 6.5.9.4 by increasing the prefix length of all > registrants within a particular pool to some specific minimum prefix > length for the pool. > > Add NRPM section 6.2.10 as follows: > > 6.2.10 Organization > > An organization under section 6 is either: > > one or more legal entities under common control or ownership, or > > one such legal entity which operates strictly separate networks from > the others. > > Add NRPM section 6.5.9 as follows: > > 6.5.9 Regular IPv6 Allocations > > 6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and only > the following prefix lengths: /56, /48, /40, /32, /24 > > 6.5.9.2 No usage-based eligibility requirements shall apply to IPv6 > allocations. > > 6.5.9.3 ARIN shall register no more than one address block of each > prefix-length for any single organization. These blocks may be > registered simultaneously. Renumbering of existing blocks is not > required to receive additional blocks. > > 6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that the > identity of the allocation pool serves to classify the expected prefix > length of allocations within. ISPs may use that classification to > filter or otherwise manage their routing tables. > > 6.5.9.5 For each allocation size, ARIN shall further manage the > allocation pools such that the pool identity serves to classify > whether or not the registrant is Multihomed. > > 6.5.9.6 ARIN shall offer addresses from pools classified as multihomed > only to organizations which ARIN has verified are multihomed on the > public Internet per NRPM 2.7. > > 6.5.9.7 Where an organization ceases to be Multihomed it shall > surrender all address allocations from within pools classified as > multihomed within 3 months. > > > Rationale: > > See the implementation notes section below for what should replace > utilization-based eligibility. > > The existing IPv6 allocation policy under section 6.5 makes a number > of unproven assumptions about how IPv6 allocations will work. > > Unproven: we can make a reasonable guess about how many IPv6 subnets > an organization will need at the outset when they first request IP > addresses. When in all of human history has this ever proven true of > any resource? > > Unproven: with sparse allocation, we can allow organizations to expand > by just changing their subnet mask so that they don't have to announce > additional routes into the DFZ. This claim is questionable. With > sparse allocation, we either consume much larger blocks that what we > assign (so why not just assign the larger block?) or else we don't > consume them in which case the org either has to renumber to expand or > he has to announce a second route. Worse, because routes of various > sizes are all scattered inside the same address space, its impractical > to filter out the traffic engineering routes. > > Unproven: we can force organizations not to disaggregate for traffic > engineering purposes. Neither any of our experience with IPv4 nor any > of the research in the IRTF Routing Research Group suggests that this > is even remotely practical so long as BGP or any similar system rules > the roost. > > Unproven: all non-ISPs can be reasonably expected to get their address > space from ISPs instead of from ARIN. We can certainly operate that > way, but it could prove deadly to the routing table. Any organization > multihomed between two ISPs will need to announce that route via BGP, > regardless of where they get the address space from. We have knobs and > dials in the routers that let us easily filter disaggregates from > distant announcements, but we don't dare do so if there is a > possibility that one of those disaggregates is a multihomed customer > rather than traffic engineering. > > Benefits of this proposal: > > A. Efficient allocation of IP addresses. Orgs get what they need when > they need it without a great deal of guesswork. > > B. Efficient utilization of BGP routing slots. No multihomed orgs will > announce more than five unfilterable routes, and that only if they're > so large that they can afford the price tag for the biggest address > blocks. That's a good thing since IPv6 routes that propagate worldwide > may impose an annual systemic overhead cost on ISPs of as much as US > $16,000 each. > > C. Traffic engineering routes are trivially filterable. Any route > longer than the published allocation size can be presumed to be > traffic engineering, not a downstream multihomed customer, thus you > can filter distant small routes with confidence and ease. > > D. Fair. No need to define the difference between ISP and not ISP. > Everybody plays by the same rules. > > E. No complicated analysis for allocation. You pay for what you want > and get what you pay for. You're either multihomed or you're not. > > F. Gets ARIN out of the business of being the gatekeeper for Internet > routing policy. By classifying allocations instead of making > eligibility decisions, ARIN empowers the ISPs to set appropriate > routing eligibility policies instead. > > FAQ > > Q. Isn't this classfull addressing all over again? > > A. Yes. > > Classful addressing had a lot of virtues with respect to route > filtering and management. We had to abandon it because there weren't > enough B's for everyone who needed more than one C and there weren't > enough A's period. With IPv6, we don't have that problem. Not yet and > maybe not ever. Perhaps we can have our cake and eat it too. > > Q. What if I don't want to accept /56 routes for single-homed users? > > A. This policy proposal intentionally and fully places backbone > routing policy in the hands of the ISPs who operate the Internet's > "Default-Free Zone (DFZ)," colloquially known as the Internet > backbone. The author expects that some of the allocations, especially > some of the single-homed allocations, *will not* be routable on the > public Internet. When we hold a general expectation that all of ARIN's > allocations will be routable, we effectively mean that ARIN decides > what the Internet routing policy will be. That's precisely the role > this proposal removes from ARIN's hands and restores to the ISPs. > > Q. Spell it out for me. How exactly will pools and size > classifications enable route filtering? > > A. Suppose ARIN holds 4000::/12. ARIN might split it up as follows: > > 4000::/13 -- reserved > 4008::/15 -- multihomed /24 allocations > 400a::/15 -- non-multihomed /24 allocations > 400c::/16 -- multihomed /32 allocations > 400d::/16 -- non-multihomed /32 allocations > 400e:0000::/18 -- multihomed /40 allocations > 400e:4000::/18 -- non-multihomed /40 allocations > 400e:8000::/24 -- multihomed /48 allocations > 400e:8100::/24 -- non-multihomed /48 allocations > 400e:8200::/24 -- multihomed /56 allocations > 400e:8300::/24 -- non-multihomed /56 allocations > 400e:8400::/22 -- reserved > 400e:8800::/21 -- reserved > 400e:9000::/20 -- reserved > 400e:a000::/19 -- reserved > 400e:c000::/18 -- reserved > 400f::/16 -- reserved > > Now, you're an ISP. Here's a sample routing policy you might choose: > > Accept any routes to /32 because anyone paying $10k per year for > addresses is big enough to ride. > For /24 allow 2 bits of traffic engineering too. > Single-homers who won't spend $10k/year on their addresses (smaller > than /32) must use addresses from their ISP. Tough luck. > Accept multihomers down to /48. > The folks paying only $10/year for /56's aren't serious. > > Your route filter looks like this: > > accept 400e:8000::/24 equal 48 > accept 400e:0000::/18 equal 40 > accept 400c::/15 equal 32 > accept 4008::/14 le 26 > reject 4000::/12 le 128 > > Note how 400e:8000::/24 contains only /48 allocations and you're > allowing only /48 announcements. Since there aren't any /47 or /46 > allocations there, nobody in the pool can slip TE routes past you. On > the other hand, you'll get some benefit of traffic engineering from > the super-massive /24 registrants up in 4008::/14 because you're > allowing them to disaggregate down to /26. > > Q. If its so expensive to announce routes into the DFZ, why not use > something better than BGP? > > A. In 2008 the IRTF Routing Research Group compiled an exhaustive > study attempting to identify the possible ways to improve the routing > system. A draft of the results is at > http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . While > there are many promising ideas for how to replace BGP with something > that scales better, we're at least a decade away and probably more > from any significant deployment of a BGP replacement. > > Q. Is it really true that multihoming requires announcing a route via > BGP? > > A. The short answer is yes. The long answer is more complicated. > > Folks have tried very hard to devise multi-vendor multihomed systems > which don't rely on BGP. The only approach that has ever come near > success is dynamically changing DNS records to favor the currently > working Internet connection. "Near" is a relative term here. Such > network architectures are enormously complex and they don't work > especially well. The DNS protocol itself supports quick changes but > the applications which use it often don't. It takes hours to achieve > two-nines recovery from an address change in the DNS and it takes > months to achieve five-nines recovery. Web browsers, for example, > don't immediately recover. Search google for "DNS Pinning." > > Q. So the Internet's resulting route policy will be to allow all the > sizes that no major ISP decides to filter and restrict the rest? > > A. That's one possible outcome. On the other hand, research in the > routing field suggests that with a sufficiently rich classification > scheme, it may be possible to implement lower priority systems with > provider-independent addresses yet without a global route. Hints for > how such a thing might work can be found in > http://www.cs.cornell.edu/people/francis/va-wp.pdf and > http://bill.herrin.us/network/trrp.html. Such schemes need a rich > classification process at the address allocation level that makes it > possible for ISPs to make reasonable and simple decisions about which > routes should be distributed to every DFZ router and which should not. > > Wouldn't that be something: IPv6 provider independent addresses for > everybody without materially increasing the cost of the routing > system. > > Q. Why allocate the /48's from a pool only for /48's, /32's from a /32 > pool, etc.? Why not allocate from just one pool? > > A. If all assignments in a particular pool are /32 then any route in > the /32 pool which is longer than /32 is a traffic engineering (TE) > route. As a router operator you can filter and discard TE routes if > you find they give you insufficient benefit. The routes you filter > don't cost you any money; only the routes you keep carry a price tag. > > You can only filter if you're sure they're TE routes... If they're > distinct downstream customer routes and you filter them, there goes > the Internet. Or at least there goes your part of it. See customers. > See customers run... straight to your competitor. Setting up the > distinct pools makes it practical to know with certainty whether the > routes you're filtering are only for TE. > > Q. Why allow only one allocation of each particular size? > > A. Without the address scarcity issue which drives IPv4 policy, the > primary criteria for IPv6 addressing policy is suppressing the > disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8). > Such a criteria is not well served if an organization holds dozens of > discontiguous address spaces as a result of acquisitions, mergers and > and growing a little bit at a time. This proposal says, in effect, > once you've consumed your smaller allocation it's time for you to get > a *much* bigger allocation. The rest of us don't want to pay the > routing table price for you coming back again and again and again. > > The proposal could require some renumbering as a result of mergers and > acquisitions. However, with only modest planning on the registrant's > part, the policy its flexible enough to allow that renumbering to > occur over a long period of time so that both cost and disruption are > minimized. In many cases, customer churn can be expected to take care > of much of the renumbering activity all by itself. > > Q. What about the IETF recommendations? > > A. RFC 3177 recommends that ISPs receive a /32 while downstream > customers receive a /48 assignment by default with so-called "sparse > allocation" to allow those assignments to expand by changing the > netmask. While this proposal supports organizations who wish to follow > those recommendations, it is not this proposal's intention that ARIN > follow RFC 3177. > > RFC 3177 is not the gospel truth. It was written back in 2001 when > there was little IPv6 outside of academia and, indeed, little IPv6 at > all. It's an engineers' SWAG about what operations folk should do > that's now 8-years-stale. > > This proposal attempts to slow-start IPv6 allocations instead, while > still maintaining the principle of suppressing the routing table size. > As an ISP, consider implementing a slow start for your downstream > customers as well: Give them a /60 initially, add a /56 when they need > it and add a /52 when they run out of the /56. A /60 is 16 /64 > subnets. That's an internal LAN, a DMZ and 14 more subnets. Just how > many subnets do you think your normal downstream customer will > actually use? > > Q. What happens when organizations merge or split? > > A. Entities which merge may renumber out of and return conflicting > allocations, or they may maintain the existence of the acquired > organization in order to keep it's addresses. Either way it should be > a minor hardship. > > Entities which split have a bigger problem since the practical effect > of route filtering may be that only one of them can keep the > addresses. To a large extent, that problem already exists and is a > pain in the rump for IPv4 operations today. This policy doesn't solve > it but it doesn't make it a whole lot worse either. Because > disaggregates are likely to be filtered, this IPv6 policy does gives > us a slightly better guarantee that the rest of us won't get stuck > with the check (in the form of routing slot consumption) when an ISP > goes bankrupt and gets split up. > > Q. What happens to the existing (legacy) IPv6 allocations and > assignments? > > A. An organization will be entitled to retain their existing > allocations indefinitely if they so desire. If the prefix length does > not match one of the standard prefix lengths then it will be treated > as the next smaller prefix length for the purposes of determining > eligibility for further IPv6 allocations. To discourage unnecessary > disaggregation, the prefix length of this "legacy" allocation will not > be expanded even if there is room in the pool to do so. > > Q. What about IPv6 addresses for uses which will not be connected to > the Internet at all? > > A. Folks are welcome to get non-multihomed addresses for any purpose > whatsoever. If they do eventually decide to connect to the Internet, > the routes will follow whatever rules the ISPs have imposed for routes > within the single-homed pools. > > Q. What about reporting requirements for downstream assignments? > > A. Reporting requirements were instituted for the purpose of verifying > eligibility for additional allocations. They have proven useful for > other purposes and the author encourages ARIN to maintain the SWIP > system. Nevertheless, this proposal renders the use of SWIP for IPv6 > optional since it is no longer needed to verify eligibility for > allocations. > > Q. What if I need more than a /24? > > A. This proposal's author asserts as obvious: anyone who defines a > need for more than a trillion subnets should make their case publicly > on PPML, seeking a follow-on proposal that establishes address pools > at the /16 level. > > Q. What does standardize prefix lengths within the legacy pools in > 6.5.7 mean? > > A. Wes George pointed out that depending on the rules ARIN has > followed with respect to leaving space between allocations, it may be > possible to standardize the existing pools on some prefix length as > well. If it is possible, folks should become able to better filter > disaggregation in those pools too. > > So, for example, if ARIN allocated a /32, a /31 and a /30 from the old > /32 pool and reserved a /28 for each allocation to expand, ARIN could > peremptorily increase all three allocations to either /28 and then > publish that the exact prefix length in that pool is /28. > > Another example, if ARIN allocated a bunch of /32's and a /26, > reserving /28 for each allocated /32, ARIN could increase the /32's to > /28 and publish that the minimum allocation size for the pool is /28. > Instead of the /26 registrant being able to disaggregate into 64 > /32's, he might then be constrained to only disaggregate into 4 /28's. > > While this proposal does not require ARIN to take that action, it > authorizes it. > > Q. What are the struck sections of the current IPv6 policy and why > should they be struck? > > A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the > policy as revised by this proposal. > > 6.3.4 paragraph 4 gives instructions on accomplishing address > aggregation which are, if this proposal's rationale is correct, > counterproductive to encouraging route aggregation. Address > aggregation only matters to the extent that it helps bring about route > aggregation. > > 6.3.5 sentence 2 speaks to documentation issues that are incompatible > with this proposal. If this proposal's rationale is correct then fees > alone are sufficient to prevent unnecessary waste. > > The 6.4.3 notion of a minimum allocation is obsoleted by the > allocation pools of specific size in this proposal. > > 6.4.4 is moot as this proposal does not expect registrants to justify > their IPv6 allocation size. > > 6.5.1 - 6.5.4 and 6.5.8 are replaced entirely by 6.5.9. > > 6.5.5 is largely moot since it's no longer necessary to confirm > downstream assignments in order to determine eligibility for > additional addresses. > > 6.7 is moot as it is unnecessary to compute utilization to justify > addresses under this proposal. > > 6.9 paragraph 2 is moot since utilization is not a factor in IPv6 > policy under this proposal. > > 6.10 is redundant since micro-allocations are trivially accomplished > under 6.5.9. > > > Implementation notes: > > To prevent wasteful consumption of IPv6 address space without a > complicated eligibility regime, the author recommends an initial and > annual fee regime for IPv6 address allocations similar to: > > /56 -- $10 USD > /48 -- $100 USD > /40 -- $1000 USD > /32 -- $10,000 USD > /24 -- $100,000 USD > Legacy -- the lesser of the cost of the next larger size or the cost > of the next smaller size times the number encompassed by the > registration. > > The above notwithstanding, it may be advisable to discount /40s and > /32s to a much lower price during IPv6's general deployment process in > order to encourage adoption. Folks who already hold /31's should > probably also get a big break on the $20k fee for a good long while, > perhaps until the first time they request an additional block without > offering a plan to return the legacy addresses. > > For verification of multihoming, the current way ARIN verifies > multihoming for other parts of it's policy appears satisfactory. > Should that change, the author suggests requiring that the AS# > contacts for at least two AS#'s submit a template indicating that they > intend to originate or propagate IPv6 BGP routes from the registrant's > ORG. > > Timetable for implementation: following an update of ARIN's IPv6 > fee structure. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From mcr at sandelman.ca Fri Dec 11 21:57:05 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 11 Dec 2009 21:57:05 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised In-Reply-To: <4B22FE8A.6090806@umn.edu> References: <4B06D427.1080905@arin.net> <4B22FE8A.6090806@umn.edu> Message-ID: <6871.1260586625@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "David" == David Farmer writes: David> - Needs Basis I agree. David> First and probably most important from my personal point of David> view, I don't see a needs basis in this policy, even in the David> classful IPv4 days you had to demonstrate need to get a Class David> B, or Class A; I believe that you had to demonstrate a need In those days was very little required to get a /24. And, lots of organizations *DID* get /8s in those days, recall. As long as: David> So, I believe this proposal would need some kind of needs David> basis. Maybe something as simple as, to get a /32 provide a David> creditable business plan for more than 200 sites in two David> years, and for a /40 more than 1 site, for a /48 a site with David> more than 256 host, and anyone my request a /56. The last part is there (/56), then I agree with the need for a minimal needs basis. David> - This could encourage the Big Guys to filter the little David> guys, by maybe making it to easy for them to do so. Doesn't matter. IPv6 encourages a site to have multiple prefixes. Officially, that's the way to multihome (until shim6 either works or fails), and now that site-locals are gone, there is nothing else to use inside. The /56s won't be seen in the routing table, and *THAT IS A GOOD THING* David> - As a result, this could encourage the smaller guys to try David> to get bigger blocks than they really need in order to David> justify having a routing slot and not being filtered. That's where we are now. David> - This would make ARIN's IPv6 policies way different than all David> the other RIRs. David> William partially answered this; paraphrasing his answer, David> maybe we shouldn't shift the whole world all at once. There David> might be an advantage for one RIR to go down this road first. I concur. David> - 6.10.1 Micro-allocations for Critical Infrastructure are David> not moot and should be preserved, this allows network David> operators to create special filtering rule, if they wish, for David> these Critical Infrastructures. It seems prudent to keep David> some special ranges such as these. Maybe they should be David> renamed to Critical Infrastructure Allocations. The term David> micro-allocations probably doesn't fit anymore, but they are David> still Critical Infrastructure. Okay. It's just a special extra pool of /48s or /56s, it's not a big deal. David> intractable ones. Are there some incremental steps we can David> take toward this vision, without jumping off the cliff into a David> brave but unknown new world? David> How about creating PI /40 allocations for small providers and David> PI /40 assignments for large multi-site end-users, and David> blessing providers to make similar PA assignments. In David> Dearborn we couldn't get consensus to change the 200 customer David> in two year justification required to get a /32. And there is David> nothing explicit for larger multi-site end users either. A David> /40 seems to fit the bill. okay, I can live with this. David> One last reminder; David> If you have opinions or arguments why the AC should or should David> not put this proposal on its docket you should speak up by David> the middle of next week. David> Thank you for your participation. Thanks for bringing this back up. I would like to see the AC proceed with this. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSyMGeYCLcPvd0N1lAQIawQgAgikXqMcRsPEDigfCZZuJ2FYZbzWHaK9m cpqzV+BT8InMMaOWcrhNSDAkwK8XNQlfvsxmoqk2of92SH7EyJLfC83Ut+PG50GF h5H5zl7etw2Tb2+LnVwpqc8h4bYi2+oLpF/p2C7heH0118YeBBferzXQcgiFS9qg uwA/xqRh+EwMm1Who4/ZFLGdBd+7sNFgo64OA2Gde58gpoqRZ519rqaBD4nDqz/w mbU2T4YLxt4uTlubNaspVOgIkCGGpRYQx0hXOXDbm0KMmIvI6SFgXzj7JHce1sAG FbPLspmuZHaC6yor4Yr8fPMuzov+FFi2Gfwu4oEi2AgJOkBtoLZAVA== =MFoK -----END PGP SIGNATURE----- From joelja at bogus.com Thu Dec 10 19:03:58 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 10 Dec 2009 16:03:58 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <04b501ca79f0$9dafb350$d90f19f0$@net> References: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> <04b501ca79f0$9dafb350$d90f19f0$@net> Message-ID: <4B218C6E.4030901@bogus.com> Tony Hain wrote: > Why do you say multi-homing is unrealistic? Do ARIN policies keep you from > getting a PI /48? If so that needs to be fixed. If not, your complaint would > appear to be an artificial justification for delaying. At check point we asked for and obtained ipv6 pi space under the current ARIN number policy, although it's been while since I've done it for ipv4 I wouldn't characterize it as either dramatically different or hard. > Tony > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Shane Foster >> Sent: Wednesday, December 09, 2009 4:25 PM >> To: John Curran; Chris Engel >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] The non-deployment of IPv6 >> >> I'm with a small content provider. >> >> At the moment, I don't see us moving any of our sites to IPv6 until >> multihoming is realistic option. >> The costs aren't an issue, the code changes and config updates are >> relatively minor, but lack of multihoming options for sites that only >> need an IPv4 /24 to advertise is a blocker. >> >> I see that there are some new (this year) Shim6 RFCs from the IETF. >> Seems unlikely that there will be any real solutions until that effort >> is finally dropped. >> >> Thanks, >> Shane >> >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of John Curran >> Sent: Wednesday, December 09, 2009 3:43 PM >> To: Chris Engel >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] The non-deployment of IPv6 >> >> On Dec 9, 2009, at 4:48 PM, Chris Engel wrote: >>> Well, >>> >>> If the time estimates I've seen put forward here are accurate....and >> I >> see no reason to assume they wouldn't be.... then it'll be 2-3 years >> minimum before we see anyone out there that can ONLY do IPv6. >> >> I agree that looks like a lot of time, but there's quite a few >> assumptions in such an estimate and it could move up very quickly. >> Additionally, there will be an increasing number of clients which will >> attempt to connect via IPv6 *first*, so you actually are impacting your >> performance if you don't do IPv6 soon. >> >>> In that time frame I'd be looking for the same sort of solution for >> public facing servers in the DMZ as I would for the rest of my >> network....namely some sort of v4 to v6 gateway service that would act >> as a proxy for my 4 machines and allow them to communicate with IPv6 >> hosts. >> >> Does your present firewall device support IPv6 NAT today? In >> discussion this situation with other organizations, I'm generally >> finding that routers, firewalls, and load-balancers aren't what are not >> what breaks, but instead their tools such as help-desk system and >> configuration generators which simply don't know IPv6. Finding these >> issues is a great reason to experiment with at least one public facing >> IPv6 server sooner rather than later. >> >> /John >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From steve at ibctech.ca Sat Dec 12 18:27:42 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sat, 12 Dec 2009 18:27:42 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B218C6E.4030901@bogus.com> References: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> <04b501ca79f0$9dafb350$d90f19f0$@net> <4B218C6E.4030901@bogus.com> Message-ID: <4B2426EE.1020604@ibctech.ca> Joel Jaeggli wrote: > > Tony Hain wrote: >> Why do you say multi-homing is unrealistic? Do ARIN policies keep you from >> getting a PI /48? If so that needs to be fixed. If not, your complaint would >> appear to be an artificial justification for delaying. > > At check point we asked for and obtained ipv6 pi space under the current > ARIN number policy, although it's been while since I've done it for ipv4 > I wouldn't characterize it as either dramatically different or hard. I concur with Joel and Tony. Although I'm not in a position to request PI space, where I had a hard time was informing ARIN that a /32 was too much for my needs (and I _still_ received it, due to policy). If anyone, anywhere feels that ARIN policy is a barrier to entry, then I personally beg you to just put in the request for the address space regardless of what the policy states. ARIN will not beat you with a stick for asking. As it goes, the worst someone can say is 'no'. If they do happen to say 'no', they will be able to refer to the specific sub-section of the policy as to why. Then, you come back here to this list, post your complaint, and we *will* change the policy. That is what this list is for. _I_ want to ensure that there is no way in hell that anyone can complain that their barrier to entry was the inability to acquire address space. Period. Steve From michael.dillon at bt.com Sat Dec 12 18:49:47 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 12 Dec 2009 23:49:47 -0000 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B2426EE.1020604@ibctech.ca> Message-ID: <28E139F46D45AF49A31950F88C497458047BBF9A@E03MVZ2-UKDY.domain1.systemhost.net> > Although I'm not in a position to request PI space, where I > had a hard time was informing ARIN that a /32 was too much > for my needs (and I _still_ received it, due to policy). That /32 may have been too much for YOUR needs, but you are not the only one whose needs are analysed. In particular, the global community of network operators also has needs, and those needs are better served by giving you a /32 even if, on the surface of it, the allocation appears too big. 1. We can afford to give every operator a /32, not matter how small. 2. By giving everyone a /32 and encouraging them to announce a single prefix, we reduce the profile of a single network operator to a single entry in the global routing table. There are exceptions of course but that is by far the most common situation. 3. If we gave smaller operators longer prefixes, many of them would come back for additional, non-aggregatable allocations as their business grew. By giving out the /32 to everyone, we minimize the impact on the global routing table of many extra non-aggregatable allocations. --Michael Dillon P.S. You cannot understand IPv6 piecemeal or by comparing IPv4 things to the IPv6 equivalent, because there often is no equivalent in IPv6. Twisting the meaning of things in IPv6 to conform to an IPv4 world view just leads to confusion. Try to understand IPv6 as a holistic system of networking that has a family resemblance to its ancestor, but also incorporates new genetic material. From steve at ibctech.ca Sat Dec 12 19:20:06 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sat, 12 Dec 2009 19:20:06 -0500 Subject: [arin-ppml] Barrier to entry into the IPv6 market Message-ID: <4B243336.4080301@ibctech.ca> I'm not one to speak often, and even though I know this is the wrong list to do it on, here it is. This is off-topic, but it seems things are getting to the point of silly. If I happen to use ALL_CAPS, refer to RFC 2119 for the meaning of the term. My assumption is that pretty well everyone here is, or has been either a network op or engineer. Personally, I've ran an ISP network for eight years, that began as a flat network (when I took it over) into a 'proper' layered network. I follow BCP 38 to the 't', have a complete v4/v6 s/RTBH setup, have more redundant paths for v6 than I do v4, am an open-source proponent, and in general would rather see the best for everyone as opposed to incur costs on them. My experience has also had me operating corporate networks, so I *clearly* understand the difference between the 'enterprise' network and the 'service provider' one. I'm sick of hearing complaining about IPv6. Here are my thoughts. I've ranted before (on NANOG) about how I feel, and I don't do so often. If you are complaining about adopting IPv6, here's what I think: - you are afraid to inform your superiors that there will be a cost involved. To what I say: If you are afraid of what your boss may say, then you are working in a company that has a short-term mentality - you are afraid of IPv6 because it is new and different, To what I say: wake the fsck up. Unless you are considering going back to construction (like I have been doing for fun), you will not last without learning. Besides, didn't you get into this industry so you could expand on what you know? - you know your company just won't invest. To what I say: leave. You are probably in a position where nothing changes anyways. If you like this scenario, then it suits you, but be prepared to have a trade behind you... - it's just too much work. To what I say: Look at this list. There have been people who have provided their own roadmaps to what they have to do to get ready, and that is the most difficult part. Really... all you have to do is search the web, look at already available wikis that provide feedback from people with real world experience, and just do it If you are on this list, you MUST get ready, whether it be for yourself, or the company that you represent. You SHOULD inform your superiors about IPv6 and how important it is. You SHOULD be concerned that if you don't learn about IPv6, that you, and the staff below you will be useless. You SHOULD recall the memo that was sent out on behalf of John Curran by ARIN to all CEOs. If you don't recall that memo, then ask the CEO about IPv6. If you do remember reading that memo, then do something about it. The only barrier to IPv6 entry is you, and the complaints that you can come up with. You can continue to complain about how hard it is, or you can do something. I assure you, as an engineer/op who runs a ~10k user ISP, who has dealt with upstreams that have no v6 plans (and can't change because of political reasons), it is *easy* to make it work. There are frameworks for change available. v6 sits on top of v4. I can personally prove it, as can many others, including people *much* larger that I. Being a giving and open-source type person, I'd rather see all of us make it work. It will only hurt my feelings a little bit when the v6 contractors start raping your company for waiting too long... Steve From michael.dillon at bt.com Sat Dec 12 19:41:45 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 13 Dec 2009 00:41:45 -0000 Subject: [arin-ppml] Barrier to entry into the IPv6 market In-Reply-To: <4B243336.4080301@ibctech.ca> Message-ID: <28E139F46D45AF49A31950F88C497458047BBF9B@E03MVZ2-UKDY.domain1.systemhost.net> > My assumption is that pretty well everyone here is, or has > been either a network op or engineer. Bad assumption. PPML means Public Policy Mailing List. In other words, members of the public who have an interest in ARIN's policies. --Michael Dillon From steve at ibctech.ca Sat Dec 12 19:41:48 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sat, 12 Dec 2009 19:41:48 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <28E139F46D45AF49A31950F88C497458047BBF9A@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458047BBF9A@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B24384C.2030701@ibctech.ca> michael.dillon at bt.com wrote: >> Although I'm not in a position to request PI space, where I >> had a hard time was informing ARIN that a /32 was too much >> for my needs (and I _still_ received it, due to policy). > > That /32 may have been too much for YOUR needs, but you are > not the only one whose needs are analysed. In particular, the > global community of network operators also has needs, and those > needs are better served by giving you a /32 even if, on the > surface of it, the allocation appears too big. > > 1. We can afford to give every operator a /32, not matter > how small. Yes, I know that _now_, but I didn't know then. I looked at my measly /21, threw the /32 into Perl, Googled how many numbers that was, and was blown away. It took me some time to realize that v4 mentality had to go out the window. I was upset when people would express to me "get rid of the v4 thinking", because I was trying to conserve. It takes quite some time building up experience and knowledge to fully understand what those people meant... > 2. By giving everyone a /32 and encouraging them to announce > a single prefix, we reduce the profile of a single network > operator to a single entry in the global routing table. There > are exceptions of course but that is by far the most common > situation. Of course. I truly believe in having a very tight routing table. I am exceptionally fond of Bill Herrin, his ideology, his work, and the effort he has put into RRG and other areas. > 3. If we gave smaller operators longer prefixes, many of them > would come back for additional, non-aggregatable allocations > as their business grew. By giving out the /32 to everyone, we > minimize the impact on the global routing table of many > extra non-aggregatable allocations. Again, agreed. I was pleading with ARIN at the time (iirc, on the telephone) that "oh my God! it's such a waste of space!", but as I said, now I know ;) > P.S. You cannot understand IPv6 piecemeal or by comparing > IPv4 things to the IPv6 equivalent, because there often is > no equivalent in IPv6. Twisting the meaning of things in > IPv6 to conform to an IPv4 world view just leads to confusion. > Try to understand IPv6 as a holistic system of networking > that has a family resemblance to its ancestor, but also > incorporates new genetic material. Indeed. Thanks Michael, Steve From bill at herrin.us Sun Dec 13 22:38:25 2009 From: bill at herrin.us (William Herrin) Date: Sun, 13 Dec 2009 22:38:25 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised In-Reply-To: <4B22FE8A.6090806@umn.edu> References: <4B06D427.1080905@arin.net> <4B22FE8A.6090806@umn.edu> Message-ID: <3c3e3fca0912131938u1f4944d4vfff928a25ddf81d1@mail.gmail.com> On Fri, Dec 11, 2009 at 9:23 PM, David Farmer wrote: > - Needs Basis > > First and probably most important from my personal point of view, I don't > see a needs basis in this policy, even in the classful IPv4 days you had to > demonstrate need to get a Class B, or Class A Hi David, If I recollect my history right (and I wasn't involved before '92 so some of this is going to be fuzzy) nothing approaching a formal needs based evaluation came in to play prior to the early '90's. Basically, the guys who were involved when IPv4 was first deployed got class A's. After that, the gentleman (just one) in charge of keeping the address allocation list had something of a "convince me you need a class A and by the way, you don't" policy but he gave out B's and C's for the asking. As the Internet got bigger and Network Solutions took over address allocation under contract to the USG, allocation of class B's got tightened up. There was an actual form (instead of an informal "I need a class B" email) and if you were requesting more than a class C you had to write a paragraph or two explaining why. I don't know if there was a formal rule but the informal rule was that if you were a college or government entity of any size, or a well known company, a B was yours for the asking. "We are the United States Bureau of the Office" justified as many class B's as you cared to ask for. C's were still the reward for merely submitted a filled-out form, no justification required. Indeed, the "official" policy was we wanted anybody building a TCP/IP network to come and get as many addresses as they thought they needed so that there wouldn't be any grief later when they decided to connect their TCP/IP network with the Internet. That's when I personally became involved, fetching a C at the start of '94 and adding an adjacent C just before Network Solutions handed off IP allocation to ARIN. And I can tell you for certain: the only justification anybody ever asked for was "do you intend to use TCP/IP?" Class-C giveaways finally started to close down as the RIRs came into existence in the mid-90's and ended with ARN's creation around about '97. The point of my ramble is this: needs-based justification wasn't always around. It's something we invented ad-hoc halfway through the game to address the disaggregation and over-consumption problems. As entrenched as it now is in formal policy, "needs-based allocation" is an underlying assumption we never really thought through all the way from the beginning. > - This could encourage the Big Guys to filter the little guys, by maybe > making it to easy for them to do so. > > - As a result, this could encourage the smaller guys to try to get bigger > blocks than they really need in order to justify having a routing slot and > not being filtered. > > Think this threw a little, by making filtering this easy based on size, if > there isn't some kind of needs based justification, and there is a pricing > scheme like described then wouldn't we end up with something like you need > to pay for a /32 for anyone to accept your route as a serious player. ?If > you can't afford $10,000 they go away you have to be my customer. This is no accident. There are multihomed organizations now who can't get usable (i.e. multihomed routable) IPv6 assignment. They have maybe 50 very valuable machines online and half a dozen Internet connections. They need multihoming reliability and $10k/year is nothing and $100k/year is a stretch but doable if it gets them the reliability. Currency is a universal metric. Acting independently, each one of us can equate the worth of behaviors into dollars and back. ISP's can convert the value of accepting routes into dollars. Users can convert the value of multihoming into dollars. It's a mental meeting point that intentionally lacks technical preconditions and as importantly: avoids technical preconceptions. A needs based metric like "200 end-user sites" is comparably _arbitrary_. In strictly traditional scenarios (ISP serving dialups and DSLs) it roughly equates with value but the moment you start talking about server farms instead, the value equation is badly skewed. And it leaves no practical way to value creative, innovative systems which need to consume IP addresses or a routing slot. > - Mergers and Acquisitions > > Getting people to properly report mergers and acquisitions seems hard enough > now. ?Requiring the single block per size per organization, and therefore > renumbering, seems like an additional disincentive to proper reporting. > ?Leading to more bad registry data, less transparency to what is really > going on, and possibly degrading operational response. To my way of thinking, this is adequately handled by ARIN's fraud reporting process. You find an AS announcing multiple same-size registrations and they appear to all be a part of that org's unified internal infrastructure, you report them and ARNI audits. Call it a question of mind over matter: if nobody minds, it doesn't matter. On the other hand, I've been thinking about this and maybe there's a better way to handle it. Allow a registration to be declared "in transition." Once it's in transition, there are no rules against comingling the acquired registrations within your network. But, declaring a registration "in transition" means you're going to renumber out of it. The declaration starts a 24-month countdown clock after which ARIN reclaims the registration no matter what and holds it unregistered for a sufficient period of time to guarantee that it's off the Internet. Of course, you don't have to go that route. You can also keep the acquired network at arms length, don't fold it in to the rest of your network and keep the acquired legal entity for the purpose of holding the registration and its network resources. The proposed policy does not obstruct such behavior. This is one of the intentional release valves that puts pressure on folks to aggregate but doesn't stand in the way of business where the value involved is high enough. > - 6.10.1 Micro-allocations for Critical Infrastructure are not moot and > should be preserved, this allows network operators to create special > filtering rule, if they wish, for these Critical Infrastructures. In all honesty I disagree. On the other hand, maintaining part or all of section 6.10 in parallel with proposal 103 has no down sides that jump out at me. If there's a desire to keep it around until the passage of time proves the issue one way or another, I have no objections. > - These changes are very radical. ?It is at least very difficult, if not > impossible, to predict what the real outcome of these policy changes will > be. I have requested and received access to the bulk whois data from ARIN. Assuming 103 is accepted for formal discussion and debate, I intend to build a simulation using this past data to try to give us a glimpse into the future of both allocation under 103 and under current IPv6 policy as well as an estimate of the impact on the routing table. It won't be perfect but it's at least a few shades better than impossible. Also, let's be honest with ourselves: we face a similar difficulty predicting the outcome of IPv6 policy as it exists today. The devil's in the details and current IPv6 policy is enough different from IPv4 policy that the results of the IPv4 allocation process do not offer a reliable guide. > Are there some incremental steps we can take toward this vision, > without jumping off the cliff into a brave but unknown new world? We could run it in parallel with the current process and let the ISPs decide which one they like better via their filtering policies, but that could create more chaos in a time when we want less. We could restrict the top end of the range with a needs analysis but unless there's at least one level of allocation that we're confident the ISPs won't filter before that kicks in, it would trash the whole function of proposal 103 -- ARIN would once again be the routing table gatekeeper. Besides: if someone wants to pay $100k *per year* for a /24, what's the problem exactly? Other than that, the answer is likely "no." If you accept 103's rationale then the core premise behind today's IPv6 allocation policy is dysfunctional: needs-based justification makes ARIN the gatekeeper to Internet routing policy when it shouldn't be. Like in Millinocket, "you can't get there from here." In order to move forward, we'll first have to identify and back out the practices derived from error. That's what I've attempted with proposal 103. > In the Internet2 world we assigned GigaPOPs /40s out of the Internet2 /32, > it worked well. Especially, in the early day of IPv6, when people still > believed in tighter providers based aggregation for IPv6. ?Think of GigaPOPs > as regional cooperative providers aggregating end-sites into the national > member owned Internet2 backbone. > > This isn't so radical, and if the rest of the world doesn't follow it still > might be a good idea anyway. Not only is that an exceptionally radical suggestion, it was solidly opposed by the participants IRTF Routing Research Group when Heiner Hummel suggested it. You can find a relatively informative iteration of the discussion starting at http://www.ops.ietf.org/lists/rrg/2008/msg01781.html . The problem is the "international member-owned backbone." There can only be one because as soon as you aggregate the traffic into gigapops you lose control over how the packets transit the backbone. During the discussion it was demonstrated that such "geographic aggregation" radically disrupts the economic underpinnings of today's Internet. With geographic aggregation and more than one backbone, theft of service anomalies are unavoidable. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cengel at sponsordirect.com Mon Dec 14 12:03:16 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Mon, 14 Dec 2009 12:03:16 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: Message-ID: Lee Howard wrote: "I'm very skeptical. Stateless NAT46/64 means a 1:1 mapping of addresses, which doesn't help after IPv4 is unavailable. Stateful NAT46 isn't even on the table at IETF yet. Doubtful we'll have a product in time. No equipment vendors say they'll have one-to- many address family translation by EOY 2011" Took me all of about 5 minutes on Google to find this. Haven't dug too deeply into it yet, but it seems to address the sort of issues we'd be facing. http://www.f5.com/products/big-ip/feature-modules/ipv6-gateway.html Again demand for these types of services is going to be big on the corporate end... switching over to IPv6 native is just NOT going to be a good option for most. At the very least, it's going to be a VERY expensive option... which means they are going to be willing to spend significantly on some sort of gateway/translation services so they don't have to do so. Are you trying to tell me that vendors are simply going to ignore all that cash waved in thier faces? I'm sure when the time comes, there will be a plethora of options availble. IETF hasn't done much to address those sort of options because IETF seems to have an allergic reaction to the term NAT.... especialy under IPv6. However an IETF RFC is not a prerequisite for vendors to offer solutions.... that certainly wasn't the case with IPv4 NAT was it? Lee Howard wrote: "As an enterprise network operator, do you support a VPN for remote employees? Once they can't get a global IPv4 address, if they change ISPs they'll either be behind IPv6 or large-scale NAT (i.e., NAT444). Will your VPN work?" Yes, and I don't know. However the general way to address that issue would be to look for a VPN solution that could handle that. You don't redo your entire network infrastructure just to address a single problem issue like that. Again, I don't assume it will be difficult to find a VPN client that can provide connectivity to a IPv6 edge device...once that connectivity is established the remote employee's machine would be getting an IPv4 Private Space Address anyways....the only thing that IPv6 would be needed for would be to establish the tunnel. Christopher Engel From owen at delong.com Mon Dec 14 06:30:33 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 14 Dec 2009 03:30:33 -0800 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised In-Reply-To: <3c3e3fca0912131938u1f4944d4vfff928a25ddf81d1@mail.gmail.com> References: <4B06D427.1080905@arin.net> <4B22FE8A.6090806@umn.edu> <3c3e3fca0912131938u1f4944d4vfff928a25ddf81d1@mail.gmail.com> Message-ID: <693DF10B-E680-4ABB-9532-CA7A8E892B9A@delong.com> On Dec 13, 2009, at 7:38 PM, William Herrin wrote: > On Fri, Dec 11, 2009 at 9:23 PM, David Farmer wrote: >> - Needs Basis >> >> First and probably most important from my personal point of view, I >> don't >> see a needs basis in this policy, even in the classful IPv4 days >> you had to >> demonstrate need to get a Class B, or Class A > > Hi David, > > If I recollect my history right (and I wasn't involved before '92 so > some of this is going to be fuzzy) nothing approaching a formal needs > based evaluation came in to play prior to the early '90's. Basically, > the guys who were involved when IPv4 was first deployed got class A's. > After that, the gentleman (just one) in charge of keeping the address > allocation list had something of a "convince me you need a class A and > by the way, you don't" policy but he gave out B's and C's for the > asking. > No... That was not the case. Even back that far (I've been involved since ~1986), A's were given to large(ish) organizations, not just anyone. There was a time when a C was the minimum allocation unit, and, you could get a C essentially for the asking, but, you always had to have at least some level of justification if you wanted a B or an A. Yes, the bar was raised over time on what that justification was, but, there has always been some level of needs-based. > As the Internet got bigger and Network Solutions took over address > allocation under contract to the USG, allocation of class B's got > tightened up. There was an actual form (instead of an informal "I need > a class B" email) and if you were requesting more than a class C you > had to write a paragraph or two explaining why. I don't know if there > was a formal rule but the informal rule was that if you were a college > or government entity of any size, or a well known company, a B was > yours for the asking. "We are the United States Bureau of the Office" > justified as many class B's as you cared to ask for. > That does not match my recollection, but, I think it has become a popular mythology. Prior to NSI taking over from SRI, SRI pretty much issued on the basis of trusting what was submitted without much verification. NSI tightened that up a bit, and later as they were preparing to split the address management out of domain management, policy started to get even tighter and more formalized. The formation of ARIN marked a major step forward in policy formulation, and, that process has continued to evolve into what we have today. > C's were still the reward for merely submitted a filled-out form, no > justification required. Indeed, the "official" policy was we wanted > anybody building a TCP/IP network to come and get as many addresses as > they thought they needed so that there wouldn't be any grief later > when they decided to connect their TCP/IP network with the Internet. > That remained mostly true up to the point where CIDR started becoming a concern, at which point, policy was tightened up not because of address shortage (which started being an issue just a little later), but, because of AGS/AGS+ memory limitations. > That's when I personally became involved, fetching a C at the start of > '94 and adding an adjacent C just before Network Solutions handed off > IP allocation to ARIN. And I can tell you for certain: the only > justification anybody ever asked for was "do you intend to use > TCP/IP?" > Sure... That was the policy for getting a minimum allocation back then, but, you always needed more than that to get something more than a minimum sized allocation. (True, there was little verification of multiple applications for minimum sized allocations, but, that was largely an oversight due to the fact that at the time, most people couldn' t really see value in asking for more than you needed). > Class-C giveaways finally started to close down as the RIRs came into > existence in the mid-90's and ended with ARN's creation around about > '97. > Not entirely accurate. The class-C giveaway was actually terminated on the altar of CIDR which was purely coincidental in time with the formation of the first RIRs and the transition away from SRI/NSI/SAIC. > The point of my ramble is this: needs-based justification wasn't > always around. It's something we invented ad-hoc halfway through the > game to address the disaggregation and over-consumption problems. As > entrenched as it now is in formal policy, "needs-based allocation" is > an underlying assumption we never really thought through all the way > from the beginning. > Yes it was. To get a minimum allocation, you had to show that you needed some IP addresses. To get more, you needed to show that you needed more, or, you had to submit multiple applications showing that you needed some. Whether or not there was effective enforcement of needs-based, the social contract was always needs-based. Prior to 1990, the internet was a much friendlier more trusting environment. > > This is no accident. There are multihomed organizations now who can't > get usable (i.e. multihomed routable) IPv6 assignment. They have maybe > 50 very valuable machines online and half a dozen Internet > connections. > They need multihoming reliability and $10k/year is nothing and > $100k/year is a stretch but doable if it gets them the reliability. > Um, why can't they get a routable assignment? All such an organization would need in order to get a PI /48 from ARIN is apply and pay the one- time fee and $100/year thereafter. You can convince me that my ARIN-assigned IPv6 /48 isn't routable when I start having trouble reaching IPv6 content I care about. So far, that hasn't been an issue. > Currency is a universal metric. Acting independently, each one of us > can equate the worth of behaviors into dollars and back. ISP's can > convert the value of accepting routes into dollars. Users can convert > the value of multihoming into dollars. It's a mental meeting point > that intentionally lacks technical preconditions and as importantly: > avoids technical preconceptions. > It also ignores the fact that merely thinking something is worth X does not necessarily mean that you can afford to pay X for it because someone else arbitrarily decided that you should. > A needs based metric like "200 end-user sites" is comparably > _arbitrary_. In strictly traditional scenarios (ISP serving dialups > and DSLs) it roughly equates with value but the moment you start > talking about server farms instead, the value equation is badly > skewed. And it leaves no practical way to value creative, innovative > systems which need to consume IP addresses or a routing slot. > Agreed. We need a better needs-based metric. Money is not a good needs-based metric, it is a good greeds-based metric. > To my way of thinking, this is adequately handled by ARIN's fraud > reporting process. You find an AS announcing multiple same-size > registrations and they appear to all be a part of that org's unified > internal infrastructure, you report them and ARNI audits. Call it a > question of mind over matter: if nobody minds, it doesn't matter. > Or, more likely, this simply creates an impetus not to actually merge the entities and continue to operate them as separate business units under common ownership. Thus, no fraud. I don't understand how the community benefits from address policy being used to dictate business models in this manner, however. This policy approach will not reduce the size of the routing table, it will merely create administrative hoops to jump through in structuring the merger to keep the resources separate in the eyes of the policy. > > Of course, you don't have to go that route. You can also keep the > acquired network at arms length, don't fold it in to the rest of your > network and keep the acquired legal entity for the purpose of holding > the registration and its network resources. The proposed policy does > not obstruct such behavior. This is one of the intentional release > valves that puts pressure on folks to aggregate but doesn't stand in > the way of business where the value involved is high enough. > I don't see how it puts pressure to do anything other than work around the system. >> Are there some incremental steps we can take toward this vision, >> without jumping off the cliff into a brave but unknown new world? > > We could run it in parallel with the current process and let the ISPs > decide which one they like better via their filtering policies, but > that could create more chaos in a time when we want less. > This approach to testing radical reform was tested in California in the form of electrical deregulation. Suffice it to say that consumers preferred regulated prices based on the savings promised by the energy producers, and, the energy producers, led by Enron preferred the spot market. The result was that the delivery utilities were caught in a squeeze between regulated (low) sell prices to consumers and unregulated (high) purchase prices from energy producers who have been shown to be more than willing to commit whatever felony was necessary to maximize arbitrage opportunities. I strongly suggest that we not do this to IP addressing, as I live in California and can assure you that electric rates and the economy of the state in general are still hurting from that "test". > We could restrict the top end of the range with a needs analysis but > unless there's at least one level of allocation that we're confident > the ISPs won't filter before that kicks in, it would trash the whole > function of proposal 103 -- ARIN would once again be the routing table > gatekeeper. Besides: if someone wants to pay $100k *per year* for a > /24, what's the problem exactly? > But someone who gets that /24 as an assignment doesn't pay $100k/year. They pay $100/year, just like someone who gets a /32 or a /48 assigment. > Other than that, the answer is likely "no." If you accept 103's > rationale then the core premise behind today's IPv6 allocation policy > is dysfunctional: needs-based justification makes ARIN the gatekeeper > to Internet routing policy when it shouldn't be. Like in Millinocket, > "you can't get there from here." In order to move forward, we'll first > have to identify and back out the practices derived from error. That's > what I've attempted with proposal 103. > Respectfully, I disagree. I think that needs-based is functional without regard to internet routing table gatekeeping being a function of ARIN. Verizon is, at this very moment, proving that needs-based /48s being issued to people does not prevent a provider from filtering them. > > >> In the Internet2 world we assigned GigaPOPs /40s out of the >> Internet2 /32, >> it worked well. Especially, in the early day of IPv6, when people >> still >> believed in tighter providers based aggregation for IPv6. Think of >> GigaPOPs >> as regional cooperative providers aggregating end-sites into the >> national >> member owned Internet2 backbone. >> >> This isn't so radical, and if the rest of the world doesn't follow >> it still >> might be a good idea anyway. > > Not only is that an exceptionally radical suggestion, it was solidly > opposed by the participants IRTF Routing Research Group when Heiner > Hummel suggested it. You can find a relatively informative iteration > of the discussion starting at > http://www.ops.ietf.org/lists/rrg/2008/msg01781.html . > The IETF also solidly opposed the idea of PI IPv6 at all. The IETF is not the canonical source for good operational practice and addressing policy. Further, I don't think David was suggesting that GigaPOPs be the model for traffic distribution, so much as suggesting an alternative address allocation strategy which was, in part, predicated on an understanding of the term "GigaPOP". Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Mon Dec 14 14:07:10 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 14 Dec 2009 11:07:10 -0800 Subject: [arin-ppml] A challenge to the assumption that a big DFZ is a problem Message-ID: <4B268CDE.2080503@ipinc.net> One of the fundamental assumptions that we all seem to accept many times is the "Ballooning BGP table/DFZ" Much policy discussion seems to be centered around the idea that if the DFZ gets bigger it's going to cost bazillions of dollars for every ISP to upgrade equipment, yadda yadda yadda. I have to ask, however, is this assumption really technically accurate? Today I can walk into the store and purchase a PC that has a CPU in it that runs at a clock speed of at least 10 times of most routers, and has at least 10 times the amount of ram, for a quarter of the cost of the annual service contract for most DFZ routers (let alone the hardware cost) Now, I think anyone who studies router hardware would probably agree that the reason routers have historically been so underpowered is that router vendors use older, less expensive, and more tried, technology AND there isn't a NEED for faster tech. Why put a super powerful CPU or ASIC in the router when the purchaser only cares if the router can route at wire speed - and the wires consists of a few DS3's and 10/100 ethernet ports? Older, cheaper tech can do those speeds while not even breaking a sweat. I have to ask, if the PURCHASERS of new router hardware were to tell the router vendors that they aren't gonna bother buying a router that cannot handle a half-million table entries in the BGP table, that the router vendors might just possibly see a need for the faster silicon - and step up to the plate and supply it? God knows they charge enough money for the OLD tech they are supplying now. Anyone heard of Moore's Law? I just have a hard time believing that when I can walk into a pizza place and drop a credit card down for payment - which carries just one of a billion or so possible numbers out there - and get an approval on it in less than a second at the register, that the silicon and software doesn't exist that could handle a DFZ that's an order of magnitude larger than what we have now. Just a random thought.... Ted From scottleibrand at gmail.com Mon Dec 14 14:19:34 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 14 Dec 2009 11:19:34 -0800 Subject: [arin-ppml] A challenge to the assumption that a big DFZ is a problem In-Reply-To: <4B268CDE.2080503@ipinc.net> References: <4B268CDE.2080503@ipinc.net> Message-ID: <4B268FC6.2050806@gmail.com> Ted, Your analysis does apply, to some extent, to the lower end of the router market. However, there are a number of higher-end routers (including pretty much anything that's more than 2U high and has more than a handful of 10G ports) where the limitation is in the custom TCAM used by the FIB. Moore's law definitely applies there, but it's an entirely different architecture than general-purpose CPUs. That said, most newer hardware currently supports about a million IPv4 routes (or 1/4 as many IPv6 routes). For those of us who only have to carry the DFZ table, that means we'll be OK for at least a few more years, and by then Moore's law should result in better faster cheaper replacements to handle the growth. There are, however, networks out there that also inject a whole bunch of internal routes into their table, and they're a lot closer to the edge. My own personal opinion is that we'll be fine as long as prefix growth continues at about the same rate it has recently. But if we make a drastic change that results in a dramatic increase in the growth rate, that could get expensive. -Scot On 12/14/2009 11:07 AM, Ted Mittelstaedt wrote: > > One of the fundamental assumptions that we all seem to accept many > times is the "Ballooning BGP table/DFZ" Much policy discussion > seems to be centered around the idea that if the DFZ gets bigger > it's going to cost bazillions of dollars for every ISP to upgrade > equipment, yadda yadda yadda. > > I have to ask, however, is this assumption really technically > accurate? > > Today I can walk into the store and purchase a PC that has a CPU > in it that runs at a clock speed of at least 10 times of > most routers, and has at least 10 times the amount of ram, for > a quarter of the cost of the annual service contract for most > DFZ routers (let alone the hardware cost) > > Now, I think anyone who studies router hardware would probably > agree that the reason routers have historically been so underpowered > is that router vendors use older, less expensive, and more tried, > technology AND there isn't a NEED for faster tech. Why put a super > powerful CPU or ASIC in the router when the purchaser only cares if > the router can route at wire speed - and the wires consists of a > few DS3's and 10/100 ethernet ports? Older, cheaper tech can do those > speeds while not even breaking a sweat. > > I have to ask, if the PURCHASERS of new router hardware were to tell > the router vendors that they aren't gonna bother buying a router > that cannot handle a half-million table entries in the BGP table, > that the router vendors might just possibly see a need for the > faster silicon - and step up to the plate and supply it? God > knows they charge enough money for the OLD tech they are supplying > now. Anyone heard of Moore's Law? > > I just have a hard time believing that when I can walk into a > pizza place and drop a credit card down for payment - which carries > just one of a billion or so possible numbers out there - and > get an approval on it in less than a second at the register, > that the silicon and software doesn't exist that could handle > a DFZ that's an order of magnitude larger than what we have now. > > Just a random thought.... > > Ted > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From warren at wholesaleinternet.com Mon Dec 14 14:33:04 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Mon, 14 Dec 2009 13:33:04 -0600 Subject: [arin-ppml] A challenge to the assumption that a big DFZ is a problem In-Reply-To: <4B268FC6.2050806@gmail.com> References: <4B268CDE.2080503@ipinc.net> <4B268FC6.2050806@gmail.com> Message-ID: <5D8E63003FDB4C35922C230C50532839@johnsonvhjjf8v> The routing table growing like crazy effectively forces providers to replace critical pieces of hardware or find themselves out of business. There is more to consider besides the cost of the router. There is man power, down-time etc and depending on your particular circumstance, this can be prohibitively expensive. Furthermore, just because router manufacturers can throw in faster hardware doesn't mean they'll do it for free or for incremental increase in cost. I reckon the transition out of v4 to v6 is going to favor those with pockets deep enough to absorb the conversion costs and/or the intermittent transition costs. Consequently, the best thing the world can do to keep the little guys up and going is agree upon policy that minimizes transition cost. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand Sent: Monday, December 14, 2009 1:20 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] A challenge to the assumption that a big DFZ is a problem Ted, Your analysis does apply, to some extent, to the lower end of the router market. However, there are a number of higher-end routers (including pretty much anything that's more than 2U high and has more than a handful of 10G ports) where the limitation is in the custom TCAM used by the FIB. Moore's law definitely applies there, but it's an entirely different architecture than general-purpose CPUs. That said, most newer hardware currently supports about a million IPv4 routes (or 1/4 as many IPv6 routes). For those of us who only have to carry the DFZ table, that means we'll be OK for at least a few more years, and by then Moore's law should result in better faster cheaper replacements to handle the growth. There are, however, networks out there that also inject a whole bunch of internal routes into their table, and they're a lot closer to the edge. My own personal opinion is that we'll be fine as long as prefix growth continues at about the same rate it has recently. But if we make a drastic change that results in a dramatic increase in the growth rate, that could get expensive. -Scot On 12/14/2009 11:07 AM, Ted Mittelstaedt wrote: > > One of the fundamental assumptions that we all seem to accept many > times is the "Ballooning BGP table/DFZ" Much policy discussion seems > to be centered around the idea that if the DFZ gets bigger it's going > to cost bazillions of dollars for every ISP to upgrade equipment, > yadda yadda yadda. > > I have to ask, however, is this assumption really technically > accurate? > > Today I can walk into the store and purchase a PC that has a CPU in it > that runs at a clock speed of at least 10 times of most routers, and > has at least 10 times the amount of ram, for a quarter of the cost of > the annual service contract for most DFZ routers (let alone the > hardware cost) > > Now, I think anyone who studies router hardware would probably agree > that the reason routers have historically been so underpowered is that > router vendors use older, less expensive, and more tried, technology > AND there isn't a NEED for faster tech. Why put a super powerful CPU > or ASIC in the router when the purchaser only cares if the router can > route at wire speed - and the wires consists of a few DS3's and 10/100 > ethernet ports? Older, cheaper tech can do those speeds while not > even breaking a sweat. > > I have to ask, if the PURCHASERS of new router hardware were to tell > the router vendors that they aren't gonna bother buying a router that > cannot handle a half-million table entries in the BGP table, that the > router vendors might just possibly see a need for the faster silicon - > and step up to the plate and supply it? God knows they charge enough > money for the OLD tech they are supplying now. Anyone heard of > Moore's Law? > > I just have a hard time believing that when I can walk into a pizza > place and drop a credit card down for payment - which carries just one > of a billion or so possible numbers out there - and get an approval > on it in less than a second at the register, that the silicon and > software doesn't exist that could handle a DFZ that's an order of > magnitude larger than what we have now. > > Just a random thought.... > > Ted > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From alh-ietf at tndh.net Mon Dec 14 15:05:53 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 14 Dec 2009 12:05:53 -0800 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised In-Reply-To: <3c3e3fca0912131938u1f4944d4vfff928a25ddf81d1@mail.gmail.com> References: <4B06D427.1080905@arin.net> <4B22FE8A.6090806@umn.edu> <3c3e3fca0912131938u1f4944d4vfff928a25ddf81d1@mail.gmail.com> Message-ID: <007201ca7cf8$d74b9970$85e2cc50$@net> Being the person that did the needs based evaluations for the DoE related allocations prior to the RIR formation, your fuzzy description is simply wrong. Routers of the day had tiny memories compared to current devices, and fitting the routing table was a strong consideration. The classful nature of allocation units didn't leave much room for negotiation. When someone needed more than a handful of /24's, it was better to give them a /16 than to blow the routing system. Please don't propagate myths ... Tony > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of William Herrin > Sent: Sunday, December 13, 2009 7:38 PM > To: David Farmer > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > Process - revised > > On Fri, Dec 11, 2009 at 9:23 PM, David Farmer wrote: > > - Needs Basis > > > > First and probably most important from my personal point of view, I > don't > > see a needs basis in this policy, even in the classful IPv4 days you > had to > > demonstrate need to get a Class B, or Class A > > Hi David, > > If I recollect my history right (and I wasn't involved before '92 so > some of this is going to be fuzzy) nothing approaching a formal needs > based evaluation came in to play prior to the early '90's. Basically, > the guys who were involved when IPv4 was first deployed got class A's. > After that, the gentleman (just one) in charge of keeping the address > allocation list had something of a "convince me you need a class A and > by the way, you don't" policy but he gave out B's and C's for the > asking. > > As the Internet got bigger and Network Solutions took over address > allocation under contract to the USG, allocation of class B's got > tightened up. There was an actual form (instead of an informal "I need > a class B" email) and if you were requesting more than a class C you > had to write a paragraph or two explaining why. I don't know if there > was a formal rule but the informal rule was that if you were a college > or government entity of any size, or a well known company, a B was > yours for the asking. "We are the United States Bureau of the Office" > justified as many class B's as you cared to ask for. > > C's were still the reward for merely submitted a filled-out form, no > justification required. Indeed, the "official" policy was we wanted > anybody building a TCP/IP network to come and get as many addresses as > they thought they needed so that there wouldn't be any grief later > when they decided to connect their TCP/IP network with the Internet. > > That's when I personally became involved, fetching a C at the start of > '94 and adding an adjacent C just before Network Solutions handed off > IP allocation to ARIN. And I can tell you for certain: the only > justification anybody ever asked for was "do you intend to use > TCP/IP?" > > Class-C giveaways finally started to close down as the RIRs came into > existence in the mid-90's and ended with ARN's creation around about > '97. > > The point of my ramble is this: needs-based justification wasn't > always around. It's something we invented ad-hoc halfway through the > game to address the disaggregation and over-consumption problems. As > entrenched as it now is in formal policy, "needs-based allocation" is > an underlying assumption we never really thought through all the way > from the beginning. > > > > - This could encourage the Big Guys to filter the little guys, by > maybe > > making it to easy for them to do so. > > > > - As a result, this could encourage the smaller guys to try to get > bigger > > blocks than they really need in order to justify having a routing > slot and > > not being filtered. > > > > Think this threw a little, by making filtering this easy based on > size, if > > there isn't some kind of needs based justification, and there is a > pricing > > scheme like described then wouldn't we end up with something like you > need > > to pay for a /32 for anyone to accept your route as a serious player. > ?If > > you can't afford $10,000 they go away you have to be my customer. > > This is no accident. There are multihomed organizations now who can't > get usable (i.e. multihomed routable) IPv6 assignment. They have maybe > 50 very valuable machines online and half a dozen Internet > connections. > They need multihoming reliability and $10k/year is nothing and > $100k/year is a stretch but doable if it gets them the reliability. > > Currency is a universal metric. Acting independently, each one of us > can equate the worth of behaviors into dollars and back. ISP's can > convert the value of accepting routes into dollars. Users can convert > the value of multihoming into dollars. It's a mental meeting point > that intentionally lacks technical preconditions and as importantly: > avoids technical preconceptions. > > A needs based metric like "200 end-user sites" is comparably > _arbitrary_. In strictly traditional scenarios (ISP serving dialups > and DSLs) it roughly equates with value but the moment you start > talking about server farms instead, the value equation is badly > skewed. And it leaves no practical way to value creative, innovative > systems which need to consume IP addresses or a routing slot. > > > > > - Mergers and Acquisitions > > > > Getting people to properly report mergers and acquisitions seems hard > enough > > now. ?Requiring the single block per size per organization, and > therefore > > renumbering, seems like an additional disincentive to proper > reporting. > > ?Leading to more bad registry data, less transparency to what is > really > > going on, and possibly degrading operational response. > > To my way of thinking, this is adequately handled by ARIN's fraud > reporting process. You find an AS announcing multiple same-size > registrations and they appear to all be a part of that org's unified > internal infrastructure, you report them and ARNI audits. Call it a > question of mind over matter: if nobody minds, it doesn't matter. > > On the other hand, I've been thinking about this and maybe there's a > better way to handle it. Allow a registration to be declared "in > transition." Once it's in transition, there are no rules against > comingling the acquired registrations within your network. But, > declaring a registration "in transition" means you're going to > renumber out of it. The declaration starts a 24-month countdown clock > after which ARIN reclaims the registration no matter what and holds it > unregistered for a sufficient period of time to guarantee that it's > off the Internet. > > Of course, you don't have to go that route. You can also keep the > acquired network at arms length, don't fold it in to the rest of your > network and keep the acquired legal entity for the purpose of holding > the registration and its network resources. The proposed policy does > not obstruct such behavior. This is one of the intentional release > valves that puts pressure on folks to aggregate but doesn't stand in > the way of business where the value involved is high enough. > > > > > - 6.10.1 Micro-allocations for Critical Infrastructure are not moot > and > > should be preserved, this allows network operators to create special > > filtering rule, if they wish, for these Critical Infrastructures. > > In all honesty I disagree. > > On the other hand, maintaining part or all of section 6.10 in parallel > with proposal 103 has no down sides that jump out at me. If there's a > desire to keep it around until the passage of time proves the issue > one way or another, I have no objections. > > > > > - These changes are very radical. ?It is at least very difficult, if > not > > impossible, to predict what the real outcome of these policy changes > will > > be. > > I have requested and received access to the bulk whois data from ARIN. > Assuming 103 is accepted for formal discussion and debate, I intend to > build a simulation using this past data to try to give us a glimpse > into the future of both allocation under 103 and under current IPv6 > policy as well as an estimate of the impact on the routing table. It > won't be perfect but it's at least a few shades better than > impossible. > > Also, let's be honest with ourselves: we face a similar difficulty > predicting the outcome of IPv6 policy as it exists today. The devil's > in the details and current IPv6 policy is enough different from IPv4 > policy that the results of the IPv4 allocation process do not offer a > reliable guide. > > > > Are there some incremental steps we can take toward this vision, > > without jumping off the cliff into a brave but unknown new world? > > We could run it in parallel with the current process and let the ISPs > decide which one they like better via their filtering policies, but > that could create more chaos in a time when we want less. > > We could restrict the top end of the range with a needs analysis but > unless there's at least one level of allocation that we're confident > the ISPs won't filter before that kicks in, it would trash the whole > function of proposal 103 -- ARIN would once again be the routing table > gatekeeper. Besides: if someone wants to pay $100k *per year* for a > /24, what's the problem exactly? > > Other than that, the answer is likely "no." If you accept 103's > rationale then the core premise behind today's IPv6 allocation policy > is dysfunctional: needs-based justification makes ARIN the gatekeeper > to Internet routing policy when it shouldn't be. Like in Millinocket, > "you can't get there from here." In order to move forward, we'll first > have to identify and back out the practices derived from error. That's > what I've attempted with proposal 103. > > > > > In the Internet2 world we assigned GigaPOPs /40s out of the Internet2 > /32, > > it worked well. Especially, in the early day of IPv6, when people > still > > believed in tighter providers based aggregation for IPv6. ?Think of > GigaPOPs > > as regional cooperative providers aggregating end-sites into the > national > > member owned Internet2 backbone. > > > > This isn't so radical, and if the rest of the world doesn't follow it > still > > might be a good idea anyway. > > Not only is that an exceptionally radical suggestion, it was solidly > opposed by the participants IRTF Routing Research Group when Heiner > Hummel suggested it. You can find a relatively informative iteration > of the discussion starting at > http://www.ops.ietf.org/lists/rrg/2008/msg01781.html . > > The problem is the "international member-owned backbone." There can > only be one because as soon as you aggregate the traffic into gigapops > you lose control over how the packets transit the backbone. During > the discussion it was demonstrated that such "geographic aggregation" > radically disrupts the economic underpinnings of today's Internet. > With geographic aggregation and more than one backbone, theft of > service anomalies are unavoidable. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jcurran at arin.net Mon Dec 14 15:43:21 2009 From: jcurran at arin.net (John Curran) Date: Mon, 14 Dec 2009 15:43:21 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised In-Reply-To: <3c3e3fca0912131938u1f4944d4vfff928a25ddf81d1@mail.gmail.com> References: <4B06D427.1080905@arin.net> <4B22FE8A.6090806@umn.edu> <3c3e3fca0912131938u1f4944d4vfff928a25ddf81d1@mail.gmail.com> Message-ID: <8D44A3CF-37A5-443D-9692-164DEF4BCE12@arin.net> On Dec 13, 2009, at 10:38 PM, William Herrin wrote: > > ... > The point of my ramble is this: needs-based justification wasn't > always around. It's something we invented ad-hoc halfway through the > game to address the disaggregation and over-consumption problems. As > entrenched as it now is in formal policy, "needs-based allocation" is > an underlying assumption we never really thought through all the way > from the beginning. Bill - Needs-based allocation wasn't "invented ad-hoc halfway through the game"... (unless claiming the ARPANET as the starting point for the game :-) As early as 1990 (in the classful, pre-web, single-default Internet), you had to explain your initial, 1, 2, and 5 year address needs in order to obtain address space. See the following DDN NIC application template, dated April 1990, for the specifics of question 8 & 9 regarding the allocation policy at that time. Departure from needs-based is certainly possible if warranted by the circumstances and desired by the community, but we should recognize such would be a departure from nearly two decades of existing practice. I'd just like to make sure that the record is straight regarding the allocation policy history in this area. FYI, /John John Curran President and CEO ARIN === [ NETINFO:INTERNET-NUMBER-TEMPLATE.TXT ] [4/90] This form must be completed as part of the application process for obtaining an Internet Protocol (IP) Network Number. To obtain an Internet number, please provide the following information online, via electronic mail, to HOSTMASTER at NIC.DDN.MIL. If electronic mail is not available to you, please mail hardcopy to: DDN Network Information Center SRI International Room EJ210 333 Ravenswood Avenue Menlo Park, CA 94025 1) If the network will be connected to the Internet, you must provide the name of the sponsoring organization, and the name, title, mailing address, phone number, net mailbox, and NIC Handle (if any) of the contact person (POC) at that organization who has authorized the network connection. This person will serve as the POC for administrative and policy questions about authorization to be a part of the Internet. Examples of such sponsoring organizations are: Defense Communications Agency (DCA), Defense Advanced Research Projects Agency (DARPA), the National Science Foundation (NSF), or similar military or government sponsors. ... 8) Estimate the number of hosts that will be on the network: 8a. Initially: 8b. Within one year: 8c. Within two years: 8d. Within five years: 9) Unless a strong and convincing reason is presented, the network (if it qualifies at all) will be assigned a class C network number. If a class C network number is not acceptable for your purposes state why. (Note: If there are plans for more than a few local networks, and more than 100 hosts, you are strongly urged to consider subnetting. [See RFC 950]) From spiffnolee at yahoo.com Mon Dec 14 15:58:45 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Mon, 14 Dec 2009 12:58:45 -0800 (PST) Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: Message-ID: <852584.38638.qm@web63305.mail.re1.yahoo.com> I'm responding to Chris Engel in this message, using his plans for what he'll do after ARIN can't fulfill IPv4 requests. But it's only an example, and the broader points apply to everyone who isn't planning to support IPv6 in 2011-2012. Those points are: * Vendors may not come to your rescue. * Your plan may include more IPv6 than you realize. * In most cases, IPv6 is simpler and cheaper than the alternatives. > > Lee Howard wrote: > > "I'm very skeptical. Stateless NAT46/64 means a 1:1 mapping > > of addresses, which doesn't help after IPv4 is unavailable. Stateful > > NAT46 isn't even on the table at IETF yet. Doubtful we'll have a > > product in time. No equipment vendors say they'll have one-to- > > many address family translation by EOY 2011" > Took me all of about 5 minutes on Google to find this. Haven't dug too > deeply into it yet, but it seems to address the sort of issues we'd be facing. > http://www.f5.com/products/big-ip/feature-modules/ipv6-gateway.html I can't find anything on their website about how they're doing it. It's important; I'll call F5 and ask them. Stateful? Stateless? Works both ways, regardless of where traffic originated? Works for UDP and ICMP? Solves the MTU mismatch problem? > Again demand for these types of services is going to be big on the > corporate end... switching over to IPv6 native is just NOT going to be > a good option for most. At the very least, it's going to be a VERY > expensive option... which means they are going to be willing to spend > significantly on some sort of gateway/translation services so they don't > have to do so. Are you trying to tell me that vendors are simply going to > ignore all that cash waved in thier faces? Why is it less expensive to buy a big NAT box to translate nearly all of your traffic than to migrate to IPv6? > IETF hasn't done much to address those sort of options because IETF > seems to have an allergic reaction to the term NAT.... IETF does whatever the people who participate want done. Many of the people who would implement AFT (Address Family Translation) at your favorite network equipment vendor are working on it at IETF They're already working on it, and don't think they'll have it in time; are you betting your company that somebody else will just make a drop-in product you can buy on your budget? > > "As an enterprise network operator, do you support a VPN for > > remote employees? Once they can't get a global IPv4 address, > > if they change ISPs they'll either be behind IPv6 or large-scale > > NAT (i.e., NAT444). Will your VPN work?" > Yes, and I don't know. However the general way to address that > issue would be to look for a VPN solution that could handle that. > You don't redo your entire network infrastructure just to address > a single problem issue like that. Depends on how important the problem is. But now you've just bought a big NAT64 box, and a new VPN solution. Of course, you still need monitoring and management systems to support those new things. This is all still cheaper than just learning and using IPv6? > Again, I don't assume it will be difficult to find a VPN client that can > provide connectivity to a IPv6 edge device...once that connectivity is > established the remote employee's machine would be getting an IPv4 > Private Space Address anyways....the only thing that IPv6 would be > needed for would be to establish the tunnel. Well, IPSec with AH won't work. It's already broken by NAT. Your VPN concentrator will be IPv4 or IPv6? If it's IPv4, then you have to have a translator in front of it (so you already have at least a data center routing and switching infrastructure running IPv6), and you have to figure out what the IPv4 address it'll translate to (since the IPv4 address of the VPN client is a private IPv4 address, which you don't control and which may have routing conflicts for you). If it's IPv6, then the only thing on the VPN that's not IPv6 is the VPN client host, which just needs an O/S upgrade [1]. Oh, and you still have to figure out the data center routing and switching. And the security and the monitoring and management systems. And train your helpdesk. Geez, why not just do IPv6? I agree that your network is yours to figure out. But everyone needs to spend several dedicated hours writing a project plan for how they will respond to an unavailability of IPv4 from ARIN. Compare different possible strategies, make a good business decision, and implement the plan. Do it this month, because IPv4 runout projections are variable, and the plan you choose may require budget and labor in 2010. Lee [1] to an O/S issued in 2007 or later, which by end of 2011 is pretty minimal; would you even allow something older on your network? Arguably; even WinXP might work, as long as you had a hack to do IPv4 lookups. I understand Windows 7 uses IPSec built into IPv6 by default, so that's a cheap option. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cengel at sponsordirect.com Mon Dec 14 17:36:11 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Mon, 14 Dec 2009 17:36:11 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <852584.38638.qm@web63305.mail.re1.yahoo.com> Message-ID: Lee Howard wrote: "Why is it less expensive to buy a big NAT box to translate nearly all of your traffic than to migrate to IPv6?" Lee, simply having Legal IDENTIFY (let alone find a way to mitigate) all the contractual and compliance issues that might be involved with such a switch would likely exceed the cost of a NAT box significantly....and that's only one small factor involved in making such a switch. "Vendors may not come to your rescue." This is entirely possible. However, there will be a large cash incentive for them to do so. Furthermore, it may not be MY rescue that they need to come to. Who is likely to be more negatively impacted by such a situation... the 1-5% of internet users who MAY initially be on IPv6 only....or the 95+% of the existing IPv4 internet that can communicate with itself just fine??? Believe it or not....I'm alot more aware of the IPv6 situation then the average Enterprise Admin..... and I expect my attitude is not at all atypical. If there aren't some fairly robust solutions available by the time IPv6 hits.... then the problem is going to be alot more wide-reaching then you may think. "In most cases, IPv6 is simpler and cheaper than the alternatives." This statement is impossible even as a generalization as the costs and impacts of IPv6 and it's ramifications vary wildly from Enterprise to Enterprise. Without understanding the specifics of each individual situation and the possible alternatives it is simply not possible to make such statements accurately. "IETF does whatever the people who participate want done. Many of the people who would implement AFT (Address Family Translation) at your favorite network equipment vendor are working on it at IETF They're already working on it, and don't think they'll have it in time; are you betting your company that somebody else will just make a drop-in product you can buy on your budget?" IETF like many institutions (including ARIN) is subject to institutional biases....just mention NAT66 on an IETF mailing list and you'll see what I mean. Heck, I've gotten enough grief for mentioning NAT here on this list....despite the fact that many Administrators find it a valuable tool. Obviously when the time comes when it is necessary to start researching a solution (I'm assuming for the 2011, 2012 or 2013 budget cycles depending on how depletion goes)....if adequate solutions do not exist....then it's time to start considering other options and costs. Right now switching to IPv6 native is pretty far down on the list of options (possibly even below not having connectivity to the IPv6 only portion of the internet initially). "Depends on how important the problem is. But now you've just bought a big NAT64 box, and a new VPN solution. Of course, you still need monitoring and management systems to support those new things. This is all still cheaper than just learning and using IPv6??" Off the top of my head...by many orders of magnitude, yes. I find that taking a gradual approach and layering services on top of existing infrastructure to address specific needs is generally more cost effective then wholesale replacement of entire infrastructure. Of course, this is just a guess on my part....but it's the initial approach I'm going to try to take with the issue. If, through further research, it proves to be impractical, I'll start looking at other options. " But everyone needs to spend several dedicated hours writing a project plan for how they will respond to an unavailability of IPv4 from ARIN. Compare different possible strategies, make a good business decision, and implement the plan. Do it this month, because IPv4 runout projections are variable, and the plan you choose may require budget and labor in 2010." Several hours??? Try a week at least. But the question of WHEN you do it is not that simple. The Leading Edge is also nick-named the "Bleeding Edge" for good reason. If providing IP transport was my core business I would say you were correct....If I was an ISP, I'd certainly be doing it already....however for the Enterprise it's just a means to an end. Problem is that if I start putting together a detailed plan now, I'm working with very limited intel. The options that are available to me now are likely far more limited then those which might exist a year or two from now. There are likely quite a few plans in the works at vendors which have not been made public yet. What I don't want to do is spend weeks on a plan now.... then go back and have to redo all that work over again next year at this time. "to an O/S issued in 2007 or later, which by end of 2011 is pretty minimal; would you even allow something older on your network? " LOL.... you really aren't that familiar with Enterprises are you?? I'm writing this from my Win2K Pro box right now. It's really not THAT uncommon for an Enterprise to have some hw/sw that is 10 years old or more. Right now XP is the standard on the Enterprise....it remains to be seen whether Windows 7 will pickup that mantle or not....and certainly there will be plenty of XP around in the Enterprise by the end of 2011. MS's life-cycle support for it extends out to 2014 or so I understand. Not trying to pick on you Lee.... but try to see things from my side. IPv6 is a huge cost for near ZERO gain from my perspective (other then addressing IPv4 runout). It's undoubted that we'll need connectivity to IPv6 address space at some-point. Obviously the natural inclination to achieve that is with as little disruption/change/cost to the existing infrastructure as possible. From my perspective that would be some sort of IPv4/IPv6 gateway services or proxy or something similar.... ideally deployed at the network perimeter. Obviously if an acceptable solution of that sort doesn't exist... we'll have to start looking for PLAN B. Given the magnitude of what PLAN B might entail.... we're certainly going to try hard to avoid it if possible. If going to IPv6 native was that simple/easy for us....we wouldn't be considering a different alternative first. Christopher Engel From bill at herrin.us Mon Dec 14 18:42:57 2009 From: bill at herrin.us (William Herrin) Date: Mon, 14 Dec 2009 18:42:57 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised In-Reply-To: <693DF10B-E680-4ABB-9532-CA7A8E892B9A@delong.com> References: <4B06D427.1080905@arin.net> <4B22FE8A.6090806@umn.edu> <3c3e3fca0912131938u1f4944d4vfff928a25ddf81d1@mail.gmail.com> <693DF10B-E680-4ABB-9532-CA7A8E892B9A@delong.com> Message-ID: <3c3e3fca0912141542v67227024v8d4a597f91f67526@mail.gmail.com> On Mon, Dec 14, 2009 at 3:43 PM, John Curran wrote: > Needs-based allocation wasn't "invented ad-hoc halfway through the game"... > (unless claiming the ARPANET as the starting point for the game :-) > > As early as 1990 (in the classful, pre-web, single-default Internet), you > had to explain your initial, 1, 2, and 5 year address needs in order to > obtain address space. See the following DDN NIC application template, > dated April 1990, for the specifics of question 8 & 9 regarding the > allocation policy at that time. John, I'll concede that the question was asked in the 1990 template. But as late as 1995 folks requesting fewer than 16 class C's needed only provide a planned subnet and host count. In fact, the instructions on justification from the 7/95 template read: If you are requesting 16 C's or more (/19 prefix) you will need to complete the network topology plan in the format shown on the template. If you are requesting 256 C's or a Class B (/16 prefix) or more, please include a copy of your network diagram. Your organization is strongly encouraged to subnet where feasible. Note the emphasis on subnetting so that you wouldn't consume an entire class C for every LAN segment. That's where the heads were in the game in 1995. That's what we cared about. Unless you were requesting a lot of addresses, deeper questions of "need" were CURSORY. Take a look at the progression of documents: http://bill.herrin.us/network/templates/ Note the change from the '94 to '95 template where describing your network became more than cursory if you wanted a large address block. Then note the dramatic change in language from the '95 template to ARIN's '97 template where needs-based justification had become a major factor overall. Suggesting that needs-based justification predates 1994 is like suggesting that Verizon's history goes back to AT&T's founding or like suggesting that the DNC's history started with Thomas Jefferson. You can trace a line through event points and it makes for a great story. It's spin-doctoring at its finest. In reality, Verizon's history started with Bell Atlantic following the '84 divestiture and the US Democratic Party started as southern reactionaries trading on what little remained of Jefferson's party following the Civil War. Needs-based justification for IP addresses hit solidly between 1995 and 1997, halfway through the game. On the other hand, whether or not you were allowed to connect to the Internet at all was a major issue in the 1990 template. Declare your sponsor remained the number one question until 1994. Since then, justifying your connection to the Internet has been very favorably resolved with a simple: show me the money. Very favorably resolved. So favorably resolved that it makes sense to me to seek structures that use money as the primary arbiter for IP address allocation too. On Mon, Dec 14, 2009 at 6:30 AM, Owen DeLong wrote: >> We could restrict the top end of the range with a needs analysis but >> unless there's at least one level of allocation that we're confident >> the ISPs won't filter before that kicks in, it would trash the whole >> function of proposal 103 -- ARIN would once again be the routing table >> gatekeeper. Besides: if someone wants to pay $100k *per year* for a >> /24, what's the problem exactly? > > But someone who gets that /24 as an assignment doesn't pay $100k/year. > They pay $100/year, just like someone who gets a /32 or a /48 assigment. Owen, Ultimately proposal 103 won't set the fees, but the folks who do set the fees would have to badly misunderstand proposal 103 to set the fees up where the annual repeat is insignificant. Such a fee structure would do little to discourage waste. As suggested in 103's implementation notes, the fee $100k for a /24 is *per year*, not once up front. Hold it for 10 years and you've coughed up seven figures. >> Not only is that an exceptionally radical suggestion, it was solidly >> opposed by the participants IRTF Routing Research Group when Heiner >> Hummel suggested it. You can find a relatively informative iteration >> of the discussion starting at >> http://www.ops.ietf.org/lists/rrg/2008/msg01781.html . > > The IETF also solidly opposed the idea of PI IPv6 at all. ?The IETF is not > the canonical source for good operational practice and addressing policy. You might want to read the referenced discussion before casting aspersions. On Mon, Dec 14, 2009 at 3:05 PM, Tony Hain wrote: > Being the person that did the needs based evaluations for the DoE related > allocations prior to the RIR formation, your fuzzy description is simply > wrong. Routers of the day had tiny memories compared to current devices, and > fitting the routing table was a strong consideration. The classful nature of > allocation units didn't leave much room for negotiation. When someone needed > more than a handful of /24's, it was better to give them a /16 than to blow > the routing system. Tony, Having read 103, I'm sure you realize that I'm conversant with the issues surrounding router memories. I've even owned an AGS and I assure you I'm well aware just how much closer we were to the line back then. Nor am I unaware that conserving routing slots was the driving force behind CIDR with conservation of addresses a distant secondary consideration. I respectfully submit that while not as close to the line, current devices have limited memories as well and as far as the routing table goes, it would still be better to give /16's to anyone who needs more than a handful of /24's. The current allocation structure too strongly favors disaggregation for traffic engineering. Can't do it for IPv4 any more; we're too strongly invested to make big changes. But IPv6 is still largely an open book. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From marty at akamai.com Mon Dec 14 18:50:04 2009 From: marty at akamai.com (Martin Hannigan) Date: Mon, 14 Dec 2009 18:50:04 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process- revised In-Reply-To: <3c3e3fca0912141542v67227024v8d4a597f91f67526@mail.gmail.com> References: <4B06D427.1080905@arin.net> <4B22FE8A.6090806@umn.edu><3c3e3fca0912131938u1f4944d4vfff928a25ddf81d1@mail.gmail.com><693DF10B-E680-4ABB-9532-CA7A8E892B9A@delong.com> <3c3e3fca0912141542v67227024v8d4a597f91f67526@mail.gmail.com> Message-ID: <1BE798EE-65E8-46EC-9A49-B6E8ABB7A34F@akamai.com> On Dec 14, 2009, at 6:42 PM, William Herrin wrote: > On Mon, Dec 14, 2009 at 3:43 PM, John Curran wrote: > > Needs-based allocation wasn't "invented ad-hoc halfway through the > game"... > > (unless claiming the ARPANET as the starting point for the game :-) > > > > As early as 1990 (in the classful, pre-web, single-default > Internet), you > > had to explain your initial, 1, 2, and 5 year address needs in > order to > > obtain address space. See the following DDN NIC application > template, > > dated April 1990, for the specifics of question 8 & 9 regarding the > > allocation policy at that time. > > John, > > I'll concede that the question was asked in the 1990 template. But as > late as 1995 folks requesting fewer than 16 class C's needed only > provide a planned subnet and host count. In fact, the instructions on > justification from the 7/95 template read: > > If you are requesting 16 C's or more (/19 prefix) you > will need to complete the network topology plan in the format > shown on the template. > > If you are requesting 256 C's or a Class B (/16 prefix) or more, > please include a copy of your network diagram. > > Your organization is strongly encouraged to subnet where > feasible. > > Note the emphasis on subnetting so that you wouldn't consume an entire > class C for every LAN segment. That's where the heads were in the game > in 1995. That's what we cared about. Unless you were requesting a lot > of addresses, deeper questions of "need" were CURSORY. > William, You realize that needs were different circa '95 and that the needs then are much different than the needs now hence where the "heads" were then? In Sep 94 there were about 84 web sites total (IIRC), hosting was done by the address routed to the machine typically and RIP was useful. At that time I was answering questions like "what is a proxy" "who is this warez guy!" and "why are people wasting our capacity going to netscape everytime they open their browser?". The needs of yesteryear were much different than the needs of today and needs have always been the driver IMHO. Food for thought. From steve at ibctech.ca Mon Dec 14 20:21:29 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 14 Dec 2009 20:21:29 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: Message-ID: <4B26E499.5000405@ibctech.ca> Chris Engel wrote: [...snip...] > Not trying to pick on you Lee.... but try to see things from my side. IPv6 is a huge cost for near ZERO gain from my perspective (other then addressing IPv4 runout). It's undoubted that we'll need connectivity to IPv6 address space at some-point. Obviously the natural inclination to achieve that is with as little disruption/change/cost to the existing infrastructure as possible. From my perspective that would be some sort of IPv4/IPv6 gateway services or proxy or something similar.... ideally deployed at the network perimeter. Obviously if an acceptable solution of that sort doesn't exist... we'll have to start looking for PLAN B. > Given the magnitude of what PLAN B might entail.... we're certainly going to try hard to avoid it if possible. If going to IPv6 native was that simple/easy for us....we wouldn't be considering a different alternative first. I'm trying to envision the problem from your perspective. I'd like to ask this: What, if anything, would your ISP be able to do to help you at least begin the transition/implementation? Is there anything that an ISP could do differently other than just be 'IPv6 enabled'? Can the ISP community _ease_ its very large enterprise clients into this somehow? If so, what would you ask them to do? Are there any ideas out there regarding how an *SP could aid their enterprise clients with their migration (erm, initial implementation) of IPv6? What about for our most dedicated, long-term clients. Would an ISP be willing to shoulder a bit of the cost in time-spent helping them out? Or is this purely a hardware-upgrade thing? I'm thinking purely from the perspective of having IPv6 ROUTING available. The desktop/server is not what I'm concerned about at this point. I just want to know what can be done differently so that the backbone of the enterprise can communicate via v6, and when the PCs are upgraded, they have a network ready to talk on. Steve From spiffnolee at yahoo.com Mon Dec 14 20:53:26 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Mon, 14 Dec 2009 17:53:26 -0800 (PST) Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: Message-ID: <193942.6708.qm@web63305.mail.re1.yahoo.com> Am I the only one who remembers when email clients let you respond in-line, preserving context? Not just you--none of my mailers do it either. > > "Why is it less expensive to buy a big NAT box to translate nearly all of your traffic than to migrate to IPv6?" > Lee, simply having Legal IDENTIFY (let alone find a way to mitigate) all the > contractual and compliance issues that might be involved with such a switch > would likely exceed the cost of a NAT box significantly....and that's only one > small factor involved in making such a switch. Legal issues with NAT: * If you get a subpeona for records related to an IP address, can you figure out what device used that IP address? * Can the legal requestor provide all of the data required to identify a host? (IP address, timestamp, port number) * The request was based on a server log someplace. Is its timestamp accurate? Is yours? * Does that server log include port numbers? * How long do you have to retain logs, and what kind of logging server do you need? What are the legal issues related to IPv6? > > "Vendors may not come to your rescue." > This is entirely possible. However, there will be a large cash incentive for > them to do so. Furthermore, it may not be MY rescue that they need to come > to. Who is likely to be more negatively impacted by such a situation... the 1-5% > of internet users who MAY initially be on IPv6 only....or the 95+% of the > existing IPv4 internet that can communicate with itself just fine??? Are you sure that none of that 1-5% is important to you? It will increase over time, as nearly 200 million devices per year [1] are added, and as people dual-stack so they can reach all of the Internet. > Believe it or not....I'm alot more aware of the IPv6 situation then the > average Enterprise Admin..... and I expect my attitude is not at all atypical. > If there aren't some fairly robust solutions available by the time IPv6 hits.... > then the problem is going to be alot more wide-reaching then you may think. Yes, I believe it. The problem is not going to be more wide-reaching than I think. I think we will have a fragmented Internet, where you just can't get from some places to others. Several bad things follow from that. > > "In most cases, IPv6 is simpler and cheaper than the alternatives." > This statement is impossible even as a generalization as the costs and > impacts of IPv6 and it's ramifications vary wildly from Enterprise to > Enterprise. Without understanding the specifics of each individual > situation and the possible alternatives it is simply not possible to make > such statements accurately. "most" is accurate. > IETF like many institutions (including ARIN) is subject to institutional > biases....just mention NAT66 on an IETF mailing list and you'll see > what I mean. Heck, I've gotten enough grief for mentioning NAT here > on this list....despite the fact that many Administrators find it a valuable tool. Drafts: http://tools.ietf.org/html/draft-mrw-behave-nat66-02.txt Mailing List: https://www.ietf.org/mailman/listinfo/nat66 Responsible AD: Ralph Droms > Obviously when the time comes when it is necessary to start researching > a solution (I'm assuming for the 2011, 2012 or 2013 budget cycles > depending on how depletion goes)....if adequate solutions do not exist.... > then it's time to start considering other options and costs. Right now > switching to IPv6 native is pretty far down on the list of options (possibly > even below not having connectivity to the IPv6 only portion of the internet initially). When is "when the time comes"? Is it when IANA runs out, or when ARIN refused your address space request, or when your ISP can only give you IPv6 for your new branch office, or when your users, customers, employees or clients can't reach your servers? My point is that now is the time to write your plan, so you know what it will be. If you do so, the odds are high that a gradual dual-stacking of public-facing systems will mean you can wrap IPv6 into planned upgrades, and won't have to buy a NAT box and hurriedly put together a whole edge plan. > > This is all still cheaper than just learning and using IPv6?? > Off the top of my head...by many orders of magnitude, yes. I find that > taking a gradual approach and layering services on top of existing > infrastructure to address specific needs is generally more cost effective > then wholesale replacement of entire infrastructure. That's exactly what I'm advocating. You probably don't need to replace any hardware for IPv6 (you may want to replace something for other reasons, and include IPv6 in your replacement decision). > There are likely quite a few plans in the works at vendors which > have not been made public yet. Probably. But not much about IPv6 is secret. And if it is, they're doing it wrong. > > "to an O/S issued in 2007 or later, which by end of 2011 is pretty > > minimal; would you even allow something older on your network? " > LOL.... you really aren't that familiar with Enterprises are you?? Silly question. Yes, I know quite a bit about the enterprise networks on which I consulted, and on the enterprise network I ran until a year ago. They're aware of IPv6, and making sure their procurement includes IPv6 support (in some cases allowing for a 2010 roadmap, but not for infrastructure). > I'm writing this from my Win2K Pro box right now. Your argument is that in 2011, you will buy an appliance to translate Internet traffic for your 11 year old operating system? > It's really not > THAT uncommon for an Enterprise to have some hw/sw that is 10 > years old or more. The point was about VPN clients, which would be home machines. Surely you're not sending your users home with Win2K on laptops? People VPN from whatever laptop you provide them, or from their home machine [shudder]. Your VPN server isn't ten years old? > Right now XP is the standard on the Enterprise....it remains to be > seen whether Windows 7 will pickup that mantle or not....and > certainly there will be plenty of XP around in the Enterprise by the > end of 2011. MS's life-cycle support for it extends out to 2014 or > so I understand. XP is also the standard in the home, with almost 70% share. But Vista and 7 are 22% and rising fast. http://marketshare.hitslink.com/os-market-share.aspx?qprid=11 > IPv6 is a huge cost for near ZERO gain from my perspective > (other then addressing IPv4 runout). It's undoubted that we'll need > connectivity to IPv6 address space at some-point. That's pretty compelling. If you have to do it anyway, are you sure it's cheaper to do it later than sooner? I'm trying to see your point, but I don't understand what costs you're talking about. It sounds like your plan is to wait until you have a lack of connectivity to something you need (so one of your users is upset), then quickly buy a translator to fix them problem. But since you have to use IPv6 into your data center (colo, server room, whatever) to get the magic box to work, and you have to run IPv6 eventually anyway, why not skip the magic box and plan the migration? Lee [1] http://www.nro.net/documents/presentations/jointstats-sept09.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From bicknell at ufp.org Mon Dec 14 23:08:08 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 14 Dec 2009 20:08:08 -0800 Subject: [arin-ppml] A challenge to the assumption that a big DFZ is a problem In-Reply-To: <4B268CDE.2080503@ipinc.net> References: <4B268CDE.2080503@ipinc.net> Message-ID: <20091215040808.GB33888@ussenterprise.ufp.org> In a message written on Mon, Dec 14, 2009 at 11:07:10AM -0800, Ted Mittelstaedt wrote: > Today I can walk into the store and purchase a PC that has a CPU > in it that runs at a clock speed of at least 10 times of > most routers, and has at least 10 times the amount of ram, for > a quarter of the cost of the annual service contract for most > DFZ routers (let alone the hardware cost) That you're asking this question tells me you don't know how larger routers (GSR, CRS-1, T640, T1600 etc) are architected at all. Please don't take that as an insult either, I suspect only a small fraction of the folks own the list own such routers, and only a much smaller fraction of those understand how they work internally. I'll provide the 10,000 foot view, but beware, that's all it is, there are a LOT of details at work. Let's look at a Juniper T1600. It is a 8 slot box, with each slot capable of 100Gbits/sec, bidirectional. Hint, 8 * 1000 * 2 = 1600. :) So if you're provisioning 10Gbps ethernet, a fairly fast technology today, you can put 160 10GE ports in the router. You don't route 1.6Terabits/sec on a CPU. Or on several CPU's. The "open source router" community (see www.vyatta.com, as an example) suggests you can software route ~3-4Gbps on a very well tuned Nahalem CPU. To route 160 10GE ports would take 480 CPU's at that rate! Even at $500 per CPU, that's 240,000 worth of CPU alone. Not to count all the bus interconnections, DRAM, etc. No, these boxes don't work like that at all. Rather there is a routing engine (Juniper's term), or route processor (Cisco's term) which runs a CPU and does BGP with your neighbors. This is the "old, slow CPU" that you're referring to in those high end boxes. Truth is though, even the "old, slow CPU's" they use could handle several million routes. All they do is run BGP, and create from that a single master copy of the routing table, generally called the FIB, or Forwarding Information Base. The distilled version of the routing table, similar to "show route". The CPU then pushes this table to the linecards, into special memory called TCAM. The tcam holds fields like: 10.0.0.0/8 Linecard3Port2 As packets come in, special hardware looks up the TCAM entry, and then sends the packet out over the switch fabric to the other cards. TCAM is expensive. Why? Well, consider a linecard in your T1600, dealing with a 100G (bidirectional) flow. That's: bits kilobits megabits gigabits speed bidrectional 1000 * 1000 * 1000 * 1000 * 100 * 2 Or 200000000000000 bits/sec. Or divide by 8, 25000000000000 bytes/sec. Now, let's say they are all 64 byte packets. 64 / 25000000000000 = .00000000000256 SECONDS PER PACKET. Let me stack that with 1 nanosecond: .00000000100000 .00000000000256 It's a lookup every 2 picoseconds. This takes arrays of crazy fast TCAM. So long story short, the vendors guess. 1,000,000 routes on the internet distils into an 800,000 route FIB, and size the TCAM for that on each linecard. Note that generally TCAM is not socketed and not field upgradable. Given the speeds it is acutally difficult to socket, and it's very static sensitive for field upgrades. So it's soldered to the board. When the guess, by the vendor or the ISP, turns out to be wrong the upgrade cost is not the "old, slow CPU"; indeed that is often working just fine if only taking 5 minutes to bring up a full table rather than the 2 minutes people would like. Rather it's throw out every linecard and buy new ones. The penalty for guessing wrong is severe, it's instant, total junking of all the linecards on your network. Care to guess what a 10 port 10GE linecard costs for one of these boxes? I'll assume you get some discount from your vendor, so maybe $400,000. So your 8 slot box costs 3.2 million to upgrade. Oh, but the new cards will be more expensive, more TCAM. Got a network with 200 core routers (I can think of some ISP's with more, for sure) and you're "only" talking a 640 million dollar upgrade, for one ISP, just to handle a larger table. Before I go any further, I'm going to tell people up front I'm not going to engage in nit picking over any of the above. If you want to design core routers go work for Junper or Cisco, if you can do it for half the cost of current designs I'm sure they will pay you a nice sum. I'm also sure it can be done both cheaper and more expensively, depending on circumstance. I've picked a run of the mill example, almost every ISP is a special case in something. So anyway, from the big ISP perspective the situation is this: currently deployed hardware is what it is. Unless a multi-hundred million dollar check falls from the sky, it will be what it is until the next, already planned equipment refresh. When it will be what the vendor has already decided the next gen platform will be (you know it takes 3-5 years to develop a next gen platform, on a quick ramp, right?). Also keep in mind some of the TCAM goes to things like MPLS VPN's, which are growing on their own. If these boxes end up exhausting TCAM there will be some upgrades, but the vast majority of ISP's will turn to filtering to solve the problem. Remove enough routes so it fits again; at least until the next refresh cycle. Lastly, I promise you this, the folks at the top 10 ISP's are all meeting with Cisco and Juniper several times a year, with real engineers, not sales folks, and trying to rationalize the cost of the parts with the needs of the network. They provide lots of engineering input on the next generation of parts. However, everyone involved is having to commit now to how big those TCAM's will be in 3 years on the next gen cards, which will be in most of the nextwork in 5-7 years. Hence my statement on the matter. On some level it doesn't matter if the RIR's give away blocks like crazy, or are as stingy as possible. What matters is that the rate at which blocks are given out roughly matches the rate that was expected. We can bend the curve, up or down, but SLOWLY, as equipment is refreshed. There is a wall. It is a 200 foot thick concrete wall. No matter how hard, or soft you hit it the wall will not move, you will be splattered. Fill most core router TCAM's and we're all in for a very bad few years. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From marty at akamai.com Mon Dec 14 23:43:45 2009 From: marty at akamai.com (Martin Hannigan) Date: Mon, 14 Dec 2009 23:43:45 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <193942.6708.qm@web63305.mail.re1.yahoo.com> References: <193942.6708.qm@web63305.mail.re1.yahoo.com> Message-ID: On Dec 14, 2009, at 8:53 PM, Lee Howard wrote: > Am I the only one who remembers when email clients let you respond > in-line, > preserving context? Not just you--none of my mailers do it either. Well, clue? If some of you folks weren't blowing us out with a scrum ton of superfluous "stuff" it wouldn't be a problem. :-) YMMV. > Legal issues with NAT: >* If you get a subpeona for records related to an IP address, can you figure > out what device used that IP address? Yes, it's called deferral. It's legit and it works to all of our benefit. Best Regards, -M< From stephen at sprunk.org Tue Dec 15 00:15:01 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 14 Dec 2009 23:15:01 -0600 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B26E499.5000405@ibctech.ca> References: <4B26E499.5000405@ibctech.ca> Message-ID: <4B271B55.8030504@sprunk.org> Steve Bertrand wrote: > I'm trying to envision the problem from your perspective. I'd like to > ask this: > > What, if anything, would your ISP be able to do to help you at least > begin the transition/implementation? > > Is there anything that an ISP could do differently other than just be > 'IPv6 enabled'? That is a necessary first step. It's hard for an ISP to convince their customers to enable IPv6 when most ISPs won't even sell them IPv6 connectivity or, if they sell it, can't actually deliver it. After that? Enable IPv6 on every customer circuit and assign every customer an IPv6 PA prefix, without waiting for them to ask for one. If they have a PI prefix in v4, send them directions on how to get one in v6. IMHO, that is where the ISP's responsibility ends when it comes to corporate customers. If the customers want to be stupid and not do anything with it, that's their choice. Of course, if the ISP had a consulting practice, IPv6 readiness would be a great service offering, but I wouldn't count on too many customers buying it. A much more important step for ISPs is getting the _eyeballs_ on v6, whether native, 6to4, or Teredo. There are hundreds of millions of home and SOHO users out there that need no more than a CPE software update to get on v6. Realistically, how are you going to convince _anyone_ that they need to v6-enable their content when none of the eyeballs can do v6? OTOH, how much convincing will you need to do when market stats show 90%+ of eyeballs have v6? > Or is this purely a hardware-upgrade thing? > Only the most obvious part is hardware; the network is a _tiny_ part of an enterprise's problems. As Chris pointed out, there's a lot of old OSes out there. Win2k? Heck, I know places that are still running Win95/98/NT4, OS/2, NetWare, etc. Just getting all the OSes upgraded to something that can do IPv6 will be a multi-year project in some places. Next, after the OSes are up to date, you have to go through every single software package used anywhere in the entire company (officially or not), checking whether or not it can handle v6--and what features silently stop working (a _serious_ problem). This may mean an upgrade to a newer version, with all the attendant testing, documentation, change management, training, etc. Maybe the vendor has gone out of business, doesn't sell that product anymore, doesn't have a v6-capable version yet, or wants outrageous fees for the upgrade. Maybe you have to find an entirely new product or rewrite some in-house custom app--if you even still have the source code for it. Now repeat that several hundred (or thousand) times. Consider that it took the better part of a decade for enterprises to switch from SNA, IPX, AppleTalk, Vines, XNS, DECnet, etc. to IPv4--and all they had running on their networks back then were file and print sharing and some dumb terminal emulators. The problem is orders of magnitude worse now. Realistically, the only way the "transition" is going to happen is to convince them to buy new firewalls that can do NAT64 and let them continue on in their RFC1918-isolated bliss. And, really, as long as their v4-only internal and DMZ hosts can talk to the v6 Internet somehow, isn't that good enough for now? You do not need to look behind the curtain, Dorothy. > I'm thinking purely from the perspective of having IPv6 ROUTING > available. The desktop/server is not what I'm concerned about at this > point. I just want to know what can be done differently so that the > backbone of the enterprise can communicate via v6, and when the PCs are > upgraded, they have a network ready to talk on. > Solving the easiest part of the problem and calling it a day doesn't do much good. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From michel at arneill-py.sacramento.ca.us Tue Dec 15 01:02:03 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 14 Dec 2009 22:02:03 -0800 Subject: [arin-ppml] A challenge to the assumption that a big DFZ is aproblem In-Reply-To: <20091215040808.GB33888@ussenterprise.ufp.org> References: <4B268CDE.2080503@ipinc.net> <20091215040808.GB33888@ussenterprise.ufp.org> Message-ID: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> > Ted Mittelstaedt wrote: > Today I can walk into the store and purchase a PC that has a CPU > in it that runs at a clock speed of at least 10 times of > most routers, and has at least 10 times the amount of ram, for > a quarter of the cost of the annual service contract for most > DFZ routers (let alone the hardware cost) I'm sorry, but you have no idea how a core router actually works. I will try to make a comparison with a device that you may actually have seen. In my laptop bag, I carry this switch: http://www.netgear.com/Products/Switches/AdvancedSmartSwitches/GS108T.as px It's a $100 device, 8W power. It's my sniffing switch. I picked it because it has port monitoring and other features such as ACLs. You can't even build a PC that does this today. Toss anything you want in the box: DDR3 1066, Dual quad-core, 2x quad GigE (or 4x dual GigE) NICs, 16x PCIExpress cards if you like, any way you do it you have a 800W $4,000 large box that won't remotely do what the smallest commodity consumer $100 product does. As of today, no PC will do 16 Gbps forwarding with ACLs or port monitoring. The difference is: the switch does it in HARDWARE. I don't know what kind of CPU there is in that specific unit, but it's in the same class as a web-enabled refrigerator. A DFZ router is the same, except that the problem is 1000 times worse: not only there is BGP to deal with (instead of a simple MAC address match), but a large router can have hundreds of ports as well. There is a reason why Cisco and Juniper still sell these multi-million dollar routers. They work (mostly). If someone had found a way to replace a CRS-1 or a T1600 with a PC, Cisco and Juniper would be out of business. Please, I understand this is a public mailing list but these sci-fi theories about having a PC than can't even emulate a $100 switch replace a core router, give me a break. Michel. From bill at herrin.us Tue Dec 15 01:08:20 2009 From: bill at herrin.us (William Herrin) Date: Tue, 15 Dec 2009 01:08:20 -0500 Subject: [arin-ppml] A challenge to the assumption that a big DFZ is a problem In-Reply-To: <4B268CDE.2080503@ipinc.net> References: <4B268CDE.2080503@ipinc.net> Message-ID: <3c3e3fca0912142208k79b52054mf08339a8b47642a3@mail.gmail.com> On Mon, Dec 14, 2009 at 2:07 PM, Ted Mittelstaedt wrote: > One of the fundamental assumptions that we all seem to accept many > times is the "Ballooning BGP table/DFZ" ?Much policy discussion > seems to be centered around the idea that if the DFZ gets bigger > it's going to cost bazillions of dollars for every ISP to upgrade > equipment, yadda yadda yadda. > > I have to ask, however, is this assumption really technically > accurate? Ted, As the DFZ gets bigger it will cost every ISP bazillions of dollars to upgrade equipment. It isn't a question of "if." Exactly how many bazillions depends on how fast the DFZ grows. At current growth rates, few of the 200,000 or so deployed DFZ routers will be usable in any DFZ application in 4 years time. Not even the ones that cost half a million or more. There's also an upper limit somewhere. We nearly hit it in the late '90s but the routing table we're capable of building routers to handle has been growing at about 40% per year since then while the actual routing table has only been growing around 25% per year. This has dramatically reduced the cost of low-end BGP routers (like the Cisco 2800 series) while allowing the high end router costs to stay relatively steady despite the rapidly increasing packets per second capacity. The technical short short version is: Routing protocols and the code which processes them are single-threaded while nearly all recent advances in processing speed are in parallel processing, so growth beyond a certain point will require radical software changes. The packet forwarding process (FIB) in high-end routers is governed by custom hardware (such as TCAMs) which are expensive to build and whose cost varies linearly with the size of the routing table. Opex too -- TCAMs are very power hungry. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Keegan.Holley at sungard.com Tue Dec 15 01:21:46 2009 From: Keegan.Holley at sungard.com (Keegan.Holley at sungard.com) Date: Tue, 15 Dec 2009 01:21:46 -0500 Subject: [arin-ppml] A challenge to the assumption that a big DFZ is a problem In-Reply-To: <20091215040808.GB33888@ussenterprise.ufp.org> References: <4B268CDE.2080503@ipinc.net> <20091215040808.GB33888@ussenterprise.ufp.org> Message-ID: Maybe I'm just that nerdy but I'm slightly offended by the assertion that so few people own routers with RE/RP's and a little TCAM. ;) From: Leo Bicknell To: Ted Mittelstaedt Cc: arin-ppml at arin.net Date: 12/14/2009 11:09 PM Subject: Re: [arin-ppml] A challenge to the assumption that a big DFZ is a problem Sent by: In a message written on Mon, Dec 14, 2009 at 11:07:10AM -0800, Ted Mittelstaedt wrote: > Today I can walk into the store and purchase a PC that has a CPU > in it that runs at a clock speed of at least 10 times of > most routers, and has at least 10 times the amount of ram, for > a quarter of the cost of the annual service contract for most > DFZ routers (let alone the hardware cost) That you're asking this question tells me you don't know how larger routers (GSR, CRS-1, T640, T1600 etc) are architected at all. Please don't take that as an insult either, I suspect only a small fraction of the folks own the list own such routers, and only a much smaller fraction of those understand how they work internally. I'll provide the 10,000 foot view, but beware, that's all it is, there are a LOT of details at work. Let's look at a Juniper T1600. It is a 8 slot box, with each slot capable of 100Gbits/sec, bidirectional. Hint, 8 * 1000 * 2 = 1600. :) So if you're provisioning 10Gbps ethernet, a fairly fast technology today, you can put 160 10GE ports in the router. You don't route 1.6Terabits/sec on a CPU. Or on several CPU's. The "open source router" community (see www.vyatta.com, as an example) suggests you can software route ~3-4Gbps on a very well tuned Nahalem CPU. To route 160 10GE ports would take 480 CPU's at that rate! Even at $500 per CPU, that's 240,000 worth of CPU alone. Not to count all the bus interconnections, DRAM, etc. No, these boxes don't work like that at all. Rather there is a routing engine (Juniper's term), or route processor (Cisco's term) which runs a CPU and does BGP with your neighbors. This is the "old, slow CPU" that you're referring to in those high end boxes. Truth is though, even the "old, slow CPU's" they use could handle several million routes. All they do is run BGP, and create from that a single master copy of the routing table, generally called the FIB, or Forwarding Information Base. The distilled version of the routing table, similar to "show route". The CPU then pushes this table to the linecards, into special memory called TCAM. The tcam holds fields like: 10.0.0.0/8 Linecard3Port2 As packets come in, special hardware looks up the TCAM entry, and then sends the packet out over the switch fabric to the other cards. TCAM is expensive. Why? Well, consider a linecard in your T1600, dealing with a 100G (bidirectional) flow. That's: bits kilobits megabits gigabits speed bidrectional 1000 * 1000 * 1000 * 1000 * 100 * 2 Or 200000000000000 bits/sec. Or divide by 8, 25000000000000 bytes/sec. Now, let's say they are all 64 byte packets. 64 / 25000000000000 = .00000000000256 SECONDS PER PACKET. Let me stack that with 1 nanosecond: .00000000100000 .00000000000256 It's a lookup every 2 picoseconds. This takes arrays of crazy fast TCAM. So long story short, the vendors guess. 1,000,000 routes on the internet distils into an 800,000 route FIB, and size the TCAM for that on each linecard. Note that generally TCAM is not socketed and not field upgradable. Given the speeds it is acutally difficult to socket, and it's very static sensitive for field upgrades. So it's soldered to the board. When the guess, by the vendor or the ISP, turns out to be wrong the upgrade cost is not the "old, slow CPU"; indeed that is often working just fine if only taking 5 minutes to bring up a full table rather than the 2 minutes people would like. Rather it's throw out every linecard and buy new ones. The penalty for guessing wrong is severe, it's instant, total junking of all the linecards on your network. Care to guess what a 10 port 10GE linecard costs for one of these boxes? I'll assume you get some discount from your vendor, so maybe $400,000. So your 8 slot box costs 3.2 million to upgrade. Oh, but the new cards will be more expensive, more TCAM. Got a network with 200 core routers (I can think of some ISP's with more, for sure) and you're "only" talking a 640 million dollar upgrade, for one ISP, just to handle a larger table. Before I go any further, I'm going to tell people up front I'm not going to engage in nit picking over any of the above. If you want to design core routers go work for Junper or Cisco, if you can do it for half the cost of current designs I'm sure they will pay you a nice sum. I'm also sure it can be done both cheaper and more expensively, depending on circumstance. I've picked a run of the mill example, almost every ISP is a special case in something. So anyway, from the big ISP perspective the situation is this: currently deployed hardware is what it is. Unless a multi-hundred million dollar check falls from the sky, it will be what it is until the next, already planned equipment refresh. When it will be what the vendor has already decided the next gen platform will be (you know it takes 3-5 years to develop a next gen platform, on a quick ramp, right?). Also keep in mind some of the TCAM goes to things like MPLS VPN's, which are growing on their own. If these boxes end up exhausting TCAM there will be some upgrades, but the vast majority of ISP's will turn to filtering to solve the problem. Remove enough routes so it fits again; at least until the next refresh cycle. Lastly, I promise you this, the folks at the top 10 ISP's are all meeting with Cisco and Juniper several times a year, with real engineers, not sales folks, and trying to rationalize the cost of the parts with the needs of the network. They provide lots of engineering input on the next generation of parts. However, everyone involved is having to commit now to how big those TCAM's will be in 3 years on the next gen cards, which will be in most of the nextwork in 5-7 years. Hence my statement on the matter. On some level it doesn't matter if the RIR's give away blocks like crazy, or are as stingy as possible. What matters is that the rate at which blocks are given out roughly matches the rate that was expected. We can bend the curve, up or down, but SLOWLY, as equipment is refreshed. There is a wall. It is a 200 foot thick concrete wall. No matter how hard, or soft you hit it the wall will not move, you will be splattered. Fill most core router TCAM's and we're all in for a very bad few years. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ [attachment "attxedn9.dat" deleted by Keegan Holley/SAS/SunGard] _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Dec 15 01:36:21 2009 From: bill at herrin.us (William Herrin) Date: Tue, 15 Dec 2009 01:36:21 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process- revised In-Reply-To: <1BE798EE-65E8-46EC-9A49-B6E8ABB7A34F@akamai.com> References: <4B06D427.1080905@arin.net> <4B22FE8A.6090806@umn.edu> <3c3e3fca0912131938u1f4944d4vfff928a25ddf81d1@mail.gmail.com> <693DF10B-E680-4ABB-9532-CA7A8E892B9A@delong.com> <3c3e3fca0912141542v67227024v8d4a597f91f67526@mail.gmail.com> <1BE798EE-65E8-46EC-9A49-B6E8ABB7A34F@akamai.com> Message-ID: <3c3e3fca0912142236l5ea57331u89c62e53783488a0@mail.gmail.com> On Mon, Dec 14, 2009 at 6:50 PM, Martin Hannigan wrote: > On Dec 14, 2009, at 6:42 PM, William Herrin wrote: >> Note the emphasis on subnetting so that you wouldn't consume an entire >> class C for every LAN segment. That's where the heads were in the game >> in 1995. That's what we cared about. Unless you were requesting a lot >> of addresses, deeper questions of "need" were CURSORY. > You realize that needs were different circa '95 and that the needs then are > much different than the needs now hence where the "heads" were then? In Sep > 94 there were about 84 web sites total (IIRC), hosting was done by the > address routed to the machine typically and RIP was useful. At that time I > was answering questions like "what is a proxy" "who is this warez guy!" and > "why are people wasting our capacity going to netscape everytime they open > their browser?". The needs of yesteryear were much different than the needs > of today and needs have always been the driver IMHO. Martin, I agree with everything you just said. Where does that leave us? The whole IPv6 PA-everywhere idea that came out of the IETF has enough glaring technical deficiencies that it won't fly. Is CIDR and the needs-based justification we've employed for the last 12 to 14 years the best answer there is? Or have we learned enough about routing and addressing in the last decade to come up with a better answer for the relatively clean slate afforded by IPv6? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From warren at wholesaleinternet.com Tue Dec 15 09:54:25 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Tue, 15 Dec 2009 08:54:25 -0600 Subject: [arin-ppml] A challenge to the assumption that a big DFZ isaproblem In-Reply-To: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> References: <4B268CDE.2080503@ipinc.net><20091215040808.GB33888@ussenterprise.ufp.org> <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> Message-ID: <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> Is it just me or do half the messages that are meant to clarify people's conception about a particular subject (IP allocations, router hardware etc) often end in patronizing tones and snarky remarks? Please, I understand this is a public mailing list but these sci-fi theories about having a PC than can't even emulate a $100 switch replace a core router, give me a break. Michel. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michel Py From jlewis at lewis.org Tue Dec 15 11:03:59 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 15 Dec 2009 11:03:59 -0500 (EST) Subject: [arin-ppml] A challenge to the assumption that a big DFZ is a problem In-Reply-To: <4B268CDE.2080503@ipinc.net> References: <4B268CDE.2080503@ipinc.net> Message-ID: On Mon, 14 Dec 2009, Ted Mittelstaedt wrote: > One of the fundamental assumptions that we all seem to accept many > times is the "Ballooning BGP table/DFZ" Much policy discussion > seems to be centered around the idea that if the DFZ gets bigger > it's going to cost bazillions of dollars for every ISP to upgrade > equipment, yadda yadda yadda. > > I have to ask, however, is this assumption really technically > accurate? ... > I have to ask, if the PURCHASERS of new router hardware were to tell > the router vendors that they aren't gonna bother buying a router > that cannot handle a half-million table entries in the BGP table, > that the router vendors might just possibly see a need for the > faster silicon - and step up to the plate and supply it? God > knows they charge enough money for the OLD tech they are supplying > now. Anyone heard of Moore's Law? This has at least to some degreee been addressed. Cisco, for example, now makes a bunch of "CPE level" routers that can take large amounts of RAM. The issue though, is the large installed base of routers and switches carrying traffic for all the service provider networks. As the DFZ grows, routers that were doing just fine traffic capacitywise will require either processor board upgrades (NPE, Sup, etc.), forklift upgrades, or filters to get by. That I can buy an inexpensive PC with quad core processors and several GB of RAM doesn't do me much good if my BGP is being done on large but aging cisco gear running out of whatever non-upgradable resources are used to hold the routing table. That a good deal of the DFZ "growth" is actually just bloat caused by sloppiness or cluelessness is particularly annoying. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From owen at delong.com Tue Dec 15 13:36:23 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Dec 2009 10:36:23 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <4B271B55.8030504@sprunk.org> References: <4B26E499.5000405@ibctech.ca> <4B271B55.8030504@sprunk.org> Message-ID: On Dec 14, 2009, at 9:15 PM, Stephen Sprunk wrote: > Steve Bertrand wrote: >> I'm trying to envision the problem from your perspective. I'd like to >> ask this: >> >> What, if anything, would your ISP be able to do to help you at least >> begin the transition/implementation? >> >> Is there anything that an ISP could do differently other than just be >> 'IPv6 enabled'? > > That is a necessary first step. It's hard for an ISP to convince > their > customers to enable IPv6 when most ISPs won't even sell them IPv6 > connectivity or, if they sell it, can't actually deliver it. > > After that? Enable IPv6 on every customer circuit and assign every > customer an IPv6 PA prefix, without waiting for them to ask for > one. If > they have a PI prefix in v4, send them directions on how to get one > in v6. > Bad idea... Notify them that the PA prefix is available for the asking: good. Assign it whether they want it or not: bad. The latter will simply lead to cruft in the database and other issues. > > A much more important step for ISPs is getting the _eyeballs_ on v6, > whether native, 6to4, or Teredo. There are hundreds of millions of > home > and SOHO users out there that need no more than a CPE software > update to > get on v6. Realistically, how are you going to convince _anyone_ that > they need to v6-enable their content when none of the eyeballs can do > v6? OTOH, how much convincing will you need to do when market stats > show 90%+ of eyeballs have v6? > Because in 3 years, none of the new eyeballs will be able to do anything but IPv6? Getting the content providers dual-stacked is far more critical than getting the eyeballs moved forward. If the content is dual- stacked, then, the eyeballs will follow fairly automatically in a few years, or, when they start to care about content that is IPv6 only. Either way, that's a much easier problem (albeit larger in scope) to solve. > > As Chris pointed out, there's a lot of old OSes out there. Win2k? > Heck, I know places that are still running Win95/98/NT4, OS/2, > NetWare, > etc. Just getting all the OSes upgraded to something that can do IPv6 > will be a multi-year project in some places. > OTOH, do those hosts running 95/98/NT4 or OS/2, etc. actually matter about getting dual-stacked? Do they actually access the internet? Chances are not much or they wouldn't still be functional since there are relatively well known and widely exploited holes available after end-of-life for security updates in most cases. > Next, after the OSes are up to date, you have to go through every > single > software package used anywhere in the entire company (officially or > not), checking whether or not it can handle v6--and what features > silently stop working (a _serious_ problem). This may mean an upgrade Only if you're turning off IPv4. In general, if the software can't handle IPv6, it doesn't break just because you add IPv6 to the box. I suppose there's a small chance that an application could be coded so badly that it somehow does, but, it's hard to fathom how. > to a newer version, with all the attendant testing, documentation, > change management, training, etc. Maybe the vendor has gone out of > business, doesn't sell that product anymore, doesn't have a v6-capable > version yet, or wants outrageous fees for the upgrade. Maybe you have > to find an entirely new product or rewrite some in-house custom app-- > if > you even still have the source code for it. Now repeat that several > hundred (or thousand) times. > For getting the application to run on IPv6 in order to be able to turn off IPv4, sure. Outside of that, not so much. > Consider that it took the better part of a decade for enterprises to > switch from SNA, IPX, AppleTalk, Vines, XNS, DECnet, etc. to IPv4--and > all they had running on their networks back then were file and print > sharing and some dumb terminal emulators. The problem is orders of > magnitude worse now. > Yes and no. > Realistically, the only way the "transition" is going to happen is to > convince them to buy new firewalls that can do NAT64 and let them > continue on in their RFC1918-isolated bliss. And, really, as long as > their v4-only internal and DMZ hosts can talk to the v6 Internet > somehow, isn't that good enough for now? You do not need to look > behind > the curtain, Dorothy. > There's two different transitions being discussed here, and, we need to be more accurate about how we talk about them. I think much of the enterprise resistance stems from the misuse of the words transition or migration to describe the first step. The first step is dual-stacking. Dual- stacking should be relatively painless and should not require a great deal of application testing, etc. Yes, removal of IPv4 will be painful and take time. The good news is that the first test cases for that will be new hosts after IPv4 addresses are no longer available with the possibility of using IPv4 NAT as a fallback to back-stop that issue initially while the native IPv6 issues are resolved. Once the IPv6-only new hosts are working fine without needing IPv4, then, we can look at removing IPv4 from the remaining dual-stack hosts and finally the network infrastructure. So, let's focus on getting existing services dual-stacked, then worry about the next steps. >> I'm thinking purely from the perspective of having IPv6 ROUTING >> available. The desktop/server is not what I'm concerned about at this >> point. I just want to know what can be done differently so that the >> backbone of the enterprise can communicate via v6, and when the PCs >> are >> upgraded, they have a network ready to talk on. >> > > Solving the easiest part of the problem and calling it a day doesn't > do > much good. > Yes and no. Solving that part of the problem does a lot of good. Calling it a day when you get to that point, however, is problematic. It's a good and necessary first step. The equally necessary next step is to get existing services dual- stacked. Dual-stacking desktops can come MUCH later and be done on a much more piecemeal basis. So, the good news is that the hardest part of the problem is easily left for last and can be done in small bites over a much longer time horizon. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From trejrco at gmail.com Tue Dec 15 14:58:20 2009 From: trejrco at gmail.com (TJ) Date: Tue, 15 Dec 2009 14:58:20 -0500 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: References: <4B26E499.5000405@ibctech.ca> <4B271B55.8030504@sprunk.org> Message-ID: <025001ca7dc0$f5d1a330$e174e990$@com> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf > Of Owen DeLong > Realistically, the only way the "transition" is going to happen is to convince > them to buy new firewalls that can do NAT64 and let them continue on in their > RFC1918-isolated bliss. ?And, really, as long as their v4-only internal and > DMZ hosts can talk to the v6 Internet somehow, isn't that good enough for now? > ?You do not need to look behind the curtain, Dorothy. > There's two different transitions being discussed here, and, we need to be > more accurate about how we talk about them. ?I think much of the enterprise > resistance stems from the misuse of the words transition or migration to > describe the first step. ?The first step is dual-stacking. ?Dual-stacking > should be relatively painless and should not require a great deal of > application testing, etc. Yes, removal of IPv4 will be painful and take time. > ?The good news is that the first test cases for that will be new hosts after > IPv4 addresses are no longer available with the possibility of using IPv4 NAT > as a fallback to back-stop that issue initially while the native > IPv6 issues are resolved. ?Once the IPv6-only new hosts are working fine > without needing IPv4, then, we can look at removing IPv4 from the remaining > dual-stack hosts and finally the network infrastructure. > > So, let's focus on getting existing services dual-stacked, then worry about > the next steps. ++1. Transition is a poorly chosen term, perhaps with hindsight that is easier to say than without. /TJ From tedm at ipinc.net Tue Dec 15 15:22:46 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 15 Dec 2009 12:22:46 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <193942.6708.qm@web63305.mail.re1.yahoo.com> References: <193942.6708.qm@web63305.mail.re1.yahoo.com> Message-ID: <4B27F016.8020606@ipinc.net> Lee Howard wrote: > > Legal issues with NAT: > * If you get a subpeona for records related to an IP address, can you > figure > out what device used that IP address? > * Can the legal requestor provide all of the data required to identify a > host? > (IP address, timestamp, port number) Among the smaller consumer routers, this capability is iffy. Some of them (Linksys BEFSR41 or RV042 for example) don't even let you see the translation table at all from any interface. Others, (linksys RVS4000, or openwrt/ddwrt) have a IP Connectrack button that lets you see the translation table - but to get any long-term history you would have to run Netflow (stuff running dd-wrt allows this, but none of the small consumer routers do) and log it. Even the commercial firewalls, Cisco PIX and ASA, would require an external logging server. And while I've seen lots of companies with firewalls like that in service - most of them don't bother setting up the logging server. The biggest problem with NAT though is that you have a device - the NAT device - which is easily attackable from the inside. All it takes is one customer to get infected with a bot and POW the NAT gets overloaded and every customer you have dependent on it, goes offline. This is even if the NAT isn't being targeted. > * The request was based on a server log someplace. Is its timestamp > accurate? Is yours? ntp on the logging server and the translator > * Does that server log include port numbers? Netflow does. But not many smaller and medium sized companies run it, or if they do run it they run a collector that doesn't save over the long term. Ted From owen at delong.com Tue Dec 15 15:44:01 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Dec 2009 12:44:01 -0800 Subject: [arin-ppml] The non-deployment of IPv6 In-Reply-To: <025001ca7dc0$f5d1a330$e174e990$@com> References: <4B26E499.5000405@ibctech.ca> <4B271B55.8030504@sprunk.org> <025001ca7dc0$f5d1a330$e174e990$@com> Message-ID: <059DA5C2-6F50-46AA-B167-6EC08E5A2510@delong.com> On Dec 15, 2009, at 11:58 AM, TJ wrote: >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- >> bounces at arin.net] On > Behalf >> Of Owen DeLong > >> Realistically, the only way the "transition" is going to happen is to > convince >> them to buy new firewalls that can do NAT64 and let them continue >> on in > their >> RFC1918-isolated bliss. And, really, as long as their v4-only >> internal > and >> DMZ hosts can talk to the v6 Internet somehow, isn't that good >> enough for > now? >> You do not need to look behind the curtain, Dorothy. The text above is not mine. The text below is mine. It is unfortunate that they appear to have both been attributed to me. >> There's two different transitions being discussed here, and, we >> need to be >> more accurate about how we talk about them. I think much of the > enterprise >> resistance stems from the misuse of the words transition or >> migration to >> describe the first step. The first step is dual-stacking. Dual- >> stacking >> should be relatively painless and should not require a great deal of >> application testing, etc. Yes, removal of IPv4 will be painful and >> take > time. >> The good news is that the first test cases for that will be new >> hosts > after >> IPv4 addresses are no longer available with the possibility of >> using IPv4 > NAT >> as a fallback to back-stop that issue initially while the native >> IPv6 issues are resolved. Once the IPv6-only new hosts are working >> fine >> without needing IPv4, then, we can look at removing IPv4 from the > remaining >> dual-stack hosts and finally the network infrastructure. >> >> So, let's focus on getting existing services dual-stacked, then worry > about >> the next steps. > > ++1. > Transition is a poorly chosen term, perhaps with hindsight that is > easier to > say than without. > Agreed. However, I don't think it's too late. I think it is worth the effort to start talking, especially to the enterprise world about dual-stacking rather than migrating/converting/transitioning to IPv6. A small change in words may garner a big change in sentiment. At this point, I think it is worth a try. Owen From tedm at ipinc.net Tue Dec 15 16:02:08 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 15 Dec 2009 13:02:08 -0800 Subject: [arin-ppml] A challenge to the assumption that a big DFZ is aproblem In-Reply-To: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> References: <4B268CDE.2080503@ipinc.net> <20091215040808.GB33888@ussenterprise.ufp.org> <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> Message-ID: <4B27F950.7070603@ipinc.net> Michel Py wrote: >> Ted Mittelstaedt wrote: >> Today I can walk into the store and purchase a PC that has a CPU >> in it that runs at a clock speed of at least 10 times of >> most routers, and has at least 10 times the amount of ram, for >> a quarter of the cost of the annual service contract for most >> DFZ routers (let alone the hardware cost) > > I'm sorry, but you have no idea how a core router actually works. I will > try to make a comparison with a device that you may actually have seen. > It's not that I don't have any idea about how a core router works internally, there's plenty of vendor documentation out there on current designs if I wanted to start debating the merits of one or the other of the current router designs. It is that what your taking about is how the silicon is built TODAY. What I'm saying is that it seems to me that there is no inherent barrier in the silicon to coming out with routers that would do a much larger DFZ TOMORROW. Granted, TODAY's designs might not scale up - but is that a silicon problem or simply that more R&D is needed to find better (or cheaper) router designs? I will be the first to admit that this might have huge economic repercussions. For example, the switchover of the US to digital TV has had huge economic repercussions in the sale of consumer electronics, since it's like half the showroom floor today is devoted to TV sales, I'd assume that TV sales today are going great guns, driven by this. Keeping in mind that most people probably WOULDN'T just go out and replace a perfectly good TV for no reason. But, is the economics of it our responsibility? What is ARIN's charter, folks? Are you saying we should modify addressing policy based on costs of hardware, or based on what it's POSSIBLE for hardware to do? I don't recall in the discussion of historical policy that the reason that IPv4 allocations were originally limited was because larger routers were expensive. I believe the limitations were because larger routers DIDN'T EXIST and there was no idea that they would EVER exist. Come on, folks, the most popular video game back then was pong!!!! It would be different if there was something in the silicon that prevented this. For example, you might have noticed recently that the newer CPU designs don't seem to have higher and higher clock speeds - that now, they are increasing the number of cores. This is because the laws of physics make it impossible to increase CPU speed much more. Thus, if we were still running on a MS-DOS world, then power increases in the personal computer would have ended - since MS-DOS didn't support more than 1 CPU. > In my laptop bag, I carry this switch: The thing about that is that your looking at a device which for the last 20 or so odd years there's been competition to make them better and faster at doing 1 thing - switching packets. A PC is a general purpose device, by definition it does nothing very well, but a lot of things mediocre. You could set your PC up as a sniffer - granted not a great sniffer - or run a wordprocessor on it - you can't run a wordprocessor on your switch. That's not really what I was talking about. > > There is a reason why Cisco and Juniper still sell these multi-million > dollar routers. They work (mostly). If someone had found a way to > replace a CRS-1 or a T1600 with a PC, Cisco and Juniper would be out of > business. > No they would not. Didn't you know that all a Cisco PIX was is a PC? It had a Intel CPU in it and all the PC support chips a PC of the time had. They'd adapt. Nobody is going to come out with a PC that works as well at routing packets as a purpose-built router, by definition you will always be able to build a purpose-built hardware device that is faster than a general-purpose device like a PC that's being used to solve a problem. BUT, that isn't what is needed, here. What I'm really asking is, CAN a router be built that's fast enough for a much larger DFZ in the core? I'm not asking if such a beast would be "too expensive", I'm not asking if such a beast exists today, I'm asking if it's theoretically impossible to build such a device - in the same sense that it would be impossible to build a square balloon out of thin, flexible rubber. Ted From michael.dillon at bt.com Tue Dec 15 18:21:50 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 15 Dec 2009 23:21:50 -0000 Subject: [arin-ppml] A challenge to the assumption that a big DFZ isaproblem In-Reply-To: <4B27F950.7070603@ipinc.net> Message-ID: <28E139F46D45AF49A31950F88C49745804898034@E03MVZ2-UKDY.domain1.systemhost.net> > What I'm saying is that it seems to me that there is no > inherent barrier in the silicon to coming out with routers > that would do a much larger DFZ TOMORROW. Granted, TODAY's > designs might not scale up - but is that a silicon problem or > simply that more R&D is needed to find better (or cheaper) > router designs? Actually, there is a silicon problem. TODAY, we already know just how much further we can take silicon. The discussion earlier about TCAM was pointing out that we already had reached a point where just making better faster Random Access Memory wasn't good enough, so we had to turn to Content Addressable Memory (CAM), specificaly to Ternary CAMs where you can record a don't-care value in addition to 1s and 0s. TCAM is still implemented in silicon, but it is a better algorithm for solving route lookups. Before that the big advance was in using a specific data structure for lookups; some form of trie if I am not mistaken. And probably the next thing that will provide an unpredicatble boost will be some combination of things that makes use of a trie, some DRAM and some TCAM in some as yet unknown technique to squeeze a bit more performance. After that, it's all over for silicon except a certain amount of predictable year-on-year improvement. In fact, this predictability is a good thing because it helps operators plan their core router investments by being able to predict how long a given router will have enough steam. The major vendors all know this and would not even deploy an improvement in silicon or algorithms that would disrupt this schedule. Once they know something works, they will tell everyone what their deployment roadmap is, and most people will not have to adjust their planned router refresh timetable by much. There is only so much money out there available for investment in this kind of core infrastructure. > But, is the economics of it our responsibility? What is > ARIN's charter, folks? Are you saying we should modify > addressing policy based on costs of hardware, or based on > what it's POSSIBLE for hardware to do? Definitely! And that is the way that it has always been. We do not make policy in a vacuum, it has always been pragmatic and in tune with the environment of the network. > I don't recall in the discussion of historical policy that > the reason that IPv4 allocations were originally limited was > because larger routers were expensive. In the really historical stuff, routers did not come into consideration at all. It was all about the protocol and the number space and the fact that we needed to address more than 255 hosts so someone suggested changing that to 255 networks and then someone else pointed out that if you only numbered 128 networks, then the other 128 numbers could be used by a large number of smaller class B and C networks. In fact, back then I don't believe routers existed at all, they used gateways instead. > I believe the > limitations were because larger routers DIDN'T EXIST and > there was no idea that they would EVER exist. Come on, > folks, the most popular video game back then was pong!!!! And a popular science fiction novel was Shockwave Rider by John Brunner, in which the hero was a programmer who sent worms into the network to collect information, and do naughty things. It isn't until the last 10 years that this has fully become a reality although we use language like botnets, keyloggers, phishing and so on, to describe this stuff. > It would be different if there was something in the silicon > that prevented this. The diameter of a silicon molecule is one thing that prevents us from going on forever in linear progression. Another thing is that when traces are only a few molecules wide, they no longer behave like wires any more. > BUT, that isn't what is needed, here. What I'm really asking > is, CAN a router be built that's fast enough for a much > larger DFZ in the core? > I'm not asking if such a beast would be "too expensive", I'm > not asking if such a beast exists today, I'm asking if it's > theoretically impossible to build such a device - in the same > sense that it would be impossible to build a square balloon > out of thin, flexible rubber. The answer is NO, NOT IN THE NEAR FUTURE. And since ARIN only makes policy to address reasonably current things, we shouldn't worry about it. When the time comes, there will be a new board trustees, a new advisory council, and probably a new crew of folks discussing things on PPML. All those folks will be at least as smart as us, and will have the benefit of greater experience than we do. If someone is going to make policy for 2015, I would prefer that they have the experiences of 2012, 2013 and 2014 under their belts first. --Michael Dillon P.S. Of course if you believe in the coming Idiocracy, you might argue for getting everything just right today so that in the future, you don't have to be the slightest bit clever in order to live a fulfilling life. From farmer at umn.edu Tue Dec 15 19:53:50 2009 From: farmer at umn.edu (David Farmer) Date: Tue, 15 Dec 2009 18:53:50 -0600 Subject: [arin-ppml] A challenge to the assumption that a big DFZ is aproblem In-Reply-To: <4B27F950.7070603@ipinc.net> References: <4B268CDE.2080503@ipinc.net> <20091215040808.GB33888@ussenterprise.ufp.org> <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <4B27F950.7070603@ipinc.net> Message-ID: <4B282F9E.2060107@umn.edu> Ted Mittelstaedt wrote: .... > What I'm really asking is, CAN a > router be built that's fast enough for a much larger DFZ in the core? > I'm not asking if such a beast would be "too expensive", I'm not asking > if such a beast exists today, I'm asking if it's theoretically > impossible to build such a device - in the same sense that it would be > impossible to build a square balloon out of thin, flexible rubber. > > Ted Theoretically, yes it could. But ARIN policy shouldn't be based solely on what is theoretically possible, anymore than it should be base solely on what we did or was possible three years ago. It should be heavily based on what is practical now and in the next few years, say 2 to 3 years for discussion, with a little bit of influence from the theoretical and the past. So I agree ARIN policy should be forward looking, but at the same time we can't get to far ahead of what is operationally possible at this moment today. Think of it this way, it takes 6 month to a year to get policy through the ARIN process. Then depending on the policy it could easily take a year or two for that policy to impact a significant number of resource holders. So depending on the policy 2 to 3 years, maybe up to 5 years in some limited cases, seems like a reasonable policy horizon to be working with. That said lets look at the theoretical a little, even if it is mostly out of scope for ARIN policy for now; As has been said, ~1M routes is fairly common today, the equipment has been available for 5 years or more. But, there is still more than a little bit of stuff that is limited to ~250K, this is being phased out or moved into non-DFZ uses by most people. And, ~3M route solutions are just starting to become available but are not at all common yet, but over the next few years I expect they will become more and more common. There are software techniques that could shrink the effective size of the DFZ, some were talked about at the last NANOG/ARIN meeting, but these are not going the magically reduce the DFZ by a factor of 100 or anything like that. There are different network architectures along with those software changes to BGP that can limit the number of routers that need a full DFZ in there forwarding plane. In this case More's Law for regular CPU and memory could play a much bigger role. But these changes are not purely technical, economics in the form of what the market finds acceptable will play a big role in what will truly happens. There are two markets at work here, enterprise and lower tier providers purchasing transport services from backbone providers, and what technologies and architectures they find acceptable. Then the backbone providers purchasing core routers from equipment manufactures, and technologies and architectures they believe their customers will find acceptable. So if ~3M route forwarding hardware, along with these software techniques, start to become common place in the next 2 or 3 years then a ~10M route DFZ might be reasonable in 3 to 5 years, but this is highly speculative. Further, I don't see ~100M route DFZ being a reasonable option in any planning horizon that I would be talking about now. Also remember that the speeds and feeds don't stand still while all of this is happening we are talking about 40G and 100G interfaces becoming common place in the backbone while all of this is happening too. So it is not hard to imagine this being an order N cubed problem, O(N^3), from a silicon complexity point of view. Personally, I believe long term the game changer is going to be IPv6 and getting a working solution that splits the identifier and locator, in a why this is what NAT does today for IPv4, just not very well. If this can happen then high performance general purpose CPUs at the boundary of the enterprise or user edge network and the provider network could really make a difference and the kind of changes you are asking about could maybe happen. This kind of solution is only in the testbed stage right now, go look at LISP. And, there are lots of people highly skeptical of this being able to work at Internet scale. So other than resources for experimentation this is not ready for ARIN policy work by any means. Thats enough for now! -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From bicknell at ufp.org Tue Dec 15 21:31:30 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 15 Dec 2009 18:31:30 -0800 Subject: [arin-ppml] A challenge to the assumption that a big DFZ is aproblem In-Reply-To: <4B27F950.7070603@ipinc.net> References: <4B268CDE.2080503@ipinc.net> <20091215040808.GB33888@ussenterprise.ufp.org> <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <4B27F950.7070603@ipinc.net> Message-ID: <20091216023130.GA31366@ussenterprise.ufp.org> In a message written on Tue, Dec 15, 2009 at 01:02:08PM -0800, Ted Mittelstaedt wrote: > What I'm saying is that it seems to me that there is no inherent barrier > in the silicon to coming out with routers that would do a much larger > DFZ TOMORROW. Granted, TODAY's designs might not scale up - but > is that a silicon problem or simply that more R&D is needed to find > better (or cheaper) router designs? You are correct from a technology point of view. I believe TCAM designs can scale to a much larger routing table, perhaps with a corresponding increase in cost. Beyond that history tells us some other solution will be found. However, R&D almost never generates cheaper designs, at least in Rev 1. Perhaps in revs 2 and 3 and 4 they get cheaper, but rarely does an advance end up cheaper out of the gate. Plus, there is lead time. Evolutionary designs take ~3-5 years to spin out. Routers you will buy in 2013 are all but done deals from a design perspective. What remains is to work out manufacturing, testing, code, etc. If you're looking at something totally new then you're probably in the 5-7 year timeframe on the short end. So if the question is, can we support a 10 million route FIB in 2020, the answer is probably yes. If the answer is can we support a 10 million route fib in 2015, the answer is almost as firmly no. The TCAM is a shared resource in most designs. Any/all of the following share the same resource: IPv4 Route Ipv6 Route ACL ARP Entry MPLS Label IPv6 ND Information CLNS Neighbor Information Those that are really worried about this aren't worried that the IPv4 routing table might grow from 300,000 today to 600,000 in 2015, or that the IPv6 routing table might grow from 2000 today to 100,000 in 2015. Nor are they worried about the MPLS table growing from 1,000 entries to 20,000 entries as MPLS VPN's take off. However, adding up all of those in the shared resource creates a grim picture. It would appear all of the people planning for those three separate things are all but assuming the others are 0. > But, is the economics of it our responsibility? What is ARIN's > charter, folks? Are you saying we should modify addressing policy > based on costs of hardware, or based on what it's POSSIBLE for > hardware to do? In the long (10+ year) view, absolutely not. Do what's right, and the vendors will sort it out. In the short term view, under 5 years for sure, probably under 10, and maybe under 15, the hardware must be considered. It need not dicate, but to ignore it would be excessively foolish, and hardly rise to the standard of being a good steward. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From michel at arneill-py.sacramento.ca.us Tue Dec 15 23:09:04 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 15 Dec 2009 20:09:04 -0800 Subject: [arin-ppml] A challenge to the assumption that a big DFZ isaproblem In-Reply-To: <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> References: <4B268CDE.2080503@ipinc.net><20091215040808.GB33888@ussenterprise.ufp.org> <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> Message-ID: <471D76419F9EF642962323D13DF1DF690115E0@newserver.arneill-py.local> > Chris Engel wrote: > IETF like many institutions (including ARIN) is subject to > institutional biases....just mention NAT66 on an IETF > mailing list and you'll see what I mean. This is soooo true. I learned that lesson the harsh way a while ago. Basically this is what led us to the current status-quo with IPv6: It is urgent to wait. Since no NAT-based migration is going to make it there (just inventorying the transition mechanisms that have been torpedoed because based on some kind of NAT would take some time) everyone is in the holding pattern for the next 5+ years. > Warren Johnson wrote: > Is it just me or do half the messages that are meant to > clarify people's conception about a particular subject > (IP allocations, router hardware etc) often end in > patronizing tones and snarky remarks? Is it just me or a large number of messages on this list are either totally unrealistic dreams, or implying that { ISPs | router vendors | software vendors | enterprise operators } who have been on the job for 10 or 20 years are bozos who don't know what they are doing? Frankly I've had enough of things on the lines of: - It's all the fault of Microsoft Windows... - Cisco does not know how to build a router... - My ISP does not know how to configure BGP... - I could do better for cheaper.... etc While I'm at it: In my lab, I have a couple of PC-based Juniper "routers"; they're called "Olives": a generic PC running JunOS. Conceptually, they could take a full BGP feed. In a lab, they're great. In a production world, they are worth as much as this 3640 or 7200 non-VXR that one can buy on eBay for next to nothing: nothing. I was wondering, actually: anyone has an Olive image that supports PCI Express and GigE NICs? Would be fun to figure out how much it can handle. Answer in private ;-) Michel. From michel at arneill-py.sacramento.ca.us Tue Dec 15 23:52:18 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 15 Dec 2009 20:52:18 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> Message-ID: <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> There were several mentions of Moore's law lately. And with them, some implied comments that scalability issues would eventually be solved by it (assuming that it keeps working, which it has so far). This is just not true, and here's why: yes, Moore's law is still in effect. But guess what: link speed / bandwidth/ TE requirements / etc have evolved also, possibly even faster than Moore's law. Not so long ago, a 7500 was hot stuff BFR. A T1 was fast, a DS-3 was smoking, and an OC-12 was something only a telco would have. Today, a T1 is slow; most consumer broadband offerings fitting a family budget are better. I have T1-speeds on my cell phone, and the CPU that runs said phone is probably more powerful than anything that ran a 7500. A DS-3 is not smoking anymore either, as FTTH and metro Ethernet have brought equivalent speeds (in urban areas) to the masses for a few hundred bucks a months. As of OC-12, it is a bit out of style too, when the typical FTTH home link is GigE and the name of the game in any data room is 10GigE. So yes, Moore's law is still working. Does it help? Not much, as the operating requirements tend to be a moving target that adapts to whatever is available on the market. Michel. From joelja at bogus.com Wed Dec 16 00:30:12 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 15 Dec 2009 21:30:12 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> Message-ID: <4B287064.3070909@bogus.com> I think it's awesome that the PPML lists has suddenly sprouted router silicon experts. It would be interesting to hear your projections for the fib capacity of 100Gb/s ethernet centric forwarding engines circa this time 2011. joel Michel Py wrote: > There were several mentions of Moore's law lately. And with them, some > implied comments that scalability issues would eventually be solved by > it (assuming that it keeps working, which it has so far). > > This is just not true, and here's why: yes, Moore's law is still in > effect. But guess what: link speed / bandwidth/ TE requirements / etc > have evolved also, possibly even faster than Moore's law. > > Not so long ago, a 7500 was hot stuff BFR. A T1 was fast, a DS-3 was > smoking, and an OC-12 was something only a telco would have. > > Today, a T1 is slow; most consumer broadband offerings fitting a family > budget are better. I have T1-speeds on my cell phone, and the CPU that > runs said phone is probably more powerful than anything that ran a 7500. > A DS-3 is not smoking anymore either, as FTTH and metro Ethernet have > brought equivalent speeds (in urban areas) to the masses for a few > hundred bucks a months. As of OC-12, it is a bit out of style too, when > the typical FTTH home link is GigE and the name of the game in any data > room is 10GigE. > > So yes, Moore's law is still working. Does it help? Not much, as the > operating requirements tend to be a moving target that adapts to > whatever is available on the market. > > Michel. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From jmaimon at chl.com Wed Dec 16 10:32:36 2009 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 16 Dec 2009 10:32:36 -0500 Subject: [arin-ppml] Policy relevant assumptions post depletion Message-ID: <4B28FD94.1050906@chl.com> All, I believe that assumptions and expectations of how providers, customers, users and the ARIN community will react to IPv4 depletion and scarcity as it is experienced widely (if unevenly) across the spectrum in ever greater degree are relevant to choices of appropriate policy. I would like to hear yours. Here are mine, for what they may be worth. I strongly doubt providers will turn up users en-mass without IPv4 access. They will use some form of system to ensure that new subscribers will continue to be able to access the IPv4 internet and appear to be part of the IPv4 internet. I accept that that systems that are put in place to continue to provide that access could grow the population that is inaccessible from the IPv4 internet. I do not view as valid the assumption that there will be an emergent population unable to access the IPv4 internet. I further assume that providers will be able to provision customers needing accessibility from the IPv4 internet for quite some time after depletion affects their provisioning of customers needing access to IPv4 internet, fueled in part by scavenging inefficient utilization, reuse of globally unique addresses used prior to implementation of CGN's and the like, or even with 4->6 address family translation systems. I assume that need will likely be weighed by compensatory or monetary value. I believe ARIN policy should do its utmost in continuing to make available IPv4 addresses continually throughout this period, in order to attempt to even the field between organizations who have large amounts of scavenge-able, reusable or otherwise obtainable resources and those who have less or none. I hope that the systems employed by providers to continue to provision customers during depletion and scarcity will include IPv6 access, thus spurring its network effect by continually increasing the chances, instances and occasions where the use of IPv6 is preferable to IPv4. I do not expect that the only practical and desirable way to take advantage of IPv6 populations will be dual stacking in entirety internal networks. I do not expect operator of systems with large target user populations to ever willingly allow themselves to be accessible only via IPv6. I believe there to be an about even chance that these events will unfold with accompanying furor, noise and angst, enabling agendas that can be detrimental to our collective one. ARIN policy should attempt to preempt this. I welcome your comments and feedback. Joe From michel at arneill-py.sacramento.ca.us Wed Dec 16 13:21:48 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 16 Dec 2009 10:21:48 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <4B287064.3070909@bogus.com> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> <4B287064.3070909@bogus.com> Message-ID: <471D76419F9EF642962323D13DF1DF690115E7@newserver.arneill-py.local> > Joel Jaeggli wrote: > I think it's awesome that the PPML lists has suddenly > sprouted router silicon experts. You're not very good at sarcasm IMHO and for the record, I never pretended to be one. > It would be interesting to hear your projections for > the fib capacity of 100Gb/s ethernet centric forwarding > engines circa this time 2011. It's just a matter of time, and I'm sure when vendors feel like producing it I'm sure they will let you know. Reality check: GigE is on the consumer/residential market by now. http://www.linksysbycisco.com/US/en/products/WRT310N http://www.linksysbycisco.com/US/en/products/EG005W Reality check: 10 Gigabit Ethernet has been available in some rooms for years. http://tinyurl.com/ycyy2wy Reality check: as of today, 10 Gigabit Ethernet is available on all the market segments. 8-port 10GigE for the CRS-1: http://tinyurl.com/yz5hbff 4 and 8-port 10 GigE for the 6500/7600: http://tinyurl.com/2fu9lm Catalyst 4900 with two 10 GigE uplinks: http://tinyurl.com/yougjl Anybody in here thinks that the vendors are not working on the next step already? Michel. From tedm at ipinc.net Wed Dec 16 13:42:20 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 16 Dec 2009 10:42:20 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> Message-ID: <4B292A0C.6070701@ipinc.net> Michel Py wrote: > There were several mentions of Moore's law lately. And with them, some > implied comments that scalability issues would eventually be solved by > it (assuming that it keeps working, which it has so far). > > This is just not true, and here's why: yes, Moore's law is still in > effect. But guess what: link speed / bandwidth/ TE requirements / etc > have evolved also, possibly even faster than Moore's law. > > Not so long ago, a 7500 was hot stuff BFR. A T1 was fast, a DS-3 was > smoking, and an OC-12 was something only a telco would have. > > Today, a T1 is slow; most consumer broadband offerings fitting a family > budget are better. I have T1-speeds on my cell phone, and the CPU that > runs said phone is probably more powerful than anything that ran a 7500. > A DS-3 is not smoking anymore either, as FTTH and metro Ethernet have > brought equivalent speeds (in urban areas) to the masses for a few > hundred bucks a months. As of OC-12, it is a bit out of style too, when > the typical FTTH home link is GigE and the name of the game in any data > room is 10GigE. > > So yes, Moore's law is still working. Does it help? Not much, as the > operating requirements tend to be a moving target that adapts to > whatever is available on the market. > While I'm of the camp that Moore's Law will eventually taper off (how are we going to produce transistors smaller than a silicon molecule?) I have to point out that Moore's Law absolutely would help, it just depends on it's implementation by the router vendors. Moore's Law says nothing about actual power, the performance gain that has accompanied transistor count doubling has happened first due to clock speed increases, and now that they have reached the limit of that, it's happening due to increasing parallelization within the chip. Moore himself states that it has nothing to do with performance: ftp://download.intel.com/museum/Moores_Law/Video-Transcripts/Excepts_A_Conversation_with_Gordon_Moore.pdf How this applies to routing should be pretty obvious. If you have silicon in a router that has only a single internal path for packets to travel, then your not going to be able to pass as many packets from interface to interface as a router that has multiple, parallel, internal packet paths - all other things being equal between the routers. More transistors, more parallel paths. This is why the Cisco CRS-1 uses "massively parallel processing on the chip for flexible service delivery" http://www.cisco.com/en/US/prod/collateral/routers/ps5763/prod_brochure0900aecd800f8118.pdf (page 9) Internet routing works the same way in the macro scale. You wanna pass a gig of data between point A and point B? Well you can get a single gig link or you can get 10 100mb links, you just need 10 routers to do it. The problem I think is that the high power routers are so incredibly expensive and multiple circuits are more expensive that network administrators are still thinking more in terms of getting 1 big hulking router and a high speed link rather than multiple smaller routers and multiple links, when they need more throughput. It simplifies network design to think like this because you then don't have to deal with the ickyness of load balancing. But, Moore had an answer to that, because the other part of Moores law has to do with cost - meaning that if you keep the same transistor count on a chip, the chip cost falls. I suspect if the Cisco CRS-1 was selling for $500 USD, rather than $500K USD, the answer would be pretty obvious to most people. So yeah, I think Moore's Law applies. I also think that the router vendors believe that most backbone providers have deep pockets and will continue to pay lots of money for high power routers, thus they are not competing on price for the high-end routers, and thus not exercising that aspect of Moore's law. Otherwise you would see yearly price drops on CRS-1 line cards. Also the carriers themselves have a vested interest in keeping high speed link prices high, too. They would rather charge the same money every year for an increasing amount of fiber capacity than lower their price every year for the same amount of fiber capacity. Whether this situation will continue is anyone's guess. It definitely has not continued in the low end SOHO router and switch market. There, everything is commodity, now. Ted From joelja at bogus.com Wed Dec 16 14:35:31 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 16 Dec 2009 11:35:31 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <471D76419F9EF642962323D13DF1DF690115E7@newserver.arneill-py.local> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> <4B287064.3070909@bogus.com> <471D76419F9EF642962323D13DF1DF690115E7@newserver.arneill-py.local> Message-ID: <4B293683.2040201@bogus.com> Michel Py wrote: >> Joel Jaeggli wrote: >> I think it's awesome that the PPML lists has suddenly >> sprouted router silicon experts. > > You're not very good at sarcasm IMHO and for the record, I never > pretended to be one. Which is good because your observations on the future are something like 2-5 years in the past. >> It would be interesting to hear your projections for >> the fib capacity of 100Gb/s ethernet centric forwarding >> engines circa this time 2011. > > It's just a matter of time, and I'm sure when vendors feel like > producing it I'm sure they will let you know. If you're engaged in a silicon design exercise or capacity planning for an isp, it's not hard to interpret the graphs on fib scaling. you've got at least a 1st order approximation of where your FIB needs to be and when. 100Gb/s is late from the perspective of a number of operators, but it's arriving, and in two years it will be deriguer. the silicon that's being taped out to support it will arrive with the interfaces. Despite assertions to the contrary stated here and elsewhere these are not the most complex pieces of low-volume silicon ever made. Complexity is growing, because as any observer can tell you that a some point the benefits of going wider exceed the cost of doing so instead of going faster. Whether moore's law does or doesn't hold, the process, speed and density requirements are still trailing those of the most complex components out there, which provides headroom. On the fib scaling front, the sky hasn't fallen since the raws workshop in 06 and it's not likely too in the scope of your planning cycles. Operators about grouse about the capex, but so long as their internal complexity continues to occupy a significant chunk of fib real-estate, bitching about fib growth from deaggregation, when it's only part of the problem is a bit strong sighted. The networks that needed 2 million route FIBS to have reasonable headroom in 08/09 didn't need it due to the DFZ. FIB growth is predictable enough to put in a business plan, if your MPLS customers are paying for it so much the better. > > Reality check: GigE is on the consumer/residential market by now. > http://www.linksysbycisco.com/US/en/products/WRT310N > http://www.linksysbycisco.com/US/en/products/EG005W > > > Reality check: 10 Gigabit Ethernet has been available in some rooms for > years. > http://tinyurl.com/ycyy2wy > > > Reality check: as of today, 10 Gigabit Ethernet is available on all the > market segments. > 8-port 10GigE for the CRS-1: http://tinyurl.com/yz5hbff > 4 and 8-port 10 GigE for the 6500/7600: http://tinyurl.com/2fu9lm > Catalyst 4900 with two 10 GigE uplinks: http://tinyurl.com/yougjl > > > Anybody in here thinks that the vendors are not working on the next step > already? > > > Michel. > From bicknell at ufp.org Wed Dec 16 15:20:51 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 16 Dec 2009 12:20:51 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> Message-ID: <20091216202051.GB3661@ussenterprise.ufp.org> In a message written on Tue, Dec 15, 2009 at 08:52:18PM -0800, Michel Py wrote: > This is just not true, and here's why: yes, Moore's law is still in > effect. But guess what: link speed / bandwidth/ TE requirements / etc > have evolved also, possibly even faster than Moore's law. I'm not quite sure Moore's law is the right analogy, but I believe the concept you put forth is sound. The same advances that drive link speed faster (lower cost components, easier integration) also drive capability in the high end boxes (able to route faster links). In some sense the entire system moves in lockstep. However, with high end routers there are actually a number of new challenges. Much like PC's, they have hit the "Megahertz Wall" and thus are moving to parallel processing solutions. The good news is packet processing is often easy to parallelize, the bad news is that it is all new code and hardware for the vendors. Someone is going to have to pay for that development. More interesting to me is the physics wall. Most long haul WDM systems still have 10G channels. It turns out as you move past 10G a number of properties of light cause added difficulty. There are 40G solutions, at a HUGE price premium over 10G solutions. The innovation is in the 100G channel space, and requires developing entirely new encoding standards. I don't think these physics challenges are going to stop 100GE or other technologies, but they are going to disrupt the curve. We've gotten used to 10M ethernet replaced 5 years later by 100M for the same cost, replaced 5 years later by 1000M for the same cost, replaced 5 years later by 10000M for the same cost. It appears rathern than seeing 100000M 5 years later and for the same cost, we're going to see it 7 years later and for twice the cost. (Ok, those are very crude estimates, but you get my drift.) Someone else mentioned parallel links. There are ISP's today running 16x10GE, which is often the load balancing limit of the hardware. They want to run 2x100G, or 4x100G, but those cards are not available. They are still being tested in the lab. There's no ISP "afraid" of running links in parallel, even where they could do 1x100G often 10x10G is cheaper right now due to the deployed long haul systems capabilities. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From mpetach at netflight.com Wed Dec 16 16:12:37 2009 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 16 Dec 2009 13:12:37 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <4B292A0C.6070701@ipinc.net> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> <4B292A0C.6070701@ipinc.net> Message-ID: <63ac96a50912161312wa172a50md2be009d1f9eba5b@mail.gmail.com> On Wed, Dec 16, 2009 at 10:42 AM, Ted Mittelstaedt wrote: ... > Internet routing works the same way in the macro scale. ?You wanna pass > a gig of data between point A and point B? ?Well you can get a single > gig link or you can get 10 100mb links, you just need 10 routers to do it. If each data flow is larger than 100mb, that doesn't work quite so well; but for many small flows, it's an entirely viable option. > The problem I think is that the high power routers are so incredibly > expensive and multiple circuits are more expensive that network > administrators are still thinking more in terms of getting 1 big hulking > router and a high speed link rather than multiple smaller routers and > multiple links, when they need more throughput. ?It simplifies network > design to think like this because you then don't have to deal with the > ickyness of load balancing. Actually, the problem tends to be limited slot space on routers. If put all your long haul links into one router, you can use 100% of the slots for long-haul links; traffic comes in, traffic goes out, all is good. Now, if you want to split your traffic up across two routers, you don't get 2x the number of long-haul ports, because you have to burn a certain number of cross-link ports to get traffic between the two routers; in fact, the number of cross-links needed between the two routers is potentially equal to the number of inbound links into either one of the two routers (since worst-case scenario, every packet entering into router A has to cross over to router B to egress towards the destination). Thus, in your worst-case traffic flow scenario, you've actually gained zero additional long-haul links, because half of the ports you freed up on each router (by adding the second router) immediately get consumed to provide cross-links between the two routers. "Fine", you may think. "I'll just add another router into the mix...and *then* I'll be able to get more long haul ports." But you again have to come up with some way to get packets from routers A and B over to router C, so you have to take away some of the long-haul ports on routers A and B so that you can plumb up crosslinks from A to C, and from B to C. The good news is that since you now have even fewer long-haul links on A and B, you don't need quite as many cross links to each of the other routers; the bad news is, you now have twice as many routers for each router to cross-link to. Ultimately, it ends up being a losing proposition, unless you can gamble on better than worst-case traffic scenarios, and build less crosslinks between routers than would be needed to handle the full worst-case traffic load. > But, Moore had an answer to that, because the other part of Moores law > has to do with cost - meaning that if you keep the same transistor count > on a chip, the chip cost falls. Only if your production costs drop for some reason; otherwise, keeping the same transistor count on the chip will continue to cost you the same amount of money. > I suspect if the Cisco CRS-1 was selling for $500 USD, rather than $500K > USD, the answer would be pretty obvious to most people. You can get old 7k-class Cisco routers for $500 on eBay; why aren't more people just running large clusters of $500 routers, then? See the above cross-linking problem, and look at the rack space cost to put them in; at your typical facility like Equinix, at $1500/rack/month, if you can only fit 3 7k-class routers per rack, if the router only costs $500, you end up spending as much on space for the router as your hardware cost *every month*. Logic says that if you can get the same interface count in a smaller package, and thus pay for less rack space each month, it's worth paying *more* for the hardware to reduce those ongoing monthly expenses. > So yeah, I think Moore's Law applies. ?I also think that the router vendors > believe that most backbone providers have deep pockets and will > continue to pay lots of money for high power routers, thus they are > not competing on price for the high-end routers, and thus not exercising > that aspect of Moore's law. ?Otherwise you would see yearly price drops > on CRS-1 line cards. ?Also the carriers themselves have a vested > interest in keeping high speed link prices high, too. ?They would > rather charge the same money every year for an increasing amount of > fiber capacity than lower their price every year for the same amount > of fiber capacity. Fiber costs are generally going down year over year, in areas where it is relatively open and plentiful (eg, most of the ARIN region). But do keep in mind that data services over fiber cost a pathetically small amount compared to voice services, so if you're a telco, you have a massive incentive to reserve capacity for voice services as much as possible, and only sell off capacity for data when there's absolutely no possibility of voice demand rising to require the circuit. Doing the math, if your voice service calls a penny a minute, for example, and uses a 64k DS0 channel, that means on an OC192 you can pack in 129,024 DS0 channels (24 DS0 per DS1, 28 DS1 per DS3, 192 DS3 equivalents in an OC192). So, that's 129024 cents, or $1,290.24 per minute if you sell that circuit for voice service. There's generally about 43,200 minutes in an average length month; if we figure the circuit gets about 10% utilization for voice calls, that's about 4,320 minutes of voice calls going through it in a month (if you prefer, you can say 10% of the DS0s are in use for the full 43,200 minutes; the math comes out the same either way) -- you end up with potentially $1,290.24*4,320, or about $5,573,836.80/month revenue for an OC192 running at 10% capacity carrying voice services. Compare that to the actual amount generally charged for a data service OC192 in the ARIN region, which is maybe $50,000/month, and you start to realize that the financial pressure is really to use as many circuits as possible for voice services, if you're a telco, and *only* sell data circuits when you just can't generate any additional voice demand, since you only make 1/100th the revenue on the data circuits that you can make off voice services running along the same circuit. There's definitely pressures at work in the market; it's just somewhat dangerous to oversimplify what those pressures are. > Whether this situation will continue is anyone's guess. ?It definitely has > not continued in the low end SOHO router and switch market. ?There, > everything is commodity, now. > Ted The low end SOHO router and switch devices can't handle even close to a full set of internet routes...that's a completely false comparison, it's like trying to compare the cost for a huffy one speed beach cruiser bike with a 78 passenger bus. Two completely different sets of requirements for the two, and you can't substitute one for the other, no matter how creative you try to get. Matt From tedm at ipinc.net Wed Dec 16 17:10:39 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 16 Dec 2009 14:10:39 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <63ac96a50912161312wa172a50md2be009d1f9eba5b@mail.gmail.com> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> <4B292A0C.6070701@ipinc.net> <63ac96a50912161312wa172a50md2be009d1f9eba5b@mail.gmail.com> Message-ID: <4B295ADF.20606@ipinc.net> Matthew Petach wrote: > On Wed, Dec 16, 2009 at 10:42 AM, Ted Mittelstaedt wrote: > ... >> Internet routing works the same way in the macro scale. You wanna pass >> a gig of data between point A and point B? Well you can get a single >> gig link or you can get 10 100mb links, you just need 10 routers to do it. > > If each data flow is larger than 100mb, that doesn't work quite so well; but > for many small flows, it's an entirely viable option. > >> The problem I think is that the high power routers are so incredibly >> expensive and multiple circuits are more expensive that network >> administrators are still thinking more in terms of getting 1 big hulking >> router and a high speed link rather than multiple smaller routers and >> multiple links, when they need more throughput. It simplifies network >> design to think like this because you then don't have to deal with the >> ickyness of load balancing. > > Actually, the problem tends to be limited slot space on routers. If put > all your long haul links into one router, you can use 100% of the slots > for long-haul links; traffic comes in, traffic goes out, all is good. > > Now, if you want to split your traffic up across two routers, you don't > get 2x the number of long-haul ports, because you have to burn a > certain number of cross-link ports to get traffic between the two > routers; in fact, the number of cross-links needed between the > two routers is potentially equal to the number of inbound links > into either one of the two routers (since worst-case scenario, > every packet entering into router A has to cross over to router B > to egress towards the destination). > Thus, in your worst-case traffic flow scenario, you've actually > gained zero additional long-haul links, because half of the ports > you freed up on each router (by adding the second router) immediately > get consumed to provide cross-links between the two routers. > > "Fine", you may think. "I'll just add another router into the mix...and > *then* I'll be able to get more long haul ports." But you again have > to come up with some way to get packets from routers A and B over > to router C, so you have to take away some of the long-haul ports on > routers A and B so that you can plumb up crosslinks from A to C, and > from B to C. The good news is that since you now have even fewer > long-haul links on A and B, you don't need quite as many cross links > to each of the other routers; the bad news is, you now have twice as > many routers for each router to cross-link to. > > Ultimately, it ends up being a losing proposition, unless you can > gamble on better than worst-case traffic scenarios, and build less > crosslinks between routers than would be needed to handle the > full worst-case traffic load. > >> But, Moore had an answer to that, because the other part of Moores law >> has to do with cost - meaning that if you keep the same transistor count >> on a chip, the chip cost falls. > > Only if your production costs drop for some reason; otherwise, keeping > the same transistor count on the chip will continue to cost you the same > amount of money. > >> I suspect if the Cisco CRS-1 was selling for $500 USD, rather than $500K >> USD, the answer would be pretty obvious to most people. > > You can get old 7k-class Cisco routers for $500 on eBay; why aren't > more people just running large clusters of $500 routers, then? See > the above cross-linking problem, and look at the rack space cost > to put them in; at your typical facility like Equinix, at $1500/rack/month, > if you can only fit 3 7k-class routers per rack, if the router only costs > $500, you end up spending as much on space for the router as your > hardware cost *every month*. Logic says that if you can get the > same interface count in a smaller package, and thus pay for less > rack space each month, it's worth paying *more* for the hardware > to reduce those ongoing monthly expenses. > >> So yeah, I think Moore's Law applies. I also think that the router vendors >> believe that most backbone providers have deep pockets and will >> continue to pay lots of money for high power routers, thus they are >> not competing on price for the high-end routers, and thus not exercising >> that aspect of Moore's law. Otherwise you would see yearly price drops >> on CRS-1 line cards. Also the carriers themselves have a vested >> interest in keeping high speed link prices high, too. They would >> rather charge the same money every year for an increasing amount of >> fiber capacity than lower their price every year for the same amount >> of fiber capacity. > > Fiber costs are generally going down year over year, in areas where it > is relatively open and plentiful (eg, most of the ARIN region). But do > keep in mind that data services over fiber cost a pathetically small > amount compared to voice services, so if you're a telco, you have > a massive incentive to reserve capacity for voice services as much > as possible, and only sell off capacity for data when there's absolutely > no possibility of voice demand rising to require the circuit. > > Doing the math, if your voice service calls a penny a minute, for example, > and uses a 64k DS0 channel, that means on an OC192 you can pack in > 129,024 DS0 channels (24 DS0 per DS1, 28 DS1 per DS3, 192 DS3 > equivalents in an OC192). So, that's 129024 cents, or $1,290.24 per > minute if you sell that circuit for voice service. There's generally about > 43,200 minutes in an average length month; if we figure the circuit gets > about 10% utilization for voice calls, that's about 4,320 minutes of voice > calls going through it in a month (if you prefer, you can say 10% of the > DS0s are in use for the full 43,200 minutes; the math comes out the > same either way) -- you end up with potentially $1,290.24*4,320, or > about $5,573,836.80/month revenue for an OC192 running at 10% > capacity carrying voice services. > > Compare that to the actual amount generally charged for a data service > OC192 in the ARIN region, which is maybe $50,000/month, and you start > to realize that the financial pressure is really to use as many circuits > as possible for voice services, if you're a telco, and *only* sell data > circuits when you just can't generate any additional voice demand, > since you only make 1/100th the revenue on the data circuits that > you can make off voice services running along the same circuit. > > There's definitely pressures at work in the market; it's just somewhat > dangerous to oversimplify what those pressures are. > >> Whether this situation will continue is anyone's guess. It definitely has >> not continued in the low end SOHO router and switch market. There, >> everything is commodity, now. >> Ted > > The low end SOHO router and switch devices can't handle even close to > a full set of internet routes...that's a completely false comparison, it's > like trying to compare the cost for a huffy one speed beach cruiser bike > with a 78 passenger bus. Two completely different sets of requirements > for the two, and you can't substitute one for the other, no matter how > creative you try to get. > I wasn't meaning substitution in that, but more history. Up until Linksys came out with their BEF series, and charged $49.95 for them, the typical SOHO router was in the $300-$500 range. The Linksys devices were game-changers. Linksys could afford to do it this way because they worked hand-in-hand with one of the chip foundries, Broadcom probably, to come out with a single-ASIC design that put the CPU and ethernet ports all on one chip. That was only possible because of Moore's Law. Production costs for all of the other vendors still did remain the same for their designs, and they didn't lower their prices - with the result that I saw quite a lot of NetScreens and stuff like that get replaced with the Linksys devices. - and the end result that companies like SMC and 3com became non-players in that market. Right now a small handful of router vendors, ie: Cisco and Juniper, have a lock on the mid-to-high end router market. But it's anybodies guess that this lock will remain since it could be broken at any time with another game-changer appearing out of nowhere. Ted > Matt > From farmer at umn.edu Wed Dec 16 20:32:54 2009 From: farmer at umn.edu (David Farmer) Date: Wed, 16 Dec 2009 19:32:54 -0600 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process- revised In-Reply-To: <3c3e3fca0912142236l5ea57331u89c62e53783488a0@mail.gmail.com> References: <4B06D427.1080905@arin.net> <4B22FE8A.6090806@umn.edu> <3c3e3fca0912131938u1f4944d4vfff928a25ddf81d1@mail.gmail.com> <693DF10B-E680-4ABB-9532-CA7A8E892B9A@delong.com> <3c3e3fca0912141542v67227024v8d4a597f91f67526@mail.gmail.com> <1BE798EE-65E8-46EC-9A49-B6E8ABB7A34F@akamai.com> <3c3e3fca0912142236l5ea57331u89c62e53783488a0@mail.gmail.com> Message-ID: <4B298A46.8020008@umn.edu> William Herrin wrote: > On Mon, Dec 14, 2009 at 6:50 PM, Martin Hannigan wrote: >> On Dec 14, 2009, at 6:42 PM, William Herrin wrote: > >>> Note the emphasis on subnetting so that you wouldn't consume an entire >>> class C for every LAN segment. That's where the heads were in the game >>> in 1995. That's what we cared about. Unless you were requesting a lot >>> of addresses, deeper questions of "need" were CURSORY. > >> You realize that needs were different circa '95 and that the needs then are >> much different than the needs now hence where the "heads" were then? In Sep >> 94 there were about 84 web sites total (IIRC), hosting was done by the >> address routed to the machine typically and RIP was useful. At that time I >> was answering questions like "what is a proxy" "who is this warez guy!" and >> "why are people wasting our capacity going to netscape everytime they open >> their browser?". The needs of yesteryear were much different than the needs >> of today and needs have always been the driver IMHO. > > Martin, > > I agree with everything you just said. Where does that leave us? > > The whole IPv6 PA-everywhere idea that came out of the IETF has enough > glaring technical deficiencies that it won't fly. Is CIDR and the > needs-based justification we've employed for the last 12 to 14 years > the best answer there is? Or have we learned enough about routing and > addressing in the last decade to come up with a better answer for the > relatively clean slate afforded by IPv6? > > Regards, > Bill Herrin Well where I think it leaves us, we should define some basic needs basis, some common sense requirements that entitles you to increasing amounts of address space. One thing I like about your proposal is that it eliminates the detailed usage based justifications of IPv4 and the HD-Ratio concept we tried to replace it with currently in IPv6. Have you ever tried to explain HD-Ratios to a pointy haired boss or an accountant? But, what is wrong with some common sense limits? Like; 1. If you need any addresses you get a /56; 2. You don't need a /48 unless you have at least 256 host; That could be one host in each of the 256 subnets that a /56 gives you, or 256 hosts in a single subnet. 3. You don't need a /40 unless you have more than one site; 4. If you reasonably expect to support more that 100 sites you probably should have a /32; 5. You don't need anything more that a /32 unless you are supporting a big bunch of sites, like 10,000 or more. These are not onerous requirements, this is more about determining the size of infinity you justify, than placing real functional limits on anyone. Furthermore, I'm not stuck on these numbers, these are just examples for discussion. Just like the pricing model you provided in the proposal is an example for discussion. But, I believe we must have something that makes it clear there is something more than simply the size of your checkbook determining how much address space you may have use of. The primary limit is still going to be the fee structure, and it probably should be, but we need something to deal with those that have more money than sense. You might say if they want to waste there money, let them. However, this will create inequities that is easy for people to criticize, and if it gets bad enough it will create problems. These are all simple enough, I could tell a pointy haired boss, an accountant, maybe even a congressman or a political appointee too, and for sure my grandma. They would all nod and would at least seem to understand what I am talking about. Talking to any of them about a HD-Ratios would make their heads explode or my teetotaling grandma to get a good stiff belt of grampa's whiskey. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From Matthew.Wilder at telus.com Wed Dec 16 20:50:40 2009 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Wed, 16 Dec 2009 18:50:40 -0700 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process- revised Message-ID: (Sorry for top-posting) I have to agree with David wholeheartedly. HD ratios are not only difficult to explain let alone understand, but they can be totally inadequate if an ISP decides that every internet subscriber needs a /48. That ISP could easily squander innumerable resources, and still get their next allocation even more easily, since the HD ratio allows lower net utilization on larger blocks. I think site quantity based rules could offers a more fair, measurable and understandable justification yardstick than we currently have in v6 and still not as onerous as we have with v4. There might need to be thought given to how you count sites when one is a corporate tower versus a Starbucks, but I believe it is worth developing the thought. M Wilder, P.Eng. ----- Original Message ----- From: arin-ppml-bounces at arin.net To: William Herrin Cc: arin-ppml at arin.net Sent: Wed Dec 16 18:32:54 2009 Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process- revised William Herrin wrote: > On Mon, Dec 14, 2009 at 6:50 PM, Martin Hannigan wrote: >> On Dec 14, 2009, at 6:42 PM, William Herrin wrote: > >>> Note the emphasis on subnetting so that you wouldn't consume an entire >>> class C for every LAN segment. That's where the heads were in the game >>> in 1995. That's what we cared about. Unless you were requesting a lot >>> of addresses, deeper questions of "need" were CURSORY. > >> You realize that needs were different circa '95 and that the needs then are >> much different than the needs now hence where the "heads" were then? In Sep >> 94 there were about 84 web sites total (IIRC), hosting was done by the >> address routed to the machine typically and RIP was useful. At that time I >> was answering questions like "what is a proxy" "who is this warez guy!" and >> "why are people wasting our capacity going to netscape everytime they open >> their browser?". The needs of yesteryear were much different than the needs >> of today and needs have always been the driver IMHO. > > Martin, > > I agree with everything you just said. Where does that leave us? > > The whole IPv6 PA-everywhere idea that came out of the IETF has enough > glaring technical deficiencies that it won't fly. Is CIDR and the > needs-based justification we've employed for the last 12 to 14 years > the best answer there is? Or have we learned enough about routing and > addressing in the last decade to come up with a better answer for the > relatively clean slate afforded by IPv6? > > Regards, > Bill Herrin Well where I think it leaves us, we should define some basic needs basis, some common sense requirements that entitles you to increasing amounts of address space. One thing I like about your proposal is that it eliminates the detailed usage based justifications of IPv4 and the HD-Ratio concept we tried to replace it with currently in IPv6. Have you ever tried to explain HD-Ratios to a pointy haired boss or an accountant? But, what is wrong with some common sense limits? Like; 1. If you need any addresses you get a /56; 2. You don't need a /48 unless you have at least 256 host; That could be one host in each of the 256 subnets that a /56 gives you, or 256 hosts in a single subnet. 3. You don't need a /40 unless you have more than one site; 4. If you reasonably expect to support more that 100 sites you probably should have a /32; 5. You don't need anything more that a /32 unless you are supporting a big bunch of sites, like 10,000 or more. These are not onerous requirements, this is more about determining the size of infinity you justify, than placing real functional limits on anyone. Furthermore, I'm not stuck on these numbers, these are just examples for discussion. Just like the pricing model you provided in the proposal is an example for discussion. But, I believe we must have something that makes it clear there is something more than simply the size of your checkbook determining how much address space you may have use of. The primary limit is still going to be the fee structure, and it probably should be, but we need something to deal with those that have more money than sense. You might say if they want to waste there money, let them. However, this will create inequities that is easy for people to criticize, and if it gets bad enough it will create problems. These are all simple enough, I could tell a pointy haired boss, an accountant, maybe even a congressman or a political appointee too, and for sure my grandma. They would all nod and would at least seem to understand what I am talking about. Talking to any of them about a HD-Ratios would make their heads explode or my teetotaling grandma to get a good stiff belt of grampa's whiskey. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From packetgrrl at gmail.com Wed Dec 16 21:51:04 2009 From: packetgrrl at gmail.com (cja@daydream.com) Date: Wed, 16 Dec 2009 19:51:04 -0700 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocation criteria In-Reply-To: <4AEB1581.8090607@arin.net> References: <4AEB1581.8090607@arin.net> Message-ID: Hi everyone... I have seen virtually no comments regarding this policy. I can't imagine there is a lack of opinion out there... Happy Holidays! -----Cathy On Fri, Oct 30, 2009 at 9:34 AM, Member Services wrote: > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with Policy Development > Process. > > This proposal is in the first stage of the Policy Development Process. > ARIN staff will perform the Clarity and Understanding step. Staff does > not evaluate the proposal at this time, their goal is to make sure that > they understand the proposal and believe the community will as well. > Staff will report their results to the ARIN Advisory Council (AC) within > 10 days. > > The AC will review the proposal at their next regularly scheduled > meeting (if the period before the next regularly scheduled meeting is > less than 10 days, then the period may be extended to the subsequent > regularly scheduled meeting). The AC will decide how to utilize the > proposal and announce the decision to the PPML. > > In the meantime, the AC invites everyone to comment on the proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 101: Multihomed initial allocation criteria > > Proposal Originator: Chris Grundemann > > Proposal Version: 1 > > Date: 30 October 2009 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Modify item number 4 under section 6.5.1.1. Initial allocation criteria > to the following: > > 4. be an existing, known ISP in the ARIN region or have a plan for > making at least 200 end-site assignments to other organizations within > 5 years or, if multihomed, demonstrate the efficient utilization of a > minimum contiguous or noncontiguous /44 (sixteen /48s) from an > upstream. > > Rationale: > > The bar for obtaining initial IPv4 allocations is lower for those ISPs > which are multi-homed, it stands to reason that it also be lower in > IPv6. Since efficient utilization is based on the use of /48s, this > policy would effectively allow any ISP with 15 active customers (with > one /48 each and one /48 for the ISPs own network) to receive an initial > allocation of an IPv6 /32 from ARIN. I think this is a better approach > than removing or lowering the end-site assignment requirement for _all_ > ISPs while still providing more open access to IPv6. > > Timetable for implementation: immediate > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Dec 16 22:20:55 2009 From: bill at herrin.us (William Herrin) Date: Wed, 16 Dec 2009 22:20:55 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process- revised In-Reply-To: <4B298A46.8020008@umn.edu> References: <4B06D427.1080905@arin.net> <4B22FE8A.6090806@umn.edu> <3c3e3fca0912131938u1f4944d4vfff928a25ddf81d1@mail.gmail.com> <693DF10B-E680-4ABB-9532-CA7A8E892B9A@delong.com> <3c3e3fca0912141542v67227024v8d4a597f91f67526@mail.gmail.com> <1BE798EE-65E8-46EC-9A49-B6E8ABB7A34F@akamai.com> <3c3e3fca0912142236l5ea57331u89c62e53783488a0@mail.gmail.com> <4B298A46.8020008@umn.edu> Message-ID: <3c3e3fca0912161920j7e7c62f7g91bf0f22a190b29d@mail.gmail.com> On Wed, Dec 16, 2009 at 8:32 PM, David Farmer wrote: > Well where I think it leaves us, we should define some basic needs basis, > some common sense requirements that entitles you to increasing amounts of > address space. ?One thing I like about your proposal is that it eliminates > the detailed usage based justifications of IPv4 and the HD-Ratio concept we > tried to replace it with currently in IPv6. ?Have you ever tried to explain > HD-Ratios to a pointy haired boss or an accountant? > > But, what is wrong with some common sense limits? > > Like; > > 1. If you need any addresses you get a /56; > > 2. You don't need a /48 unless you have at least 256 host; > > That could be one host in each of the 256 subnets that a /56 gives you, or > 256 hosts in a single subnet. > > 3. You don't need a /40 unless you have more than one site; > > 4. If you reasonably expect to support more that 100 sites you probably > should have a /32; > > 5. You don't need anything more that a /32 unless you are supporting a big > bunch of sites, like 10,000 or more. Hi David, Wherever possible you want to think in terms of simplified classification vectors. If the vector is single/multihomed then the only thing I should have to do to change the class I'm in is add another ISP. I shouldn't have to pay more for the addresses. I shouldn't have to change the number of hosts I deploy. If the vector is cash I spend as a reflection of the value I assign to my network, then the only thing I should have to do to reach the next class is spend more money. If you want to look at host counts then that should be a separate vector. The only thing I should have to do to reach the next class is deploy more machines. I shouldn't have to spend more money or multihome. Think about this. If you limit the money=value vector based on a host count vector, you cut high value services off at the knees. Case and point: DNS. Each DNS root is one server or a small cluster of servers. Stick it in the same class as a home hobbyist with both a DSL and a cable modem? Ouch. Caution: adding additional vectors has a price. The number of allocation pools set aside can be multiplicative. 5 payment classes plus 2 ISP-count classes takes 10 pools. Add 5 host count levels and you have to set aside 50 pools! What are some of the problems with using host count as a classification vector and then tying the prefix length to the host count instead of the payment? 1. If you use it in addition to a payment classification vector, you might not save any addresses space. You'll have to set aside a lot of additional allocation pools, large parts of which will sit idle. 2. If you use it instead of a less technically-bound value vector like money spent, you skew the classification system against high-value low-host-count services. The DNS roots are an extreme case but server farms also suffer. 3. How do you determine what sort of host count is fair? HD-ratio is a mess but it was adopted because its about as close to fair as we were able to agree on along the host count classification vector. Also, at a technical level IPv6 addressing is structured along the idea of 64-bit subnets rather than variable size subnets accommodating 128-bit hosts. If we want to think about host count as a classification vector, maybe we should couch it in terms of LAN count instead. 4. Complexity. Counting hosts can be hard in a classical ISP scenario where you may not have any idea how many hosts live with each customer yet they consume your address space and count towards your classification. Counting money is comparably easy: a check was received. It didn't bounce. 5. It may not be necessary. The largest, most expensive possible allocation under 103 consumes the same percentage of the IPv6 address space as the smallest routeable allocation in IPv4. Think about the implications to that. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From sethm at rollernet.us Wed Dec 16 22:52:57 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 16 Dec 2009 19:52:57 -0800 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocation criteria In-Reply-To: <4AEB1581.8090607@arin.net> References: <4AEB1581.8090607@arin.net> Message-ID: <4B29AB19.1010005@rollernet.us> Member Services wrote: > > Policy Proposal 101: Multihomed initial allocation criteria > > Proposal Originator: Chris Grundemann > > Proposal Version: 1 > > Date: 30 October 2009 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Modify item number 4 under section 6.5.1.1. Initial allocation criteria > to the following: > > 4. be an existing, known ISP in the ARIN region or have a plan for > making at least 200 end-site assignments to other organizations within > 5 years or, if multihomed, demonstrate the efficient utilization of a > minimum contiguous or noncontiguous /44 (sixteen /48s) from an > upstream. > I support this proposal as written. (Must have missed this the first time around since I was moving an office on Oct. 29.) ~Seth From bill at herrin.us Wed Dec 16 22:54:36 2009 From: bill at herrin.us (William Herrin) Date: Wed, 16 Dec 2009 22:54:36 -0500 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocation criteria In-Reply-To: References: <4AEB1581.8090607@arin.net> Message-ID: <3c3e3fca0912161954g86a2b72pe208891db982e9dc@mail.gmail.com> On Wed, Dec 16, 2009 at 9:51 PM, cja at daydream.com wrote: > Hi everyone... > I have seen virtually no comments regarding this policy. ?I can't imagine > there is a lack of opinion out there... Hi Cathy, A) Proposal 101 does no harm relative to the rest of existing IPv6 policy. B) Proposal 101 is a superficial change to a fundamentally flawed policy. C) As it is presently impossible to multihome in IPv6 using a /44 cutout of an ISP's /32, proposal 101 doesn't make technical sense. I decline to support or oppose proposal 101. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scottleibrand at gmail.com Wed Dec 16 22:47:28 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 16 Dec 2009 22:47:28 -0500 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocation criteria In-Reply-To: References: <4AEB1581.8090607@arin.net> Message-ID: <4B29A9D0.2070807@gmail.com> It seems like a step in the right direction. But... here's a question for ARIN staff: If an organization gets an ORG ID, gets an allocation from their ISP, and starts reassigning space to customers (and SWIP'ing it), does that make them a "known ISP"? If so, then this policy may not actually change anything. If not, then perhaps we could just change 6.5.1.1 (d) to read "be an existing LIR in the ARIN region"? -Scott On 12/16/2009 9:51 PM, cja at daydream.com wrote: > Hi everyone... > > I have seen virtually no comments regarding this policy. I can't > imagine there is a lack of opinion out there... > > Happy Holidays! > -----Cathy > > On Fri, Oct 30, 2009 at 9:34 AM, Member Services > wrote: > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with Policy > Development > Process. > > This proposal is in the first stage of the Policy Development Process. > ARIN staff will perform the Clarity and Understanding step. Staff does > not evaluate the proposal at this time, their goal is to make sure > that > they understand the proposal and believe the community will as well. > Staff will report their results to the ARIN Advisory Council (AC) > within > 10 days. > > The AC will review the proposal at their next regularly scheduled > meeting (if the period before the next regularly scheduled meeting is > less than 10 days, then the period may be extended to the subsequent > regularly scheduled meeting). The AC will decide how to utilize the > proposal and announce the decision to the PPML. > > In the meantime, the AC invites everyone to comment on the proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their > deliberations. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 101: Multihomed initial allocation criteria > > Proposal Originator: Chris Grundemann > > Proposal Version: 1 > > Date: 30 October 2009 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Modify item number 4 under section 6.5.1.1. Initial allocation > criteria > to the following: > > 4. be an existing, known ISP in the ARIN region or have a plan for > making at least 200 end-site assignments to other organizations within > 5 years or, if multihomed, demonstrate the efficient utilization of a > minimum contiguous or noncontiguous /44 (sixteen /48s) from an > upstream. > > Rationale: > > The bar for obtaining initial IPv4 allocations is lower for those ISPs > which are multi-homed, it stands to reason that it also be lower in > IPv6. Since efficient utilization is based on the use of /48s, this > policy would effectively allow any ISP with 15 active customers (with > one /48 each and one /48 for the ISPs own network) to receive an > initial > allocation of an IPv6 /32 from ARIN. I think this is a better approach > than removing or lowering the end-site assignment requirement for > _all_ > ISPs while still providing more open access to IPv6. > > Timetable for implementation: immediate > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you > experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel at arneill-py.sacramento.ca.us Wed Dec 16 22:57:58 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 16 Dec 2009 19:57:58 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <20091216202051.GB3661@ussenterprise.ufp.org> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> <20091216202051.GB3661@ussenterprise.ufp.org> Message-ID: <471D76419F9EF642962323D13DF1DF690115EA@newserver.arneill-py.local> Leo, >> Michel Py wrote: >> This is just not true, and here's why: yes, Moore's law is still in >> effect. But guess what: link speed / bandwidth/ TE requirements / >> etc have evolved also, possibly even faster than Moore's law. > Leo Bicknell wrote: > I'm not quite sure Moore's law is the right analogy, > but I believe the concept you put forth is sound. I believe that it is more of an analogy, there is a direct relation as I will attempt to explain below: - The bandwidth on the Internet is driven by demand. - The demand is driven by devices that connect, namely computers and now TVs. - The {speed | power | memory} of these devices is directly related to Moore's law. - Michel's law 0.9 says: "A device that is twice as fast or has twice as much memory will consume twice as much bandwidth". Therefore I say: there is a direct relation between Moore's law and Internet bandwidth. Call this simple, simplified, simplistic, whatever. And debunk it please. Michel. From jmaimon at chl.com Wed Dec 16 23:03:28 2009 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 16 Dec 2009 23:03:28 -0500 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocation criteria In-Reply-To: References: <4AEB1581.8090607@arin.net> Message-ID: <4B29AD90.9080600@chl.com> cja at daydream.com wrote: > Hi everyone... > > I have seen virtually no comments regarding this policy. I can't > imagine there is a lack of opinion out there... > > Happy Holidays! > -----Cathy I support this proposal, even as I suspect its a no-op, and even as I have the following reservations, since now is not the time to keep a tight rein nor is it the time to let them drag on the ground. At 16 /48's with potentially one /48 per customer, thats a significantly lower bar than with IPv4 multihoming requirements, where a /24 per customer raises some eyebrows. I believe that efficiency and allocation guidelines need to be reconciled with a less ipv4-centric viewpoint. Judging efficiency by the # of assigned /48 basically penalizes organizations who choose to not follow allocation recommendations of /48 per site/customer and rewards those who disregard the /56 and any other bit-points in between /64 and /48. From bicknell at ufp.org Wed Dec 16 23:24:35 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 16 Dec 2009 20:24:35 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <471D76419F9EF642962323D13DF1DF690115EA@newserver.arneill-py.local> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> <20091216202051.GB3661@ussenterprise.ufp.org> <471D76419F9EF642962323D13DF1DF690115EA@newserver.arneill-py.local> Message-ID: <20091217042435.GA31550@ussenterprise.ufp.org> In a message written on Wed, Dec 16, 2009 at 07:57:58PM -0800, Michel Py wrote: > - The bandwidth on the Internet is driven by demand. > - The demand is driven by devices that connect, namely computers and now > TVs. > - The {speed | power | memory} of these devices is directly related to > Moore's law. > - Michel's law 0.9 says: "A device that is twice as fast or has twice as > much memory will consume twice as much bandwidth". > > Therefore I say: there is a direct relation between Moore's law and > Internet bandwidth. Call this simple, simplified, simplistic, whatever. > And debunk it please. http://singularity.com/images/charts/SuperComputers.jpg Computing power seems to double every 1.2 years, roughly. Note that this is loosely coupled to moore's law, but there is a relationship. Picking an arbitrary spot in time, in 1991 the first 14.4k modem was introduced. That was 18 years ago, or 15 doubling cycles, at the speed supercomputers have evolved. 14.4kbits * 2^15 is 450 Gigabits. So if you could afford a 14.4K modem in 1991 which, while expensive was something the average joe could afford. It might cost as much as your computer at that time, you should be able to afford a 450Gigabit home connection today. Video is a prime example. Quality has improved, but as much due to better compression as to more bandwidth. Turns out we burn a bunch of CPU cycles to conserve bandwidth, as bandwidth is vastly harder to increase. It may not seem like YouTube is saving bandwidth, but raw 1080i uncompresed video is ~1.5Gbits/sec, while YouTube has encoded it as ~12Megabits/sec. All the CPU is going to make up for the fact that we don't have 1.5Gbits/sec to the home. So no, twice the speed does not equal twice the bandwidth consumed. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From cgrundemann at gmail.com Wed Dec 16 23:41:37 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 16 Dec 2009 21:41:37 -0700 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocation criteria In-Reply-To: <3c3e3fca0912161954g86a2b72pe208891db982e9dc@mail.gmail.com> References: <4AEB1581.8090607@arin.net> <3c3e3fca0912161954g86a2b72pe208891db982e9dc@mail.gmail.com> Message-ID: <443de7ad0912162041t2b69c848k1543e47012ea6baa@mail.gmail.com> On Wed, Dec 16, 2009 at 20:54, William Herrin wrote: > On Wed, Dec 16, 2009 at 9:51 PM, cja at daydream.com wrote: >> Hi everyone... >> I have seen virtually no comments regarding this policy. ?I can't imagine >> there is a lack of opinion out there... > > Hi Cathy, > > A) Proposal 101 does no harm relative to the rest of existing IPv6 policy. > > B) Proposal 101 is a superficial change to a fundamentally flawed policy. Agreed > > C) As it is presently impossible to multihome in IPv6 using a /44 > cutout of an ISP's /32, proposal 101 doesn't make technical sense. I wrote this in haste and have meant to re-write it since, it really should read "organization intending to multihome." Every time I go to re-write it though I bump into your point B and have not taken the time to really asses what is needed -- I need to jump into the pp103 discussion and wrap my head back around this before attempting the re-write (or not). > > I decline to support or oppose proposal 101. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com ?bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From cgrundemann at gmail.com Wed Dec 16 23:43:55 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 16 Dec 2009 21:43:55 -0700 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocation criteria In-Reply-To: <4B29A9D0.2070807@gmail.com> References: <4AEB1581.8090607@arin.net> <4B29A9D0.2070807@gmail.com> Message-ID: <443de7ad0912162043h72c0dc5kea3abff9b408dffd@mail.gmail.com> On Wed, Dec 16, 2009 at 20:47, Scott Leibrand wrote: > It seems like a step in the right direction. > > But... here's a question for ARIN staff: > > If an organization gets an ORG ID, gets an allocation from their ISP, and > starts reassigning space to customers (and SWIP'ing it), does that make them > a "known ISP"? I am under the impression that you must have an existing ARIN allocation to be a "known ISP" in the ARIN region. > > If so, then this policy may not actually change anything. > > If not, then perhaps we could just change 6.5.1.1 (d) to read "be an > existing LIR in the ARIN region"? I am not positive on the wording but I think I like this approach. > > -Scott > > On 12/16/2009 9:51 PM, cja at daydream.com wrote: > > Hi everyone... > I have seen virtually no comments regarding this policy. ?I can't imagine > there is a lack of opinion out there... > Happy Holidays! > -----Cathy > > On Fri, Oct 30, 2009 at 9:34 AM, Member Services wrote: >> >> ARIN received the following policy proposal and is posting it to the >> Public Policy Mailing List (PPML) in accordance with Policy Development >> Process. >> >> This proposal is in the first stage of the Policy Development Process. >> ARIN staff will perform the Clarity and Understanding step. Staff does >> not evaluate the proposal at this time, their goal is to make sure that >> they understand the proposal and believe the community will as well. >> Staff will report their results to the ARIN Advisory Council (AC) within >> 10 days. >> >> The AC will review the proposal at their next regularly scheduled >> meeting (if the period before the next regularly scheduled meeting is >> less than 10 days, then the period may be extended to the subsequent >> regularly scheduled meeting). The AC will decide how to utilize the >> proposal and announce the decision to the PPML. >> >> In the meantime, the AC invites everyone to comment on the proposal on >> the PPML, particularly their support or non-support and the reasoning >> behind their opinion. Such participation contributes to a thorough >> vetting and provides important guidance to the AC in their deliberations. >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> The ARIN Policy Development Process can be found at: >> https://www.arin.net/policy/pdp.html >> >> Mailing list subscription information can be found >> at: https://www.arin.net/mailing_lists/ >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Policy Proposal 101: Multihomed initial allocation criteria >> >> Proposal Originator: Chris Grundemann >> >> Proposal Version: 1 >> >> Date: 30 October 2009 >> >> Proposal type: modify >> >> Policy term: permanent >> >> Policy statement: >> >> Modify item number 4 under section 6.5.1.1. Initial allocation criteria >> to the following: >> >> 4. be an existing, known ISP in the ARIN region or have a plan for >> making at least 200 end-site assignments to other organizations within >> 5 years or, if multihomed, demonstrate the efficient utilization of a >> minimum contiguous or noncontiguous /44 (sixteen /48s) from an >> upstream. >> >> Rationale: >> >> The bar for obtaining initial IPv4 allocations is lower for those ISPs >> which are multi-homed, it stands to reason that it also be lower in >> IPv6. ?Since efficient utilization is based on the use of /48s, this >> policy would effectively allow any ISP with 15 active customers (with >> one /48 each and one /48 for the ISPs own network) to receive an initial >> allocation of an IPv6 /32 from ARIN. I think this is a better approach >> than removing or lowering the end-site assignment requirement for _all_ >> ISPs while still providing more open access to IPv6. >> >> Timetable for implementation: immediate >> >> >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From scottleibrand at gmail.com Wed Dec 16 23:41:59 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 16 Dec 2009 23:41:59 -0500 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <20091217042435.GA31550@ussenterprise.ufp.org> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> <20091216202051.GB3661@ussenterprise.ufp.org> <471D76419F9EF642962323D13DF1DF690115EA@newserver.arneill-py.local> <20091217042435.GA31550@ussenterprise.ufp.org> Message-ID: <4B29B697.1000200@gmail.com> On 12/16/2009 11:24 PM, Leo Bicknell wrote: > In a message written on Wed, Dec 16, 2009 at 07:57:58PM -0800, Michel Py wrote: > >> - The bandwidth on the Internet is driven by demand. >> - The demand is driven by devices that connect, namely computers and now >> TVs. >> - The {speed | power | memory} of these devices is directly related to >> Moore's law. >> - Michel's law 0.9 says: "A device that is twice as fast or has twice as >> much memory will consume twice as much bandwidth". >> >> Therefore I say: there is a direct relation between Moore's law and >> Internet bandwidth. Call this simple, simplified, simplistic, whatever. >> And debunk it please. >> > http://singularity.com/images/charts/SuperComputers.jpg > > Computing power seems to double every 1.2 years, roughly. Note > that this is loosely coupled to moore's law, but there is a > relationship. > > Picking an arbitrary spot in time, in 1991 the first 14.4k modem > was introduced. That was 18 years ago, or 15 doubling cycles, at > the speed supercomputers have evolved. > > 14.4kbits * 2^15 is 450 Gigabits. > I'm showing 14400 * 2^15 = 471859200, which is ~450 Megabits, not Gigabits. (Is that right?) Gigabit Ethernet hardware today costs about the same (order of magnitude) as what 14.4k modems cost in 1991. You can even do GigE over SMF (to achieve approximately the same distance range) for not much more. Once we get into the question of what medium is comparable (twisted pair copper? cat5? MMF? SMF? PSTN? DWDM?), then obviously the question gets a lot more complicated. But as exponential doubling laws go, I think this one holds fairly well so far. The doubling time may not be exactly 1.2 years (I've heard 18 months), but it definitely looks like a similar curve to me... -Scott > So if you could afford a 14.4K modem in 1991 which, while expensive > was something the average joe could afford. It might cost as much > as your computer at that time, you should be able to afford a > 450Gigabit home connection today. > > Video is a prime example. Quality has improved, but as much due > to better compression as to more bandwidth. Turns out we burn a > bunch of CPU cycles to conserve bandwidth, as bandwidth is vastly > harder to increase. It may not seem like YouTube is saving bandwidth, > but raw 1080i uncompresed video is ~1.5Gbits/sec, while YouTube has > encoded it as ~12Megabits/sec. All the CPU is going to make up for > the fact that we don't have 1.5Gbits/sec to the home. > > So no, twice the speed does not equal twice the bandwidth consumed. > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel at arneill-py.sacramento.ca.us Thu Dec 17 00:27:03 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 16 Dec 2009 21:27:03 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <63ac96a50912161312wa172a50md2be009d1f9eba5b@mail.gmail.com> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> <4B292A0C.6070701@ipinc.net> <63ac96a50912161312wa172a50md2be009d1f9eba5b@mail.gmail.com> Message-ID: <471D76419F9EF642962323D13DF1DF690115EE@newserver.arneill-py.local> > Matthew Petach wrote: > You can get old 7k-class Cisco routers for $500 on eBay; > why aren't more people just running large clusters of $500 > routers, then? See the above cross-linking problem, and > look at the rack space cost to put them in; at your typical > facility like Equinix, at $1500/rack/month, if you can only > fit 3 7k-class routers per rack, if the router only costs > $500, you end up spending as much on space for the router as > your hardware cost *every month*. +1 You forgot the cost of electricity; colos charge or will charge for it. These days, if you're not "green", you look "bad". BTW, I have a mighty 7507 with dual RSPs to give away if someone cares to drive and pick it up. 200lbs. 12U. $100 a month of electricity just to power it up (not in winter, great heating system; in California summer it's another story). > Leo Bicknell wrote: > However, with high end routers there are actually a number of > new challenges. Much like PC's, they have hit the "Megahertz > Wall" and thus are moving to parallel processing solutions. Indeed; which is why I started this thread in the first place. Where is some kind of a sound barrier here; it does not mean it's a wall in the sky that will rip your ears off if you try to break it, but there are cost issues. If instead of DRAM we have to move to something equivalent to CPU L1 cache today, I will remind everyone that the current size is 8MBytes, which does not go far on a DFZ router. > The good news is packet processing is often easy to parallelize, > the bad news is that it is all new code and hardware for the > vendors. Someone is going to have to pay for that development. Guess who :-D > I don't think these physics challenges are going to stop 100GE or > other technologies, but they are going to disrupt the curve. > We've gotten used to 10M ethernet replaced 5 years later by 100M > for the same cost, replaced 5 years later by 1000M for the same > cost, replaced 5 years later by 10000M for the same cost. It > appears rather than seeing 100000M 5 years later and for the same > cost, we're going to see it 7 years later and for twice the cost. > (Ok, those are very crude estimates, but you get my drift.) I do; I steer clear of 100G predictions. >> Michel Py wrote: >> Michel's law 0.9 says: "A device that is twice as fast or has >> twice as much memory will consume twice as much bandwidth". > Leo Bicknell wrote: > http://singularity.com/images/charts/SuperComputers.jpg > [SNIP] > So no, twice the speed does not equal twice the bandwidth consumed. [Love the 2025 requirement, BTW. Where do I sign up?] Ok, come up with a formula? And read below, too. >> Michel's law 0.9 says: "A device that is twice as fast or has >> twice as much memory will consume twice as much bandwidth". > Scott Leibrand wrote: > I'm showing 14400 * 2^15 = 471859200, which is ~450 > Megabits, not Gigabits. (Is that right?) Same here. > The doubling time may not be exactly 1.2 years (I've heard 18 > months), but it definitely looks like a similar curve to me... Similar is the word. And although debating the actual value of the "multiplying factor" sounds interesting, I would welcome more feedback on the raw assertion that there is indeed a direct relationship between Moore's law and Internet bandwidth. Michel. From tyler at stephouse.net Thu Dec 17 00:57:05 2009 From: tyler at stephouse.net (Tyler Booth) Date: Wed, 16 Dec 2009 21:57:05 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <471D76419F9EF642962323D13DF1DF690115EE@newserver.arneill-py.local> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> <4B292A0C.6070701@ipinc.net> <63ac96a50912161312wa172a50md2be009d1f9eba5b@mail.gmail.com> <471D76419F9EF642962323D13DF1DF690115EE@newserver.arneill-py.local> Message-ID: On Dec 16, 2009, at 9:27 PM, Michel Py wrote: >> Matthew Petach wrote: >> You can get old 7k-class Cisco routers for $500 on eBay; >> why aren't more people just running large clusters of $500 >> routers, then? See the above cross-linking problem, and >> look at the rack space cost to put them in; at your typical >> facility like Equinix, at $1500/rack/month, if you can only >> fit 3 7k-class routers per rack, if the router only costs >> $500, you end up spending as much on space for the router as >> your hardware cost *every month*. > > +1 > > You forgot the cost of electricity; colos charge or will charge for it. > These days, if you're not "green", you look "bad". > > BTW, I have a mighty 7507 with dual RSPs to give away if someone cares > to drive and pick it up. 200lbs. 12U. $100 a month of electricity just > to power it up (not in winter, great heating system; in California > summer it's another story). We use our old 7507 as a coffee table in our office. AAUI and OC3 interfaces included Tyler Booth // President ph. 503.548.2000 | fx. 503.548.2002 921 SW Washington St, Suite 224 Portland OR 97205 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mysidia at gmail.com Thu Dec 17 02:04:50 2009 From: mysidia at gmail.com (James Hess) Date: Thu, 17 Dec 2009 01:04:50 -0600 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised In-Reply-To: <4B06D427.1080905@arin.net> References: <4B06D427.1080905@arin.net> Message-ID: <6eb799ab0912162304o2f97d0fcpb0a49a041f807a6e@mail.gmail.com> On Fri, Nov 20, 2009 at 11:38 AM, Member Services wrote: Making V6 allocation more like V4 or classful allocation does seem to have some major benefits, there's a lot to like about the proposal, and it's definitely an improvement to reduce the number of different prefix lengths that may be allocated .. but > 6.5.7. Existing IPv6 address space holders [...]> manner approaching 6.5.9.4 by increasing the prefix length of all >registrants within a particular pool to some specific minimum prefix >length for the pool. [..] Increasing the prefix length of an existing registration.... Also known as: taking back part of an allocation made earlier seems an exceeding harmful proposition. Unproven: That you can actually use an RIR address pool scheme to effectively filter out only TE routes. It's just as unproven that this is better as it's unproven that sparse allocation results in fewer announcements. The RIR isn't the only organization to allocate IPs. The ISP distinction is important. No matter how well ARIN pools allocations, ISPs can allocate /48s or /56s from e.g. in their shorter /32 prefix to downstream customers. Multi-homed customers of the ISP who do not otherwise have, want, or need their own AS number (or may become multi-homed at a later time after receiving the allocation from their ISP). As they have done in IPv4. You break connectivity if you only accept /32s from the ISP /32 PA block, which results in inability to effectively, safely filter. Unproven: That pooling RIR allocations by size alone actually makes filtering particularly easy in the long run. Suggested alternative... One way to allow more precise filtering in such cases would be to allow ISPs to have several allocations, from several RIR pools which the ISP must assign, according to the exact size, multi-homed status, and justified need of downstream customer IP address block they are allocating (e.g. the ISP has to make their allocations along the pool lines). One possibility would be to sub-divide: allocate /31s to ISPs, and require ISPs to keep the first bit inside the allocation to equal to zero, except for multi-homed sub-delegations of a designated prefix length. So that across the entire ISPs' assignments, longer prefixes could be filtered when the sub-delegation's multi-homed bit was zero; and end-users only ever get odd-numbered /32s directly from ARIN. E.g. Or another alternative would be to allocate ISPs an additional /32 or /40 from a separate block.. a "multi-block" for multi-homed /48s upon request, in addition to their PA space. Let ARIN require ISPs re-assign from "their" multi-block only to downstream multi-homed customers, every customer in the multi-block must be assigned a /48 exactly: require they be assigned sequentially (one after the other), RE-Assignment registered with ARIN registered, prior to use. /48 not announced until use: the multi-blocks don't _really_ belong to the ISP at all, the ISP may not announce the aggregate; ARIN can let the blocks be portable (with annual maintenance fee), and any announcements other than /48 are an end-user's TE routes. Let ARIN take back any or part of the un-assigned portion at any time, _and_ have a policy to actually do so, if /48s aren't actually being re-assigned. Aside from multi-blocks: let the ISP get another separate /32 or /40 from which they assign single-homed PA, the "normal" allocation; the ISP can announce the aggregate, and anything else is TE. For a larger amount of addresses than /48, don't let their ISP allocate it; force the end user to go to ARIN directly, and always assign a /40 or /32 to end-users. Justification _should_ be required. Fee-based disicentives are insufficient for large organizations, given the cost of renumbering. For ISP requests, only allow a /24 multi-block to be allocated to an ISP who can prove they have more than >20,000 multi-homed customers. Only allow a /24 PA block to be assigned to an ISP or org who can document that they have more than 1 million hosts to be attached to their network. Anyways, those are some thoughts.. [snip] > To prevent wasteful consumption of IPv6 address space without a > complicated eligibility regime, the author recommends an initial and > annual fee regime for IPv6 address allocations similar to: > /56 -- $10 USD > /48 -- $100 USD > /40 -- $1000 USD > /32 -- $10,000 USD > /24 -- $100,000 USD [snip] I don't like this fee table at all... /40 and /32 appear way too expensive, /56 and /48 are too cheap. An ISP with an IPv6 /32 should not pay more than an ISP needing a new IPv4 /16 every year. V6 adoption is already expensive without creating inflated IP fees. It (seems) a bit absurd for usable quantities of IPv6 address space alone to be 10x+ as expensive to maintain as IPv4 address space, especially given the nature of V6 addressing; it is not clear that it costs any more for ARIN to maintain such registrations. I expect prices to go _down_ with V6, not go up. There is, after all, more supply, and the demand is virtuallly non-existent. Do not believe ARIN should replace needs-based allocation with fee-based allocation sizing. Due to "6.5.9.2 No usage-based eligibility requirements shall apply to IPv6 allocations." _Every_ end-user might be inclined to seek a /56, however, eliminating some need for ISPs to get larger blocks. Since PI address space has so many advantages. $10 a year is too low to discourage the very large future eventual IPv6 user base from simply going directly to ARIN... It doesn't seem like it's sustainable. IPv4 equivalent to this would be allowing folks to register an IPv4 /26 for $10... probably not very useful, but maybe... However, If end-users get their V6 /56 or any resource from ARIN and then find they can't get their new block in the routing table (which is the most likely outcome), that is a bad thing, actually... Policy should definitely not ignore such considerations altogether.. -- -J From bill at herrin.us Thu Dec 17 03:55:35 2009 From: bill at herrin.us (William Herrin) Date: Thu, 17 Dec 2009 03:55:35 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised In-Reply-To: <6eb799ab0912162304o2f97d0fcpb0a49a041f807a6e@mail.gmail.com> References: <4B06D427.1080905@arin.net> <6eb799ab0912162304o2f97d0fcpb0a49a041f807a6e@mail.gmail.com> Message-ID: <3c3e3fca0912170055g1ab96409ja69f74c6cd5336ba@mail.gmail.com> On Thu, Dec 17, 2009 at 2:04 AM, James Hess wrote: > The RIR isn't the only organization to allocate IPs. The ISP > distinction is important. > > No matter how well ARIN pools allocations, ISPs ?can allocate ?/48s > or ?/56s ?from ?e.g. in their ? shorter /32 ?prefix to downstream > customers. > > Multi-homed customers of the ISP who do not otherwise have, want, or > need their own AS number ?(or may become multi-homed at a later time > after receiving the allocation from their ISP). > As they have done in IPv4. ? You break connectivity ?if you ?only > accept /32s ?from the ?ISP /32 ?PA block, which results in inability > to effectively, safely filter. Hi James, A: The status quo is that IPv6 ISP cutouts smaller than /32 are not separately routable on the backbone. Today. Right now. Some ISPs route them but enough don't that you're only fully connected via the ISP from which you got the IPs. B. This is a good thing. Lots of bad mojo from announcing cutouts. Makes a godawful mess of filtering and supporting it impairs a number of next generation routing architectures. Better for everybody if folks who mutlihome get their IP addresses direct from ARIN. >> 6.5.7. Existing IPv6 address space holders > [...]> manner approaching 6.5.9.4 by increasing the prefix length of all >>registrants within a particular pool to some specific minimum prefix >>length for the pool. > [..] > Increasing the prefix length of an existing registration.... Also > known as: taking back part of an allocation made earlier seems an > exceeding harmful proposition. Clarification: "increasing" in this context is intended to mean "shorten" the prefix length, increasing the size of the allocated block. Giving more, not taking back. Wordsmithing suggestions welcome. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From michael.dillon at bt.com Thu Dec 17 05:49:28 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 17 Dec 2009 10:49:28 -0000 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 AllocationProcess- revised In-Reply-To: <3c3e3fca0912161920j7e7c62f7g91bf0f22a190b29d@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C49745804898E3B@E03MVZ2-UKDY.domain1.systemhost.net> > 3. How do you determine what sort of host count is fair? You can't count hosts any more. And IPv6 no longer has the concept of a host. The /128 addresses are "interface IDs" and the thing that was called a host in IPv4, could have more than 1 interface. In addition, IPv6 allows for multiple interface IDs per interface. It is a different world. > HD-ratio is a mess but it was adopted because its about as > close to fair as we were able to agree on along the host > count classification vector. Also, at a technical level IPv6 > addressing is structured along the idea of 64-bit subnets > rather than variable size subnets accommodating 128-bit > hosts. If we want to think about host count as a > classification vector, maybe we should couch it in terms of > LAN count instead. Not to mention that HD ratio only affects the large ISPs who cannot live within their initial allocation. Note that the RIRs are perfectly willing to give larger ISPs an initial allocation bigger than /32 because we have no shortage of address space, and by giving a really big initial allocation we have a better chance of reducing the number of routes in the global routing table when IPv4 is shut off. --Michael Dillon From michael.dillon at bt.com Thu Dec 17 05:59:33 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 17 Dec 2009 10:59:33 -0000 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocationcriteria In-Reply-To: <443de7ad0912162043h72c0dc5kea3abff9b408dffd@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C49745804898E81@E03MVZ2-UKDY.domain1.systemhost.net> > I am under the impression that you must have an existing ARIN > allocation to be a "known ISP" in the ARIN region. An existing ARIN IPv4 allocation. In IPv6 the terminology of LIR is used, but in IPv4, ISP was used. --Michael Dillon From farmer at umn.edu Thu Dec 17 08:24:04 2009 From: farmer at umn.edu (David Farmer) Date: 17 Dec 2009 07:24:04 -0600 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process- revised In-Reply-To: <63883B32-DB38-49FD-9463-DFB5F210A563@delong.com> References: <4B06D427.1080905@arin.net> <4B22FE8A.6090806@umn.edu> <3c3e3fca0912131938u1f4944d4vfff928a25ddf81d1@mail.gmail.com> <693DF10B-E680-4ABB-9532-CA7A8E892B9A@delong.com> <3c3e3fca0912141542v67227024v8d4a597f91f67526@mail.gmail.com> <1BE798EE-65E8-46EC-9A49-B6E8ABB7A34F@akamai.com> <3c3e3fca0912142236l5ea57331u89c62e53783488a0@mail.gmail.com> <4B298A46.8020008@umn.edu> <63883B32-DB38-49FD-9463-DFB5F210A563@delong.com> Message-ID: On Dec 16 2009, Owen DeLong wrote: >On Dec 16, 2009, at 5:32 PM, David Farmer wrote: .... >> The primary limit is still going to be the fee structure, and it >> probably should be, but we need something to deal with those that >> have more money than sense. You might say if they want to waste >> there money, let them. However, this will create inequities that is >> easy for people to criticize, and if it gets bad enough it will >> create problems. >> >Indeed. However, it might not be an issue of more money than sense... >It might be an issue of more greed than anticipated. That is another possible explanation. I was trying to follow Halon's Razor, "Never attribute to malice that which can be adequately explained by stupidity." >> These are all simple enough, I could tell a pointy haired boss, an >> accountant, maybe even a congressman or a political appointee too, >> and for sure my grandma. They would all nod and would at least seem >> to understand what I am talking about. Talking to any of them about >> a HD-Ratios would make their heads explode or my teetotaling grandma >> to get a good stiff belt of grampa's whiskey. >> >I'm really not convinced that these are the metrics we should use to >judge whether a proposal is good policy. >Internet addressing is a technical field requiring a certain amount of >expertise. There is no reason that address >policy should not incorporate that expertise or be written to some >certain minimal level of it. > >Just as there is no expectation that the FDA could perform its duties >without medical experts, nor, is there >an expectation that drug laws do not contain medical terms that may >not be easily understood by lay persons. Personally, I believe true expertise is demonstrated by explaining a complicated subject in terms that a lay person can understand. Furthermore, not only has "needs basis" been a fundamental tenet of Internet resource allocation since the beginning, "KISS" has been a concept that historically permeates the Internet architecture. I find it difficult to reconcile HD Ratios and KISS, but that could be a personal failing of my own. >Owen > > From steve at ibctech.ca Thu Dec 17 09:01:39 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 17 Dec 2009 09:01:39 -0500 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocation criteria In-Reply-To: <4B29AD90.9080600@chl.com> References: <4AEB1581.8090607@arin.net> <4B29AD90.9080600@chl.com> Message-ID: <4B2A39C3.5050906@ibctech.ca> Joe Maimon wrote: > > cja at daydream.com wrote: > >> Hi everyone... >> >> I have seen virtually no comments regarding this policy. I can't >> imagine there is a lack of opinion out there... >> >> Happy Holidays! >> -----Cathy > > > I support this proposal, even as I suspect its a no-op, and even as I > have the following reservations, since now is not the time to keep a > tight rein nor is it the time to let them drag on the ground. > > At 16 /48's with potentially one /48 per customer, thats a significantly > lower bar than with IPv4 multihoming requirements, where a /24 per > customer raises some eyebrows. > > I believe that efficiency and allocation guidelines need to be > reconciled with a less ipv4-centric viewpoint. > > Judging efficiency by the # of assigned /48 basically penalizes > organizations who choose to not follow allocation recommendations of /48 > per site/customer and rewards those who disregard the /56 and any other > bit-points in between /64 and /48. Why not just drop the 'efficient use' part of the multi-homed part of the policy, and put the effort into ensuring the requesting site *is* multi-homed, and not just planning on it? Perhaps I'm off base here, but this may also lower the barrier to entry for some, and free up resources for ISPs. a) the requester won't have to request and implement space (to meet the efficient use criteria) from their provider just to get a PI block, just to have the provider un-provision the space a little while later so their client can get their own space b) entrants who are already multi-homed with IPv4 who have never implemented IPv6 don't ever have to worry about renumbering from PA space into PI Steve From scottleibrand at gmail.com Thu Dec 17 10:01:25 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 17 Dec 2009 10:01:25 -0500 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <471D76419F9EF642962323D13DF1DF690115EE@newserver.arneill-py.local> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> <4B292A0C.6070701@ipinc.net> <63ac96a50912161312wa172a50md2be009d1f9eba5b@mail.gmail.com> <471D76419F9EF642962323D13DF1DF690115EE@newserver.arneill-py.local> Message-ID: <4B2A47C5.8080206@gmail.com> On 12/17/2009 12:27 AM, Michel Py wrote: > >>> Michel's law 0.9 says: "A device that is twice as fast or has >>> twice as much memory will consume twice as much bandwidth". >>> > >> The doubling time may not be exactly 1.2 years (I've heard 18 >> months), but it definitely looks like a similar curve to me... >> > Similar is the word. And although debating the actual value of the > "multiplying factor" sounds interesting, I would welcome more feedback > on the raw assertion that there is indeed a direct relationship between > Moore's law and Internet bandwidth. > I've always looked at it from the supply side instead of the demand side (although both probably contribute). The cost of transporting a bit is a function of the cost to route it (electronics), and the cost to transport it (optics). Routing costs seem to be tied to some version of Moore's law. Although there are specialized components like TCAM that don't observe the exact same factors as general purpose CPUs, they seem to be on a similar exponential curve. Transport costs are somewhat more volatile, especially with regard to the amount of dark fiber available during and after the .com/telecom boom. But even given the now relatively fixed amount of cheap dark fiber available, improvements in link speeds and DWDM capacities have resulted in what appears to be an exponential improvement in transport costs, which looks to continue at least in the near and medium term. -Scott From jmaimon at chl.com Thu Dec 17 10:05:39 2009 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 17 Dec 2009 10:05:39 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 AllocationProcess- revised In-Reply-To: <28E139F46D45AF49A31950F88C49745804898E3B@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745804898E3B@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B2A48C3.6080609@chl.com> michael.dillon at bt.com wrote: > >> 3. How do you determine what sort of host count is fair? > > You can't count hosts any more. And IPv6 no longer has the > concept of a host. The /128 addresses are "interface IDs" > and the thing that was called a host in IPv4, could have > more than 1 interface. In addition, IPv6 allows for multiple > interface IDs per interface. It is a different world. The only thing different in this so-called new world is terminology changes. IPv4 hosts are quite capable of more than one interface and of more than one address per interface. The change in terminology is a result of pervasive practice in IPv4 leading to discomfort with the "old" terms. It is also an attempt to prod gear and software producers into handling this practice more robustly. It is not new and earth changing. > --Michael Dillon From michael.dillon at bt.com Thu Dec 17 10:24:26 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 17 Dec 2009 15:24:26 -0000 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 AllocationProcess- revised Message-ID: <28E139F46D45AF49A31950F88C49745804914EF0@E03MVZ2-UKDY.domain1.systemhost.net> > > 3. How do you determine what sort of host count is fair? > > You can't count hosts any more. And IPv6 no longer has the > concept of a host. The /128 addresses are "interface IDs" > and the thing that was called a host in IPv4, could have more > than 1 interface. In addition, IPv6 allows for multiple > interface IDs per interface. It is a different world. That should say "multiple IP addresses per interface". --Michael Dillon From bicknell at ufp.org Thu Dec 17 15:19:48 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 17 Dec 2009 12:19:48 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <4B29B697.1000200@gmail.com> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> <20091216202051.GB3661@ussenterprise.ufp.org> <471D76419F9EF642962323D13DF1DF690115EA@newserver.arneill-py.local> <20091217042435.GA31550@ussenterprise.ufp.org> <4B29B697.1000200@gmail.com> Message-ID: <20091217201948.GA3723@ussenterprise.ufp.org> In a message written on Wed, Dec 16, 2009 at 11:41:59PM -0500, Scott Leibrand wrote: > 14.4kbits * 2^15 is 450 Gigabits. > > I'm showing 14400 * 2^15 = 471859200, which is ~450 Megabits, not > Gigabits. (Is that right?) Doh, quite right, 450 Megabits. Still, you can't buy a GigE router at Best Buy, at all. (As a minor nit, you can buy a router with GigE, but not one that will route even a fraction of it). > Gigabit Ethernet hardware today costs about the same (order of > magnitude) as what 14.4k modems cost in 1991. You can even do GigE > over SMF (to achieve approximately the same distance range) for not > much more. Once we get into the question of what medium is comparable > (twisted pair copper? cat5? MMF? SMF? PSTN? DWDM?), then obviously the > question gets a lot more complicated. But as exponential doubling laws > go, I think this one holds fairly well so far. The doubling time may > not be exactly 1.2 years (I've heard 18 months), but it definitely > looks like a similar curve to me... If the sole issue was the hardware interface; e.g. the cost of the modulation hardware in the modem compared to the cost of a GigE chipset you might be right; but that is not "bandwidth", that's simple hardware, and back to Mores law. However, the interface cost is only a small player in "bandwidth" costs. Routing it takes more than just interfaces.... http://newsroom.cisco.com/dlls/1993/prod_062193h.html A 2 port 10 Megabit ethernet router was $5,495 list. A Cisco 7301 router today (3xGigE) is ~$20,000 list. That $5495 adjusted for inflation would be $8331. So in fact a router today costs "twice as much" adjusted for inflation. Of course, that's still not the entire picture. Bandwidth costs are "cumulative". If your traceroute to say www.arin.net goes through 7 routers, then the cost to "upgrade your connection" from 100M to 1000M for instance is 7 times the cost of upgrading an individual box. So you're having to pay your service provider for 6 of those (figuring you own the end box). As the network footprint expands, the number of routers in the path expands, and the cost to provide you service increases as a result. But wait, there's more. In 1991 probably 99% of residental users were wired for 14.4 modems (e.g. had a phone line). You buy the hardware and you're good to go. In 2009, what percentage of homes can get GigE service? 1%? I doubt it rises even that high. The fastest service I've seen for residential users in the US is 100M FIOS, where available. The problem is that the way we've cost controled Ethernet chips down to $1 parts is by requiring more from the cabling. Rather than using the copper in the ground and in the walls, it's 4 pair Cat 5e, or fiber. Even fiber has not proven to be future proof. Some of the original fiber put in the ground in the early 1990's does not support 10G WDM systems (at least, over any length) and had to be overlayed in the 2000's with better quality fiber to keep up with network demand. The question becomes, "what is bandwidth": Chipset availability for higher speeds: Follows Moores Law. Router availability for higher speeds: Follows Moores Law. Router cost for higher speeds: Expands with network diameter. Availability of bandiwdth: Expands with capital cable investment. On the last point: http://arstechnica.com/tech-policy/news/2007/05/survey-average-broadband-speed-in-us-is-1-9mbps.ars In 2007 the average broadband speed in the US was 1.9 Megabits. If we use the 14.4k modem in 1991 as our comparison again that's approximately 7 doublings, where as Moores law has taken us through 15 in the same time. If you're up on exponential curves that means the curves are diverging, and at an ever accelerating rate. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From marty at akamai.com Thu Dec 17 16:45:21 2009 From: marty at akamai.com (Martin Hannigan) Date: Thu, 17 Dec 2009 16:45:21 -0500 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <471D76419F9EF642962323D13DF1DF690115EE@newserver.arneill-py.local> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local><457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v><471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local><4B292A0C.6070701@ipinc.net><63ac96a50912161312wa172a50md2be009d1f9eba5b@mail.gmail.com> <471D76419F9EF642962323D13DF1DF690115EE@newserver.arneill-py.local> Message-ID: On Dec 17, 2009, at 12:27 AM, Michel Py wrote: > > Matthew Petach wrote: > > You can get old 7k-class Cisco routers for $500 on eBay; > > why aren't more people just running large clusters of $500 > > routers, then? See the above cross-linking problem, and > > look at the rack space cost to put them in; at your typical > > facility like Equinix, at $1500/rack/month, if you can only > > fit 3 7k-class routers per rack, if the router only costs > > $500, you end up spending as much on space for the router as > > your hardware cost *every month*. > > +1 > > You forgot the cost of electricity; colos charge or will charge for > it.y > These days, if you're not "green", you look "bad". > Green has zero to do with this discussion. It's all about costs. If the power to drive a 7k is more than the power to drive something newer over a useful life the choice is pretty clear to those of us adept at making money. -M< From joelja at bogus.com Thu Dec 17 17:16:47 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 17 Dec 2009 14:16:47 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <20091217201948.GA3723@ussenterprise.ufp.org> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> <20091216202051.GB3661@ussenterprise.ufp.org> <471D76419F9EF642962323D13DF1DF690115EA@newserver.arneill-py.local> <20091217042435.GA31550@ussenterprise.ufp.org> <4B29B697.1000200@gmail.com> <20091217201948.GA3723@ussenterprise.ufp.org> Message-ID: <4B2AADCF.6070902@bogus.com> Leo Bicknell wrote: > In a message written on Wed, Dec 16, 2009 at 11:41:59PM -0500, Scott Leibrand wrote: >> 14.4kbits * 2^15 is 450 Gigabits. >> >> I'm showing 14400 * 2^15 = 471859200, which is ~450 Megabits, not >> Gigabits. (Is that right?) > > Doh, quite right, 450 Megabits. > > Still, you can't buy a GigE router at Best Buy, at all. (As a minor > nit, you can buy a router with GigE, but not one that will route > even a fraction of it). Actually WRT610n will route (as in make a layer-3 forwarding decision) about 300Mb/s it costs around $150, and yeah you can buy it a best buy. From tyler at stephouse.net Thu Dec 17 18:26:39 2009 From: tyler at stephouse.net (Tyler Booth) Date: Thu, 17 Dec 2009 15:26:39 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <4B2AADCF.6070902@bogus.com> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> <20091216202051.GB3661@ussenterprise.ufp.org> <471D76419F9EF642962323D13DF1DF690115EA@newserver.arneill-py.local> <20091217042435.GA31550@ussenterprise.ufp.org> <4B29B697.1000200@gmail.com> <20091217201948.GA3723@ussenterprise.ufp.org> <4B2AADCF.6070902@bogus.com> Message-ID: > Leo Bicknell wrote: >> In a message written on Wed, Dec 16, 2009 at 11:41:59PM -0500, Scott Leibrand wrote: >>> 14.4kbits * 2^15 is 450 Gigabits. >>> >>> I'm showing 14400 * 2^15 = 471859200, which is ~450 Megabits, not >>> Gigabits. (Is that right?) >> >> Doh, quite right, 450 Megabits. >> >> Still, you can't buy a GigE router at Best Buy, at all. (As a minor >> nit, you can buy a router with GigE, but not one that will route >> even a fraction of it). > > Actually WRT610n will route (as in make a layer-3 forwarding decision) > about 300Mb/s it costs around $150, and yeah you can buy it a best buy. NAT is not routing. You can however pick up a Mikrotik Routerboard RB1000 for less than $700 (not at best buy, but easy to find on the web) and it can forward 3.2Gbit/sec or 400,000pps. It also supports IPv6, BGP, and MPLS. If you're looking for consumer grade their smaller RB450G is under $100 and handles about 950Mbit or 140,000pps. It too supports IPv6, BGP, and MPLS but doesn't have enough RAM to handle a full IPv4 BGP route table. Tyler Booth // President ph. 503.548.2000 | fx. 503.548.2002 921 SW Washington St, Suite 224 Portland OR 97205 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rw at firstpr.com.au Thu Dec 17 20:02:24 2009 From: rw at firstpr.com.au (Robin Whittle) Date: Fri, 18 Dec 2009 12:02:24 +1100 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation Message-ID: <4B2AD4A0.6080908@firstpr.com.au> Further to the threads: A challenge to the assumption that a big DFZ is a problem debunking the myth that Moore's law helps the IRTF RRG is about to decide on its recommendation to the IETF about scalable routing. Charter: http://www.irtf.org/charter?gtype=rg&group=rrg Wiki: http://tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup List archives: http://www.ietf.org/mail-archive/web/rrg/current/maillist.html Proposals need to be in by 22 December: http://www.ietf.org/mail-archive/web/rrg/current/msg05489.html In mid-2007 the RRG took over the discussions from the RAM list, which was established following the October IAB Workshop on Routing and Addressing workshop (RAWS) in Amsterdam: http://tools.ietf.org/html/rfc4984 http://www.iab.org/about/workshops/routingandaddressing/ For most of this time, discussion of actual proposals has been discouraged or banned. However, now there is discussion of a bunch of *proposals*, in order to finalise a recommendation to the IETF by 2010-03. - Robin From bicknell at ufp.org Thu Dec 17 21:00:45 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 17 Dec 2009 18:00:45 -0800 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <4B2AD4A0.6080908@firstpr.com.au> References: <4B2AD4A0.6080908@firstpr.com.au> Message-ID: <20091218020045.GA24163@ussenterprise.ufp.org> In a message written on Fri, Dec 18, 2009 at 12:02:24PM +1100, Robin Whittle wrote: > the IRTF RRG is about to decide on its recommendation to the > IETF about scalable routing. I'm hoping you can fill in a gap for me, as I don't follow this work very closely. In looking at the problems with the current Internet it appears most of the blame is laid at the feet of BGP4. BGP has a number of properties that lead to scaling issues, some well documented, some not so well documented. All the solutions I see proposed though are fundamental changes to how we do addressing. Locator-Identifier separation ideas, alternate lookup databases (e.g. DNS), translation solutions, including simple NAT and address embedding. What I haven't seen is anything that makes the leap from "BGP is broken" to "the whole architecture must be changed". More specifically, I haven't seen anyone look at BGPv5, or a brand new replacement routing protocol. It seems that improving the system and fixing some of the known issues may be useful if nothing else as a stopgap, and yet no one seems to be working seriously on the issue. I also haven't seen any analysis on how much of the issues with BGP scaling come from things that have been lumped on to BGP, like MPLS VPN's. That is, if we hadn't added these things to BGP would we have no scaling problems at the current time? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From michel at arneill-py.sacramento.ca.us Thu Dec 17 22:45:34 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 17 Dec 2009 19:45:34 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <4B2A47C5.8080206@gmail.com> References: <471D76419F9EF642962323D13DF1DF690115D6@newserver.arneill-py.local> <457FCAE8ADA24640AB2FFF322DE300F6@johnsonvhjjf8v> <471D76419F9EF642962323D13DF1DF690115E1@newserver.arneill-py.local> <4B292A0C.6070701@ipinc.net> <63ac96a50912161312wa172a50md2be009d1f9eba5b@mail.gmail.com><471D76419F9EF642962323D13DF1DF690115EE@newserver.arneill-py.local> <4B2A47C5.8080206@gmail.com> Message-ID: <471D76419F9EF642962323D13DF1DF690115F9@newserver.arneill-py.local> > Scott Leibrand wrote: > I've always looked at it from the supply side instead of > the demand side (although both probably contribute). That is a very valid point, and although I would have a few arguments about the demand side driving the supply side, I will not start a discussion about this because it would be as productive as the chicken and egg problem. The relation between supply and demand is complex. > The cost of transporting a bit is a function of the cost to route > it (electronics), and the cost to transport it (optics). Routing > costs seem to be tied to some version of Moore's law. Although > there are specialized components like TCAM that don't observe the > exact same factors as general purpose CPUs, they seem to be on a > similar exponential curve. Agree. Back to the original topic, can we agree that Moore's law does not help building faster routers and might even have a negative side, because the general purpose CPU may be on a faster version of Moore's law than TCAM? > Joel Jaeggli wrote: > Actually WRT610n will route (as in make a layer-3 forwarding decision) > about 300Mb/s it costs around $150, and yeah you can buy it a best buy. > Tyler Booth wrote: > NAT is not routing. I will point out that NATing is actually more work than routing (if the routing table is small) as it has to replace addresses and port numbers, and sometimes requires the ALG to de-encapsulate higher layers. Joel, the WRT610n does NAT at 300Mb/s? I mean measured in the real world, not only manufacturer's marketing? Gee I'd like to have that kind of residential bandwidth for sure. I've never seen anything that comes with a GigE interface yet. Michel. From bill at herrin.us Fri Dec 18 01:24:57 2009 From: bill at herrin.us (William Herrin) Date: Fri, 18 Dec 2009 01:24:57 -0500 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <20091218020045.GA24163@ussenterprise.ufp.org> References: <4B2AD4A0.6080908@firstpr.com.au> <20091218020045.GA24163@ussenterprise.ufp.org> Message-ID: <3c3e3fca0912172224x62ccd1b6n34cc937e3385de55@mail.gmail.com> On Thu, Dec 17, 2009 at 9:00 PM, Leo Bicknell wrote: > What I haven't seen is anything that makes the leap from "BGP is > broken" to "the whole architecture must be changed". ?More specifically, > I haven't seen anyone look at BGPv5, or a brand new replacement > routing protocol. Hi Leo, Here's a clip from the intro to an internet draft I'm preparing which may explain it: Efficient Internet routing is all about aggregation. Combine multiple downstream routes into a single CIDR prefix sent upstream and all is well in the world. Fail and the routing table grows, the cost of routers rises and the general stability of the Internet falls. Because of how TCP and the various UDP-based transport protocols interact with the IP address, multihoming and mobility can defeat aggregation. These protocols require the IP address to remain the same throughout their operation. Any time a host changes its location within the network without also changing its IP address, knowledge about that address becomes disaggregate with its neighbors. The change must be propagated throughout the entire network. Routing researchers believe that if the host could readily change its IP addresses to match its attachment to the network then the network wouldn't have to change its routing to match the host's movement. This would improve aggregation and reduce the frequency of routing updates needed to keep the network operating. They call this concept "locator/identifier separation." Locator/identifier separation's premise is simple: don't use the IP address for both forwarding packets through the network and associating those packets with their respective endpoints. Instead, separate this overloaded functionality into distinct elements within each packet: locators used solely for forwarding packets and identifiers used to associate those packets with specific hosts, services and sessions. Practically speaking, this means we can either treat the IP address as a host identifier and build an overlay to the routing system with a new locator field somewhere in the packet or we can treat the IP address as a locator and introduce new elements into the transport protocols to figure out which packets belong to who. > It seems that improving the system and fixing > some of the known issues may be useful if nothing else as a stopgap, > and yet no one seems to be working seriously on the issue. That would be the IETF GROW working group. They're plenty serious but they've run short on ideas. Hence the RRG's exploration of potential next-generation architectures. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rw at firstpr.com.au Fri Dec 18 04:20:54 2009 From: rw at firstpr.com.au (Robin Whittle) Date: Fri, 18 Dec 2009 20:20:54 +1100 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <20091218020045.GA24163@ussenterprise.ufp.org> References: <4B2AD4A0.6080908@firstpr.com.au> <20091218020045.GA24163@ussenterprise.ufp.org> Message-ID: <4B2B4976.2070302@firstpr.com.au> Short version: Why no-one is seriously suggesting fixing the routing scaling problem by upgrading BGP alone. Constraints on solutions posed by the need for voluntary adoption. My objections to requiring all hosts to do more Routing and Addressing work than at present. At present, they don't do any - unless they are mobile, in which case they do just a little. I think current host stack and app functionality and the current BGP-based DFZ will be fine in the long-term future provided we have: 1 - A core-edge separation scheme such as Ivip. 2 - We use the TTR approach to mobility - based on the core-edge separation scheme, to scalably support global mobility for both IPv4 and IPv6 in a way which requires no changes to non-mobile hosts. Hi Leo, Opinions on scalable routing vary widely. Here's my response. >> the IRTF RRG is about to decide on its recommendation to the >> IETF about scalable routing. > > I'm hoping you can fill in a gap for me, as I don't follow this > work very closely. > > In looking at the problems with the current Internet it appears > most of the blame is laid at the feet of BGP4. BGP has a number > of properties that lead to scaling issues, some well documented, > some not so well documented. Can you mention those which you think are not well documented? > All the solutions I see proposed though are fundamental changes to > how we do addressing. Locator-Identifier separation ideas, alternate > lookup databases (e.g. DNS), translation solutions, including simple > NAT and address embedding. Core-edge separation schemes are sometimes also known as "map encap" or (incorrectly) "locator/identifier separation" schemes. In my next message to Bill Herrin I discuss what I think is the incorrect use of "locator/identifier separation" for core-edge separation schemes. HIP is a real "locator/identifier separation" scheme. Core-edge separation schemes (LISP, APT, Ivip and TRRP) don't alter the functions of hosts or most internal routers. They just provide a new set of end-user address prefixes which are portable to any ISP with an ETR, and which are not advertised directly in the DFZ. A covering prefix, including many such longer prefixes, is advertised by special ITRs ("Open ITRs in the DFZ" is the Ivip term, "Proxy Tunnel Routers" is the LISP term) so these routers collect packets sent by hosts in networks without ITRs and tunnel those packets to the correct address. APT and TRRP have functionally similar arrangements for packets sent from networks without ITRs. >From the point of view of host stacks and applications, the adoption of a core-edge separation scheme is not a change to addressing or to anything else. A true "locator/identifier separation" scheme such as HIP certainly does change the host's functionality regarding addressing. > What I haven't seen is anything that makes the leap from "BGP is > broken" to "the whole architecture must be changed". More specifically, > I haven't seen anyone look at BGPv5, or a brand new replacement > routing protocol. It seems that improving the system and fixing > some of the known issues may be useful if nothing else as a stopgap, > and yet no one seems to be working seriously on the issue. The first difficulty is that a new routing protocol can never be introduced to replace BGP4 unless it is fully backwards compatible - and no-one has devised such a thing AFAIK. The second is that it is pretty tricky to come up with a protocol for the Internet's interdomain routing system which could cope with the growth in the number of separately advertised end-user networks. There could be millions or billions of separate prefixes which end-user networks, including mobile devices, need to keep no matter where they physically connect to the Net. > I also haven't seen any analysis on how much of the issues with BGP > scaling come from things that have been lumped on to BGP, like MPLS > VPN's. That is, if we hadn't added these things to BGP would we > have no scaling problems at the current time? AFAIK, the problems are inherent in trying to make 200k (my estimate - 123k was a minimum figure two years ago - see my message to Bill) or more DFZ routers maintain BGP conversations with all their neighbours - involving a separate conversation about each advertised prefix, of which there are currently (http://bgp.potaroo.net/) about 300k with a doubling time of 4 or 5 years. The goal is to be able to accommodate millions or billions of separate, multihomable, portable, subnets of end-user address space in a scalable manner. Even if the DFZ routers' FIBs could handle this, there's no way the RIB and the global BGP control plane can scale to these numbers. All this was pretty much agreed in the RAWS workshop in late 2006. In my view, there are two major classes of proposal: 1 - Those which can work with IPv4 and IPv6 and have a hope of being accepted widely enough on a voluntary basis. 2 - Those which don't - they either don't work for IPv4 or they involve host changes or some other major thing which means they can't be adopted widely enough on a voluntary basis. I am only interested in the first set. No-one has figured out a way to replace BGP4 in a manner which could be voluntarily adopted - that is, in a way which would generate immediate nett benefits for early adoptors, without significant disruption to anyone. The first class, I think, consists of the core-edge separation schemes LISP-ALT, APT, Ivip and Bill Herrin's TRRP. My list of constraints imposed by the need for widespread voluntary adoption is here: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ In RRG discussions, I have had some support for this list being accurate - though of course no-one likes having such constraints. No-one has suggested that this list is flawed. Many of the proposals now being made for the RRG process seem to involve host changes - specifically making the host responsible for more routing and addressing things than in the past. This is for *every* host, not just for mobile hosts. Even if it were possible to change host stack and/or app functionality, for IPv4 and/or IPv6, I would still argue against it. As I wrote to the RRG nearly two weeks ago: http://www.firstpr.com.au/ip/ivip/RRG-2009/host-responsibilities/ there are major objections to requiring all hosts to be more complex and to require them to handle the extra management traffic which comes with their new Routing and Addressing responsibilities. Even if these objections could be overcome, I would still object to it because it significantly slows down the ability to send the first packet of user data. This slowness depends on the RTT between the hosts, and is greatly exacerbated by a lost packet in the initial management exchange which must precede (AFAIK) the packet which actually contains the user traffic packet. These objections are at odds with some of the current RRG proposals, which involve new host functions along the lines of HIP. I haven't had any bites yet, but I am sure I will when I raise these objections during the discussions of the next two months. I think it will be a pretty good long-term arrangement to keep BGP4 running the interdomain routing system, as long as the number of prefixes doesn't grow too much. I think the routing and addressing system should provide hosts with IP addresses they can actually use, rather than requiring all hosts to manage physical and logical addresses (locator address and identifier address) themselves. In the case of mobility, I think hosts need to a little extra work. The best way I can think of doing it is the TTR mobility approach: http://www.firstpr.com.au/ip/ivip/RRG-2009/host-responsibilities/ which would work with any core-edge separation scheme. Mapping changes are only required when the MN moves a large distance, such as 1000km or more - not whenever it changes its physical address. My scalable routing proposal - Ivip - is summarised here: http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf 10371 words http://www.firstpr.com.au/ip/ivip/Ivip-RRG.html 2100 words http://www.firstpr.com.au/ip/ivip/Ivip-RRG-1kw.html 995 words - Robin From rw at firstpr.com.au Fri Dec 18 04:28:14 2009 From: rw at firstpr.com.au (Robin Whittle) Date: Fri, 18 Dec 2009 20:28:14 +1100 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <3c3e3fca0912172224x62ccd1b6n34cc937e3385de55@mail.gmail.com> References: <4B2AD4A0.6080908@firstpr.com.au> <20091218020045.GA24163@ussenterprise.ufp.org> <3c3e3fca0912172224x62ccd1b6n34cc937e3385de55@mail.gmail.com> Message-ID: <4B2B4B2E.9070909@firstpr.com.au> Hi Bill, You wrote, in part: > Efficient Internet routing is all about aggregation. Combine > multiple downstream routes into a single CIDR prefix sent upstream > and all is well in the world. Fail and the routing table grows, the > cost of routers rises and the general stability of the Internet falls. Yes, assuming we keep the current interdomain routing system with its BGP-based DFZ. I support these remaining. No-one has a practical way of introducing something else. Also, it is harder for the increasing number of end-user networks which need multihoming and portability to get it. > Because of how TCP and the various UDP-based transport protocols > interact with the IP address, multihoming and mobility can defeat > aggregation. Because the only way of doing multihoming at present is to get your own PI space and advertise it in the DFZ. > These protocols require the IP address to remain the > same throughout their operation. Any time a host changes its > location within the network without also changing its IP address, > knowledge about that address becomes disaggregate with its neighbors. > The change must be propagated throughout the entire network. Yes - there's no solid estimate of the number of DFZ routers, but 123k was the best estimate anyone could find in August 2007: http://www.ops.ietf.org/lists/rrg/2007/msg00253.html Every one of those DFZ routers has to develop a best path for every end-user network - and may have to do extra work whenever that network advertises its prefix from a different point in the topology. > Routing researchers believe that if the host could readily change its > IP addresses to match its attachment to the network then the network > wouldn't have to change its routing to match the host's movement. > This would improve aggregation and reduce the frequency of routing > updates needed to keep the network operating. They call this concept > "locator/identifier separation." This is a host-based approach, such as with HIP. Within the RRG and the scalable routing field, "Locator/Identifier Separation" is often used to refer to core-edge separation schemes (see my previous message to Leo Bicknell), especially since one of them is called (the) Locator Identifier Separation Protocol (LISP). But LISP doesn't really do this. HIP is the real deal for Locator/Identifier Separation. So I agree with your use of the term. I am just noting that I think the term has been widely misused in recent years. I also agree that if hosts did this, we could keep the existing interdomain routing system and put all end-user networks on inherently scalable PA space from their ISP. Then, multihoming and inbound TE involves switching a whole network from one ISP's PA prefix to another. Portability is portability of the logical address space assigned to the end-user network, which is a different kind of address space - in a different namespace - from the physical connection addresses of the PA space. (It would also be possible to do it with locator and identifier addresses being of the same type: sharing the same namespace - just different subsets of the one range of numbers.) However, as noted below, I have strong objections to all hosts being required to do this. So I support a core-edge separation approach instead. > Locator/identifier separation's premise is simple: don't use the IP > address for both forwarding packets through the network and > associating those packets with their respective endpoints. Instead, > separate this overloaded functionality into distinct elements within > each packet: locators used solely for forwarding packets and > identifiers used to associate those packets with specific hosts, > services and sessions. > > Practically speaking, this means we can either treat the IP address > as a host identifier and build an overlay to the routing system with > a new locator field somewhere in the packet or we can treat the IP > address as a locator and introduce new elements into the transport > protocols to figure out which packets belong to who. In a theoretical sense, I agree this would be a good thing to do: keep the network simple and make the hosts do more work. This is what made the Internet such a great thing compared to the phone network. Every host gets a potentially unstable PA address, and can move itself to any other PA address while retaining its application level address and continuing host-to-host sessions. However, this is at odds with my argument that it is wrong to burden all hosts with such extra responsibilities. I summarised these objections in my previous message to Leo. They are at: http://www.firstpr.com.au/ip/ivip/RRG-2009/host-responsibilities/ - Robin From dave at connetrix.com Fri Dec 18 08:15:19 2009 From: dave at connetrix.com (Dave Feuer ) Date: Fri, 18 Dec 2009 08:15:19 -0500 Subject: [arin-ppml] debunking the myth that Moore's law helps Message-ID: <200912180815.AA54264012@connetrix.com> ---------- Original Message ---------------------------------- From: "Michel Py" Date: Thu, 17 Dec 2009 19:45:34 -0800 >Joel, the WRT610n does NAT at 300Mb/s? I mean measured in the >real >world, not only manufacturer's marketing? > In "real word" tests it does about 50% to 60% of that. The older 600 was a bit faster. But still not bad for something you can pick up for $179 or less at WalMart. -Dave ________________________________________________________________ Sent via the WebMail system at connetrix.com From bicknell at ufp.org Fri Dec 18 10:51:53 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 18 Dec 2009 07:51:53 -0800 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <4B2B4976.2070302@firstpr.com.au> References: <4B2AD4A0.6080908@firstpr.com.au> <20091218020045.GA24163@ussenterprise.ufp.org> <4B2B4976.2070302@firstpr.com.au> Message-ID: <20091218155153.GA78343@ussenterprise.ufp.org> Thanks Robin for a very complete reply. No matter how cantankerous I may seem in e-mail I really appreciate it. There's a lot to follow here and most folks just don't have the time. In a message written on Fri, Dec 18, 2009 at 08:20:54PM +1100, Robin Whittle wrote: > > In looking at the problems with the current Internet it appears > > most of the blame is laid at the feet of BGP4. BGP has a number > > of properties that lead to scaling issues, some well documented, > > some not so well documented. > > Can you mention those which you think are not well documented? I think the effects of how ISP's configure BGP on the performance have been relatively poorly studied. What I see mostly are lab tests, there are very few studies tracking CPU usage or propogation times in the real Internet and relating that back to protocol or configuration weakless. > Core-edge separation schemes (LISP, APT, Ivip and TRRP) don't alter > the functions of hosts or most internal routers. They just provide a > new set of end-user address prefixes which are portable to any ISP > with an ETR, and which are not advertised directly in the DFZ. A > covering prefix, including many such longer prefixes, is advertised > by special ITRs ("Open ITRs in the DFZ" is the Ivip term, "Proxy > Tunnel Routers" is the LISP term) so these routers collect packets > sent by hosts in networks without ITRs and tunnel those packets to > the correct address. APT and TRRP have functionally similar > arrangements for packets sent from networks without ITRs. I've done some work with the LISP folks, but I'm far from an expert on that particular example. At least in the LISP case, but I suspect in all of these, it feels a lot like squeezing a balloon. That is, they do improve the area they are looking to improve, but at the expense of reducing the performance in some other way. As a result, as an operator, I find it hard to consider these solutions "better". Indeed, without the item being optimized for being a very scarce resource it seems unlikely folks are going to want to transition to a new technology solely for the same size balloon. > The first difficulty is that a new routing protocol can never be > introduced to replace BGP4 unless it is fully backwards compatible - > and no-one has devised such a thing AFAIK. I strongly disagree with this statement. While it would be vastly easier if it were fully backwards compatable that is by no means a requirement. Indeed, many of the schemes proposed are what I would call less than backwards compatable. I know folks may look at map-encap as keeping the host stack the same; but the reality is to the backbone operator it is a forklift upgrade to new technology and stands a really good chance of requiring new hardware (in some cases) at the edge. Rolling out a new routing protocol, even if it must just replace BGP, is no harder. > The second is that it is pretty tricky to come up with a protocol for > the Internet's interdomain routing system which could cope with the > growth in the number of separately advertised end-user networks. > > There could be millions or billions of separate prefixes which > end-user networks, including mobile devices, need to keep no matter > where they physically connect to the Net. Here is where I feel like there is a major disconnect. Operators today are concerned with growing the current system. Perhaps looking at a 10 year figure of 1 million IPv4 routes and 300k IPv6 routes, using more or less the exsiting schemes. What the IETF (researchers, vendors, etc?) seem to be looking at is how can we give every man woman and child a provider independant prefix and route all of them. Your "billions of prefixes" case. That's worthy work, I'm all for seeing if there is a way to do that and then assessing if it is a path we want to go down as an industry. However I feel that it is coming at the expense of the much less sexy problem of "how to we keep the status quo going for 10, 20, or 30 more years". It's also a harder problem, which means it will almost certianly take more money and effort to solve. > Many of the proposals now being made for the RRG process seem to > involve host changes - specifically making the host responsible for > more routing and addressing things than in the past. This is for > *every* host, not just for mobile hosts. There is an old belief that the Internet succeeded over some other technologies in part due to the fact that "routers are dumb" and all of the smarts are in the host. TCP congestion control is often cited as an example, let the hosts deal rather than having X.25 or Frame Relay style notification in the middle boxes. While I think many of the examples given are poor, I think the premise is right. Having to scale the technology in a PC is vastly cheaper than in core routers. If there is a choice of putting complexity in the host or in the core router, the host wins hands down. The down side of course is that there are many more devices to upgrade, so adoption is a much harder thing. > Even if these objections could be overcome, I would still object to > it because it significantly slows down the ability to send the first > packet of user data. This slowness depends on the RTT between the > hosts, and is greatly exacerbated by a lost packet in the initial > management exchange which must precede (AFAIK) the packet which > actually contains the user traffic packet. Having lived through some technologies with this property in the past (e.g. some of the IP over ATM "solutions") and seeing how it works in proposals like LISP I have to say this is an achillies heal in many of the proposals. Not just due to first packet slowness, but due to the caching of this information that must occur. Cache based router designs went from being the most common to non-existant a decade ago for a wide range of performance reasons. It seems to me most of the proposals bring back the badness in these designs, but rather than having it be all in one box, it's distributed across multiple routers and hosts across the Internet. I can't wait for the day that routing instability causes worldwide cache invalidations in some map-encap scheme. :( Lastly, a bit of ARIN related content... What I am hearing is that the research community believes that BGP4 cannot scale to the point where everyone has a provider independant prefix. That if we want to have everyone have a provider independant prefix, we need a new technology to be in place first. I think that's a very important message for the ARIN community to understand. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From michel at arneill-py.sacramento.ca.us Fri Dec 18 13:34:58 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 18 Dec 2009 10:34:58 -0800 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <20091218155153.GA78343@ussenterprise.ufp.org> References: <4B2AD4A0.6080908@firstpr.com.au><20091218020045.GA24163@ussenterprise.ufp.org><4B2B4976.2070302@firstpr.com.au> <20091218155153.GA78343@ussenterprise.ufp.org> Message-ID: <471D76419F9EF642962323D13DF1DF6901160A@newserver.arneill-py.local> > Leo Bicknell wrote: > What I am hearing is that the research community believes that BGP4 > cannot scale to the point where everyone has a provider independent > prefix. That if we want to have everyone have a provider independent > prefix, we need a new technology to be in place first. That technology was supposed to be IPv6, PA-only. Unfortunately it was launched before the quest for a working PA-only multihoming solution ended up returning with nothing. Back in these days, there was also a feeling that IPv6 would be easy to deploy, and if not easy at least a lot easier than replacing BGP. I think that another very important message for the ARIN community to understand is that replacing BGP is a HUGE undertaking. Michel. From michel at arneill-py.sacramento.ca.us Fri Dec 18 13:45:31 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 18 Dec 2009 10:45:31 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <200912180815.AA54264012@connetrix.com> References: <200912180815.AA54264012@connetrix.com> Message-ID: <471D76419F9EF642962323D13DF1DF6901160C@newserver.arneill-py.local> >> Michel Py wrote: >> the WRT610n does NAT at 300Mb/s? I mean measured in the >> real world, not only manufacturer's marketing? > Dave Feuer wrote: > In "real word" tests it does about 50% to 60% of that. The > older 600 was a bit faster. But still not bad for something > you can pick up for $179 or less at WalMart. Pretty good indeed. This also means that by the first day ISPs start to deploy GigE for residential Internet service, the typical home "router" will already be capable of sucking this GigE pipe dry. The days of forklift upgrades may not be over, after all. Michel. From owen at delong.com Fri Dec 18 13:50:59 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Dec 2009 10:50:59 -0800 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <20091218020045.GA24163@ussenterprise.ufp.org> References: <4B2AD4A0.6080908@firstpr.com.au> <20091218020045.GA24163@ussenterprise.ufp.org> Message-ID: On Dec 17, 2009, at 6:00 PM, Leo Bicknell wrote: > In a message written on Fri, Dec 18, 2009 at 12:02:24PM +1100, Robin > Whittle wrote: >> the IRTF RRG is about to decide on its recommendation to the >> IETF about scalable routing. > > I'm hoping you can fill in a gap for me, as I don't follow this > work very closely. > > In looking at the problems with the current Internet it appears > most of the blame is laid at the feet of BGP4. BGP has a number > of properties that lead to scaling issues, some well documented, > some not so well documented. > > All the solutions I see proposed though are fundamental changes to > how we do addressing. Locator-Identifier separation ideas, alternate > lookup databases (e.g. DNS), translation solutions, including simple > NAT and address embedding. > > What I haven't seen is anything that makes the leap from "BGP is > broken" to "the whole architecture must be changed". More > specifically, > I haven't seen anyone look at BGPv5, or a brand new replacement > routing protocol. It seems that improving the system and fixing > some of the known issues may be useful if nothing else as a stopgap, > and yet no one seems to be working seriously on the issue. > The fundamental issue of overloading end system identifiers with topological locator semantics is not from BGP and is a major source of scaling problems. Scalable routing depends on not impairing the topological locators with end system identifier semantics and vice versa. People are progressively less willing to tolerate the dictates of aggregation, and, this means that scaleable routing requires that we develop a routing system based on a more aggregable construct related to actual topology rather than end-system identifier semantics. Owen From Lee at dilkie.com Fri Dec 18 14:18:13 2009 From: Lee at dilkie.com (Lee Dilkie) Date: Fri, 18 Dec 2009 14:18:13 -0500 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <471D76419F9EF642962323D13DF1DF6901160C@newserver.arneill-py.local> References: <200912180815.AA54264012@connetrix.com> <471D76419F9EF642962323D13DF1DF6901160C@newserver.arneill-py.local> Message-ID: <4B2BD575.5090800@dilkie.com> I wonder how much b/w to the home is actually needed and if there is a natural demand "limit". It seems to me that once b/w to the home reaches realtime HD video there's not really much more that is required (except for separate channels for the kids, of course). If you think about it, there's only historically been two drivers for b/w throughout the history of communications. Ignoring the original low b/w uses, morse code, teletype, etc, we have realtime voice and realtime video. For 80 years, video has stabilized at about 3 Mhz b/w and it's only with the advent of HD that we have exceeded that (is that true? I'm not sure, considering compression and all). Is it really reasonable to expect future b/w demands to the home to keep going up and up? What drivers do you see for this? Just curious. -lee Michel Py wrote: > Pretty good indeed. This also means that by the first day ISPs start to > deploy GigE for residential Internet service, the typical home "router" > will already be capable of sucking this GigE pipe dry. > > The days of forklift upgrades may not be over, after all. > > Michel. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From kkargel at polartel.com Fri Dec 18 14:42:42 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 18 Dec 2009 13:42:42 -0600 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <4B2BD575.5090800@dilkie.com> References: <200912180815.AA54264012@connetrix.com> <471D76419F9EF642962323D13DF1DF6901160C@newserver.arneill-py.local> <4B2BD575.5090800@dilkie.com> Message-ID: <8695009A81378E48879980039EEDAD287B27A0BD@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Lee Dilkie > > I wonder how much b/w to the home is actually needed and if there is a > natural demand "limit". It seems to me that once b/w to the home reaches > realtime HD video there's not really much more that is required (except > for separate channels for the kids, of course). If you think about it, > there's only historically been two drivers for b/w throughout the > history of communications. Ignoring the original low b/w uses, morse > code, teletype, etc, we have realtime voice and realtime video. For 80 > years, video has stabilized at about 3 Mhz b/w and it's only with the > advent of HD that we have exceeded that (is that true? I'm not sure, > considering compression and all). > > Is it really reasonable to expect future b/w demands to the home to keep > going up and up? What drivers do you see for this? > > Just curious. > > -lee HD video to the home over IP is already a reality. MPEG4 will help this, but still figure 10Mbps of multicast IP per HD stream, and it is not beyond reality for a single family residence to have four TV's and a couple of PVR's all watching different channels.. so that could be over 60Mbps right there.. Add in some security video streams, a couple of game stations running.. a few piddly VOIP connections, a few instances of Microsoft update, junior pirating music and daddy downloading porn and you are starting to build up a pretty significant bandwidth requirement. As more bandwidth is available the apps will grow to consume it. Nature abhors a vacuum. There has to be some law of supply and demand that says that the amount of bandwidth required will grow to exceed what is available. Remember the famous quote "Nobody will EVER need more than 640K of RAM..." > > > Michel Py wrote: > > Pretty good indeed. This also means that by the first day ISPs start to > > deploy GigE for residential Internet service, the typical home "router" > > will already be capable of sucking this GigE pipe dry. > > > > The days of forklift upgrades may not be over, after all. > > > > Michel. From tedm at ipinc.net Fri Dec 18 14:43:08 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 18 Dec 2009 11:43:08 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <200912180815.AA54264012@connetrix.com> References: <200912180815.AA54264012@connetrix.com> Message-ID: <4B2BDB4C.2020105@ipinc.net> Dave Feuer wrote: > ---------- Original Message ---------------------------------- > From: "Michel Py" > Date: Thu, 17 Dec 2009 19:45:34 -0800 > >> Joel, the WRT610n does NAT at 300Mb/s? I mean measured in the >> real >> world, not only manufacturer's marketing? >> > > In "real word" tests it does about 50% to 60% of that. The older > 600 was a bit faster. But still not bad for something you can > pick up for $179 or less at WalMart. > Most of the Linksys routers have a button in the firmware you can select NAT or Gateway mode - in gateway mode, the device is indeed a real router, not a NAT Also, the WRT610N version 1 and 2 both run dd-wrt firmware, and there's a build of that firmware that supports IPv6, both as a tunnel endpoint, and a native IPv6 router. I'd be very happy to accept a donated WRT610N in exchange for running it through a testbed and publishing the results. ;-) ;-) Ted From tedm at ipinc.net Fri Dec 18 14:45:20 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 18 Dec 2009 11:45:20 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <4B2BD575.5090800@dilkie.com> References: <200912180815.AA54264012@connetrix.com> <471D76419F9EF642962323D13DF1DF6901160C@newserver.arneill-py.local> <4B2BD575.5090800@dilkie.com> Message-ID: <4B2BDBD0.4080508@ipinc.net> Lee Dilkie wrote: > > Is it really reasonable to expect future b/w demands to the home to keep > going up and up? What drivers do you see for this? > You can never have "too much bandwidth" That's like having "too much" sex. Ted From bicknell at ufp.org Fri Dec 18 14:51:10 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 18 Dec 2009 11:51:10 -0800 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <471D76419F9EF642962323D13DF1DF6901160A@newserver.arneill-py.local> References: <20091218155153.GA78343@ussenterprise.ufp.org> <471D76419F9EF642962323D13DF1DF6901160A@newserver.arneill-py.local> Message-ID: <20091218195110.GA99464@ussenterprise.ufp.org> In a message written on Fri, Dec 18, 2009 at 10:34:58AM -0800, Michel Py wrote: > > Leo Bicknell wrote: > > What I am hearing is that the research community believes that BGP4 > > cannot scale to the point where everyone has a provider independent > > prefix. That if we want to have everyone have a provider independent > > prefix, we need a new technology to be in place first. > > That technology was supposed to be IPv6, PA-only. Unfortunately it was > launched before the quest for a working PA-only multihoming solution > ended up returning with nothing. I agree that was the IETF's direction, but it is also a different solution. As I see it, the problem space has three, high level, diverging paths: A Multihoming happens entirely at the host, making PA-only possible. B The routing system can scale to PI, so everyone has PI. C Neither A or B is possible, so we attempt to decide who is worthy of PI. It seems to me we are in case C now, the IETF tried A several years ago and gave up, and the IETF is now trying B. (roughly) Which raises an interesting question, why hasn't SCTP taken off more? http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From terry.l.davis at boeing.com Fri Dec 18 15:18:52 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Fri, 18 Dec 2009 12:18:52 -0800 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <20091218195110.GA99464@ussenterprise.ufp.org> References: <20091218155153.GA78343@ussenterprise.ufp.org> <471D76419F9EF642962323D13DF1DF6901160A@newserver.arneill-py.local> <20091218195110.GA99464@ussenterprise.ufp.org> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF55127B08D2@XCH-NW-05V.nw.nos.boeing.com> Leo PA assumes that we discover how to keep our developers and ops staffs from embedding low level network infrastructure into their applications and processes. And that so far we have not managed to do; so from a CIO's point of view, PA is inherently hard to sell due the risk of system/application outages involved with changing ISPs. Most businesses also require multi-homing to meet their "business continuity" requirements; so to a CIO of any sizable company/entity, PA without it is a non-starter. Also I understand that the risks associated either of the above can become an issue in SOX compliance reporting. Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Leo Bicknell > Sent: Friday, December 18, 2009 11:51 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Routing Research Group is about to decide its > scalable routing recommendation > > In a message written on Fri, Dec 18, 2009 at 10:34:58AM -0800, Michel Py > wrote: > > > Leo Bicknell wrote: > > > What I am hearing is that the research community believes that BGP4 > > > cannot scale to the point where everyone has a provider independent > > > prefix. That if we want to have everyone have a provider independent > > > prefix, we need a new technology to be in place first. > > > > That technology was supposed to be IPv6, PA-only. Unfortunately it was > > launched before the quest for a working PA-only multihoming solution > > ended up returning with nothing. > > I agree that was the IETF's direction, but it is also a different > solution. As I see it, the problem space has three, high level, > diverging paths: > > A Multihoming happens entirely at the host, making PA-only possible. > > B The routing system can scale to PI, so everyone has PI. > > C Neither A or B is possible, so we attempt to decide who is worthy > of PI. > > It seems to me we are in case C now, the IETF tried A several years ago > and gave up, and the IETF is now trying B. (roughly) > > Which raises an interesting question, why hasn't SCTP taken off more? > > http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ From terry.l.davis at boeing.com Fri Dec 18 15:04:52 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Fri, 18 Dec 2009 12:04:52 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <4B2BD575.5090800@dilkie.com> References: <200912180815.AA54264012@connetrix.com><471D76419F9EF642962323D13DF1DF6901160C@newserver.arneill-py.local> <4B2BD575.5090800@dilkie.com> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF55127B08D1@XCH-NW-05V.nw.nos.boeing.com> Lee I suspect that 3-D imaging systems will be the next really big leap; hopefully we have 20 or so years before that occurs. Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Lee Dilkie > Sent: Friday, December 18, 2009 11:18 AM > To: Michel Py > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] debunking the myth that Moore's law helps > > I wonder how much b/w to the home is actually needed and if there is a > natural demand "limit". It seems to me that once b/w to the home reaches > realtime HD video there's not really much more that is required (except > for separate channels for the kids, of course). If you think about it, > there's only historically been two drivers for b/w throughout the > history of communications. Ignoring the original low b/w uses, morse > code, teletype, etc, we have realtime voice and realtime video. For 80 > years, video has stabilized at about 3 Mhz b/w and it's only with the > advent of HD that we have exceeded that (is that true? I'm not sure, > considering compression and all). > > Is it really reasonable to expect future b/w demands to the home to keep > going up and up? What drivers do you see for this? > > Just curious. > > -lee > > > Michel Py wrote: > > Pretty good indeed. This also means that by the first day ISPs start to > > deploy GigE for residential Internet service, the typical home "router" > > will already be capable of sucking this GigE pipe dry. > > > > The days of forklift upgrades may not be over, after all. > > > > Michel. > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From whinery at hawaii.edu Fri Dec 18 14:59:50 2009 From: whinery at hawaii.edu (Alan Whinery) Date: Fri, 18 Dec 2009 09:59:50 -1000 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <200912180815.AA54264012@connetrix.com> References: <200912180815.AA54264012@connetrix.com> Message-ID: <4B2BDF36.4090901@hawaii.edu> Dave Feuer wrote: > ---------- Original Message ---------------------------------- > From: "Michel Py" > Date: Thu, 17 Dec 2009 19:45:34 -0800 > > >> Joel, the WRT610n does NAT at 300Mb/s? I mean measured in the >> real >> world, not only manufacturer's marketing? >> >> > > In "real word" tests it does about 50% to 60% of that. The older > 600 was a bit faster. But still not bad for something you can > pick up for $179 or less at WalMart. > > -Dave > > > > > ________________________________________________________________ > Sent via the WebMail system at connetrix.com > Here is something that I wrote after we took the opportunity to play with one, for an hour about a year ago: > One of our campus departments recently purchased a Linksys WRT610N, > which is a consumer-grade SOHO (Small Office/Home Office) > NAT/Firewall/Wireless AP, which cost somewhere in the neighborhood of > $170.00. > > http://tinyurl.com/6ecntu > > Since the device has a 1/100/1000 UTP uplink, I was asked how to > determine what the throughput limit of the device was. They didn't > care much about the wireless part, they bought it mostly for the GigE > uplink. (And we didn't test the wireless part). > > The WRT610N arrived on Friday, and after several minutes of > preparation, we used the Windows desktop that happens to be near the > uhmanoa measurement machine to do a simple iperf test. > > They departmental guys had already installed DD-WRT ( Linux-derived > open source OS for little routers -- > http://www.dd-wrt.com/dd-wrtv3/index.php ) on it before I got to it, > but not tested, and although the DD-WRT page says it works with > WRT610N, we did not get the outside interface to pass traffic. > > So we re-flashed back to the Linksys firmware, and then we were able > to test. > > As a control, iperf was run between the two test hosts over a 3 meter > Systimax-D cable, which is supposed to meet or exceed category 6. > > Doing "-r" TCP tests, it was shown that the test hosts reliably > obtained in excess of 900 Mbps in either direction over a half a dozen > tests, using just the control wire. > > The WRT610N is a 4-port 10/100/1000 UTP switch, and a NAT/Firewall > with a fifth port as an uplink. When we tested with one host on a > switchport, and the other on the uplink port, the max throuhgput was > 130 Mbps in either direction. When a third machine was added to > another switch port, the combined throughput was 130 Mbps. The > bottleneck appears to be at the NAT/Firewall function. > > When 4 hosts were connected to the switchports, leaving the uplink > un-populated, the built-in switch performed admirably, simultaneous > iperfs yielded > 900 Mbps throughput. > > Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From schnizlein at isoc.org Fri Dec 18 16:34:42 2009 From: schnizlein at isoc.org (John Schnizlein) Date: Fri, 18 Dec 2009 16:34:42 -0500 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B08D1@XCH-NW-05V.nw.nos.boeing.com> References: <200912180815.AA54264012@connetrix.com><471D76419F9EF642962323D13DF1DF6901160C@newserver.arneill-py.local> <4B2BD575.5090800@dilkie.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B08D1@XCH-NW-05V.nw.nos.boeing.com> Message-ID: 20 years seems too long an estimate IMHO. Don't you think that somebody will want to download the equivalent of the 3D Blu-ray standard format that was announced today, within about a year of being able to get the disc? John On 2009Dec18, at 3:04 PM, Davis, Terry L wrote: > Lee > > I suspect that 3-D imaging systems will be the next really big leap; > hopefully we have 20 or so years before that occurs. > > Take care > Terry > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- >> bounces at arin.net] On >> Behalf Of Lee Dilkie >> Sent: Friday, December 18, 2009 11:18 AM >> To: Michel Py >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] debunking the myth that Moore's law helps >> >> I wonder how much b/w to the home is actually needed and if there >> is a >> natural demand "limit". It seems to me that once b/w to the home >> reaches >> realtime HD video there's not really much more that is required >> (except >> for separate channels for the kids, of course). If you think about >> it, >> there's only historically been two drivers for b/w throughout the >> history of communications. Ignoring the original low b/w uses, morse >> code, teletype, etc, we have realtime voice and realtime video. For >> 80 >> years, video has stabilized at about 3 Mhz b/w and it's only with the >> advent of HD that we have exceeded that (is that true? I'm not sure, >> considering compression and all). >> >> Is it really reasonable to expect future b/w demands to the home to >> keep >> going up and up? What drivers do you see for this? >> >> Just curious. >> >> -lee From terry.l.davis at boeing.com Fri Dec 18 17:05:38 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Fri, 18 Dec 2009 14:05:38 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: References: <200912180815.AA54264012@connetrix.com><471D76419F9EF642962323D1 3DF1DF6901160C@newserver.arneill-py.local> <4B2BD575.5090800@dilkie.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B08D1@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF55127B08D8@XCH-NW-05V.nw.nos.boeing.com> John Blu-ray yes but I think full 3-D communication and videos are out at least beyond 10 years. Take care Terry > -----Original Message----- > From: John Schnizlein [mailto:schnizlein at isoc.org] > Sent: Friday, December 18, 2009 1:35 PM > To: Davis, Terry L > Cc: 'Lee Dilkie'; Michel Py; arin-ppml at arin.net > Subject: Re: [arin-ppml] debunking the myth that Moore's law helps > > 20 years seems too long an estimate IMHO. > Don't you think that somebody will want to download the equivalent of > the 3D Blu-ray standard format that was announced today, within about > a year of being able to get the disc? > > John > > On 2009Dec18, at 3:04 PM, Davis, Terry L wrote: > > > Lee > > > > I suspect that 3-D imaging systems will be the next really big leap; > > hopefully we have 20 or so years before that occurs. > > > > Take care > > Terry > > > >> -----Original Message----- > >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- > >> bounces at arin.net] On > >> Behalf Of Lee Dilkie > >> Sent: Friday, December 18, 2009 11:18 AM > >> To: Michel Py > >> Cc: arin-ppml at arin.net > >> Subject: Re: [arin-ppml] debunking the myth that Moore's law helps > >> > >> I wonder how much b/w to the home is actually needed and if there > >> is a > >> natural demand "limit". It seems to me that once b/w to the home > >> reaches > >> realtime HD video there's not really much more that is required > >> (except > >> for separate channels for the kids, of course). If you think about > >> it, > >> there's only historically been two drivers for b/w throughout the > >> history of communications. Ignoring the original low b/w uses, morse > >> code, teletype, etc, we have realtime voice and realtime video. For > >> 80 > >> years, video has stabilized at about 3 Mhz b/w and it's only with the > >> advent of HD that we have exceeded that (is that true? I'm not sure, > >> considering compression and all). > >> > >> Is it really reasonable to expect future b/w demands to the home to > >> keep > >> going up and up? What drivers do you see for this? > >> > >> Just curious. > >> > >> -lee From michael.dillon at bt.com Fri Dec 18 18:11:48 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 18 Dec 2009 23:11:48 -0000 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <4B2BDBD0.4080508@ipinc.net> Message-ID: <28E139F46D45AF49A31950F88C49745804915AF8@E03MVZ2-UKDY.domain1.systemhost.net> > > Is it really reasonable to expect future b/w demands to the home to > > keep going up and up? What drivers do you see for this? > > You can never have "too much bandwidth" That's like having > "too much" sex. Predicting the future by means of linear extrapolation rarely works for very long. Reality is not like that. For example lots of people have "too much" sex and go into therapy and rehab clinics as a result. I suppose their might be some freaks out there who want to install wall-sized 24x7 telepresence screens on every room in each of their houses in LA, Aspen, New York and the Hamptons, but these will be way out on the right hand side of the normal curve. I would expect that the "average" home bandwidth will be less than a single realtime HD video screen because it will be cheaper to buy that with the overnight movie download service, than it will be to have the two realtime HD feed service. --Michael Dillon From scottleibrand at gmail.com Fri Dec 18 19:12:46 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 18 Dec 2009 16:12:46 -0800 Subject: [arin-ppml] Proposal 97. Waiting List for Unmet IPv4 Requests In-Reply-To: <4B2BE2E4.4070207@umn.edu> References: <4B2BE2E4.4070207@umn.edu> Message-ID: <4B2C1A7E.4070706@gmail.com> On 12/18/2009 12:15 PM, David Farmer wrote: > Scott, > > This is looking good; > > But I have some questions and comments; Thanks, the more feedback the better. > 1. The effect of 2009-8, if implemented by the Board, is to allow > transfers to be up to a 12 month supply of resources and up to a 3 > month supply for resource from the ARIN free pool. Does that jive > with your intent for this policy? Maybe you should mention this in > the rational. Correct. After we get to the last /8, you can request up to a 3-month supply from the free pool, but only every 3 months unless you can document an unforeseen change in circumstances since your last request. However, if you get the space via transfer, you can get a block big enough for 12 month's need, and if you end up using it up faster, you can submit another request after 3 months. (Does anyone have feedback on the exact numbers here? Is having to wait 3 months between 3-month-supply requests too long? Should I make it 1 or 2 months between requests instead?) > > 2. I believe the way this is stated that an organization with Multiple > Discrete Networks is only entitled to a single allocation or > assignment per organization, not per network. Maybe you should > mention this in the rational too. Does the fact that they might be > able to use multiple smaller blocks make any difference? > > 3. Should resources received via section 4.10 "Dedicated IPv4 block to > facilitate IPv6 Deployment" be exempted from these processes and limits? I believe that the numbered requirements under 4.10 are all more strict than those in proposal 97. As a result, I think the only effect of proposal 97 on 4.10 would be that if we ever burn through all the /24's in the reserved /10, we would use the same waiting list mechanism to deal with further requests after that. I think that's far enough out that policy will likely change first, though. > > 4. If I were on the waiting list, and subsequently received a transfer > via 8.3, would I be removed from the waiting list? Yes. > > I believe that is implied, in the following statement from 4.1.8; "an > organization may only receive one allocation, assignment, or transfer > every 3 months"; > > But, it might be better if the removal from the waiting list were more > explicit. In 4.1.8.2, it says that "Any requests met through a transfer will be considered fulfilled and removed from the waiting list." > > So to deal with #3 and #4, how about adding an additional sentence to > the end of 4.1.8.1 "Waiting list". > > "At the time of the allocation, assignment, or transfer of any amount > IPv4 resources, except via section 4.10, an organization's request > will be removed from the waiting list." > > 5. I believe M&A transfers are intended to be included a receipt of > resources that would remove you from the waiting list, implied in the > original text and more explicit with the text above. Maybe you should > mention this in the rational too. I think that depends on how the M&A is justified. If you acquire a company that is already efficiently utilizing all its IP space, I don't think that would count toward fulfilling an outstanding need that you have a request on the waiting list for. However, if your justification for keeping the space held by the acquired company is that you plan to use it for new stuff, then that would meet an outstanding need, and a request for that same need would be considered fulfilled and removed from the waiting list. Maybe I'll create a FAQ in the rationale with some of these questions and answers... Thanks, Scott From scottleibrand at gmail.com Fri Dec 18 19:29:29 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 18 Dec 2009 16:29:29 -0800 Subject: [arin-ppml] Proposal 97. Waiting List for Unmet IPv4 Requests In-Reply-To: <4B2C1A7E.4070706@gmail.com> References: <4B2BE2E4.4070207@umn.edu> <4B2C1A7E.4070706@gmail.com> Message-ID: <4B2C1E69.7090701@gmail.com> Oops, I forgot to answer this one: On 12/18/2009 4:12 PM, Scott Leibrand wrote: > > 2. I believe the way this is stated that an organization with Multiple > Discrete Networks is only entitled to a single allocation or > assignment per organization, not per network. Maybe you should > mention this in the rational too. Does the fact that they might be > able to use multiple smaller blocks make any difference? I guess that really comes down to whether you think that it's better for an organization with multiple discrete networks to qualify for more space than an organization with a single network and the same sized need. From a routing perspective, that's fine, as each discrete network is going to advertise its own route into the DFZ regardless. But from a fairness perspective, I'm not sure whether we want to add an MDN exception to bypass the single continuous range of addresses requirement. Anyone else have an opinion about whether blocks for multiple discrete networks should have to be allocated as a single continuous range of addresses or not? Thanks, Scott From farmer at umn.edu Fri Dec 18 19:47:01 2009 From: farmer at umn.edu (David Farmer) Date: Fri, 18 Dec 2009 18:47:01 -0600 Subject: [arin-ppml] Proposal 97. Waiting List for Unmet IPv4 Requests In-Reply-To: <4B2C1A7E.4070706@gmail.com> References: <4B2BE2E4.4070207@umn.edu> <4B2C1A7E.4070706@gmail.com> Message-ID: <4B2C2285.40905@umn.edu> Scott Leibrand wrote: > On 12/18/2009 12:15 PM, David Farmer wrote: >> Scott, >> >> This is looking good; >> >> But I have some questions and comments; > > Thanks, the more feedback the better. > >> 1. The effect of 2009-8, if implemented by the Board, is to allow >> transfers to be up to a 12 month supply of resources and up to a 3 >> month supply for resource from the ARIN free pool. Does that jive >> with your intent for this policy? Maybe you should mention this in >> the rational. > > Correct. After we get to the last /8, you can request up to a 3-month > supply from the free pool, but only every 3 months unless you can > document an unforeseen change in circumstances since your last request. > However, if you get the space via transfer, you can get a block big > enough for 12 month's need, and if you end up using it up faster, you > can submit another request after 3 months. > > (Does anyone have feedback on the exact numbers here? Is having to wait > 3 months between 3-month-supply requests too long? Should I make it 1 > or 2 months between requests instead?) I think it is fine the way it is, maybe just add it to the FAQ you mention below. >> 2. I believe the way this is stated that an organization with Multiple >> Discrete Networks is only entitled to a single allocation or >> assignment per organization, not per network. Maybe you should >> mention this in the rational too. Does the fact that they might be >> able to use multiple smaller blocks make any difference? >> >> 3. Should resources received via section 4.10 "Dedicated IPv4 block to >> facilitate IPv6 Deployment" be exempted from these processes and limits? > > I believe that the numbered requirements under 4.10 are all more strict > than those in proposal 97. As a result, I think the only effect of > proposal 97 on 4.10 would be that if we ever burn through all the /24's > in the reserved /10, we would use the same waiting list mechanism to > deal with further requests after that. I think that's far enough out > that policy will likely change first, though. But if you had a request on the waiting list could you make a separate qualifying request to this pool. Because of how restricted those resources are, I was thinking maybe you should be able to get resources from this special pool, if the use qualifies, without losing a spot on the waiting list for less restricted resources. And like you say, it should be a while before this policy is necessary for this special pool. >> 4. If I were on the waiting list, and subsequently received a transfer >> via 8.3, would I be removed from the waiting list? > > Yes. > >> >> I believe that is implied, in the following statement from 4.1.8; "an >> organization may only receive one allocation, assignment, or transfer >> every 3 months"; >> >> But, it might be better if the removal from the waiting list were more >> explicit. > > In 4.1.8.2, it says that "Any requests met through a transfer will be > considered fulfilled and removed from the waiting list." DOH! Sorry, I don't know how I missed that, yes you have this handled. >> So to deal with #3 and #4, how about adding an additional sentence to >> the end of 4.1.8.1 "Waiting list". >> >> "At the time of the allocation, assignment, or transfer of any amount >> IPv4 resources, except via section 4.10, an organization's request >> will be removed from the waiting list." >> >> 5. I believe M&A transfers are intended to be included a receipt of >> resources that would remove you from the waiting list, implied in the >> original text and more explicit with the text above. Maybe you should >> mention this in the rational too. > > I think that depends on how the M&A is justified. If you acquire a > company that is already efficiently utilizing all its IP space, I don't > think that would count toward fulfilling an outstanding need that you > have a request on the waiting list for. However, if your justification > for keeping the space held by the acquired company is that you plan to > use it for new stuff, then that would meet an outstanding need, and a > request for that same need would be considered fulfilled and removed > from the waiting list. That seems reasonable to me > Maybe I'll create a FAQ in the rationale with some of these questions > and answers... Yea, an FAQ would be fine, that way it is clear in the record what the intent is. > Thanks, > Scott -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From farmer at umn.edu Fri Dec 18 19:50:13 2009 From: farmer at umn.edu (David Farmer) Date: Fri, 18 Dec 2009 18:50:13 -0600 Subject: [arin-ppml] Proposal 97. Waiting List for Unmet IPv4 Requests In-Reply-To: <4B2C1E69.7090701@gmail.com> References: <4B2BE2E4.4070207@umn.edu> <4B2C1A7E.4070706@gmail.com> <4B2C1E69.7090701@gmail.com> Message-ID: <4B2C2345.8070105@umn.edu> Scott Leibrand wrote: > Oops, I forgot to answer this one: > > On 12/18/2009 4:12 PM, Scott Leibrand wrote: >> >> 2. I believe the way this is stated that an organization with Multiple >> Discrete Networks is only entitled to a single allocation or >> assignment per organization, not per network. Maybe you should >> mention this in the rational too. Does the fact that they might be >> able to use multiple smaller blocks make any difference? > > I guess that really comes down to whether you think that it's better for > an organization with multiple discrete networks to qualify for more > space than an organization with a single network and the same sized > need. From a routing perspective, that's fine, as each discrete network > is going to advertise its own route into the DFZ regardless. But from a > fairness perspective, I'm not sure whether we want to add an MDN > exception to bypass the single continuous range of addresses requirement. > > Anyone else have an opinion about whether blocks for multiple discrete > networks should have to be allocated as a single continuous range of > addresses or not? I'm fine with them getting a single request and block per organization and not per network. But, this would be another good one for an FAQ in the rationale. > Thanks, > Scott -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From scottleibrand at gmail.com Sat Dec 19 00:00:13 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 18 Dec 2009 21:00:13 -0800 Subject: [arin-ppml] Does Moore's law help with routing table growth? Message-ID: <4B2C5DDD.7050501@gmail.com> On 12/17/2009 7:45 PM, Michel Py wrote: > That is a very valid point, and although I would have a few arguments > about the demand side driving the supply side, I will not start a > discussion about this because it would be as productive as the chicken > and egg problem. The relation between supply and demand is complex. > > >> The cost of transporting a bit is a function of the cost to route >> it (electronics), and the cost to transport it (optics). Routing >> costs seem to be tied to some version of Moore's law. Although >> there are specialized components like TCAM that don't observe the >> exact same factors as general purpose CPUs, they seem to be on a >> similar exponential curve. >> > Agree. Back to the original topic, can we agree that Moore's law does > not help building faster routers and might even have a negative side, > because the general purpose CPU may be on a faster version of Moore's > law than TCAM? > Well, back to the original topic, what we need to be concerned with for policy is not the relationship between bandwidth supply and demand, but the relationship between the growth of the BGP routing table and the growth of FIBs to accommodate it. It appears to me that we're doing OK there: router growth seems to be mostly keeping ahead of table growth. As long as we don't dramatically increase the rate of growth of the routing table, I think we're ok. And AFAICT none of the policy proposals currently on the table would change that growth rate enough to alarm me. -Scott From michel at arneill-py.sacramento.ca.us Sat Dec 19 00:19:11 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 18 Dec 2009 21:19:11 -0800 Subject: [arin-ppml] Does Moore's law help with routing table growth? In-Reply-To: <4B2C5DDD.7050501@gmail.com> References: <4B2C5DDD.7050501@gmail.com> Message-ID: <471D76419F9EF642962323D13DF1DF69011612@newserver.arneill-py.local> > Scott Leibrand wrote: > Well, back to the original topic, what we need to be concerned > with for policy is not the relationship between bandwidth > supply and demand, but the relationship between the growth of > the BGP routing table and the growth of FIBs to accommodate it. Indeed. > It appears to me that we're doing OK there: router growth seems > to be mostly keeping ahead of table growth. As long as we don't > dramatically increase the rate of growth of the routing table, > I think we're ok. And AFAICT none of the policy proposals > currently on the table would change that growth rate enough > to alarm me. I agree with this wording. I don't think we have much maneuvering room though; the benefits of Moore's law helping building faster routers are more or less offset by the same Moore's law helping building more bandwidth-hungry consumer devices. In other words, growth of the DFZ table has to rely on router enhancements, not on riding Moore's law. There is no such thing as "PI for everyone" in the foreseeable future. Michel. From michel at arneill-py.sacramento.ca.us Sat Dec 19 00:25:18 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 18 Dec 2009 21:25:18 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <8695009A81378E48879980039EEDAD287B27A0BD@MAIL1.polartel.local> References: <200912180815.AA54264012@connetrix.com><471D76419F9EF642962323D13DF1DF6901160C@newserver.arneill-py.local> <4B2BD575.5090800@dilkie.com> <8695009A81378E48879980039EEDAD287B27A0BD@MAIL1.polartel.local> Message-ID: <471D76419F9EF642962323D13DF1DF69011613@newserver.arneill-py.local> > Alan Whinery wrote: > [Linksys WRT610N] Thanks for the detailed feedback. So, the switch part works at wire speed; that was somehow expected, given that the backplane capacity on a 4-port switch is a non-issue. The NAT part goes over 100Mbps but not much. Does everyone agree that a $250 device with something like an Atom CPU would get ~800Mps NAT (if there was a market for that device today)? >>> Michel Py wrote: >>> [GigE residential] This also means that by the first day ISPs >>> start to deploy GigE for residential Internet service, the typical >>> home "router" will already be capable of sucking this GigE pipe dry. >> Lee Dilkie wrote: >> I wonder how much b/w to the home is actually needed and >> if there is a natural demand "limit". [SNIP] Is it really >> reasonable to expect future b/w demands to the home to >> keep going up and up? What drivers do you see for this? > Kevin Kargel wrote: > HD video to the home over IP is already a reality. MPEG4 will > help this, but still figure 10Mbps of multicast IP per HD stream, > and it is not beyond reality for a single family residence to have > four TV's and a couple of PVR's all watching different channels.. > so that could be over 60Mbps right there.. Agree, and these are low numbers. Not trying to push FUD or marketing bu||$hi7, but "True HD blah blah uncompressed that looks as good as BluRay" ads are already there, and we might look at 20Mps per stream. And indeed 6 streams may not be enough in the long run; just listen to the current "Uverse" commercial: 4 streams already. > Add in some security video streams, a couple of game stations running.. > a few piddly VOIP connections, a few instances of Microsoft update, > junior pirating music and daddy downloading porn and you are starting > to build up a pretty significant bandwidth requirement. LMAO. Don't forget that mom also pirates music and junior also looks at porn :-) I have been saying for a while that FTTH deployments based on anything less than GigE are a disaster waiting to happen. The situation today is clear, IMHO: 100Mpbs is not enough and 10Gig is way too expensive. GigE is the name of the game for FTTH. > As more bandwidth is available the apps will grow to consume it. > Nature abhors a vacuum. There has to be some law of supply and > demand that says that the amount of bandwidth required will grow > to exceed what is available. Ack. As of today, at least. It seems to me that in the HDD storage market, the supply has exceeded the demand, but not on the bandwidth market. > Kevin Kargel wrote: > Remember the famous quote "Nobody will EVER need more than 640K of RAM..." > Ted Mittelstaedt wrote: > You can never have "too much bandwidth" That's like having "too much" sex. Well I'd say that either may eventually get old, but the day I get this GigE home link for $20/mo or get stranded on a tropical island with 5 beautiful young women and nothing to do all day, I would probably test the theory for a while ;-) Michel. From scottleibrand at gmail.com Sat Dec 19 00:34:25 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 18 Dec 2009 21:34:25 -0800 Subject: [arin-ppml] Does Moore's law help with routing table growth? In-Reply-To: <471D76419F9EF642962323D13DF1DF69011612@newserver.arneill-py.local> References: <4B2C5DDD.7050501@gmail.com> <471D76419F9EF642962323D13DF1DF69011612@newserver.arneill-py.local> Message-ID: <4B2C65E1.3090705@gmail.com> On 12/18/2009 9:19 PM, Michel Py wrote: > > I don't think we have much maneuvering room though; the benefits of > Moore's law helping building faster routers are more or less offset by > the same Moore's law helping building more bandwidth-hungry consumer > devices. Except that the bandwidth of consumer devices is completely independent of the number of routes we have to stuff into our FIB. That is dependent on the number of independently multihomed networks, which is determined by economic and business forces. > In other words, growth of the DFZ table has to rely on router > enhancements, not on riding Moore's law. > I believe that enhancements in router FIB capacity are to some degree dependent on the same forces driving Moore's law. Obviously keeping Moore's law going (whether in CPUs or in TCAMs) requires hard engineering work, but that's not the point. The point of Moore's law is that all that hard work results in a periodic doubling of capacity (in this case, FIB routes) for the same price. For now, that improvement is keeping ahead of the growth rate of networks seeking to multihome. > There is no such thing as "PI for everyone" in the foreseeable future. > If by "everyone" you mean "every organization with a single-homed network", then I agree, that will be infeasible at least as long as we're running BGP4. But as long as we move the bar gradually, I think we can safely move toward a situation where PI addresses are generally available for multihomed organizations who are willing to pay their providers enough to run BGP. -Scott -Scott From rw at firstpr.com.au Sat Dec 19 00:47:04 2009 From: rw at firstpr.com.au (Robin Whittle) Date: Sat, 19 Dec 2009 16:47:04 +1100 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <20091218155153.GA78343@ussenterprise.ufp.org> References: <4B2AD4A0.6080908@firstpr.com.au> <20091218020045.GA24163@ussenterprise.ufp.org> <4B2B4976.2070302@firstpr.com.au> <20091218155153.GA78343@ussenterprise.ufp.org> Message-ID: <4B2C68D8.7020006@firstpr.com.au> Short version: Responding to Leo and giving my views on the three types of solution to the routing scaling problem: Soup up BGP No-one suggests this. Core-edge separation LISP, APT, Ivip & TRRP. Backwards compatible, works for IPv4/6 and requires no host changes. New functions added to ISP and end-user networks. Core-edge elimination Generally involves host changes - stack and apps. Not backwards compatible. Generally does not add new functions into any part of the network. Discussion of the number of end-user networks which need to be supported, and why I think 10M is the max for non-mobile networks. Agreeing that LISP involves some delayed or dropped initial packets, but pointing out that this problem does not exist for APT or Ivip. Hi Leo, Thanks for your appreciative reply. You wrote: > What I am hearing is that the research community believes that BGP4 > cannot scale to the point where everyone has a provider independent > prefix. That if we want to have everyone have a provider > independent prefix, we need a new technology to be in place first. > > I think that's a very important message for the ARIN community to > understand. I think this is absolutely true. No-one has seriously suggested a way of solving the routing scaling problem by souping up BGP and the DFZ in its current form. I think that pretty much everyone agrees the most important problem is in the RIB and BGP exchanges, and the stability and response times of the whole BGP DFZ control plane - rather than a problem with the number of routes the FIB handles. However, FIB limitations surely rule out trying to make the DFZ handle tens or millions or more separate end-user prefixes, even if there were no RIB or BGP control plane objections. On problems with BGP: >> Can you mention those which you think are not well documented? > > I think the effects of how ISP's configure BGP on the performance > have been relatively poorly studied. What I see mostly are lab > tests, there are very few studies tracking CPU usage or propogation > times in the real Internet and relating that back to protocol or > configuration weakless. OK. While there may be ways of marginally improving the operation of the DFZ, including by improvements to the BGP protocol, the goal of scalable routing is far beyond the modest improvements these might bring. The aim are not just to enable end-user networks who advertise PI space now to adopt a scalable alternative. The aim (of most people, I think) is to extend this so it is attractive to many smaller end-user networks so they can get portable space, suitable for multihoming and inbound TE. I think it should extend to SOHO "networks" even though they might have most of their hosts behind NAT. For instance, if I am running a business and am concerned about the reliability of my DSL line, I should be able to get a 3G or WiMAX service as a backup, and use my address space on either. That is a cheap backup arrangement - since there's no need for new fibre or wires. My address space may only be a single IPv4 address, but if I need it for mail, HTTPS e-commerce transactions, VoIP etc. I would want it to keep working without a hitch if the DSL line or its ISP was not working. Since we are doing this, I think it should extend to mobility too - with each device getting its own IPv4 address or IPv6 /64. Mobility support is not formally part of what the RRG is supposed to be doing, but I think it would be unwise to choose a solution without at the same time making sure it was a good basis for mobility. Many people think that a core-edge separation scheme with mobility (such as the LISP-MN internet draft) must involve the MN being its own ETR. That won't work for IPv4 and there are many objections to this for IPv6. See my critique: http://www.ietf.org/mail-archive/web/lisp/current/msg00749.html http://www.ietf.org/mail-archive/web/lisp/current/msg00772.html The TTR approach to mobility involves the MN using one or more nearby "Translating Tunnel Routers" as its ETR(s) and also as outgoing routers, with ITR functions. http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf There's no need for new protocols - the mobile hosts, via their TTRs, communicate normally and with generally optimal path lengths with ordinary IPv4 or IPv6 hosts. My rough estimate of the maximum number of non-mobile end-user networks we would ever need to support is about 10 million. This is on the basis of 10 billion people, and one organisation or business per thousand people being concerned enough about multihoming to want to get a second connection to a second ISP, and get their own Scalable PI (SPI - my term) space. If this is all we need to handle, there's no strong argument for the LISP-CONS, LISP-ALT or TRRP approach - which is to build a globally distributed query server network for mapping, because the mapping itself is too big to store in any one location. 10M mappings will fit in DRAM of a big server now, and a small server by the time we get 10M multihomed non-mobile networks. So in my view, anyone who says we need to cope with more than about 10M EID prefixes (LISP terminology) must be assuming the system supports mobility. With mobility, I think a worst case is 10 billion - one for a cell-phone for everyone on a rather crowded planet. Clearly this means IPv6, though the TTR approach will work for both IPv4 and IPv6. I think this is still feasible to do with a local query server architecture such as APT or Ivip. Ivip's IPv6 mapping is the start and end of the range of SPI space, in units of /64, and a single ETR address. This is 32 bytes, so the total mapping database would be 320Gbytes. That fits on a consumer hard drive today, and should be fine in server DRAM by the time such adoption is achieved. >> Core-edge separation schemes (LISP, APT, Ivip and TRRP) don't alter >> the functions of hosts or most internal routers. They just provide a >> new set of end-user address prefixes which are portable to any ISP >> with an ETR, and which are not advertised directly in the DFZ. A >> covering prefix, including many such longer prefixes, is advertised >> by special ITRs ("Open ITRs in the DFZ" is the Ivip term, "Proxy >> Tunnel Routers" is the LISP term) so these routers collect packets >> sent by hosts in networks without ITRs and tunnel those packets to >> the correct address. APT and TRRP have functionally similar >> arrangements for packets sent from networks without ITRs. > > I've done some work with the LISP folks, but I'm far from an expert > on that particular example. At least in the LISP case, but I suspect > in all of these, it feels a lot like squeezing a balloon. That is, > they do improve the area they are looking to improve, but at the > expense of reducing the performance in some other way. I think LISP is not a suitable solution. LISP-NERD involved all the mapping going to every ITR. Everyone agreed that this was not going to scale as well as some alternative. NERD is no longer being developed. To me, the best alternative is local (in the ISP or end-user network) full-database query servers. This is what APT and Ivip use. Instead the LISP crew went to the other extreme - a distributed global query server network, in which no one device has the total mapping database. In principle this should scale without limit. However, these two LISP approaches - CONS and now ALT - are nowhere near being able to scale to tens or hundreds of millions of EIDs. CONS was pursued for a few months in 2007. ALT was launched in November 2007 and since then I and others have been critical of its "long-path" problem. There is no obvious way to shorten the total path length through the "highly aggregated" ALT network, while ensuring the network is robust against router or link failure. See the recent discussion on the LISP WG list: ALT structure, robustness and the long-path problem http://www.ietf.org/mail-archive/web/lisp/current/msg01801.html Two years after ALT's inception, there are no answers. Some key people on the list regard it as something worth building to experiment with - without at the same time thinking that it will be the best final architecture. Even if these problems were solved, LISP-ALT would frequently drop the initial packets in a new communication flow, since it could take a fraction of a second to several seconds for the ITR to get the mapping it needs from the global ALT query server system. (Or longer if the request or response packet is lost.) Since the delay is too long to hold on to the packet for, the ITR drops the initial packet and sends a mapping request. When the response arrives, it has to wait for the sending host to send another packet (assuming the host keeps trying - it might try an alternative IP address it got from round-robin DNS). So it is not just the delay inherent in LISP-ALT's global query server system - the delay involves waiting for the host to resend, and dropping all resent packets which the ITR gets before the map reply message arrives. LISP-ALT's initial packet delays could affect A doing a DNS lookup for B's address, A sending a packet to B and B sending a packet back to A. APT and my Ivip proposal don't have a crowd of people working on them, but both proposals do not have this major problem of LISP-ALT. In both proposals, the ITR gets mapping quickly and reliably from a local full database query server (the Default Mapper in APT). So APT and Ivip would not significantly alter performance, in terms of the time it takes for traffic packets to reach their destination - while LISP-ALT would significantly delay many initial packets. > As a result, as an operator, I find it hard to consider these > solutions "better". Indeed, without the item being optimized for > being a very scarce resource it seems unlikely folks are going to > want to transition to a new technology solely for the same size > balloon. A core-edge separation scheme should provide profound benefits, as long as there were no significant loss of performance. With Ivip, the ETR could be a device in the ISP, shared by many end-user networks, or it could be a device in the end-user network - and that network runs it on one or maybe four IP addresses it gets from its ISP's address space. In the latter case, the end-user network gets a tiny piece of PA space from one, two or more ISPs and then runs its own ETRs, through which it can use as much SPI space as it likes. With Ivip on IPv4, this means an end-user network can (effectively permanently) rent some SPI space from some entity anywhere in the world - probably not any of its ISPs - and then use that space as it wishes, on any PA address at any ISP (with its own ETRs) or using shared ETRs at ISPs which have installed them. The end-user network might get 16 IPv4 addresses and split them up so head office gets four and the branch offices get one each. If each office multihomes, then these are stable addresses which can be relied upon, including for VoIP and VPNs. The offices can be anywhere in the world, and it is little fuss to choose different ISPs at each location. ISPs don't need to do anything in order to support the second mode - the end-user network running its own ETR. Indeed, the ISP would be unable to prevent this usage. ISPs which installed their own ETRs would be more attractive to Ivip-using end-user networks which wanted to do it this way. Ideally ISPs and end-user networks would install their own ITRs - no matter whether or not they used SPI space. This means they encapsulate their own packets which are addressed to SPI addresses, rather than letting the packet go out to the DFZ where it would be forwarded to the nearest Open ITR in the DFZ (OITRD in Ivip, Proxy Tunnel Router in LISP - and APT has similar functionality) which would tunnel it to the correct ETR. One reason for an ISP installing its own ITRs would be to stop traffic going out to the DFZ when it really needs to be encapsulated and sent to an ETR in its own network. (This is for Ivip, I am not sure how LISP would work in this respect.) So there would be little or no investment for an ISP to be able to support some of its customers using SPI space. >> The first difficulty is that a new routing protocol can never be >> introduced to replace BGP4 unless it is fully backwards compatible - >> and no-one has devised such a thing AFAIK. > > I strongly disagree with this statement. While it would be vastly > easier if it were fully backwards compatable that is by no means a > requirement. Indeed, many of the schemes proposed are what I would > call less than backwards compatable. I know folks may look at > map-encap as keeping the host stack the same; but the reality is > to the backbone operator it is a forklift upgrade to new technology > and stands a really good chance of requiring new hardware (in some > cases) at the edge. Rolling out a new routing protocol, even if > it must just replace BGP, is no harder. Can you point to any proposal to replace BGP which could be introduced in a way which provided significant immediate benefits to the early adoptors (not just dependent on how many others adopt it, which initially is very low) while also working with the existing system? >> The second is that it is pretty tricky to come up with a protocol for >> the Internet's interdomain routing system which could cope with the >> growth in the number of separately advertised end-user networks. >> >> There could be millions or billions of separate prefixes which >> end-user networks, including mobile devices, need to keep no matter >> where they physically connect to the Net. > > Here is where I feel like there is a major disconnect. Operators > today are concerned with growing the current system. Perhaps looking > at a 10 year figure of 1 million IPv4 routes and 300k IPv6 routes, > using more or less the exsiting schemes. > > What the IETF (researchers, vendors, etc?) seem to be looking at > is how can we give every man woman and child a provider independant > prefix and route all of them. Your "billions of prefixes" case. Yes, in the case of mobility. If you ignore mobility, I don't think many people would argue that we need to support more than a few million or perhaps my 10 million non-mobile end-user networks. > That's worthy work, I'm all for seeing if there is a way to do that > and then assessing if it is a path we want to go down as an industry. Some of the proposals to the RRG are for IPv6-only and/or involve host changes - so there's no way they can be adopted widely enough on a voluntary basis to solve the only routing scaling problem we have at present: in IPv4's DFZ. These tend to be core-edge elimination schemes - which avoid adding much into the network and put a bunch of new routing and addressing responsibilities on all hosts. HIP is the most prominent example of such an architecture. LISP, APT, Ivip - and TRRP if Bill Herrin is still working on it - could all, in principle, solve the IPv4 scaling problem, to very large numbers of end-user networks. These are all core edge separation schemes. LISP-ALT and TRRP rely on a global query server network, so they are subject to the critique about dropped and delayed initial packets. There definitely is a desire to provide a new architecture - either to replace the current architecture (as with the core-edge elimination schemes) or to add it to the current architecture (core-edge separation schemes) which will do more than just cope with the current growth rate in the DFZ routing table. This is because that growth in numbers still only represents a fraction of the numbers of end-user networks which want or need portability, multihoming and/or inbound TE. > However I feel that it is coming at the expense of the much less > sexy problem of "how to we keep the status quo going for 10, 20, > or 30 more years". It's also a harder problem, which means it will > almost certianly take more money and effort to solve. The core-edge separation schemes can keep the current system going, without any changes to host stacks or apps. The core-edge elimination schemes can't - they require new stacks and probably apps. I am 100% certain this will not happen within decades. They may never happen. There are fundamental objections to requiring every host to manage more routing and addressing stuff: http://www.firstpr.com.au/ip/ivip/RRG-2009/host-responsibilities/ >> Many of the proposals now being made for the RRG process seem to >> involve host changes - specifically making the host responsible for >> more routing and addressing things than in the past. This is for >> *every* host, not just for mobile hosts. > > There is an old belief that the Internet succeeded over some other > technologies in part due to the fact that "routers are dumb" and > all of the smarts are in the host. TCP congestion control is often > cited as an example, let the hosts deal rather than having X.25 or > Frame Relay style notification in the middle boxes. > > While I think many of the examples given are poor, I think the > premise is right. Having to scale the technology in a PC is vastly > cheaper than in core routers. If there is a choice of putting > complexity in the host or in the core router, the host wins hands > down. I agree to some extent. APT and LISP do not allow the ITR function to be in the sending host. Ivip has an option for placing the ITR in the sending host. This is a good idea except when either of these are true: 1 - The host is on a high latency link, such as a wireless mobile device, or any non-mobile network relying on a satellite link. This will delay the ability of the ITR to get mapping from its local query server, and so delay the forwarding of initial packets. 2 - Where it is vital that the host be as simple and low-power as possible. This includes many mobile devices. A good example of where to do it would be in a web-server farm - so each server does the ITR work and there is no need to have a separate ITR to encapsulate the large volume of outgoing packets. However, this optional placement of the ITR function is very different from what I think you are suggesting, which is the pattern followed in the core-edge elimination schemes: have no additional routing and addressing stuff in the network, and make the hosts do all the new work. This is the HIP approach - and it burdens *every* host with a bunch of new responsibilities. That might be fine for many hosts, with plenty of CPU power, RAM etc. AND which are on fast links. It is a bad idea for low-power devices on flaky long-latency 3G wireless links. In the future, if mobility is developed as it should be, there will be billions of devices, typically connected by a flaky long-latency 3G link. So to say the whole Internet must follow your principle: If there is a choice of putting complexity in the host or in the core router, the host wins hands down. as with HIP, then this is going to make mobile hosts have higher costs and worse performance than they already do. > The down side of course is that there are many more devices to upgrade, > so adoption is a much harder thing. The core-edge elimination architectures are not backwards compatible. So you have to alter all the hosts, effectively creating a new set of Internet protocols and addressing - a new Internet which can't directly work with the current Internet. A decade and a half after IPv6 was developed, still there wouldn't be a single end-user who can do all the normal, wide range, of Internet activities using only an IPv6 address. The core-edge separation architectures don't require host changes. The "optional ITR function in sending host" part of Ivip is just there to reduce costs when it makes sense. >> Even if these objections could be overcome, I would still object to >> it because it significantly slows down the ability to send the first >> packet of user data. This slowness depends on the RTT between the >> hosts, and is greatly exacerbated by a lost packet in the initial >> management exchange which must precede (AFAIK) the packet which >> actually contains the user traffic packet. > > Having lived through some technologies with this property in the > past (e.g. some of the IP over ATM "solutions") and seeing how it > works in proposals like LISP I have to say this is an achillies > heal in many of the proposals. I think this slowness of delivering the initial packet rules out all the core-edge elimination schemes - as far as I know, they all involve hosts doing fancy things to authenticate the other host's identity before they will send the traffic packet. Likewise LISP-ALT, TRRP or any other core-edge separation scheme which relies on a global query server network. That leaves APT and Ivip as the two proposals which do not delay initial packets. APT's Internet Draft is 2 years old, and it has not yet been submitted as a proposal to the final RRG process. I assume it is still being developed and will be part of the RRG's final deliberations. > Not just due to first packet slowness, > but due to the caching of this information that must occur. > > Cache based router designs went from being the most common to > non-existant a decade ago for a wide range of performance reasons. > It seems to me most of the proposals bring back the badness in these > designs, but rather than having it be all in one box, it's distributed > across multiple routers and hosts across the Internet. > > I can't wait for the day that routing instability causes worldwide > cache invalidations in some map-encap scheme. :( Ivip's full database query servers get the latest mapping, as chosen by the end-user networks themselves (typically from a specialised monitoring company contracted by the end-user network to choose the best ETR to use) within a few seconds. They retain a record of which ITRs requested mapping within the caching time, and send secure (with a nonce from the ITR's query) mapping update messages to the ITR. So the ITR gets the changed mapping within tens of milliseconds of the local full database query server getting it. (There are optional caching query servers between the ITRs and the full database query servers, but the same thing happens.) So caching is not necessarily evil. LISP involves caching - and I haven't really followed the work on how ETRs can securely update ITR mapping. I don't support this approach. In Ivip, ETRs simply decapsulate packets and sometimes communicate with ITRs for the purpose of Path MTU Discovery management. ETRs are not at all involved in Ivip's mapping system. LISP-ALT's ETRs are the authoritative source of mapping - they are mapping query servers as well as traffic decapsulators. - Robin From bicknell at ufp.org Sat Dec 19 01:01:16 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 18 Dec 2009 22:01:16 -0800 Subject: [arin-ppml] debunking the myth that Moore's law helps In-Reply-To: <471D76419F9EF642962323D13DF1DF69011613@newserver.arneill-py.local> References: <4B2BD575.5090800@dilkie.com> <8695009A81378E48879980039EEDAD287B27A0BD@MAIL1.polartel.local> <471D76419F9EF642962323D13DF1DF69011613@newserver.arneill-py.local> Message-ID: <20091219060116.GA34678@ussenterprise.ufp.org> In a message written on Fri, Dec 18, 2009 at 09:25:18PM -0800, Michel Py wrote: > So, the switch part works at wire speed; that was somehow expected, > given that the backplane capacity on a 4-port switch is a non-issue. The > NAT part goes over 100Mbps but not much. Does everyone agree that a $250 > device with something like an Atom CPU would get ~800Mps NAT (if there > was a market for that device today)? I think this thread has gone slightly astray. The initial comparison was of a "ISP grade" router in 1991, to an "ISP Grade" router in 2009. There is no firm definition of this, so I can't put my finger on a single definition that would include or exclude boxes. That said, the "home routers" being discussed are not something a business needing GigE service would purchase. They are not something an ISP offering managed CPE to a GigE customer would purchase. Be it filtering, routing protocols, command line management, ssh, there are a host of features missing. I think it is quite cool that these low cost, specialized application devices exist. I'm not sure how this furthers the discussion of device growth related to bandwidth over time. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From bicknell at ufp.org Sat Dec 19 01:17:11 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 18 Dec 2009 22:17:11 -0800 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <4B2C68D8.7020006@firstpr.com.au> References: <4B2AD4A0.6080908@firstpr.com.au> <20091218020045.GA24163@ussenterprise.ufp.org> <4B2B4976.2070302@firstpr.com.au> <20091218155153.GA78343@ussenterprise.ufp.org> <4B2C68D8.7020006@firstpr.com.au> Message-ID: <20091219061711.GB34678@ussenterprise.ufp.org> In a message written on Sat, Dec 19, 2009 at 04:47:04PM +1100, Robin Whittle wrote: > OK. While there may be ways of marginally improving the operation of > the DFZ, including by improvements to the BGP protocol, the goal of > scalable routing is far beyond the modest improvements these might bring. As I outlined in another message, there are really three visions of the future. A) PA only, you will be aggregated. B) PI for everyone, take your addresses with you for every end user. C) Extending the current scheme of figuring out who is "worth" for PI. If we could do A, BGP is fine. For B, BGP is a lost cause. For C, it depends entirely on where you want to put the curve. I put your work in the "B" bucket, and in that context your statement is right. If we can't do that though, the "C" bucket may be the future, in which case I'm not sure your statement is accurate. > I think it should extend to SOHO "networks" even though they might > have most of their hosts behind NAT. For instance, if I am running a > business and am concerned about the reliability of my DSL line, I > should be able to get a 3G or WiMAX service as a backup, and use my > address space on either. That is a cheap backup arrangement - since > there's no need for new fibre or wires. My address space may only be > a single IPv4 address, but if I need it for mail, HTTPS e-commerce > transactions, VoIP etc. I would want it to keep working without a > hitch if the DSL line or its ISP was not working. I really like this concept, but somewhere my statistics professor is wispering in my ear. It's not entirely clear to me that from a measured uptime perspective that a future with a SOHO network with the ability to do the type of "backup" you describe is more reliable than a SOHO network with a single upstream. That is, the ability to have the backup just work introduces complexity with its own failure modes, and that may offset the redundancy. The average end user does not understand this concept though, so even if I am right they may demand reundancy, even if it lowers their uptime overall. > Can you point to any proposal to replace BGP which could be > introduced in a way which provided significant immediate benefits to > the early adoptors (not just dependent on how many others adopt it, > which initially is very low) while also working with the existing system? Can I point to a proposal, no. Can I imagine a new routing protocol, which could be run on a single AS, and redistributed in/out of BGP at the boarders during transition? Sure. > In the future, if mobility is developed as it should be, there will > be billions of devices, typically connected by a flaky long-latency > 3G link. So to say the whole Internet must follow your principle: I'm cherry picking a statement here, but I want to pick on the mobility technical qualifications. A "flaky long-latency 3G link" seems like a poor point to start. Given where wireless is and the future this seems to me a bit like designing BGP in the days of 9600 Baud Modems and assuming 10G wavelengths would have the same reliability factors. I feel like before any of the things discussed are out in production 5, 6, or 7G links will be seen as reliable and "low latency", but perhaps I'm optimistic. Again, thanks for providing the information in this forum. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From rw at firstpr.com.au Sat Dec 19 02:34:26 2009 From: rw at firstpr.com.au (Robin Whittle) Date: Sat, 19 Dec 2009 18:34:26 +1100 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <20091219061711.GB34678@ussenterprise.ufp.org> References: <4B2AD4A0.6080908@firstpr.com.au> <20091218020045.GA24163@ussenterprise.ufp.org> <4B2B4976.2070302@firstpr.com.au> <20091218155153.GA78343@ussenterprise.ufp.org> <4B2C68D8.7020006@firstpr.com.au> <20091219061711.GB34678@ussenterprise.ufp.org> Message-ID: <4B2C8202.1050204@firstpr.com.au> Hi Leo, Thanks for the continuing conversation. You wrote: >> OK. While there may be ways of marginally improving the operation of >> the DFZ, including by improvements to the BGP protocol, the goal of >> scalable routing is far beyond the modest improvements these might bring. > > As I outlined in another message, there are really three visions of the > future. > > A) PA only, you will be aggregated. > > B) PI for everyone, take your addresses with you for every end user. > > C) Extending the current scheme of figuring out who is "worth" for PI. > If we could do A, BGP is fine. Yes. But then there's no portability or multihoming unless everyone uses modified host stacks and apps according to a core-edge elimination scheme. Core-edge elimination schemes let applications see a single IP address (or whatever they use to identify hosts, uniquely, within the Internet), no matter what physical connection and physical address the host currently has. Then all hosts in end-user networks are on physical addresses of PA prefixes temporarily given to them by their current choice of ISP. But they retain their identity when they use another physical address. That is portability. By making them keep their identity and retain session continuity when they get a different physical address, this is multihoming - also with the possibility of doing inbound traffic engineering (TE). This has some similarity with current approaches to mobility. However, in these core-edge elimination schemes, ideally, the identifiers are drawn from a different namespace than the locators (physical addresses) and the applications somehow never need to worry about the locators. With a core-edge elimination scheme, all identifiers are "PI" - you keep them no matter what ISP you use. Meanwhile, the DFZ and the locators (conventional IP addresses of today, for instance) keeps on running BGP and the only routes advertised in the DFZ are those for ISPs. This number is assumed not to create too much of a scaling problem - which I think is reasonable. > For B, BGP is a lost cause. BGP on its own, with no additions, won't work - I agree. However, core-edge separation techniques keep the DFZ (core) to a small number of routes, while supporting a much larger number of end-user prefixes which are PI. > For C, it depends entirely on where you want to put the curve. The purpose of the RRG scalable routing project (as I understand it - I am a participant, not speaking for the RRG itself in any way) is to enable pretty much anyone who wants or needs multihoming, portability and/or inbound TE to have it - in a scalable fashion. "Portability" was not a popular term in the RRG and it still makes some people's skin crawl . . . What is really needed is freedom of choice between ISPs. In theory you could do this with PA space and some automated approach to renumbering. However, even with IPv6 which was meant to allow this, there is no way this is going to be practical. For one thing, it is complex and probably impossible to identify and change every place in a network where IP addresses appear. Secondly, it would be close to impossible to reliably test the switch-over without actually doing it - and then finding out the hard way it doesn't work. Even if this was possible, it doesn't cover the use of the physical addresses in configuration files and application code in other systems. VPNs are one example. DNS zone files are another. And to achieve multihoming, you would need all sessions to continue the moment the addresses changed. HIP and SCTP can do this, but that involves stack and host changes, and in the case of HIP, IPv6. So "Portability" is not officially what the RRG was trying to achieve. Its only due to the impossibility of making renumbering work reliably that "Portability" becomes the only way to ensure freedom of choice between ISPs. > I put your work in the "B" bucket, and in that context your statement is > right. Yes, if you mean "BGP on its own can't cope, so we need to add something to the routing and addressing system to achieve our goals, while keeping the DFZ routing table within reasonable bounds." > If we can't do that though, the "C" bucket may be the future, in > which case I'm not sure your statement is accurate. I am sure we can achieve scalable routing with a core-edge separation scheme. C is the current situation and the idea is that we won't need to be so fussy once there is a scalable form of PI space. >> I think it should extend to SOHO "networks" even though they might >> have most of their hosts behind NAT. For instance, if I am running a >> business and am concerned about the reliability of my DSL line, I >> should be able to get a 3G or WiMAX service as a backup, and use my >> address space on either. That is a cheap backup arrangement - since >> there's no need for new fibre or wires. My address space may only be >> a single IPv4 address, but if I need it for mail, HTTPS e-commerce >> transactions, VoIP etc. I would want it to keep working without a >> hitch if the DSL line or its ISP was not working. > > I really like this concept, but somewhere my statistics professor is > wispering in my ear. > > It's not entirely clear to me that from a measured uptime perspective > that a future with a SOHO network with the ability to do the type > of "backup" you describe is more reliable than a SOHO network with a > single upstream. That is, the ability to have the backup just work > introduces complexity with its own failure modes, and that may offset > the redundancy. I agree - extra complexity could result in overall less reliability than reliance on a single system which is in fact highly reliable. I don't clearly remember a time in the last 3.5 years when my DSL service (Internode, via a Telstra DSLAM and 4km line) has been down. I was trying to estimate an upper bound for how many end-user networks the scalable routing solution would need to work with if there was no mobility. I think the number is probably going to be a lot lower, such as a million or so in the long-term. Nor am I arguing that mobility will cover 10 billion devices. More likely a few billion. I was just trying to find an upper bound, because these various core-edge separation schemes are being evaluated, in part, on how well they scale to some large number of end-user network prefixes. > The average end user does not understand this concept though, so even if > I am right they may demand reundancy, even if it lowers their uptime > overall. Indeed - it would be possible to market a scare campaign of an entire business physically hanging off a single fibre, or a single twisted pair of 0.7mm copper wires, and spook millions of people into getting a backup link and multihomable address space, even if the overall outcome was more downtime. >> Can you point to any proposal to replace BGP which could be >> introduced in a way which provided significant immediate benefits to >> the early adoptors (not just dependent on how many others adopt it, >> which initially is very low) while also working with the existing system? > > Can I point to a proposal, no. Can I imagine a new routing protocol, > which could be run on a single AS, and redistributed in/out of BGP > at the boarders during transition? Sure. If you can think of a way of solving the problem by progressively replacing BGP on a voluntary basis, then 22 December is the deadline for registering RRG proposals. >> In the future, if mobility is developed as it should be, there will >> be billions of devices, typically connected by a flaky long-latency >> 3G link. So to say the whole Internet must follow your principle: > > I'm cherry picking a statement here, but I want to pick on the > mobility technical qualifications. A "flaky long-latency 3G link" > seems like a poor point to start. Given where wireless is and the > future this seems to me a bit like designing BGP in the days of > 9600 Baud Modems and assuming 10G wavelengths would have the same > reliability factors. > > I feel like before any of the things discussed are out in production 5, > 6, or 7G links will be seen as reliable and "low latency", but perhaps > I'm optimistic. > > Again, thanks for providing the information in this forum. Thanks. Current wireless communication technologies are pretty close to the physical limits imposed by limited radio spectrum. Unless we put a base-station every 20 metres, then each device only has a limited amount of spectrum to use. The current 3G techniques and the upcoming 4G, which use OFDM to squeeze every last drop of bandwidth from the spectrum, are about as good as it gets. Its not like semiconductors or fibre, which can be pushed to extraordinary lengths, since they are dedicated to a single user. Wireless depends on limited spectrum shared over some number of devices, in a noisy environment, in a given area, with crosstalk from similar systems in other areas. The devices are moving, so there is Doppler shift. They are moving into the areas best served by other base-stations too, and there needs to be exploration of all the conditions and a quick handover. OFDM achieves high throughput by being coupled with forward error correction, and then scattering the resulting bits over time and frequency, so a single frequency interferer or single time glitch at all frequencies doesn't clobber enough bits to stop the FEC from fully reconstructing the original data. So these high performance systems involve unavoidable latency, in order to operate reliably in the noisy environment. I am keen to get some responses to my critique of putting more routing and addressing responsibilities into all hosts: http://www.firstpr.com.au/ip/ivip/RRG-2009/host-responsibilities/ - Robin From michel at arneill-py.sacramento.ca.us Sat Dec 19 03:25:02 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sat, 19 Dec 2009 00:25:02 -0800 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <20091218195110.GA99464@ussenterprise.ufp.org> References: <20091218155153.GA78343@ussenterprise.ufp.org><471D76419F9EF642962323D13DF1DF6901160A@newserver.arneill-py.local> <20091218195110.GA99464@ussenterprise.ufp.org> Message-ID: <471D76419F9EF642962323D13DF1DF69011616@newserver.arneill-py.local> > Leo Bicknell wrote: > As I see it, the problem space has three, high level, > diverging paths: > A Multihoming happens entirely at the host, making > PA-only possible. > B The routing system can scale to PI, so everyone has PI. > C Neither A or B is possible, so we attempt to decide > who is worthy of PI. There is also D: Dual space protocols (ID/LOC). None of them really got traction in the IETF. > It seems to me we are in case C now. We are. And in the case of IPv6, we are because the RIRs passed policies to allocate PI to non-LIRs, not because the IETF wanted so. > the IETF tried A several years ago and gave up, and the > IETF is now trying B. (roughly) I don't think that the IETF gave up on A. And although the IRTF is looking at B, there still is a long road before it gets traction in the IETF, IMHO. > Which raises an interesting question, why hasn't SCTP taken off more? I have met in person with some of the guys heavily involved in SCTP ways back when; very interesting work. I think that in the end the reason it has not taken off more is basically the same reason none of the host-based multihoming solutions has taken off either: too complex. Anything that involves multiple addresses per host and heaven forbid even worse multiple interfaces per host is a nightmare to TE and troubleshoot. Imagine trying to troubleshoot a network issue with your typical tech support subcontracted overseas when the thing involves multiple interfaces with multiple addresses crossing multiple backbones. Good luck; as of today there are no tools for this and no money to build them. Sadly, nothing matches the raw simplicity of this unique PI prefix that, unfortunately, makes the DFZ big. Michel. From michel at arneill-py.sacramento.ca.us Sat Dec 19 03:34:39 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sat, 19 Dec 2009 00:34:39 -0800 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <4B2C8202.1050204@firstpr.com.au> References: <4B2AD4A0.6080908@firstpr.com.au> <20091218020045.GA24163@ussenterprise.ufp.org> <4B2B4976.2070302@firstpr.com.au> <20091218155153.GA78343@ussenterprise.ufp.org> <4B2C68D8.7020006@firstpr.com.au><20091219061711.GB34678@ussenterprise.ufp.org> <4B2C8202.1050204@firstpr.com.au> Message-ID: <471D76419F9EF642962323D13DF1DF69011617@newserver.arneill-py.local> > Robin Whittle wrote: > I am sure we can achieve scalable routing with a > core-edge separation scheme. C is the current > situation and the idea is that we won't need to > be so fussy once there is a scalable form of PI space. I will point out that this approach has been tried many times before: 8+8, GSE, MHAP, etc. Michel. From rw at firstpr.com.au Sat Dec 19 07:55:50 2009 From: rw at firstpr.com.au (Robin Whittle) Date: Sat, 19 Dec 2009 23:55:50 +1100 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <471D76419F9EF642962323D13DF1DF69011616@newserver.arneill-py.local> References: <20091218155153.GA78343@ussenterprise.ufp.org><471D76419F9EF642962323D13DF1DF6901160A@newserver.arneill-py.local> <20091218195110.GA99464@ussenterprise.ufp.org> <471D76419F9EF642962323D13DF1DF69011616@newserver.arneill-py.local> Message-ID: <4B2CCD56.20801@firstpr.com.au> Short version: More on latency of 3G and GPRS wireless links. Historical approaches to scalable routing and addressing: 8+8, GSE and MHAP. Hi Michel, Before replying to your message, I want to mention that there's a much more important factor in the latency of 3G wireless data than the modulation technique - the time-slicing of the upstream and downstream channels. Downstream, the device has to wait its turn for data to arrive for it, rather than some other device. Upstream, it has to wait for the right time to transmit - and there are various ways this can be organised. Here are some observations done quickly. Using a 3G HDSPA link and pinging from WinXP I find a RTT of 114 to about 300ms to the first router at the ISP. But the first packet, after a few seconds of inactivity, might have a RTT of 800 to 1500ms. (The 3G network is Optus and the router is at Internode in my city - Melbourne.) When the link switches itself to WCDMA, for reasons unknown, the RTT is typically 400 to 500ms with initial packet RTTs around 1000 to 1200ms. Forcing the modem to GSM (GPRS data), I get RTT times 500 to 1300ms, with no obvious extra time for the first packet. I think for the 3G modes, the initial packet extra delay reflects not so much the slots for upstream and downstream, but the modem going from inactive to active, which takes a while to reserve some upstream and downstream bandwidth. Without this, the modem would be chewing spectrum and time all the time - which I suspect it may be doing in GPRS mode. You wrote, in part: >> Which raises an interesting question, why hasn't SCTP taken off more? > > I have met in person with some of the guys heavily involved in SCTP ways > back when; very interesting work. I think that in the end the reason it > has not taken off more is basically the same reason none of the > host-based multihoming solutions has taken off either: too complex. > > Anything that involves multiple addresses per host and heaven forbid > even worse multiple interfaces per host is a nightmare to TE and > troubleshoot. Imagine trying to troubleshoot a network issue with your > typical tech support subcontracted overseas when the thing involves > multiple interfaces with multiple addresses crossing multiple backbones. > Good luck; as of today there are no tools for this and no money to build > them. > > Sadly, nothing matches the raw simplicity of this unique PI prefix that, > unfortunately, makes the DFZ big. This is with host-based multihoming - core-edge elimination schemes. A core-edge separation scheme does the work in ITRs and ETRs, so there are no questions about host software. This is more complex than at present - but extra complexity seems unavoidable. >> Robin Whittle wrote: >> I am sure we can achieve scalable routing with a >> core-edge separation scheme. C is the current >> situation and the idea is that we won't need to >> be so fussy once there is a scalable form of PI space. > > I will point out that this approach has been tried many times > before: 8+8, GSE, MHAP, etc. I don't know much about these, but 8+8 and GSE are mentioned in: http://tools.ietf.org/html/draft-ietf-ipngwg-gseaddr-00 http://tools.ietf.org/html/rfc3177 I don't know anything about your MHAP - but its ca. 2003 home is: http://arneill-py.sacramento.ca.us/mhap/ I can't find mention of MHAP in my archive of RRG messages. There are 42 mentions of "8+8" and 160 mentions of GSE. Ran Atkinson wrote a little timeline of GSE: http://www.ops.ietf.org/lists/rrg/2008/msg01488.html In June 2008, Tony Li (RRG co-chair) wrote to me: http://lists.arin.net/pipermail/arin-ppml/2008-June/010988.html >> Please, please, please go read GSE. You may not like it, you may >> not agree with it, but until you grok it, you haven't seen a big >> chunk of the solution space. http://tools.ietf.org/html/draft-ietf-ipngwg-gseaddr-00 I had a quick look at it, but it is for IPv6 only so I didn't study it in depth. - Robin From owen at delong.com Sat Dec 19 08:42:10 2009 From: owen at delong.com (Owen DeLong) Date: Sat, 19 Dec 2009 05:42:10 -0800 Subject: [arin-ppml] Does Moore's law help with routing table growth? In-Reply-To: <4B2C65E1.3090705@gmail.com> References: <4B2C5DDD.7050501@gmail.com> <471D76419F9EF642962323D13DF1DF69011612@newserver.arneill-py.local> <4B2C65E1.3090705@gmail.com> Message-ID: <9BEF39BF-519E-48FC-AAC0-C792FE7F2EB2@delong.com> > >> There is no such thing as "PI for everyone" in the foreseeable future. >> > > If by "everyone" you mean "every organization with a single-homed network", then I agree, that will be infeasible at least as long as we're running BGP4. But as long as we move the bar gradually, I think we can safely move toward a situation where PI addresses are generally available for multihomed organizations who are willing to pay their providers enough to run BGP. BGP is not the driving deficiency in this situation. Indeed, we could switch to locator-based forwarding in the IDR realm without actually changing BGP. We will, however, need to change the packet header to at least include a destination IDR Locator (such as adding a 32-bit field for the destination ASN). BGP4 contains a superset of the required FIB information for this, so, the protocol is not the major limitation there. BGP does run into other scaling limits (churn rates, etc.) which do scale somewhat with prefix distribution, but, I don't think that would outpace moore's law if we were able to do FIB lookups in TCAM based on dest-AS instead of prefix. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sat Dec 19 08:59:42 2009 From: owen at delong.com (Owen DeLong) Date: Sat, 19 Dec 2009 05:59:42 -0800 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <4B2C8202.1050204@firstpr.com.au> References: <4B2AD4A0.6080908@firstpr.com.au> <20091218020045.GA24163@ussenterprise.ufp.org> <4B2B4976.2070302@firstpr.com.au> <20091218155153.GA78343@ussenterprise.ufp.org> <4B2C68D8.7020006@firstpr.com.au> <20091219061711.GB34678@ussenterprise.ufp.org> <4B2C8202.1050204@firstpr.com.au> Message-ID: On Dec 18, 2009, at 11:34 PM, Robin Whittle wrote: > Hi Leo, > > Thanks for the continuing conversation. You wrote: > >>> OK. While there may be ways of marginally improving the operation of >>> the DFZ, including by improvements to the BGP protocol, the goal of >>> scalable routing is far beyond the modest improvements these might bring. >> >> As I outlined in another message, there are really three visions of the >> future. >> >> A) PA only, you will be aggregated. >> >> B) PI for everyone, take your addresses with you for every end user. >> >> C) Extending the current scheme of figuring out who is "worth" for PI. > > >> If we could do A, BGP is fine. > I think we are mixing up concepts and overloading terms in this discussion even worse than the overloaded locator/identifier semantics of IP addresses. BGP is not the primary issue. The primary issue we are faced with is the scalability of the way we make forwarding decisions in the IDR (Inter-Domain Routing) realm. Currently, we make those decisions based on the IP prefix, thus overloading the IP addresses task as an end-system identifier with additional topological locator semantics. That is the issue which prevents scaling the routing system to PI for everyone, much more than any of the deficiencies in BGP4. In fact, BGP4 contains a superset of that which would be necessary to build a FIB that could forward based on destination ASN. What is needed is a field in the packet header for the destination ASN to be inserted at some point close to the origin, and a way to do so without affecting host protocol stacks, at least initially. A solution which can be incrementally deployed would be vastly superior to a solution which requires a flag day since a flag day is pretty much impossible in the current internet. I am glad to see IETF working on this problem, but, I believe that all of the current solutions are vastly more complicated than they need to be, and, encompass changing a lot more than needs to be changed. Owen From owen at delong.com Sat Dec 19 09:03:21 2009 From: owen at delong.com (Owen DeLong) Date: Sat, 19 Dec 2009 06:03:21 -0800 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <471D76419F9EF642962323D13DF1DF69011616@newserver.arneill-py.local> References: <20091218155153.GA78343@ussenterprise.ufp.org><471D76419F9EF642962323D13DF1DF6901160A@newserver.arneill-py.local> <20091218195110.GA99464@ussenterprise.ufp.org> <471D76419F9EF642962323D13DF1DF69011616@newserver.arneill-py.local> Message-ID: <8D346C3A-F2C9-42B2-81BD-F2B4E857BAB4@delong.com> On Dec 19, 2009, at 12:25 AM, Michel Py wrote: >> Leo Bicknell wrote: >> As I see it, the problem space has three, high level, >> diverging paths: >> A Multihoming happens entirely at the host, making >> PA-only possible. >> B The routing system can scale to PI, so everyone has PI. >> C Neither A or B is possible, so we attempt to decide >> who is worthy of PI. > > There is also D: Dual space protocols (ID/LOC). None of them really got > traction in the IETF. > >> It seems to me we are in case C now. > > We are. And in the case of IPv6, we are because the RIRs passed policies > to allocate PI to non-LIRs, not because the IETF wanted so. > Space A is a non-starter in the real world and was a strong barrier to IPv6 adoption. The IETF wanting to restrict the world to case A simply wasn't going to fly. The RIRs recognized this and passed pragmatic policy to enable IPv6 to get deployed, since it was far more important to get people moving on IPv6 than to pretend we didn't have to solve the routing scalability problem. The fact that the IETF couldn't see this does not really further the discussion. > > Sadly, nothing matches the raw simplicity of this unique PI prefix that, > unfortunately, makes the DFZ big. > It doesn't have to, if you consider using a different locator for your IDR forwarding decisions, such as destination ASN. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel at arneill-py.sacramento.ca.us Sat Dec 19 18:36:00 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sat, 19 Dec 2009 15:36:00 -0800 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <4B2CCD56.20801@firstpr.com.au> References: <20091218155153.GA78343@ussenterprise.ufp.org><471D76419F9EF642962323D13DF1DF6901160A@newserver.arneill-py.local> <20091218195110.GA99464@ussenterprise.ufp.org> <471D76419F9EF642962323D13DF1DF69011616@newserver.arneill-py.local> <4B2CCD56.20801@firstpr.com.au> Message-ID: <471D76419F9EF642962323D13DF1DF69011618@newserver.arneill-py.local> Robin, > Robin Whittle wrote: > I can't find mention of MHAP in my archive of RRG messages. MHAP was a too-little-too-late off-IETF effort. > A core-edge separation scheme does the work in ITRs and ETRs, > so there are no questions about host software. This is more > complex than at present - but extra complexity seems unavoidable. I know, I designed one years ago ;-) Read the following link, it's short. You may find that it looks a lot like what you are talking about. http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-intro-00.txt Read this one very fast; don't bother getting into the details. http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt Finally, this page may provide you with interesting historic information: http://arneill-py.sacramento.ca.us/ipv6mh/ Keep it mind it's for part a graveyard of torpedoed-by-the-IETF solutions. Any effort to revive any of these concepts there will have to understand why they failed in the first place. > Robin Whittle wrote: > http://tools.ietf.org/html/draft-ietf-ipngwg-gseaddr-00 > I had a quick look at it, but it is for IPv6 only so I > didn't study it in depth. Anything at the time was designed with the assumption that IPv6 would be widely deployed by now. In the "Goals and non-goals" section of MHAP, I wrote in 2002: > There is no goal at this time to provide an IPv4 solution. > Although the protocol could be adapted to IPv4, the editor > does not think that it can realistically implemented on > today's Internet without a successful IPv6 implementation, > and, by the time that is realized, solving the IPv4 problem > might be a non-issue. Enjoy! Michel. From danny at tcb.net Sat Dec 19 22:23:42 2009 From: danny at tcb.net (Danny McPherson) Date: Sat, 19 Dec 2009 20:23:42 -0700 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <4B2AD4A0.6080908@firstpr.com.au> References: <4B2AD4A0.6080908@firstpr.com.au> Message-ID: On Dec 17, 2009, at 6:02 PM, Robin Whittle wrote: > Further to the threads: > > A challenge to the assumption that a big DFZ is a problem > debunking the myth that Moore's law helps I find it interesting that folks in RRG are worrying most about the number of unique *prefixes* in the DFZ, while the number of unique *routes* (prefix/path attributes) is growing steeper. Further, most all the work in the IETF BGP-related working groups aims to ADD more routes in order to support multi-path, alleviate route oscillation, provide faster convergence, obtain more operations visibility, etc.., pretty much completely in odds with the RRG work, and exacerbating the issues of scalability and instability, path hunting, RIB issues, RAM, CPU, FIB I/O, etc.. More on some of my thoughts related to this topic here: Perhaps the disparity between the IETF work and the IRTF RRG work is that the operators are busy running networks and dealing with real operational issues, while the RRG folks are solving problems that won't been an issue for a decade or more.. This seems eerily similar to the IPv6 conundrum as of late, eh? -danny From rw at firstpr.com.au Sun Dec 20 06:21:40 2009 From: rw at firstpr.com.au (Robin Whittle) Date: Sun, 20 Dec 2009 22:21:40 +1100 Subject: [arin-ppml] Modified Header Forwarding for scalable routing In-Reply-To: References: <4B2AD4A0.6080908@firstpr.com.au> <20091218020045.GA24163@ussenterprise.ufp.org> <4B2B4976.2070302@firstpr.com.au> <20091218155153.GA78343@ussenterprise.ufp.org> <4B2C68D8.7020006@firstpr.com.au> <20091219061711.GB34678@ussenterprise.ufp.org> <4B2C8202.1050204@firstpr.com.au> Message-ID: <4B2E08C4.7020004@firstpr.com.au> Short version: Owen DeLong suggested a scalable routing solution would be to have DFZ routers modified to handle packets with modified header structure. As I understand it, the new packet format would contain the ASN of the destination ISP and the DFZ routers forward it on this basis, without looking at the destination address, which would remain unaltered. I discuss this idea and two other proposals for Modified Header Forwarding: ETR Address Forwarding (EAF) - for IPv4 Prefix Label Forwarding (PLF) - for IPv6 These are extensions to my Ivip core-edge separation proposal. These would at least be used in the long-term future - once all DFZ routers had the new capabilities. In the long- term this would eliminate encapsulation overhead (which is monstrous for IPv6 VoIP packets) and Path MTU Discovery problems. Ideally, they would be used for Ivip's initial introduction - then we wouldn't need to worry about encapsulation overhead or Path MTU Discovery problems - so ITRs and ETRs could be very simple indeed. But that means having most DFZ routers upgraded before Ivip could be used. All such proposals require upgrades to essentially all DFZ routers. However, my two only involve FIB changes, and for PLF a minor minor RIB change. Neither requires a new FIB namespace or any change to BGP operations. Hi Owen, In "Re: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation" you wrote, in part: > BGP is not the primary issue. The primary issue we are faced with is the > scalability of the way we make forwarding decisions in the IDR (Inter-Domain > Routing) realm. I understand you are suggesting that if there was a different algorithm for forwarding packets, including extra information in the packet headers, then BGP (I guess a suitably modified version of BGP) would not be such a limiting factor as it is today in the provision of multihoming, portability and inbound TE to a much larger number of end-user networks. > Currently, we make those decisions based on the IP prefix, thus overloading > the IP addresses task as an end-system identifier with additional topological > locator semantics. Another way of saying this is that the IDR (Inter Domain Routing) system can only use the same bits, or a subset of the same bits, for forwarding each packet as we use for identifying hosts for host-to-host communications. > That is the issue which prevents scaling the routing system to PI for everyone, > much more than any of the deficiencies in BGP4. In fact, BGP4 contains a > superset of that which would be necessary to build a FIB that could forward > based on destination ASN. What is needed is a field in the packet header > for the destination ASN to be inserted at some point close to the origin, > and a way to do so without affecting host protocol stacks, at least initially. I think that both the IPv4 and IPv6 headers could be modified to contain an ASN. I understand from this that you are suggesting that packets would be emitted normally by sending hosts, but that they would all be processed by something resembling an ITR (Ingress Tunnel Router) of the core-edge separation schemes (LISP, APT, Ivip and TRRP). This ITR function would be in the sending host or be in a router in the ISP or end-user network where the sending host is located. The ITR function could also be out in the DFZ: a router advertising prefixes which match the unmodified packets' destination address. (This is Ivip's Open ITR in the DFZ - OITRD - or LISP's "Proxy Tunnel Router".) In all cases, the ITR would alter the format of the packet header in a way that suitably modified routers in the DFZ (and also in ISP and end-user networks, if the ITR function was within those networks, or in the sending hosts) would forward the packet according to this new information. At some point, the modification would have to be reversed, to reconstitute the packet ready for the destination host. In core-edge separation schemes, decapsulation is done by an ETR (Egress Tunnel Router). The ETR needs to be at some point in the destination ISP or end-user network where the packet in its original form will be forwarded to its proper destination - not to an ITR which would modify it again. Maybe it would be good enough to use the ASN directly, since a large network, or a network with multiple topologically diverse border routers would use the same ASN for all those border routers and assuming the ASN is happy to accept incoming traffic for any of its internal destinations on any of its BRs. However, it would be possible to extend your proposal to use a different number than the ASN to control the forwarding of the packet. What you are suggesting is something like a core-edge separation scheme - but maybe it is something different, since within the core, you are forwarding packets according to an ASN number which is added to the packet somewhere. ASN is a different namespace from IP address, whereas core-edge separation schemes keep the one namespace (IP addresses) and use one subset for scalable end-user network space ("edge" addresses) and retain the rest as "core" addresses, for ISPs and end-user networks with conventional PI space. Your proposal is not exactly a core-edge elimination scheme - since they tend to change the hosts so the applications address hosts by one kind of address ("edge") and the hosts are physically accessed by another kind "core", with the routing system operating much as it does today, forwarding according to destination address, where this is of the physical address of the host ("core" address AKA "locator") and is unrelated to its logical application level address ("edge" AKA "identifier"). Anyway, as I understand it, your proposal needs some things resembling ITRs, which accept traffic packets with certain ranges of destination addresses (that of the "edge" subset of all IP addresses) and do something to the packet to get them to an appropriate ETR (or whatever it is which converts the packet to its original form) near the destination end-user network. This involves a "mapping lookup" to produce something which will enable the packet to be forwarded to the ETR. With LISP, APT, Ivip and TRRP, the mapping lookup produces an ETR address, and the packet is encapsulated so it is tunneled to the ETR. In your proposal, the mapping produces an ASN of the ISP which the destination network is connected to. The DFZ forwards the packet to the correct ASN - to any border router of that ASN, typically the "closest" (in terms of how the DFZ routers choose their paths). As I understand it, the effect of your proposal would be: 1 - If an ASN advertises a prefix on any one of its BRs, it must be prepared to accept packets matching this prefix on all of its BRs. I suspect this is not what any ISP wants - since it gives it no control over where incoming traffic arrives. But for the purpose of discussion, I will assume your scheme is desirable. 2 - The DFZ routers wouldn't need a large FIB - at least for these modified packets, since the FIB wouldn't be dealing with the destination prefixes of these packets which are addressed to hosts in end-user networks with the new kind of scalable PI space. This new section of the FIB would only match ASNs, and for each ASN, the router would have one best path. So your proposal reduces FIB size, but makes it more complex. 3 - The DFZ routers may well be running BGP - but for these end-user network prefixes your scheme works for, it is not clear why. Maybe that's the benefit - these end-user network prefixes should not be advertised in the DFZ at all. In that case, you radically reduce the RIB size and so really do achieve routing scalability, since this is the main goal of current scalable routing proposals. However, see point 6. The DFZ routers would still have RIB and FIB entries for prefixes not of the scalable end-user PI type covered by your scheme. But this is scalable. 4 - Each DFZ router needs to decide a best path to the "nearest" ideally (actually any one of them) BR of each ASN. This is a different task from what BGP is intended to achieve. I suppose if every BR advertised at least one conventional prefix, then you could extract from the RIB all the information you need and choose the apparently nearest path to a BR of each ASN, to write this to this new ASN section of the FIB. 5 - The BRs of all these ASNs would need to recognise the modified header and reconstruct the packet so it will be forwarded to and recognised by the destination host. 6 - But what of the "ITR" function - the router somewhere which modifies the packet header to install the ASN? In the current DFZ, this could be done by a suitably modified DFZ router. All DFZ routers know about all advertised prefixes and in the RIB you can easily see the ASN of the BR which advertised the prefix. But I think a major goal of your proposal is to avoid all these scalable PI prefixes from being advertised in the DFZ (3 above). In that case, the "ITR" function can't be a DFZ router of the new kind. It has to look up a mapping database - either within itself or at some local or distant query server system. The mapping function accepts the packet's destination address and returns an ASN number. Before this, the "ITR" function needs to recognise whether it the destination address matches a conventionally advertised prefix. So I guess if the packet's destination address matches a prefix in the conventional IP address FIB, forward it that way. If not, look up the mapping function. If the mapping is to an ASN, modify the packet. If there is no such mapping, drop the packet. So these "ITR" devices need to have a complete copy of the mapping database, or to be able to query something which has it and to cache the result in its "FIB", or whatever it uses to handle incoming packets. So if your aim is to remove these prefixes from the DFZ, then your ITR-like devices do resemble an ITR of LISP, APT etc. in that there needs to be a global mapping database, which tells the ITRs how the prefixes of scalable end-user address space are moved from one ISP to another. Then, you get into questions of multihoming service restoration. How does your system respond to an end-user network no longer being able to use the link from its ISP with ASN AAA, and needing its packets to be forwarded to another ISP with ASN BBB? If this changed requirement could be transferred to all your "ITR" devices in real-time, that would solve the problem pretty well. Ivip does it this way. The other core-edge separation schemes assume this is either impossible or undesirable. So the ITR gets mapping in the form of "send these packets to AAA, unless it is unreachable - in which case send them to BBB". Then the ITR has to do reachability testing and it gets very complex. Ivip ITRs are simpler. They do not test for reachability to ETRs. They only have one ETR address and the tunnel packets to that address. If your ITR was like a current DFZ router, then it could find out about AAA being unreachable and BBB being the new ASN to forward the packets to, by allowing the current DFZ to propagate best paths to it. However, I think the main benefit of your scheme would be to avoid advertising all these end-user prefixes in the DFZ - so this won't work. I think that to be really useful for scaling, your scheme would need a separate (not BGP-based) mapping arrangement by which the ITR functions could quickly and reliably decide which ASN to forward the packets to. I think this requires some separate mapping system. In the mapping systems of core-edge separation schemes, a subset of the IP address range returns a positive response from the mapping system. These are what I call the "Scalable PI" (SPI) addresses - that subset of the address range which is used by end-user networks for scalably getting address space which is portable and gives them multihoming and inbound TE. (This may also be thought of as the "edge" subset, or the "identifier" subset of the whole IP address range. This subset of the address space would be many separate prefixes scattered through the range. The remainder are "core" (AKA "locator" or "RLOC" in LISP), since these core addresses continue to function as they do today, with all routers, including DFZ routers, using these addresses to forward packets all the way to their destination. Core addresses can still be used for end-user network PI space, but this is not scalable. The usual arrangement for a core-edge separation scheme is to encapsulate the packet and tunnel it to an ETR. ETRs are always on "core" addresses. The total packet, now longer due to the one or more headers used to encapsulate it, is handled in the same way by DFZ routers as any other packet, so the DFZ routers don't need any upgraded functionality. With your suggested scheme, there is no encapsulation and the packet is not made any longer. The DFZ routers forward the packet to the "nearest" BR of the currently mapped ASN for the packet's destination prefix. So there's no encapsulation overhead. If the packet is too long for one of these DFZ routers, it will presumably convert the packet back to its original form and send a conventional ICMP Packet Too Big message, so the sending host will get this message and retry with a shorter packet. So there are no thorny PMTUD problems, as there are with encapsulation. With what you are suggesting, the DFZ routers need to be upgraded to recognise the new packet format. This raises major problems for widespread voluntary adoption - but I think it is well worth exploring. In the long term, it will cost little to progressively upgrade all DFZ routers with the new function. So in the long-term, a core-edge separation scheme could be migrated to this modified header arrangement without significant cost. Its just a matter of making sure all new routers perform the function. When all DFZ routers are of this type, the system can be turned on. I think that using modified headers only makes sense if the core-edge separation scheme does not need to send any extra information along with the traffic packet. LISP does send extra info with each traffic packet - in a LISP header which itself is behind a UDP header. Ivip does not send any extra information and uses simple IP-in-IP encapsulation. (I am not sure whether APT or TRRP send extra data.) If the core-edge separation scheme needs to send extra data with each traffic packet, then most of the benefits of modifying the header are lost, since there would still need to be some additional header, which lengthens the total packet and causes a lot of trouble with Path MTU Discovery. Avoiding the encapsulation overhead and PMTUD complexities are extremely worthwhile goals. Sorry this was rather long, but I wanted to say that I think modified header forwarding is worth exploring - and I tried to imagine what your scheme would involve. Since you are prepared to consider upgrading all DFZ routers and modifying the IP header, here are my two proposals which do this. They are both extensions to Ivip - one for IPv4 and one for IPv6. ETR Address Forwarding (EAF) - for IPv4 http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw Do away with fragmented packets in the DFZ. If any host sends a fragmentable packet above a certain length - somewhere between 1000 and 1500 bytes - it will be dropped. This should not cause much trouble since well written applications have been able to use RFC 1191 PMTUD since 1990. (Google servers regularly put out long fragmentable packets, but that could easily be changed.) Do away with header checksums. IPv6 gets along OK without them. Now we can set the Evil Bit 48 to 1, indicating the header has the new EAF format. We now have 30 bits to play with: 1 bit "More Fragments" 13 bits "Fragment Offset" 16 bits "Checksum" These 30 bits are now used to specify the IP address of the ETR. The DFZ routers recognise such packets and use this 30 bit ETR address for forwarding, with their conventional IP address FIB, rather than the destination address. The DFZ routers do ordinary BGP and run their FIBs as usual - with just this potential conversion step added. The ETR addresses are all "core" addresses - in prefixes of ISPs. So there's no need to advertise each individual prefix of millions of end-user networks using scalable PI space. ETRs need to be on addresses ending in binary 00. They reconstruct the original state of the header and forward the packet to the destination end-user network. Prefix Label Forwarding (PLF) - for IPv6 http://www.firstpr.com.au/ip/ivip/ivip6/ Grab the 20 bit Flow Label and put it to good use. A non-zero Flow Label indicates this packet has the modified IPv6 header. One way of using this would be to use all 2^20 code points to refer to ETRs which are reachable via up to 2^20 separately advertised prefixes. These are prefixes advertised by ISPs, each one for either a single ETR, or multiple ETRs via some further mechanisms I won't mention here. 2^20 is an upper limit. Hopefully the system would work fine with a few hundred thousand such prefixes. In this first approach we have a block of IPv6 address space which is divided into 2^20 equal-sized prefixes, and assign these to ISPs by some means. Then, the 20 bits in the modified header is used to alter the FIB algorithm from using the destination address (which remains unchanged, being the scalable PI address of the destination host) to using the address extended from these 20 bits. The rest of the FIB operation remains the same. There are other ways of using the bits. The way I am currently thinking of is to reserve 2^19 code points for use in the way just described - to forward the packet across the DFZ to a BR which advertises a particular prefix. Then reserve the other 2^19 code points for private use within each ASN, for whatever purposes the network chooses. It would also be possible to use all 2^20 code points as described above in the DFZ and let ASNs use them for whatever they like inside their own networks, but for robustness I think it is best to keep the namespaces separate. Both these schemes keep the FIB of DFZ routers substantially the same - whereas I think yours involves significant additions, by way of a new kind of lookup in the ASN namespace, instead of the IP namespace. Both of them keep BGP going as it does today - except that there is no need to advertise the prefixes of scalable PI end-user address space, just as is the case with Ivip etc. using encapsulation. > A solution which can be incrementally deployed would be vastly superior > to a solution which requires a flag day since a flag day is pretty much > impossible in the current internet. "Incremental deployment" turns out to mean different things to different people. I thought it meant "substantial benefits to early adoptors, irrespective of how few adopters there were, while being backwards compatible with existing systems and not disrupting anything". But other people had a much less restrictive understanding of the term, so I don't use it any more. The trouble with your scheme and my two is that they only produce benefits when all, or essentially all, DFZ routers are upgraded. An ITR can only convert a packet to the new format if it can be sure that all routers (DFZ and any internal routers at its end, or the other) between itself and the ETR will handle the new format. If there are networks which don't have ETRs, then it doesn't matter if their BRs and any DFZ routers serving them don't have the upgrades. However, every other DFZ router needs to be upgraded. So I think these schemes are very hard to introduce with a new system. Ideally, we could introduce Ivip with PLF on IPv6. It will be a long time before we really need a scalable routing solution on IPv6, so it would be great to do it this way from the start. This would mean we don't have to worry about PMTUD problems at all, or about encapsulation overhead. ITRs and ETRs could be very simple. Encapsulation overhead with IPv6 is much worse than in IPv4, especially for short packets such as VoIP. At least Ivip uses simple IP-in-IP encapsulation. LISP uses UDP and its own LISP header too, so the encapsulation can easily be longer than the VoIP payload. Ideally we could upgrade all IPv4 DFZ routers, with a firmware upgrade, before introducing Ivip. The change is purely in the FIB. The longer this scalable routing debate goes on, the more DFZ routers should be fully firmware based and the more it will be practical to upgrade the lot of them by the time a scalable routing solution is actually introduced. If this can't be done - if Ivip is introduced with encapsulation for either IPv4 or IPv6 or both, then the systems should be designed for long-term transition to Modified Header Forwarding, at some time in the future when all the DFZ routers have the upgraded functionality. This need not cost much - AFAIK, it is purely a firmware matter for modern routers, and is not particularly complex. > I am glad to see IETF working on this problem, but, I believe that all of the > current solutions are vastly more complicated than they need to be, and, > encompass changing a lot more than needs to be changed. I think that if you worked on your proposal in detail, with the goal of removing all these end-user prefixes from the DFZ, then you would have some thorny problems to solve with the mapping system and how the ITRs would forward packets to BBB instead of AAA for multihoming service restoration. You could do it with something like Ivip's real-time mapping system, or you could do it with the slow approach, and more complex mapping and more complex ITRs of LISP, APT and TRRP. Then, I don't think your system would be significantly simpler than these proposals. I think it would be better to use one of my approaches, rather than just the ASN, because I am pretty sure that ASNs want to be able to specify which of their BR gets packets addressed to a given prefix. Ivip and the other core-edge separation schemes achieve this, but your's, as far as I know, will send packets to any BR of the ASN which advertises the prefix at even one of its BRs. Also, you would have to figure out what to do if the BRs of two ASNs advertise the same end-user prefix. - Robin http://www.firstpr.com.au/ip/ivip/ From rw at firstpr.com.au Sun Dec 20 06:37:16 2009 From: rw at firstpr.com.au (Robin Whittle) Date: Sun, 20 Dec 2009 22:37:16 +1100 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: References: <4B2AD4A0.6080908@firstpr.com.au> Message-ID: <4B2E0C6C.4020800@firstpr.com.au> Hi Danny, I found these presentations interesting: http://www.ietf.org/proceedings/74/slides/grow-6.pdf http://www.tcb.net/rr-thing.pdf concerning problems with iBGP in large ISPs. You wrote: > I find it interesting that folks in RRG are worrying most about > the number of unique *prefixes* in the DFZ, while the number of > unique *routes* (prefix/path attributes) is growing steeper. I understand "unique route" means a best path received from a neighbouring router. Each router chooses one of these to be the best path it uses for its FIB, and which it offers to its neighbours, according to local policy and various algorithms. > Further, most all the work in the IETF BGP-related working groups > aims to ADD more routes in order to support multi-path, alleviate > route oscillation, provide faster convergence, obtain more operations > visibility, etc.., pretty much completely in odds with the RRG work, > and exacerbating the issues of scalability and instability, path > hunting, RIB issues, RAM, CPU, FIB I/O, etc.. I don't know much about how changes to BGP will cause more work for routers, but I can easily imagine this being the case. > Perhaps the disparity between the IETF work and the IRTF RRG work > is that the operators are busy running networks and dealing with > real operational issues, while the RRG folks are solving problems > that won't been an issue for a decade or more.. This seems eerily > similar to the IPv6 conundrum as of late, eh? Maybe so. However, as long as the RRG work does result in a reduction in the number of DFZ routes, below what would have happened without this work, then this will be worthwhile. Maybe it will be another 10 years or more before it happens - but it will still be well worthwhile, I think. I think that the proposals which could possibly be voluntarily adopted on a wide enough scale to solve the routing scaling problem: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ are core-edge elimination schemes. LISP-ALT and Ivip so far have been submitted for the final RRG process. I assume APT and TRRP will be submitted too. All these are intended to provide a much greater number of end-user networks having their own scalable PI space (my term) in a way that each such prefix doesn't need to be in the DFZ. Since the growth in "unique routes" you refer to is due to a growing multiplier effect on the number of DFZ routes, one of these schemes being successfully and widely adopted should offer a big relief. The other proposals, I think, are core-edge elimination schemes. I can't see how these could be voluntarily adopted, since they require major host changes (stack and apps). They too would provide scalable multihoming, portability etc. without burdening the DFZ with a prefix for each such end-user network. - Robin From jmaimon at chl.com Sun Dec 20 10:14:43 2009 From: jmaimon at chl.com (Joe Maimon) Date: Sun, 20 Dec 2009 10:14:43 -0500 Subject: [arin-ppml] Modified Header Forwarding for scalable routing In-Reply-To: <4B2E08C4.7020004@firstpr.com.au> References: <4B2AD4A0.6080908@firstpr.com.au> <20091218020045.GA24163@ussenterprise.ufp.org> <4B2B4976.2070302@firstpr.com.au> <20091218155153.GA78343@ussenterprise.ufp.org> <4B2C68D8.7020006@firstpr.com.au> <20091219061711.GB34678@ussenterprise.ufp.org> <4B2C8202.1050204@firstpr.com.au> <4B2E08C4.7020004@firstpr.com.au> Message-ID: <4B2E3F63.2010007@chl.com> Robin Whittle wrote: > Wow you sure packed a lot in there. I cant get past the motivation factor. Why would a user accept as PI a prefix that wont go into the DFZ and/or is for all intents and purposes a second class prefix were they to have the choice and what would otherwise deprive them of a choice and why would DFZ routers and network operators expend the effort required to even make that option realistic? Who is required to extend the effort or make the sacrifice in order for whom to properly benefit? If they are not the same people, I dont see any of this working, even as they may very well all be technically workable. Joe From michel at arneill-py.sacramento.ca.us Sun Dec 20 15:47:44 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 20 Dec 2009 12:47:44 -0800 Subject: [arin-ppml] Routing Research Group is about to decide itsscalable routing recommendation In-Reply-To: References: <4B2AD4A0.6080908@firstpr.com.au> Message-ID: <471D76419F9EF642962323D13DF1DF69011622@newserver.arneill-py.local> > Danny McPherson wrote: > Perhaps the disparity between the IETF work and the IRTF RRG > work is that the operators are busy running networks and > dealing with real operational issues, while the RRG folks > are solving problems that won't been an issue for a decade > or more.. This seems eerily similar to the IPv6 conundrum > as of late, eh? :-) > Joe Maimon wrote: > Why would a user accept as PI a prefix that wont go into > the DFZ and/or is for all intents and purposes a second > class prefix were they to have the choice and what would > otherwise deprive them of a choice and why would DFZ > routers and network operators expend the effort required to > even make that option realistic? > Who is required to extend the effort or make the sacrifice > in order for whom to properly benefit? If they are not the > same people, I dont see any of this working, even as they > may very well all be technically workable. I came to the same conclusions years ago when I pulled the plug on my own thing. There is no market for a second class complicated multihoming solution. Michel. From jmaimon at chl.com Sun Dec 20 20:36:11 2009 From: jmaimon at chl.com (Joe Maimon) Date: Sun, 20 Dec 2009 20:36:11 -0500 Subject: [arin-ppml] Routing Research Group is about to decide itsscalable routing recommendation In-Reply-To: <471D76419F9EF642962323D13DF1DF69011622@newserver.arneill-py.local> References: <4B2AD4A0.6080908@firstpr.com.au> <471D76419F9EF642962323D13DF1DF69011622@newserver.arneill-py.local> Message-ID: <4B2ED10B.4040704@chl.com> Michel Py wrote: > >> Joe Maimon wrote: >> Why would a user accept as PI a prefix that wont go into >> the DFZ and/or is for all intents and purposes a second >> class prefix were they to have the choice and what would >> otherwise deprive them of a choice and why would DFZ >> routers and network operators expend the effort required to >> even make that option realistic? >> Who is required to extend the effort or make the sacrifice >> in order for whom to properly benefit? If they are not the >> same people, I dont see any of this working, even as they >> may very well all be technically workable. > > I came to the same conclusions years ago when I pulled the plug on my > own thing. There is no market for a second class complicated multihoming > solution. > > Michel. > Michel, Thank you for the feedback. To be clear, I dont [want to] have any of my own conclusions, only the curiosity of the likely ill-informed as to the thoughts of those involved in the problem space in this aspect. Even as the tech appears shiny and usable, I am unclear on how it will actually eliminate the PI v. DFZ debate that crops up here and there now and again. Track record of technology to date seems to show that pervasive or even widespread implementation can be a difficult goal without clear and present self-interest to each individual actor in a targeted population. It really would be nice have our cake and eat it too and I was hoping that a navigable path to there can be shown to exist. Joe From farmer at umn.edu Tue Dec 22 12:24:20 2009 From: farmer at umn.edu (David Farmer) Date: Tue, 22 Dec 2009 11:24:20 -0600 Subject: [arin-ppml] efficient utilization != needs basis Message-ID: <4B3100C4.2040901@umn.edu> I had an epiphany the other day, I believe we are frequently equating "efficient utilization" with "operational need" and "needs basis" in our policy discussions. In todays world of IPv4 that is understandable, and mostly true in IPv4 policy. I've seen numbers claiming there are 5 billion devices connected to the Internet today. So it is obvious that with only 4 billion addresses in IPv4, "operational need" has a strong correlation with "efficient utilization" for IPv4. However, back in the day of class based IPv4 "operational need" and "efficient utilization" were not strongly correlated, other issues like DFZ size were far bigger issues. But there has always been a "needs basis" for assignments. In IPv6 "efficient utilization", at least on an address by address basis, wasn't even a design consideration, in fact one reason for 128 bits was to make this a non-issue for a long time. Since it is not even a design consideration it is not a necessary as a primary attribute for IPv6 number resource policy. So everyone needs to disassociate "efficient utilization" from there definition of "needs basis" at least as related to IPv6. But I believe there still should be a "needs basis" for address allocation in IPv6 it will just be defined in a completely different way. Note that HD-Ratio is by definition a measure of address assignment efficiency, not necessarily a measure of need in a IPv6 world where "operational need" and "efficient utilization" have little or no correlation. With all that said I think we need to figure out what a "needs basis" really means for IPv6. For devices connected to the Internet, AKA the Web, or public broadband service, in a IPv6 world the primary challenge I see is DFZ growth. I believe IPv6 addresses intended for this purpose for the immediate future will need to be based on a hierarchical routing, with mostly provider aggregated addressing, and limited provider independent end-user addressing, probably based on multi-homing requirements. However, there are other IP technologies coming that may or may not be connected to the Internet and will possibly form other internets. These internets will probably have other challenges and possibly form other address hierarchies independent of the Internet as we know it today. But, they will almost assuredly need globally unique addresses too. Some examples are; Smart Grids, emergency response networks, and one that has been functioning from more that a decade is the Automotive Network Exchange (ANX). Why do these need globally unique addressing? As was discussed on PPML already, Smart Grids have a enormous number of potential devices that will have addressing needs, just by that sheer size globally unique addresses are the only really practical solution. Emergency response networks will need globally unique addressing, because the consequences of address conflicts will likely be measured in lives lost. Globally unique addresses really make thing like the ANX much easier, and there are many other private inter-AS networks that exist today and I only see more and more in the future. These all have different challenges and I bring them up in this context because they all also have "operational need" and as we to define a "needs basis" for IPv6, we must find a definition that encompasses the "operational needs" of these other internets too. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From schnizlein at isoc.org Tue Dec 22 13:06:19 2009 From: schnizlein at isoc.org (John Schnizlein) Date: Tue, 22 Dec 2009 13:06:19 -0500 Subject: [arin-ppml] efficient utilization != needs basis In-Reply-To: <4B3100C4.2040901@umn.edu> References: <4B3100C4.2040901@umn.edu> Message-ID: <70BDA4DB-CD7C-498C-85C6-AAD7EDF0091A@isoc.org> Absolutely correct! \ On 2009Dec22, at 12:24 PM, David Farmer wrote: > Note that HD-Ratio is by definition a measure of address assignment > efficiency, not necessarily a measure of need in a IPv6 world where > "operational need" and "efficient utilization" have little or no > correlation. From mcr at sandelman.ca Tue Dec 22 14:23:28 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 22 Dec 2009 14:23:28 -0500 Subject: [arin-ppml] efficient utilization != needs basis In-Reply-To: <4B3100C4.2040901@umn.edu> References: <4B3100C4.2040901@umn.edu> Message-ID: <25792.1261509808@marajade.sandelman.ca> Thank for a great email. >>>>> "David" == David Farmer writes: David> However, there are other IP technologies coming that may or David> may not be connected to the Internet and will possibly form David> other internets. These internets will probably have other David> challenges and possibly form other address hierarchies David> independent of the Internet as we know it today. But, they David> will almost assuredly need globally unique addresses too. +1 (And ULA does not cut it for me) Proposal 103 gives out globally unique (but not routable) /48s to anyone that asks, and that is enough to get these other networks off the ground to the point where one can understand just how much space you really do need. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From info at arin.net Tue Dec 22 14:30:26 2009 From: info at arin.net (Member Services) Date: Tue, 22 Dec 2009 14:30:26 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - December 2009 Message-ID: <4B311E52.8050508@arin.net> In accordance with the ARIN Policy Development Process the ARIN Advisory Council (AC) held a meeting on 17 December 2009 and made decisions about several draft policies and proposals. The AC recommended the following draft policy to the ARIN Board of Trustees for adoption: Draft Policy 2009-8: Equitable IPv4 Run-Out The AC reviewed the following two proposals and accepted them onto the AC's docket for development and evaluation: 101. Multihomed initial allocation criteria 102. Reduce and Simplify IPv4 Initial Allocations The AC abandoned the following two proposals: 103. Change IPv6 Allocation Process 104. Multiple Discrete Networks for proposal 103 The AC stated, "The ARIN Advisory Council determined to abandon Policy Proposal #103: Change IPv6 Allocation Process. While the AC perceives there is significant support for major revisions to IPv6 policy, the AC could not support this proposal in its current form. The majority of the AC felt the only way they could move this proposal forward would have been to modify it in ways not perceived as compatible with the author?s original intent. The AC would like to work with the author and the rest of community to develop future IPv6 policy proposals. Additionally, the AC abandoned Policy Proposal #104: Multiple Discrete Networks for proposal 103, as it is dependent on Policy Proposal #103 and is not useful on its own." The abandonment of proposals 103 and 104 by the AC is a decision that can be petitioned by any member of the community, including a proposal originator. The deadline to begin a petition is 23:59 EST on 31 December 2009. For more information on starting and participating in petitions, see PDP Petitions (Discussion Petition) at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Dec 22 14:30:43 2009 From: info at arin.net (Member Services) Date: Tue, 22 Dec 2009 14:30:43 -0500 Subject: [arin-ppml] Policy Proposal 105: Simplified M&A transfer policy Message-ID: <4B311E63.9040103@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 105: Simplified M&A transfer policy Proposal Originator: Scott Leibrand Proposal Version: 1.0 Date: 22 December 2009 Proposal type: new Policy term: permanent Policy statement: Replace section 8.2 with: 8.2. Mergers and Acquisitions ARIN will consider requests for the transfer of number resources in the case of properly documented mergers and acquisitions. ARIN will maintain an up-to-date list of acceptable types of documentation. In the event that number resources of the acquired/merged organization(s) are no longer efficiently utilized at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or aggregate resources as appropriate via the processes outlined in sections 4.6, 4.7, or 12 of the NRPM. Add "In addition to transfers under section 8.2, " at the beginning of section 8.3. Transfers to Specified Recipients. Rationale: This policy proposal: attempts to simplify the M&A transfer section of the NRPM; eliminates the ambiguity discussed at the ARIN Public Policy Meeting (PPM) in Dearborn by clarifying that transfers can occur under either 8.2 or 8.3 independently; and attempts to address the concerns raised in the staff policy implementation report at the Dearborn PPM. The idea here is to simply say that ARIN will allow M&A transfers, and to require the return of any address space that is not efficiently utilized after the acquisition. Preferably that would happen voluntarily under the policies of NRPM 4.6 (Amnesty), but it also leaves the door open for ARIN to revoke space under NRPM 12 (Resource Review) if necessary. This also should dramatically increase the completion rate for transfer requests, as the evaluation of whether space is efficiently utilized after the transfer can occur in parallel, completely independently of the transfer request, and can continue even if the transfer request is abandoned. The bulleted lists of acceptable documentation removed from the NRPM should be maintained by ARIN elsewhere on the website, such as at https://www.arin.net/resources/request/transfers.html Timetable for implementation: Immediate From mpetach at netflight.com Tue Dec 22 15:18:54 2009 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 22 Dec 2009 12:18:54 -0800 Subject: [arin-ppml] Does Moore's law help with routing table growth? In-Reply-To: <4B2C65E1.3090705@gmail.com> References: <4B2C5DDD.7050501@gmail.com> <471D76419F9EF642962323D13DF1DF69011612@newserver.arneill-py.local> <4B2C65E1.3090705@gmail.com> Message-ID: <63ac96a50912221218o7c83feddu403c1179b8eda63c@mail.gmail.com> On Fri, Dec 18, 2009 at 9:34 PM, Scott Leibrand wrote: > On 12/18/2009 9:19 PM, Michel Py wrote: >> >> I don't think we have much maneuvering room though; the benefits of >> Moore's law helping building faster routers are more or less offset by >> the same Moore's law helping building more bandwidth-hungry consumer >> devices. > > Except that the bandwidth of consumer devices is completely independent of > the number of routes we have to stuff into our FIB. ?That is dependent on > the number of independently multihomed networks, which is determined by > economic and business forces. Which seems to imply that one perfectly valid control point to limit the growth of the routing table is simply keep raising the price of registering an ASN to the point where few enough new business can afford to multihome; if we keep the number of new multihomed networks entering the global tables to a rate slightly slower than the development and deployment curve of hardware able to do lookups on those new multihomed networks, then we should be able to continue to scale the DFZ as long as necessary. Just give the hardware engineers a means to feed back into the RIRs if they run into a roadblock, so that the appropriate fees for an ASN can be raised to slow down the rate of new multihoming entrants until the technology is able to overcome the roadblock and continue progressing again. Thus, the concern of DFZ routing table slots moves firmly into the business realm, subject to economic forces, and out of the policy-making arena. >> ?In other words, growth of the DFZ table has to rely on router >> enhancements, not on riding Moore's law. >> > I believe that enhancements in router FIB capacity are to some degree > dependent on the same forces driving Moore's law. ?Obviously keeping Moore's > law going (whether in CPUs or in TCAMs) requires hard engineering work, but > that's not the point. ?The point of Moore's law is that all that hard work > results in a periodic doubling of capacity (in this case, FIB routes) for > the same price. ?For now, that improvement is keeping ahead of the growth > rate of networks seeking to multihome. We currently have a very loose economic feedback system in place; the hardware needed to effectively multihome via BGP4 is kept expensive because it's funding a rapid development cycle which is attempting to stay abreast of that curve. If we raise the costs to multihome, fewer networks will add to the DFZ routing table, and the pressure on growth and technology advancement decreases. We can raise the cost to multihome in 2 ways; one, through the hardware costs (today's model); the other is via the one other item required for multihoming--number resources (IP addresses and ASNs). ASNs are explicitly tied to multihoming, so those are an easy one to control; raise the price, and fewer new entrants show up to tie up slots in the DFZ RIB. Non-aggregatable IP addresses can also contribute, but they're a little harder to pin down; you may be using them internally, and not advertising them at all externally, so they don't burn a slot. And extending existing allocations should also not burn additional routing table slots, so pricing on extending existing allocations won't have the same effect, and doesn't need to share the same economic feedback loop. >> There is no such thing as "PI for everyone" in the foreseeable future. >> > If by "everyone" you mean "every organization with a single-homed network", > then I agree, that will be infeasible at least as long as we're running > BGP4. ?But as long as we move the bar gradually, I think we can safely move > toward a situation where PI addresses are generally available for multihomed > organizations who are willing to pay their providers enough to run BGP. I'm interested in digging deeper on the "as long as we move the bar gradually" concept. I'm thinking of economic feedback loops to help keep the bar moving gradually, based on pricing of new ASNs and new non-aggregatable IP address allocations, which would definitely play a hand in keeping that rate of change under control; but the one area it doesn't help control at all is the people who de-aggregate their existing space. Right now, we have no explicit registration requirement for prefix announcements, unlike with registering for new ASNs or new IP address blocks, so there's no means to provide pushback on the number of additional slots consumed when people deaggregate existing blocks. Would it help if we made route table advertisement registration via the registry's IRR mandatory, and charged each network for IRR services based on the number of route announcements they make--so, first announcement for the supernet/aggregate comes free with the number resource, but each additional more specific within the aggregate comes at increasing cost to register? First deaggregation costs $100/year additional, second one from the same supernet costs $200/year additional, etc. That way, even if you have 1,000 prefixes assigned by the RIR, if all you announce is the aggregates, there's no net additional cost; but if you have a single /20 from the registry, and deaggregate it down to /24s, it'll cost you $12,000 extra per year (for the 15 additional deaggregations you've added within the block). That would give us very strong economic feedback systems for ensuring that companies are well-motivated to not deaggregate unless it is for very good business reasons (ie, the additional revenue they bring in by deaggregating more than offsets the additional costs for registering the deaggregates.) That would also bring about the benefit that we could all build very clean explicit route filters based on the contents of the routing registry; if you haven't paid to register the route, people won't listen to it. I suppose it's easier to charge more for IP addresses and ASNs to limit growth than it is to charge for route registrations because up to now, there's been no charge for route registrations, and there'd be a huge hue and cry if we tried to start charging for them, probably even more of a fuss than was heard when ASNs and IP address registrations were first charged for. Still...I do think it's valuable to realize that fundamentally the concerns people have over routing table growth are largely economic ones, so it would make sense to put the feedback controls squarely into the economic realm, rather than trying to figure a way to jury-rig them in via the policy system. > -Scott Matt From mcr at sandelman.ca Tue Dec 22 15:57:51 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 22 Dec 2009 15:57:51 -0500 Subject: [arin-ppml] questions about AC decision re: 103. In-Reply-To: <4B311E52.8050508@arin.net> References: <4B311E52.8050508@arin.net> Message-ID: <591.1261515471@marajade.sandelman.ca> >>>>> "Member" == Member Services writes: Member> 103. Change IPv6 Allocation Process 104. Multiple Discrete Member> Networks for proposal 103 Member> The AC stated, "The ARIN Advisory Council determined to Member> abandon Policy Proposal #103: Change IPv6 Allocation Member> Process. While the AC perceives there is significant Member> support for major revisions to IPv6 policy, the AC could not Member> support this proposal in its current form. The majority of Member> the AC felt the only way they could move this proposal Member> forward would have been to modify it in ways not perceived Member> as compatible with the author's original intent. The AC Member> would like to work with the author and the rest of community Member> to develop future IPv6 policy proposals. Can we get a clear statement of: 1) what does the AC feel they need to do? 2) what does the AC feel the author's intent is? 3) is the "classful" nature of the proposal a sticking point? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From farmer at umn.edu Tue Dec 22 16:09:14 2009 From: farmer at umn.edu (David Farmer) Date: Tue, 22 Dec 2009 15:09:14 -0600 Subject: [arin-ppml] efficient utilization != needs basis In-Reply-To: <25792.1261509808@marajade.sandelman.ca> References: <4B3100C4.2040901@umn.edu> <25792.1261509808@marajade.sandelman.ca> Message-ID: <4B31357A.8090003@umn.edu> Michael Richardson wrote: > Thank for a great email. > >>>>>> "David" == David Farmer writes: > David> However, there are other IP technologies coming that may or > David> may not be connected to the Internet and will possibly form > David> other internets. These internets will probably have other > David> challenges and possibly form other address hierarchies > David> independent of the Internet as we know it today. But, they > David> will almost assuredly need globally unique addresses too. > > +1 > (And ULA does not cut it for me) I agree the current ULA is not a substitute for globally unique addresses that are stipulated as not intended to be part of the hierarchically routed global Internet, AKA the global route table, by being assigned by ARIN from a designated range for this purpose. Please note I am not saying they are not routable, they are most assuredly intended to be routed within an Autonomous System or even within a small set of Autonomous Systems. But, that they are not intended to be routed across the entire hierarchically routed global Internet. In other words, by default the normal expected behavior for a network operator is to not route these across an Autonomous System boundary without special arrangements. But because they have an intended scope that is meant to encompass multiple Autonomous Systems I believe that use of IPv6 Global Unicast addresses are appropriate. So, a question I have for you and something I'm not 100% decided on would ULA-Central or ULA-Global be an acceptable alternative? > Proposal 103 gives out globally unique (but not routable) /48s to anyone > that asks, and that is enough to get these other networks off the ground > to the point where one can understand just how much space you really do > need. While I agree this would be possible with PP#103, I believe it is possible to provide these addresses without such a massive change to IPv6 policy structure. I plan to draft a policy to accomplish just this, if it will get sufficient support that is another matter. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From mpetach at netflight.com Tue Dec 22 16:59:06 2009 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 22 Dec 2009 13:59:06 -0800 Subject: [arin-ppml] Modified Header Forwarding for scalable routing In-Reply-To: <4B2E08C4.7020004@firstpr.com.au> References: <4B2AD4A0.6080908@firstpr.com.au> <20091218020045.GA24163@ussenterprise.ufp.org> <4B2B4976.2070302@firstpr.com.au> <20091218155153.GA78343@ussenterprise.ufp.org> <4B2C68D8.7020006@firstpr.com.au> <20091219061711.GB34678@ussenterprise.ufp.org> <4B2C8202.1050204@firstpr.com.au> <4B2E08C4.7020004@firstpr.com.au> Message-ID: <63ac96a50912221359m1e2bbddaub3567789b5cbc2ab@mail.gmail.com> On Sun, Dec 20, 2009 at 3:21 AM, Robin Whittle wrote: > Short version: ? ?Owen DeLong suggested a scalable routing solution > ? ? ? ? ? ? ? ? ?would be to have DFZ routers modified to handle > ? ? ? ? ? ? ? ? ?packets with modified header structure. ?As I > ? ? ? ? ? ? ? ? ?understand it, the new packet format would contain > ? ? ? ? ? ? ? ? ?the ASN of the destination ISP and the DFZ routers > ? ? ? ? ? ? ? ? ?forward it on this basis, without looking at the > ? ? ? ? ? ? ? ? ?destination address, which would remain unaltered. This isn't sounding that far off from just running MPLS in the DFZ core, and passing labels around, with a set of label values representing the peering edge routers of other ASNs. Just seems like if we already have a code base for passing packets along based on a single tag value instead of doing address parsing and lookups, with routing of the internal packet being handled at the far end like normal after popping off the intervening tag, we might consider leveraging an encapsulation format that's been widely deployed and operated for the past decade. Then the challenges become around how best to propagate label assignment data between ISPs; the encapsulation and decapsulation code is already well baked in PE devices the world over. I suppose the 20 bit MPLS label limit will bite us in a decade or so, when there's enough ISP edge routers to exhaust the 20 bit label space, but it's sufficiently larger than the current number of ASNs and ISP edge routers in the DFZ to work for quite a while. This probably would be a better discussion on NANOG or some other more routing-operations focused list, rather than a numbers resource policy list, though. ^_^; Matt From owen at delong.com Tue Dec 22 17:17:38 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Dec 2009 14:17:38 -0800 Subject: [arin-ppml] Policy Proposal 105: Simplified M&A transfer policy In-Reply-To: <4B311E63.9040103@arin.net> References: <4B311E63.9040103@arin.net> Message-ID: <73DCA149-36EB-49F8-B6BF-06FCA1EEDADE@delong.com> > > 8.2. Mergers and Acquisitions > > ARIN will consider requests for the transfer of number resources in the > case of properly documented mergers and acquisitions. ARIN will > maintain an up-to-date list of acceptable types of documentation. > Perhaps ...ARIN staff will... > In the event that number resources of the acquired/merged > organization(s) are no longer efficiently utilized at the time ARIN > becomes aware of the transaction, through a transfer request or > otherwise, ARIN will work with the resource holder(s) to return or > aggregate resources as appropriate via the processes outlined in > sections 4.6, 4.7, or 12 of the NRPM. > I think that there's an issue here. I think that we need to talk about the number resources of the resultant combined organization rather than of the acquired/merged organization... Here's why... The term acquired/merged could be construed to refer only to the resources that were acquired without regard for the resources already held by the acquiring organization. Let's say that two organizations A and B merge. Prior to merger, A efficiently used 17 /24s and held a /19, while B efficiently used a /23 and held a /22. The combined usage is 19 /24s which would justify a /19, but, would not justify the /22 of additional space. The /22 should be returned in this case and be renumbered into the /19. > Add "In addition to transfers under section 8.2, " at the beginning of > section 8.3. Transfers to Specified Recipients. > Otherwise, looks good to me. Owen > Rationale: > > This policy proposal: attempts to simplify the M&A transfer section of > the NRPM; eliminates the ambiguity discussed at the ARIN Public Policy > Meeting (PPM) in Dearborn by clarifying that transfers can occur under > either 8.2 or 8.3 independently; and attempts to address the concerns > raised in the staff policy implementation report at the Dearborn PPM. > > The idea here is to simply say that ARIN will allow M&A transfers, and > to require the return of any address space that is not efficiently > utilized after the acquisition. Preferably that would happen > voluntarily under the policies of NRPM 4.6 (Amnesty), but it also leaves > the door open for ARIN to revoke space under NRPM 12 (Resource Review) > if necessary. This also should dramatically increase the completion > rate for transfer requests, as the evaluation of whether space is > efficiently utilized after the transfer can occur in parallel, > completely independently of the transfer request, and can continue even > if the transfer request is abandoned. > > The bulleted lists of acceptable documentation removed from the NRPM > should be maintained by ARIN elsewhere on the website, such as at > https://www.arin.net/resources/request/transfers.html > > Timetable for implementation: Immediate > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Dec 22 17:42:11 2009 From: bill at herrin.us (William Herrin) Date: Tue, 22 Dec 2009 17:42:11 -0500 Subject: [arin-ppml] efficient utilization != needs basis In-Reply-To: <4B3100C4.2040901@umn.edu> References: <4B3100C4.2040901@umn.edu> Message-ID: <3c3e3fca0912221442v4f59d2e6n3ed34754e9a25803@mail.gmail.com> On Tue, Dec 22, 2009 at 12:24 PM, David Farmer wrote: > With all that said I think we need to figure out what a "needs basis" really > means for IPv6. Hi David, Some comments: 1. I'm not conveinced it's possible to define a "needs basis" that doesn't have the practical effect of making ARIN the gatekeeper to Internet routing policy. I haven't thought of one and the attempts I've seen others make have fallen short. Making the RIRs the gatekeepers to Internet routing policy is not necessarily a bad thing, but we should keep eyes wide open. 2. Technologically, the only thing that absolutely requires an address block distinct from your service provider's is multihoming. The natural question which follows from that observation is: who is deserving enough to be permitted multihoming? 3. The cost of renumbering remains substantial. A needs basis should weigh the cost of renumbering divided by the typical number of years between changing ISPs versus the annual cost of maintaining a route or routes in the DFZ table. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scottleibrand at gmail.com Tue Dec 22 17:49:34 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 22 Dec 2009 14:49:34 -0800 Subject: [arin-ppml] Policy Proposal 105: Simplified M&A transfer policy In-Reply-To: <73DCA149-36EB-49F8-B6BF-06FCA1EEDADE@delong.com> References: <4B311E63.9040103@arin.net> <73DCA149-36EB-49F8-B6BF-06FCA1EEDADE@delong.com> Message-ID: <4B314CFE.3010908@gmail.com> On 12/22/2009 2:17 PM, Owen DeLong wrote: >> >> 8.2. Mergers and Acquisitions >> >> ARIN will consider requests for the transfer of number resources in the >> case of properly documented mergers and acquisitions. ARIN will >> maintain an up-to-date list of acceptable types of documentation. >> > Perhaps ...ARIN staff will... IMO just "ARIN" is better than "ARIN staff". We don't want to dictate how ARIN does it. If ARIN decides that the best way to maintain an up-to-date list of acceptable types of documentation is to pay a contractor to do it, that's fine. It doesn't have to be staff's job, it just has to be done. >> In the event that number resources of the acquired/merged >> organization(s) are no longer efficiently utilized at the time ARIN >> becomes aware of the transaction, through a transfer request or >> otherwise, ARIN will work with the resource holder(s) to return or >> aggregate resources as appropriate via the processes outlined in >> sections 4.6, 4.7, or 12 of the NRPM. >> > I think that there's an issue here. I think that we need to talk about > the number resources of the resultant combined organization rather > than of the acquired/merged organization... Here's why... > > The term acquired/merged could be construed to refer only to the > resources that were acquired without regard for the resources already > held by the acquiring organization. Let's say that two organizations > A and B merge. Prior to merger, A efficiently used 17 /24s and held > a /19, while B efficiently used a /23 and held a /22. The combined > usage is 19 /24s which would justify a /19, but, would not justify the > /22 of additional space. The /22 should be returned in this case and > be renumbered into the /19. Fair enough. Should I just change it to read "In the event that number resources of the combined organizations are no longer efficiently utilized..."? Thanks, Scott > >> Add "In addition to transfers under section 8.2, " at the beginning of >> section 8.3. Transfers to Specified Recipients. >> > Otherwise, looks good to me. > > Owen > > >> Rationale: >> >> This policy proposal: attempts to simplify the M&A transfer section of >> the NRPM; eliminates the ambiguity discussed at the ARIN Public Policy >> Meeting (PPM) in Dearborn by clarifying that transfers can occur under >> either 8.2 or 8.3 independently; and attempts to address the concerns >> raised in the staff policy implementation report at the Dearborn PPM. >> >> The idea here is to simply say that ARIN will allow M&A transfers, and >> to require the return of any address space that is not efficiently >> utilized after the acquisition. Preferably that would happen >> voluntarily under the policies of NRPM 4.6 (Amnesty), but it also leaves >> the door open for ARIN to revoke space under NRPM 12 (Resource Review) >> if necessary. This also should dramatically increase the completion >> rate for transfer requests, as the evaluation of whether space is >> efficiently utilized after the transfer can occur in parallel, >> completely independently of the transfer request, and can continue even >> if the transfer request is abandoned. >> >> The bulleted lists of acceptable documentation removed from the NRPM >> should be maintained by ARIN elsewhere on the website, such as at >> https://www.arin.net/resources/request/transfers.html >> >> Timetable for implementation: Immediate >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Tue Dec 22 17:53:58 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 22 Dec 2009 14:53:58 -0800 Subject: [arin-ppml] Policy Proposal 105: Simplified M&A transfer policy In-Reply-To: <4B314CFE.3010908@gmail.com> References: <4B311E63.9040103@arin.net> <73DCA149-36EB-49F8-B6BF-06FCA1EEDADE@delong.com> <4B314CFE.3010908@gmail.com> Message-ID: <4B314E06.4090901@gmail.com> On 12/22/2009 2:49 PM, Scott Leibrand wrote: > Should I just change it to read "In the event that number resources of > the combined > organizations are no longer efficiently utilized..."? Or, to David Farmer's point, do I need to use a different phrase instead of "efficiently utilized"? Perhaps just "justified" would work? -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmaimon at chl.com Tue Dec 22 18:00:18 2009 From: jmaimon at chl.com (Joe Maimon) Date: Tue, 22 Dec 2009 18:00:18 -0500 Subject: [arin-ppml] Policy Proposal 105: Simplified M&A transfer policy In-Reply-To: <73DCA149-36EB-49F8-B6BF-06FCA1EEDADE@delong.com> References: <4B311E63.9040103@arin.net> <73DCA149-36EB-49F8-B6BF-06FCA1EEDADE@delong.com> Message-ID: <4B314F82.9070002@chl.com> Owen DeLong wrote: > > >> In the event that number resources of the acquired/merged >> organization(s) are no longer efficiently utilized at the time ARIN >> becomes aware of the transaction, through a transfer request or >> otherwise, ARIN will work with the resource holder(s) to return or >> aggregate resources as appropriate via the processes outlined in >> sections 4.6, 4.7, or 12 of the NRPM. >> > I think that there's an issue here. I think that we need to talk about > the number resources of the resultant combined organization rather > than of the acquired/merged organization... Here's why... > > The term acquired/merged could be construed to refer only to the > resources that were acquired without regard for the resources already > held by the acquiring organization. Let's say that two organizations > A and B merge. Prior to merger, A efficiently used 17 /24s and held > a /19, while B efficiently used a /23 and held a /22. The combined > usage is 19 /24s which would justify a /19, but, would not justify the > /22 of additional space. The /22 should be returned in this case and > be renumbered into the /19. > I think that bringing the possibility of renumbering and reclamation is somewhat of a disincentive to getting people into the door in the first place. If you are buying a network that you may have to renumber, you might want to think twice about it - or wait until you finish renumbering it before going to 8.3. What is the priority for the goals of 8.2 and how much efficiency should we let slide to achieve them? These changes could make 8.3 more attractive than 8.2 Joe From jmaimon at chl.com Tue Dec 22 18:13:45 2009 From: jmaimon at chl.com (Joe Maimon) Date: Tue, 22 Dec 2009 18:13:45 -0500 Subject: [arin-ppml] efficient utilization != needs basis In-Reply-To: <3c3e3fca0912221442v4f59d2e6n3ed34754e9a25803@mail.gmail.com> References: <4B3100C4.2040901@umn.edu> <3c3e3fca0912221442v4f59d2e6n3ed34754e9a25803@mail.gmail.com> Message-ID: <4B3152A9.5030309@chl.com> William Herrin wrote: > 2. Technologically, the only thing that absolutely requires an address > block distinct from your service provider's is multihoming. Lets just call it what it is. A truly autonomous system. > The > natural question which follows from that observation is: who is > deserving enough to be permitted multihoming? Anyone who thinks it is worth their dollars and efforts. Or do you mean in the future, when those might not (be perceived to) be high enough to keep the multitudes out? > > > 3. The cost of renumbering remains substantial. A needs basis should > weigh the cost of renumbering divided by the typical number of years > between changing ISPs versus the annual cost of maintaining a route or > routes in the DFZ table. The biggest problem with this equation is that it is weighing my cost versus everyone's else. And the cost to everyone else for my single prefix addition is negligible. It needs to occur dozens of thousands of times annually to actually cost anybody anything at which point it costs a lot. Since I cant stop the other prefix additions, there is no reason nor benefit for me to stop adding my prefix either. I dont stop driving my car either. > > > Regards, > Bill Herrin > > Joe From owen at delong.com Tue Dec 22 18:22:47 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Dec 2009 15:22:47 -0800 Subject: [arin-ppml] Policy Proposal 105: Simplified M&A transfer policy In-Reply-To: <4B314F82.9070002@chl.com> References: <4B311E63.9040103@arin.net> <73DCA149-36EB-49F8-B6BF-06FCA1EEDADE@delong.com> <4B314F82.9070002@chl.com> Message-ID: On Dec 22, 2009, at 3:00 PM, Joe Maimon wrote: > > > Owen DeLong wrote: >> >> >>> In the event that number resources of the acquired/merged >>> organization(s) are no longer efficiently utilized at the time ARIN >>> becomes aware of the transaction, through a transfer request or >>> otherwise, ARIN will work with the resource holder(s) to return or >>> aggregate resources as appropriate via the processes outlined in >>> sections 4.6, 4.7, or 12 of the NRPM. >>> >> I think that there's an issue here. I think that we need to talk about >> the number resources of the resultant combined organization rather >> than of the acquired/merged organization... Here's why... >> >> The term acquired/merged could be construed to refer only to the >> resources that were acquired without regard for the resources already >> held by the acquiring organization. Let's say that two organizations >> A and B merge. Prior to merger, A efficiently used 17 /24s and held >> a /19, while B efficiently used a /23 and held a /22. The combined >> usage is 19 /24s which would justify a /19, but, would not justify the >> /22 of additional space. The /22 should be returned in this case and >> be renumbered into the /19. >> > > > I think that bringing the possibility of renumbering and reclamation is somewhat of a disincentive to getting people into the door in the first place. If you are buying a network that you may have to renumber, you might want to think twice about it - or wait until you finish renumbering it before going to 8.3. > I don't see the connection, necessarily. > What is the priority for the goals of 8.2 and how much efficiency should we let slide to achieve them? > Primarily to make it clear that number resources are not transferable away from their original intended purpose without justified need under ARIN policy. 8.3 is not particularly useful for the merger/acquisition of company scenario. > These changes could make 8.3 more attractive than 8.2 > As a point of information, I am proposing changes to a proposal to bring its effect closer to existing policy, not changes to the implementation of existing policy. Since this proposal is billed as a "simplified" M&A transfer policy and intended, as I understand it to provide a clearer wording for essentially current policy effect, I think that is desirable. I do not think that relaxing efficiency requirements is desirable for 8.2. Further, 8.3 is not a substitute for 8.2, since, 8.3 would require the acquiring organization to completely justify their need for all the space coming from the organization to be acquired without using the network assets/utilization of the organization being acquired. Both policies preserve the same requirement that you adhere to ARIN needs-based policy to effectuate a legitimate transfer. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue Dec 22 18:27:15 2009 From: farmer at umn.edu (David Farmer) Date: Tue, 22 Dec 2009 17:27:15 -0600 Subject: [arin-ppml] questions about AC decision re: 103. In-Reply-To: <591.1261515471@marajade.sandelman.ca> References: <4B311E52.8050508@arin.net> <591.1261515471@marajade.sandelman.ca> Message-ID: <4B3155D3.40009@umn.edu> Michael Richardson wrote: >>>>>> "Member" == Member Services writes: > Member> 103. Change IPv6 Allocation Process 104. Multiple Discrete > Member> Networks for proposal 103 > > Member> The AC stated, "The ARIN Advisory Council determined to > Member> abandon Policy Proposal #103: Change IPv6 Allocation > Member> Process. While the AC perceives there is significant > Member> support for major revisions to IPv6 policy, the AC could not > Member> support this proposal in its current form. The majority of > Member> the AC felt the only way they could move this proposal > Member> forward would have been to modify it in ways not perceived > Member> as compatible with the author's original intent. The AC > Member> would like to work with the author and the rest of community > Member> to develop future IPv6 policy proposals. > > Can we get a clear statement of: > 1) what does the AC feel they need to do? > 2) what does the AC feel the author's intent is? > 3) is the "classful" nature of the proposal a sticking point? > I am not speaking for the whole AC, and I'm not sure how clear this will all actually be either. As one of the shepherds for this proposal I attempted to distill a number of points that were being discussed, at least by some of the members of the AC. I refer you to my email of December 11th for that. http://lists.arin.net/pipermail/arin-ppml/2009-December/015819.html To that I will add, that while not directly part of the proposal, the fee structure example in the rational was also at least partially an issue discussed. I will reiterate, I believe the biggest issue was the lack of a "needs basis". I don't believe "efficient utilization" is necessarily a proper measure of "operational need" in IPv6. But, neither is how big of a check you can write a proper measure of "operational need". Personally, I'm OK with it being part of the equation, but there most be something more to it than just that. I don't believe the classful nature was that much of an issue, at least for me personally. The current IPv6 policy is rather classful already, at least from my point of view, /32s and /48s seem a lot like Class As and Bs to me. But, I must say I wasn't comfortable with /24s being handed out as loosely as was being proposed. It just doesn't seem right, my best example is how some people feel today about some of the original Class A or /8 allocations, to major corporations. What are the options from here; 1. Bill or someone else could appeal the AC decision, see the original email for the details. 2. We can discuss changing Bill's proposal and then resubmit it. As one of the AC shepherds for this proposal, I believe it is my role to help facilitate this option, if there is interest in this at least in the near term. Or; 3. We could drop this discussion and look at other ideas. Independent of those options and more broadly where do I think we go from here? Shorter-term (for the Toronto PPM) I believe we need proposals to; 1. Rewrite 6.5.1.1; to better specify qualifications to be an ISP or LIR and get a /32. A lot of people don't like the 200 end-site definition that is there today. This discussion started back in Dearborn and PP#101 is one option for this. 2. Rewrite 6.5.8.1; Currently end-user policy for IPv6 depends on IPv4 policy. 3. Either as part of #2 or separately, I want to propose a separate IPv6 pool for assignments that are not intended to be part of the hierarchically routed global Internet. Longer-term (beyond the Toronto PPM, maybe with an open discussion at the Toronto PPM)), I believe we must to figure out what "operation need" and "needs basis" really means for IPv6 and maybe revisit HD-Ratios and really rethink IPv6 policy altogether. But, I'm not sure any of these are will be ready for policy for a little while. I would hope other AC members will express their opinions too. But, also the minutes for the AC meetings do get posted at the following link, usually a few weeks after the meeting. But given the holidays, I expect it will be a little longer for this one. So, next month sometime look for the minutes of the December 17th Advisory Council meeting. The minutes for the AC meetings up to, but not including, the one last week have been posted; https://www.arin.net/about_us/ac/index.html -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From scottleibrand at gmail.com Tue Dec 22 18:41:57 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 22 Dec 2009 15:41:57 -0800 Subject: [arin-ppml] Policy Proposal 105: Simplified M&A transfer policy In-Reply-To: <4B314F82.9070002@chl.com> References: <4B311E63.9040103@arin.net> <73DCA149-36EB-49F8-B6BF-06FCA1EEDADE@delong.com> <4B314F82.9070002@chl.com> Message-ID: <4B315945.6060804@gmail.com> On 12/22/2009 3:00 PM, Joe Maimon wrote: > > > Owen DeLong wrote: >> >> >>> In the event that number resources of the acquired/merged >>> organization(s) are no longer efficiently utilized at the time ARIN >>> becomes aware of the transaction, through a transfer request or >>> otherwise, ARIN will work with the resource holder(s) to return or >>> aggregate resources as appropriate via the processes outlined in >>> sections 4.6, 4.7, or 12 of the NRPM. >>> >> I think that there's an issue here. I think that we need to talk about >> the number resources of the resultant combined organization rather >> than of the acquired/merged organization... Here's why... >> >> The term acquired/merged could be construed to refer only to the >> resources that were acquired without regard for the resources already >> held by the acquiring organization. Let's say that two organizations >> A and B merge. Prior to merger, A efficiently used 17 /24s and held >> a /19, while B efficiently used a /23 and held a /22. The combined >> usage is 19 /24s which would justify a /19, but, would not justify the >> /22 of additional space. The /22 should be returned in this case and >> be renumbered into the /19. >> > > > I think that bringing the possibility of renumbering and reclamation > is somewhat of a disincentive to getting people into the door in the > first place. If you are buying a network that you may have to > renumber, you might want to think twice about it - or wait until you > finish renumbering it before going to 8.3. > > What is the priority for the goals of 8.2 and how much efficiency > should we let slide to achieve them? > > These changes could make 8.3 more attractive than 8.2 8.3. is already significantly more attractive than 8.2 in many cases for simply transferring IPv4 resources, but 8.3 doesn't apply to IPv6 or ASN resources. The current NRPM's 8.2 (https://www.arin.net/policy/nrpm.html#eight2) is much more complex, and basically requires "that the assets being transferred (e.g. customers or equipment) must have been using the resources at the time of the M&A" (https://www.arin.net/participate/meetings/reports/ARIN_XXIV/PDF/thursday/policy_exp_report.pdf, page 9). The new proposal simply says that, if you're not using the space and don't have a need for it in the near term (which I'd assume would mean 12 months, since that's how much space you can currently request), then you need to work with ARIN to return unused resources. As you can see from the policy_exp_report.pdf, that much more closely matches actual current practice, and ARIN staff's recommendation for revising the policy to match the actual needs of transfer applicants. I'm not sure I understand your point about renumbering. No one making an acquisition is forced by ARIN to renumber. If they wish to renumber and return space, then NRPM 4.6 allows them "an appropriate timeframe" of 6-18 months (with a possible extension of 6-12 months more), and NRPM 4.7 allows 12 months for renumbering to aggregate space. Do you feel that the proposal's simplified 8.2 language is in any way worse than the version it would replace? Do you have any suggestions for how to improve it? Thanks, Scott From scottleibrand at gmail.com Tue Dec 22 18:50:59 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 22 Dec 2009 15:50:59 -0800 Subject: [arin-ppml] Policy Proposal 105: Simplified M&A transfer policy In-Reply-To: <4B314CFE.3010908@gmail.com> References: <4B311E63.9040103@arin.net> <73DCA149-36EB-49F8-B6BF-06FCA1EEDADE@delong.com> <4B314CFE.3010908@gmail.com> Message-ID: <4B315B63.4090002@gmail.com> Based on feeback so far, here's the updated/revised version of proposal 105. Additional feedback welcome, particularly from folks who have recently done (or are in process of doing) an M&A transfer. Thanks, Scott Policy Proposal 105: Simplified M&A transfer policy Proposal Version: 1.1 Date: 22 December 2009 Policy statement: Replace section 8.2 with: 8.2. Mergers and Acquisitions ARIN will consider requests for the transfer of number resources in the case of properly documented mergers and acquisitions. ARIN will maintain an up-to-date list of acceptable types of documentation. In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or aggregate resources as appropriate via the processes outlined in sections 4.6, 4.7, or 12 of the NRPM. Add "In addition to transfers under section 8.2, " at the beginning of section 8.3. Transfers to Specified Recipients. Rationale: This policy proposal: attempts to simplify the M&A transfer section of the NRPM; eliminates the ambiguity discussed at the ARIN Public Policy Meeting (PPM) in Dearborn by clarifying that transfers can occur under either 8.2 or 8.3 independently; and attempts to address the concerns raised in the staff policy implementation report at the Dearborn PPM (https://www.arin.net/participate/meetings/reports/ARIN_XXIV/PDF/thursday/policy_exp_report.pdf) The idea here is to simply say that ARIN will allow M&A transfers, and to require the return of any number resources for which there is no longer a justified need after the acquisition. Preferably that would happen voluntarily under the policies of NRPM 4.6 (Amnesty), but it also leaves the door open for ARIN to revoke space under NRPM 12 (Resource Review) if necessary. By implication, future needs that would qualify the organization for an allocation/assignment would likewise justify keeping transferred space. In particular, see the language of NRPM section 12, paragraphs 4 and 4a. This policy also should dramatically increase the completion rate for transfer requests, as the evaluation of whether space is efficiently utilized after the transfer can occur in parallel, completely independently of the transfer request, and can continue even if the transfer request is abandoned. The bulleted lists of acceptable documentation removed from the NRPM should be maintained by ARIN elsewhere on the website, such as at https://www.arin.net/resources/request/transfers.html From terry.l.davis at boeing.com Tue Dec 22 18:53:33 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Tue, 22 Dec 2009 15:53:33 -0800 Subject: [arin-ppml] questions about AC decision re: 103. In-Reply-To: <4B3155D3.40009@umn.edu> References: <4B311E52.8050508@arin.net> <591.1261515471@marajade.sandelman.ca> <4B3155D3.40009@umn.edu> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF55127B090E@XCH-NW-05V.nw.nos.boeing.com> David I'll take a crack at this "needs issue" from a different angle. Since I'm in the edge of critical infrastructure numerous ways every, I guess I'd point out a few things in the way of re-addressing that we don't really think about: - When would be a good time for your local hospital to re-address its Emergency Room and ICU? - If a small biotec company has to re-address its control systems, when is a good time? An outage to their control systems, could destroy years of work. - The company supplying your local water? (not nearly all of them are public) - The local small power company providing your power? - The local industry that has highly specialized control systems to enable a highly robotic process with very high close tolerances on its products? What's the cost of failure? - The local irrigation district? (The ditch rider is now a SCADA system and every farm depends on it!) - What about my community bank; am I comfortable with the risk to my account access if they have to change? - What about my city government? It's intelligent (?) traffic control systems? Some still run their own 911 services. ?? - A small regional food distributor? (How time can they be out before their stocks spoil?) - The local company that provide fire and security monitoring to your business or home? - The local company that provides all the web sites for businesses in your community? Just visually walk down your community's main street and try to imagine what re-addressing might mean to any one of them! We make this crazy assumption that our business models function as they did before the Internet. They DON'T! We live in a 7x24 world now; our businesses, our livelihood, and our own personal safety depend on the Internet, 7x24 with at least 4 9's reliability. The PA concept is so broken in this context that I can find no way to defend it; I understand it at a technical level but that does not translate to the real world we live in. And we wonder why we cannot get IPv6 deployed? Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of David Farmer > Sent: Tuesday, December 22, 2009 3:27 PM > To: Michael Richardson > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] questions about AC decision re: 103. > > Michael Richardson wrote: > >>>>>> "Member" == Member Services writes: > > Member> 103. Change IPv6 Allocation Process 104. Multiple Discrete > > Member> Networks for proposal 103 > > > > Member> The AC stated, "The ARIN Advisory Council determined to > > Member> abandon Policy Proposal #103: Change IPv6 Allocation > > Member> Process. While the AC perceives there is significant > > Member> support for major revisions to IPv6 policy, the AC could not > > Member> support this proposal in its current form. The majority of > > Member> the AC felt the only way they could move this proposal > > Member> forward would have been to modify it in ways not perceived > > Member> as compatible with the author's original intent. The AC > > Member> would like to work with the author and the rest of community > > Member> to develop future IPv6 policy proposals. > > > > Can we get a clear statement of: > > 1) what does the AC feel they need to do? > > 2) what does the AC feel the author's intent is? > > 3) is the "classful" nature of the proposal a sticking point? > > > > I am not speaking for the whole AC, and I'm not sure how clear this will > all actually be either. As one of the shepherds for this proposal I > attempted to distill a number of points that were being discussed, at > least by some of the members of the AC. I refer you to my email of > December 11th for that. > > http://lists.arin.net/pipermail/arin-ppml/2009-December/015819.html > > To that I will add, that while not directly part of the proposal, the > fee structure example in the rational was also at least partially an > issue discussed. > > I will reiterate, I believe the biggest issue was the lack of a "needs > basis". I don't believe "efficient utilization" is necessarily a proper > measure of "operational need" in IPv6. But, neither is how big of a > check you can write a proper measure of "operational need". Personally, > I'm OK with it being part of the equation, but there most be something > more to it than just that. > > I don't believe the classful nature was that much of an issue, at least > for me personally. The current IPv6 policy is rather classful already, > at least from my point of view, /32s and /48s seem a lot like Class As > and Bs to me. But, I must say I wasn't comfortable with /24s being > handed out as loosely as was being proposed. It just doesn't seem > right, my best example is how some people feel today about some of the > original Class A or /8 allocations, to major corporations. > > What are the options from here; > > 1. Bill or someone else could appeal the AC decision, see the original > email for the details. > > 2. We can discuss changing Bill's proposal and then resubmit it. As one > of the AC shepherds for this proposal, I believe it is my role to help > facilitate this option, if there is interest in this at least in the > near term. Or; > > 3. We could drop this discussion and look at other ideas. > > Independent of those options and more broadly where do I think we go > from here? Shorter-term (for the Toronto PPM) I believe we need > proposals to; > > 1. Rewrite 6.5.1.1; to better specify qualifications to be an ISP or LIR > and get a /32. A lot of people don't like the 200 end-site definition > that is there today. This discussion started back in Dearborn and > PP#101 is one option for this. > > 2. Rewrite 6.5.8.1; Currently end-user policy for IPv6 depends on IPv4 > policy. > > 3. Either as part of #2 or separately, I want to propose a separate IPv6 > pool for assignments that are not intended to be part of the > hierarchically routed global Internet. > > Longer-term (beyond the Toronto PPM, maybe with an open discussion at > the Toronto PPM)), I believe we must to figure out what "operation need" > and "needs basis" really means for IPv6 and maybe revisit HD-Ratios and > really rethink IPv6 policy altogether. But, I'm not sure any of these > are will be ready for policy for a little while. > > I would hope other AC members will express their opinions too. > > But, also the minutes for the AC meetings do get posted at the following > link, usually a few weeks after the meeting. But given the holidays, I > expect it will be a little longer for this one. So, next month sometime > look for the minutes of the December 17th Advisory Council meeting. The > minutes for the AC meetings up to, but not including, the one last week > have been posted; > > https://www.arin.net/about_us/ac/index.html > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bill at herrin.us Tue Dec 22 19:08:49 2009 From: bill at herrin.us (William Herrin) Date: Tue, 22 Dec 2009 19:08:49 -0500 Subject: [arin-ppml] questions about AC decision re: 103. In-Reply-To: <4B3155D3.40009@umn.edu> References: <4B311E52.8050508@arin.net> <591.1261515471@marajade.sandelman.ca> <4B3155D3.40009@umn.edu> Message-ID: <3c3e3fca0912221608yb7086f3t4e86d8d5bcff6238@mail.gmail.com> On Tue, Dec 22, 2009 at 6:27 PM, David Farmer wrote: > I will reiterate, I believe the biggest issue was the lack of a "needs > basis". David, I'd love to see a definition of needs-basis which doesn't have the effect of making ARIN the gatekeeper for Internet routing policy. If such a definition can be developed, I would be pleased to integrate it into a proposal like 103. I won't hold my breath and I respectfully don't believe the AC should expect the rest of the world to hold its breath either. Does the AC believe that abandoning needs-basis or moving ARIN out of the business of setting Internet routing policy are not proper topics for formal discussion and presentation at the meeting? Please explain. > I don't believe the classful nature was that much of an issue, at least for > me personally. ?The current IPv6 policy is rather classful already, at least > from my point of view, /32s and /48s seem a lot like Class As and Bs to me. > ?But, I must say I wasn't comfortable with /24s being handed out as loosely > as was being proposed. ?It just doesn't seem right, my best example is how > some people feel today about some of the original Class A or /8 allocations, > to major corporations. If this was the only show stopper, I'd be happy to insert some sort of LAN-count language which applies only to /24's and resubmit. I don't imagine any harm in applying a needs-basis to this largest of allocations. Please advise. > Independent of those options and more broadly where do I think we go from > here? ?Shorter-term (for the Toronto PPM) I believe we need proposals to; > > 1. Rewrite 6.5.1.1; to better specify qualifications to be an ISP or LIR and > get a /32. ?A lot of people don't like the 200 end-site definition that is > there today. ?This discussion started back in Dearborn and PP#101 is one > option for this. > > 2. Rewrite 6.5.8.1; Currently end-user policy for IPv6 depends on IPv4 > policy. > > 3. Either as part of #2 or separately, I want to propose a separate IPv6 > pool for assignments that are not intended to be part of the hierarchically > routed global Internet. Respectfully, these notions are stale. We've repeatedly examined them and gotten nowhere fast. Move past this logjam to something fresh. > But, also the minutes for the AC meetings do get posted at the > following link, usually a few weeks after the meeting. But given > the holidays, I expect it will be a little longer for this one. So, next > month sometime look for the minutes of the December 17th Advisory > Council meeting. The minutes for the AC meetings up to, but not > including, the one last week have been posted; It's unfortunate that the minutes will not be posted prior to the deadline for petitioning the AC's decision. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From terry.l.davis at boeing.com Tue Dec 22 18:16:28 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Tue, 22 Dec 2009 15:16:28 -0800 Subject: [arin-ppml] Policy Proposal 105: Simplified M&A transfer policy In-Reply-To: <4B314F82.9070002@chl.com> References: <4B311E63.9040103@arin.net><73DCA149-36EB-49F8-B6BF-06FCA1EEDADE@delong.com> <4B314F82.9070002@chl.com> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF55127B090D@XCH-NW-05V.nw.nos.boeing.com> Joe I absolutely agree and was going to respond to Bill's previous email to agree with his third point on the cost of re-numbering. This idea of forcing an entity to go through the costs and risks associated with re-numbering is I believe the single largest DISINCENTIVE to IPv6 we can perpetuate! Forcing PA space as the only option for most entities to deploy IPv6 has not, nor will it ever fly! It carries too much cost and far too much risk to business continuity. Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Joe Maimon > Sent: Tuesday, December 22, 2009 3:00 PM > To: Owen DeLong > Cc: ARIN PPML > Subject: Re: [arin-ppml] Policy Proposal 105: Simplified M&A transfer > policy > > > > Owen DeLong wrote: > > > > > >> In the event that number resources of the acquired/merged > >> organization(s) are no longer efficiently utilized at the time ARIN > >> becomes aware of the transaction, through a transfer request or > >> otherwise, ARIN will work with the resource holder(s) to return or > >> aggregate resources as appropriate via the processes outlined in > >> sections 4.6, 4.7, or 12 of the NRPM. > >> > > I think that there's an issue here. I think that we need to talk about > > the number resources of the resultant combined organization rather > > than of the acquired/merged organization... Here's why... > > > > The term acquired/merged could be construed to refer only to the > > resources that were acquired without regard for the resources already > > held by the acquiring organization. Let's say that two organizations > > A and B merge. Prior to merger, A efficiently used 17 /24s and held > > a /19, while B efficiently used a /23 and held a /22. The combined > > usage is 19 /24s which would justify a /19, but, would not justify the > > /22 of additional space. The /22 should be returned in this case and > > be renumbered into the /19. > > > > > I think that bringing the possibility of renumbering and reclamation is > somewhat of a disincentive to getting people into the door in the first > place. If you are buying a network that you may have to renumber, you > might want to think twice about it - or wait until you finish > renumbering it before going to 8.3. > > What is the priority for the goals of 8.2 and how much efficiency should > we let slide to achieve them? > > These changes could make 8.3 more attractive than 8.2 > > Joe > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From scottleibrand at gmail.com Tue Dec 22 19:33:55 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 22 Dec 2009 16:33:55 -0800 Subject: [arin-ppml] Policy Proposal 105: Simplified M&A transfer policy In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B090D@XCH-NW-05V.nw.nos.boeing.com> References: <4B311E63.9040103@arin.net><73DCA149-36EB-49F8-B6BF-06FCA1EEDADE@delong.com> <4B314F82.9070002@chl.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B090D@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <4B316573.2030201@gmail.com> On 12/22/2009 3:16 PM, Davis, Terry L wrote: > I absolutely agree and was going to respond to Bill's previous email to agree with his third point on the cost of re-numbering. > > This idea of forcing an entity to go through the costs and risks associated with re-numbering is I believe the single largest DISINCENTIVE to IPv6 we can perpetuate! > > Forcing PA space as the only option for most entities to deploy IPv6 has not, nor will it ever fly! It carries too much cost and far too much risk to business continuity. > Do you see this as a problem with Policy Proposal 105: Simplified M&A transfer policy, or are you making a more general point? Assuming you're referring to proposal 105, can you clarify for me what in the proposed policy drives the renumbering concern? I'm afraid I'm missing something, or that I wrote the proposal in such a way that it's causing unnecessary confusion. Thanks, Scott > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Joe Maimon >> Sent: Tuesday, December 22, 2009 3:00 PM >> To: Owen DeLong >> Cc: ARIN PPML >> Subject: Re: [arin-ppml] Policy Proposal 105: Simplified M&A transfer >> policy >> >> >> >> Owen DeLong wrote: >> >>> >>> >>>> In the event that number resources of the acquired/merged >>>> organization(s) are no longer efficiently utilized at the time ARIN >>>> becomes aware of the transaction, through a transfer request or >>>> otherwise, ARIN will work with the resource holder(s) to return or >>>> aggregate resources as appropriate via the processes outlined in >>>> sections 4.6, 4.7, or 12 of the NRPM. >>>> >>>> >>> I think that there's an issue here. I think that we need to talk about >>> the number resources of the resultant combined organization rather >>> than of the acquired/merged organization... Here's why... >>> >>> The term acquired/merged could be construed to refer only to the >>> resources that were acquired without regard for the resources already >>> held by the acquiring organization. Let's say that two organizations >>> A and B merge. Prior to merger, A efficiently used 17 /24s and held >>> a /19, while B efficiently used a /23 and held a /22. The combined >>> usage is 19 /24s which would justify a /19, but, would not justify the >>> /22 of additional space. The /22 should be returned in this case and >>> be renumbered into the /19. >>> >>> >> >> I think that bringing the possibility of renumbering and reclamation is >> somewhat of a disincentive to getting people into the door in the first >> place. If you are buying a network that you may have to renumber, you >> might want to think twice about it - or wait until you finish >> renumbering it before going to 8.3. >> >> What is the priority for the goals of 8.2 and how much efficiency should >> we let slide to achieve them? >> >> These changes could make 8.3 more attractive than 8.2 >> >> Joe >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From owen at delong.com Tue Dec 22 19:41:44 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Dec 2009 16:41:44 -0800 Subject: [arin-ppml] Policy Proposal 105: Simplified M&A transfer policy In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B090D@XCH-NW-05V.nw.nos.boeing.com> References: <4B311E63.9040103@arin.net><73DCA149-36EB-49F8-B6BF-06FCA1EEDADE@delong.com> <4B314F82.9070002@chl.com> <0267B5481DCC474D8088BF4A25C7F1DF55127B090D@XCH-NW-05V.nw.nos.boeing.com> Message-ID: Terry, I agree with you, but, that's WAY off of what is being suggested below. What is being suggested below is that if two organizations merge, resulting in a plethora of extra space, they should need to return enough space to be restored to ARIN utilization policies. Given current IPv6 utilization policies, it's almost impossible to produce a scenario where an IPv6 return would be necessary under this policy, so, I think it would primarily affect IPv4. Owen On Dec 22, 2009, at 3:16 PM, Davis, Terry L wrote: > Joe > > I absolutely agree and was going to respond to Bill's previous email to agree with his third point on the cost of re-numbering. > > This idea of forcing an entity to go through the costs and risks associated with re-numbering is I believe the single largest DISINCENTIVE to IPv6 we can perpetuate! > > Forcing PA space as the only option for most entities to deploy IPv6 has not, nor will it ever fly! It carries too much cost and far too much risk to business continuity. > > Take care > Terry > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Joe Maimon >> Sent: Tuesday, December 22, 2009 3:00 PM >> To: Owen DeLong >> Cc: ARIN PPML >> Subject: Re: [arin-ppml] Policy Proposal 105: Simplified M&A transfer >> policy >> >> >> >> Owen DeLong wrote: >>> >>> >>>> In the event that number resources of the acquired/merged >>>> organization(s) are no longer efficiently utilized at the time ARIN >>>> becomes aware of the transaction, through a transfer request or >>>> otherwise, ARIN will work with the resource holder(s) to return or >>>> aggregate resources as appropriate via the processes outlined in >>>> sections 4.6, 4.7, or 12 of the NRPM. >>>> >>> I think that there's an issue here. I think that we need to talk about >>> the number resources of the resultant combined organization rather >>> than of the acquired/merged organization... Here's why... >>> >>> The term acquired/merged could be construed to refer only to the >>> resources that were acquired without regard for the resources already >>> held by the acquiring organization. Let's say that two organizations >>> A and B merge. Prior to merger, A efficiently used 17 /24s and held >>> a /19, while B efficiently used a /23 and held a /22. The combined >>> usage is 19 /24s which would justify a /19, but, would not justify the >>> /22 of additional space. The /22 should be returned in this case and >>> be renumbered into the /19. >>> >> >> >> I think that bringing the possibility of renumbering and reclamation is >> somewhat of a disincentive to getting people into the door in the first >> place. If you are buying a network that you may have to renumber, you >> might want to think twice about it - or wait until you finish >> renumbering it before going to 8.3. >> >> What is the priority for the goals of 8.2 and how much efficiency should >> we let slide to achieve them? >> >> These changes could make 8.3 more attractive than 8.2 >> >> Joe >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. From owen at delong.com Tue Dec 22 19:50:02 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Dec 2009 16:50:02 -0800 Subject: [arin-ppml] Abandonment of 103/104 Message-ID: <73E11B6A-EB6F-4D02-8F2B-F9345F776644@delong.com> As one of the members of the AC who voted to abandon these proposals, I will state that my reasoning was as follows: 1. Basing address policy solely on the amount of money you are willing to spend for addresses is completely contrary to my understanding of the good of the community. 2. Crafting internet addressing policy with the clear intent of making it easy for larger networks to treat smaller networks or networks with smaller budgets as second-class citizens by easily relegating them into a filtration category based solely on assignment size is contrary to my understanding of the good of the community. Finally, it is difficult to express this without violating confidentiality provisions of the NDA each AC member signs, so, please understand that I am limited in what I can say here and cannot clarify. I felt that the alternative suggested actions on this policy were contrary to the intent of the PDP and that abandonment with the author/community having their full ability to utilize the petition process was the more correct action. Owen From rw at firstpr.com.au Tue Dec 22 19:39:19 2009 From: rw at firstpr.com.au (Robin Whittle) Date: Wed, 23 Dec 2009 11:39:19 +1100 Subject: [arin-ppml] Does Moore's law help with routing table growth? Get thee to the RRG! In-Reply-To: <63ac96a50912221218o7c83feddu403c1179b8eda63c@mail.gmail.com> References: <4B2C5DDD.7050501@gmail.com> <471D76419F9EF642962323D13DF1DF69011612@newserver.arneill-py.local> <4B2C65E1.3090705@gmail.com> <63ac96a50912221218o7c83feddu403c1179b8eda63c@mail.gmail.com> Message-ID: <4B3166B7.7040906@firstpr.com.au> Short version: The tension between DFZ scaling vs. end-user network portability/multihoming/TE need not be a zero-sum game. The IRTF Routing Research Group has multiple proposals to enhance the Internet's architecture to enable much wider use of portability, multihoming etc. without seriously burdening the DFZ. Discussions continue to mid-February and the final recommendation to the IETF needs to be finished by the end of February. I hope anyone with an interest in this field will participate: http://www.irtf.org/charter?gtype=rg&group=rrg http://tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup http://www.ietf.org/mail-archive/web/rrg/current/maillist.html Hi Matt, There are various administrative and economic ways of limiting the growth in the DFZ routing table, and so reducing DFZ router costs and limiting the increase in DFZ convergence time. This would directly protect two sets of interests: 1 - Costs of ISPs. 2 - Costs of end-user networks with ASNs which currently advertise their space in the DFZ AND run their own DFZ routers. It would also tend to improve everyone's Internet use if the DFZ stability is improved, or at least not worsened as much as it would be with many more DFZ routes. Also, reducing ISP costs is generally a benefit to all Internet users, since we all depend on ISPs in one way or another and ultimately pay all their costs. (Perhaps end-user networks with their own DFZ routers are not so dependent on ISPs.) Its not just a question of advertising a prefix - it is how often that advertisement is changed. Rapid TE, such as to accommodate traffic patterns which change on a 24 hour cycle, or faster, will change the advertisements frequently and so burden the DFZ's BGP control plane - leading to potentially greater instability. We accept that ISPs need to advertise their prefixes in the DFZ and we accept that this alone is scalable - but this depends on some limit to the number of ISPs, which so far has not been a problem. Any ISPs which chop and change their advertisements would arguably be as much of a burden on the DFZ as a bunch of extra end-user network prefixes. Your solution - administrative and economic push-back - involves restricting end-user networks from getting something they can get now, so it is harder or impossible to get. The RRG is trying to find a way to alter the architecture of the Net so the end-user networks, potentially right down to SOHO (and mobile devices, though mobility is outside the RRG's goals) can get what they want, inexpensively, without causing a burden on the DFZ. There are multiple proposals - 22 December is the final day for accepting them and I guess they will soon be listed in the wiki. I think you and any other people who have thought about this DFZ vs. multihoming/portability/TE problem would be able to make a contribution to the RRG's decisions on what to recommend to the IETF. (I am just an RRG member.) - Robin From bill at herrin.us Tue Dec 22 20:01:46 2009 From: bill at herrin.us (William Herrin) Date: Tue, 22 Dec 2009 20:01:46 -0500 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <73E11B6A-EB6F-4D02-8F2B-F9345F776644@delong.com> References: <73E11B6A-EB6F-4D02-8F2B-F9345F776644@delong.com> Message-ID: <3c3e3fca0912221701l4db11136h1721433b55cde89a@mail.gmail.com> On Tue, Dec 22, 2009 at 7:50 PM, Owen DeLong wrote: > As one of the members of the AC who voted to abandon these proposals, I will > state that my reasoning was as follows: > > 1. ? ? ?Basing address policy solely on the amount of money you are willing > ? ? ? ?to spend for addresses is completely contrary to my understanding of > ? ? ? ?the good of the community. > > 2. ? ? ?Crafting internet addressing policy with the clear intent of making it easy > ? ? ? ?for larger networks to treat smaller networks or networks with smaller > ? ? ? ?budgets as second-class citizens by easily relegating them into a > ? ? ? ?filtration category based solely on assignment size is contrary to my > ? ? ? ?understanding of the good of the community. Owen, Is the community not capable of expressing this during the consensus call following formal presentation? You would substitute your judgment for theirs? I'm deeply disturbed by this post. My understanding is that the AC's mission is to help the community craft the best possible policy which expresses its will and to help the process move smoothly. Killing a well supported proposal this early obstructs the community's role in the policy process. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jmaimon at chl.com Tue Dec 22 20:11:09 2009 From: jmaimon at chl.com (Joe Maimon) Date: Tue, 22 Dec 2009 20:11:09 -0500 Subject: [arin-ppml] Policy Proposal 105: Simplified M&A transfer policy In-Reply-To: References: <4B311E63.9040103@arin.net> <73DCA149-36EB-49F8-B6BF-06FCA1EEDADE@delong.com> <4B314F82.9070002@chl.com> Message-ID: <4B316E2D.6070601@chl.com> Owen DeLong wrote: > > On Dec 22, 2009, at 3:00 PM, Joe Maimon wrote: >> >> I think that bringing the possibility of renumbering and reclamation >> is somewhat of a disincentive to getting people into the door in the >> first place. If you are buying a network that you may have to >> renumber, you might want to think twice about it - or wait until you >> finish renumbering it before going to 8.3. >> > I don't see the connection, necessarily. > >> What is the priority for the goals of 8.2 and how much efficiency >> should we let slide to achieve them? >> > Primarily to make it clear that number resources are not transferable > away from their original intended > purpose without justified need under ARIN policy. 8.3 is not > particularly useful for the merger/acquisition > of company scenario. > > Both policies preserve the same requirement that you adhere to ARIN > needs-based policy > to effectuate a legitimate transfer. > > Owen > Lets take this illustration. Suppose I acquire an ISP whose bread and butter is dialup and some colo servers. They justified a /20 when they started out, but their dial up population has been decreasing steadily. They would only qualify now for a /22. Thats not an issue for them since they are not trying to obtain any more space. Does this policy change increase or decrease the odds that I would choose to initiate 8.2 rather than simply continue to treat these resources and organizations as separate ARIN entities? And if acquiring this company initates a review of my companies utilization, does the acquisition now have higher risk because of these policy changes? Do we want organizations to voluntary initiate 8.2? Renumbering a legacy network where everything works just fine as it is adds to acquisition costs. And if the likely result of any of this policy change means that you are going to have to renumber, it is probably better to just go ahead and do so. Hold off on 8.2 and wait for depletion so that you can either 8.3 between organizations or just to get some dollars. Joe From sethm at rollernet.us Tue Dec 22 20:22:31 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 22 Dec 2009 17:22:31 -0800 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <73E11B6A-EB6F-4D02-8F2B-F9345F776644@delong.com> References: <73E11B6A-EB6F-4D02-8F2B-F9345F776644@delong.com> Message-ID: <4B3170D7.8040407@rollernet.us> Owen DeLong wrote: > As one of the members of the AC who voted to abandon these proposals, I will > state that my reasoning was as follows: > > 1. Basing address policy solely on the amount of money you are willing > to spend for addresses is completely contrary to my understanding of > the good of the community. > > 2. Crafting internet addressing policy with the clear intent of making it easy > for larger networks to treat smaller networks or networks with smaller > budgets as second-class citizens by easily relegating them into a > filtration category based solely on assignment size is contrary to my > understanding of the good of the community. > While I agree with your disagreement on class separation by how much money you have, I do believe that IPv6 lends itself to classful-ness and trying to apply IPv4 style justification to IPv6 is inherently broken. ~Seth From owen at delong.com Tue Dec 22 20:22:45 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Dec 2009 17:22:45 -0800 Subject: [arin-ppml] Policy Proposal 105: Simplified M&A transfer policy In-Reply-To: <4B316E2D.6070601@chl.com> References: <4B311E63.9040103@arin.net> <73DCA149-36EB-49F8-B6BF-06FCA1EEDADE@delong.com> <4B314F82.9070002@chl.com> <4B316E2D.6070601@chl.com> Message-ID: <3C85A935-93FC-49E2-BBAC-E53523894786@delong.com> On Dec 22, 2009, at 5:11 PM, Joe Maimon wrote: > > > Owen DeLong wrote: >> >> On Dec 22, 2009, at 3:00 PM, Joe Maimon wrote: >>> >>> I think that bringing the possibility of renumbering and reclamation is somewhat of a disincentive to getting people into the door in the first place. If you are buying a network that you may have to renumber, you might want to think twice about it - or wait until you finish renumbering it before going to 8.3. >>> >> I don't see the connection, necessarily. >> >>> What is the priority for the goals of 8.2 and how much efficiency should we let slide to achieve them? >>> >> Primarily to make it clear that number resources are not transferable away from their original intended >> purpose without justified need under ARIN policy. 8.3 is not particularly useful for the merger/acquisition >> of company scenario. >> >> Both policies preserve the same requirement that you adhere to ARIN needs-based policy >> to effectuate a legitimate transfer. >> >> Owen >> > > Lets take this illustration. Suppose I acquire an ISP whose bread and butter is dialup and some colo servers. They justified a /20 when they started out, but their dial up population has been decreasing steadily. They would only qualify now for a /22. Thats not an issue for them since they are not trying to obtain any more space. > Sure it is... A section 12 resource review could well cause them to need to return some of that space. They should return it if they are no longer using it. > Does this policy change increase or decrease the odds that I would choose to initiate 8.2 rather than simply continue to treat these resources and organizations as separate ARIN entities? And if acquiring this company initates a review of my companies utilization, does the acquisition now have higher risk because of these policy changes? > Not really... The company could get reviewed at any time under section 12 whether you acquire it or not. > Do we want organizations to voluntary initiate 8.2? Renumbering a legacy network where everything works just fine as it is adds to acquisition costs. > Again, this doesn't require any renumbering that wouldn't otherwise be required under ARIN policy. It does make it more likely that policy could get enforced, but, other forces will drive that absent acquisition in the near future in my opinion. > And if the likely result of any of this policy change means that you are going to have to renumber, it is probably better to just go ahead and do so. Hold off on 8.2 and wait for depletion so that you can either 8.3 between organizations or just to get some dollars. > I don't think that the policy change being proposed change that likelihood vs. the current policy. Both existing and the proposed change to the policy provide for a review. So does section 8.3. Owen From rw at firstpr.com.au Tue Dec 22 20:34:30 2009 From: rw at firstpr.com.au (Robin Whittle) Date: Wed, 23 Dec 2009 12:34:30 +1100 Subject: [arin-ppml] Modified Header Forwarding for scalable routing In-Reply-To: <63ac96a50912221359m1e2bbddaub3567789b5cbc2ab@mail.gmail.com> References: <4B2AD4A0.6080908@firstpr.com.au> <20091218020045.GA24163@ussenterprise.ufp.org> <4B2B4976.2070302@firstpr.com.au> <20091218155153.GA78343@ussenterprise.ufp.org> <4B2C68D8.7020006@firstpr.com.au> <20091219061711.GB34678@ussenterprise.ufp.org> <4B2C8202.1050204@firstpr.com.au> <4B2E08C4.7020004@firstpr.com.au> <63ac96a50912221359m1e2bbddaub3567789b5cbc2ab@mail.gmail.com> Message-ID: <4B3173A6.8000909@firstpr.com.au> Short version: MPLS doesn't seem to be suitable for the task of scalably transporting traffic packets across the DFZ in a core-edge separation solution to the routing scaling problem. Even if it was suitable, it involves encapsulation overhead and therefore Path MTU Discovery problems. AFAIK, no RRG proposals involve MPLS. Hi Matt, You wrote: >> Short version: Owen DeLong suggested a scalable routing solution >> would be to have DFZ routers modified to handle >> packets with modified header structure. As I >> understand it, the new packet format would contain >> the ASN of the destination ISP and the DFZ routers >> forward it on this basis, without looking at the >> destination address, which would remain unaltered. > > This isn't sounding that far off from just running MPLS in the DFZ > core, and passing labels around, with a set of label values > representing the peering edge routers of other ASNs. Just > seems like if we already have a code base for passing packets > along based on a single tag value instead of doing address > parsing and lookups, with routing of the internal packet being > handled at the far end like normal after popping off the intervening > tag, we might consider leveraging an encapsulation format that's > been widely deployed and operated for the past decade. I think what Owen and I are attempting to achieve, with our different proposals, is a system which doesn't add to the length of the packet at all - and can still be used to provide multihoming, portability and TE for very large numbers of end-user networks, without overburdening the DFZ. The focus of my plans is to reduce the burden on the FIB of each DFZ router, and more importantly the RIB and therefore the DFZ's BGP control plane. I think Owen wants to reduce the FIB size, but is so concerned about the RIB and the general BGP control traffic, stability etc. Establishing an MPLS path involves a great deal of control plane activity, and involves significant state in the FIB. The label value is changed at each router, and the path is a point-to-point path. I can't see how point-to-point paths could perform what we need here: getting traffic packets from ITR or ITR-like device (really from any one of potentially millions of them) across the DFZ to some ETR or ETR-like device which restores the packet to its original form and somehow gets it to the destination network. These paths need to change quickly for the purposes of multihoming service restoration and inbound traffic engineering. MPLS's extra packet length represents inefficiency, especially for small VoIP packets, and raises difficult problems with Path MTU Discovery. So I don't think MPLS is a suitable technique. AFAIK, no RRG proposal uses MPLS. > This probably would be a better discussion on NANOG or some > other more routing-operations focused list, rather than a numbers > resource policy list, though. ^_^; Maybe so, but we just had 40 or so messages on Moore's Law and about the DFZ. The RRG is focussed now on discussing proposals which have been registered. Owen's proposal is not registered, so I think PPML is a good place to discuss it - but if the moderators say otherwise, that's fine. My two proposals are part of my Ivip proposal with the RRG, so the RRG would be a good place to discuss them. - Robin From scottleibrand at gmail.com Tue Dec 22 20:34:47 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 22 Dec 2009 17:34:47 -0800 Subject: [arin-ppml] Policy Proposal 105: Simplified M&A transfer policy In-Reply-To: <4B316E2D.6070601@chl.com> References: <4B311E63.9040103@arin.net> <73DCA149-36EB-49F8-B6BF-06FCA1EEDADE@delong.com> <4B314F82.9070002@chl.com> <4B316E2D.6070601@chl.com> Message-ID: <4B3173B7.8080202@gmail.com> On 12/22/2009 5:11 PM, Joe Maimon wrote: > > Lets take this illustration. Suppose I acquire an ISP whose bread and > butter is dialup and some colo servers. They justified a /20 when they > started out, but their dial up population has been decreasing > steadily. They would only qualify now for a /22. Thats not an issue > for them since they are not trying to obtain any more space. Ok. So the dialup pools are dynamically assigned, and the colo servers are static. Under NRPM section 12, the ISP you acquired was already subject (before the acquisition) to an audit of their space. Assuming they no longer need all of it, they would be asked to return some of it. That *doesn't* mean they'd need to do any renumbering. Per 4.6.2 and especially 4.6.3, "An organization shall be allowed to return a partial block of any size to ARIN. For any return greater than a /24, ARIN shall not require that the non-returned portion of the block be renumbered unless the returning organization wishes to do so." So they could simply return half of their dynamic dial-up pool. > > Does this policy change increase or decrease the odds that I would > choose to initiate 8.2 rather than simply continue to treat these > resources and organizations as separate ARIN entities? And if > acquiring this company initates a review of my companies utilization, > does the acquisition now have higher risk because of these policy > changes? > > Do we want organizations to voluntary initiate 8.2? Renumbering a > legacy network where everything works just fine as it is adds to > acquisition costs. Several different scenarios are possible: - Let's say you're growing your business, and have been requesting a /23 every six months. Therefore, you'll be able to use the extra /22 within a year, and you shouldn't have to return anything. - Alternately, let's say you're also in the dial-up business, and have some unused space of your own. In that case, you'd need to return some space. As I mentioned above, that doesn't require you to renumber if you don't want to: you can just return the unused space. > > And if the likely result of any of this policy change means that you > are going to have to renumber, it is probably better to just go ahead > and do so. Hold off on 8.2 and wait for depletion so that you can > either 8.3 between organizations or just to get some dollars. You can already use 8.3 to transfer IPv4 addresses between organizations, but the receiving organization has to have a justified need for the space. If an organization is attempting to defraud ARIN by hanging on to unjustified IPv4 space until scarcity develops, with the intent of attempting to transferring that space under 8.3 for a profit, then no matter what we do to 8.2, they're going to do their best to stay as far away from ARIN as possible until they're ready to transfer the space. I actually attempted to address that, to some degree, by directing ARIN to "work with the resource holder(s) to return or aggregate resources as appropriate via the processes outlined in sections 4.6, 4.7, or 12 of the NRPM" "in the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise". That way the resource review will occur as soon as ARIN finds out about the situation, regardless of whether a transfer request is initiated. -Scott From scottleibrand at gmail.com Tue Dec 22 21:42:50 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 22 Dec 2009 18:42:50 -0800 Subject: [arin-ppml] Does Moore's law help with routing table growth? In-Reply-To: <63ac96a50912221218o7c83feddu403c1179b8eda63c@mail.gmail.com> References: <4B2C5DDD.7050501@gmail.com> <471D76419F9EF642962323D13DF1DF69011612@newserver.arneill-py.local> <4B2C65E1.3090705@gmail.com> <63ac96a50912221218o7c83feddu403c1179b8eda63c@mail.gmail.com> Message-ID: <4B3183AA.6080205@gmail.com> On 12/22/2009 12:18 PM, Matthew Petach wrote: > On Fri, Dec 18, 2009 at 9:34 PM, Scott Leibrand wrote: > >> On 12/18/2009 9:19 PM, Michel Py wrote: >> >>> I don't think we have much maneuvering room though; the benefits of >>> Moore's law helping building faster routers are more or less offset by >>> the same Moore's law helping building more bandwidth-hungry consumer >>> devices. >>> >> Except that the bandwidth of consumer devices is completely independent of >> the number of routes we have to stuff into our FIB. That is dependent on >> the number of independently multihomed networks, which is determined by >> economic and business forces. >> > Which seems to imply that one perfectly valid control point to limit the > growth of the routing table is simply keep raising the price of registering > an ASN to the point where few enough new business can afford to multihome; > If we just raised the prices of ASNs, multihoming with private ASNs would become a lot more popular. > if we keep the number of new multihomed networks entering the global > tables to a rate slightly slower than the development and deployment > curve of hardware able to do lookups on those new multihomed networks, > then we should be able to continue to scale the DFZ as long as necessary. > Which is, AFAICT, exactly what has been happening, without any policy or fee action on our part. (Anyone can buy a cheap router off eBay, get a /24 from an upstream, and announce it into BGP. The router doesn't need to be able to take a full BGP feed.) > Just give the hardware engineers a means to feed back into the RIRs if > they run into a roadblock, so that the appropriate fees for an ASN can be > raised to slow down the rate of new multihoming entrants until the technology > is able to overcome the roadblock and continue progressing again. > > Thus, the concern of DFZ routing table slots moves firmly into the business > realm, subject to economic forces, and out of the policy-making arena. > IMO the RIRs are not the proper tool for doing this. If it becomes necessary to put a price on routing slots, I think it would be much more appropriate for ISPs to do it directly. It wouldn't have to be an exactly equal charge across-the-board, either: they could do it much as airlines have done for checked bags. >>> In other words, growth of the DFZ table has to rely on router >>> enhancements, not on riding Moore's law. >>> >>> >> I believe that enhancements in router FIB capacity are to some degree >> dependent on the same forces driving Moore's law. Obviously keeping Moore's >> law going (whether in CPUs or in TCAMs) requires hard engineering work, but >> that's not the point. The point of Moore's law is that all that hard work >> results in a periodic doubling of capacity (in this case, FIB routes) for >> the same price. For now, that improvement is keeping ahead of the growth >> rate of networks seeking to multihome. >> > We currently have a very loose economic feedback system in place; > the hardware needed to effectively multihome via BGP4 is kept expensive > because it's funding a rapid development cycle which is attempting to > stay abreast of that curve. If we raise the costs to multihome, fewer > networks will add to the DFZ routing table, and the pressure on growth > and technology advancement decreases. We can raise the cost to > multihome in 2 ways; one, through the hardware costs (today's model); > the other is via the one other item required for multihoming--number > resources (IP addresses and ASNs). ASNs are explicitly tied to > multihoming, so those are an easy one to control; raise the price, > and fewer new entrants show up to tie up slots in the DFZ RIB. > Or they show up as two different announcements originated by both their upstreams, because they've switched to using a private ASN. > Would it help if we made route table advertisement registration via the > registry's IRR mandatory, and charged each network for IRR services > based on the number of route announcements they make--so, first > announcement for the supernet/aggregate comes free with the number > resource, but each additional more specific within the aggregate > comes at increasing cost to register? First deaggregation costs > $100/year additional, second one from the same supernet costs > $200/year additional, etc. > That way, even if you have 1,000 prefixes assigned by the RIR, if > all you announce is the aggregates, there's no net additional cost; > but if you have a single /20 from the registry, and deaggregate it > down to /24s, it'll cost you $12,000 extra per year (for the 15 > additional deaggregations you've added within the block). > That would give us very strong economic feedback systems for > ensuring that companies are well-motivated to not deaggregate > unless it is for very good business reasons (ie, the additional > revenue they bring in by deaggregating more than offsets the > additional costs for registering the deaggregates.) > > That would also bring about the benefit that we could all build > very clean explicit route filters based on the contents of the > routing registry; if you haven't paid to register the route, people > won't listen to it. > That would work, but only if you can get everyone to participate. I'm not sure you could, and even if you could, you might need to get an anti-trust exemption from the federal government to make it legal. > I suppose it's easier to charge more for IP addresses and > ASNs to limit growth than it is to charge for route registrations > because up to now, there's been no charge for route registrations, > and there'd be a huge hue and cry if we tried to start charging > for them, probably even more of a fuss than was heard when > ASNs and IP address registrations were first charged for. > Agreed. There's also the question of who does the charging. If it's ARIN, what do they do with the money? Spend it? Distribute it somehow? Up until now, ARIN has operated on a cost recovery basis (with some reserves). Changing that is fraught with complexity, IMO, and should only be done if we get to the point where they can't handle the problem directly (by charging customers, and through peering agreements and possibly filters on more-specific peer routes). > Still...I do think it's valuable to realize that fundamentally the > concerns people have over routing table growth are largely > economic ones, so it would make sense to put the feedback > controls squarely into the economic realm, rather than trying > to figure a way to jury-rig them in via the policy system. > Agreed. But we're essentially talking about externalities here, which are a hard nut to crack. But not an impossible one: the latest Nobel Economics prize was given out for research into various such externality/collective action/trajedy-of-the-commons problems, which demonstrated that it can be done when done right. -Scott From mcr at sandelman.ca Tue Dec 22 22:11:58 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 22 Dec 2009 22:11:58 -0500 Subject: [arin-ppml] questions about AC decision re: 103. In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B090E@XCH-NW-05V.nw.nos.boeing.com> References: <4B311E52.8050508@arin.net> <591.1261515471@marajade.sandelman.ca> <4B3155D3.40009@umn.edu> <0267B5481DCC474D8088BF4A25C7F1DF55127B090E@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <10473.1261537918@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Terry" == Terry L Davis writes: Terry> David Terry> I'll take a crack at this "needs issue" from a different Terry> angle. Terry> Since I'm in the edge of critical infrastructure numerous Terry> ways every, I guess I'd point out a few things in the way of Terry> re-addressing that we don't really think about: Terry> - When would be a good time for your local hospital to Terry> re-address its Emergency Room and ICU? This seems like IPv4 thinking to me. Renumbering in IPv4 is very hard. Addresses are hard coded rather than discovered by name, and DHCP can only assign end-host addresses, rather than also assign subnets to routers. In IPv4 nodes had one IP per interface, and no easy way to get two. In IPv6, nodes have multiple IPs per interface, in seperate subnets. Renumbering, while not very fun, occurs incrementally. I know a bit about Emergency Rooms and ICUs, as well as how the hospitals track equipment (generally.. badly).... you renumber a room when you have moved the patient out, while you are cleaning up, and resetting all the equipment. In the future, likely this equipment is connected together with Zigbee or bluetooth using 6lowpan and/or RPL into a /64. Likely, all that equipment routes through a grounded router (maybe in the bed). (grounded means, having an uplink, not electrical ground) I would design this system to be a self-contained /64, mobile in the hospital, and I would never renumber it as long as the patient is in that bed. To renumber, move the patient to another bed. (No, none of this address space is globally routed, but all of it is unique) Terry> We make this crazy assumption that our business models Terry> function as they did before the Internet. They DON'T! We Terry> live in a 7x24 world now; our businesses, our livelihood, and Terry> our own personal safety depend on the Internet, 7x24 with at Terry> least 4 9's reliability. Terry> The PA concept is so broken in this context that I can find Terry> no way to defend it; I understand it at a technical level but Terry> that does not translate to the real world we live in. PA is not the problem --- it works for the majority of current uses. Religious belief in only PA is the problem. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSzGKeYCLcPvd0N1lAQJPLwf8D1+69PaQFTWpnxCg3AsyXFbObg3jISql epow/dNuR96nUisI/gaPWMmramo0YQ5NCu7ROQldVz2whZD4YaNbezgr9s0SVKQT SNRZluMVDCMPi9Xfn9hplPHtFonS4o1ASXMrnJBZVEE+n62jFIlMoERlwoin7hQs LktT+8IwWQG4XY4wXnckMtKvv2OaN4PCJ4e39B5IELS93TL2CYOCbnpTXe9DdVvL W2DhImBG25gTOEdvGdUkl0OUnrB6wv14Rg3T3Rzf16mHRvSBnB73NG+jdCQpAcdE L+Eebsk+DdrTxLEZA1e53EH4mE8ebZ/fje3DwR1RXiVI08jShRKMFA== =3FrH -----END PGP SIGNATURE----- From owen at delong.com Tue Dec 22 22:29:24 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Dec 2009 19:29:24 -0800 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <3c3e3fca0912221701l4db11136h1721433b55cde89a@mail.gmail.com> References: <73E11B6A-EB6F-4D02-8F2B-F9345F776644@delong.com> <3c3e3fca0912221701l4db11136h1721433b55cde89a@mail.gmail.com> Message-ID: <78E9E00B-5F61-4503-9F48-A50288544227@delong.com> On Dec 22, 2009, at 5:01 PM, William Herrin wrote: > On Tue, Dec 22, 2009 at 7:50 PM, Owen DeLong wrote: >> As one of the members of the AC who voted to abandon these proposals, I will >> state that my reasoning was as follows: >> >> 1. Basing address policy solely on the amount of money you are willing >> to spend for addresses is completely contrary to my understanding of >> the good of the community. >> >> 2. Crafting internet addressing policy with the clear intent of making it easy >> for larger networks to treat smaller networks or networks with smaller >> budgets as second-class citizens by easily relegating them into a >> filtration category based solely on assignment size is contrary to my >> understanding of the good of the community. > > Owen, > > Is the community not capable of expressing this during the consensus > call following formal presentation? You would substitute your judgment > for theirs? > The PDP tasks the AC with determining if a proposal could result in good policy. In my judgment, this policy could not without being modified in ways that, to me, seemed incompatible with your rationale and stated intent. As such, I felt it was best to abandon the proposal. I do not know to what extent the other AC members who voted to abandon these proposals have the same reasons as I do for their votes. I am speaking only for myself, and, the above accusation is probably one of the reasons I am the only one who has spoken up so far about my reasons. > I'm deeply disturbed by this post. My understanding is that the AC's > mission is to help the community craft the best possible policy which > expresses its will and to help the process move smoothly. Killing a > well supported proposal this early obstructs the community's role in > the policy process. > If you feel that the proposal is so well supported, the petition process provides a very good safety valve for exactly that purpose. Owen From michel at arneill-py.sacramento.ca.us Tue Dec 22 23:24:15 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 22 Dec 2009 20:24:15 -0800 Subject: [arin-ppml] Routing Research Group is about to decide its scalable routing recommendation In-Reply-To: <4B2ED10B.4040704@chl.com> References: <4B2AD4A0.6080908@firstpr.com.au> <471D76419F9EF642962323D13DF1DF69011622@newserver.arneill-py.local> <4B2ED10B.4040704@chl.com> Message-ID: <471D76419F9EF642962323D13DF1DF6901162C@newserver.arneill-py.local> > Joe Maimon wrote: > To be clear, I dont [want to] have any of my own conclusions, > only the curiosity of the likely ill-informed as to the > thoughts of those involved in the problem space in this aspect. There is nothing wrong in having your own conclusions IMHO, as long as you understand that their influence greatly depends on how bold they are and the "peer recognition" factor. The only reason I think that I am somehow entitled to a voice in this is because I tried, and because I failed. > Even as the tech appears shiny and usable, I am unclear on > how it will actually eliminate the PI v. DFZ debate that > crops up here and there now and again. Of course this is exaggerated, but I think that the PI v. DFZ is as sure as death and taxes from where I stand from. No matter how bright and optimistic Robin and other IRTF folks are (and they are bright and hard-working on it), I (not the only one, doesn't claim I invented it all) wrote years ago about the hot topics they are currently discussing. I can remember the excitement. That being said, in my wildest dreams, it will take at least 15 years to replace BGP if the economic conditions were there, which they are not anymore. As stated earlier, many people considered earlier on that deploying IPv6 would be a lesser challenge than replacing BGP. > It really would be nice have our cake and eat it too and I was > hoping that a navigable path to there can be shown to exist. So did I believe, 10 years ago. And I did spend a lot of time and some personal money to write things, attend IETF meetings on my on dime, and so on. I still have to see that navigable path. When I designed MHAP, the design goal was 1 Billion multihomed sites. Just too complex. Michel. From michel at arneill-py.sacramento.ca.us Tue Dec 22 23:31:07 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 22 Dec 2009 20:31:07 -0800 Subject: [arin-ppml] Does Moore's law help with routing table growth? In-Reply-To: <4B3183AA.6080205@gmail.com> References: <4B2C5DDD.7050501@gmail.com> <471D76419F9EF642962323D13DF1DF69011612@newserver.arneill-py.local> <4B2C65E1.3090705@gmail.com><63ac96a50912221218o7c83feddu403c1179b8eda63c@mail.gmail.com> <4B3183AA.6080205@gmail.com> Message-ID: <471D76419F9EF642962323D13DF1DF6901162D@newserver.arneill-py.local> > Scott Leibrand wrote: > If we just raised the prices of ASNs, multihoming with > private ASNs would become a lot more popular. We may be agreeing on this, but I feel the limitations of my English here. I must have missed a step; how does multihoming with private ASNs work? Besides, ASNs are not in short supply, slots in the routing table are problematic. How would raising the price of ASNs would prevent people from announcing a gazillion prefixes from one ASN? Michel. From scottleibrand at gmail.com Wed Dec 23 00:25:47 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 22 Dec 2009 21:25:47 -0800 Subject: [arin-ppml] Does Moore's law help with routing table growth? In-Reply-To: <471D76419F9EF642962323D13DF1DF6901162D@newserver.arneill-py.local> References: <4B2C5DDD.7050501@gmail.com> <471D76419F9EF642962323D13DF1DF69011612@newserver.arneill-py.local> <4B2C65E1.3090705@gmail.com><63ac96a50912221218o7c83feddu403c1179b8eda63c@mail.gmail.com> <4B3183AA.6080205@gmail.com> <471D76419F9EF642962323D13DF1DF6901162D@newserver.arneill-py.local> Message-ID: <4B31A9DB.6000704@gmail.com> On 12/22/2009 8:31 PM, Michel Py wrote: >> Scott Leibrand wrote: >> If we just raised the prices of ASNs, multihoming with >> private ASNs would become a lot more popular. >> > We may be agreeing on this, but I feel the limitations of my English > here. You hide any such limitation well. :-) > I must have missed a step; how does multihoming with private ASNs > work? > Our mutual customer runs BGP with both of us, uses a private ASN to run BGP, and announces both of us his route. We both implement the remote-private-as command (or equivalent) to strip his private ASN from the path before announcing it to our providers and peers. As a result, the BGP table contains the route with two different origin ASNs: mine and yours. That's ugly, but it doesn't really break anything. > Besides, ASNs are not in short supply, slots in the routing table are > problematic. How would raising the price of ASNs would prevent people > from announcing a gazillion prefixes from one ASN? Exactly correct. Which is why any viable method would have to monetize the routing slots directly, for example by tier 1 transit providers charging their customers per route announced, and adding deaggregation ratio requirements to their existing traffic ratio requirements in their peering agreements with each other. Which won't happen unless the rate of growth of the routing table becomes a much more significant problem than it is today, or router capacity growth dramatically slows. -Scott From scottleibrand at gmail.com Wed Dec 23 01:10:36 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 22 Dec 2009 22:10:36 -0800 Subject: [arin-ppml] Does Moore's law help with routing table growth? In-Reply-To: <4B31A9DB.6000704@gmail.com> References: <4B2C5DDD.7050501@gmail.com> <471D76419F9EF642962323D13DF1DF69011612@newserver.arneill-py.local> <4B2C65E1.3090705@gmail.com><63ac96a50912221218o7c83feddu403c1179b8eda63c@mail.gmail.com> <4B3183AA.6080205@gmail.com> <471D76419F9EF642962323D13DF1DF6901162D@newserver.arneill-py.local> <4B31A9DB.6000704@gmail.com> Message-ID: <4B31B45C.1050501@gmail.com> On 12/22/2009 9:25 PM, Scott Leibrand wrote: > We both implement the remote-private-as command (or equivalent) to > strip his private ASN from the path I meant remove-private-as, of course. ("Spellcheckers... Helping you correctly spell the wrong word every time." - Thanks, Owen!) :-) -Scott From bill at herrin.us Wed Dec 23 01:16:19 2009 From: bill at herrin.us (William Herrin) Date: Wed, 23 Dec 2009 01:16:19 -0500 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <78E9E00B-5F61-4503-9F48-A50288544227@delong.com> References: <73E11B6A-EB6F-4D02-8F2B-F9345F776644@delong.com> <3c3e3fca0912221701l4db11136h1721433b55cde89a@mail.gmail.com> <78E9E00B-5F61-4503-9F48-A50288544227@delong.com> Message-ID: <3c3e3fca0912222216s5dffd68fxfa5b5c11460533d5@mail.gmail.com> On Tue, Dec 22, 2009 at 10:29 PM, Owen DeLong wrote: > The PDP tasks the AC with determining if a proposal could result in good > policy. Yes, it does. At a much later point in the process: when the AC is called upon to recommend for or against adoption by the board. But hey, you know what's good for the community so let's take a shortcut and skip the part where we ask the community what it wants. > I do not know to what extent the other AC members who voted to abandon > these proposals have the same reasons as I do for their votes. ?I am > speaking only for myself, and, the above accusation is probably one > of the reasons I am the only one who has spoken up so far about > my reasons. I appreciate your honesty. I hope you're wrong about the other AC members speaking up. No one likes taking abuse but you do sign up for explaining yourself when you run for election to the AC. That's part of the "public" in "public policy." > If you feel that the proposal is so well supported, the petition process > provides a very good safety valve for exactly that purpose. >The PDP tasks the AC with determining if a proposal could result in good >policy. In my judgment, this policy could not without being modified >in ways that, to me, seemed incompatible with your rationale and >stated intent. Scott suggested that we first wait a week and see if anyone has anything fresh to say on the well worn trails of brokenness in the current IPv6 policy. I think that's a fine idea, so let's hear the proposal as you say you would modify it, whether it matches my intent or not. Seriously, you've had 6 months since abandoning proposal 92 and what you've achieved is a change from: "The AC [...] does not believe that the problem addressed is immediate nor of sufficient scope currently" to "the AC perceives there is significant support for major revisions to IPv6 policy" but we don't like this one. Lead, follow or get out of the way. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From christopher.morrow at gmail.com Wed Dec 23 02:33:36 2009 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 23 Dec 2009 02:33:36 -0500 Subject: [arin-ppml] Does Moore's law help with routing table growth? In-Reply-To: <4B2C5DDD.7050501@gmail.com> References: <4B2C5DDD.7050501@gmail.com> Message-ID: <75cb24520912222333r2a29a328x5a58cc58bf5686fd@mail.gmail.com> (from the wayback machine) On Sat, Dec 19, 2009 at 12:00 AM, Scott Leibrand wrote: > On 12/17/2009 7:45 PM, Michel Py wrote: > > Well, back to the original topic, what we need to be concerned with for > policy is not the relationship between bandwidth supply and demand, but > the relationship between the growth of the BGP routing table and the > growth of FIBs to accommodate it. ?It appears to me that we're doing OK I think, to be really clear there are two problems, one tends (today) to track with the other though: 1) size of FIB (in general you can find a way to scale the RIB since that happens on the much cheaper part of almost all core routers) 2) speed of change of the FIB (RIB -> FIB convergence rate) FIB size means TCAM or SRAM size Speed of change is how quickly you can update, and often across a severely limited pathway, the FIB when a RIB change happens. Today you stay ahead of that change rate (mostly) and your device's view of the world is 'converged'. Tomorrow if that change rate is higher than you can keep up with you will never converge. > there: router growth seems to be mostly keeping ahead of table growth. > As long as we don't dramatically increase the rate of growth of the > routing table, I think we're ok. ?And AFAICT none of the policy See the note about change rate, if the current change rate (for example) 10%/second == 35k changes/second and the pathway you can make these across can only support 50k/second. You need to be sure that growth rates won't get you to 500k prefixes before your next upgrade cycle. Also, it'd be nice if the vendor you choose for that upgrade didn't keep their current 50k rate-limited pathway intact. -Chris From michael.dillon at bt.com Wed Dec 23 03:28:36 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 23 Dec 2009 08:28:36 -0000 Subject: [arin-ppml] efficient utilization != needs basis In-Reply-To: <4B3100C4.2040901@umn.edu> Message-ID: <28E139F46D45AF49A31950F88C497458049FD288@E03MVZ2-UKDY.domain1.systemhost.net> > Some examples are; Smart Grids, emergency response networks, > and one that has been functioning from more that a decade is > the Automotive Network Exchange (ANX). ANX is a "community of interest network". There are others. For instance, SITA operates one for the global air transport industry and my employer operates one for the global financial services industry. > Why do these need globally unique addressing? > Globally unique addresses really make thing like the ANX much > easier, and there are many other private inter-AS networks > that exist today and I only see more and more in the future. Things like ANX, SITA's network and the BT Radianz Shared Market Infrastructure, are all internetworks. Just like the public Internet, these private internets interconnect multiple independent networks. Just like on the public Internet, these internets have their own peering with many ASes. Globally unique registered addresses are essential to manage the complexity of these networks. > These all have different challenges and I bring them up in > this context > because they all also have "operational need" and as we to > define a "needs basis" for IPv6, we must find a definition > that encompasses the "operational needs" of these other internets too. Even RFC 2050 recognizes this type of operational need in section 3 a) the organization has no intention of connecting to the Internet-either now or in the future-but it still requires a globally unique IP address. The organization should consider using reserved addresses from RFC1918. If it is determined this is not possible, they can be issued unique (if not Internet routable) IP addresses. The fact is that when you have multiple independent organizations interconnecting their networks, it doesn't matter whether it is the public Internet or a private internet that does the interconnection, RFC1918 addressing is simply not possible. The addresses in RFC1918 were allocated for "private network" use, meaning for use in networks which do NOT INTERCONNECT with other networks. I think that when people talk about needs basis they are conflating operational need for a unique globally registered range, with the justified quantity of addresses that are needed. Certainly in IPv6, we focus on operational need, i.e. if you have a unique site, then your operational need justifies a /48 assignment from your ISP. But at the higher levels, we still evaluate the justified quantity of address space when making allocations to ISPs. --Michael Dillon From michael.dillon at bt.com Wed Dec 23 03:37:18 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 23 Dec 2009 08:37:18 -0000 Subject: [arin-ppml] Policy Proposal 105: Simplified M&A transfer policy In-Reply-To: <4B311E63.9040103@arin.net> Message-ID: <28E139F46D45AF49A31950F88C497458049FD2A5@E03MVZ2-UKDY.domain1.systemhost.net> > 8.2. Mergers and Acquisitions > > ARIN will consider requests for the transfer of number > resources in the case of properly documented mergers and > acquisitions. ARIN will maintain an up-to-date list of > acceptable types of documentation. > > In the event that number resources of the acquired/merged > organization(s) are no longer efficiently utilized at the > time ARIN becomes aware of the transaction, through a > transfer request or otherwise, ARIN will work with the > resource holder(s) to return or aggregate resources as > appropriate via the processes outlined in sections 4.6, 4.7, > or 12 of the NRPM. This is a positive move which will ensure that ARIN's policy does not put a barrier in the way of M&A activity. After IPv4 runout, we can expect an increase in the number of acquisitions as ISPs which had prepared for IPv6 buy out failing companies which did not prepare. This simpler policy should also make it easier for ARIN staff to deal with the volume of transfers that take place. --Michael Dillon From michael.dillon at bt.com Wed Dec 23 03:58:52 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 23 Dec 2009 08:58:52 -0000 Subject: [arin-ppml] efficient utilization != needs basis In-Reply-To: <4B31357A.8090003@umn.edu> Message-ID: <28E139F46D45AF49A31950F88C497458049FD2CE@E03MVZ2-UKDY.domain1.systemhost.net> > Please note I am not saying they are not routable, they are > most assuredly intended to be routed within an Autonomous > System or even within a small set of Autonomous Systems. This small set can be as much as several hundred ASNs. > But, that they are not intended to be routed across the > entire hierarchically routed global Internet. In other > words, by default the normal expected behavior for a network > operator is to not route these across an Autonomous System > boundary without special arrangements. That is an odd way of putting it. These blocks are intended to be routed across ASN boundaries but the network operator typically maintains separacy between their public Internet infrastructure and the COIN (Community of Interest Network) infrastructure. Even the automotive industry, which does not have the same security needs as air transport or finance, requires the ISPs to use a separate infrastructure for ANX traffic. Let's put it this way, if company A is a member of a COIN supplied by ISP B, the Company A will buy a separate circuit from ISP B to supply Internet access. The COIN does not meet the Internet except internally in the member company networks where there are usually strict controls in place including routing, firewalls, edge ACLS to make sure traffic does not leak onto the wrong network. COIN IP address blocks are indeed routed across the entire hierarchically routed global internetwork of the COIN. > But because they have an intended scope that is meant to > encompass multiple Autonomous Systems I believe that use of > IPv6 Global Unicast addresses are appropriate. Yes. > So, a question I have for you and something I'm not 100% > decided on would ULA-Central or ULA-Global be an acceptable > alternative? I suspect that the only acceptable alternative would be one in which the IETF recognizes the existence of multiple global internets, not just the one with the big I, and sets aside special Global Unicast prefixes for these COINs. And to get there, at minimum they would have to get the agreement of the air transport folks, the automotive folks and the global financial industry folks. It seems easier to just use ordinary global unicast. --Michael Dillon From scottleibrand at gmail.com Wed Dec 23 04:05:59 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Dec 2009 01:05:59 -0800 Subject: [arin-ppml] Simplified IPv6 policy Message-ID: Here's an attempt at how we might simplify IPv6 policy, incorporating many of the ideas we've discussed recently. It's much simpler than current policy, but is still quite long. It's also late, so I reserve the right to make mistakes, and to disagree with myself later. :-) Delete "6.1 Introduction" This is all historical. Delete "6.2 Definitions" The definitions we need are all defined in section 2. Leave 6.3 as is (renumber to 6.1) I think these still accurately reflect the Goals we want our policy to follow. Move 6.4.1 to 1.1. Retitle to "Number resources not to be considered property" and update text per below. This is a principle more general than just IPv6, and needs to be updated to be ARIN-specific and refer to the RSA. Delete 6.4.2 - 6.4.4 These principles don't seem worthy of elevation to special status. Replace 6.5 Policies for allocations and assignments with text below (renumber to 6.2) This seems to be where most of the changes and simplification are needed. Delete 6.6 References This is all historical, and doesn't need to be part of the NRPM. Delete 6.7 Appendix A: HD-Ratio As above, we can let the HD-Ratio guide policy without making people do the math. Delete 6.8. Appendix B: Background information This is all historical Move 6.9 and 6.10 into 6.2.3.2 below Replacement text: 1.1. Number resources not to be considered property It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property. The policies in this document are based upon the understanding that globally-unique number resources are licensed for use rather than owned. Specifically, IP addresses and ASNs will be allocated and assigned on a license basis, with licenses subject to renewal on a periodic basis. The granting of a license is subject to specific conditions applied at the start or renewal of the license, as definied in the ARIN Registration Services Agreement. Note that when a license is renewed, the new license will be evaluated under and governed by the applicable number resource policies in place at the time of renewal, which may differ from the policy in place at the time of the original allocation or assignment. 6.2. Policies for IPv6 allocations and assignments 6.2.1. Allocations and assignments To meet the goal of Fairness, ARIN makes both allocations and assignments according to common criteria. Allocations are made to LIRs, and assignments to certain end users. 6.2.2. Assignments from LIRs/ISPs End-users are assigned an end site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): * /64 when it is known that one and only one subnet is needed * /56 for small sites, those expected to need only a few subnets over the next 5 years. * /48 for larger sites For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation. ARIN is not concerned about which address size an LIR/ISP actually assigns. Accordingly, ARIN will not request the detailed information on IPv6 user networks as in IPv4, except for the purpose of measuring utilization as defined in this document. 6.2.3. Allocations and assignments from ARIN 6.2.3.1 Goals To balance the goals of Aggregation, Conservation, Fairness, and Minimized Overhead, ARIN normally makes allocations only in the discrete sizes of /48, /40, /32, /28, or /24 or larger. Each organization or discrete network may qualify for one allocation or assignment of each size, and must pay fees according to ARIN's fee schedule for each size assigned. 6.2.3.2 X-Small (/48) To qualify for a /48 allocation or assignment, an organization must: * Serve at least 500 hosts, if multihomed; or * Serve at least 1000 hosts; or * Demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA; or * Be a critical infrastructure provider of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA; or * Qualify for a Micro-allocations for Internal Infrastructure per 6.3.3.2.2. 6.2.3.2.1 Critical Infrastructure Organizations qualified as critical infrastructure providers may be granted multiple /48 allocations in certain situations. Exchange point allocations MUST be allocated from specific blocks reserved only for this purpose. All other micro-allocations WILL be allocated out of other blocks reserved for micro-allocation purposes. ARIN will make a list of these blocks publicly available. Exchange point operators must provide justification for the allocation, including: connection policy, location, other participants (minimum of two total), ASN, and contact information. ISPs and other organizations receiving these micro-allocations will be charged under the ISP fee schedule, while end-users will be charged under the fee schedule for end-users. This policy does not preclude exchange point operators from requesting address space under other policies. 6.2.3.2.2 Micro-allocations for Internal Infrastructure Organizations that currently hold IPv6 allocations may apply for a /48 micro-allocation for internal infrastructure. Applicant must provide technical justification indicating why a separate non-routed block is required. Justification must include why a sub-allocation of currently held IP space cannot be utilized. Internal infrastructure allocations must be allocated from specific blocks reserved only for this purpose. 6.2.3.3 Small (/40) To qualify for a /40 allocation or assignment, an organization must qualify for two or more /48s. 6.2.3.4 Medium (/32) To qualify for a /32 allocation or assignment, an organization must: * Qualify for 100 or more /48s; or * Be an existing, known LIR; or * Have a plan to provide IPv6 connectivity to other organizations and assign at least 100 end-site assignments to those organizations within 5 years. 6.2.3.5 Large (/28) To qualify for a /28, an organization must demonstrate the need to make assignments and/or reallocations equal to at least 20,000 /48s. 6.2.3.6 X-Large (/24 or larger) Allocations or assignments of /24 or larger may be made only in exceptional cases, to organizations that require more than a /28, and have submitted documentation that reasonably justifies the request. If approved, the allocation size will be based on the number of existing users and the extent of the organization's infrastructure. 6.3. Registration When an organization holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate (information registered by ARIN may be replaced by a distributed database for registering address management information in future). Information is registered in units of assigned /56 networks. When more than a /56 is assigned to an organization, the assigning organization is responsible for ensuring that the address space is registered in an ARIN database. IRs shall maintain systems and practices that protect the security of personal and commercial information that is used in request evaluation, but which is not required for public registration. 6.3.1. Residential Customer Privacy (2003-3) 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. 6.3.2. Reverse lookup When ARIN delegates IPv6 address space to an organization, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organization should properly manage its reverse lookup zone. When making an address assignment, the organization must delegate to an assignee organization, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address. Thoughts? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Dec 23 04:28:23 2009 From: bill at herrin.us (William Herrin) Date: Wed, 23 Dec 2009 04:28:23 -0500 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: References: Message-ID: <3c3e3fca0912230128p523a6e69q7e89b7821a76ea28@mail.gmail.com> On Wed, Dec 23, 2009 at 4:05 AM, Scott Leibrand wrote: > Here's an attempt at how we might simplify IPv6 policy, incorporating many > of the ideas we've discussed recently.? It's much simpler than current > policy, but is still quite long.? It's also late, so I reserve the right to > make mistakes, and to disagree with myself later.? :-) Hi Scott, I think your thoughts here would be a major improvement to IPv6 policy. Not as good as 103 (naturally!) but nevertheless a major improvement. One serious problem jumps out at me: > 6.2.3.2? X-Small (/48) > To qualify for a /48 allocation or assignment, an organization must: > ?? * Serve at least 500 hosts, if multihomed; or > ?? * Serve at least 1000 hosts; or > ?? * Demonstrate efficient utilization of all direct IPv4 assignments and > allocations, each of which must be covered by any current ARIN RSA; or > ?? * Be a critical infrastructure provider of the Internet, including public > exchange points, core DNS service providers (e.g. ICANN-sanctioned root, > gTLD, and ccTLD operators) as well as the RIRs and IANA; or > ?? * Qualify for a Micro-allocations for Internal Infrastructure per > 6.3.3.2.2. > > 6.2.3.2.1 Critical Infrastructure > Organizations qualified as critical infrastructure providers may be granted > multiple /48 allocations in certain situations.? Exchange point allocations > MUST be allocated from specific blocks reserved only for this purpose. All > other micro-allocations WILL be allocated out of other blocks reserved for > micro-allocation purposes. ARIN will make a list of these blocks publicly > available. Exchange point operators must provide justification for the > allocation, including: connection policy, location, other participants > (minimum of two total), ASN, and contact information. ISPs and other > organizations receiving these micro-allocations will be charged under the > ISP fee schedule, while end-users will be charged under the fee schedule for > end-users. This policy does not preclude exchange point operators from > requesting address space under other policies. IMO, this is faulty. When you get this part right, you won't have to carve out an exception for Internet-Critical Infrastructure because it'll fit naturally with all the other low-server-count facilities of sufficient value. Like the ones that today multihome a few servers with an IPv4 /24 justified because they're multihomed. I'll read it more carefully later and offer additional comments. This was the one that jumped out at me. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Wed Dec 23 05:53:22 2009 From: bill at herrin.us (William Herrin) Date: Wed, 23 Dec 2009 05:53:22 -0500 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: References: Message-ID: <3c3e3fca0912230253x78027638l82bc102aee544edc@mail.gmail.com> On Wed, Dec 23, 2009 at 4:05 AM, Scott Leibrand wrote: > Here's an attempt at how we might simplify IPv6 policy, incorporating many > of the ideas we've discussed recently.? It's much simpler than current > policy, but is still quite long.? It's also late, so I reserve the right to > make mistakes, and to disagree with myself later.? :-) Hi Scott, I think your proposal offers a major improvement on existing IPv6 policy. Problems addressed by your proposal: * Enables effective TE filtering where ISPs determine that disaggregate TE is undesirable. * Unifies ISP/end-user policy so that all organizations are treated fairly Problems not resolved by your proposal: * Offers no IPv6 replacement for organizations with small but valuable server infrastructures which today multihome with either a legacy address block or a /24 ISP cutout. * Retains ARIN as the gatekeeper for Internet routing policy. ISPs must accept and route all allocations, even the x-small ones, or they'll lose access to critical infrastructure. Some specific comments inline: > > Delete "6.1 Introduction" > This is all historical. > > Delete "6.2 Definitions" > The definitions we need are all defined in section 2. > > Leave 6.3 as is (renumber to 6.1) > I think these still accurately reflect the Goals we want our policy to > follow. Try to avoid renumbering sections. Many volumes of googleable verbiage have been written which refer to ARIN policy by section number. These often-useful documents can become incomprehensible when the referenced policy number suddenly contains something entirely different. > Move 6.4.1 to 1.1.? Retitle to "Number resources not to be considered > property" and update text per below. > This is a principle more general than just IPv6, and needs to be updated to > be ARIN-specific and refer to the RSA. > > Delete 6.4.2 - 6.4.4 > These principles don't seem worthy of elevation to special status. > > Replace 6.5 Policies for allocations and assignments with text below > (renumber to 6.2) > This seems to be where most of the changes and simplification are needed. > > Delete 6.6 References > This is all historical, and doesn't need to be part of the NRPM. > > Delete 6.7 Appendix A: HD-Ratio > As above, we can let the HD-Ratio guide policy without making people do the > math. > > Delete 6.8. Appendix B: Background information > This is all historical > > Move 6.9 and 6.10 into 6.2.3.2 below > > > > > Replacement text: > > 1.1.? Number resources not to be considered property > > It is contrary to the goals of this document and is not in the interests of > the Internet community as a whole for address space to be considered > freehold property. > > The policies in this document are based upon the understanding that > globally-unique number resources are licensed for use rather than owned. > Specifically, IP addresses and ASNs will be allocated and assigned on a > license basis, with licenses subject to renewal on a periodic basis. The > granting of a license is subject to specific conditions applied at the start > or renewal of the license, as definied in the ARIN Registration Services > Agreement. > > Note that when a license is renewed, the new license will be evaluated under > and governed by the applicable number resource policies in place at the time > of renewal, which may differ from the policy in place at the time of the > original allocation or assignment. Good or bad, I'm not sure 1.1 is germane to the rest of the proposal. Can it be left out without impacting the rest or does it change something crucial? > 6.2.? Policies for IPv6 allocations and assignments > > 6.2.1.? Allocations and assignments > To meet the goal of Fairness, ARIN makes both allocations and assignments > according to common criteria.? Allocations are made to LIRs, and assignments > to certain end users. In a policy designed to enable disaggregate filtering, the distinction between a LIR and an ISP is not technologically sound. There are no LIRs who allocate or assign addresses to entities they don't also supply Internet service to. I suggest replacing all instances of LIR with ISP. > 6.2.2.? Assignments from LIRs/ISPs > End-users are assigned an end site assignment from their LIR or ISP. The > exact size of the assignment is a local decision for the LIR or ISP to make, > using a minimum value of a /64 (when only one subnet is anticipated for the > end site) up to the normal maximum of /48, except in cases of extra large > end sites where a larger assignment can be justified. > > The following guidelines may be useful (but they are only guidelines): > > ?? * /64 when it is known that one and only one subnet is needed > ?? * /56 for small sites, those expected to need only a few subnets over the > next 5 years. > ?? * /48 for larger sites > > For end sites to whom reverse DNS will be delegated, the LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to simplify > reverse lookup delegation. > > ARIN is not concerned about which address size an LIR/ISP actually assigns. > Accordingly, ARIN will not request the detailed information on IPv6 user > networks as in IPv4, except for the purpose of measuring utilization as > defined in this document. > > 6.2.3. Allocations and assignments from ARIN > > 6.2.3.1? Goals > To balance the goals of Aggregation, Conservation, Fairness, and Minimized > Overhead, ARIN normally makes allocations only in the discrete sizes of /48, > /40, /32, /28, or /24 or larger.? Each organization or discrete network may > qualify for one allocation or assignment of each size, and must pay fees > according to ARIN's href="https://www.arin.net/fees/fee_schedule.html">fee schedule > for each size assigned. Good. > 6.2.3.2? X-Small (/48) > To qualify for a /48 allocation or assignment, an organization must: > ?? * Serve at least 500 hosts, if multihomed; or > ?? * Serve at least 1000 hosts; or IPv6 addressing is LAN-centric rather than host-centric. Accordingly I suggest expressing this in terms of a number of LANs served. Perhaps 50 or 100 LANs instead of 500 or 1000 hosts? > ?? * Demonstrate efficient utilization of all direct IPv4 assignments and > allocations, each of which must be covered by any current ARIN RSA; or > ?? * Be a critical infrastructure provider of the Internet, including public > exchange points, core DNS service providers (e.g. ICANN-sanctioned root, > gTLD, and ccTLD operators) as well as the RIRs and IANA; or > ?? * Qualify for a Micro-allocations for Internal Infrastructure per > 6.3.3.2.2. > > 6.2.3.2.1 Critical Infrastructure > Organizations qualified as critical infrastructure providers may be granted > multiple /48 allocations in certain situations.? Exchange point allocations > MUST be allocated from specific blocks reserved only for this purpose. All > other micro-allocations WILL be allocated out of other blocks reserved for > micro-allocation purposes. ARIN will make a list of these blocks publicly > available. Exchange point operators must provide justification for the > allocation, including: connection policy, location, other participants > (minimum of two total), ASN, and contact information. ISPs and other > organizations receiving these micro-allocations will be charged under the > ISP fee schedule, while end-users will be charged under the fee schedule for > end-users. This policy does not preclude exchange point operators from > requesting address space under other policies. At work I operate a ground station for a satellite constellation. The non-IP satellite devices deliver messages to the ground station which disperses them via the Internet. This very high value application uses 5 T1s from 5 different ISPs, a 100 meg ISP link and a 100 meg peering link. It uses only a few score hosts and a handful of LANs. I use an ARIN AS# to announce an IPv4 /24 cutout from an ISP block via BGP on all the ISP and peering links. Because it's multihomed, this is in full compliance with ARIN policy. Because it's impractical to filter announcements /24 and shorter, it works great. How do I get usable IPv6 addresses? > 6.2.3.2.2 Micro-allocations for Internal Infrastructure > Organizations that currently hold IPv6 allocations may apply for a /48 > micro-allocation for internal infrastructure. Applicant must provide > technical justification indicating why a separate non-routed block is > required. Justification must include why a sub-allocation of currently held > IP space cannot be utilized. Internal infrastructure allocations must be > allocated from specific blocks reserved only for this purpose. > > 6.2.3.3? Small (/40) > To qualify for a /40 allocation or assignment, an organization must qualify > for two or more /48s. > > 6.2.3.4? Medium (/32) > To qualify for a /32 allocation or assignment, an organization must: > ?? * Qualify for 100 or more /48s; or > ?? * Be an existing, known LIR; or > ?? * Have a plan to provide IPv6 connectivity to other organizations and > assign at least 100 end-site assignments to those organizations within 5 > years. > > 6.2.3.5? Large (/28) > To qualify for a /28, an organization must demonstrate the need to make > assignments and/or reallocations equal to at least 20,000 /48s. Why not demonstrate that they -have made- at least 20,000 /48 assignments from their /32? > 6.2.3.6? X-Large (/24 or larger) > Allocations or assignments of /24 or larger may be made only in exceptional > cases, to organizations that require more than a /28, and have submitted > documentation that reasonably justifies the request. If approved, the > allocation size will be based on the number of existing users and the extent > of the organization's infrastructure. > > 6.3. Registration > > When an organization holding an IPv6 address allocation makes IPv6 address > assignments, it must register assignment information in a database, > accessible by RIRs as appropriate (information registered by ARIN may be > replaced by a distributed database for registering address management > information in future). Information is registered in units of assigned /56 > networks. When more than a /56 is assigned to an organization, the assigning > organization is responsible for ensuring that the address space is > registered in an ARIN database. Might want to put some verbiage here about assignments/reallocations to legal entities other than the registrant so that you don't have to register internal assignments for the printer LAN. > IRs shall maintain systems and practices that protect the security of > personal and commercial information that is used in request evaluation, but > which is not required for public registration. > > 6.3.1. Residential Customer Privacy (2003-3) > > 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. Is residential privacy already in effect? If not, it probably isn't germane to the rest of the policy proposal. Potentially valuable but better off in a separate proposal. > 6.3.2. Reverse lookup > > When ARIN delegates IPv6 address space to an organization, it also delegates > the responsibility to manage the reverse lookup zone that corresponds to the > allocated IPv6 address space. Each organization should properly manage its > reverse lookup zone. When making an address assignment, the organization > must delegate to an assignee organization, upon request, the responsibility > to manage the reverse lookup zone that corresponds to the assigned address. That would be totally sweet if ISPs were required to delegate RNDS to the customers on request. I have a long-running argument with Cox on the subject. But is this really ARIN's job? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rw at firstpr.com.au Wed Dec 23 07:15:39 2009 From: rw at firstpr.com.au (Robin Whittle) Date: Wed, 23 Dec 2009 23:15:39 +1100 Subject: [arin-ppml] Modified Header Forwarding for scalable routing In-Reply-To: <67499163-2A2C-4565-9F39-7A23FD55DEDF@delong.com> References: <4B2AD4A0.6080908@firstpr.com.au> <20091218020045.GA24163@ussenterprise.ufp.org> <4B2B4976.2070302@firstpr.com.au> <20091218155153.GA78343@ussenterprise.ufp.org> <4B2C68D8.7020006@firstpr.com.au> <20091219061711.GB34678@ussenterprise.ufp.org> <4B2C8202.1050204@firstpr.com.au> <4B2E08C4.7020004@firstpr.com.au> <67499163-2A2C-4565-9F39-7A23FD55DEDF@delong.com> Message-ID: <4B3209EB.9000400@firstpr.com.au> Owen replied to me offlist, but with his permission I am responding on-list. I am trying to understand and critique his proposal - and contrast it with my two proposals. Hi Owen, Thanks for your reply, which is here in full, but with parts of the my message deleted. >>> Currently, we make those decisions based on the IP prefix, thus overloading >>> the IP addresses task as an end-system identifier with additional topological >>> locator semantics. >> >> Another way of saying this is that the IDR (Inter Domain Routing) >> system can only use the same bits, or a subset of the same bits, for >> forwarding each packet as we use for identifying hosts for >> host-to-host communications. > > No, that says something different. OK. > My point is that the two uses of IP addresses (end system identifier which > wants to be long duration in nature and possibly transitory with regard to > topology, such as when a business changes one or more ISPs, and topological > locator, which works best when there is a single topological locator for each > given unique zone of network administrative control, e.g. autonomous system). However we say it, I think we agree that expecting all DFZ routers to use the IP address, as currently used to identify hosts and sessions, is not scalable when large numbers of end-user networks want their own space which is portable and suitable for multihoming. >> I think that both the IPv4 and IPv6 headers could be modified to >> contain an ASN. > > Sure, but, I don't think it's necessarily worth doing for IPv4. OK. I am working on both - and I think there's a real scaling problem in IPv4 today, with it being difficult to get portable, multihomable space, and with the only approaches to multihoming both burdening the entire DFZ and only working for 256 or more IP addresses. I think this /24 chunk approach to multihoming and portability is probably driving address depletion - assuming many networks which want these things could also get by fine with less than 256 IPv4 addresses. >> I understand from this that you are suggesting that packets would be >> emitted normally by sending hosts, but that they would all be >> processed by something resembling an ITR (Ingress Tunnel Router) of >> the core-edge separation schemes (LISP, APT, Ivip and TRRP). This >> ITR function would be in the sending host or be in a router in the >> ISP or end-user network where the sending host is located. The ITR >> function could also be out in the DFZ: a router advertising prefixes >> which match the unmodified packets' destination address. (This is >> Ivip's Open ITR in the DFZ - OITRD - or LISP's "Proxy Tunnel Router".) > > Correct. > >> In all cases, the ITR would alter the format of the packet header in >> a way that suitably modified routers in the DFZ (and also in ISP and >> end-user networks, if the ITR function was within those networks, or >> in the sending hosts) would forward the packet according to this new >> information. > > Correct. > >> At some point, the modification would have to be reversed, to >> reconstitute the packet ready for the destination host. In core-edge >> separation schemes, decapsulation is done by an ETR (Egress Tunnel >> Router). The ETR needs to be at some point in the destination ISP or >> end-user network where the packet in its original form will be >> forwarded to its proper destination - not to an ITR which would >> modify it again. > > Yes, when it reaches the destination ASN or the first router that needs > to forward it to a router which has not passed this capability as a > negotiated feature in it's neighborship in BGP was my thinking > on the decapsulation point. > >> Maybe it would be good enough to use the ASN directly, since a large >> network, or a network with multiple topologically diverse border >> routers would use the same ASN for all those border routers and >> assuming the ASN is happy to accept incoming traffic for any of its >> internal destinations on any of its BRs. > > Correct... That is my thinking. > >> However, it would be possible to extend your proposal to use a >> different number than the ASN to control the forwarding of the packet. > > Sure, it's possible, but, that would require information that is not currently > available in BGP4. Yes, but my aim is to do it at an ITR, which is not necessarily connected with the BGP DFZ, and while also allowing a reduction in the number of routes in the DFZ. > OTOH, the AS-PATH/next-hop data already present > in BGP4 would allow an ASN-Based FIB to be constructed from the > existing RIB without modification to the wire protocol for BGP4. Yes - I think the router would look at the path of the prefix and use only the last ASN. > Routers participating in this type of forwarding and understanding > these new format packs would pass this capability as a negotiated > feature much like 32-bit ASN capability today. I find this interesting: converting subsets of the DFZ to handle a modified header scalable routing system, which means not necessarily requiring all DFZ routers to be upgraded before the system can be used. >> What you are suggesting is something like a core-edge separation >> scheme - but maybe it is something different, since within the core, >> you are forwarding packets according to an ASN number which is added >> to the packet somewhere. ASN is a different namespace from IP >> address, whereas core-edge separation schemes keep the one namespace >> (IP addresses) and use one subset for scalable end-user network space >> ("edge" addresses) and retain the rest as "core" addresses, for ISPs >> and end-user networks with conventional PI space. > > Correct. The problem I see with the other core-edge separation schemes > is: > 1. The encapsulation is much higher overhead since you are adding > a lot more data to each packet, and, it's essentially a full tunneling > implementation. Mine is much lighter weight, along the lines > of ATM encapsulation without the limitation of the small cell > size. Its lighter-weight than ATM, MPLS or any kind of IP encapsulation - since the packet doesn't get any longer. It is zero weight! > 2. The routing semantics for people attempting to debug routing > problems become much more complex in the other schemes. > With my stuff the ASN in the packet and forward on that where > you can scheme, you have the following advantages: > > 1. Can be deployed incrementally > 2. The routing semantics remain largely the same and the > FIB is computed from the same existing RIB. > 3. The same commands we use for debugging today still > give you the same information you need. (mostly) OK - I will concentrate on trying to understand and critique your scheme, but I agree debugging is an important issue. >> Your proposal is not exactly a core-edge elimination scheme - since >> they tend to change the hosts so the applications address hosts by >> one kind of address ("edge") and the hosts are physically accessed by >> another kind "core", with the routing system operating much as it >> does today, forwarding according to destination address, where this >> is of the physical address of the host ("core" address AKA "locator") >> and is unrelated to its logical application level address ("edge" AKA >> "identifier"). > > Correct. > >> Anyway, as I understand it, your proposal needs some things >> resembling ITRs, which accept traffic packets with certain ranges of >> destination addresses (that of the "edge" subset of all IP addresses) >> and do something to the packet to get them to an appropriate ETR (or >> whatever it is which converts the packet to its original form) near >> the destination end-user network. This involves a "mapping lookup" >> to produce something which will enable the packet to be forwarded to >> the ETR. > > Correct, although there is no reason the "certain range" could not be ::/0. OK - here is a big difference between a core-edge separation scheme and your scheme: In a core-edge separation scheme, one subset of the address range is given the new title "edge" - I call it "Scalable PI" (SPI). This is for end-user networks only and is portable, multihomable and usable for inbound TE on a scalable basis. Therefore it works very differently from the currently only approach to this: advertising each end-user network prefix in the DFZ. In practice, with Ivip at least, this subset would include many prefixes scattered through the unicast address space. Within each such prefix, there would be the SPI address space used by many end-user networks. With Ivip, the space can be divided down into ranges of any number of IPv4 addresses or IPv6 /64s, so each separately mapped range is not necessarily a binary boundary prefix. The rest of the address remains as it is, and is known as "core" address space. The ITRs only encapsulate packets whose destination address matches one of the prefixes in the SPI subset. They tunnel these packets to ETRs, which always have "core" addresses. In your scheme, parts of the DFZ and ultimately the whole DFZ change in the way they handle all packets. There is no concept of "core" or "edge". I assumed there was this distinction because I assumed you were trying to reduce the number of routes in the RIB of DFZ routers. But as you write below, this is not the case - except perhaps after complete adoption. So your scheme is an overall change to the DFZ which alters the current functionality of routers forwarding packets to specific BRs - the ones which advertise the prefix. Instead, the packets are forwarded to the BR of the ASN which the one or more advertising BRs are a part of. As you write below, "ASN" does not mean "ISP" - an ASN could be a subset of the ISP's network. >> With LISP, APT, Ivip and TRRP, the mapping lookup produces an ETR >> address, and the packet is encapsulated so it is tunneled to the ETR. >> >> In your proposal, the mapping produces an ASN of the ISP which the >> destination network is connected to. The DFZ forwards the packet to >> the correct ASN - to any border router of that ASN, typically the >> "closest" (in terms of how the DFZ routers choose their paths). > > The mapping lookup would, in my thinking, produce one or more > destination ASNs, possibly with preferences, ala MX records. OK - so you anticipate the ITR (or whatever you call the device which alters the format to the new one, putting an ASN in the header) would somehow obtain mapping which gave it either one ASN, or multiple ASNs with priorities. Because you anticipate separate parts of the DFZ being converted to your system, these "ITRs" would frequently be DFZ routers. Perhaps every "ITR" would be a DFZ router. I guess the "mapping" information would be derived directly from what the "ITR" device already has at hand via BGP. For instance, if the router received two paths for a given prefix, each ending in a different ASN, then the mapping would contain the two ASNs, with there being some algorithm for deciding the priorities of each. How would the ITR function decide which ASN to use when there were more than one in the mapping? In LISP, APT and TRRP - and any other core-edge separation schemes I know of apart from Ivip - the ITR gets a prioritized list of ETR addresses and tests reachability to the highest priority one. If that is not reachable, it tunnels packets to the next highest priority one which it is able to reach. (I think this is very messy - Ivip ITRs get a single ETR address and always tunnel to that.) But your "ITR" function doesn't get from the mapping information an IP address to tunnel packets to - it gets one or more ASNs. The BGP information in the DFZ router may have multiple paths for a prefix, with various ASNs and with different BRs within the one ASN. But that doesn't help your system at all, I think, since you are not deciding which BR to send the packets too - just which ASN. I can't think of a way your "ITR" function could predict exactly which BR of the ASN the packet would be forwarded to, so I can't think of how you could test reachability to any one BR, or to the ASN in general. > The rest is generally correct, with the caveat that along the way > the packet may be reverted to prefix forwarding and then > re-encapsulated again as it traverses areas of capable and > non-capable router peerings. OK - I hadn't anticipated this when I replied to you. Your plan involves some DFZ routers accepting an ordinary packet and performing what I call an "ITR" function on it. However that term is for tunnelling to a specific end-point. In your system this router changes the header format to contain an ASN, and then forwards it to a neighbour which has previously been determined as being the best path towards any BR of this ASN. The modified format packet may then be forwarded in the same way by the next DFZ router and it may be forwarded this way to the BR, which does the "ETR" function and turns the header back to a normal state. However, the packet may reach a DFZ router, which has been upgraded to handle your system, and that router decides one of: 1 - The next hop for the packet (based solely on the ASN in its header) is not a BR of that ASN. 2 - It is a BR of the ASN, but that this BR hasn't been upgraded to handle the modified packets. This can be determined by the BR's BGP messages to this DFZ router. 3 - The next hop router is not the BR of the ASN and has not been upgraded to handle the modified packets. In all three cases, the router now performs an "ETR" function: it restores the header to the normal state and then forwards the packet according to its conventional destination address FIB algorithm. So a packet could pass through one "island" of modified header forwarding, to a DFZ router which causes it to be forwarded normally, and then to one or more other islands before arriving at the BR. When it gets to the BR, it may be in ordinary form or modified header form. >> As I understand it, the effect of your proposal would be: >> >> 1 - If an ASN advertises a prefix on any one of its BRs, it >> must be prepared to accept packets matching this prefix >> on all of its BRs. >> >> I suspect this is not what any ISP wants - since it gives >> it no control over where incoming traffic arrives. But >> for the purpose of discussion, I will assume your scheme >> is desirable. > > Perhaps an ISP that wants that kind of control needs more than > one ASN. Many ISPs have multiple ASNs, so, let's talk about how > we define the term Autonomous System. You are using the term > above as synonymous with ISP. Let us instead state that an AS > is a collection of prefixes with a common routing policy. > > Thus, if you want different ingress rules for prefix A than for > prefix B, prefixes A and B should be in different Autonomous > systems. OK. This would probably lead to many ISPs wanting a significant number of ASNs. Maybe one router can advertise some routes with one ASN and some with another - I am not sure if BGP allows this. If not, then the ISP would face some tricky questions deciding how to partition all its BRs into one ASN or another. I can't see how either approach would be an improvement for ISPs over the current arrangement where a BR advertises a prefix and the DFZ forwards packets to that BR - or to as many BRs as advertise the same prefix. It seems your proposal would greatly reduce the ISP's control of which BR packets arrive at. > The gain here is that you have N FIB destinations where N is > the number of ingress policies rather than N*X FIB destinations > where N is the number of ingress policies and X is the average > number of prefixes represented in each policy. OK - in the modified routers IF you could do away with the conventional IP-address based FIB, then the ASN-based FIB would be simpler because there are a smaller number of ASNs than there are prefixes. (At least there is supposed to be - what if an ISP decided it wanted to retain its former level of control and therefore registered a separate ASN for each prefix, including each prefix it advertises of an end-user network?) > So, yes, this will require some TE users today to modify their > TE tactics, but, they should be able to preserve their strategy > with only minor modifications to the network for new tactics > at least in most cases I know of. I still don't see how your system would improve the inbound TE control when compared to the current arrangements. >> 2 - The DFZ routers wouldn't need a large FIB - at least for >> these modified packets, since the FIB wouldn't be dealing >> with the destination prefixes of these packets which are >> addressed to hosts in end-user networks with the new kind >> of scalable PI space. This new section of the FIB would >> only match ASNs, and for each ASN, the router would have one >> best path. >> >> So your proposal reduces FIB size, but makes it more complex. > > Actually,think it simplifies the FIB as well since the FIB really only > needs to contain the following now: > > ASN Next-Hop-IP Next-Hop-Interface (policy) > I'm curious where you see additional complexity. Yes - but that is only when the DFZ router doesn't need to forward packets according to their destination address. Until then, it needs its full IP-address based FIB plus the new ASN based one. I (and many other people) think that scalable routing proposals need to provide continual scaling benefits, in proportion to how much they are adopted - not just provide improvements once they are 100% adopted. In a fully adopted scheme, you may be able to get all DFZ routers using only an ASN FIB, but the "ITR-like" devices which modify the header need to do this at "wire-speed": in their FIBs. So you still need an FIB in the "ITR-like" devices which works from the destination IP address to determine whether to modify the header, and if so to what contain which ASN - according to some algorithm which has previously chosen which of potentially multiple prioritized ASNs to use. >> 3 - The DFZ routers may well be running BGP - but for these >> end-user network prefixes your scheme works for, it is not >> clear why. Maybe that's the benefit - these end-user >> network prefixes should not be advertised in the DFZ at >> all. In that case, you radically reduce the RIB size and >> so really do achieve routing scalability, since this is the >> main goal of current scalable routing proposals. >> >> However, see point 6. >> >> The DFZ routers would still have RIB and FIB entries for >> prefixes not of the scalable end-user PI type covered by >> your scheme. But this is scalable. > > You'd probably still have the full RIB, at least for quite some time. > Obviously, once this became ubiquitous, the EBGP RIB could > be reduced to AS Path information, but, that would be a long-term > savings, not something immediate and would require significant > changes to BGP and more coordination, but, could eventually > be achieved. But if the RIB only contains the ASN of the BR advertising the prefix, how could the router decide which path was shortest, if there were two or more paths from two or more neighbours for the same prefix, with the same ASN? Or if they were for different ASNs? This comes back to my question about how the "mapping" data could be made to include priorities. > BGP is preserved for two reasons. It's a convenient method for > distributing the AS PATH information (the new scalable PI > addresses for ESIs is the existing IPv6 address in my scheme, > btw). I don't understand the section in brackets - can you elaborate? Is this the ATM End System Address mentioned in RFC 2492? > Second, by preserving BGP as is, it should be possible > to allow this to be implemented as islands which eventually > grow until there is more land and the oceans become lakes, > then puddles, then non-existant as the code is upgraded to > support this new capability. OK - I can imagine how your islands would work. However, I wonder about potential routing loops. Maybe in an island the packet gets forwarded according to one algorithm, which causes it to leave the island, where another algorithm (the one currently used in the DFZ) decides its next path. Maybe that will put it back in the same island and the process will repeat. Also, I remain to be convinced that any ISP actually wants to degrade (in my view) the specificity of its incoming traffic control by having the DFZ forward packets to any BR in an ASN just because one BR in the ASN advertises the prefix. > Further, my understanding of the scaling limits is that the issue > is with TCAM (FIB only) much moreso than RAM (RIB+FIB), so, > I'm less worried bout shrinking the RIB. This is what I thought three years ago . . . Reading the RAWS material: http://tools.ietf.org/html/rfc4984 http://www.iab.org/about/workshops/routingandaddressing/ I thought that the FIB was the big problem, since it had to deal with every traffic packet, ideally in a fraction of a microsecond. I figured BGP and the RIB could cope with many more prefixes, since this was just non-traffic-related parleys between router CPUs, at a relaxed pace. I made a magnificent plan for IPv4 router FIBs to be made with high-speed static RAM to a resolution of /24 - and wrote it up as an Internet Draft. On the RAM list, which followed RAWS and preceded the current incarnation of the RRG, no-one was interested. I soon learned that the BGP control plane and the RIB functions of routers are the real problem in scalable routing. I believe that both the FIB and the RIB of all DFZ routers needs to be limited to the prefixes of ISPs and some or all currently advertising end-user networks, but not lots more. So if your scheme doesn't alter the RIB situation until there is a complete conversion in the DFZ, I don't think it would solve the scaling problem as well as other proposals. >> 4 - Each DFZ router needs to decide a best path to the "nearest" >> ideally (actually any one of them) BR of each ASN. This is >> a different task from what BGP is intended to achieve. I >> suppose if every BR advertised at least one conventional >> prefix, then you could extract from the RIB all the information >> you need and choose the apparently nearest path to a BR of >> each ASN, to write this to this new ASN section of the FIB. > > Let's look at this a little differently, because I believe it maps to todays > forwarding fairly well... > > Let's say that 2620:0:930::200:2/48 maps to ASN1734 > Now, let's say that your AS Paths for 1734 are: > 2958 59392 3921 591 392 701 9323 6939 1734 > 2394 9080 29348 270 892 3749 3948 238472 10565 1734 > 2348 29837 234 2342 83 283 234283 29384 23423 8121 1734 > > You decide, first, that the shortest AS PATH is the one starting 2958. > Next, you look up your immediate next hop for 2958, and, poof, > off it goes in that direction. > > Make sense? OK - that gives your FIB a single mapping result: a particular next hop neighbour router. What about priorities? The whole idea of an end-user network multihoming is to use two or more physical links and two or more separate ISPs. Then, the scalable routing system needs to respond quickly when ISP AAA disappears, or the link from AAA to the end-user site goes down (two totally different things, and the latter one may be hard to detect from an "ITR") so the packets are tunneled to ISP BBB instead. This needs to happen without changing any DFZ advertisements - and to achieve scalable routing in terms of RIB and the DFZ control plane, the end-user prefix can't be advertised in the DFZ anyway. I don't see how your scheme would respond in the short term to achieve multihoming failure restoration. You discuss this more below. >> 5 - The BRs of all these ASNs would need to recognise the modified >> header and reconstruct the packet so it will be forwarded to >> and recognised by the destination host. > > See above where I described advertising this capability in BGP > as a negotiated feature, like 32-bit ASNs. OK. >> 6 - But what of the "ITR" function - the router somewhere which >> modifies the packet header to install the ASN? >> >> In the current DFZ, this could be done by a suitably modified >> DFZ router. All DFZ routers know about all advertised prefixes >> and in the RIB you can easily see the ASN of the BR which >> advertised the prefix. >> > Maybe, but, not ideal in my opinion. > >> But I think a major goal of your proposal is to avoid all these >> scalable PI prefixes from being advertised in the DFZ (3 >> above). > > Correctttt. OK - then how does any DFZ router know about the end-user prefix in order to determine the ASN of the one or more BRs which advertise it? >> In that case, the "ITR" function can't be a DFZ router of the >> new kind. It has to look up a mapping database - either within >> itself or at some local or distant query server system. > > It can be a function of any DFZ router, but, we need to provide an > alternate means of mapping. Yes - because the prefixes won't be advertised in the DFZ. >> The mapping function accepts the packet's destination address >> and returns an ASN number. Before this, the "ITR" function >> needs to recognise whether it the destination address matches >> a conventionally advertised prefix. So I guess if the >> packet's destination address matches a prefix in the >> conventional IP address FIB, forward it that way. If not, >> look up the mapping function. If the mapping is to an ASN, >> modify the packet. If there is no such mapping, drop the >> packet. > > Sounds reasonable. OK - but now we are talking about a core-edge separation scheme, where the "ITR" or whatever has a conventional IP-address-based FIB, and when it finds a packet's destination address doesn't match any prefix in that FIB (which contains no SPI "edge" prefixes) then it uses the mapping function to see if the packet matches an SPI prefix - and if so what are the one or more ASNs with priorities, to consider forwarding it towards. >> So these "ITR" devices need to have a complete copy of the >> mapping database, or to be able to query something which >> has it and to cache the result in its "FIB", or whatever >> it uses to handle incoming packets. > > I was thinking the latter. OK - only LISP-NERD went so far as to put a full copy of the mapping database in each ITR. NERD is no longer being developed. APT and Ivip have local full-database query servers - local to the ISP or end-user network which contains the ITRs. LISP-ALT (and all the other LISP mapping approaches: CONS, DNS, DHT . . .) use a fully distributed, non-centralised, and therefore global system of mapping resolution. That leads to serious problem with the time it takes to get the mapping - so initial packets may be dropped or be so delayed they are more trouble than they are worth. LISP-ALT routers drop packets for which they have no mapping - and then send a map request. Once the map reply arrives, they put that in their cache and wait for the sending host to send another packet - which is then encapsulated immediately and tunneled to the ETR. (This doesn't count however the ITR tests which of multiple ETRs are reachable now . . .) >> So if your aim is to remove these prefixes from the DFZ, then >> your ITR-like devices do resemble an ITR of LISP, APT etc. >> in that there needs to be a global mapping database, which >> tells the ITRs how the prefixes of scalable end-user address >> space are moved from one ISP to another. > > Correct. OK - so then you don't need to rely on BGP at all. Yet you previously wrote that your scheme had the benefit that the DFZ routers already had the required information to decide which ASN to use, based on their BGP communications. Perhaps you mean use BGP during deployment and switch to a separate method when it is fully deployed. >> Then, you get into questions of multihoming service >> restoration. How does your system respond to an end-user >> network no longer being able to use the link from its ISP >> with ASN AAA, and needing its packets to be forwarded to >> another ISP with ASN BBB? > > Two possibilities: > > 1. Extension header field "Beenthere" where the AAA > ASN is appeneded and a lookup is performed to find > an additional candidate ASN, replace AAA in header, > forward towards BBB. I think this means the packet gets longer, adding to traffic loads and leading to Path MTU Discovery problems which are really tricky to solve. Extension headers are only for IPv6 anyway. > 2. Depend on updating the map quickly and dynamically. Welcome to the RRG debates! Most people assume it is not possible to do real-time (a few seconds) updates of mapping to ITRs. I think it is possible and more than desirable - I think it is the only proper way to do a core-edge separation scheme. So Ivip is currently the only proposal involving real-time mapping updates to local query servers, which push the changes (secured with a nonce from the map query) to the ITRs which requested the mapping and which would still be caching time the previously received mapping information. So Ivip's mapping consists of a single ETR address - and the ITR never has to test reachability to the ETR. > I think option 1 is more likely to work more often, but, they could > be combined. My Modified Header Forwarding approaches avoid using extension headers and, within the context of Ivip, the ITRs get changed mapping within seconds of whatever mechanism changes the mapping in response to TE needs, multihoming failure restoration or portability. The best place to discuss Ivip or my two Modified Header Forwarding approaches is the RRG, since this is one of the proposals which is being considered. >> If this changed requirement could be transferred to >> all your "ITR" devices in real-time, that would solve >> the problem pretty well. Ivip does it this way. The >> other core-edge separation schemes assume this is either >> impossible or undesirable. So the ITR gets mapping in the >> form of "send these packets to AAA, unless it is unreachable >> - in which case send them to BBB". Then the ITR has to >> do reachability testing and it gets very complex. Ivip >> ITRs are simpler. They do not test for reachability to ETRs. >> They only have one ETR address and the tunnel packets to that >> address. > > My favorite is somewhat of a hybrid... The map looks a lot like > an MX lookup receiving a set of candidates with optional preferences. > On possibilty is to include an "Encapsulating Router" IP in the > additional packet header fields so that if a re-mapping occurs, > the encapsulating router can be notified. I don't clearly understand this, but I think you may be considering a global distributed query server system such as LISP-ALT (or now several more RRG proposals) with some kind of secure update to the ITRs which requested the mapping. Global systems don't scale well, due to delay problems and considering how many ITRs might be requesting the mapping and needing to be informed in the event of a TE, multihoming or portability change. > By using the beenthere field I suggested above, we preserve loop > detection. But I think this means adding headers. >> If your ITR was like a current DFZ router, then it could >> find out about AAA being unreachable and BBB being the new >> ASN to forward the packets to, by allowing the current >> DFZ to propagate best paths to it. However, I think the >> main benefit of your scheme would be to avoid advertising >> all these end-user prefixes in the DFZ - so this won't >> work. > > Correct. In which case BGP couldn't be used and you would need either need a mapping system which worked to all ITRs in real-time (like Ivip) or you could use a slower mapping distribution system, with multiple options of ASNs or whatever to forward the packet to, and then require the ITR to choose between the options, such as by some reachability testing. That reachability testing takes time - and I think all the core-edge separation schemes apart from Ivip suffer from problems with ITRs finding it slow and expensive to test reachability - when the ITR is really supposed to forward all packets without delay. Without first testing, how can the ITR know which ETR address to use? >> I think that to be really useful for scaling, your >> scheme would need a separate (not BGP-based) mapping >> arrangement by which the ITR functions could quickly and >> reliably decide which ASN to forward the packets to. I think >> this requires some separate mapping system. > > Correct. OK. >> In the mapping systems of core-edge separation schemes, a subset of >> the IP address range returns a positive response from the mapping >> system. These are what I call the "Scalable PI" (SPI) addresses - >> that subset of the address range which is used by end-user networks >> for scalably getting address space which is portable and gives them >> multihoming and inbound TE. (This may also be thought of as the >> "edge" subset, or the "identifier" subset of the whole IP address >> range. This subset of the address space would be many separate >> prefixes scattered through the range. > > Sure, although in my scheme, there is no reason that subset could > not become the entire IP space. OK - so then it is not a core-edge separation scheme. Then, there's no need to advertise any prefixes in the DFZ, except perhaps just one prefix from each BR of an ASN, so the DFZ routers can determine paths to ASNs. This "skeleton set" of prefixes is the bare minimum which needs to be advertised in order that the DFZ routers can know paths to at least one BR of each ASN. Then, before the packets get to the DFZ, or at the first DFZ router, there is a mapping lookup and the packet's header is modified to contain an ASN. The rest of the DFZ routers forward it towards any BR of that ASN. >> The remainder are "core" (AKA "locator" or "RLOC" in LISP), since >> these core addresses continue to function as they do today, with all >> routers, including DFZ routers, using these addresses to forward >> packets all the way to their destination. Core addresses can still >> be used for end-user network PI space, but this is not scalable. > > In my scheme, the core locator space is a completely separate namespace, > so, duplicates (of sort) are possible. (e.g. AS1734 while numerically > comparable to 0::6c6, there is not really any overlap between them). OK - so your scheme is ultimately (once fully deployed) a core-edge elimination scheme: There is a whole new namespace for identifying where packets need to be forwarded to in the DFZ - AKA the "locator" address. This namespace is ASNs. Whereas other core-edge elimination schemes do this work at the host, and all routers then operate on the "locator" address, yours has the hosts behaving as they do now, sending and receiving packets with IP addresses ("edge" addresses). Some or all of the edge networks' routers also handle packets with IP addresses. Only when the packets traverse the core do you switch to the new core namespace for determining forwarding. The other core-edge elimination schemes do their work in the hosts for at least two reasons: 1 - To avoid new or changed functionality in the network - though they still need some kind of mapping system to securely find out the current locator address for a host with a given edge ("identifier") address. 2 - To enable the hosts to respond quickly when one or the other or both change their physical location - likewise without having to alter the operation of any routers in the network itself. On this basis, I think your scheme, once fully deployed, would be network-based core-edge elimination scheme, while all the others I know of are host-based. (However there has been a flurry of proposals to the RRG in recent days and I haven't read them all yet.) >> The usual arrangement for a core-edge separation scheme is to >> encapsulate the packet and tunnel it to an ETR. ETRs are always on >> "core" addresses. > > Sure. This is a little bit different in implementation, but, not completely > different in concept. OK. >> The total packet, now longer due to the one or more headers used to >> encapsulate it, is handled in the same way by DFZ routers as any >> other packet, so the DFZ routers don't need any upgraded functionality. > > And the fact that the packet is longer is an additional reason to include > the encapsulating router ID (so PMTU-D responses can be sent back > correctly and translated by the encapsulating router back to the origin) This is how LISP and APT work. Ivip uses the sending host's IP address in the outer header, which enables ETRs to easily enforce ISP BR filtering which rejects incoming packets with source addresses matching a prefix of the ISP's network. The ETR does this by dropping packets whose inner address is different from the outer address. If LISP and APT are to enforce this existing filtering, they need to do it directly on the inner address. Such filtering, for more than a handful of prefixes, is extremely expensive - and routers need to use TCAM to do it acceptably quickly. Ivip has a different approach to PMTUD management than to require the ITR to recognise and correctly handle Packet Too Big messages. Requiring ITRs to recognise PTBs is very tricky - since to do it securely requires a nonce in the traffic packet's LISP/APT header (which must be cached in the ITR for a few seconds) and also relies on the router to send back enough of the too-long packet to include this nonce. I think most routers do this, but RFC 1191 only requires it sends back the IP header and the next one. In LISP and I think APT, that is the UDP header. >> With your suggested scheme, there is no encapsulation and the packet >> is not made any longer. The DFZ routers forward the packet to the >> "nearest" BR of the currently mapped ASN for the packet's destination >> prefix. So there's no encapsulation overhead. If the packet is too >> long for one of these DFZ routers, it will presumably convert the >> packet back to its original form and send a conventional ICMP Packet >> Too Big message, so the sending host will get this message and retry >> with a shorter packet. So there are no thorny PMTUD problems, as >> there are with encapsulation. > > There is additional data in the packet (the ASN), but, it's less encapsulation > overhead than the other schemes. The rest is correct, mostly, with > the exception that PMTUD does get slightly thorny. My two Modified Header Forwarding proposals, when used with Ivip, do not lengthen the packet at all. So at the router where the next hop MTU is not big enough, some CPU firmware will need to turn the packet back into its original form, like an ETR, and then perform the usual PTB operation on it. The result goes back to the sending host (NOT the ITR) and the PTB contains the correct length to which the sending host should keep its packets. So RFC 1191 PMTUD works fine without any ITR involvement. Part of the PMTUD problem with encapsulation is that the PTB generated by the router, even if it went to the sending host, has the wrong number in it. The sending host needs to get a PTB with that number minus the length of the encapsulation headers. Only the ITR can generate this, but in Ivip, I have another method which doesn't rely on ITRs getting PTBs. The ITR probes the PMTU all the way to the ETR when it gets a packet longer than it had previously sent. It is complex, but I think it can be done. This doesn't need to be done with Modified Header Forwarding. >> With what you are suggesting, the DFZ routers need to be upgraded to >> recognise the new packet format. This raises major problems for >> widespread voluntary adoption - but I think it is well worth >> exploring. In the long term, it will cost little to progressively >> upgrade all DFZ routers with the new function. So in the long-term, >> a core-edge separation scheme could be migrated to this modified >> header arrangement without significant cost. Its just a matter of >> making sure all new routers perform the function. When all DFZ >> routers are of this type, the system can be turned on. > > Correct, the DFZ routers would eventually all need new software to > accommodate this, but, the existing hardware should suffice. OK - I am glad to find support for this. > The nice > thing is that by having it as a negotiated feature in BGP, like 32-bit > ASNs, it could be adopted in islands without requiring widespread > adoption day 1. That seems to me like it might overcome some of > the voluntary adoption hurdles. Yes. I don't think my approaches are amenable to this "island" model of adoption, but I will keep it in mind. >> I think that using modified headers only makes sense if the core-edge >> separation scheme does not need to send any extra information along >> with the traffic packet. LISP does send extra info with each traffic >> packet - in a LISP header which itself is behind a UDP header. Ivip >> does not send any extra information and uses simple IP-in-IP >> encapsulation. (I am not sure whether APT or TRRP send extra data.) > > This would send extra data, but, less extra data than LISP. I don't know > for sure about APT or TRRP, either, but, I believe they send at least an > extra 256 bits. OK. >> If the core-edge separation scheme needs to send extra data with each >> traffic packet, then most of the benefits of modifying the header are >> lost, since there would still need to be some additional header, >> which lengthens the total packet and causes a lot of trouble with >> Path MTU Discovery. Avoiding the encapsulation overhead and PMTUD >> complexities are extremely worthwhile goals. > > Sure, but, I think they're inevitable. Ivip is the only proposal so far which uses pure IP-in-IP encapsulation (no extra data) or pure Modified Header Forwarding (no extra packet length at all). If you have time to critique Ivip and let me know privately, or on the RRG list, what you think, I would very much appreciate it. > However, I will say that if you extend > the header only by 4 octets (ASN) + 16 octets (IPv6 address of encapsulating > router), that 20 octet add is less likely to trip PMTU issues than many of the > 36+ octet adds in things like LISP, etc. I also think that having the PMTU > issue reduced to "send the Packet Too Big to the encapsulating router with > original source+dest in payload" which would then result in the encapsulating > router taking the suggested MTU-20 and forwarding that back to the origin > with an ICMP message that looked just like one that would have come > from the reporting router if there hadn't been an encapsulation (other than > reducing the recommended MTU by 20) is pretty straight forward. You could do this, but as I mentioned above, doing it securely is very expensive. >> Sorry this was rather long, but I wanted to say that I think modified >> header forwarding is worth exploring - and I tried to imagine what >> your scheme would involve. > > Hopefully I've clarified enough for your imagination to take it further. Indeed you have. >> Since you are prepared to consider upgrading all DFZ routers and >> modifying the IP header, here are my two proposals which do this. > > Sort of... I think it needs to be possible to implement in islands rather > than requiring a flag day. I haven't figured out a way of doing it yet - but there would be no need to upgrade DFZ routers if the only ISP networks behind them did not have any SPI-using end-user networks. > I'll try to look at your suggestions a little later today. I need to get moving > towards work right now. > > Owen OK - Thanks! - Robin From michael.dillon at bt.com Wed Dec 23 08:26:25 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 23 Dec 2009 13:26:25 -0000 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <3c3e3fca0912221701l4db11136h1721433b55cde89a@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C497458049FD6B4@E03MVZ2-UKDY.domain1.systemhost.net> > I'm deeply disturbed by this post. My understanding is that > the AC's mission is to help the community craft the best > possible policy which expresses its will and to help the > process move smoothly. Actually, according to ARIN Bylaws Article VI, Section 2 a. the function of the Advisory Council is as follows: The Advisory Council shall act in an advisory capacity to the Board of Trustees on matters as the Board of Trustees may, from time to time, request involving Internet numbering resource policies and related matters. The President of ARIN shall be the primary point of contact between the Advisory Council and the Board of Trustees. The AC has never been there to help the community express its will. In fact, it was created in order to collate and filter the desires of the "Internet community". It is easy for mythology to build up around an organization and it is useful, from time to time, to review the basic principles on which an organisation is founded. It would also be useful to look through the PDP at where you will note that it talks about the community "developing" policies. It never states that policies are to express the will of the community, instead it talks about the community "supporting" a policy change, about consensus and about the community initiating proposals. It also clearly defines the role of the Advisory Council thus: The Advisory Council determines the consensus of the community regarding the draft policy. It evaluates the type and amount of support and opposition to a policy as expressed by the community on the ppml and in the public policy meeting. In particular, if you have a proposal that has overwhelming public support for a new fee structure for ARIN, then the ACs job is clearly to reject that proposal. The amount of support was right, but the type of support is wrong since "Policies developed through the PDP do not define or establish ARIN fees.". --Michael Dillon From michael.dillon at bt.com Wed Dec 23 08:47:53 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 23 Dec 2009 13:47:53 -0000 Subject: [arin-ppml] Modified Header Forwarding for scalable routing In-Reply-To: <4B3173A6.8000909@firstpr.com.au> Message-ID: <28E139F46D45AF49A31950F88C497458049FD6ED@E03MVZ2-UKDY.domain1.systemhost.net> > Short version: MPLS doesn't seem to be suitable for the task of > scalably transporting traffic packets across the > DFZ in a core-edge separation solution to the > routing scaling problem. That is an opinion, but I don't think that anyone has examined the suitability of MPLS for this role in enough detail in order to determine whether or not it is suitable. In particular, the role under discussion is such a key role than any inadequacy of any given technology could be changed and those changes would be implemented by all the vendors that matter. > Even if it was suitable, > it involves encapsulation overhead and therefore > Path MTU Discovery problems. How many nanoseconds of encap overhead are there on 10G links? As for PMTU discovery, this is a solveable problem since if there is a will to make an MPLS core, there would also be a will to establish a set of standard MTUs that would guarantee a specified MTU size across the entire core. Or maybe there would be separate cores for jumbo MTUs and smaller ones. > MPLS's extra packet length represents inefficiency, > especially for small VoIP packets, In the UK, the PSTN is being migrated onto VoIP over MPLS As of the 16th of December there are over 700 telephone exchanges running on MPLS and around 800 exchanges ready for Ethernet local access connections. In other words, in addition to VoIP packets, this network carries normal IP traffic such as business VPNs and last mile broadband Internet access for ISPs. You may be correct that MPLS packets take an extra nanosecond to transit a router, but to call that inefficient ignores all of the other benefits of having a converged core. I recognize that my employer is a pioneer in doing this much with MPLS, but many more carriers are running international MPLS networks carrying VoIP along with Internet traffic, VPNs, telepresence, streaming video, video backhaul and other things. The arguments of 1995 do not apply to today's MPLS. > So I don't think MPLS is a suitable technique. AFAIK, no RRG > proposal uses MPLS. There is no guarantee that the RRG will agree with any of the proposals before it nor is there any guarantee that the RRG won't go with something completely different from all current proposals. It's not a beauty contest. The RRG wants something that will work in the real world, and that can be transitioned without causing massive network disruption. In the meantime, the real world has already solved the problem and is continuing to build out more infrastructure BYPASSING THE PUBLIC INTERNET. If growth goes elsewhere, then the Internet core has less need to grow. --Michael Dillon From terry.l.davis at boeing.com Wed Dec 23 09:53:30 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Wed, 23 Dec 2009 06:53:30 -0800 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: References: Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF55127B090F@XCH-NW-05V.nw.nos.boeing.com> Scott This is definitely along the right track! I'll think more about it over the weekend. Take care Terry ________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand Sent: Wednesday, December 23, 2009 1:06 AM To: ARIN-PPML List Subject: [arin-ppml] Simplified IPv6 policy Here's an attempt at how we might simplify IPv6 policy, incorporating many of the ideas we've discussed recently. It's much simpler than current policy, but is still quite long. It's also late, so I reserve the right to make mistakes, and to disagree with myself later. :-) Delete "6.1 Introduction" This is all historical. Delete "6.2 Definitions" The definitions we need are all defined in section 2. Leave 6.3 as is (renumber to 6.1) I think these still accurately reflect the Goals we want our policy to follow. Move 6.4.1 to 1.1. Retitle to "Number resources not to be considered property" and update text per below. This is a principle more general than just IPv6, and needs to be updated to be ARIN-specific and refer to the RSA. Delete 6.4.2 - 6.4.4 These principles don't seem worthy of elevation to special status. Replace 6.5 Policies for allocations and assignments with text below (renumber to 6.2) This seems to be where most of the changes and simplification are needed. Delete 6.6 References This is all historical, and doesn't need to be part of the NRPM. Delete 6.7 Appendix A: HD-Ratio As above, we can let the HD-Ratio guide policy without making people do the math. Delete 6.8. Appendix B: Background information This is all historical Move 6.9 and 6.10 into 6.2.3.2 below Replacement text: 1.1. Number resources not to be considered property It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property. The policies in this document are based upon the understanding that globally-unique number resources are licensed for use rather than owned. Specifically, IP addresses and ASNs will be allocated and assigned on a license basis, with licenses subject to renewal on a periodic basis. The granting of a license is subject to specific conditions applied at the start or renewal of the license, as definied in the ARIN Registration Services Agreement. Note that when a license is renewed, the new license will be evaluated under and governed by the applicable number resource policies in place at the time of renewal, which may differ from the policy in place at the time of the original allocation or assignment. 6.2. Policies for IPv6 allocations and assignments 6.2.1. Allocations and assignments To meet the goal of Fairness, ARIN makes both allocations and assignments according to common criteria. Allocations are made to LIRs, and assignments to certain end users. 6.2.2. Assignments from LIRs/ISPs End-users are assigned an end site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): * /64 when it is known that one and only one subnet is needed * /56 for small sites, those expected to need only a few subnets over the next 5 years. * /48 for larger sites For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation. ARIN is not concerned about which address size an LIR/ISP actually assigns. Accordingly, ARIN will not request the detailed information on IPv6 user networks as in IPv4, except for the purpose of measuring utilization as defined in this document. 6.2.3. Allocations and assignments from ARIN 6.2.3.1 Goals To balance the goals of Aggregation, Conservation, Fairness, and Minimized Overhead, ARIN normally makes allocations only in the discrete sizes of /48, /40, /32, /28, or /24 or larger. Each organization or discrete network may qualify for one allocation or assignment of each size, and must pay fees according to ARIN's fee schedule for each size assigned. 6.2.3.2 X-Small (/48) To qualify for a /48 allocation or assignment, an organization must: * Serve at least 500 hosts, if multihomed; or * Serve at least 1000 hosts; or * Demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA; or * Be a critical infrastructure provider of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA; or * Qualify for a Micro-allocations for Internal Infrastructure per 6.3.3.2.2. 6.2.3.2.1 Critical Infrastructure Organizations qualified as critical infrastructure providers may be granted multiple /48 allocations in certain situations. Exchange point allocations MUST be allocated from specific blocks reserved only for this purpose. All other micro-allocations WILL be allocated out of other blocks reserved for micro-allocation purposes. ARIN will make a list of these blocks publicly available. Exchange point operators must provide justification for the allocation, including: connection policy, location, other participants (minimum of two total), ASN, and contact information. ISPs and other organizations receiving these micro-allocations will be charged under the ISP fee schedule, while end-users will be charged under the fee schedule for end-users. This policy does not preclude exchange point operators from requesting address space under other policies. 6.2.3.2.2 Micro-allocations for Internal Infrastructure Organizations that currently hold IPv6 allocations may apply for a /48 micro-allocation for internal infrastructure. Applicant must provide technical justification indicating why a separate non-routed block is required. Justification must include why a sub-allocation of currently held IP space cannot be utilized. Internal infrastructure allocations must be allocated from specific blocks reserved only for this purpose. 6.2.3.3 Small (/40) To qualify for a /40 allocation or assignment, an organization must qualify for two or more /48s. 6.2.3.4 Medium (/32) To qualify for a /32 allocation or assignment, an organization must: * Qualify for 100 or more /48s; or * Be an existing, known LIR; or * Have a plan to provide IPv6 connectivity to other organizations and assign at least 100 end-site assignments to those organizations within 5 years. 6.2.3.5 Large (/28) To qualify for a /28, an organization must demonstrate the need to make assignments and/or reallocations equal to at least 20,000 /48s. 6.2.3.6 X-Large (/24 or larger) Allocations or assignments of /24 or larger may be made only in exceptional cases, to organizations that require more than a /28, and have submitted documentation that reasonably justifies the request. If approved, the allocation size will be based on the number of existing users and the extent of the organization's infrastructure. 6.3. Registration When an organization holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate (information registered by ARIN may be replaced by a distributed database for registering address management information in future). Information is registered in units of assigned /56 networks. When more than a /56 is assigned to an organization, the assigning organization is responsible for ensuring that the address space is registered in an ARIN database. IRs shall maintain systems and practices that protect the security of personal and commercial information that is used in request evaluation, but which is not required for public registration. 6.3.1. Residential Customer Privacy (2003-3) 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. 6.3.2. Reverse lookup When ARIN delegates IPv6 address space to an organization, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organization should properly manage its reverse lookup zone. When making an address assignment, the organization must delegate to an assignee organization, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address. Thoughts? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Wed Dec 23 10:59:08 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 23 Dec 2009 10:59:08 -0500 Subject: [arin-ppml] efficient utilization != needs basis In-Reply-To: <4B31357A.8090003@umn.edu> References: <4B3100C4.2040901@umn.edu> <25792.1261509808@marajade.sandelman.ca> <4B31357A.8090003@umn.edu> Message-ID: <14292.1261583948@marajade.sandelman.ca> >>>>> "David" == David Farmer writes: David> However, there are other IP technologies coming that may or David> may not be connected to the Internet and will possibly form David> other internets. These internets will probably have other David> challenges and possibly form other address hierarchies David> independent of the Internet as we know it today. But, they David> will almost assuredly need globally unique addresses too. >> +1 (And ULA does not cut it for me) ... David> Please note I am not saying they are not routable, they are David> most assuredly intended to be routed within an Autonomous David> System or even within a small set of Autonomous Systems. David> But, that they are not intended to be routed across the David> entire hierarchically routed global Internet. In other David> words, by default the normal expected behavior for a network David> operator is to not route these across an Autonomous System David> boundary without special arrangements. I agree with what you said. When I said "not routable", I mean what you said. David> So, a question I have for you and something I'm not 100% David> decided on would ULA-Central or ULA-Global be an acceptable David> alternative? I was a supporter of ULA-Central, before, I thought that there was another proposal from Paul Vixie. I can't find it right now, so just so that everyone knows what is being talked about: http://www.ripe.net/ripe/policies/proposals/2007-05.html http://smakd.potaroo.net/ietf/idref/draft-ietf-ipv6-ula-central/index.html I was never clear if ULA-Central would include a whois database and proper delegation of reverse DNS. >> Proposal 103 gives out globally unique (but not routable) /48s to >> anyone that asks, and that is enough to get these other networks >> off the ground to the point where one can understand just how >> much space you really do need. David> While I agree this would be possible with PP#103, I believe David> it is possible to provide these addresses without such a David> massive change to IPv6 policy structure. I would welcome such a proposal, but until I see it, I'm not prepared to give up on 103. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr at sandelman.ca Wed Dec 23 11:03:51 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 23 Dec 2009 11:03:51 -0500 Subject: [arin-ppml] efficient utilization != needs basis In-Reply-To: <28E139F46D45AF49A31950F88C497458049FD2CE@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458049FD2CE@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <14572.1261584231@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "michael" == michael dillon writes: >> But, that they are not intended to be routed across the entire >> hierarchically routed global Internet. In other words, by >> default the normal expected behavior for a network operator is to >> not route these across an Autonomous System boundary without >> special arrangements. michael> That is an odd way of putting it. These blocks are intended michael> to be routed across ASN boundaries but the network operator michael> typically maintains separacy between their public Internet michael> infrastructure and the COIN (Community of Interest Network) michael> infrastructure. Even the automotive industry, which does michael> not have the same security needs as air transport or michael> finance, requires the ISPs to use a separate infrastructure michael> for ANX traffic. Let's put it this way, if company A is a michael> member of a COIN supplied by ISP B, the Company A will buy michael> a separate circuit from ISP B to supply Internet michael> access. The COIN does not meet the Internet except michael> internally in the member company networks where there are michael> usually strict controls in place including routing, michael> firewalls, edge ACLS to make sure traffic does not leak michael> onto the wrong network. That's great for Ford or American Airlines. That's totally ridiculous for linking the 7 locations of Bob-DryCleaning's together over $200 VPN. Perhaps tunnelling IPv6 inside IPv4, without the help/knowledge of the ISPs. michael> I suspect that the only acceptable alternative would be one michael> in which the IETF recognizes the existence of multiple michael> global internets, not just the one with the big I, and sets michael> aside special Global Unicast prefixes for these COINs. And michael> to get there, at minimum they would have to get the michael> agreement of the air transport folks, the automotive folks michael> and the global financial industry folks. michael> It seems easier to just use ordinary global unicast. The big guys do not have a problem --- look the government of germany just got a /26. No big deal for them to parcel off a /32 for use on some COIN. It's the small guys that will have a problem --- and it will be the small guys that will deploy useful things first. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSzI/ZYCLcPvd0N1lAQKjwggAvaeNS+P3EOBWb9xT78+I9qP2FV5ijggS avpxi90pMlkqGRsFEhMH1CFcd/sbMjeJQsKTIbQAQ0OVrUbefFM9f9gHdJrqn3pL nPaZu/ucbLZCaHnHu0lKW+F6UrqM07+45rfIXABUYeYIT0U1qWFFAlED0Bi3YF1G nsOgq3LfBvavqzhPMp86imY/MfRz35stPS30nIWet9dJGveYl3jsgagz5AL52FL3 b2cSYMqp9+DXmNP9H4ngIEyRbyOa/RX8hDnnja1FuwWin1mm9DJnmvl2WE0/cGlK 1u+JMq7taeHrsp1oqoFiz4n1zAms6PIVjxHT0QWW+Jc/mgwybXc3JQ== =XSDq -----END PGP SIGNATURE----- From bicknell at ufp.org Wed Dec 23 11:10:46 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 23 Dec 2009 08:10:46 -0800 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <3c3e3fca0912221701l4db11136h1721433b55cde89a@mail.gmail.com> References: <73E11B6A-EB6F-4D02-8F2B-F9345F776644@delong.com> <3c3e3fca0912221701l4db11136h1721433b55cde89a@mail.gmail.com> Message-ID: <20091223161046.GA71845@ussenterprise.ufp.org> In a message written on Tue, Dec 22, 2009 at 08:01:46PM -0500, William Herrin wrote: > I'm deeply disturbed by this post. My understanding is that the AC's > mission is to help the community craft the best possible policy which > expresses its will and to help the process move smoothly. Killing a > well supported proposal this early obstructs the community's role in > the policy process. There seems to be a myth that policy ideas cannot be discussed without a proposal on the table. I have no idea where that idea originated, but it is demonstratibly false. For instance, every face to face meeting has the "Open Policy Hour" specifically to discuss things not on the table. PPML archives are filled with discussions that either never resulted in policy, or were discussed without a proposal for months or years before a proposal was put forward. What having a proposal does is put requirements on the discussion. Timelines. Presentations at meetings. These can be useful, but also in the early days of a proposal can be harmful; rather than letting the idea develop and turn into something good it is shoehorned into a timeline. As for this particular proposal, it appeared to me it was not ripe. Long proposals almost never pass, and not only is this one long but it touches on many different areas. I believe in its current form it has no chance of passing, as the details need to be refined, simplified, and folks brought on board before there is a reason to have a formal proposal. The mailing list has also made something clear to me recently. The community does not know what it wants to do with IPv6. There are several competing factions, all basing their positions off of, well, wild assumptions. As an AC member, this makes me sour on all IPv6 policies. We need to form some cohesion around basic principals before we go crafting policy details. I encourage you to continue to discuss your ideas on PPML, and see if you can build support and/or refine the ideas. It's quite possible they will become ripe in the future and turn into a policy. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From farmer at umn.edu Wed Dec 23 11:47:16 2009 From: farmer at umn.edu (David Farmer) Date: Wed, 23 Dec 2009 10:47:16 -0600 Subject: [arin-ppml] efficient utilization != needs basis In-Reply-To: <14292.1261583948@marajade.sandelman.ca> References: <4B3100C4.2040901@umn.edu> <25792.1261509808@marajade.sandelman.ca> <4B31357A.8090003@umn.edu> <14292.1261583948@marajade.sandelman.ca> Message-ID: <4B324994.8000002@umn.edu> Michael Richardson wrote: >>>>>> "David" == David Farmer writes: > David> So, a question I have for you and something I'm not 100% > David> decided on would ULA-Central or ULA-Global be an acceptable > David> alternative? > > I was a supporter of ULA-Central, before, I thought that there was > another proposal from Paul Vixie. I can't find it right now, so just so > that everyone knows what is being talked about: Vixie's proposal was ULA-Global http://nsa.vix.com/~vixie/ula-global.txt > http://www.ripe.net/ripe/policies/proposals/2007-05.html > http://smakd.potaroo.net/ietf/idref/draft-ietf-ipv6-ula-central/index.html > > I was never clear if ULA-Central would include a whois database and > proper delegation of reverse DNS. So would you prefer ULA-Central or ULA-Global type solution or a solution based on Global Unicast address space. Personally, I'm leaning toward Global Unicast address space. > >> Proposal 103 gives out globally unique (but not routable) /48s to > >> anyone that asks, and that is enough to get these other networks > >> off the ground to the point where one can understand just how > >> much space you really do need. > > David> While I agree this would be possible with PP#103, I believe > David> it is possible to provide these addresses without such a > David> massive change to IPv6 policy structure. > > I would welcome such a proposal, but until I see it, I'm not prepared to > give up on 103. I'll get it out soon. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From mcr at sandelman.ca Wed Dec 23 12:11:36 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 23 Dec 2009 12:11:36 -0500 Subject: [arin-ppml] ULA-Global/Central vs prop.103. In-Reply-To: <4B324994.8000002@umn.edu> References: <4B3100C4.2040901@umn.edu> <25792.1261509808@marajade.sandelman.ca> <4B31357A.8090003@umn.edu> <14292.1261583948@marajade.sandelman.ca> <4B324994.8000002@umn.edu> Message-ID: <19283.1261588296@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "David" == David Farmer writes: >> I was a supporter of ULA-Central, before, I thought that there was another >> proposal from Paul Vixie. I can't find it right now, so just so >> that everyone knows what is being talked about: David> Vixie's proposal was ULA-Global David> http://nsa.vix.com/~vixie/ula-global.txt Thanks. What is the difference, I was not sure. >> I was never clear if ULA-Central would include a whois database and >> proper delegation of reverse DNS. David> So would you prefer ULA-Central or ULA-Global type solution David> or a solution based on Global Unicast address space. David> Personally, I'm leaning toward Global Unicast address space. I am agnostics as whether I have to type "fc00:.." or "2001:..". If in global unicast space, possibly each RIR will have distinct pools to allocate out of, although I suppose they could go to IANA and ask for a new /12 for this, and split it up among the RIRs. (This might require an IETF action... in which case, what the difference between this and using fc00?) The problem with fc00 is that I'm really not clear how the reverse map will be populated. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSzJPOYCLcPvd0N1lAQLEhwf/cEy+di8hi3b9Gh5RBw49aCk2nyjFPbyZ 2E87pjOtcUjmUiQ7xCqrzh1bUePIiOwdM/bAydQqx6aOnjRS9SaSZ1tiR8v52WN3 zxiit8ORAEKqCEb/wPgCB2bTKMN3jxyXUCNW9hNJqxk8iVrDZoP6zW5+VyPTmlYx Nmi8Wagg3qM/CMyNrGTJAaKf4c1HKoAzUNeqp4KanyC3WJzQz8T1vbuRyGH8P8h5 E8KYt2RtE4kaS/lqf0A1oGLXNxmPtW8011tQFCZEW+5Rbo8oPNmDTXv3fwWp7cCK kq9cPfwLwCRGZPVhAKN1IdrnDizF9qar7gTZIMUHCbWkQ5anoWxp6A== =V4pN -----END PGP SIGNATURE----- From scottleibrand at gmail.com Wed Dec 23 12:24:13 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Dec 2009 09:24:13 -0800 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: <3c3e3fca0912230253x78027638l82bc102aee544edc@mail.gmail.com> References: <3c3e3fca0912230253x78027638l82bc102aee544edc@mail.gmail.com> Message-ID: <4B32523D.2020501@gmail.com> On 12/23/2009 2:53 AM, William Herrin wrote: > On Wed, Dec 23, 2009 at 4:05 AM, Scott Leibrand wrote: > >> Here's an attempt at how we might simplify IPv6 policy, incorporating many >> of the ideas we've discussed recently. It's much simpler than current >> policy, but is still quite long. It's also late, so I reserve the right to >> make mistakes, and to disagree with myself later. :-) >> > > Hi Scott, > > I think your proposal offers a major improvement on existing IPv6 policy. > > > Problems addressed by your proposal: > > * Enables effective TE filtering where ISPs determine that > disaggregate TE is undesirable. > > * Unifies ISP/end-user policy so that all organizations are treated fairly > > Problems not resolved by your proposal: > > * Offers no IPv6 replacement for organizations with small but valuable > server infrastructures which today multihome with either a legacy > address block or a /24 ISP cutout. > If you have (or acquire via 8.3) a legacy address block, then you can qualify for a PI /48. If you multihome with a PA /24 today, the equivalent in v6 would be to multihome with a PA /48. At the moment, such cutouts are not routable, but to me that's not something policy can fix. If your upstreams won't take your money to accept your /48 cutout from each other, then how are we going to get them to agree to route a whole bunch of new PI /48s that they don't necessarily get paid for? This is not a theoretical problem: AFAIK Verizon has not yet started accepting the PI /48s ARIN is already allocating. If we give out PI /48s to anyone who wants to multihome, they (and others) will be even less likely to accept those. > * Retains ARIN as the gatekeeper for Internet routing policy. ISPs > must accept and route all allocations, even the x-small ones, or > they'll lose access to critical infrastructure. > Not as currently written. Among the extra critical infrastructure text I kept is a requirement that critical infrastructure blocks be allocated from a dedicated block so that ISPs can selectively accept those. I agree that the policy retains ARIN as the gatekeeper for Internet routing policy. Perhaps we can change that, but I'm pretty sure that a policy proposal doing so by liberalizing assignment policy to the point where ISPs *have to* filter would generate a large amount of opposition. Owen is just the most willing-to-speak-up tip of that iceberg of opposition. > Some specific comments inline: > > >> Replacement text: >> >> 1.1. Number resources not to be considered property >> >> It is contrary to the goals of this document and is not in the interests of >> the Internet community as a whole for address space to be considered >> freehold property. >> >> The policies in this document are based upon the understanding that >> globally-unique number resources are licensed for use rather than owned. >> Specifically, IP addresses and ASNs will be allocated and assigned on a >> license basis, with licenses subject to renewal on a periodic basis. The >> granting of a license is subject to specific conditions applied at the start >> or renewal of the license, as definied in the ARIN Registration Services >> Agreement. >> >> Note that when a license is renewed, the new license will be evaluated under >> and governed by the applicable number resource policies in place at the time >> of renewal, which may differ from the policy in place at the time of the >> original allocation or assignment. >> > Good or bad, I'm not sure 1.1 is germane to the rest of the proposal. > Can it be left out without impacting the rest or does it change > something crucial? > It seemed like something that had enough value to be worth keeping. If/when this ever gets to draft policy stage, we can ask ARIN Counsel's opinion on whether to keep it. >> 6.2. Policies for IPv6 allocations and assignments >> >> 6.2.1. Allocations and assignments >> To meet the goal of Fairness, ARIN makes both allocations and assignments >> according to common criteria. Allocations are made to LIRs, and assignments >> to certain end users. >> > In a policy designed to enable disaggregate filtering, the distinction > between a LIR and an ISP is not technologically sound. There are no > LIRs who allocate or assign addresses to entities they don't also > supply Internet service to. I suggest replacing all instances of LIR > with ISP. > Section 2.4. defines a Local Internet Registry (LIR) as "an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs, whose customers are primarily end users and possibly other ISPs." I don't think it matters one way or the other. >> 6.2.2. Assignments from LIRs/ISPs >> End-users are assigned an end site assignment from their LIR or ISP. The >> exact size of the assignment is a local decision for the LIR or ISP to make, >> using a minimum value of a /64 (when only one subnet is anticipated for the >> end site) up to the normal maximum of /48, except in cases of extra large >> end sites where a larger assignment can be justified. >> >> The following guidelines may be useful (but they are only guidelines): >> >> * /64 when it is known that one and only one subnet is needed >> * /56 for small sites, those expected to need only a few subnets over the >> next 5 years. >> * /48 for larger sites >> >> For end sites to whom reverse DNS will be delegated, the LIR/ISP should >> consider making an assignment on a nibble (4-bit) boundary to simplify >> reverse lookup delegation. >> >> ARIN is not concerned about which address size an LIR/ISP actually assigns. >> Accordingly, ARIN will not request the detailed information on IPv6 user >> networks as in IPv4, except for the purpose of measuring utilization as >> defined in this document. >> >> 6.2.3. Allocations and assignments from ARIN >> >> 6.2.3.1 Goals >> To balance the goals of Aggregation, Conservation, Fairness, and Minimized >> Overhead, ARIN normally makes allocations only in the discrete sizes of /48, >> /40, /32, /28, or /24 or larger. Each organization or discrete network may >> qualify for one allocation or assignment of each size, and must pay fees >> according to ARIN's> href="https://www.arin.net/fees/fee_schedule.html">fee schedule >> for each size assigned. >> > Good. > > > >> 6.2.3.2 X-Small (/48) >> To qualify for a /48 allocation or assignment, an organization must: >> * Serve at least 500 hosts, if multihomed; or >> * Serve at least 1000 hosts; or >> > IPv6 addressing is LAN-centric rather than host-centric. Accordingly I > suggest expressing this in terms of a number of LANs served. Perhaps > 50 or 100 LANs instead of 500 or 1000 hosts? > Why is number of LANs a better metric than number of hosts to determine who deserves a routing slot? We're not really talking efficient utilization here, so I don't think number of LANs is relevant. Besides, I can create 100 VLANs on a single inexpensive switch. Creating 500 VMs (with running OSs) at least requires gear with more than a few dozen GB of RAM These numbers were adapted from existing IPv4 PI policy. Perhaps we should lower the numbers to better reflect the lower IPv4 requirements currently on the table. Perhaps 250 or 500 hosts? >> * Demonstrate efficient utilization of all direct IPv4 assignments and >> allocations, each of which must be covered by any current ARIN RSA; or >> * Be a critical infrastructure provider of the Internet, including public >> exchange points, core DNS service providers (e.g. ICANN-sanctioned root, >> gTLD, and ccTLD operators) as well as the RIRs and IANA; or >> * Qualify for a Micro-allocations for Internal Infrastructure per >> 6.3.3.2.2. >> >> 6.2.3.2.1 Critical Infrastructure >> Organizations qualified as critical infrastructure providers may be granted >> multiple /48 allocations in certain situations. Exchange point allocations >> MUST be allocated from specific blocks reserved only for this purpose. All >> other micro-allocations WILL be allocated out of other blocks reserved for >> micro-allocation purposes. ARIN will make a list of these blocks publicly >> available. Exchange point operators must provide justification for the >> allocation, including: connection policy, location, other participants >> (minimum of two total), ASN, and contact information. ISPs and other >> organizations receiving these micro-allocations will be charged under the >> ISP fee schedule, while end-users will be charged under the fee schedule for >> end-users. This policy does not preclude exchange point operators from >> requesting address space under other policies. >> > At work I operate a ground station for a satellite constellation. The > non-IP satellite devices deliver messages to the ground station which > disperses them via the Internet. > > This very high value application uses 5 T1s from 5 different ISPs, a > 100 meg ISP link and a 100 meg peering link. It uses only a few score > hosts and a handful of LANs. > > I use an ARIN AS# to announce an IPv4 /24 cutout from an ISP block via > BGP on all the ISP and peering links. Because it's multihomed, this is > in full compliance with ARIN policy. Because it's impractical to > filter announcements /24 and shorter, it works great. > > How do I get usable IPv6 addresses? > As I mentioned above, if you can't pay your upstreams enough money to accept PA /48s from each other, perhaps your application isn't high-value enough to justify a routing table slot. In this case, I think it is, but as I mentioned above, I think you should have to work that out with your upstreams, not rely on ARIN to make them accept a whole bunch of lower-value PI /48s. >> 6.2.3.2.2 Micro-allocations for Internal Infrastructure >> Organizations that currently hold IPv6 allocations may apply for a /48 >> micro-allocation for internal infrastructure. Applicant must provide >> technical justification indicating why a separate non-routed block is >> required. Justification must include why a sub-allocation of currently held >> IP space cannot be utilized. Internal infrastructure allocations must be >> allocated from specific blocks reserved only for this purpose. >> >> 6.2.3.3 Small (/40) >> To qualify for a /40 allocation or assignment, an organization must qualify >> for two or more /48s. >> >> 6.2.3.4 Medium (/32) >> To qualify for a /32 allocation or assignment, an organization must: >> * Qualify for 100 or more /48s; or >> * Be an existing, known LIR; or >> * Have a plan to provide IPv6 connectivity to other organizations and >> assign at least 100 end-site assignments to those organizations within 5 >> years. >> >> 6.2.3.5 Large (/28) >> To qualify for a /28, an organization must demonstrate the need to make >> assignments and/or reallocations equal to at least 20,000 /48s. >> > Why not demonstrate that they -have made- at least 20,000 /48 > assignments from their /32? > That would be OK, but I was hoping to avoid having to make an ISP get a /32, start using it, and then renumber everything into a /28 if they know from the start they have more customers than will fit in a /32. >> 6.2.3.6 X-Large (/24 or larger) >> Allocations or assignments of /24 or larger may be made only in exceptional >> cases, to organizations that require more than a /28, and have submitted >> documentation that reasonably justifies the request. If approved, the >> allocation size will be based on the number of existing users and the extent >> of the organization's infrastructure. >> >> 6.3. Registration >> >> When an organization holding an IPv6 address allocation makes IPv6 address >> assignments, it must register assignment information in a database, >> accessible by RIRs as appropriate (information registered by ARIN may be >> replaced by a distributed database for registering address management >> information in future). Information is registered in units of assigned /56 >> networks. When more than a /56 is assigned to an organization, the assigning >> organization is responsible for ensuring that the address space is >> registered in an ARIN database. >> > Might want to put some verbiage here about assignments/reallocations > to legal entities other than the registrant so that you don't have to > register internal assignments for the printer LAN. > The text in section 6.3 is only slightly modified (i.e. to replace RIR/NIR with ARIN) from what's already in the NRPM. I think we're changing enough already. :-) >> IRs shall maintain systems and practices that protect the security of >> personal and commercial information that is used in request evaluation, but >> which is not required for public registration. >> >> 6.3.1. Residential Customer Privacy (2003-3) >> >> 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. >> > Is residential privacy already in effect? If not, it probably isn't > germane to the rest of the policy proposal. Potentially valuable but > better off in a separate proposal. > This is also already in the NRPM, and is really just another subsection renumbering. >> 6.3.2. Reverse lookup >> >> When ARIN delegates IPv6 address space to an organization, it also delegates >> the responsibility to manage the reverse lookup zone that corresponds to the >> allocated IPv6 address space. Each organization should properly manage its >> reverse lookup zone. When making an address assignment, the organization >> must delegate to an assignee organization, upon request, the responsibility >> to manage the reverse lookup zone that corresponds to the assigned address. >> > That would be totally sweet if ISPs were required to delegate RNDS to > the customers on request. I have a long-running argument with Cox on > the subject. But is this really ARIN's job? Again, already in the NRPM, just moved it and made some insubstantial edits. -Scott From farmer at umn.edu Wed Dec 23 12:56:34 2009 From: farmer at umn.edu (David Farmer) Date: Wed, 23 Dec 2009 11:56:34 -0600 Subject: [arin-ppml] questions about AC decision re: 103. In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B090E@XCH-NW-05V.nw.nos.boeing.com> References: <4B311E52.8050508@arin.net> <591.1261515471@marajade.sandelman.ca> <4B3155D3.40009@umn.edu> <0267B5481DCC474D8088BF4A25C7F1DF55127B090E@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <4B3259D2.2020500@umn.edu> Davis, Terry L wrote: > David > > I'll take a crack at this "needs issue" from a different angle. > > Since I'm in the edge of critical infrastructure numerous ways every, I guess I'd point out a few things in the way of re-addressing that we don't really think about: > > - When would be a good time for your local hospital to re-address its Emergency Room and ICU? > > - If a small biotec company has to re-address its control systems, when is a good time? An outage to their control systems, could destroy years of work. > > - The company supplying your local water? (not nearly all of them are public) > > - The local small power company providing your power? > > - The local industry that has highly specialized control systems to enable a highly robotic process with very high close tolerances on its products? What's the cost of failure? > > - The local irrigation district? (The ditch rider is now a SCADA system and every farm depends on it!) > > - What about my community bank; am I comfortable with the risk to my account access if they have to change? > > - What about my city government? It's intelligent (?) traffic control systems? Some still run their own 911 services. ?? > > - A small regional food distributor? (How time can they be out before their stocks spoil?) > > - The local company that provide fire and security monitoring to your business or home? > > - The local company that provides all the web sites for businesses in your community? > > Just visually walk down your community's main street and try to imagine what re-addressing might mean to any one of them! > > We make this crazy assumption that our business models function as they did before the Internet. They DON'T! We live in a 7x24 world now; our businesses, our livelihood, and our own personal safety depend on the Internet, 7x24 with at least 4 9's reliability. > > The PA concept is so broken in this context that I can find no way to defend it; I understand it at a technical level but that does not translate to the real world we live in. > > And we wonder why we cannot get IPv6 deployed? > > Take care > Terry Believe me I understand many of those issues with direct experience. I've even had to deal with UL864 listed networking gear, what a pain! - The University of Minnesota is more a small sized city, than a typical business - The University at one time to operate it own hospital with ER - The Twin Cities campus alone is 250+ buildings, 32M raw sqrft, 24M assignable sqrft - The TC campus operate its own a power gird, Steam Plant, Chiller Plant - Level-3 medical biocontainment facilities, thank god we don't have level 4 or 5 facilities - 1200 Security Cameras - Phone Switch with 45,000 time slots and a 911 PSAP - Campus Network, 85,000 ports of GigE, providing Internet Access, SCADA, HIPPA, PCI, Security Video, etc... Connectivity to the Internet is only one small part of the Universities network, it is just the most obvious to most people, the other parts are mostly unseen on a day to day basis. While I agree that a PA only world will not work, neither will a PI for everyone world, at least for the Big-I Internet. For the Big-I Internet to work, at least right now, we we need aggregation. However, many, if not most, of the things you mention don't actually need to be part of the Big-I Internet's addressing plan, at least the mission critical function of those items. Maybe the outside wrapper for the VPN that these might be running over part of the Big-I's infrastructure need to be part of the Big-I's addressing scheme. So, please read the other thread I started. Thanks -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From bill at herrin.us Wed Dec 23 13:08:38 2009 From: bill at herrin.us (William Herrin) Date: Wed, 23 Dec 2009 13:08:38 -0500 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <20091223161046.GA71845@ussenterprise.ufp.org> References: <73E11B6A-EB6F-4D02-8F2B-F9345F776644@delong.com> <3c3e3fca0912221701l4db11136h1721433b55cde89a@mail.gmail.com> <20091223161046.GA71845@ussenterprise.ufp.org> Message-ID: <3c3e3fca0912231008x36b293fao35c46dad763ee303@mail.gmail.com> On Wed, Dec 23, 2009 at 11:10 AM, Leo Bicknell wrote: > There seems to be a myth that policy ideas cannot be discussed > without a proposal on the table. ?I have no idea where that idea > originated, but it is demonstratibly false. ?For instance, every > face to face meeting has the "Open Policy Hour" specifically to > discuss things not on the table. ?PPML archives are filled with > discussions that either never resulted in policy, or were discussed > without a proposal for months or years before a proposal was put > forward. > > What having a proposal does is put requirements on the discussion. > Timelines. ?Presentations at meetings. ?These can be useful, but > also in the early days of a proposal can be harmful; rather than > letting the idea develop and turn into something good it is shoehorned > into a timeline. Leo, Disruptive proposals serve an intrinsic purpose simply by existing and demanding attention. Six months ago you killed proposal 92 on the basis that you wanted more time to consider small changes which might fix IPv6 policy's severe dysfunction. Without pressure from an active proposal, what have you accomplished with that time? > As for this particular proposal, it appeared to me it was not ripe. > Long proposals almost never pass, and not only is this one long but > it touches on many different areas. ?I believe in its current form > it has no chance of passing, as the details need to be refined, > simplified, and folks brought on board before there is a reason to > have a formal proposal. You've couched it better than Owen but you've basically said the same thing: the community won't want this, so why bother bringing it to the point where you ask them? The problem with that theory is two-fold: 1. Small changes are good but when small changes don't get the job done it's time to consider big changes. 2. The response 103 got on the PPML was heavily weighted towards the positive and comparable to other eventually-successful proposals in that phase of the process. YOU COULD BE MISTAKEN. The only way to know for sure is to take it to the meeting and ask. In the end you could be right. It could well go down in flames during the consensus call at the meeting. But even that serves a valuable purpose. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mcr at sandelman.ca Wed Dec 23 13:41:10 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 23 Dec 2009 13:41:10 -0500 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <20091223161046.GA71845@ussenterprise.ufp.org> References: <73E11B6A-EB6F-4D02-8F2B-F9345F776644@delong.com> <3c3e3fca0912221701l4db11136h1721433b55cde89a@mail.gmail.com> <20091223161046.GA71845@ussenterprise.ufp.org> Message-ID: <25580.1261593670@marajade.sandelman.ca> >>>>> "Leo" == Leo Bicknell writes: Leo> The mailing list has also made something clear to me recently. The Leo> community does not know what it wants to do with IPv6. There are Leo> several competing factions, all basing their positions off of, well, Leo> wild assumptions. As an AC member, this makes me sour on all IPv6 Leo> policies. We need to form some cohesion around basic principals Leo> before we go crafting policy details. You are right --- the IPv6 community is very young. One of the reasons IPv4 took in the late-1980s, early 1990s is that we did not have to have these long discussions before someone had the (addressing) resources to they needed to innovate. The community won't know what policies it needs until after there have been some mistakes made! In the IPv6 space, perhaps the best thing ARIN could do would be to do is to have no policy for awhile, but to agree on what the "awhile" is, and make all assignments there expire then. We did that in some sense with 3ffe:: already, but that was awhile ago, and IPv6 did not take off the way people hoped, so maybe it's time to repeat that kind of thing. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From bill at herrin.us Wed Dec 23 13:52:35 2009 From: bill at herrin.us (William Herrin) Date: Wed, 23 Dec 2009 13:52:35 -0500 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: <4B32523D.2020501@gmail.com> References: <3c3e3fca0912230253x78027638l82bc102aee544edc@mail.gmail.com> <4B32523D.2020501@gmail.com> Message-ID: <3c3e3fca0912231052i4ffac09ew5a52e72ce8258f96@mail.gmail.com> On Wed, Dec 23, 2009 at 12:24 PM, Scott Leibrand wrote: > On 12/23/2009 2:53 AM, William Herrin wrote: >> Problems not resolved by your proposal: >> >> * Offers no IPv6 replacement for organizations with small but valuable >> server infrastructures which today multihome with either a legacy >> address block or a /24 ISP cutout. > > If you have (or acquire via 8.3) a legacy address block, then you can > qualify for a PI /48. > > If you multihome with a PA /24 today, the equivalent in v6 would be to > multihome with a PA /48. Hi Scott, There is no IPv6 equivalent to a multihomed IPv4 /24 PA cutout. Not in this proposal with its classifications that enable strong disaggregate filtering. Not in existing IPv6 policy that enables less effective prefix filtering. Not in the IETF's recommendations. > At the moment, such cutouts are not routable, but > to me that's not something policy can fix. If your upstreams won't take > your money to accept your /48 cutout from each other, then how are we going > to get them to agree to route a whole bunch of new PI /48s that they don't > necessarily get paid for? Convincing ISPs to accept /48 cutouts from each other is in direct opposition to the classification for disaggregate management that your proposal creates. Further, suggesting that policy can't fix it is a cop-out. Policy did fix it in IPv4: by authorizing /24 cutouts for multihomed entities regardless of size based on the knowledge that /24's are generally routable. Successful ARIN IPv6 policy will have to create an IPv6 equivalent to a multihomed IPv4 /24 PA cutout or else leave a well-funded class of users with a solid technical basis for actively opposing IPv6 deployment. Put another way: it is absurd to think that we will successfully disenfranchise anyone in the IPv4 to IPv6 movement. We can change the shape of the game but some rules are fundamental. The sooner we figure this out, and address it in formal policy, the sooner we can move forward. > This is not a theoretical problem: AFAIK Verizon > has not yet started accepting the PI /48s ARIN is already allocating. If we > give out PI /48s to anyone who wants to multihome, they (and others) will be > even less likely to accept those. Whether Verizon plays ball is another matter entirely. Your choices there are threefold: 1. Bend ARIN policy to meet Verizon's will. You have a Verizon representative on the AC so you'll have little problem learning their requirements. 2. Ignore Verizon presuming that customer and government pressure will eventually compel them to practices compatible with ARIN policy. A letter from the GSA threatening to classify Verizon as not-IPv6-compliant with respect to Federal purchasing rules would end its resistance to /48's overnight. 3. Institute a policy like 103 in which Verizon and the other ISPs intentionally have the power to make such filtering choices and registrants can, with an application of cash, adjust their own decisions to match. In other words, create a dynamic system and let it find its natural balance point instead of trying to impose one from on-high at the ARIN level. It's ironic that bottom-up is an important goal in the PDP but not in the NRPM. >>> 6.2.3.2 ?X-Small (/48) >>> To qualify for a /48 allocation or assignment, an organization must: >>> ? ?* Serve at least 500 hosts, if multihomed; or >>> ? ?* Serve at least 1000 hosts; or >>> >> >> IPv6 addressing is LAN-centric rather than host-centric. Accordingly I >> suggest expressing this in terms of a number of LANs served. Perhaps >> 50 or 100 LANs instead of 500 or 1000 hosts? >> > > Why is number of LANs a better metric than number of hosts to determine who > deserves a routing slot? ?We're not really talking efficient utilization > here, so I don't think number of LANs is relevant. ?Besides, I can create > 100 VLANs on a single inexpensive switch. ?Creating 500 VMs (with running > OSs) at least requires gear with more than a few dozen GB of RAM You mean all I have to do for an IPv4 /22 is stand up 500 VMs? Damn, I've been doing it the hard way. I just got my new 72 gig vmware server too. > These numbers were adapted from existing IPv4 PI policy. ?Perhaps we should > lower the numbers to better reflect the lower IPv4 requirements currently on > the table. ?Perhaps 250 or 500 hosts? It's just a quibble but hosts is IPv4-think. Subnets is consistent with IPv6. There will be a certain degree of arbitrariness to any selected numbers, but basing the count on subnets will make it slightly less so. >> At work I operate a ground station for a satellite constellation. The >> non-IP satellite devices deliver messages to the ground station which >> disperses them via the Internet. >> >> This very high value application uses 5 T1s from 5 different ISPs, a >> 100 meg ISP link and a 100 meg peering link. It uses only a few score >> hosts and a handful of LANs. >> >> I use an ARIN AS# to announce an IPv4 /24 cutout from an ISP block via >> BGP on all the ISP and peering links. Because it's multihomed, this is >> in full compliance with ARIN policy. Because it's impractical to >> filter announcements /24 and shorter, it works great. >> >> How do I get usable IPv6 addresses? >> > > As I mentioned above, if you can't pay your upstreams enough money to accept > PA /48s from each other, perhaps your application isn't high-value enough to > justify a routing table slot. ?In this case, I think it is, but as I > mentioned above, I think you should have to work that out with your > upstreams, not rely on ARIN to make them accept a whole bunch of lower-value > PI /48s. Translation: You don't want me to deploy IPv6. Okay. I won't. This is an example of how needs-based allocation gets you into real trouble real fast. As the gatekeeper, ARIN is stuck with this damned-if-you-do, damned-if-you-don't problem which in a dynamic system like 103 was solved with a trivial application of cash by those willing to spend it. If ARIN is to be the gatekeeper then ARIN policy must solve this problem. Full stop. >>> 6.2.3.5 ?Large (/28) >>> To qualify for a /28, an organization must demonstrate the need to make >>> assignments and/or reallocations equal to at least 20,000 /48s. >> >> Why not demonstrate that they -have made- at least 20,000 /48 >> assignments from their /32? > > That would be OK, but I was hoping to avoid having to make an ISP get a /32, > start using it, and then renumber everything into a /28 if they know from > the start they have more customers than will fit in a /32. Why would they renumber? Your proposal allows them to hold both a /32 and a /28. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From john.sweeting at twcable.com Wed Dec 23 14:24:21 2009 From: john.sweeting at twcable.com (Sweeting, John) Date: Wed, 23 Dec 2009 14:24:21 -0500 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <3c3e3fca0912231008x36b293fao35c46dad763ee303@mail.gmail.com> Message-ID: Hi Bill, I just want to share some of the information that was not provided in the explanation posted but was discussed at the AC's meeting and will be part of the minutes. The first motion was to Accept Proposal 103 on the docket. After much discussion it was voted down 5 For, 7 Against, 1 Abstention (there were 2 AC members absent). The main reasoning was that by putting it on the docket with the intention of major revisions, the AC was aborting the author's (and community's) right to petition. The second motion was to Abandon which carried unanimously. As the Chair I asked the 2 shepherds, David Farmer and Scott Leibrand, to please contact you, the author, and explain why the AC voted to abandon your proposal at this time. Another AC member requested that the 2 shepherds continue to work with the author to come up with a workable proposal and it was stated that they would. David and/or Scott should be working with you (and others) to try and work out the flaws. I have seen a lot of back and forth on this list so it seems to be what is happening. We, the AC, have no intentions of dropping this and I just wanted to state that on this list. Thanks and Happy Holidays, John On 12/23/09 1:08 PM, "William Herrin" wrote: On Wed, Dec 23, 2009 at 11:10 AM, Leo Bicknell wrote: > There seems to be a myth that policy ideas cannot be discussed > without a proposal on the table. I have no idea where that idea > originated, but it is demonstratibly false. For instance, every > face to face meeting has the "Open Policy Hour" specifically to > discuss things not on the table. PPML archives are filled with > discussions that either never resulted in policy, or were discussed > without a proposal for months or years before a proposal was put > forward. > > What having a proposal does is put requirements on the discussion. > Timelines. Presentations at meetings. These can be useful, but > also in the early days of a proposal can be harmful; rather than > letting the idea develop and turn into something good it is shoehorned > into a timeline. Leo, Disruptive proposals serve an intrinsic purpose simply by existing and demanding attention. Six months ago you killed proposal 92 on the basis that you wanted more time to consider small changes which might fix IPv6 policy's severe dysfunction. Without pressure from an active proposal, what have you accomplished with that time? > As for this particular proposal, it appeared to me it was not ripe. > Long proposals almost never pass, and not only is this one long but > it touches on many different areas. I believe in its current form > it has no chance of passing, as the details need to be refined, > simplified, and folks brought on board before there is a reason to > have a formal proposal. You've couched it better than Owen but you've basically said the same thing: the community won't want this, so why bother bringing it to the point where you ask them? The problem with that theory is two-fold: 1. Small changes are good but when small changes don't get the job done it's time to consider big changes. 2. The response 103 got on the PPML was heavily weighted towards the positive and comparable to other eventually-successful proposals in that phase of the process. YOU COULD BE MISTAKEN. The only way to know for sure is to take it to the meeting and ask. In the end you could be right. It could well go down in flames during the consensus call at the meeting. But even that serves a valuable purpose. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From owen at delong.com Wed Dec 23 15:17:26 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 23 Dec 2009 12:17:26 -0800 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <3c3e3fca0912222216s5dffd68fxfa5b5c11460533d5@mail.gmail.com> References: <73E11B6A-EB6F-4D02-8F2B-F9345F776644@delong.com> <3c3e3fca0912221701l4db11136h1721433b55cde89a@mail.gmail.com> <78E9E00B-5F61-4503-9F48-A50288544227@delong.com> <3c3e3fca0912222216s5dffd68fxfa5b5c11460533d5@mail.gmail.com> Message-ID: On Dec 22, 2009, at 10:16 PM, William Herrin wrote: > On Tue, Dec 22, 2009 at 10:29 PM, Owen DeLong wrote: >> The PDP tasks the AC with determining if a proposal could result in good >> policy. > > Yes, it does. At a much later point in the process: when the AC is > called upon to recommend for or against adoption by the board. But > hey, you know what's good for the community so let's take a shortcut > and skip the part where we ask the community what it wants. > The AC is tasked with making this decision about what we accept onto our docket as well. While I understand your perception, I really do not feel that I substituted my judgment for that of the community. Again, if you feel that there is community support to move this proposal forward and that the AC was wrong to abandon it, I encourage you to make use of the petition process. That's why it's there. > >> I do not know to what extent the other AC members who voted to abandon >> these proposals have the same reasons as I do for their votes. I am >> speaking only for myself, and, the above accusation is probably one >> of the reasons I am the only one who has spoken up so far about >> my reasons. > > I appreciate your honesty. I hope you're wrong about the other AC > members speaking up. No one likes taking abuse but you do sign up for > explaining yourself when you run for election to the AC. That's part > of the "public" in "public policy." > And I have explained myself. Whether you like my position or not, whether you think I did the right thing or not, I will at least do my best to explain it honestly. Owen From owen at delong.com Wed Dec 23 15:43:14 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 23 Dec 2009 12:43:14 -0800 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: References: Message-ID: > > > > Replacement text: > > 1.1. Number resources not to be considered property > > It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property. > > The policies in this document are based upon the understanding that globally-unique number resources are licensed for use rather than owned. Specifically, IP addresses and ASNs will be allocated and assigned on a license basis, with licenses subject to renewal on a periodic basis. The granting of a license is subject to specific conditions applied at the start or renewal of the license, as definied in the ARIN Registration Services Agreement. > > Note that when a license is renewed, the new license will be evaluated under and governed by the applicable number resource policies in place at the time of renewal, which may differ from the policy in place at the time of the original allocation or assignment. > I do not like the use of the term license, and, I think Steve Ryan would likely take issue with it as well. Personally, I think that the first paragraph is sufficient. The remaining two paragraphs simply restate (badly) what is in the RSA and do not need to be part of the NRPM. > > > 6.2. Policies for IPv6 allocations and assignments > > 6.2.1. Allocations and assignments > To meet the goal of Fairness, ARIN makes both allocations and assignments according to common criteria. Allocations are made to LIRs, and assignments to certain end users. > > 6.2.2. Assignments from LIRs/ISPs > End-users are assigned an end site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. > > The following guidelines may be useful (but they are only guidelines): > > * /64 when it is known that one and only one subnet is needed > * /56 for small sites, those expected to need only a few subnets over the next 5 years. > * /48 for larger sites > > For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation. > > ARIN is not concerned about which address size an LIR/ISP actually assigns. Accordingly, ARIN will not request the detailed information on IPv6 user networks as in IPv4, except for the purpose of measuring utilization as defined in this document. > This paragraph should be deleted. ARIN is concerned if you want to issue more than a /48 to an end site and should be able to review such large assignments. > 6.2.3. Allocations and assignments from ARIN > > 6.2.3.1 Goals > To balance the goals of Aggregation, Conservation, Fairness, and Minimized Overhead, ARIN normally makes allocations only in the discrete sizes of /48, /40, /32, /28, or /24 or larger. Each organization or discrete network may qualify for one allocation or assignment of each size, and must pay fees according to ARIN's fee schedule > for each size assigned. > The first "makes allocations" should either be "issues IPv6 addresses" or "makes allocations or assignments". The last "assigned" should either be "issued" or "assigned or allocated". > 6.2.3.2 X-Small (/48) > To qualify for a /48 allocation or assignment, an organization must: > * Serve at least 500 hosts, if multihomed; or > * Serve at least 1000 hosts; or > * Demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA; or > * Be a critical infrastructure provider of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA; or > * Qualify for a Micro-allocations for Internal Infrastructure per 6.3.3.2.2. > I would rather see this in the ~100 host range, if multihomed. I'm fine with 1000 hosts otherwise. There should not be any IPv4 requirement for getting IPv6 space. The efficient utilization of IPv4 resources as a determining factor for getting IPv6 resources should be removed in my opinion. > 6.2.3.2.1 Critical Infrastructure > Organizations qualified as critical infrastructure providers may be granted multiple /48 allocations in certain situations. Exchange point allocations MUST be allocated from specific blocks reserved only for this purpose. All other micro-allocations WILL be allocated out of other blocks reserved for micro-allocation purposes. ARIN will make a list of these blocks publicly available. Exchange point operators must provide justification for the allocation, including: connection policy, location, other participants (minimum of two total), ASN, and contact information. ISPs and other organizations receiving these micro-allocations will be charged under the ISP fee schedule, while end-users will be charged under the fee schedule for end-users. This policy does not preclude exchange point operators from requesting address space under other policies. > Why create a separate pool for exchange point allocations? > 6.2.3.2.2 Micro-allocations for Internal Infrastructure > Organizations that currently hold IPv6 allocations may apply for a /48 micro-allocation for internal infrastructure. Applicant must provide technical justification indicating why a separate non-routed block is required. Justification must include why a sub-allocation of currently held IP space cannot be utilized. Internal infrastructure allocations must be allocated from specific blocks reserved only for this purpose. > > 6.2.3.3 Small (/40) > To qualify for a /40 allocation or assignment, an organization must qualify for two or more /48s. > This is in direct conflict with the statement at the beginning that an organization can only qualify for one block of each size. This problem persists in your subsequent requirements to qualify for larger blocks as well. > 6.2.3.4 Medium (/32) > To qualify for a /32 allocation or assignment, an organization must: > * Qualify for 100 or more /48s; or > * Be an existing, known LIR; or > * Have a plan to provide IPv6 connectivity to other organizations and assign at least 100 end-site assignments to those organizations within 5 years. > > 6.2.3.5 Large (/28) > To qualify for a /28, an organization must demonstrate the need to make assignments and/or reallocations equal to at least 20,000 /48s. > > 6.2.3.6 X-Large (/24 or larger) > Allocations or assignments of /24 or larger may be made only in exceptional cases, to organizations that require more than a /28, and have submitted documentation that reasonably justifies the request. If approved, the allocation size will be based on the number of existing users and the extent of the organization's infrastructure. > > 6.3. Registration > > When an organization holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate (information registered by ARIN may be replaced by a distributed database for registering address management information in future). Information is registered in units of assigned /56 networks. When more than a /56 is assigned to an organization, the assigning organization is responsible for ensuring that the address space is registered in an ARIN database. > This is a major departure from current whois policy and I do not think that an overhaul of whois should be packaged with a major change to IPv6 policy. Please restore the current SWIP/rhwois requirements for publishing the data. I'm fine with registering IPv6 data in terms of /56s, but, what about cases where customers are issued /64s? There are 256 /64 customers in a single /56. > IRs shall maintain systems and practices that protect the security of personal and commercial information that is used in request evaluation, but which is not required for public registration. > I don't think this needs to be in the NRPM. I think that it is already addressed in other areas. > 6.3.1. Residential Customer Privacy (2003-3) > > 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. > > 6.3.2. Reverse lookup > > When ARIN delegates IPv6 address space to an organization, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organization should properly manage its reverse lookup zone. When making an address assignment, the organization must delegate to an assignee organization, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address. > I think this needs word-smithing, but, I'm at a loss to come up with something better at the moment. > Thoughts? See above. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bicknell at ufp.org Wed Dec 23 16:04:09 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 23 Dec 2009 13:04:09 -0800 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <3c3e3fca0912231008x36b293fao35c46dad763ee303@mail.gmail.com> References: <73E11B6A-EB6F-4D02-8F2B-F9345F776644@delong.com> <3c3e3fca0912221701l4db11136h1721433b55cde89a@mail.gmail.com> <20091223161046.GA71845@ussenterprise.ufp.org> <3c3e3fca0912231008x36b293fao35c46dad763ee303@mail.gmail.com> Message-ID: <20091223210409.GA96429@ussenterprise.ufp.org> In a message written on Wed, Dec 23, 2009 at 01:08:38PM -0500, William Herrin wrote: > You've couched it better than Owen but you've basically said the same > thing: the community won't want this, so why bother bringing it to the > point where you ask them? The problem with that theory is two-fold: You are putting words into my mouth. The community may well want this in the future, I have no reason to believe they will or they won't. > In the end you could be right. It could well go down in flames during > the consensus call at the meeting. But even that serves a valuable > purpose. There is still time for it to be on the agenda at the next meeting. Work the idea in the mailing list. Refine it. Resubmit. The AC saying "not ready yet" doesn't remotely imply the AC saying "never". If we ever have to say never I bet we will do that quite clearly. :) -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From scottleibrand at gmail.com Wed Dec 23 16:05:06 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Dec 2009 13:05:06 -0800 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: <3c3e3fca0912231052i4ffac09ew5a52e72ce8258f96@mail.gmail.com> References: <3c3e3fca0912230253x78027638l82bc102aee544edc@mail.gmail.com> <4B32523D.2020501@gmail.com> <3c3e3fca0912231052i4ffac09ew5a52e72ce8258f96@mail.gmail.com> Message-ID: <4B328602.2040706@gmail.com> On 12/23/2009 10:52 AM, William Herrin wrote: > On Wed, Dec 23, 2009 at 12:24 PM, Scott Leibrand > wrote: > >> On 12/23/2009 2:53 AM, William Herrin wrote: >> >>> Problems not resolved by your proposal: >>> >>> * Offers no IPv6 replacement for organizations with small but valuable >>> server infrastructures which today multihome with either a legacy >>> address block or a /24 ISP cutout. >>> >> If you have (or acquire via 8.3) a legacy address block, then you can >> qualify for a PI /48. >> >> If you multihome with a PA /24 today, the equivalent in v6 would be to >> multihome with a PA /48. >> > Hi Scott, > > There is no IPv6 equivalent to a multihomed IPv4 /24 PA cutout. Not in > this proposal with its classifications that enable strong disaggregate > filtering. Not in existing IPv6 policy that enables less effective > prefix filtering. Not in the IETF's recommendations. > > Convincing ISPs to accept /48 cutouts from each other is in direct > opposition to the classification for disaggregate management that your > proposal creates. > > Further, suggesting that policy can't fix it is a cop-out. Policy did > fix it in IPv4: by authorizing /24 cutouts for multihomed entities > regardless of size based on the knowledge that /24's are generally > routable. > I'm not sure what you think makes /24 PA in IPv4 special, then. It's not because ARIN policy allows ISPs to give them out: IPv6 PA /48s can be given out even more easily. Is it just because we have a swamp of legacy class C's that can't be filtered? > Successful ARIN IPv6 policy will have to create an IPv6 equivalent to > a multihomed IPv4 /24 PA cutout or else leave a well-funded class of > users with a solid technical basis for actively opposing IPv6 > deployment. > > I proposed (and we adopted) policy 2007-21 (https://www.arin.net/policy/proposals/2007_21.html) to address the issue of the class of users with legacy /24s who couldn't get IPv6 PI space. Maybe once I understand what aspects of IPv4 PA /24s need to be replicated in IPv6, I can better understand where current policy (and current proposals) fall short. >> This is not a theoretical problem: AFAIK Verizon >> has not yet started accepting the PI /48s ARIN is already allocating. If we >> give out PI /48s to anyone who wants to multihome, they (and others) will be >> even less likely to accept those. >> > Whether Verizon plays ball is another matter entirely. Your choices > there are threefold: > > 1. Bend ARIN policy to meet Verizon's will. You have a Verizon > representative on the AC so you'll have little problem learning their > requirements. > We understand their concerns (and share many of them), but there are a lot more small orgs demanding PI, so large orgs definitely don't have a veto. > 2. Ignore Verizon presuming that customer and government pressure will > eventually compel them to practices compatible with ARIN policy. This appears to be what will happen for the existing PI /48 policy. If we create a new set of filterable PI with more liberal rules, though, I'm pretty sure they (and other ISPs) will filter those for quite a while longer. > 3. Institute a policy like 103 in which Verizon and the other ISPs > intentionally have the power to make such filtering choices and > registrants can, with an application of cash, adjust their own > decisions to match. In other words, create a dynamic system and let it > find its natural balance point instead of trying to impose one from > on-high at the ARIN level. > > It's ironic that bottom-up is an important goal in the PDP but not in the NRPM. >>>> 6.2.3.2 X-Small (/48) >>>> To qualify for a /48 allocation or assignment, an organization must: >>>> * Serve at least 500 hosts, if multihomed; or >>>> * Serve at least 1000 hosts; or >>>> >>>> >>> IPv6 addressing is LAN-centric rather than host-centric. Accordingly I >>> suggest expressing this in terms of a number of LANs served. Perhaps >>> 50 or 100 LANs instead of 500 or 1000 hosts? >>> >>> >> Why is number of LANs a better metric than number of hosts to determine who >> deserves a routing slot? We're not really talking efficient utilization >> here, so I don't think number of LANs is relevant. Besides, I can create >> 100 VLANs on a single inexpensive switch. Creating 500 VMs (with running >> OSs) at least requires gear with more than a few dozen GB of RAM >> > You mean all I have to do for an IPv4 /22 is stand up 500 VMs? Damn, > I've been doing it the hard way. I just got my new 72 gig vmware > server too. > Heh, good luck with that. :-) Among other things, you'll need to demonstrate why those 500 VMs each need a unique public IP address. >> These numbers were adapted from existing IPv4 PI policy. Perhaps we should >> lower the numbers to better reflect the lower IPv4 requirements currently on >> the table. Perhaps 250 or 500 hosts? >> > It's just a quibble but hosts is IPv4-think. Subnets is consistent > with IPv6. There will be a certain degree of arbitrariness to any > selected numbers, but basing the count on subnets will make it > slightly less so. > Agreed that it's a minor point, which we can decide on when it comes time to iron out details. Either way would work. >>> At work I operate a ground station for a satellite constellation. The >>> non-IP satellite devices deliver messages to the ground station which >>> disperses them via the Internet. >>> >>> This very high value application uses 5 T1s from 5 different ISPs, a >>> 100 meg ISP link and a 100 meg peering link. It uses only a few score >>> hosts and a handful of LANs. >>> >>> I use an ARIN AS# to announce an IPv4 /24 cutout from an ISP block via >>> BGP on all the ISP and peering links. Because it's multihomed, this is >>> in full compliance with ARIN policy. Because it's impractical to >>> filter announcements /24 and shorter, it works great. >>> >>> How do I get usable IPv6 addresses? >>> >>> >> As I mentioned above, if you can't pay your upstreams enough money to accept >> PA /48s from each other, perhaps your application isn't high-value enough to >> justify a routing table slot. In this case, I think it is, but as I >> mentioned above, I think you should have to work that out with your >> upstreams, not rely on ARIN to make them accept a whole bunch of lower-value >> PI /48s. >> > Translation: You don't want me to deploy IPv6. Okay. I won't. > > This is an example of how needs-based allocation gets you into real > trouble real fast. As the gatekeeper, ARIN is stuck with this > damned-if-you-do, damned-if-you-don't problem which in a dynamic > system like 103 was solved with a trivial application of cash by those > willing to spend it. > > If ARIN is to be the gatekeeper then ARIN policy must solve this > problem. Full stop. > I think you're making an unfounded assumption that PI space is the only way to multihome. It is true today that PI space is (mostly) routable, because most ISPs see filtering PI space as more problematic than carrying it in their RIBs and FIBs. However, if PI space were given out like domain names, then that tradeoff would no longer hold. If, for example, we adopted 103 as written (with your suggested fee schedule), then /48s and probably even /40s would be filtered by a large number of ISPs, requiring everyone desiring global reachability to upgrade to a /32 or go back to PA space. On the other hand, the only thing I can see preventing ISPs from accepting PA /48s is the lack of market pressure to do so. If my paying customers want to multihome with PA /48s, I'll be happy to accept them from my customers, announce them to my peers and transit providers, and accept them from my peers and transit providers as well (for failover). If there's enough demand, I'm sure other ISPs will do so as well. If there's not enough demand, then maybe there's not enough demand to justify forcing ISPs to filter, either... >>>> 6.2.3.5 Large (/28) >>>> To qualify for a /28, an organization must demonstrate the need to make >>>> assignments and/or reallocations equal to at least 20,000 /48s. >>>> >>> Why not demonstrate that they -have made- at least 20,000 /48 >>> assignments from their /32? >>> >> That would be OK, but I was hoping to avoid having to make an ISP get a /32, >> start using it, and then renumber everything into a /28 if they know from >> the start they have more customers than will fit in a /32. >> > Why would they renumber? Your proposal allows them to hold both a /32 and a /28. Or they could keep both, but I'd rather not force them to have two blocks when one will do, either. -Scott From sethm at rollernet.us Wed Dec 23 16:10:12 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 23 Dec 2009 13:10:12 -0800 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: <3c3e3fca0912230253x78027638l82bc102aee544edc@mail.gmail.com> References: <3c3e3fca0912230253x78027638l82bc102aee544edc@mail.gmail.com> Message-ID: <4B328734.6050005@rollernet.us> William Herrin wrote: > On Wed, Dec 23, 2009 at 4:05 AM, Scott Leibrand wrote: >> Here's an attempt at how we might simplify IPv6 policy, incorporating many >> of the ideas we've discussed recently. It's much simpler than current >> policy, but is still quite long. It's also late, so I reserve the right to >> make mistakes, and to disagree with myself later. :-) > > > Hi Scott, > > I think your proposal offers a major improvement on existing IPv6 policy. > > > Problems addressed by your proposal: > > * Enables effective TE filtering where ISPs determine that > disaggregate TE is undesirable. > > * Unifies ISP/end-user policy so that all organizations are treated fairly > I'll disagree a tiny bit; I do think it's fair (and maybe we should) discriminate between sites that multihome and those that do not. The "200 users" policy and "what's an ISP" are harder to quantify. Whether or not a site is multihomed is a simple metric. ~Seth From scottleibrand at gmail.com Wed Dec 23 16:19:50 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Dec 2009 13:19:50 -0800 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: References: Message-ID: <4B328976.70209@gmail.com> On 12/23/2009 12:43 PM, Owen DeLong wrote: >> >> >> >> Replacement text: >> >> 1.1. Number resources not to be considered property >> >> It is contrary to the goals of this document and is not in the >> interests of the Internet community as a whole for address space to >> be considered freehold property. >> >> The policies in this document are based upon the understanding that >> globally-unique number resources are licensed for use rather than >> owned. Specifically, IP addresses and ASNs will be allocated and >> assigned on a license basis, with licenses subject to renewal on a >> periodic basis. The granting of a license is subject to specific >> conditions applied at the start or renewal of the license, as >> definied in the ARIN Registration Services Agreement. >> >> Note that when a license is renewed, the new license will be >> evaluated under and governed by the applicable number resource >> policies in place at the time of renewal, which may differ from the >> policy in place at the time of the original allocation or assignment. >> > I do not like the use of the term license, and, I think Steve Ryan > would likely take issue with it as well. > > Personally, I think that the first paragraph is sufficient. The > remaining two paragraphs simply restate > (badly) what is in the RSA and do not need to be part of the NRPM. I already deleted a couple extraneous paragraphs, and would be happy to trim further, once we've gotten to the point of getting a Legal review if not before. In any event, this is all in the existing NRPM already. >> ARIN is not concerned about which address size an LIR/ISP actually >> assigns. Accordingly, ARIN will not request the detailed information >> on IPv6 user networks as in IPv4, except for the purpose of measuring >> utilization as defined in this document. >> > This paragraph should be deleted. ARIN is concerned if you want to > issue more than a /48 to an end site and should > be able to review such large assignments. Ok. I like deleting unnecessary text. :-) >> 6.2.3. Allocations and assignments from ARIN >> >> 6.2.3.1 Goals >> To balance the goals of Aggregation, Conservation, Fairness, and >> Minimized Overhead, ARIN normally makes allocations only in the >> discrete sizes of /48, /40, /32, /28, or /24 or larger. Each >> organization or discrete network may qualify for one allocation or >> assignment of each size, and must pay fees according to ARIN's > href="https://www.arin.net/fees/fee_schedule.html">fee schedule >> for each size assigned. >> > The first "makes allocations" should either be "issues IPv6 addresses" > or "makes allocations or assignments". > The last "assigned" should either be "issued" or "assigned or allocated". Agreed. > >> 6.2.3.2 X-Small (/48) >> To qualify for a /48 allocation or assignment, an organization must: >> * Serve at least 500 hosts, if multihomed; or >> * Serve at least 1000 hosts; or >> * Demonstrate efficient utilization of all direct IPv4 assignments >> and allocations, each of which must be covered by any current ARIN >> RSA; or >> * Be a critical infrastructure provider of the Internet, including >> public exchange points, core DNS service providers (e.g. >> ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs >> and IANA; or >> * Qualify for a Micro-allocations for Internal Infrastructure per >> 6.3.3.2.2. >> > I would rather see this in the ~100 host range, if multihomed. I'm > fine with 1000 hosts otherwise. > > There should not be any IPv4 requirement for getting IPv6 space. The > efficient utilization of IPv4 resources as a determining > factor for getting IPv6 resources should be removed in my opinion. Note that this is an "or", so it's just another way to get space. Removing it would repeal 2007-21, which I don't think should be done until we're much further along in IPv6 deployment. > >> 6.2.3.2.1 Critical Infrastructure >> Organizations qualified as critical infrastructure providers may be >> granted multiple /48 allocations in certain situations. Exchange >> point allocations MUST be allocated from specific blocks reserved >> only for this purpose. All other micro-allocations WILL be allocated >> out of other blocks reserved for micro-allocation purposes. ARIN will >> make a list of these blocks publicly available. Exchange point >> operators must provide justification for the allocation, including: >> connection policy, location, other participants (minimum of two >> total), ASN, and contact information. ISPs and other organizations >> receiving these micro-allocations will be charged under the ISP fee >> schedule, while end-users will be charged under the fee schedule for >> end-users. This policy does not preclude exchange point operators >> from requesting address space under other policies. >> > Why create a separate pool for exchange point allocations? Cause that's what existing policy does. I'd be OK with deleting this, but didn't see a reason to. >> 6.2.3.2.2 Micro-allocations for Internal Infrastructure >> Organizations that currently hold IPv6 allocations may apply for a >> /48 micro-allocation for internal infrastructure. Applicant must >> provide technical justification indicating why a separate non-routed >> block is required. Justification must include why a sub-allocation of >> currently held IP space cannot be utilized. Internal infrastructure >> allocations must be allocated from specific blocks reserved only for >> this purpose. >> >> 6.2.3.3 Small (/40) >> To qualify for a /40 allocation or assignment, an organization must >> qualify for two or more /48s. >> > This is in direct conflict with the statement at the beginning that an > organization can only qualify for one block of each size. This problem > persists in your subsequent requirements to qualify for larger blocks > as well. The idea here is that if you qualify for a /48, you get one. If you qualify for more than one /48, you can't have a second, but you can have a /40 instead. I'd welcome suggestions for better ways to say that. >> 6.3. Registration >> >> When an organization holding an IPv6 address allocation makes IPv6 >> address assignments, it must register assignment information in a >> database, accessible by RIRs as appropriate (information registered >> by ARIN may be replaced by a distributed database for registering >> address management information in future). Information is registered >> in units of assigned /56 networks. When more than a /56 is assigned >> to an organization, the assigning organization is responsible for >> ensuring that the address space is registered in an ARIN database. >> > This is a major departure from current whois policy and I do not think > that an overhaul of whois > should be packaged with a major change to IPv6 policy. Please restore > the current SWIP/rhwois > requirements for publishing the data. > > I'm fine with registering IPv6 data in terms of /56s, but, what about > cases where customers are > issued /64s? There are 256 /64 customers in a single /56. This isn't a departure, this is a copy and paste (with minor edits) from existing policy (https://www.arin.net/policy/nrpm.html#six55) > >> IRs shall maintain systems and practices that protect the security of >> personal and commercial information that is used in request >> evaluation, but which is not required for public registration. >> > I don't think this needs to be in the NRPM. I think that it is > already addressed in other areas. It's in the current NRPM, but I'll be happy to remove it unless anyone thinks it needs to stay. (Like much of NRPM section 6, the globally coordinated policy restates a lot of policy from elsewhere, and some operational practice stuff as well.) >> 6.3.1. Residential Customer Privacy (2003-3) >> >> 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. >> >> 6.3.2. Reverse lookup >> >> When ARIN delegates IPv6 address space to an organization, it also >> delegates the responsibility to manage the reverse lookup zone that >> corresponds to the allocated IPv6 address space. Each organization >> should properly manage its reverse lookup zone. When making an >> address assignment, the organization must delegate to an assignee >> organization, upon request, the responsibility to manage the reverse >> lookup zone that corresponds to the assigned address. >> > I think this needs word-smithing, but, I'm at a loss to come up with > something better at the moment. Well, this too is existing NRPM text, so we don't have to fix it right now. Thanks for the feedback. I'd also like to hear anyone's general thoughts on the proposal as a whole, if you've formed an opinion on it yet. Thanks, Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From terry.l.davis at boeing.com Wed Dec 23 16:21:12 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Wed, 23 Dec 2009 13:21:12 -0800 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <20091223210409.GA96429@ussenterprise.ufp.org> References: <73E11B6A-EB6F-4D02-8F2B-F9345F776644@delong.com> <3c3e3fca0912221701l4db11136h1721433b55cde89a@mail.gmail.com> <20091223161046.GA71845@ussenterprise.ufp.org> <3c3e3fca0912231008x36b293fao35c46dad763ee303@mail.gmail.com> <20091223210409.GA96429@ussenterprise.ufp.org> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF55127B0919@XCH-NW-05V.nw.nos.boeing.com> All Maybe to open an old topic into the discussion again... Is there a good reason that ARIN doesn't pick 1 to 5 hubs in a province/state and assign a /32 or larger to them depending on their Internet population and then make sub-allocations from these region prefixes to smaller entities in that region? Huge amounts of the potential global routing tables could then be aggregated regionally with still gaining the ability allow small local sub-allocations for small entities without much impact to the global routing. Then from the regional aggregations could be broken up locally by ISP. And I'm fine with the idea that if the entity moves out of the regional then they do have to re-address or if they open branches in other regions, those branches get regional addressing based on their location. I probably missed something basic here and I know this has a problem with the preservation Internet "anonymity" but I think that concept actually died a long time ago; most of the web sites I visit anymore seem to even which city (it's pretty small) I live in already. Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Leo Bicknell > Sent: Wednesday, December 23, 2009 1:04 PM > To: ARIN PPML > Subject: Re: [arin-ppml] Abandonment of 103/104 > > In a message written on Wed, Dec 23, 2009 at 01:08:38PM -0500, William > Herrin wrote: > > You've couched it better than Owen but you've basically said the same > > thing: the community won't want this, so why bother bringing it to the > > point where you ask them? The problem with that theory is two-fold: > > You are putting words into my mouth. The community may well want > this in the future, I have no reason to believe they will or they > won't. > > > In the end you could be right. It could well go down in flames during > > the consensus call at the meeting. But even that serves a valuable > > purpose. > > There is still time for it to be on the agenda at the next meeting. > Work the idea in the mailing list. Refine it. Resubmit. The AC > saying "not ready yet" doesn't remotely imply the AC saying "never". > If we ever have to say never I bet we will do that quite clearly. > :) > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ From michael.dillon at bt.com Wed Dec 23 16:23:12 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 23 Dec 2009 21:23:12 -0000 Subject: [arin-ppml] efficient utilization != needs basis In-Reply-To: <14572.1261584231@marajade.sandelman.ca> Message-ID: <28E139F46D45AF49A31950F88C497458049FD988@E03MVZ2-UKDY.domain1.systemhost.net> > That's great for Ford or American Airlines. It's not just for big companies like Ford. Last time I looked the ANX connected over 4000 companies of all sizes that are part of the supply chain for the major auto manufacturers. I don't know how many companies are on the SITA network but it connects all international airports including small ones like YLW in Kelowna, British Columbia, Canada. It also connects all the international airlines, and some other supporting companies. The BT Radianz network connects over 10,000 sites around the globe that are part of the Global Financial Services Industry. Roughly 250 companies on the Radianz network are service providers that are analogous to the big hosting sites on the public Internet. Those are the three COIN's that I know about, but there may be others. > That's totally ridiculous for linking the 7 locations of > Bob-DryCleaning's together over $200 VPN. Of course you are right. I wasn't suggesting that any handful of companies who need to communicate need special treatment and in particular, I am talking about COINs which bypass the Internet, i.e. they primarily have separate infrastructure not just a VPN overlay on the public Internet. Such COINs actually provide a service to the Internet community by taking traffic off the public Internet and slowing the rate of growth to give vendors and operators time to react to growth. Note also that a community of interest network does not bypass network operators. In fact, network operators build and operate separate infrastructure for the COINs. > The big guys do not have a problem --- look the government > of germany just got a /26. No big deal for them to parcel > off a /32 for use on some COIN. That's another good point. We have no scarcity of IPv6 addresses so if an organization needs a much larger block than a /32 to build their network, they can get it. This time around we have enough address space to handle all global and local telecommunications needs of the whole planet even if the population continues growing and 3rd world countries build the same infrastructure per person as the 1st world. In other words, there is no need to skimp. If you have big plans, and they are realistic plans, then ARIN should give you the allocation needed to make those plans a reality. We still should ask applicants to demonstrate operational need for the allocation and justify the magnitude of the allocation as well. > It's the small guys that will have a problem --- and it > will be the small guys that will deploy useful things first. The jury is out on that one. The Internet is no longer the weird new technology out in left field. It is the heart of all communications infrastructure and everyone now realises this. --Michael Dillon P.S. there has recently been some discussion in RIPE of a new transitional technology called 6RD that requires a much larger ISP allocation than would otherwise be justified to map the entire IPv4 address space into one ISP's allocation. This is an example of operational need where the fact of using 6RD demonstrates an operational need for a bigger than normal allocation. In the discussion people were generally in favor of these big IPv6 allocations even if it meant giving a large ISP a whole /21 block just for 6RD. From michael.dillon at bt.com Wed Dec 23 16:29:27 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 23 Dec 2009 21:29:27 -0000 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: <3c3e3fca0912231052i4ffac09ew5a52e72ce8258f96@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C497458049FD98A@E03MVZ2-UKDY.domain1.systemhost.net> > 3. Institute a policy like 103 in which Verizon and the other > ISPs intentionally have the power to make such filtering > choices and registrants can, with an application of cash, > adjust their own decisions to match. In other words, create a > dynamic system and let it find its natural balance point > instead of trying to impose one from on-high at the ARIN level. In my opinion, it is not within ARIN's scope to give any ISP any sort of permission regarding filtering, nor is it within ARINs scope to prohibit any ISP from any operational activities that are not directly related to managing a shared global address pool. --Michael Dillon From scottleibrand at gmail.com Wed Dec 23 16:32:29 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Dec 2009 13:32:29 -0800 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: <4B328734.6050005@rollernet.us> References: <3c3e3fca0912230253x78027638l82bc102aee544edc@mail.gmail.com> <4B328734.6050005@rollernet.us> Message-ID: <4B328C6D.3060701@gmail.com> On 12/23/2009 1:10 PM, Seth Mattinen wrote: > William Herrin wrote: >> >> >> Hi Scott, >> >> I think your proposal offers a major improvement on existing IPv6 >> policy. >> >> >> Problems addressed by your proposal: >> >> * Enables effective TE filtering where ISPs determine that >> disaggregate TE is undesirable. >> >> * Unifies ISP/end-user policy so that all organizations are treated >> fairly >> > > I'll disagree a tiny bit; I do think it's fair (and maybe we should) > discriminate between sites that multihome and those that do not. The > "200 users" policy and "what's an ISP" are harder to quantify. Whether > or not a site is multihomed is a simple metric. I think this proposal preserves the multihomed / non-multihomed distinction (while eliminating the distinction between multihomed ISPs and multihomed end user networks, for example). Do you feel that the proposal makes / fails to make any distinctions it shouldn't/should? I'm looking forward to your feedback on the proposal itself. Thanks, Scott From scottleibrand at gmail.com Wed Dec 23 16:34:18 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Dec 2009 13:34:18 -0800 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B0919@XCH-NW-05V.nw.nos.boeing.com> References: <73E11B6A-EB6F-4D02-8F2B-F9345F776644@delong.com> <3c3e3fca0912221701l4db11136h1721433b55cde89a@mail.gmail.com> <20091223161046.GA71845@ussenterprise.ufp.org> <3c3e3fca0912231008x36b293fao35c46dad763ee303@mail.gmail.com> <20091223210409.GA96429@ussenterprise.ufp.org> <0267B5481DCC474D8088BF4A25C7F1DF55127B0919@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <4B328CDA.9050301@gmail.com> Terry, In order for that to work, some network must announce the aggregate /32, and provide Internet service to all the smaller entities being numbered out of it. That is essentially what an ISP/LIR does. If you'd like to start such an ISP, you could easily qualify for an IPv6 /32 under existing policy for LIRs. -Scott On 12/23/2009 1:21 PM, Davis, Terry L wrote: > All > > Maybe to open an old topic into the discussion again... > > Is there a good reason that ARIN doesn't pick 1 to 5 hubs in a province/state and assign a /32 or larger to them depending on their Internet population and then make sub-allocations from these region prefixes to smaller entities in that region? > > Huge amounts of the potential global routing tables could then be aggregated regionally with still gaining the ability allow small local sub-allocations for small entities without much impact to the global routing. Then from the regional aggregations could be broken up locally by ISP. > > And I'm fine with the idea that if the entity moves out of the regional then they do have to re-address or if they open branches in other regions, those branches get regional addressing based on their location. > > I probably missed something basic here and I know this has a problem with the preservation Internet "anonymity" but I think that concept actually died a long time ago; most of the web sites I visit anymore seem to even which city (it's pretty small) I live in already. > > Take care > Terry > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Leo Bicknell >> Sent: Wednesday, December 23, 2009 1:04 PM >> To: ARIN PPML >> Subject: Re: [arin-ppml] Abandonment of 103/104 >> >> In a message written on Wed, Dec 23, 2009 at 01:08:38PM -0500, William >> Herrin wrote: >> >>> You've couched it better than Owen but you've basically said the same >>> thing: the community won't want this, so why bother bringing it to the >>> point where you ask them? The problem with that theory is two-fold: >>> >> You are putting words into my mouth. The community may well want >> this in the future, I have no reason to believe they will or they >> won't. >> >> >>> In the end you could be right. It could well go down in flames during >>> the consensus call at the meeting. But even that serves a valuable >>> purpose. >>> >> There is still time for it to be on the agenda at the next meeting. >> Work the idea in the mailing list. Refine it. Resubmit. The AC >> saying "not ready yet" doesn't remotely imply the AC saying "never". >> If we ever have to say never I bet we will do that quite clearly. >> :) >> >> -- >> Leo Bicknell - bicknell at ufp.org - CCIE 3440 >> PGP keys at http://www.ufp.org/~bicknell/ >> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From bill at herrin.us Wed Dec 23 16:40:35 2009 From: bill at herrin.us (William Herrin) Date: Wed, 23 Dec 2009 16:40:35 -0500 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: <4B328602.2040706@gmail.com> References: <3c3e3fca0912230253x78027638l82bc102aee544edc@mail.gmail.com> <4B32523D.2020501@gmail.com> <3c3e3fca0912231052i4ffac09ew5a52e72ce8258f96@mail.gmail.com> <4B328602.2040706@gmail.com> Message-ID: <3c3e3fca0912231340h5dbc7a0flf71ee8802bbdc3c1@mail.gmail.com> On Wed, Dec 23, 2009 at 4:05 PM, Scott Leibrand wrote: > On 12/23/2009 10:52 AM, William Herrin wrote: >> There is no IPv6 equivalent to a multihomed IPv4 /24 PA cutout. Not in >> this proposal with its classifications that enable strong disaggregate >> filtering. Not in existing IPv6 policy that enables less effective >> prefix filtering. Not in the IETF's recommendations. >> > >> Convincing ISPs to accept /48 cutouts from each other is in direct >> opposition to the classification for disaggregate management that your >> proposal creates. >> >> Further, suggesting that policy can't fix it is a cop-out. Policy did >> fix it in IPv4: by authorizing /24 cutouts for multihomed entities >> regardless of size based on the knowledge that /24's are generally >> routable. >> > > I'm not sure what you think makes /24 PA in IPv4 special, then. ?It's not > because ARIN policy allows ISPs to give them out: IPv6 PA /48s can be given > out even more easily. ?Is it just because we have a swamp of legacy class > C's that can't be filtered? Hi Scott, It's because of 4.2.3.6 -combined with- the accurate expectation that /24's are individually routable. Only in combination do these two elements result in a functional technical solution. Even then it's suboptimal; we'd be better off if ARIN gave out the /24. Some things in BGP have subtle differences when its a cutout instead of a distinct block. But I digress... There is no expectation that a /48 cutout will be individually routable and the policy appears to be evolving further from that sort of use. Thus ARIN IPv6 policy needs an element functionally comparable to the combination of 4.2.3.6 and IPv4 prefix filtering best practices. >> Successful ARIN IPv6 policy will have to create an IPv6 equivalent to >> a multihomed IPv4 /24 PA cutout or else leave a well-funded class of >> users with a solid technical basis for actively opposing IPv6 >> deployment. > > I proposed (and we adopted) policy 2007-21 > (https://www.arin.net/policy/proposals/2007_21.html) to address the issue of > the class of users with legacy /24s who couldn't get IPv6 PI space. ?Maybe > once I understand what aspects of IPv4 PA /24s need to be replicated in > IPv6, I can better understand where current policy (and current proposals) > fall short. I remember having something to do with that. ;) Hopefully my explanation above helps. >> Translation: You don't want me to deploy IPv6. Okay. I won't. >> >> This is an example of how needs-based allocation gets you into real >> trouble real fast. As the gatekeeper, ARIN is stuck with this >> damned-if-you-do, damned-if-you-don't problem which in a dynamic >> system like 103 was solved with a trivial application of cash by those >> willing to spend it. >> >> If ARIN is to be the gatekeeper then ARIN policy must solve this >> problem. Full stop. >> > > I think you're making an unfounded assumption that PI space is the only way > to multihome. ?It is true today that PI space is (mostly) routable, because > most ISPs see filtering PI space as more problematic than carrying it in > their RIBs and FIBs. ?However, if PI space were given out like domain names, > then that tradeoff ?would no longer hold. ?If, for example, we adopted 103 > as written (with your suggested fee schedule), then /48s and probably even > /40s would be filtered by a large number of ISPs, requiring everyone > desiring global reachability to upgrade to a /32 or go back to PA space. > > On the other hand, the only thing I can see preventing ISPs from accepting > PA /48s is the lack of market pressure to do so. It all comes back to filtering. When I see a disaggregate /48 cut out of an ISP's /32, I can't tell whether it's a multihomed customer (that I need to carry) or traffic engineering (which will work out OK even if I drop it). The price for strong TE filtering is that multihomed PA cutouts have to be replaced with PI. Can't have both. That's just the character of the technology. IMHO, the potential for TE filtering is too valuable to give up and PA cutouts never worked very well to begin with. They should be replaced with PI. >>>>> 6.2.3.5 ?Large (/28) >>>>> To qualify for a /28, an organization must demonstrate the need to make >>>>> assignments and/or reallocations equal to at least 20,000 /48s. >> Why would they renumber? Your proposal allows them to hold both a /32 and >> a /28. > Or they could keep both, but I'd rather not force them to have two blocks > when one will do, either. I don't see any harm in starting with "demonstrate the need" and changing it if a lot of ISPs "demonstrate" a need they doesn't match their deployment. On Wed, Dec 23, 2009 at 3:43 PM, Owen DeLong wrote: >> 6.2.3.3 Small (/40) >> To qualify for a /40 allocation or assignment, an organization must qualify >> for two or more /48s. > > This is in direct conflict with the statement at the beginning that an > organization can only qualify for one block > of each size. This problem persists in your subsequent requirements to > qualify for larger blocks as well. Hi Owen, I don't see the issue. At 500 hosts you're qualified for a /48. At 1000 (or having received an order to provide service to a downstream customer) you'd be qualified for two if two was allowed and thus a /40. Or is it just a wordsmithing gripe? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scottleibrand at gmail.com Wed Dec 23 16:44:47 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Dec 2009 13:44:47 -0800 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: <28E139F46D45AF49A31950F88C497458049FD98A@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458049FD98A@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <3698DCA2-C28F-4478-A67D-DB8FC5FCD25C@gmail.com> On Dec 23, 2009, at 1:29 PM, wrote: > >> 3. Institute a policy like 103 in which >> ISPs intentionally have the power to make such filtering >> choices and registrants can, with an application of cash, >> adjust their own decisions to match. In other words, create a >> dynamic system and let it find its natural balance point >> instead of trying to impose one from on-high at the ARIN level. > > In my opinion, it is not within ARIN's scope to give any > ISP any sort of permission regarding filtering, nor is > it within ARINs scope to prohibit any ISP from any operational > activities that are not directly related to managing a > shared global address pool. I think we agree on that. What we're discussing is the interaction of ARIN numbering policy and the likely responses of ISPs, which are quite relevant to the usefulness of the resources ARIN gives out. What IPv6 policy would you favor here? Thanks, Scott From michael.dillon at bt.com Wed Dec 23 16:46:36 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 23 Dec 2009 21:46:36 -0000 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B0919@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <28E139F46D45AF49A31950F88C497458049FD98D@E03MVZ2-UKDY.domain1.systemhost.net> > Is there a good reason that ARIN doesn't pick 1 to 5 hubs in > a province/state and assign a /32 or larger to them depending > on their Internet population and then make sub-allocations > from these region prefixes to smaller entities in that region? When I suggested something like this, the feeling was that the IETF would have to bless it first. My idea was for the IETF to give each RIR a block that was big enough to carve out one suballocation region for each of the world's major cities that are within the RIR's region. If possible, those city allocations would be aggregated into clusters of cities that were close to each other, for instance New York and Montreal and Boston would be in the same cluster, San Francisco, Las Vegas, LA, and Tijuana in another. That sort of thing. The basic rationale was that the world's physical network links tend to converge on a small number of major cities, somewhere between 100 to 1000 cities depending on how fine you want to slice it. And the small organizations that want to multihome typically either want to stay in the same building and change local providers, or move to another site in the same metro area, possibly with a new provider. There's a lot more to it than that, but if the RIRs would implement such a scenario, it would add 1000 new city-aggregate routes to the DFZ, and would give end users the option of PA, PI or CA (City Aggregate) addressing. The existing PA and PI allocations would be unchanged, and no doubt, some providers would ignore CA altogether and it would be more popular in some cities than in others. If we did implement this, then there is no longer any good reason for the ITU to call for country allocations because, for instance, half the CA address users in the Strasbourg, France aggregate would be located across the river in Germany. Maybe Tijuana would be part of a San Diego aggregate. > Huge amounts of the potential global routing tables could > then be aggregated regionally with still gaining the ability > allow small local sub-allocations for small entities without > much impact to the global routing. Then from the regional > aggregations could be broken up locally by ISP. Exactly my point. Perhaps the time has come to take another serious look at it. As I recall last time, there were no substantive technical issues with doing this. The biggest problem people had was that it was not guaranteed to work unless imposed from above, and then people attacked that strawman of "imposed from above". I always viewed it as an experiment of sorts where we make the address space available to those organizations who want to try and make City Aggregate work. Even if it only works in half the major cities of the planet, that is 500 cities that are not spewing new entries into the DFZ. In my opinion, there is no grand solution to DFZ growth, just a bunch of small improvements that slow DFZ growth and when all of these small improvements are combined, they keep DFZ growth manageable. Maybe in 10 years from now the RRG and IETF work will come to fruition and we will have a grand solution, maybe not. > And I'm fine with the idea that if the entity moves out of > the regional then they do have to re-address or if they open > branches in other regions, those branches get regional > addressing based on their location. Yes. There is not point in asking an improvement to be perfect and to deliver 100% of the desired benefits. If it works for over 80% of the cases, then it is worth doing. --Michael Dillon P.S. I will work with anyone who wants to hone this idea into an Internet draft. From michael.dillon at bt.com Wed Dec 23 16:50:07 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 23 Dec 2009 21:50:07 -0000 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: <3698DCA2-C28F-4478-A67D-DB8FC5FCD25C@gmail.com> Message-ID: <28E139F46D45AF49A31950F88C497458049FD98E@E03MVZ2-UKDY.domain1.systemhost.net> > What IPv6 policy would you favor here? I favor an IPv6 policy that makes sense and one in which ISPs could feasibly change their filtering rules to accomodate the new policy. I would not worry about which ISP acts first and which ones wait and see for a year or so. If the policy is sensible, then everyone will eventually fall in line, more or less. We had this same discussion when I was on the AC and we wanted to reduce the minimum ISP allocation from /19 to /20. I believed that ISPs would eventually change their filters. And they did, eventually. --Michael Dillon From scottleibrand at gmail.com Wed Dec 23 17:06:06 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Dec 2009 14:06:06 -0800 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: References: <3698DCA2-C28F-4478-A67D-DB8FC5FCD25C@gmail.com> <28E139F46D45AF49A31950F88C497458049FD98E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On Wed, Dec 23, 2009 at 1:50 PM, wrote: > > > What IPv6 policy would you favor here? > > I favor an IPv6 policy that makes sense and one in > which ISPs could feasibly change their filtering > rules to accomodate the new policy. I would not > worry about which ISP acts first and which ones > wait and see for a year or so. If the policy is > sensible, then everyone will eventually fall > in line, more or less. > > We had this same discussion when I was on the > AC and we wanted to reduce the minimum ISP > allocation from /19 to /20. I believed that > ISPs would eventually change their filters. > And they did, eventually. > Ok, so sounds like you'd support a lot of the minor changes being proposed. What about the major rewrites of IPv6 policy, like Bill's proposal 103, and my rewrite of some of the same ideas? Thanks, Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Wed Dec 23 17:04:47 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Dec 2009 14:04:47 -0800 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: <3c3e3fca0912231340h5dbc7a0flf71ee8802bbdc3c1@mail.gmail.com> References: <3c3e3fca0912230253x78027638l82bc102aee544edc@mail.gmail.com> <4B32523D.2020501@gmail.com> <3c3e3fca0912231052i4ffac09ew5a52e72ce8258f96@mail.gmail.com> <4B328602.2040706@gmail.com> <3c3e3fca0912231340h5dbc7a0flf71ee8802bbdc3c1@mail.gmail.com> Message-ID: On Wed, Dec 23, 2009 at 1:40 PM, William Herrin wrote: > On Wed, Dec 23, 2009 at 4:05 PM, Scott Leibrand > wrote: > > On 12/23/2009 10:52 AM, William Herrin wrote: > >> There is no IPv6 equivalent to a multihomed IPv4 /24 PA cutout. Not in > >> this proposal with its classifications that enable strong disaggregate > >> filtering. Not in existing IPv6 policy that enables less effective > >> prefix filtering. Not in the IETF's recommendations. > >> > >> Further, suggesting that policy can't fix it is a cop-out. Policy did > >> fix it in IPv4: by authorizing /24 cutouts for multihomed entities > >> regardless of size based on the knowledge that /24's are generally > >> routable. > >> > > > > I'm not sure what you think makes /24 PA in IPv4 special, then. It's not > > because ARIN policy allows ISPs to give them out: IPv6 PA /48s can be > given > > out even more easily. Is it just because we have a swamp of legacy class > > C's that can't be filtered? > > Hi Scott, > > It's because of 4.2.3.6 -combined with- the accurate expectation that > /24's are individually routable. Only in combination do these two > elements result in a functional technical solution. Even then it's > suboptimal; we'd be better off if ARIN gave out the /24. Some things > in BGP have subtle differences when its a cutout instead of a distinct > block. But I digress... > > There is no expectation that a /48 cutout will be individually > routable and the policy appears to be evolving further from that sort > of use. Thus ARIN IPv6 policy needs an element functionally comparable > to the combination of 4.2.3.6 and IPv4 prefix filtering best > practices. > Got it, thanks. > > >> Successful ARIN IPv6 policy will have to create an IPv6 equivalent to > >> a multihomed IPv4 /24 PA cutout or else leave a well-funded class of > >> users with a solid technical basis for actively opposing IPv6 > >> deployment. > > > > I proposed (and we adopted) policy 2007-21 > > (https://www.arin.net/policy/proposals/2007_21.html) to address the > issue of > > the class of users with legacy /24s who couldn't get IPv6 PI space. > Maybe > > once I understand what aspects of IPv4 PA /24s need to be replicated in > > IPv6, I can better understand where current policy (and current > proposals) > > fall short. > > I remember having something to do with that. ;) Hopefully my > explanation above helps. > Heh. I thought you might've been, but couldn't remember. :-) > > > On the other hand, the only thing I can see preventing ISPs from > accepting > > PA /48s is the lack of market pressure to do so. > > It all comes back to filtering. When I see a disaggregate /48 cut out > of an ISP's /32, I can't tell whether it's a multihomed customer (that > I need to carry) or traffic engineering (which will work out OK even > if I drop it). > > The price for strong TE filtering is that multihomed PA cutouts have > to be replaced with PI. Can't have both. That's just the character of > the technology. > > IMHO, the potential for TE filtering is too valuable to give up and PA > cutouts never worked very well to begin with. They should be replaced > with PI. > Ok, that's a good way to look at it. In exchange for reasonably-assured TE filterability, we give out PI space to anyone who has a need to multihome, and they can be reasonably assured that those prefixes will mostly be accepted. A grand bargain: I hope it would work. Let me go see what I can do to make my proposal accomplish the policy portion of that... Thanks, Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Wed Dec 23 17:32:06 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Dec 2009 14:32:06 -0800 Subject: [arin-ppml] Updated text for Simplified IPv6 Policy Message-ID: <4B329A66.2010306@gmail.com> Below is an updated copy of my Simplified IPv6 Policy proposal, which takes into account suggestions made on the list so far. Thoughts? -Scott Delete "6.1 Introduction" /This is all historical./ Delete "6.2 Definitions" /The definitions we need are all defined in section 2./ Leave 6.3 as is (renumber to 6.1) /I think these still accurately reflect the Goals we want our policy to follow./ Move 6.4.1 to 1.1. Retitle to "Number resources not to be considered property" and update text per below. /This is a principle more general than just IPv6, and needs to be updated to be ARIN-specific and refer to the RSA./ Delete 6.4.2 - 6.4.4 /These principles don't seem worthy of elevation to special status./ Replace 6.5 Policies for allocations and assignments with text below (renumber to 6.2) /This seems to be where most of the changes and simplification are needed./ Delete 6.6 References /This is all historical, and doesn't need to be part of the NRPM./ Delete 6.7 Appendix A: HD-Ratio /We can let the HD-Ratio guide policy without making people like David's grandma do the math./ Delete 6.8. Appendix B: Background information /This is all historical/ Move 6.9 and 6.10 into 6.2.3.2 below Replacement text: 1.1. Number resources not to be considered property It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property. The policies in this document are based upon the understanding that globally-unique number resources are licensed for use rather than owned. Specifically, IP addresses and ASNs will be allocated and assigned as defined in the ARIN Registration Services Agreement. 6.2. Policies for IPv6 allocations and assignments 6.2.1. Allocations and assignments To meet the goal of Fairness, ARIN makes both allocations and assignments according to common criteria. Allocations are made to LIRs, and assignments to certain end users. 6.2.2. Assignments from LIRs/ISPs End-users are assigned an end site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): * /64 when it is known that one and only one subnet is needed * /56 for small sites, those expected to need only a few subnets over the next 5 years. * /48 for larger sites For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation. 6.2.3. Allocations and assignments from ARIN 6.2.3.1 Goals To balance the goals of Aggregation, Conservation, Fairness, and Minimized Overhead, ARIN normally issues IPv6 addresses only in the discrete sizes of /48, /40, /32, /28, or /24 or larger. Each organization or discrete network may qualify for one allocation or assignment of each size, and must pay fees according to ARIN's fee schedule [1] for each size issued. 6.2.3.2 X-Small (/48) To qualify for a /48 allocation or assignment, an organization must: * Be multihomed, per section 2.7, and qualify for an ASN per section 5; or * Serve at least 1000 hosts; or * Demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA; or * Qualify for a Micro-allocations for Internal Infrastructure per 6.2.3.2.1. 6.2.3.2.1 Micro-allocations for Internal Infrastructure /(Copied from NRPM 6.10.2)/ Organizations that currently hold IPv6 allocations may apply for a /48 micro-allocation for internal infrastructure. Applicant must provide technical justification indicating why a separate non-routed block is required. Justification must include why a sub-allocation of currently held IP space cannot be utilized. Internal infrastructure allocations must be allocated from specific blocks reserved only for this purpose. 6.2.3.3 Small (/40) To qualify for a /40 allocation or assignment, an organization must qualify for two or more /48s. 6.2.3.4 Medium (/32) To qualify for a /32 allocation or assignment, an organization must: * Qualify for 100 or more /48s; or * Be an existing, known LIR; or * Have a plan to provide IPv6 connectivity to other organizations and assign at least 100 end-site assignments to those organizations within 5 years. 6.2.3.5 Large (/28) To qualify for a /28, an organization must demonstrate the need to make assignments and/or reallocations equal to at least 20,000 /48s. 6.2.3.6 X-Large (/24 or larger) Allocations or assignments of /24 or larger may be made only in exceptional cases, to organizations that require more than a /28, and have submitted documentation that reasonably justifies the request. If approved, the allocation size will be based on the number of existing users and the extent of the organization's infrastructure. 6.3. Registration /(Copied from NRPM 6.5.5)/ When an organization holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate (information registered by ARIN may be replaced by a distributed database for registering address management information in future). Information is registered in units of assigned /56 networks. When more than a /56 is assigned to an organization, the assigning organization is responsible for ensuring that the address space is registered in an ARIN database. 6.3.1. Residential Customer Privacy /(Copied from NRPM 6.5.5.1)/ 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. 6.3.2. Reverse lookup /(Copied from NRPM 6.5.6)/ When ARIN delegates IPv6 address space to an organization, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organization should properly manage its reverse lookup zone. When making an address assignment, the organization must delegate to an assignee organization, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address. -------------- next part -------------- An HTML attachment was scrubbed... URL: From terry.l.davis at boeing.com Wed Dec 23 18:00:04 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Wed, 23 Dec 2009 15:00:04 -0800 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <28E139F46D45AF49A31950F88C497458049FD98D@E03MVZ2-UKDY.domain1.systemhost.net> References: <0267B5481DCC474D8088BF4A25C7F1DF55127B0919@XCH-NW-05V.nw.nos.boeing.com> <28E139F46D45AF49A31950F88C497458049FD98D@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF55127B091A@XCH-NW-05V.nw.nos.boeing.com> Michael Thanks. I didn't recall the original proposer of the concept, it was what 5 or 6 years ago? But yes this is what I was referring to. Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of michael.dillon at bt.com > Sent: Wednesday, December 23, 2009 1:47 PM > To: ppml at arin.net > Subject: Re: [arin-ppml] Abandonment of 103/104 > > > Is there a good reason that ARIN doesn't pick 1 to 5 hubs in > > a province/state and assign a /32 or larger to them depending > > on their Internet population and then make sub-allocations > > from these region prefixes to smaller entities in that region? > > When I suggested something like this, the feeling was that > the IETF would have to bless it first. My idea was for the > IETF to give each RIR a block that was big enough to carve > out one suballocation region for each of the world's major > cities that are within the RIR's region. If possible, those > city allocations would be aggregated into clusters of cities > that were close to each other, for instance New York and > Montreal and Boston would be in the same cluster, San Francisco, > Las Vegas, LA, and Tijuana in another. That sort of thing. > > The basic rationale was that the world's physical network > links tend to converge on a small number of major cities, > somewhere between 100 to 1000 cities depending on how fine > you want to slice it. And the small organizations that want > to multihome typically either want to stay in the same > building and change local providers, or move to another > site in the same metro area, possibly with a new provider. > > There's a lot more to it than that, but if the RIRs would > implement such a scenario, it would add 1000 new city-aggregate > routes to the DFZ, and would give end users the option of > PA, PI or CA (City Aggregate) addressing. The existing PA > and PI allocations would be unchanged, and no doubt, some > providers would ignore CA altogether and it would be more > popular in some cities than in others. > > If we did implement this, then there is no longer any > good reason for the ITU to call for country allocations > because, for instance, half the CA address users in > the Strasbourg, France aggregate would be located > across the river in Germany. Maybe Tijuana would be > part of a San Diego aggregate. > > > Huge amounts of the potential global routing tables could > > then be aggregated regionally with still gaining the ability > > allow small local sub-allocations for small entities without > > much impact to the global routing. Then from the regional > > aggregations could be broken up locally by ISP. > > Exactly my point. Perhaps the time has come to take another > serious look at it. As I recall last time, there were no > substantive technical issues with doing this. The biggest > problem people had was that it was not guaranteed to work > unless imposed from above, and then people attacked that > strawman of "imposed from above". I always viewed it as > an experiment of sorts where we make the address space > available to those organizations who want to try and > make City Aggregate work. Even if it only works in half > the major cities of the planet, that is 500 cities that > are not spewing new entries into the DFZ. > > In my opinion, there is no grand solution to DFZ growth, > just a bunch of small improvements that slow DFZ growth > and when all of these small improvements are combined, > they keep DFZ growth manageable. Maybe in 10 years from > now the RRG and IETF work will come to fruition and we > will have a grand solution, maybe not. > > > And I'm fine with the idea that if the entity moves out of > > the regional then they do have to re-address or if they open > > branches in other regions, those branches get regional > > addressing based on their location. > > Yes. There is not point in asking an improvement to be > perfect and to deliver 100% of the desired benefits. > If it works for over 80% of the cases, then it is worth > doing. > > --Michael Dillon > > P.S. I will work with anyone who wants to hone this idea > into an Internet draft. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From scottleibrand at gmail.com Wed Dec 23 18:22:02 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Dec 2009 15:22:02 -0800 Subject: [arin-ppml] Updated text for Simplified IPv6 Policy In-Reply-To: <17838240D9A5544AAA5FF95F8D520316074E7752@ad-exh01.adhost.lan> References: <4B329A66.2010306@gmail.com> <17838240D9A5544AAA5FF95F8D520316074E7752@ad-exh01.adhost.lan> Message-ID: <4B32A61A.2040906@gmail.com> On 12/23/2009 3:13 PM, Michael K. Smith - Adhost wrote: > > Hey Scott: > > I've got some more comments for you below, with the understanding that > I'm supporting the concept. > Thanks for the feedback. > *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > *On Behalf Of *Scott Leibrand > *Sent:* Wednesday, December 23, 2009 2:32 PM > *To:* PPML > *Subject:* [arin-ppml] Updated text for Simplified IPv6 Policy > > > Replacement text: > > 1.1. Number resources not to be considered property > > It is contrary to the goals of this document and is not in the > interests of the Internet community as a whole for address space to be > considered freehold property. > > The policies in this document are based upon the understanding that > globally-unique number resources are licensed for use rather than > owned. Specifically, IP addresses and ASNs will be allocated and > assigned as defined in the ARIN Registration Services Agreement. > > Remove the first sentence entirely. The second paragraph sums it up > nicely without giving it an emotional underpinning. Also, freehold has > to be defined if it stays in. > Ok. > 6.2. Policies for IPv6 allocations and assignments > > 6.2.1. Allocations and assignments > > To meet the goal of Fairness, ARIN makes both allocations and > assignments according to common criteria. Allocations are made to > LIRs, and assignments to certain end users. > > Do we need a 6.2.1 here? Allocations and assignments are both defined > below in 6.2.2 and 6.2.3, so this is redundant, in my opinion. > It's not strictly necessary, but I wanted to explain at a high level that we're doing things differently than in IPv4, and creating common policy for both allocations and assignments. Since it's just explanatory text, it can be removed at some point if no one finds it useful. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Wed Dec 23 18:25:14 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Dec 2009 15:25:14 -0800 Subject: [arin-ppml] Updated text for Simplified IPv6 Policy In-Reply-To: References: <4B329A66.2010306@gmail.com> Message-ID: <4B32A6DA.2020506@gmail.com> On 12/23/2009 2:59 PM, Geoffrey Keating wrote: > Scott Leibrand writes: >> 6.2.3.2 X-Small (/48) >> >> To qualify for a /48 allocation or assignment, an organization must: >> >> * Be multihomed, per section 2.7, and qualify for an ASN per section >> 5; or >> * Serve at least 1000 hosts; or >> * Demonstrate efficient utilization of all direct IPv4 assignments >> and allocations, each of which must be covered by any current ARIN >> RSA; or >> * Qualify for a Micro-allocations for Internal Infrastructure per >> 6.2.3.2.1. >> > ... > >> 6.2.3.3 Small (/40) >> >> To qualify for a /40 allocation or assignment, an organization must >> qualify for two or more /48s. >> > I found the interpretation of this a bit confusing. Does it mean: > > * Be multihomed at more than one distinct site, or > Yes... > * Be multihomed through 4 upstreams and qualify for 2 ASNs, or > No... > * Serve at least 2000 hosts, or > Yes... > * ?? not sure how the third bullet can be doubled > sensibly---perhaps with efficient utilisation at more than one RIR? :-), or > Don't even bother. :-) > * Qualify for both an X-Small allocation and a Micro-allocation? > Possibly... > Or does it mean > > * Has two customers (or itself plus one customer, more likely) each of > which qualifies for a /48? > Yes... > I think some of those are unintended, perhaps it would be better to > list out the precise criteria. > The basic idea is, if you qualify for more than a /48, you get a /40. This seems to be an area that several folks think needs improvement, so I'd welcome suggestions. Thanks for the feedback, Scott From bill at herrin.us Wed Dec 23 18:42:47 2009 From: bill at herrin.us (William Herrin) Date: Wed, 23 Dec 2009 18:42:47 -0500 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B0919@XCH-NW-05V.nw.nos.boeing.com> References: <73E11B6A-EB6F-4D02-8F2B-F9345F776644@delong.com> <3c3e3fca0912221701l4db11136h1721433b55cde89a@mail.gmail.com> <20091223161046.GA71845@ussenterprise.ufp.org> <3c3e3fca0912231008x36b293fao35c46dad763ee303@mail.gmail.com> <20091223210409.GA96429@ussenterprise.ufp.org> <0267B5481DCC474D8088BF4A25C7F1DF55127B0919@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <3c3e3fca0912231542j560560d4s914d3e8088f9c9cf@mail.gmail.com> On Wed, Dec 23, 2009 at 4:21 PM, Davis, Terry L wrote: > Is there a good reason that ARIN doesn't pick >1 to 5 hubs in a province/state and assign a /32 or larger >to them depending on their Internet population and >then make sub-allocations from these region prefixes >to smaller entities in that region? > > Huge amounts of the potential global routing tables >could then be aggregated regionally with still gaining >the ability allow small local sub-allocations for small > entities without much impact to the global routing. >Then from the regional aggregations could be broken > up locally by ISP. Hi Terry, You may want to peruse this IRTF RRG discussion on this topic: http://www.ops.ietf.org/lists/rrg/2008/msg01781.html . The short short version is: geographic route aggregation has been demonstrated impractical because aggregation depends on administrative vectors (e.g. which ISP you pay and which ones they pay) as well physical and technological factors. For the long version with the step-by-step gory details, read the the RRG thread. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Wed Dec 23 18:51:02 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 23 Dec 2009 15:51:02 -0800 Subject: [arin-ppml] Simplified IPv6 policy In-Reply-To: <4B328976.70209@gmail.com> References: <4B328976.70209@gmail.com> Message-ID: <86E898B0-3502-4F75-B05B-7705AA357DAC@delong.com> > >>> 6.3. Registration >>> >>> When an organization holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate (information registered by ARIN may be replaced by a distributed database for registering address management information in future). Information is registered in units of assigned /56 networks. When more than a /56 is assigned to an organization, the assigning organization is responsible for ensuring that the address space is registered in an ARIN database. >>> >> This is a major departure from current whois policy and I do not think that an overhaul of whois >> should be packaged with a major change to IPv6 policy. Please restore the current SWIP/rhwois >> requirements for publishing the data. >> >> I'm fine with registering IPv6 data in terms of /56s, but, what about cases where customers are >> issued /64s? There are 256 /64 customers in a single /56. > > This isn't a departure, this is a copy and paste (with minor edits) from existing policy (https://www.arin.net/policy/nrpm.html#six55) I stand corrected... I was assuming that existing IPv6 registration policy mirrored IPv4 whois/swip policy. Interesting that the IPv6 policy does not require public visibility. That should definitely be rectified. Guess it's time to write another proposal. Sorry for the interruption. >> >>> IRs shall maintain systems and practices that protect the security of personal and commercial information that is used in request evaluation, but which is not required for public registration. >>> >> I don't think this needs to be in the NRPM. I think that it is already addressed in other areas. > > It's in the current NRPM, but I'll be happy to remove it unless anyone thinks it needs to stay. (Like much of NRPM section 6, the globally coordinated policy restates a lot of policy from elsewhere, and some operational practice stuff as well.) > Yep. >>> 6.3.1. Residential Customer Privacy (2003-3) >>> >>> 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. >>> >>> 6.3.2. Reverse lookup >>> >>> When ARIN delegates IPv6 address space to an organization, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organization should properly manage its reverse lookup zone. When making an address assignment, the organization must delegate to an assignee organization, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address. >>> >> I think this needs word-smithing, but, I'm at a loss to come up with something better at the moment. > > Well, this too is existing NRPM text, so we don't have to fix it right now. > Perhaps not, but, it would be nice if we did while we're here. I think the general intent is right, just needs to be a cleaner way to say it. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Wed Dec 23 19:18:00 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 23 Dec 2009 19:18:00 -0500 Subject: [arin-ppml] efficient utilization != needs basis In-Reply-To: <28E139F46D45AF49A31950F88C497458049FD988@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458049FD988@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <12437.1261613880@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "michael" == michael dillon writes: >> That's great for Ford or American Airlines. michael> It's not just for big companies like Ford. Last time I michael> looked the ANX connected over 4000 companies of all sizes No, you missed the point. It's fine for companies that are part of large COINs. >> That's totally ridiculous for linking the 7 locations of >> Bob-DryCleaning's together over $200 VPN. michael> Of course you are right. I wasn't suggesting that any michael> handful of companies who need to communicate need special michael> treatment and in particular, I am talking about COINs which Yes, I understand. In the old days, we called them leased lines. Some of us ran IP on them, and others ran other things that are best left unspoken lest their respective dark-deities rise again. >> The big guys do not have a problem --- look the government of >> germany just got a /26. No big deal for them to parcel off a /32 >> for use on some COIN. michael> That's another good point. We have no scarcity of IPv6 michael> addresses so if an organization needs a much larger block michael> than a /32 to build their network, they can get it. This michael> time around we have enough address space to handle all michael> global and local telecommunications needs of the whole michael> planet even if the population continues growing and 3rd michael> world countries build the same infrastructure per person as michael> the 1st world. In other words, there is no need to michael> skimp. If you have big plans, and they are realistic plans, michael> then ARIN should give you the allocation needed to make michael> those plans a reality. We still should ask applicants to michael> demonstrate operational need for the allocation and justify michael> the magnitude of the allocation as well. Like I said --- no problem if you are big guy. Significant problem if you are not a big guy. >> It's the small guys that will have a problem --- and it will be >> the small guys that will deploy useful things first. michael> The jury is out on that one. The Internet is no longer the michael> weird new technology out in left field. It is the heart of michael> all communications infrastructure and everyone now realises michael> this. I will agree, as long as you write: s/Internet/IPv4+NAT/ IPv6 is still out in left field. Much better this year than last, mind you. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSzKzNoCLcPvd0N1lAQLgdwf+M+7hwZJKfGPjfee3pkeRwJGeqaQBY17f AQ6lbAZIE1TxrXVubu6TZxFNe1gjD6rh5Q5Ob+AAkJanXnzwEUoKl8vaKzvpOGs6 NT8hieo4Q7Ma5L3c7wLnmsz+RDm6GJF9YuXsov27cJVBwQ0c+42YJ2+YyE7EDqvW VM6vuPRzFPlYZt6n4BfewBu5pY40ktkpQ5zj3W/hyykrUsnCLEhffNlcpx+MBOgZ K23V3aDkNaDwLPjj5BWnv7cC5j5XkrNuuVlGvy9KvSM2kjlZtd+vU/J6nIbHG0qQ GG+4MCxrFTb3NHFjB0W8OMlSaRFnK6mEDwM9amWDtcelYHr1WX+1uQ== =LPEM -----END PGP SIGNATURE----- From scottleibrand at gmail.com Wed Dec 23 20:03:28 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Dec 2009 17:03:28 -0800 Subject: [arin-ppml] Updated text for Simplified IPv6 Policy In-Reply-To: <4B32B49A.8070102@ibctech.ca> References: <4B329A66.2010306@gmail.com> <4B32B49A.8070102@ibctech.ca> Message-ID: <4B32BDE0.9000802@gmail.com> On 12/23/2009 4:23 PM, Steve Bertrand wrote: > Scott Leibrand wrote: > >> * Demonstrate efficient utilization of all direct IPv4 assignments >> and allocations, each of which must be covered by any current ARIN >> RSA; or >> > How is "current RSA" defined? If I signed an RSA five years ago and > they've updated the RSA three times since then, does that mean that I > have to re-sign my existing assignment/allocation into the most recent > RSA to qualify? > If you request new IPv4 space, is ARIN going to require you to sign the updated RSA to get it? (If you don't know, we'd have to ask ARIN staff. I think there were some discussions about this back when we passed 2007-21, but I can't remember the details.) If so, then you'd need to do so before getting IPv6 under this policy (2007-21) as well. If not, then ARIN considers your version current, and you're fine. >> * Qualify for a Micro-allocations for Internal Infrastructure per >> 6.2.3.2.1. >> >> 6.2.3.2.1 Micro-allocations for Internal Infrastructure /(Copied from >> NRPM 6.10.2)/ >> >> Organizations that currently hold IPv6 allocations may apply for a /48 >> micro-allocation for internal infrastructure. Applicant must provide >> technical justification indicating why a separate non-routed block is >> required. Justification must include why a sub-allocation of currently >> held IP space cannot be utilized. Internal infrastructure allocations >> must be allocated from specific blocks reserved only for this purpose. >> > *tongue-in-cheek* > > Why is it that the critical infrastructure blocks "must be allocated > from specific blocks reserved only for this purpose"? > > Why can't this text be removed from this sub-section, and include a > global section that claims that 'each type of assignment/allocation must > be allocated/assigned from specific blocks reserved only for this purpose'? > > I don't currently know how ARIN carves up the space, so the above is > just a clueless remark, while thinking along the lines of > TE/filtering/deaggregation. > > /tongue-in-cheek > Actually, that is a really good point. I think I'll incorporate it. To answer your question, it is only that way for critical and internal infrastructure because when we passed those policies we wanted to make sure that ISPs could poke holes in their filters to allow CI routes through and filter II routes. >> 6.2.3.4 Medium (/32) >> >> To qualify for a /32 allocation or assignment, an organization must: >> >> * Qualify for 100 or more /48s; or >> * Be an existing, known LIR; or >> > I'm assuming this means that so long as I'm already an ISP/LIR with > _any_ IPv4 space (from ARIN) that I can get IPv6 with essentially no > questions asked? > Yep. The same is true of existing policy. On 12/23/2009 4:34 PM, Steve Bertrand wrote: > Steve Bertrand wrote: > > >> Also, I don't like the N hosts rule. I'd rather see that changed to >> something like 'N connected interfaces' (including sub-ints and >> virtual-ints), or 'N number of subnets/networks'. >> > Replying to my self, I don't like any of this. For instance: > > If I have five Apache server 'hosts', each with 200 domains on them, and > I feel that I can use the luxury of IPv6 to assign an IPv6 address to > each domain to provide the domain owner better service, I can't see how > this could be classified as host, interface etc, but I've managed to > assign 1k addresses. (not that I'd ever do such a thing... I've learnt > by having to renumber entire networks to do with as few addresses as > possible, where possible ;) > Actually, I think that's totally reasonable. There are more than enough IPs in a /64 to do that for every registered domain on the planet. Just don't expect that to justify getting more than a /48. :-) > Perhaps it would be better to either get rid of the clause entirely, or > have it read something such as "have 1,000 IPv6 address assignable > objects", where 'object' could be defined as 'any network resource that > can be addressed'. > I'm still waiting for someone to come up with the magic metric here. But right now, I still think hosts are the best technical metric we have for defining the size class of a network. I'm not really trying to define "how many subnets you need", but rather "are you big enough to fit into this size class", for purposes of routing table slots, etc. -Scott From scottleibrand at gmail.com Wed Dec 23 20:51:00 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Dec 2009 17:51:00 -0800 Subject: [arin-ppml] Updated text for Simplified IPv6 Policy In-Reply-To: <4B32BDE0.9000802@gmail.com> References: <4B329A66.2010306@gmail.com> <4B32B49A.8070102@ibctech.ca> <4B32BDE0.9000802@gmail.com> Message-ID: <4B32C904.6090002@gmail.com> On 12/23/2009 5:03 PM, Scott Leibrand wrote: > > Actually, that is a really good point. I think I'll incorporate it. Incorporating suggestions from Steve and Geoff, I came up with: 6.2.3.1.1 Allocation and assignment from specific blocks Each allocation/assignment size will be made out of separate blocks reserved for that purpose. Additionally, non-routed assignments for internal infrastructure, and assignments to Critical Infrastructure Providers per section 2.8, will each be made out of separate blocks reserved for those purposes. ARIN will make a list of these blocks publicly available. 6.2.3.2 X-Small (/48) To qualify for a /48 allocation or assignment, an organization must: * Be Multihomed per section 2.7, and qualify for an ASN per section 5; or * Serve at least 1000 hosts; or * Demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA; or * Require a non-routed block for internal infrastructure (assigned from specific blocks reserved only for this purpose); or * Be a Critical Infrastructure Provider per section 2.8. 6.2.3.3 Small (/40) To qualify for a /40 allocation or assignment, an organization must: * Have two or more Multihomed sites, each of which would qualify for a /48; or * Serve at least 2000 hosts; or * Be an LIR. Thoughts? -Scott P.S. I also created a wave for the topic at https://wave.google.com/wave/#restored:wave:googlewave.com!w%252B8kNAmoiXA If anyone wants an invite to play around with Wave, LMK. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marty at akamai.com Thu Dec 24 00:23:05 2009 From: marty at akamai.com (Martin Hannigan) Date: Thu, 24 Dec 2009 00:23:05 -0500 Subject: [arin-ppml] Updated text for Simplified IPv6 Policy In-Reply-To: <4B32BDE0.9000802@gmail.com> References: <4B329A66.2010306@gmail.com> <4B32B49A.8070102@ibctech.ca> <4B32BDE0.9000802@gmail.com> Message-ID: On Dec 23, 2009, at 8:03 PM, Scott Leibrand wrote: > On 12/23/2009 4:23 PM, Steve Bertrand wrote: > > Scott Leibrand wrote: > > > >> * Demonstrate efficient utilization of all direct IPv4 > assignments > >> and allocations, each of which must be covered by any > current ARIN > >> RSA; or > >> > > How is "current RSA" defined? If I signed an RSA five years ago and > > they've updated the RSA three times since then, does that mean > that I > > have to re-sign my existing assignment/allocation into the most > recent > > RSA to qualify? > > > > If you request new IPv4 space, is ARIN going to require you to sign > the > updated RSA to get it? (If you don't know, we'd have to ask ARIN > staff. I think there were some discussions about this back when we > passed 2007-21, but I can't remember the details.) If so, then you'd > need to do so before getting IPv6 under this policy (2007-21) as well. > If not, then ARIN considers your version current, and you're fine. > > You haven't read the RSA. . Section 2 "BECAUSE OF THE NECESSARY ROLE THAT ARIN PERFORMS FOR THE INTERNET COMMUNITY, ARIN RESERVES THE RIGHT TO MODIFY THIS AGREEMENT AT ANY TIME. ARIN WILL PROVIDE NOTIFICATION OF ANY MODIFICATION(S) VIA ELECTRONIC MAIL TO THE CURRENTLY REGISTERED ADMINISTRATIVE POINT OF CONTACT. FOLLOWING THIS ELECTRONIC NOTIFICATION, ARIN WILL POST THE MODIFICATION(S) ON ITS WEBSITE. CHANGES WILL BE EFFECTIVE AFTER BEING POSTED ON ARIN?S WEBSITE FOR 30 DAYS AND WILL BE APPLIED TO ALL APPLICANTS OR PERSONS RECEIVING SERVICES. CONTINUED RECEIPT OR USE OF THE SERVICES CONSTITUTES APPLICANT?S ACCEPTANCE OF THE CHANGES." And legacy RSA: "7. CURRENT AND FUTURE POLICIES As set forth in Section 2, to the extent of any conflict between the provisions of this Legacy Agreement and the Policies, the terms of this Legacy Agreement shall prevail. Notwithstanding the foregoing, pursuant to ARIN's Policy Development Process ("PDP"), ARIN maintains the Policies and may at any time in its sole, absolute, and reasonable discretion amend the Policies, implement new policies (which once implemented, will be considered Policies), or make certain Policies obsolete. Such amendments or new Policies shall be binding upon Legacy Applicant immediately after they are posted on the Website. Legacy Applicant acknowledges and agrees it has read, understands, and agrees to be bound by and comply with the Policies, as amended, except to the extent those Policies may conflict with the rights and duties provided Legacy Applicant in this Legacy Agreement. " From scottleibrand at gmail.com Thu Dec 24 01:02:01 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Dec 2009 22:02:01 -0800 Subject: [arin-ppml] Please don't be afraid to contribute! In-Reply-To: References: <4B329A66.2010306@gmail.com> <4B32A6DA.2020506@gmail.com> <6A257547-0F8B-49B0-B99F-1A120092F2FB@geoffk.org> <4B32B485.50609@gmail.com> Message-ID: <4B3303D9.6010505@gmail.com> On 12/23/2009 6:39 PM, Geoff Keating wrote privately: > On 23/12/2009, at 4:23 PM, Scott Leibrand wrote privately: > > >> Geoff, >> >> Is there any reason you're not Cc'ing PPML on your replies? Do you mind if I do so? >> > I just didn't want to bother the list, but feel free to do so yourself! > Thanks, I'll take the liberty to do just that. :-) You're not the only one who has responded directly to me today with excellent feedback. I really appreciate it, and would like to encourage everyone to do the same. But even more importantly, I'd like to ask something of you, and all the other people with opinions and ideas who were reluctant to post them: Please, please, PLEASE don't consider it an imposition on anyone to share your thoughts, opinions, and ideas on PPML. This list is here for just that reason. We hear quite often what the usual suspects (like me!) think, to the point that we can often predict what they'll say in advance. But we don't hear nearly enough from folks like you, who are diligently following the list, forming opinions, and coming up with ideas. I don't think there's a single idea in this simplified IPv6 policy that I came up with all on my own. Every single one of them came from pulling together all of the great ideas circulating on this list and in recent public policy meetings. My own little contribution would not have been possible if everyone kept their thoughts to themselves. So, again, thanks for everyone's excellent feedback so far. Please keep it up, and don't be afraid to post your questions, opinions, and ideas. We need more of them. Thanks again, Scott From bill at herrin.us Thu Dec 24 02:21:36 2009 From: bill at herrin.us (William Herrin) Date: Thu, 24 Dec 2009 02:21:36 -0500 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <20091223210409.GA96429@ussenterprise.ufp.org> References: <73E11B6A-EB6F-4D02-8F2B-F9345F776644@delong.com> <3c3e3fca0912221701l4db11136h1721433b55cde89a@mail.gmail.com> <20091223161046.GA71845@ussenterprise.ufp.org> <3c3e3fca0912231008x36b293fao35c46dad763ee303@mail.gmail.com> <20091223210409.GA96429@ussenterprise.ufp.org> Message-ID: <3c3e3fca0912232321s16a0793flbf4002b3f1f385b0@mail.gmail.com> On Wed, Dec 23, 2009 at 4:04 PM, Leo Bicknell wrote: > In a message written on Wed, Dec 23, 2009 at 01:08:38PM -0500, William Herrin wrote: >> You've couched it better than Owen but you've basically said the same >> thing: the community won't want this, so why bother bringing it to the >> point where you ask them? The problem with that theory is two-fold: > > You are putting words into my mouth. ?The community may well want > this in the future, I have no reason to believe they will or they > won't. Leo, You're right. I owe you a more thoughtful response: > What having a proposal does is put requirements on the discussion. > Timelines. Presentations at meetings. These can be useful, but > also in the early days of a proposal can be harmful; rather than > letting the idea develop and turn into something good it is shoehorned > into a timeline. > > As for this particular proposal, it appeared to me it was not ripe. > Long proposals almost never pass, and not only is this one long but > it touches on many different areas. I believe in its current form > it has no chance of passing, as the details need to be refined, > simplified, and folks brought on board before there is a reason to > have a formal proposal. It's obvious to me and I think it's becoming obvious to you and to others that the IPv6 policy requires a major overhaul. If we were going to get to something that worked rationally with small, incremental adjustments to the existing policy, we'd have achieved it already. For better or for worse, this means writing a long proposal. And rewriting it until we have one that passes. One important intermediate step is getting folks used to the idea of a major rewrite and used the range of ideas for what to replace existing IPv6 policy with. We've made considerable headway for the folks who camp on PPML but not all folks who attend meetings do so. If we want all the folks who participate in the policy process to gain exposure the the ideas then we have to bring some proposals forward through the process. And if necessary, allow them to be shot down at the meeting, preferably with a selection of good comments from the community there as to what must change in the proposal. The ideas won't get appropriate exposure from an open policy hour. Open policy hour is a place where you float vague ideas and get snap feedback. We're well past vague ideas. A proposal on the table demands attention and critical evaluation, and that's what's needed. If for no other reason, I think the AC should have moved 103 forward. As for ripeness, what do you have in mind? Do you spy technical flaws in how the proposal could be reasonably expected to function when the rubber meets the road? I'll welcome your thoughts. But Leo, ripeness doesn't mean that a proposal isn't ready to be accepted, it means that a proposal isn't fully formed. If 103 has covered it's corner cases and achieved language that forms actionable policy then let the community do it's job of evaluating the proposal. The AC doesn't have to shield the community from making decisions. It's okay to let the wider community shoot a proposal down. It gets the ideas out there and makes the next attempt at a proposal that much stronger. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Thu Dec 24 02:39:51 2009 From: bill at herrin.us (William Herrin) Date: Thu, 24 Dec 2009 02:39:51 -0500 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: References: <3c3e3fca0912231008x36b293fao35c46dad763ee303@mail.gmail.com> Message-ID: <3c3e3fca0912232339i30779b3ck6bdeeba63d827dd5@mail.gmail.com> On Wed, Dec 23, 2009 at 2:24 PM, Sweeting, John wrote: > I just want to share some of the information that was not >provided in the explanation posted but was discussed at >the AC's meeting and will be part of the minutes. The first >motion was to Accept Proposal 103 on the docket. After >much discussion it was voted down 5 For, 7 Against, >1 Abstention (there were 2 AC members absent). The >main reasoning was that by putting it on the docket >with the intention of major revisions, the AC was aborting >the author's (and community's) right to petition. [...] ?David >and/or Scott should be working with you (and others) to try >and work out the flaws. I have seen a lot of back and forth >on this list so it seems to be what is happening. We, the >AC, have no intentions of dropping this and I just wanted to > state that on this list. Thanks John. I appreciate the insight. I would like to see Scott's proposal move forward. I'd also like to see some alternatives. Though I haven't yet decided, I will likely petition 103. I find that ideas germinate better in the presence of direct competition. Should one of the alternatives prove superior, an active 103 would, at the least, provide a useful yardstick by which the alternative is measured. By the way, if there's anyone out there who would be willing to support a petition to move 103 forward to the discussion and presentation phase, I'd love to hear from you privately. I'd hate to post a petition only to hear the crickets chirp. As I see it, you don't have to support adopting the proposal to support a petition. I know I won't push for adoption of a proposal unless it has gained consensus. To support a petition, you just have to believe that the proposal should move forward to formal discussion, and be presented for critical analysis to the wider policy community at an ARIN meeting. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From michael.dillon at bt.com Thu Dec 24 03:27:15 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 24 Dec 2009 08:27:15 -0000 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B091A@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <28E139F46D45AF49A31950F88C497458049FD9F0@E03MVZ2-UKDY.domain1.systemhost.net> > Thanks. I didn't recall the original proposer of the > concept, it was what 5 or 6 years ago? > > But yes this is what I was referring to. I suggested this about 4 years ago but I chose a bad name to describe it which caused people to think that it was something completely different. Referring to this concept as City Aggregate (CA) addressing, gets to the heart of the matter. It is still ordinary Global Unicast from the IETF point of view. However large blocks of CA address space need to be pre-committed to specific cities and allocated to the RIRs under the stipulation that they only be assigned to end users from the appropriate CA block. Any intermediate regional layer of aggregation would be managed by the RIRs themselves and no allocations at all would be done. Also, the RIRs would not prescribe how ISPs should handle the routing for CA blocks. CA will work best in cities where there is a local Internet exchange point that is well subscribed by the ISPs who provide the majority of Internet Access service in that city. --Michael Dillon From michael.dillon at bt.com Thu Dec 24 03:38:38 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 24 Dec 2009 08:38:38 -0000 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <20091223231410.GA31206@vacation.karoshi.com.> Message-ID: <28E139F46D45AF49A31950F88C497458049FDA00@E03MVZ2-UKDY.domain1.systemhost.net> > Steve Deering originally floated the idea. I trawled the net looking for something and discovered that Steve did indeed present some slides to the IETF in 1995 about something called metropolitan addressing which is similar to City Aggregate addressing. However, in 1995 the routing architecture of the Internet was not yet in place, and Steve's concept was directed at the IPv4 Internet and asked for everyone to move to metro addressing. CA addressing is only for the IPv6 Internet and is intended to coexist with PA and PI addressing so that network operators and end users can choose the CA model if they want to. --Michael Dillon From michael.dillon at bt.com Thu Dec 24 04:19:57 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 24 Dec 2009 09:19:57 -0000 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <3c3e3fca0912231542j560560d4s914d3e8088f9c9cf@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C497458049FDA5F@E03MVZ2-UKDY.domain1.systemhost.net> > You may want to peruse this IRTF RRG discussion on this topic: > http://www.ops.ietf.org/lists/rrg/2008/msg01781.html . > > The short short version is: geographic route aggregation has > been demonstrated impractical because aggregation depends on > administrative vectors (e.g. which ISP you pay and which ones > they pay) as well physical and technological factors. For the > long version with the step-by-step gory details, read the the > RRG thread. That is a discussion about replacing the current routing paradigm with a geographically-based routing paradigm CA addressing is not about replacing anything but about providing an additional option for people to work with. The economic issues are for others to work out, and if you don't try to reengineer the entire network, then they are a non-issue. --Michael Dillon From bill at herrin.us Thu Dec 24 05:53:46 2009 From: bill at herrin.us (William Herrin) Date: Thu, 24 Dec 2009 05:53:46 -0500 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <28E139F46D45AF49A31950F88C497458049FDA5F@E03MVZ2-UKDY.domain1.systemhost.net> References: <3c3e3fca0912231542j560560d4s914d3e8088f9c9cf@mail.gmail.com> <28E139F46D45AF49A31950F88C497458049FDA5F@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <3c3e3fca0912240253o44e129feve7a2a5ba308aae3c@mail.gmail.com> On Thu, Dec 24, 2009 at 4:19 AM, wrote: > >> You may want to peruse this IRTF RRG discussion on this topic: >> http://www.ops.ietf.org/lists/rrg/2008/msg01781.html . > > That is a discussion about replacing the current routing > paradigm with a geographically-based routing paradigm > CA addressing is not about replacing anything but about > providing an additional option for people to work with. Michael, Addressing is routing is addressing. How many cities does a typical ISP span? With addresses aggregated by city, each ISP+city pair would have to be announced as a separate prefix, just as the multinational ISPs have to announce their regional RIR-allocated prefixes separately today. And as discussed in the RRG thread, the prefix announcements don't successfully aggregate across ISPs in the same city. There are few enough multinationals that the split by RIR is not a serious problem though even there you'd get slightly better aggregation by having each org declare a home RIR and get its global addresses from only that one. Start divvying up by much smaller geographies like cities and you could see a routing table explosion. Every conceivable form of geographic addressing has been exhaustively explored in the research community since the early ideas like CA. Vast numbers of man-hours were spent chasing it in the hopes it would prove to be a Holy Grail. It's a blind alley. There's nothing there to be found. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From michael.dillon at bt.com Thu Dec 24 07:14:31 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 24 Dec 2009 12:14:31 -0000 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <3c3e3fca0912240253o44e129feve7a2a5ba308aae3c@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C497458049FDC18@E03MVZ2-UKDY.domain1.systemhost.net> > Addressing is routing is addressing. How many cities does a > typical ISP span? With addresses aggregated by city, each > ISP+city pair would have to be announced as a separate > prefix, No. ISPs don't HAVE TO do anything. And most importantly, it is not ARIN's job to tell ISPs how to implement routing for city aggregates. It is up to ISPs and their customers to work out what needs to be done which may very well include special regional peering that allows for cold potato routing and it may well involve different cost-sharing agreements. But it is not our job to work out those details. In fact, it is better to leave this stuff unsaid in order to encourage ISPs to innovate and try out different solutions in different regions. > just as the multinational ISPs have to announce their > regional RIR-allocated prefixes separately today. And as > discussed in the RRG thread, the prefix announcements don't > successfully aggregate across ISPs in the same city. They do successfully aggregate if the one single city aggregate is the only route announced to the DFZ, and any longer prefixes are only announced within the city and the nearby region. ISP's in Europe may need to carry more than just the CA prefix for Paris, to avoid trombone routes but North American ISPs can get away with one routing table entry for Paris. > There are few enough multinationals that the split by RIR is > not a serious problem though even there you'd get slightly > better aggregation by having each org declare a home RIR and > get its global addresses from only that one. Start divvying > up by much smaller geographies like cities and you could see > a routing table explosion. But that routing table explosion would be less than putting every company's PI block in the DFZ and it would also be regionalised. And it would be optional. If a global ISP does not want to deal with the complexity, they can just send all their Paris traffic to the LINX in London, even if the traffic comes from Strasbourg or Berlin or Warsaw. If that is the way that it has to be for users of CA blocks, then when they CHOOSE to use a CA block, they will have evaluated the tradeoffs and decided that higher latency is acceptable. > Every conceivable form of geographic addressing has been > exhaustively explored in the research community since the > early ideas like CA. Vast numbers of man-hours were spent > chasing it in the hopes it would prove to be a Holy Grail. > It's a blind alley. There's nothing there to be found. That's because there is no Holy Grail. In addition, a lot of that effort was directed to IPv4. The CA addressing solution is only for IPv6, where the vastness of the address space allows us to run a decade or two of experimentation with very low risk of hitting any kind of IPv6 exhaustion. And CA addressing is not meant to replace any current practice of routing, but to supplement it. --Michael Dillon From mcr at sandelman.ca Thu Dec 24 08:20:18 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 24 Dec 2009 08:20:18 -0500 Subject: [arin-ppml] Abandonment of 103/104 In-Reply-To: <28E139F46D45AF49A31950F88C497458049FD98D@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458049FD98D@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <5674.1261660818@marajade.sandelman.ca> >>>>> "michael" == michael dillon writes: michael> P.S. I will work with anyone who wants to hone this idea michael> into an Internet draft. Tony Hain has revised his document. http://tools.ietf.org/html/draft-hain-ipv6-geo-addr-01 -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From bicknell at ufp.org Thu Dec 24 21:29:20 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 24 Dec 2009 18:29:20 -0800 Subject: [arin-ppml] China Telecom IPv6 Schedule Message-ID: <20091225022920.GA6375@ussenterprise.ufp.org> http://www.marbridgeconsulting.com/marbridgedaily/2009-12-22/article/32322/china_telecom_ipv6_to_see_commercial_launch_in_2012 While the 2012 timeline to launch IPv6 is interesting (and, at least to me a tad disappointing) more interesting is that they have already set a schedule of 2015 to start retreating from IPv4. I've long aruged the overlap period will be shorter, not longer due to the cost of running dual networks. China Telecom would seem to agree with such an agressive timeline. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From rudi.daniel at gmail.com Fri Dec 25 18:37:07 2009 From: rudi.daniel at gmail.com (RudOlph Daniel) Date: Fri, 25 Dec 2009 19:37:07 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 54, Issue 98/leo Message-ID: <8aeeaff60912251537n1341c98egdcee4f05fb6e5924@mail.gmail.com> Leo, I do believe that due to changing global dynamics that we should not sit on our backsides but engineer a v6 transition by any means necessary. China "will" be more aggressive than the US in this regard. RD > > > http://www.marbridgeconsulting.com/marbridgedaily/2009-12-22/article/32322/china_telecom_ipv6_to_see_commercial_launch_in_2012 > > While the 2012 timeline to launch IPv6 is interesting (and, at least > to me a tad disappointing) more interesting is that they have already > set a schedule of 2015 to start retreating from IPv4. > > I've long aruged the overlap period will be shorter, not longer due to > the cost of running dual networks. China Telecom would seem to agree > with such an agressive timeline. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 826 bytes > Desc: not available > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20091224/708d14ee/attachment-0001.bin > > > > -- Rudi Daniel Independent Consultants http://www.svgpso.org http://danielcharles.weebly.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel at arneill-py.sacramento.ca.us Sat Dec 26 20:13:54 2009 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sat, 26 Dec 2009 17:13:54 -0800 Subject: [arin-ppml] Does Moore's law help with routing table growth? In-Reply-To: <4B31A9DB.6000704@gmail.com> References: <4B2C5DDD.7050501@gmail.com> <471D76419F9EF642962323D13DF1DF69011612@newserver.arneill-py.local> <4B2C65E1.3090705@gmail.com><63ac96a50912221218o7c83feddu403c1179b8eda63c@mail.gmail.com> <4B3183AA.6080205@gmail.com> <471D76419F9EF642962323D13DF1DF6901162D@newserver.arneill-py.local> <4B31A9DB.6000704@gmail.com> Message-ID: <471D76419F9EF642962323D13DF1DF69011630@newserver.arneill-py.local> >> Michel Py wrote: >> I must have missed a step; how does multihoming with >> private ASNs work? > > Scott Leibrand wrote: > Our mutual customer runs BGP with both of us, uses a private ASN to > run BGP, and announces both of us his route. We both implement the > remote-private-as command (or equivalent) to strip his private ASN > from the path before announcing it to our providers and peers. As a > result, the BGP table contains the route with two different origin > ASNs: mine and yours. That's ugly, but it doesn't really break > anything. Oh. Well while in that mood we might as well announce PA prefixes, it doesn't break anything either. No ASN, no PI prefix. Simpler. We don't need BGP either, there's always static routes :-D >> Besides, ASNs are not in short supply, slots in the routing table >> are problematic. How would raising the price of ASNs would prevent >> people from announcing a gazillion prefixes from one ASN? > Exactly correct. Which is why any viable method would have to > monetize the routing slots directly, Indeed. > for example by tier 1 transit providers charging their customers > per route announced, and adding deaggregation ratio requirements > to their existing traffic ratio requirements in their peering > agreements with each other. This may be a sticky thing. > Which won't happen unless the rate of growth of the routing table > becomes a much more significant problem than it is today, or router > capacity growth dramatically slows. Agree. > Christopher Morrow wrote: > Speed of change is how quickly you can update, and often across > a severely limited pathway, the FIB when a RIB change happens. > Today you stay ahead of that change rate (mostly) and your > device's view of the world is 'converged'. Tomorrow if that > change rate is higher than you can keep up with you will never > converge. Indeed; when a tier-1 flaps there is a ripple effect globally; I'm not a dampening specialist though. I can certainly see a potential issue if the pathway ratios between tier-1 and multihomed customers changes significantly; conceptually a large route flap could be handled by the core but overwhelm the edge just because of the sheer size of the update. Michel. From scottleibrand at gmail.com Mon Dec 28 15:10:00 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 28 Dec 2009 12:10:00 -0800 Subject: [arin-ppml] Does Moore's law help with routing table growth? In-Reply-To: <471D76419F9EF642962323D13DF1DF69011630@newserver.arneill-py.local> References: <4B2C5DDD.7050501@gmail.com> <471D76419F9EF642962323D13DF1DF69011612@newserver.arneill-py.local> <4B2C65E1.3090705@gmail.com><63ac96a50912221218o7c83feddu403c1179b8eda63c@mail.gmail.com> <4B3183AA.6080205@gmail.com> <471D76419F9EF642962323D13DF1DF6901162D@newserver.arneill-py.local> <4B31A9DB.6000704@gmail.com> <471D76419F9EF642962323D13DF1DF69011630@newserver.arneill-py.local> Message-ID: <4B391098.5020102@gmail.com> On 12/26/2009 5:13 PM, Michel Py wrote: >>> Michel Py wrote: >>> I must have missed a step; how does multihoming with >>> private ASNs work? >>> >> >> Scott Leibrand wrote: >> Our mutual customer runs BGP with both of us, uses a private ASN to >> run BGP, and announces both of us his route. We both implement the >> remote-private-as command (or equivalent) to strip his private ASN >> from the path before announcing it to our providers and peers. As a >> result, the BGP table contains the route with two different origin >> ASNs: mine and yours. That's ugly, but it doesn't really break >> anything. >> > Oh. Well while in that mood we might as well announce PA prefixes, it > doesn't break anything either. No ASN, no PI prefix. Simpler. We don't > need BGP either, there's always static routes :-D > PI multihoming could be done without BGP, but you'd want a dynamic routing protocol, and you'd need to convince your upstream to redistribute the route into BGP. Static routes, of course, are insensitive to certain outage conditions, so they're less ideal than, for example, RIP. In any event, I'm not saying running an inferior routing protocol, or BGP with private ASNs, is a good idea: just that it's the kind of thing people will do if you start charging for ASNs. But to your PA vs. PI point, there's a strong driver towards getting PI space for any org that doesn't want to be tied to their provider and be forced to renumber. Since the substitute for PI space (PA space) isn't as good as the substitute for public ASNs (private ASNs), the demand for PI space is less elastic (more resistant to price pressure) than the demand for ASNs. -Scott From kellermg at potsdam.edu Tue Dec 29 09:12:57 2009 From: kellermg at potsdam.edu (Matthew Keller) Date: 29 Dec 2009 09:12:57 -0500 Subject: [arin-ppml] The non-deployment of IPv6 - The Economic Factor In-Reply-To: <00ea01ca7934$68582d70$39088850$@com> References: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> <00ea01ca7934$68582d70$39088850$@com> Message-ID: <4B3A0E69.8060502@potsdam.edu> Sorry to dredge an "old" thread back, but I'm catching up on PPML and Vaughn's note really nailed a large segment of what I've been explaining for several years now when dealing with the "deploy IPv6 or you suck and are a bad netizen" crowd. > This (*The Economic Factor*) should not be underestimated I'll go one step further - Deploying IPv6 across a perfectly-running enterprise network is excruciatingly daunting. This isn't daunting because admins lack the expertise or confidence to do so, or haven't done it a bajillion times in test environments, it's because our customers (and bosses) don't care - they don't care one lick that you're rolling out IPv6, whatever that is. The network is _working_, everything is _fine_ and they very simply don't want to risk something not working anymore: If it ain't broke, don't fix it. The customer has plenty of other things they _do_ want. There is little-to-no consumer-driver to enable IPv6 in established networks, and when coupled with Vaughn's assessment of economic dissuasion, it paints a picture that unless you are very well-off (capitally and/or human-resourcely), _forced_ by outside powers (something to show your customers and bosses to justify the risk of change), or setting up a new network from scratch (you'd be stupid not to): Trying to get "normal", established edge networks to deploy IPv6 is one-step down from trying to herd cats. -- Matthew Keller Information Security Officer/Network Administrator Computing & Technology Services State University of New York @ Potsdam Potsdam, NY, USA From info at arin.net Tue Dec 29 11:38:45 2009 From: info at arin.net (Member Services) Date: Tue, 29 Dec 2009 11:38:45 -0500 Subject: [arin-ppml] Policy Proposal 106: Simplified IPv6 policy Message-ID: <4B3A3095.4020000@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 106: Simplified IPv6 policy Proposal Originator: Scott Leibrand Proposal Version: 1.0 Date: 29 December 2009 Proposal type: new Policy term: permanent Policy statement: Delete "6.1 Introduction" This is all historical. Delete "6.2 Definitions" The definitions we need are all defined in section 2. Leave 6.3 as is (renumber to 6.1) I think these still accurately reflect the Goals we want our policy to follow. Move 6.4.1 to 1.1. Retitle to "Number resources not to be considered property" and update text per below. This is a principle more general than just IPv6, and needs to be updated to be ARIN-specific and refer to the RSA. Delete 6.4.2 - 6.4.4 These principles don't seem worthy of elevation to special status. Replace 6.5 Policies for allocations and assignments with text below (renumber to 6.2) This seems to be where most of the changes and simplification are needed. Delete 6.6 References This is all historical, and doesn't need to be part of the NRPM. Delete 6.7 Appendix A: HD-Ratio We can let the HD-Ratio guide policy without making people like David's grandma do the math. Delete 6.8. Appendix B: Background information This is all historical Move 6.9 and 6.10 into 6.2.3.2 below Replacement text: 1.1. Number resources not to be considered property The policies in this document are based upon the understanding that globally-unique number resources are licensed for use rather than owned. Specifically, IP addresses and ASNs will be allocated and assigned as defined in the ARIN Registration Services Agreement. 2.8. Critical Infrastructure Providers Critical infrastructure providers of the Internet include public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA. 4.4. Micro-allocation ARIN will make IPv4 micro-allocations to Critical Infrastructure Providers per section 2.8. These allocations will be no longer than a /24. Multiple allocations may be granted in certain situations. 4.4.1. Allocation and assignment from specific blocks Exchange point allocations MUST be allocated from specific blocks reserved only for this purpose. All other micro-allocations WILL be allocated out of other blocks reserved for micro-allocation purposes. ARIN will make a list of these blocks publicly available. 4.4.2. Exchange point requirements Exchange point operators must provide justification for the allocation, including: connection policy, location, other participants (minimum of two total), ASN, and contact information. ISPs and other organizations receiving these micro-allocations will be charged under the ISP fee schedule, while end-users will be charged under the fee schedule for end-users. This policy does not preclude exchange point operators from requesting address space under other policies. 6.2. Policies for IPv6 allocations and assignments 6.2.1. Allocations and assignments To meet the goal of Fairness, ARIN makes both allocations and assignments according to common criteria. Allocations are made to LIRs, and assignments to certain end users. 6.2.2. Assignments from LIRs/ISPs End-users are assigned an end site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): * /64 when it is known that one and only one subnet is needed * /56 for small sites, those expected to need only a few subnets over the next 5 years. * /48 for larger sites For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation. 6.2.3. Allocations and assignments from ARIN 6.2.3.1 Goals To balance the goals of Aggregation, Conservation, Fairness, and Minimized Overhead, ARIN normally issues IPv6 addresses only in the discrete sizes of /48, /40, /32, /28, or /24 or larger. Each organization or discrete network may qualify for one allocation or assignment of each size, and must pay fees according to ARIN's fee schedule [https://www.arin.net/fees/fee_schedule.html] for each size issued. 6.2.3.1.1 Allocation and assignment from specific blocks Each allocation/assignment size will be made out of separate blocks reserved for that purpose. Additionally, non-routed assignments for internal infrastructure, and assignments to Critical Infrastructure Providers per section 2.8, will each be made out of separate blocks reserved for those purposes. ARIN will make a list of these blocks publicly available. 6.2.3.2 X-Small (/48) To qualify for a /48 allocation or assignment, an organization must: * Be Multihomed per section 2.7, and qualify for an ASN per section 5; or * Serve at least 1000 hosts; or * Demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA; or * Require a non-routed block for internal infrastructure; or * Be a Critical Infrastructure Provider per section 2.8. 6.2.3.3 Small (/40) To qualify for a /40 allocation or assignment, an organization must: * Have two or more Multihomed sites, each of which would qualify for a /48; or * Serve at least 2000 hosts; or * Be an LIR. 6.2.3.4 Medium (/32) To qualify for a /32 allocation or assignment, an organization must: * Have 100 or more sites, each of which would qualify for a /48; or * Be an existing, known LIR; or * Have a plan to provide IPv6 connectivity to other organizations and assign at least 100 end-site assignments to those organizations within 5 years. 6.2.3.5 Large (/28) To qualify for a /28, an organization must demonstrate the need to make assignments and/or reallocations equal to at least 25,000 /48s. 6.2.3.6 X-Large (/24) To qualify for a /24, an organization must demonstrate the need to make assignments and/or reallocations equal to at least 330,000 /48s. 6.2.3.7 XX-Large (larger than /24) Allocations or assignments larger than /24 may be made only in exceptional cases, to organizations that demonstrate the need to make assignments and/or reallocations equal to at least 4,500,000 /48s. If approved, the allocation prefix length will be based on the number of /24s justified (at 4,500,000 /48s each). 6.3. Registration ''(Copied from NRPM 6.5.5)'' When an organization holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate (information registered by ARIN may be replaced by a distributed database for registering address management information in future). Information is registered in units of assigned /56 networks. When more than a /56 is assigned to an organization, the assigning organization is responsible for ensuring that the address space is registered in an ARIN database. 6.3.1. Residential Customer Privacy ''(Copied from NRPM 6.5.5.1)'' 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. 6.3.2. Reverse lookup ''(Copied from NRPM 6.5.6)'' When ARIN delegates IPv6 address space to an organization, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organization should properly manage its reverse lookup zone. When making an address assignment, the organization must delegate to an assignee organization, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address. Rationale: This policy proposal attempts to simplify IPv6 policy in a number of ways. For example, it: * Deletes a number of historical sections and items that duplicate text elsewhere in the NRPM. * Removes the HD-ratio, instead incorporating values calculated from it as the basis for qualification criteria. It also replaces & rewrites section 6.5 "Policies for allocations and assignments" entirely. This rewrite: * Eliminates the different criteria for allocations (ISPs) vs. assignments (end users) and replaces them with a single common set of criteria for both classes of users. The allocation vs. assignment distinction itself is preserved, as it still forms a useful basis for a cost-recovery fee structure, and for other parts of the NRPM (such as whois policy). * Creates a size-class-based system for allocating IPv6 address blocks. This has a number of advantages over the existing policy: ** Allows for safe filtering of traffic-engineering (TE) more-specific route announcements. ** In exchange (since PA more-specifics are expected to be filterable), allows any multihomed organization to get an assignment from ARIN. The smaller number of such PI assignments (compared to TE more-specifics) should mean that such assignments will largely be accepted across the DFZ. ** Expands the use of discrete blocks from which all allocations will be of identical prefix length and categorization. This will enable safer and easier TE filtering, as mentioned above. ** Expands the availability of non-routed blocks for internal infrastructure. Since routable blocks are available to any multihomed organization, there is no longer a need to restrict the availability of blocks from the non-routable pool. ** Makes allocations available to any LIR. Note: In the event of an M&A transfer per section 8.2 that would result in more than one block of a given size class being held by the combined organization, the organization should be encouraged to renumber into a single larger block and return the smaller block(s) when feasible. However, as long as the organization doesn't require any additional resources, this policy does not force them to make any changes. OTOH, if they request a larger block and still hold two or more smaller blocks, they would be required to return the smaller block as a condition for receiving the larger one. Timetable for implementation: Immediate (as soon as practical). From tedm at ipinc.net Tue Dec 29 11:39:19 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 29 Dec 2009 08:39:19 -0800 Subject: [arin-ppml] The non-deployment of IPv6 - The Economic Factor In-Reply-To: <4B3A0E69.8060502@potsdam.edu> References: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net> <00ea01ca7934$68582d70$39088850$@com> <4B3A0E69.8060502@potsdam.edu> Message-ID: <4B3A30B7.3030504@ipinc.net> Matthew Keller wrote: > Sorry to dredge an "old" thread back, but I'm catching up on PPML and > Vaughn's note really nailed a large segment of what I've been explaining > for several years now when dealing with the "deploy IPv6 or you suck and > are a bad netizen" crowd. > >> This (*The Economic Factor*) should not be underestimated > > I'll go one step further - Deploying IPv6 across a perfectly-running > enterprise network is excruciatingly daunting. > > This isn't daunting because admins lack the expertise or confidence to > do so, or haven't done it a bajillion times in test environments, it's > because our customers (and bosses) don't care - they don't care one lick > that you're rolling out IPv6, whatever that is. The network is > _working_, everything is _fine_ and they very simply don't want to risk > something not working anymore: If it ain't broke, don't fix it. The > customer has plenty of other things they _do_ want. > They didn't give a rat's ass what they were running on when we switched them from IPX-only to dual-stack IP and IPX a decade ago when we were switching from Netware to Windows Server, and then later switched them from dual-stack IPX and IP to IP-only. This is an excuse, pure and simple. But, it's your network, run it any way you want. If you want to do nothing until you absolutely have to access an IPv6 content provider then slap in an IPv4->IPv6 gateway at your border, your welcome to do so. > There is little-to-no consumer-driver to enable IPv6 in established > networks, and when coupled with Vaughn's assessment of economic > dissuasion, it paints a picture that unless you are very well-off > (capitally and/or human-resourcely), _forced_ by outside powers > (something to show your customers and bosses to justify the risk of > change), or setting up a new network from scratch (you'd be stupid not > to): Trying to get "normal", established edge networks to deploy IPv6 is > one-step down from trying to herd cats. > Perhaps. But I do know one thing - 10 years from now when both you and I are out of work and looking for a job, my Resume is going to say IPv6 experience and yours won't - and I'll likely get a position faster and with more compensation than you do. Suit yourself. Ted From cengel at sponsordirect.com Tue Dec 29 17:57:15 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Tue, 29 Dec 2009 17:57:15 -0500 Subject: [arin-ppml] The non-deployment of IPv6 - The Economic Factor In-Reply-To: Message-ID: Matthew Keller wrote: "I'll go one step further - Deploying IPv6 across a perfectly-running enterprise network is excruciatingly daunting." Matt, Very much so....in point of fact....I would say for an established edge network right now, IPv6 is a solution looking for a problem. That's not to say it might not be a real problem 2 years from now that needs to be addressed...but right now it's not. I'm not one to argue against trying to get ahead of the game if you have sufficient resources (time/money/manpower) to do so....and can do so with little disruption.... but I don't believe that's the position most enterprise admins/managers find themselves in these days. If you have a limited pool of resources and you can choose to spend them on solving the problem that keeps you in business 2 months from now....or spending them on solving the problem that keeps you in business 2 years from now....it's a no brainer which one of those you prioritize. Furthermore, there is no real indication that switching to IPv6 native will be the best solution to the problem when it does come. There is no one size fits all solution. Every organizations business needs are different....and therefore the solutions that make sense for them can be different as well. Right now my gut tells me that an IPv4 to IPv6 gateway service seems to make sense for my particular business needs, if I can find one that provides the features I need. It's entirely possible I may be wrong on that (particularly not having a good idea what solutions along those might look like when the time comes that they are needed). Since I haven't pulled the trigger on anything yet....I can always adjust plans if that is looking not to be the case as time gets closer. What kind of amazes me is the strength of reaction that some of these posts get. After-all, what does it matter to anyone else what a network runs behind it's firewall....it could be IPv6, IPv4, IPX/SPX or smoke signals... as long as it serves their needs and they aren't bleeding stuff out onto the public net that trashes anyone else's network...what does it matter? If I didn't know better I swear some folks here were getting a nickel every time some-one configured a NIC with IPv6. Christopher Engel From steve at ibctech.ca Tue Dec 29 18:32:25 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 29 Dec 2009 18:32:25 -0500 Subject: [arin-ppml] Policy Proposal 106: Simplified IPv6 policy In-Reply-To: <4B3A3095.4020000@arin.net> References: <4B3A3095.4020000@arin.net> Message-ID: <4B3A9189.7020809@ibctech.ca> Member Services wrote: > 6.3.1. Residential Customer Privacy ''(Copied from NRPM 6.5.5.1)'' > > 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. Looking for a little clarification... If I'm either lazy, or otherwise feel that NONE of my residential clients require a SWIP entry, does this piece of the policy allow me to reserve a portion of my /32 (eg. /44) for residential clients and SWIP the entire thing as a whole as 'Private Customer Block - XYZ Network' as opposed to SWIPing each individual /56 as private? Besides that, and until someone comes up with a better metric than 'N hosts' as a qualification, I support this policy. Steve From scottleibrand at gmail.com Tue Dec 29 19:22:35 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 29 Dec 2009 16:22:35 -0800 Subject: [arin-ppml] Policy Proposal 106: Simplified IPv6 policy In-Reply-To: <4B3A9189.7020809@ibctech.ca> References: <4B3A3095.4020000@arin.net> <4B3A9189.7020809@ibctech.ca> Message-ID: <4B3A9D4B.8040009@gmail.com> On 12/29/2009 3:32 PM, Steve Bertrand wrote: > Member Services wrote: > > >> 6.3.1. Residential Customer Privacy ''(Copied from NRPM 6.5.5.1)'' >> >> 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. >> > Looking for a little clarification... > > If I'm either lazy, or otherwise feel that NONE of my residential > clients require a SWIP entry, does this piece of the policy allow me to > reserve a portion of my /32 (eg. /44) for residential clients and SWIP > the entire thing as a whole as 'Private Customer Block - XYZ Network' as > opposed to SWIPing each individual /56 as private? > I'm going to start a new thread to reply to this, as this is existing policy text, not something that this proposal would change... > Besides that, and until someone comes up with a better metric than 'N > hosts' as a qualification, If anyone has suggestions for a better metric, please share. But IMO this policy proposal is structured to make it easy to change that metric later, so I'm not too worried about it if we have to wait until we have some experience with IPv6-only networks before we decide what it should be changed to. > I support this policy. > Thanks for expressing your opinion directly. -Scott From scottleibrand at gmail.com Tue Dec 29 19:23:25 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 29 Dec 2009 16:23:25 -0800 Subject: [arin-ppml] IPv6 whois/SWIP/privacy policy In-Reply-To: <4B3A9189.7020809@ibctech.ca> References: <4B3A3095.4020000@arin.net> <4B3A9189.7020809@ibctech.ca> Message-ID: <4B3A9D7D.2040401@gmail.com> On 12/29/2009 3:32 PM, Steve Bertrand wrote: > Member Services wrote: > > >> 6.3.1. Residential Customer Privacy ''(Copied from NRPM 6.5.5.1)'' >> >> 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. >> > Looking for a little clarification... > > If I'm either lazy, or otherwise feel that NONE of my residential > clients require a SWIP entry, does this piece of the policy allow me to > reserve a portion of my /32 (eg. /44) for residential clients and SWIP > the entire thing as a whole as 'Private Customer Block - XYZ Network' as > opposed to SWIPing each individual /56 as private? > I'm trying not to propose any changes to whois/SWIP/privacy policy, as that is an entirely different can of worms. Owen has already mentioned that he thinks we need to change existing IPv6 whois/SWIP/privacy policy. Perhaps this new thread would be a good opportunity to discuss ideas about how to do so? To get the discussion started, here are the IPv4 and IPv6 sections of the existing NRPM: https://www.arin.net/policy/nrpm.html#four237 > 4.2.3.7. Reassignment information > 4.2.3.7.1. Customer organization information > > ISPs are required to demonstrate efficient use of IP address space > allocations by providing appropriate documentation, including > assignment histories, showing their efficient use. SWIP and RWHOIS > reassignments should show each client's organizational information. > 4.2.3.7.2. /29s and larger nets > > ISPs must provide reassignment information on the entire previously > allocated block(s) via SWIP or RWHOIS server for /29 or larger blocks. > For blocks smaller than /29 and for internal space, ISPs should > provide utilization data via SWIP or RWHOIS server or by using the > format described in Section 4.2.3.7.5. > 4.2.3.7.3. Submit within 7 days > > Any time an ISP receives a new block of address space, reassignment > information should be submitted within 7 days of issuance of the new > space. This information is used to demonstrate that the address space > received is being efficiently utilized. Also, it will be reviewed to > determine an ISP's and its downstream customers' utilization > effectiveness if and when additional space is requested in the future. > 4.2.3.7.4. Visible via WHOIS > > This information must be visible via WHOIS prior to submitting a > request for a new allocation. For further information on reassigning > IP address space, please see RFC 2050. > 4.2.3.7.5. Accounting for additional utilization > > The following format should be used to provide the required > information for utilization of blocks smaller than /29 and for > describing internal networks when either SWIP or RWHOIS server is not > used: > City Which IP Addresses Assigned No. of Ports No. of > Dial-up Clients > City Which IP Addresses Assigned No. of Internal Machines > Purpose > Which IP Addresses Assigned List URLs for Websites > 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. https://www.arin.net/policy/nrpm.html#six55 > 6.5.5. Registration > > When an organization holding an IPv6 address allocation makes IPv6 > address assignments, it must register assignment information in a > database, accessible by RIRs as appropriate (information registered by > an RIR/NIR may be replaced by a distributed database for registering > address management information in future). Information is registered > in units of assigned /56 networks. When more than a /56 is assigned to > an organization, the assigning organization is responsible for > ensuring that the address space is registered in an RIR/NIR database. > > RIR/NIRs will use registered data to calculate the HD-Ratio at the > time of application for subsequent allocation and to check for changes > in assignments over time. > > IRs shall maintain systems and practices that protect the security of > personal and commercial information that is used in request > evaluation, but which is not required for public registration. > 6.5.5.1. Residential Customer Privacy (2003-3) > > 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. -Scott From info at arin.net Wed Dec 30 11:43:14 2009 From: info at arin.net (Member Services) Date: Wed, 30 Dec 2009 11:43:14 -0500 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocation criteria - revised Message-ID: <4B3B8322.1030609@arin.net> The proposal originator submitted a revised version of the proposal. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 101: Multihomed initial allocation criteria Proposal Originator: Chris Grundemann Proposal Version: 2 Date: 30 December 2009 Proposal type: modify Policy term: permanent Policy statement: Modify item letter "d." under section 6.5.1.1. Initial allocation criteria to the following: d. be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years or be currently Multihomed (or immediately become Multihomed) and have an ARIN assigned AS number. Rationale: I think this is a better approach than removing or lowering the end-site assignment requirement for any/all ISPs while still providing more open access to IPv6. Since these are "or" statements, it is one of the three, so existing LIR/ISP *or* 200 sites *or* multihomed. IMHO, if you are not multihomed *and* not serving (or planning to serve) at least 200 customers, you might not be (probably are not) an ISP. Timetable for implementation: immediate From marty at akamai.com Wed Dec 30 11:56:57 2009 From: marty at akamai.com (Martin Hannigan) Date: Wed, 30 Dec 2009 11:56:57 -0500 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocationcriteria - revised In-Reply-To: <4B3B8322.1030609@arin.net> References: <4B3B8322.1030609@arin.net> Message-ID: <1C4AC777-7938-4632-BFAF-8FA2DF17E25C@akamai.com> On Dec 30, 2009, at 11:43 AM, Member Services wrote: > > Modify item letter "d." under section 6.5.1.1. Initial allocation > criteria to the following: > > d. be an existing, known ISP in the ARIN region > > or > > have a plan for making at least 200 end-site assignments to other > organizations within 5 years > > or > > Isn't being in the ARIN region already implied and why do we keep perpetuating this ambiguous language? Why can't we write in english and write something like: "Be engaged in providing internet based services to end users or other networks and have a documented plan to assign at least 200 end-sites within five years". Best, -M< From Brian.Knight at us.mizuho-sc.com Wed Dec 30 11:50:11 2009 From: Brian.Knight at us.mizuho-sc.com (Knight, Brian) Date: Wed, 30 Dec 2009 11:50:11 -0500 Subject: [arin-ppml] The non-deployment of IPv6 - The Economic Factor In-Reply-To: <4B3A0E69.8060502@potsdam.edu> References: <35B0F632-5470-4E72-8625-8830AE91D48B@arin.net> <00ACE320-5703-403F-8937-5B9C443DD50A@arin.net><00ea01ca7934$68582d70$39088850$@com> <4B3A0E69.8060502@potsdam.edu> Message-ID: <54777E145E97BE4E8C5A26DD78EFB11B01DD9E30@EXMAIL.usi.mizuho-sc.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Keller > Sent: Tuesday, December 29, 2009 8:13 AM > To: VAUGHN THURMAN - SWIFT SYSTEMS INC > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] The non-deployment of IPv6 - The > Economic Factor > > Sorry to dredge an "old" thread back, but I'm catching up on > PPML and Vaughn's note really nailed a large segment of what > I've been explaining for several years now when dealing with > the "deploy IPv6 or you suck and are a bad netizen" crowd. > > > This (*The Economic Factor*) should not be underestimated > > I'll go one step further - Deploying IPv6 across a > perfectly-running enterprise network is excruciatingly daunting. > > This isn't daunting because admins lack the expertise or > confidence to do so, or haven't done it a bajillion times in > test environments, it's because our customers (and bosses) > don't care - they don't care one lick that you're rolling out > IPv6, whatever that is. The network is _working_, everything > is _fine_ and they very simply don't want to risk something > not working anymore: If it ain't broke, don't fix it. The > customer has plenty of other things they _do_ want. The customers and bosses likely care more about the operational risk of adding a new protocol to the production network. As long as that is mitigated by planning and testing, you're quite right, the bosses won't otherwise care about v6 -- *yet*. After v4 runout, it's an entirely different situation: there will be significant business risk in *not* embracing IPv6. If it's gonna break, ya wanna fix it before it does. > There is little-to-no consumer-driver to enable IPv6 in > established networks, and when coupled with Vaughn's > assessment of economic dissuasion, it paints a picture that > unless you are very well-off (capitally and/or > human-resourcely), _forced_ by outside powers (something to > show your customers and bosses to justify the risk of > change), or setting up a new network from scratch (you'd be stupid not > to): Trying to get "normal", established edge networks to > deploy IPv6 is one-step down from trying to herd cats. There are many folks who don't care about exactly how the Internet works, but they have got a set of expectations about whether it will work and whether they can make money with it. In my experience, it's usually those sorts of folks that call the shots and control the purse strings. I'm not worried about the economics or about getting management endorsement for v6 deployment when the time comes. > -- > Matthew Keller > Information Security Officer/Network Administrator Computing > & Technology Services State University of New York @ Potsdam > Potsdam, NY, USA _______________________________________________ -Brian Knight Sr. Network Engineer Mizuho Securities USA Inc http://www.mizuho-sc.com/ * Please note that I do not speak for my employer - only for myself. ** The below disclaimer is standard; the reader may consider addressees, mailing list members, and archive viewers to be intended recipients. CONFIDENTIAL: This e-mail, including its contents and attachments, if any, are confidential. It is neither an offer to buy or sell, nor a solicitation of an offer to buy or sell, any securities or any related financial instruments mentioned in it. If you are not the named recipient please notify the sender and immediately delete it. You may not disseminate, distribute, or forward this e-mail message or disclose its contents to anybody else. Unless otherwise indicated, copyright and any other intellectual property rights in its contents are the sole property of Mizuho Securities USA Inc. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Although we routinely screen for viruses, addressees should check this e-mail and any attachments for viruses. We make no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our customers and business, we may monitor and read e-mails sent to and from our server(s). ##################################################################################### From owen at delong.com Wed Dec 30 12:25:08 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 30 Dec 2009 09:25:08 -0800 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocation criteria - revised In-Reply-To: <4B3B8322.1030609@arin.net> References: <4B3B8322.1030609@arin.net> Message-ID: On Dec 30, 2009, at 8:43 AM, Member Services wrote: > The proposal originator submitted a revised version of the proposal. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 101: Multihomed initial allocation criteria > > Proposal Originator: Chris Grundemann > > Proposal Version: 2 > > Date: 30 December 2009 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Modify item letter "d." under section 6.5.1.1. Initial allocation > criteria to the following: > > d. be an existing, known ISP in the ARIN region > > or > > have a plan for making at least 200 end-site assignments to other > organizations within 5 years > > or > > be currently Multihomed (or immediately become Multihomed) and have an > ARIN assigned AS number. > Why would you want to preclude the use of legacy ASNs and/or ASNs issued by other registries? Otherwise, I'm generally OK with the policy, but, would be strongly in favor of it at 100 sites rather than 200 as I do know of ISPs that are smaller than 200 sites, are not multihomed, but, are legitimate. Owen From cgrundemann at gmail.com Wed Dec 30 12:32:31 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 30 Dec 2009 10:32:31 -0700 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocationcriteria - revised In-Reply-To: <1C4AC777-7938-4632-BFAF-8FA2DF17E25C@akamai.com> References: <4B3B8322.1030609@arin.net> <1C4AC777-7938-4632-BFAF-8FA2DF17E25C@akamai.com> Message-ID: <443de7ad0912300932v26430240l9e7f12d9d4b5472@mail.gmail.com> On Wed, Dec 30, 2009 at 09:56, Martin Hannigan wrote: > > On Dec 30, 2009, at 11:43 AM, Member Services wrote: > >> >> Modify item letter "d." under section 6.5.1.1. Initial allocation >> criteria to the following: >> >> d. be an existing, known ISP in the ARIN region >> >> or >> >> have a plan for making at least 200 end-site assignments to other >> organizations within 5 years >> >> or >> >> > > > Isn't being in the ARIN region already implied and why do we keep > perpetuating this ambiguous language? The first two statements are unchanged from current policy. This proposal is simply to add the third, multihomed criteria as an option. In the interest of keeping things simple, I was trying to only change one thing at a time. As i see it we have two options: a sweeping re-write of section 6 (or major portions of section 6) such as the abandoned pp103 and new pp106 propose or an incremental approach that nibbles away at the problems and slowly transforms section 6 into better policy. I am obviously taking the latter approach, perhaps to too extreme a degree. I would appreciate feedback on three questions: 1) Ignoring the unchanged policy bits, do you support the change being proposed? 2) Would you rather see a more sweeping change? I think your answer here is yes which makes the third question more relevant: 3) Where should the line be drawn? Rewrite the whole initial allocation criteria section (6.5.1.1)? The entire initial allocation section (6.5.1)? All of the "Policies for allocations and assignments" (6.5)? Or the entire section? It has been my experience that the smaller bite approach to policy change is easier to get right because there are less moving parts and knobs to turn in each individual proposal and thus easier to get the community to coalesce. ~Chris > Why can't we write in english and write something like: > > "Be engaged in providing internet based services to end users or other > networks and have a documented plan to assign at least 200 end-sites within > five years". > > > Best, > > -M< > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From cgrundemann at gmail.com Wed Dec 30 12:35:00 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 30 Dec 2009 10:35:00 -0700 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocation criteria - revised In-Reply-To: References: <4B3B8322.1030609@arin.net> Message-ID: <443de7ad0912300935s1920b450od576b4813582609@mail.gmail.com> On Wed, Dec 30, 2009 at 10:25, Owen DeLong wrote: > > On Dec 30, 2009, at 8:43 AM, Member Services wrote: >> be currently Multihomed (or immediately become Multihomed) and have an >> ARIN assigned AS number. >> > Why would you want to preclude the use of legacy ASNs and/or ASNs issued > by other registries? I had not thought of legacy ASNs - perhaps the wording should be "...and have a validly assigned AS number."? ~Chris > > Otherwise, I'm generally OK with the policy, but, would be strongly in favor > of it at 100 sites rather than 200 as I do know of ISPs that are smaller than > 200 sites, are not multihomed, but, are legitimate. > > Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From farmer at umn.edu Wed Dec 30 12:30:12 2009 From: farmer at umn.edu (David Farmer) Date: Wed, 30 Dec 2009 11:30:12 -0600 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocationcriteria - revised In-Reply-To: <1C4AC777-7938-4632-BFAF-8FA2DF17E25C@akamai.com> References: <4B3B8322.1030609@arin.net> <1C4AC777-7938-4632-BFAF-8FA2DF17E25C@akamai.com> Message-ID: <4B3B8E24.1070009@umn.edu> Martin Hannigan wrote: > > On Dec 30, 2009, at 11:43 AM, Member Services wrote: > >> >> Modify item letter "d." under section 6.5.1.1. Initial allocation >> criteria to the following: >> >> d. be an existing, known ISP in the ARIN region >> >> or >> >> have a plan for making at least 200 end-site assignments to other >> organizations within 5 years >> >> or >> >> > > > Isn't being in the ARIN region already implied and why do we keep > perpetuating this ambiguous language? Why can't we write in english and > write something like: How about even more clear, IMHO; Have an existing IPv4 ISP allocation from ARIN, or have a plan for making at least 200 end-site assignments to other organizations within 5 years. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From marty at akamai.com Wed Dec 30 13:37:45 2009 From: marty at akamai.com (Martin Hannigan) Date: Wed, 30 Dec 2009 13:37:45 -0500 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocationcriteria - revised In-Reply-To: <443de7ad0912300935s1920b450od576b4813582609@mail.gmail.com> References: <4B3B8322.1030609@arin.net> <443de7ad0912300935s1920b450od576b4813582609@mail.gmail.com> Message-ID: <8AEF20A7-9CA8-48E4-AF6F-6373E91C6DB9@akamai.com> On Dec 30, 2009, at 12:35 PM, Chris Grundemann wrote: > On Wed, Dec 30, 2009 at 10:25, Owen DeLong wrote: > > > > On Dec 30, 2009, at 8:43 AM, Member Services wrote: > > >> be currently Multihomed (or immediately become Multihomed) and > have an > >> ARIN assigned AS number. > >> > > Why would you want to preclude the use of legacy ASNs and/or ASNs > issued > > by other registries? > > I had not thought of legacy ASNs - perhaps the wording should be > "...and have a validly assigned AS number."? > It appears to me that the RSA covers the geographic requirements and that including them in policy is redundant and confusing. These additional requirements seem to make this policy intractable. Including the comments that I made related to the previous text (something I consider valid since this is a political process) I did intend to include that ASN requirement. If I were to write this in laymans english; [...] be multihomed, contractually obligated to become mult-homed and be eligible for assignment of IP address resources in the ARIN region. The rationale here is to let the RSA do it's job and us to do our job more easily. I'm not really in support of this policy as it stands, but might be with edits that clean it up. I don't agree with nibbles. Why not get it out of the way now and finally get it off of the to-do list? Best Regards, -M<