From Michael.Dillon at radianz.com Mon Aug 11 10:02:03 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 11 Aug 2003 15:02:03 +0100 Subject: [ppml] IANA is dead!? Message-ID: Does anyone have any recent evidence to suggest that IANA still exists and functions? I tried to contact them about a month ago and have received only a single reply from someone stating that they would review my email and get back to me at some indeterminate future date. Apparently ICANN is supposed to be running the "IANA function" under contract to the U.S. government but I've been unable to detect any "function" at all. Theoretically, IANA is supposed to hold the root responsibility for all of the IPv4 address space, but apparently they are unwilling to communicate with anyone about IP addresses other than RIR officials. This does not seem terribly responsible to me. I want to discuss the possibility of setting up a non-RIR registry similar the the 24/8 deal with the cable industry and the 57/8 deal with the air traffic industry. In my case I work in an industry (financial services) that has global networking requirements between many companies. However, these networks are somewhat different from the Internet. For one thing, they are not connected directly to the Internet. For another thing, the companies who interconnect are terribly interested in knowing who has registered addresses and who is using them and for what. In other words, filtering and ACLs all over the place. It is my assertion that this industry would be better served by having a global address registry separate from the RIRs. Before I start making the rounds of the various network operators in this industry to discuss this idea, I would like to find out under what circumstances it would be possible to proceed. If IANA cannot do this any more, then where is the joint RIR body who can discuss this issue? P.S. Financial Services refers to banking, stock exchanges, fund management, forex, trading networks, etc... ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From Michael.Dillon at radianz.com Mon Aug 11 10:26:41 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 11 Aug 2003 15:26:41 +0100 Subject: [ppml] IP Address Management Tools Message-ID: A few weeks ago, John Lewis said: >It doesn't help that there seems to be no suitable tool for tracking IP >utilization to the degree that ARIN applications require...at least none >that I've seen, and I've installed and tested several of the free >ones...and never got anywhere trying to get info or a test drive out of a >commercial one. This means for the average ISP, ARIN application time is >also IP utilization audit time. Not a fun time for whoever does it. >If someone were to develop an affordable (to the average small ISP) tool >for IP allocation tracking, and applying for more space was reduced to >filling out a few text fields on the ARIN application and including a >report from your allocation tracking system, I think there'd be alot less >complaining about the 3-month's supply policy by ISPs when they get to >their 3rd allocation and finally get slapped down by the 3-month policy. I suggest that ARIN should provide such a tool in furtherance of its purposes such as numbers 4, 5 and 8. You can read the full text of those numbered purposes at this URL: http://www.arin.net/library/corp_docs/amend_june_19_1997.pdf I would like to see a discussion of this on the agenda at the next members meeting. I envisage this tool as something which uses a proper hierarchical data model for IP addresse, not a relational data model, and which uses an appropriate programming language which could be incorporated into commercial software packages or adopted by enterprise IT departments. That probably means a Java framework combined with Python for scripting glue. http://www.jython.org Some things which are definitely not appropriate are MySQL and PERL. There are already several hack jobs that people have thrown together using PERL and MySQL but they don't do the job well enough, would never be adopted by enterprise IT departments or commercial network management packages. In addition, MySQL is a RELATIONAL database but IP address ranges are hierarchical in nature and are better suited to an object-oriented or a hierarchical database model. The intention is not to do another hack job but to provide a reference implementation that other people will adopt and integrate into their larger systems. ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From randy at psg.com Mon Aug 11 10:34:30 2003 From: randy at psg.com (Randy Bush) Date: Mon, 11 Aug 2003 07:34:30 -0700 Subject: [ppml] IANA is dead!? References: Message-ID: > Does anyone have any recent evidence to suggest that IANA still exists and > functions? works for me randy From baptista at dot-god.com Mon Aug 11 11:05:19 2003 From: baptista at dot-god.com (Joe Baptista) Date: Mon, 11 Aug 2003 11:05:19 -0400 (EDT) Subject: [ppml] IANA is dead!? In-Reply-To: Message-ID: thats a pretty lame response from someone who should know better. On Mon, 11 Aug 2003, Randy Bush wrote: > > Does anyone have any recent evidence to suggest that IANA still exists and > > functions? > > works for me > > randy > > From msalim at localweb.com Mon Aug 11 11:17:46 2003 From: msalim at localweb.com (A. Michael Salim) Date: Mon, 11 Aug 2003 11:17:46 -0400 (EDT) Subject: [ppml] IANA is dead!? In-Reply-To: Message-ID: Hi, An interesting application ... however forgive me for being ignorant but could this not be done by using the 10.x.x.x space and a physically private network - as you indicated, your networks are not connected to the Internet anyhow, and yet they presumably are interconnected in some other fashion perhaps through a backbone of routers using IPv4, in which case you are free to use the 10.x.x.x space as you will. If and when your private network needs to connect to the "real interent", presumably you could employ secure gateways or border routers, or some form of VPN maybe? best regards Mike Salim www.adti.us > I want to discuss the possibility of setting up a non-RIR registry similar > the the 24/8 deal with the cable industry and the 57/8 deal with the air > traffic industry. In my case I work in an industry (financial services) > that has global networking requirements between many companies. However, > these networks are somewhat different from the Internet. For one thing, > they are not connected directly to the Internet. For another thing, the > companies who interconnect are terribly interested in knowing who has > registered addresses and who is using them and for what. In other words, > filtering and ACLs all over the place. > > It is my assertion that this industry would be better served by having a > global address registry separate from the RIRs. Before I start making the > rounds of the various network operators in this industry to discuss this > idea, I would like to find out under what circumstances it would be > possible to proceed. If IANA cannot do this any more, then where is the > joint RIR body who can discuss this issue? > > P.S. Financial Services refers to banking, stock exchanges, fund > management, forex, trading networks, etc... From Michael.Dillon at radianz.com Mon Aug 11 12:21:37 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 11 Aug 2003 17:21:37 +0100 Subject: [ppml] IANA is dead!? Message-ID: >An interesting application ... however forgive me for being ignorant but >could this not be done by using the 10.x.x.x space and a physically >private network - as you indicated, your networks are not connected to the >Internet anyhow, As I said this is an industry, i.e. thousands of independent companies and organizations. Many of them already use RFC 1918 addresses in their own private networks. However, because the industry is built entirely on the notion of transactions between two or more organizations, there is a need for internetworking. These internets may not be *THE* Internet, but they are still internets and they need globally unique IP addresses to function. In almost every case, the organizations in the industry have internal networks that connect to both the public Internet and to multiple private internetworks. The trend is to reduce the number of private internetworks which means that these internets are becoming larger and more similar in character to the Internet. >If and when your >private network needs to connect to the "real interent", presumably you >could employ secure gateways or border routers, or some form of VPN maybe? These industry internets already use many forms of secure gateways, NAT, VPNs etc, much like the public Internet. But that doesn't make it possible to go very far reusing the same small blocks of RFC 1918 addresses over and over again. --Michael Dillon From andrew.dul at quark.net Mon Aug 11 13:21:58 2003 From: andrew.dul at quark.net (Andrew Dul) Date: Mon, 11 Aug 2003 10:21:58 -0700 Subject: [ppml] POC verification process Message-ID: <3.0.5.32.20030811102158.018c58c8@pop3.quark.net> Hello Everyone, We are requested feedback on the proposed text below. Your comments will be used in the creation of a policy that could go before the membership at the October meeting. This proposed policy was the offshoot of 2003-1 & 2003-2 at the spring meeting. Andrew Dul ARIN AC -------------------------------------------------------------------------- Purpose: This policy is intended to provide the Internet community with information regarding the accuracy of POC data listed in the ARIN whois database. This policy is designed to provide a framework for the ARIN staff to implement a system to publicly track the accuracy of a POC's data. Requirements: ARIN will setup a webform on their website to allow the Internet community at large to notify ARIN that a POC may be inaccurate. The public database states will be displayed in whois including the last verified date. Public Database States: - Active: The POC has been verified within the last year or there have been no reports that the POC data is inaccurate. - In-Process: The ARIN staff is currently investigating the accuracy of the POC. - Unverified: ARIN has been unable to verify the accuracy of the POC data. - Last Verified Date: The database will list the date when the POC data was last verified or if the data has never been verified the date when ARIN first displayed the accuracy state in whois. ARIN should also develop any additional private database states that are necessary to fulfill the verification process of the policy. Verification Process: If ARIN receives notification either internally or externally that a POC record may be inaccurate ARIN should start the process of verifying the POC if the POC has not been verified or updated within one year. ARIN should mark the POC as "In-Process" and send an email to the POC notifying them to verify the accuracy of the data listed. The email should contain the full POC information, information on how the user can update the data, and a method (email and/or webform) for the POC to certify the POC as accurate. If the POC has not been updated or certified within 15 days ARIN should send a fax if the POC has a listed fax number, if there is no fax listed the next verification method should be used. If the POC has not been updated or certified within the last 15 days of the last ARIN notice, ARIN should attempt to verify the POC by telephone call. If ARIN has been unable to reach the POC via telephone ARIN should send via regular mail a notice to the POC to update or certify their POC record. If the record has not been updated or verified within 20 days of notice via regular mail the record should be marked "Unverified" or "Delinquent". From william at elan.net Mon Aug 11 12:23:49 2003 From: william at elan.net (william at elan.net) Date: Mon, 11 Aug 2003 09:23:49 -0700 (PDT) Subject: [ppml] POC verification process In-Reply-To: <3.0.5.32.20030811102158.018c58c8@pop3.quark.net> Message-ID: > Purpose: This policy is intended to provide the Internet community with > information regarding the accuracy of POC data listed in the ARIN whois > database. This policy is designed to provide a framework for the ARIN > staff to implement a system to publicly track the accuracy of a POC's data. So we're now assuming its OK for AC and public in general to provide comments and procedures on operational issues to be dealt with by ARIN staff. Good. > Requirements: ARIN will setup a webform on their website to allow the > Internet community at large to notify ARIN that a POC may be inaccurate. > The public database states will be displayed in whois including the last > verified date. I agree with above. Would like to note that link needs to exist directly from website index page and from the page where whois results are displayed to the user. Might also be good idea to add comments additional comments to whois output (at the end after all the results are displayed) that if any data is known to be inaccurate the user should go to particular page or send email to hostmaster to report a problem. > Public Database States: > - Active: The POC has been verified within the last year or there have been > no reports that the POC data is inaccurate. > - In-Process: The ARIN staff is currently investigating the accuracy of the > POC. > - Unverified: ARIN has been unable to verify the accuracy of the POC data. I'm assuming state names and name of the field are not "set" yet. I do not like names "active" & "unverified" for the status, it should be "verified", "verification in process", "unverified" or better something like "Verification Status:" - "OK", "currently being verifiied", "inaccurate" My own names are not the best either ... Also what happens when telephone is ok but email is not? Maybe ARIN should specify what type of verification regarding accuracy of data ARIn did (i.e. if ARIN verified POC by telephone, email, address, etc). Also note that with ICANN they require user to send confirmation email they they indeed send report that something is not accurate with domain whois data (this protects against those who just want to annoy somebody or send these inacurate reports on purpose). The email reply to confirm report should be adapted by ARIN as well. > - Last Verified Date: The database will list the date when the POC data was > last verified or if the data has never been verified the date when ARIN > first displayed the accuracy state in whois. > > ARIN should also develop any additional private database states that are > necessary to fulfill the verification process of the policy. > > Verification Process: > If ARIN receives notification either internally or externally that a POC > record may be inaccurate ARIN should start the process of verifying the POC > if the POC has not been verified or updated within one year. One year is way too long. One month would be better (but I'm sure people will again scream at me on this being too short). Like I did with Whois AUP policy proposal it might be best to leave the up to ARIN staff when its decides that data needs to be verified but specify that if it has been verified in > 1 year ago they MUST do verification, otherwise then CAN do it, if ARIN staff receives too many reports that data is not accurate. > ARIN should mark the POC as "In-Process" and send an email to the POC > notifying them to verify the accuracy of the data listed. The email should > contain the full POC information, information on how the user can update > the data, and a method (email and/or webform) for the POC to certify the > POC as accurate. > > If the POC has not been updated or certified within 15 days ARIN should > send a fax if the POC has a listed fax number, if there is no fax listed > the next verification method should be used. Which one is next, phone? > If the POC has not been updated or certified within the last 15 days of the > last ARIN notice, ARIN should attempt to verify the POC by telephone call. I think ARIN should change status for POC after first 15 days to indicate that verification by email has failed and after 30 days that verification by telephone has failed as well but after 30 days it should send a letter to listed address and if ARIN does not receive reply after the letter then after another 30 days (so total 60 days from start of the process), it should mark POC data as completely unverifiable (i.e. email, telephone, address verification all failed). > If ARIN has been unable to reach the POC via telephone ARIN should send via > regular mail a notice to the POC to update or certify their POC record. > > If the record has not been updated or verified within 20 days of notice via > regular mail the record should be marked "Unverified" or "Delinquent". See my comments above on this. Also maybe one week before marking it completely inaccurate ARIN should attempt one last time by email and inform POC that if they do not respond data will be marked as complete inaccurate. Also in my opinion keeping there should be some consecuence to the company if their POC data is inaccurate (I'll separately from ARIN keep list of inaccurate POCs and ip blocks to which they correspond - first edition of this will be ready end of this month actually; but somethig more official maybe good idea as well). I don't want to immediatly get the ip block removed from ARIN database, but possibly the following are ok to do: 1. If this is SWIP, the parent ISP should be informed and maybe they can contact their client and get their POC data corrected if ISP can take decide remove the swip. 2. If this is ip block directly from ARIN, if there is yearly maintainer fee involved and all POCs for ip block are not accurate, ARIN billing should not allow to pay for ip block until data has been corrected. 3. For legacy ip blocks, I have no good suggestion on what to do. But possibly this should initiate futher investigation and ARIN should check if that business is still active or not (i.e. check state corporation records, etc). Possibly ARIN can try to verify data using older data if there were updates for ip blocks (yes, this works - sometimes old data is more accurate :) -- William Leibzon Elan Networks william at elan.net From ibaker at codecutters.org Tue Aug 12 03:27:17 2003 From: ibaker at codecutters.org (Ian Baker) Date: Tue, 12 Aug 2003 08:27:17 +0100 Subject: [ppml] POC verification process References: Message-ID: <006501c360a3$2bb0f920$642fa8c0@codecutters.org> ----- Original Message ----- From: To: Sent: Monday, August 11, 2003 5:21 PM Subject: Re: [ppml] IANA is dead!? > These industry internets already use many forms of secure gateways, NAT, > VPNs etc, much like the public Internet. But that doesn't make it possible > to go very far reusing the same small blocks of RFC 1918 addresses over > and over again. Just sticking to the 10 range in IPv4.. 16 million large organizations is not enough? (That's just assuming simple NAT, and that smaller organizations will continue to use the general Internet - lease-line telecoms are simply too expensive for such dedicated links). I dare say that IPv6 would solve the problem entirely.. after all, you're talking about a strictly private and proprietary network, so the appropriate hardware would be a tiny proportion of the overall infrastructure cost to set this all up. As goes data storage - given the relatively small amount of data and the availability of a simple hash (the numeric representation of the address), two flat files (address index and associated organization details) should be sufficient on any post-1995 machine.. That appears to suffice for Reuters, who, if memory serves, have a private IP network that encompasses pretty much all large and small players in that industry, with a variety of end-points at each customer premises. Regards, Ian Baker EMEA Support Manager OpenConnect Systems Ltd. http://www.openconnect.com - Where E-Business meets the Mainframe From Michael.Dillon at radianz.com Tue Aug 12 05:09:01 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 12 Aug 2003 10:09:01 +0100 Subject: [ppml] POC verification process Message-ID: >We are requested feedback on the proposed text below. Sounds good. >Verification Process: Whoa!!! Does that say process? I thought this was supposed to be a policy? Let's leave process details to the ARIN staff. If we need to mention it in the policy we could say something like ARIN Staff will attempt to contact the POC using email, fax, telephone and any other suitable means. If contact cannot be made after 30 days, then the status will be changed to... Please try to avoid micromanaging ARIN staff. We need to ensure that they have the flexibilty to deal with changing circumstances rather than yoke them with an overly bureaucratic mandate. In fact, I'm real uncomfortable about even mentioning time frames as in the 30 days I mentioned above. Unless timeframes are absolutely necessary as an upper limit, it might be better to ask ARIN to publish the date that the status was changed to "In-Process" so that we can clearly see the elapsed time and leave it at that. --Michael Dillon From Michael.Dillon at radianz.com Tue Aug 12 07:19:30 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 12 Aug 2003 12:19:30 +0100 Subject: [ppml] POC verification process Message-ID: >Just sticking to the 10 range in IPv4.. 16 million large organizations is >not enough? The problem is that it is unregistered and there is no way to control what ranges any organization might be using internally. If it were really feasible to build an internet without globally unique IP addresses, then ARIN would not even exist. >I dare say that IPv6 would solve the problem entirely. Yes. Because of the large address space, it is straightforward to get a large enough allocation to build a sizable internetwork. But v6 isn't here yet because the application developpers aren't pushing or supporting it. >after all, you're >talking about a strictly private and proprietary network, No. An internetwork, by its very nature, is not strictly private. There are many private companies who are sharing the internetwork just like the public Internet. The main difference is that the AUP of the public Internet is very loose and only prohibits network abusers from connecting. On the financial industry internets, the AUP requires companies to be in the industry and use the network to buy or sell services from each other. This may be something like a private club but it is still a public network within that industry because you and your competitors are all on the same internet. >That appears to suffice for Reuters, who, if memory serves, have a private >IP network that encompasses pretty much all large and small players in that >industry, with a variety of end-points at each customer premises. Reuters did not use RFC1918 addresses for their network; they simply borrowed ranges like 1/8, 2/8, 3/8, 4/8 etc. But that's history now. For over three years Reuters has been migrating their services to larger shared internets which use registered IP addresses. My company happens to run one of those shared internets, perhaps the larger one. Our internet also has about 100 providers of financial services in addition to Reuters on it. -- Michael Dillon From ibaker at codecutters.org Tue Aug 12 08:10:34 2003 From: ibaker at codecutters.org (Ian Baker) Date: Tue, 12 Aug 2003 13:10:34 +0100 Subject: [ppml] POC verification process References: Message-ID: <00d001c360ca$bf9b1d60$642fa8c0@codecutters.org> ----- Original Message ----- From: To: Sent: Tuesday, August 12, 2003 12:19 PM Subject: Re: [ppml] POC verification process > >Just sticking to the 10 range in IPv4.. 16 million large organizations is > >not enough? > > The problem is that it is unregistered and there is no way to control what > ranges any organization might be using internally. If it were really > feasible > to build an internet without globally unique IP addresses, then ARIN would > not even exist. Well, it seems to me that you are proposing an independant proprietary network addressing scheme. Since this is, by your own definition (it would appear to me) independant of the Internet, then I can't see the problem in simply using the 10 block and maintaining an independant record, one IP per defined organization. The organization could presumably just NAT from their network into yours. > >I dare say that IPv6 would solve the problem entirely. > > Yes. Because of the large address space, it is straightforward to get a > large > enough allocation to build a sizable internetwork. But v6 isn't here yet > because > the application developpers aren't pushing or supporting it. There's a reason for that. Well, several really. > >after all, you're > >talking about a strictly private and proprietary network, > > No. An internetwork, by its very nature, is not strictly private. There > are > many private companies who are sharing the internetwork just like the > public Internet. The main difference is that the AUP of the public > Internet > is very loose and only prohibits network abusers from connecting. On the > financial industry internets, the AUP requires companies to be in the > industry > and use the network to buy or sell services from each other. This may be > something like a private club but it is still a public network within that > industry because you and your competitors are all on the same internet. That's still proprietary, by my lights. Doesn't really matter whether it uses IP, baked bean cans and bits of string, or whatever. If you're enforcing some sort of access policy, then it's private. Period. Given that the vast majority of companies are moving away from precisely that sort of scenario to the public Internet, I can't really see people investing in such a thing - while it's fine for defined circumstances (e.g. dropping the serial lines to the LSE as part of the Sequence program in the mid-90s), but I personally can't see it as anything but a policy reversal. YMMV. > >That appears to suffice for Reuters, who, if memory serves, have a > private > >IP network that encompasses pretty much all large and small players in > that > >industry, with a variety of end-points at each customer premises. > > Reuters did not use RFC1918 addresses for their network; they simply > borrowed > ranges like 1/8, 2/8, 3/8, 4/8 etc. But that's history now. For over three > years > Reuters has been migrating their services to larger shared internets which > use > registered IP addresses. My company happens to run one of those shared > internets, > perhaps the larger one. Our internet also has about 100 providers of > financial > services in addition to Reuters on it. IIRC, Radianz were the Reuters spin-off when they decided to cut costs - post Bridge and Instinet - and flog HPSN (if I recall the name correctly - it's been a long time), under the tutelage of Dave Ure (again, if memory serves). Reuters themselves moved away from the fixed-connection Monitor network into IP, and, IIRC, provided DEC PDP-8 based units to allow NAT access to their (supposedly!) low-latency network by customers. [I say "supposedly" because a 30-second delay between the old switching centre at Singer Street and Singapore Editorial was more than a bit inconvenient in a VT320-based application)] I would suggest that your target customers would be best served by a consortium-led directory made up of the main players in the industry, and that - therefore - this isn't really a valid topic for discussion here. I personally see it more akin to synchronising POTS telephone directories than something requiring the formation of an independent international body. (Obviously, I'm more than willing to listen to other opinions on this). Please feel free to take this discussion private, should you prefer.. Regards, Ian Baker EMEA Support Manager OpenConnect Systems Ltd. From plzak at arin.net Tue Aug 12 08:20:40 2003 From: plzak at arin.net (Ray Plzak) Date: Tue, 12 Aug 2003 08:20:40 -0400 Subject: [ppml] IANA is dead!? In-Reply-To: Message-ID: <010301c360cc$2540e270$638888c0@arin.net> > > I want to discuss the possibility of setting up a non-RIR > registry similar > There are no non-RIR registries for this address space. Prospective users of this space must apply for it to an RIR and must meet the IPv4 justification criteria. Ray From cjw at groovy.com Tue Aug 12 10:14:45 2003 From: cjw at groovy.com (CJ Wittbrodt) Date: Tue, 12 Aug 2003 07:14:45 -0700 Subject: [ppml] IANA is dead!? In-Reply-To: Message from Michael.Dillon@radianz.com of "Mon, 11 Aug 2003 15:02:03 BST." Message-ID: <200308121414.h7CEEj716602@duchess.groovy.com> Just an addition to Ray's response. 24/8 was never a separate registry. It was a block allocated specifically to cable IP providers but it was always managed by the RIR system. The process for getting space in 24/8 was actually more stringent than the regular registry policies and required the RIR to review it and then for IANA to approve it. We also had to provide much more information about utilization than do regular ISPs. Be afraid of what you ask for, you just might get it. ---Cathy From: Michael.Dillon at radianz.com Subject: [ppml] IANA is dead!? Does anyone have any recent evidence to suggest that IANA still exists and functions? I tried to contact them about a month ago and have received only a single reply from someone stating that they would review my email and get back to me at some indeterminate future date. Apparently ICANN is supposed to be running the "IANA function" under contract to the U.S. government but I've been unable to detect any "function" at all. Theoretically, IANA is supposed to hold the root responsibility for all of the IPv4 address space, but apparently they are unwilling to communicate with anyone about IP addresses other than RIR officials. This does not seem terribly responsible to me. I want to discuss the possibility of setting up a non-RIR registry similar the the 24/8 deal with the cable industry and the 57/8 deal with the air traffic industry. In my case I work in an industry (financial services) that has global networking requirements between many companies. However, these networks are somewhat different from the Internet. For one thing, they are not connected directly to the Internet. For another thing, the companies who interconnect are terribly interested in knowing who has registered addresses and who is using them and for what. In other words, filtering and ACLs all over the place. It is my assertion that this industry would be better served by having a global address registry separate from the RIRs. Before I start making the rounds of the various network operators in this industry to discuss this idea, I would like to find out under what circumstances it would be possible to proceed. If IANA cannot do this any more, then where is the joint RIR body who can discuss this issue? P.S. Financial Services refers to banking, stock exchanges, fund management, forex, trading networks, etc... ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From Michael.Dillon at radianz.com Tue Aug 12 10:11:40 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 12 Aug 2003 15:11:40 +0100 Subject: [ppml] POC verification process Message-ID: >I would suggest that your target customers would be best served by a >consortium-led directory made up of the main players in the industry, and >that - therefore - this isn't really a valid topic for discussion here. I agree about the consortium but disagree about the discussion. There is only one IPv4 address space and it is a matter of public policy how this space is carved up and managed by different organizations. Right now there are roughly 3 classes of organizations that manage IPv4 space and each class does so under different rules. RIRs can reserve unallocated blocks and don't need to meet the 80% utilization rule. ISPs or LIRs have to justify receiving more space than they can use directly on the basis that they are providing network services to other orgs. And end users have to get their space from an ISP/LIR unless they need portability. In APNIC they have NIRs which are like national branches of the RIR. Now what I am proposing here is an RIR-like organization to serve the financial services industry. That is something which does not currently exist although there are precedents in the way SITA was given space for the air-traffic industry and the way that the North American cable industry was given a /8. Before one can reasonably discuss this with the companies which would form this type of new registry, one first needs to have some idea of how to go about getting an allocation of space. That is a matter of public policy so I am discussing it here. Also, I suspect that most organizations who would be part of the said consortium are also ARIN members so it does no harm to broach the subject in this forum. By the way, no matter how hard we try, it is not possible any more to create a private IP network that is not connected to the Internet. The Internet is defined as the collection of sites connected to the Internet. Nowadays, that includes just about every medium and large organization on the planet. It probably includes every single one of the companies which form the financial services industry. A reasonable assumption is that every one of these companies also uses RFC 1918 addressing internally in their private networks and the larger ones probably have an internal registry managing their use of RFC 1918 space. In that context, the only feasable way of building a private internet and avoid all manner of wierd addressing corner cases, is to use globally unique registered addresses just like the public Internet. This need was foreseen by the authors of RFC2050 which is why this is considered a valid usage of IPv4 addresses. Please do not call this a private network; it is not. It is a private internetwork or private internet that interconnects a large number of networks which are also connected to the public Internet. If it helps, you can envision this as a thin layer around the edge of the public Internet where stub networks have a non-transit IPv4 connection to each other through this thin layer. These stub networks are private networks belonging to companies like NYSE, Chicago Board of Trade, Merrill Lynch, Belzberg, Standard & Poor's, etc. Looking at the world from their point of view, they consider their privately owned corporate networks to be private networks and they consider RadianzNet (or SAVVIS Financial Xchange or SWIFTNet) to be a public network shared with their customers and competitors. --Michael Dillon From Michael.Dillon at radianz.com Tue Aug 12 10:22:35 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 12 Aug 2003 15:22:35 +0100 Subject: [ppml] IANA is dead!? Message-ID: >> I want to discuss the possibility of setting up a non-RIR >> registry similar >There are no non-RIR registries for this address space. Prospective >users of this space must apply for it to an RIR and must meet the IPv4 >justification criteria. There used to be non-RIR registries before we separated ARIN from the Internic and created ICANN. RIR means REGIONAL Internet Registry and there is something fundamentally wrong with that in the context of the global internets which serve the financial services industry. I don't expect ARIN to fix that by itself, but the discussion needs to take place somewhere and ARIN needs to be involved in the decision-making. To date, ICANN has been rather silent on the matter other than to suggest that the matter needs to be discussed with the regional registry policy makers first. The fact is that ARIN's current policies are too rigid and do not take into account the varying needs of today's ISPs. The policies were put in place when all ISPs were small rapidly growing entrepreneurial startups with virtually the same business model as every other ISP. The world has changed and now there are a wide variety of business models and a wide variety of ways in which IPv4 networks are constructed and managed. The ARIN policies are now attempting to enforce an obsolete business model and are an impediment to competition in the marketplace. The challenge is to change the policies before real damage is done to member businesses and legal actions are launched. I believe that there is broad support for policy reform within the ARIN membership. People do differ on the details but I do not detect any significant level of support for "business as usual". --Michael Dillon From ahp at hilander.com Tue Aug 12 10:42:12 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Tue, 12 Aug 2003 08:42:12 -0600 Subject: [ppml] IANA is dead!? In-Reply-To: References: Message-ID: <2147483647.1060677732@[192.168.1.100]> --On Tuesday, August 12, 2003 15:22 +0100 Michael.Dillon at radianz.com wrote: > > I believe that there is broad support for policy reform within the ARIN > membership. People do differ on the details but I do not detect any > significant level of support for "business as usual". The reason you do not detect such support is because you are only listening to the sounds, instead of listening to the silence. Therein is the problem with mailing list discussions, those who support change generally tend to participate more than those who support the status quo. I feel it is naive of you to make such a broad assumption, given how large the ARIN constituency is relative to the size of the group that participates in the policy process. There are many entities which exist quite happily within the parameters of the existing ARIN process. However, this is not to say that ARIN's policies are perfect, that too would be a fallacy. ARIN's policies are always evolving. Given the importance of the resources ARIN manages, it is prudent to make incremental changes, which is what registries have done historically. I'm aware that you have proposed some such changes, and for that I am grateful as an AC member. The AC is looking into the best way to evaluate the issues you have raised. Alec Chair, ARIN AC From ibaker at codecutters.org Tue Aug 12 13:41:01 2003 From: ibaker at codecutters.org (Ian Baker) Date: Tue, 12 Aug 2003 18:41:01 +0100 Subject: [ppml] POC verification process References: Message-ID: <006701c360f8$e962d470$642fa8c0@codecutters.org> ----- Original Message ----- From: To: Sent: Tuesday, August 12, 2003 3:11 PM Subject: Re: [ppml] POC verification process > >I would suggest that your target customers would be best served by a > >consortium-led directory made up of the main players in the industry, and > >that - therefore - this isn't really a valid topic for discussion here. > Now what I am proposing here is an RIR-like organization to serve the > financial services industry. That is something which does not currently > exist although there are precedents in the way SITA was given space for > the air-traffic industry and the way that the North American cable > industry > was given a /8. Before one can reasonably discuss this with the companies > which would form this type of new registry, one first needs to have some > idea of how to go about getting an allocation of space. That is a matter > of public policy so I am discussing it here. Also, I suspect that most > organizations who would be part of the said consortium are also ARIN > members > so it does no harm to broach the subject in this forum. Hmm? If there is only one address space (something I dispute), and backed-up by your comments concerning Reuters, then I would be very interested to hear the reasons as to why just one market sector (financial) should justify special attention over all other people and organizations on the planet. > By the way, no matter how hard we try, it is not possible any more to > create > a private IP network that is not connected to the Internet. Show me a CAT-5 crossover cable and two NICs and I'll show you a contradiction to that argument ;o) Given that, I guess that I won't have to explain security in military installations, and the internal "Chinese Walls" mandated by both law and regulation in (ahen) UK financial institutions..? > The Internet > is > defined as the collection of sites connected to the Internet. Nowadays, > that > includes just about every medium and large organization on the planet. > It probably includes every single one of the companies which form the > financial services industry. .. and the others.. > A reasonable assumption is that every one of these companies also uses RFC > 1918 addressing internally in their private networks and the larger ones > probably have an internal registry managing their use of RFC 1918 space. Remarkable reasonable, if untrue in a "couple" of instances that spring to mind - I have yet to come across any centralised database of *all* IPs in any organization that is not totally dedicated to such things (i.e. lies outside the telecoms sector). In addition, you would have to scratch anyone that uses DHCP, so out goes BT, NTL, etc. In fact, I can't think of a /single/ organization that has a fully comprehensive database as you describe. If we're willing to expand the parameters slightly, then we have a directory that is anything but unique to the financial sector. So why the proposed special treatment? > In > that context, the only feasable way of building a private internet and > avoid > all manner of wierd addressing corner cases, is to use globally unique > registered addresses just like the public Internet. This need was foreseen > by the authors of RFC2050 which is why this is considered a valid usage of > IPv4 addresses. Yes.. if I have the passage correctly, "the organization has no intention of connecting to the Internet-either now or in the future", and that the addresses should not be Internet routable. This is, in any event, something that I would have thought to be the remit of the RFC 2050 Working Group, rather than here? Simple NAT would solve the other issue, as currently used globally by millions. If it were an argument for the adoption of IPv6, then I'd accept its validity. > Please do not call this a private network; it is not. It is a private > internetwork > or private internet that interconnects a large number of networks which > are > also connected to the public Internet. If it helps, you can envision this > as a thin layer around the edge of the public Internet where stub networks > have a non-transit IPv4 connection to each other through this thin layer. I fail to see the distinction. By this logic, if I were to dial-out using the modem in my desktop machine, my /home/ network would also match this definition! Why not avoid the semantics and just refer to all of this as " a series of IP networks, forming one large IP network". Or, perhaps, "network" for short. > These stub networks are private networks belonging to companies like NYSE, > Chicago Board of Trade, Merrill Lynch, Belzberg, Standard & Poor's, etc. > Looking at the world from their point of view, they consider their > privately > owned corporate networks to be private networks and they consider > RadianzNet > (or SAVVIS Financial Xchange or SWIFTNet) to be a public network shared > with > their customers and competitors. I very much doubt that broad-brush assertion (having dealt with one of those network providers in the past as a partner/vendor; believe me, they were even clearer in person than on their website). Yes, those organizations have their own private networks, but, no, I do not agree that they consider the various VPN vendors to constitute a public network. Even if it /is/ firewalled and proxied to the hilt - I would hope that most organizations would have learnt from that unfortunate episode in Hong Kong. Which, to my mind, makes your proposal seem very like the Internet as it stands today - the only difference being that the Financial Services sector gets to set the rules for all other private individuals and other industrial sectors. Perhaps you could remind me - why exactly why would that be A Good Thing for anyone outside of that minority? Why we're at it, why not delegate the whole thing to AOL - after all, they have a more representative spread of customers (I hasten to point out that was a joke!) Regards, Ian Baker EMEA Support Manager OpenConnect Systems Ltd. From ahp at hilander.com Tue Aug 12 14:52:45 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Tue, 12 Aug 2003 12:52:45 -0600 Subject: [ppml] HD Ratio Applied to IPv4 Message-ID: <2147483647.1060692765@[192.168.1.101]> Greetings all, APNIC is looking at applying the HD Ratio system to IPv4 allocations. Attached is their draft document discussing the idea. I'm curious what people in the ARIN region think of the idea. Alec -------------- next part -------------- Discussion Document Application of the HD-Ratio to IPv4 Prepared by: Paul Wilson, APNIC Secretariat Version: 1.0 Date: 7 August 2003 1 Summary Internet address space is managed hierarchically, by allocation from IANA to RIRs and from RIRs to LIRs (ISPs), and by assignment from LIRs to infrastructure components and customer networks. Within each level of allocation or assignment some address space is generally reserved for future expansion and/or efficient aggregation. As more hierarchical levels are introduced into any address space, the overall efficiency of utilisation of that space (in terms of the total number of individual addresses actually used) will inevitably decrease. The HD Ratio (Host-Density Ratio) has been proposed as a practical mechanism for measuring the utilisation of addresses within hierarchically-managed Internet address blocks [RFC 3194]. A given HD Ratio value corresponds to a percentage utilisation which decreases as the size of the address space grows, thus allowing for the decreasing overall address management efficiency which is described above. The HD Ratio is currently used as the utilisation metric for IPv6 address space, under the current IPv6 management policy [ipv6-address-policy]. According to this policy, a block of IPv6 address space is considered to be effectively utilised when its HD-Ratio reaches 0.80. This value is said to represent a conservative but manageable figure ("values of 80% or less correspond to comfortable trade-offs between pain and efficiency" [RFC 3194]). This document explores the possible use of the HD Ratio for measurement of IPv4 utilisation, for the same purpose of determining when a given block of address space should be considered as fully utilised. 2 Background and problem The current management framework for IPv4 address space relies on policies developed within each RIR community [ipv4- address-policy]. These policies dictate, effectively, that a given block of IPv4 addresses should be considered "utilised" when at least 80% of the addresses within the block have been allocated or assigned. This measure is applied equally for address blocks held by small or large LIRs, regardless of their size. In any case, it is deemed that once 80% of the space held by an LIR has been allocated or assigned, that LIR may request more address space from its appropriate RIR. Current policies assume a hierarchical system of address space delegation (from IANA to RIRs to LIRs to customers, as described above), but they make no allowance for hierarchical address management within an organisation's own address space. For LIRs in particular, a hierarchical approach is often required for assignment of address space to service elements such as customer networks, individual POPs, regionalised topologies, and even distinct ISP products. Small network infrastructures may require simple hierarchies, but large infrastructures can require several levels of address space subdivision. These levels of hierarchy are "hidden" in terms of recognition by the current RIR policy framework, and highly constrained by the 80% utilisation requirement. As a result, management of large blocks is often extremely difficult, requiring large internal routing tables and/or frequent renumbering of internal address blocks. One of the goals of the RIR system is to avoid unnecessary depletion of IPv4 address space, and the 80% utilisation requirement may be justifiable on that basis. However address management policies must also be practical in terms of management overhead imposed. It may be argued that when large address spaces are involved, the "80% rule" imposes unreasonable management overheads on an LIR. A more reasonable approach should attempt to impose a uniform degree of management overhead, rather than penalising the holders of large address blocks. This may be achievable to some degree by basing utilisation requirements on the HD ratio rather than the fixed percentage-based measure which is in use today. 3 A Proposal In recognition of the problems outlined above, it is now proposed to consider replacing the current fixed percentage based utilisation requirement for IPv4 address space with an "HD Ratio" based requirement, referred to as the AD Ratio. 3.1 The HD Ratio According to RFC3194, The HD-Ratio is calculated as follows: HD = log(U)/log(S) Where: S is the size of the address block concerned, and U is the number of site addresses (/48s) which are utilised. In order to calculate the HD-Ratio for a given IPv6 block, it is necessary to know the size of that block, and number of host addresses which are in use. The current IPv6 policies allow for this by requiring registration of address assignments to the /48 level, however this degree of registration is not appropriate under IPv4 management policies. 3.2 Definition - the AD Ratio IPv4 address space utilisation is measured in terms of the number of allocations or assignments which have been made from a given address block, rather than the number of host addresses which are in use within the block. We therefore use the term "Allocation Density" for the measure of address space utilisation within an IPv4 block, rather than the term "Host Density" which represents host-address utilisation in IPv6. Consequently, we refer propose a new utilisation metric for IPv4, to be known as the "AD Ratio" (for Allocation or Assignment Density Ratio). The AD Ratio measures the number of addresses allocated or assigned from a given block of address space, as follows: AD = log(A)/log(S) Where: S is the size of the of the address block, and A is the number of addresses allocated or assigned from that block. 3.3 Selection of AD Ratio value The appropriate AD Ratio value for the purposes of this proposal should be decided on a rational basis. In order to do this, we make certain assumptions about the depth of "hidden" hierarchy involved in managing address blocks of various sizes. We then assume that at each level of this assumed hierarchy, the currently accepted 80% utilisation requirement is achieved, in order for the entire address space to be considered as fully utilised. The following table proposes a set of assumed hierarchical depths which may be reasonably expected within hierarchically-managed address spaces of certain sizes. At each delegation level an allocation density of 80% is assumed, so that within a hierarchy of "n" levels, the overall address space utilisation is calculated as 0.80 to the power of "n". Size range Depth Util AD Ratio (prefix) (n) (0.80**n) (calculated) /24 to /20 1 80% .960 to .973 /20 to /16 1.5 72% .961 to .970 /16 to /12 2 64% .960 to .968 /12 to /8 2.5 57.2% .960 to .966 /8 to /4 3 51.20% .960 to .966 Note: the above AD Ratio values are derived directly from the formula above. For instance, a /20 block contains 4096 addresses, and 80% utilisation corresponds to 3276.8 addresses; therefore the corresponding AD Ratio is calculated as log(3276.8)/log(4096) = 0.973 The depths of address hierarchy listed above are notional approximations only, based on general assumptions about the likely size and structure of LIRs holding address blocks in the respective size ranges. From the table, a rational common AD ratio value may be determined as 0.966 (chosen as the most conservative value which is common to all of the listed ranges). For this value, the following table gives the percentage utilisation requirement for the full range of IPv4 address blocks (this is also derived directly from the AD ratio formula shown above). IPv4 Addresses Addresses Util% Prefix Total Utilised 32 1 1 100.00% 31 2 2 97.67% 30 4 4 95.40% 29 8 7 93.17% 28 16 15 91.00% 27 32 28 88.88% 26 64 56 86.81% 25 128 109 84.79% 24 256 212 82.82% 23 512 414 80.89% 22 1024 809 79.00% 21 2048 1580 77.16% 20 4096 3087 75.37% 19 8192 6030 73.61% 18 16384 11780 71.90% 17 32768 23010 70.22% 16 65536 44949 68.59% 15 131072 87804 66.99% 14 262144 171518 65.43% 13 524288 335046 63.90% 12 1048576 654485 62.42% 11 2097152 1278482 60.96% 10 4194304 2497408 59.54% 9 8388608 4878479 58.16% 8 16777216 9529704 56.80% 7 33554432 18615487 55.48% 6 67108864 36363809 54.19% 5 134217728 71033685 52.92% 4 268435456 138758413 51.69% 3 536870912 271053050 50.49% 2 1073741824 529479652 49.31% 1 2147483648 1034294583 48.16% 0 4294967296 2020408681 47.04% Note: This table provides values for CIDR blocks only, however for non-CIDR blocks the same calculations can be applied to produce equally meaningful results. 4 Implementation If implemented at any particular level in the IP address delegation chain, this proposal would have a number of impacts on administrative processes at that level. It is not currently proposed to apply this proposal to the relationship between RIRs and IANA, therefore the implementation of the proposal at the RIR-LIR level is discussed there. 4.1 RIR-LIR Procedures The impact of the proposal on the RIR-LIR administrative procedures would be to replace the current 80% utilisation requirement, with a 0.966 AD Ratio requirement. By way of examples, an LIR holding a total address space equal to a /16 would be able to receive more address space when they had allocated or assigned 68.59% of that space; while an LIR holding a /9 would be able to receive more space when they had allocated or assigned 58.16% of their address space. For blocks smaller than /22, it is proposed that the current 80% requirement be used, in order that this new policy does not impose tighter utilisation requirements than were previously imposed. The AD-Ratio calculation is trivial, but certainly more complex and less intuitive than the existing 80% calculation. Some APNIC members may in some circumstances require extra assistance, however for those using the MyAPNIC service, the calculation would be automatic and therefore no additional effort would be involved. 4.2 Assignment procedures In order to support consistent calculation of an LIR's AD Ratio, it would be preferable for each LIR to register infrastructure assignments in the same way as customer assignments. This could be done by whois update via email, or via the MyAPNIC service. It would not be necessary to register individual hardware components or subnets, but rather only the independent infrastructure blocks which are designated by the LIR, and which can be justified on the same basis as customer assignments. Such registrations would be publicly visible as normal whois records, unless database changes were implemented to specifically hide them. 4.3 Implementation timeline If implemented, this policy could be effective within 3 months of the implementation date. 5 Impacts 5.1 Administrative Impact The primary administrative impact of this proposal is to ease the administrative address management burden experienced by LIRs, especially those with large address space holdings. The proposal recognises the need to manage address space hierarchically within an LIR service infrastructure, and makes allowance for it through the use of the AD ratio for assessment of address utilisation. This proposal would impose a small administrative cost on LIRs. In the first place, an LIR's internal systems (manual or automated) would need to incorporate a new method of calculating address space utilisation (and especially when determining the point at which the LIR may request more space from APNIC). In the second place, an LIR would need to register infrastructure assignments in the same way as customer assignments, which would impose additional administrative cost. In both cases, LIRs using the MyAPNIC service would experience a small extra cost because these changes can be automated within that system. The administrative impact on internal systems of the APNIC Secretariat is also relatively small. APNIC hostmaster processes can be tailored easily to accommodate a changed method of calculating address space utilisation; and the whois database can certainly accommodate an increased number of registrations. 5.2 Address Space Consumption Because this proposal lowers the utilisation requirement for IPv4 address blocks, it would certainly increase the rate of deployment of IP addresses. In analysing this impact, we can identify two separate factors contributing to increased consumption: firstly, an initial impact resulting from increased "wastage" of deployed address space; and secondly, on ongoing impact as utilisation requirements continue to fall for individual LIRs' growing address holdings. 5.2.1 Initial impact The initial impact on address consumption can be estimated by calculating for each APNIC LIR the difference between the current 80% utilisation, and the AD-ratio-determined utilisation requirement. This calculation will indicate the amount of extra "wasted" address space which would result from the proposed policy change. Total LIRs in sample 788 Total address space held 4.17 (/8 blocks) Utilised addresses (80%) 3.32 Utilised addresses (AD 0.966) 2.53* Extra "wasted" space 0.81 Extra "wastage" as % of total 19% * This figure is calculated from the sample of 788 LIRs, according to actual address space holdings These figures show that by reducing the address space utilisation requirement from 80% to AD 0.966, an additional 0.81 blocks are consumed out of a total 4.17 blocks allocated. This corresponds to an additional of 19% of the total allocated address space. It should be noted that this assessment indicates a theoretical impact in terms of increased address consumption, assuming all deployed address space is actually utilised. The actual impact will be less than this due to underutilisation of address space; and furthermore the impact will not take place at one time, but progressively as part of ongoing address space allocations. 5.2.2 Ongoing impact The ongoing impact on address consumption can be estimated by distributing additional address space to the same set of LIRs, in proportion to their existing address space holdings. For the purposes of this analysis, an additional /8 block is distributed to the same set of 788 LIRs, in proportion to their existing address holdings. Initial address space held 4.17 (/8 blocks) Additional space allocated 1.00 Total address space now held 5.17 Utilised addresses (AD 0.966) 3.11* Additional addresses utilised 0.58* Utilised addresses (80%) 0.80 Extra "wasted" space 0.22 Extra "wastage" as % of allocation 22% * These figures are calculated from the same sample of 788 LIRs, assuming a proportional distribution of an additional /8 block These figures show that after an additional /8 block is distributed and utilised, 58% of that block would actually be utilised, rather than 80%. Therefore up to 22% of that block would be "wasted" by the use of AD 0.966 in place of 80% as the utilisation measure, resulting potentially in an increased consumption rate of up to 22%. Again, this calculation is theoretical only, and assumes that all address space which has been distributed will be utilised. 5.2.3 Conclusions on address consumption The above analysis indicates that the adoption of this proposal would cause an initial additional consumption of up to 19% of address space allocated. In APNIC's case, a total of 8.07 /8 blocks have been allocated (as of 1 July 2003), so up to an additional 1.53 blocks would eventually be consumed as a result of the change. The analysis also indicates that this proposal would cause an overall 22% increase in the rate of address consumption. In APNIC's case, a total of 1.90 /8 blocks per year are currently being allocated (in the 12 months to 1 July 2003), and this rate would therefore rise to 2.32 blocks per year. The assumptions on which the above analysis is made include: firstly, that the 788 LIRs in the sample are representative of all LIRs in the region; and secondly, that a consistent rate of growth will be experienced by all LIRs in the region. 6 References [RFC 3194] "The Host-Density Ratio for Address Assignment Efficiency: An update on the H ratio", A. Durand, C.Huitema, November 2001. [ipv6-address-policy] APNIC document: "IPv6 Address Allocation and Assignment Policy" (http://www.apnic.net/docs/policy/ipv6-address-policy.html) [ipv4-address-policy] APNIC document: "Policies for IPv4 address space management in the Asia Pacific region" (http://www.apnic.net/docs/policy/add-manage-policy.html) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pkcs7-signature Size: 2288 bytes Desc: not available URL: From bmanning at karoshi.com Tue Aug 12 15:58:50 2003 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Tue, 12 Aug 2003 12:58:50 -0700 (PDT) Subject: [ppml] POC verification process In-Reply-To: from "Michael.Dillon@radianz.com" at Aug 12, 2003 03:11:40 PM Message-ID: <200308121958.h7CJwoT32425@karoshi.com> > > >I would suggest that your target customers would be best served by a > >consortium-led directory made up of the main players in the industry, and > >that - therefore - this isn't really a valid topic for discussion here. > > Now what I am proposing here is an RIR-like organization to serve the > financial services industry. That is something which does not currently > exist although there are precedents in the way SITA was given space for > the air-traffic industry and the way that the North American cable > industry > was given a /8. Before one can reasonably discuss this with the companies > which would form this type of new registry, one first needs to have some > idea of how to go about getting an allocation of space. That is a matter > of public policy so I am discussing it here. Also, I suspect that most > organizations who would be part of the said consortium are also ARIN > members > so it does no harm to broach the subject in this forum. > > --Michael Dillon If that is what you are proposing, why are you bringing it to ARIN at this time? What you need to do is to get the members of the financial services industry to agree among themselves on a single party to represent their interests to the RIR community. This new entity would have, as its customers, the members of the finacial services industry. They, presumably, would all be legally bound to only use the services of this "stovepipe" services group to manage their network addressing requirements. If such a group were to be formed, I have no doubt that ARIN would be happy to work with them to meet the needs of their customers. I honestly do not see anything unique or different here. It looks very much like normal ISP startup to me. --bill From sigma at smx.pair.com Tue Aug 12 16:40:11 2003 From: sigma at smx.pair.com (sigma at smx.pair.com) Date: Tue, 12 Aug 2003 16:40:11 -0400 (EDT) Subject: [ppml] HD Ratio Applied to IPv4 In-Reply-To: <2147483647.1060692765@[192.168.1.101]> from "Alec H. Peterson" at "Aug 12, 3 12:52:45 pm" Message-ID: <20030812204011.57157.qmail@smx.pair.com> > APNIC is looking at applying the HD Ratio system to IPv4 allocations. > Attached is their draft document discussing the idea. I'm curious what > people in the ARIN region think of the idea. The current situation, where 80% utilization is required for any size block, is more challenging when you have multiple levels of assignment downstream, subdividing the block, wasting boundary addresses, making it difficult to ensure that each assignment is well-utilized, etc. The AD-Ratio idea seems to reverse the situation. Now things are smooth for networks with multiple levels of assignment, but waaaay too loose for simpler networks. A company which has a /17, for example, and uses it entirely for their own networking, can now get new allocations after only 70.22% utilization. These companies (eg, datacenters, Web hosts, large workstation clusters, etc) have the best opportunity for utilization nearing 99%. This effectively gives those companies less reason to be efficient. Is there any way to distinguish the two scenarios usefully and adjust the idea accordingly? Kevin From billd at cait.wustl.edu Wed Aug 13 07:58:57 2003 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 13 Aug 2003 06:58:57 -0500 Subject: [ppml] HD Ratio Applied to IPv4 Message-ID: If one uses Philip Smith's number of 56% of available addresses allocated (in weekly routing table summary), one finds an AD Ratio for the entire IPv4 space of .97385 (log 2.4049/log 4.2945) which suggests to me that we are in need of a new allocation of IPv4 addresses... ;-) bd > -----Original Message----- > From: Alec H. Peterson [mailto:ahp at hilander.com] > Sent: Tuesday, August 12, 2003 1:53 PM > To: ppml at arin.net > Subject: [ppml] HD Ratio Applied to IPv4 > > > Greetings all, > > APNIC is looking at applying the HD Ratio system to IPv4 allocations. > Attached is their draft document discussing the idea. I'm > curious what > people in the ARIN region think of the idea. > > Alec > From lee.howard at mci.com Wed Aug 13 10:23:44 2003 From: lee.howard at mci.com (Lee Howard) Date: Wed, 13 Aug 2003 10:23:44 -0400 (EDT) Subject: [ppml] IANA is dead!? In-Reply-To: Message-ID: On Mon, 11 Aug 2003 Michael.Dillon at radianz.com wrote: > Date: Mon, 11 Aug 2003 17:21:37 +0100 > From: Michael.Dillon at radianz.com > To: ppml at arin.net > Subject: Re: [ppml] IANA is dead!? > > >An interesting application ... however forgive me for being ignorant but > >could this not be done by using the 10.x.x.x space and a physically > >private network - as you indicated, your networks are not connected to > the > >Internet anyhow, > > As I said this is an industry, i.e. thousands of independent companies and > organizations. Many of them already use RFC 1918 addresses in their own > private networks. However, because the industry is built entirely on the > notion of transactions between two or more organizations, there is a need > for internetworking. These internets may not be *THE* Internet, but they > are still internets and they need globally unique IP addresses to When I have encountered this kind of need in my day job, I have suggested that nobody needs "globally unique" addresses, only "unique within a given network" addresses. What we call the capital-I Internet is not the only internet, and any agency coordinating an internet can construct its own registry for that purpose. It is not clear to me that it is in the public interest to reserve IPv4 address space on a per-industry basis. > --Michael Dillon Lee From cscott at gaslightmedia.com Wed Aug 13 17:02:21 2003 From: cscott at gaslightmedia.com (Charles Scott) Date: Wed, 13 Aug 2003 17:02:21 -0400 (EDT) Subject: [ppml] HD Ratio Applied to IPv4 In-Reply-To: <20030812204011.57157.qmail@smx.pair.com> Message-ID: Kevin: I'm sorry, I'm just not getting this. It would seem that any particular level of assignment needs to stand on it's own. Why then would more levels of assignment below a particular level make that one level more challenging to manage. Also, the larger the assignment, the larger 20% of the assignment becomes, so it would seem to be easier to manage larger size blocks unless the size of the sub-assignments for some reason become proportionately lager relative to the size of the total block as one manages larger and larger blocks. I don't say the above rhetorically. If there's a good reason to make this kind of adjustment then it should be done. But when we're looking at a potential for significantly large additions of wasted (unassigned) space added to the equation, there should be darn'd good reason for making the change, particularly when it adds an additional level of confusion to the process. Chuck On Tue, 12 Aug 2003 sigma at smx.pair.com wrote: > > > APNIC is looking at applying the HD Ratio system to IPv4 allocations. > > Attached is their draft document discussing the idea. I'm curious what > > people in the ARIN region think of the idea. > > The current situation, where 80% utilization is required for any size > block, is more challenging when you have multiple levels of assignment > downstream, subdividing the block, wasting boundary addresses, making it > difficult to ensure that each assignment is well-utilized, etc. > > The AD-Ratio idea seems to reverse the situation. Now things are smooth > for networks with multiple levels of assignment, but waaaay too loose for > simpler networks. A company which has a /17, for example, and uses it > entirely for their own networking, can now get new allocations after only > 70.22% utilization. These companies (eg, datacenters, Web hosts, large > workstation clusters, etc) have the best opportunity for utilization > nearing 99%. This effectively gives those companies less reason to be > efficient. > > Is there any way to distinguish the two scenarios usefully and adjust the > idea accordingly? > > Kevin > From pwilson at apnic.net Wed Aug 13 21:03:28 2003 From: pwilson at apnic.net (Paul Wilson) Date: Thu, 14 Aug 2003 11:03:28 +1000 Subject: [ppml] HD Ratio Applied to IPv4 In-Reply-To: Message-ID: <63B9746D4A92BF498D78584958F537E30A511E@lotus.exchange> For background on the HD ratio, including the justification of this approach in preference to percentage-based utilisation measures, please see RFC3194. Paul Wilson APNIC > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Charles Scott > Sent: Thursday, 14 August 2003 7:02 AM > To: sigma at smx.pair.com > Cc: ppml at arin.net > Subject: Re: [ppml] HD Ratio Applied to IPv4 > > > > Kevin: > I'm sorry, I'm just not getting this. It would seem that > any particular level of assignment needs to stand on it's > own. Why then would more levels of assignment below a > particular level make that one level more challenging to manage. > Also, the larger the assignment, the larger 20% of the > assignment becomes, so it would seem to be easier to manage > larger size blocks unless the size of the sub-assignments for > some reason become proportionately > lager relative to the size of the total block as one manages > larger and > larger blocks. > I don't say the above rhetorically. If there's a good > reason to make this kind of adjustment then it should be > done. But when we're looking at a potential for significantly > large additions of wasted (unassigned) space added to the > equation, there should be darn'd good reason for making the > change, particularly when it adds an additional level of > confusion to the process. > > Chuck > > > > > On Tue, 12 Aug 2003 sigma at smx.pair.com wrote: > > > > > > APNIC is looking at applying the HD Ratio system to IPv4 > > > allocations. > > > Attached is their draft document discussing the idea. > I'm curious what > > > people in the ARIN region think of the idea. > > > > The current situation, where 80% utilization is required > for any size > > block, is more challenging when you have multiple levels of > assignment > > downstream, subdividing the block, wasting boundary > addresses, making > > it difficult to ensure that each assignment is well-utilized, etc. > > > > The AD-Ratio idea seems to reverse the situation. Now things are > > smooth for networks with multiple levels of assignment, but > waaaay too > > loose for simpler networks. A company which has a /17, for > example, > > and uses it entirely for their own networking, can now get new > > allocations after only 70.22% utilization. These companies (eg, > > datacenters, Web hosts, large workstation clusters, etc) > have the best > > opportunity for utilization nearing 99%. This effectively > gives those > > companies less reason to be efficient. > > > > Is there any way to distinguish the two scenarios usefully > and adjust > > the idea accordingly? > > > > Kevin > > > From sigma at smx.pair.com Wed Aug 13 21:22:51 2003 From: sigma at smx.pair.com (sigma at smx.pair.com) Date: Wed, 13 Aug 2003 21:22:51 -0400 (EDT) Subject: [ppml] HD Ratio Applied to IPv4 In-Reply-To: <63B9746D4A92BF498D78584958F537E30A511E@lotus.exchange> from Paul Wilson at "Aug 14, 3 11:03:28 am" Message-ID: <20030814012251.14776.qmail@smx.pair.com> http://www.faqs.org/rfcs/rfc3194.html It boils down to the fact that at each level of reassignment, there is waste and an inability to ensure the 80% utilization at each such level. That RFC is good reading, IMHO. Kevin > For background on the HD ratio, including the justification of this approach > in preference to percentage-based utilisation measures, please see RFC3194. > > Paul Wilson > APNIC > > > Behalf Of Charles Scott > > > > Kevin: > > I'm sorry, I'm just not getting this. It would seem that > > any particular level of assignment needs to stand on it's > > own. Why then would more levels of assignment below a > > particular level make that one level more challenging to manage. > > Also, the larger the assignment, the larger 20% of the > > assignment becomes, so it would seem to be easier to manage > > larger size blocks unless the size of the sub-assignments for > > some reason become proportionately > > lager relative to the size of the total block as one manages > > larger and > > larger blocks. > > I don't say the above rhetorically... From arin-member at quadrix.com Wed Aug 13 21:53:00 2003 From: arin-member at quadrix.com (Bill Van Emburg) Date: Wed, 13 Aug 2003 21:53:00 -0400 Subject: [ppml] POC verification process Message-ID: <3F3AEB7C.9070802@quadrix.com> What each of you who is following an argument similar to Ian's appears to be missing is that it is a very real problem for enterprises that are interconnected to avoid conflicting IP space, even within RFC 1918 addresses. In any case, they certainly don't globally coordinate their use of the private IP space. It is also not possible to simply grab a slice of public IP space, even though the networks involved will not connect to the Internet. This is because the enterprise would lose the ability to communicate with a piece of the Internet, since they would be routing that slice of addresses to a private network instead. At a previous venture, we used a slice of public IP space assigned to us for a network that would never see Internet-routed packets. The reason for this was that we were interconnecting the private networks of multiple customers. Each customer made use of the private IP space, and their various uses of it conflicted with each other. All of them needed to get packets to our back end network. The only way to ensure that a conflict of addressing could be avoided was to use addresses that would never be used on any customer's private network, and that would never need to be routed from our own internal network to the Internet. The only way to do *that* is with a slice of public IP space that we *know* is never going to be used by anyone else -- one that we had assigned to us. Do you understand the issue? I happen to think that the idea presented here is an excellent one, as it handles one of the largest examples of such a case. I would venture to guess that I was not the first one to think of doing as we did in my example above.... -- -- Bill Van Emburg Quadrix Solutions, Inc. Phone: 732-235-2335, x7016 (mailto:bve at quadrix.com) Fax: 732-235-2336 (http://quadrix.com) The eBusiness Solutions Company Ian Baker wrote: > ----- Original Message ----- > From: > To: > Sent: Tuesday, August 12, 2003 3:11 PM > Subject: Re: [ppml] POC verification process > > > >>>I would suggest that your target customers would be best served by a >>>consortium-led directory made up of the main players in the industry, and >>>that - therefore - this isn't really a valid topic for discussion here. >> > > > >>Now what I am proposing here is an RIR-like organization to serve the >>financial services industry. That is something which does not currently >>exist although there are precedents in the way SITA was given space for >>the air-traffic industry and the way that the North American cable >>industry >>was given a /8. Before one can reasonably discuss this with the companies >>which would form this type of new registry, one first needs to have some >>idea of how to go about getting an allocation of space. That is a matter >>of public policy so I am discussing it here. Also, I suspect that most >>organizations who would be part of the said consortium are also ARIN >>members >>so it does no harm to broach the subject in this forum. > > > Hmm? If there is only one address space (something I dispute), and backed-up > by your comments concerning Reuters, then I would be very interested to hear > the reasons as to why just one market sector (financial) should justify > special attention over all other people and organizations on the planet. > > > >>By the way, no matter how hard we try, it is not possible any more to >>create >>a private IP network that is not connected to the Internet. > From william at elan.net Wed Aug 13 19:45:16 2003 From: william at elan.net (william at elan.net) Date: Wed, 13 Aug 2003 16:45:16 -0700 (PDT) Subject: [ppml] POC verification process In-Reply-To: <3F3AEB7C.9070802@quadrix.com> Message-ID: Overall this situation seems to indicate that we need additional ip blocks to be reserved as non-routabled ip space (that everybody would also knew about and would filter at the router level). I'd say /1 and /2 are good choices for it. The idea would be to specify that 10.x is to be used for LAN while /1 or /2 is said to be used for WAN (meaning global scale) private networks. In addition somebody can keep track of all these private "WANs" and registries involved (like we already have WIANA discussed before) so that different industries not start to have duplicate private network operators (or if they do so we at least knew who they are). On Wed, 13 Aug 2003, Bill Van Emburg wrote: > What each of you who is following an argument similar to Ian's appears > to be missing is that it is a very real problem for enterprises that are > interconnected to avoid conflicting IP space, even within RFC 1918 > addresses. In any case, they certainly don't globally coordinate their > use of the private IP space. > > It is also not possible to simply grab a slice of public IP space, even > though the networks involved will not connect to the Internet. This is > because the enterprise would lose the ability to communicate with a > piece of the Internet, since they would be routing that slice of > addresses to a private network instead. > > At a previous venture, we used a slice of public IP space assigned to us > for a network that would never see Internet-routed packets. The reason > for this was that we were interconnecting the private networks of > multiple customers. Each customer made use of the private IP space, and > their various uses of it conflicted with each other. All of them needed > to get packets to our back end network. The only way to ensure that a > conflict of addressing could be avoided was to use addresses that would > never be used on any customer's private network, and that would never > need to be routed from our own internal network to the Internet. The > only way to do *that* is with a slice of public IP space that we *know* > is never going to be used by anyone else -- one that we had assigned to us. > > Do you understand the issue? I happen to think that the idea presented > here is an excellent one, as it handles one of the largest examples of > such a case. I would venture to guess that I was not the first one to > think of doing as we did in my example above.... From william at elan.net Wed Aug 13 19:46:36 2003 From: william at elan.net (william at elan.net) Date: Wed, 13 Aug 2003 16:46:36 -0700 (PDT) Subject: [ppml] POC verification process In-Reply-To: Message-ID: I meant 1.0.0.0/8 and 2.0.0.0/8 not /1 and /2. Sorry about mistype. On Wed, 13 Aug 2003 william at elan.net wrote: > > Overall this situation seems to indicate that we need additional ip blocks > to be reserved as non-routabled ip space (that everybody would also knew > about and would filter at the router level). I'd say /1 and /2 are good > choices for it. The idea would be to specify that 10.x is to be used for > LAN while /1 or /2 is said to be used for WAN (meaning global scale) > private networks. In addition somebody can keep track of all these private > "WANs" and registries involved (like we already have WIANA discussed before) > so that different industries not start to have duplicate private network > operators (or if they do so we at least knew who they are). > > On Wed, 13 Aug 2003, Bill Van Emburg wrote: > > > What each of you who is following an argument similar to Ian's appears > > to be missing is that it is a very real problem for enterprises that are > > interconnected to avoid conflicting IP space, even within RFC 1918 > > addresses. In any case, they certainly don't globally coordinate their > > use of the private IP space. > > > > It is also not possible to simply grab a slice of public IP space, even > > though the networks involved will not connect to the Internet. This is > > because the enterprise would lose the ability to communicate with a > > piece of the Internet, since they would be routing that slice of > > addresses to a private network instead. > > > > At a previous venture, we used a slice of public IP space assigned to us > > for a network that would never see Internet-routed packets. The reason > > for this was that we were interconnecting the private networks of > > multiple customers. Each customer made use of the private IP space, and > > their various uses of it conflicted with each other. All of them needed > > to get packets to our back end network. The only way to ensure that a > > conflict of addressing could be avoided was to use addresses that would > > never be used on any customer's private network, and that would never > > need to be routed from our own internal network to the Internet. The > > only way to do *that* is with a slice of public IP space that we *know* > > is never going to be used by anyone else -- one that we had assigned to us. > > > > Do you understand the issue? I happen to think that the idea presented > > here is an excellent one, as it handles one of the largest examples of > > such a case. I would venture to guess that I was not the first one to > > think of doing as we did in my example above.... > From marla_azinger at eli.net Thu Aug 14 12:05:27 2003 From: marla_azinger at eli.net (Azinger, Marla) Date: Thu, 14 Aug 2003 09:05:27 -0700 Subject: [ppml] POC verification process Message-ID: <5BD887EB4A582A439038636F7A93A5A701E5A117@wava00s2kexch01.eli.czn.com> Bill- You are not the one and only that has done this. We did the same things because we had a company that was resposible for connecting a large number of seperate 911 dispatch locations. All these locations had already utilized the private IP space and public IP's were the only way to avoid redundancy. Originally I had thought a proposal would have been needed in order to use the public ips for private use. However, after talking with several board members I discovered that it wasnt necessary and that use of the IP's this way was plenty justified. Marla Azinger Electric Lightwave -----Original Message----- From: Bill Van Emburg [mailto:arin-member at quadrix.com] Sent: Wednesday, August 13, 2003 6:53 PM To: ppml at arin.net Subject: Re: [ppml] POC verification process What each of you who is following an argument similar to Ian's appears to be missing is that it is a very real problem for enterprises that are interconnected to avoid conflicting IP space, even within RFC 1918 addresses. In any case, they certainly don't globally coordinate their use of the private IP space. It is also not possible to simply grab a slice of public IP space, even though the networks involved will not connect to the Internet. This is because the enterprise would lose the ability to communicate with a piece of the Internet, since they would be routing that slice of addresses to a private network instead. At a previous venture, we used a slice of public IP space assigned to us for a network that would never see Internet-routed packets. The reason for this was that we were interconnecting the private networks of multiple customers. Each customer made use of the private IP space, and their various uses of it conflicted with each other. All of them needed to get packets to our back end network. The only way to ensure that a conflict of addressing could be avoided was to use addresses that would never be used on any customer's private network, and that would never need to be routed from our own internal network to the Internet. The only way to do *that* is with a slice of public IP space that we *know* is never going to be used by anyone else -- one that we had assigned to us. Do you understand the issue? I happen to think that the idea presented here is an excellent one, as it handles one of the largest examples of such a case. I would venture to guess that I was not the first one to think of doing as we did in my example above.... -- -- Bill Van Emburg Quadrix Solutions, Inc. Phone: 732-235-2335, x7016 (mailto:bve at quadrix.com) Fax: 732-235-2336 (http://quadrix.com) The eBusiness Solutions Company Ian Baker wrote: > ----- Original Message ----- > From: > To: > Sent: Tuesday, August 12, 2003 3:11 PM > Subject: Re: [ppml] POC verification process > > > >>>I would suggest that your target customers would be best served by a >>>consortium-led directory made up of the main players in the industry, and >>>that - therefore - this isn't really a valid topic for discussion here. >> > > > >>Now what I am proposing here is an RIR-like organization to serve the >>financial services industry. That is something which does not currently >>exist although there are precedents in the way SITA was given space for >>the air-traffic industry and the way that the North American cable >>industry >>was given a /8. Before one can reasonably discuss this with the companies >>which would form this type of new registry, one first needs to have some >>idea of how to go about getting an allocation of space. That is a matter >>of public policy so I am discussing it here. Also, I suspect that most >>organizations who would be part of the said consortium are also ARIN >>members >>so it does no harm to broach the subject in this forum. > > > Hmm? If there is only one address space (something I dispute), and backed-up > by your comments concerning Reuters, then I would be very interested to hear > the reasons as to why just one market sector (financial) should justify > special attention over all other people and organizations on the planet. > > > >>By the way, no matter how hard we try, it is not possible any more to >>create >>a private IP network that is not connected to the Internet. > From cscott at gaslightmedia.com Thu Aug 14 15:34:31 2003 From: cscott at gaslightmedia.com (Charles Scott) Date: Thu, 14 Aug 2003 15:34:31 -0400 (EDT) Subject: [ppml] HD Ratio Applied to IPv4 In-Reply-To: <63B9746D4A92BF498D78584958F537E30A511E@lotus.exchange> Message-ID: Paul: OK, I've read the RFC, but don't agree with how this affects allocation from ARIN. I said before that I think each level of allocation/assignment needs to stand on it's own justification. The current policies set up parameters for this that I am hard-pressed to see why they are anything but reasonable. RFC 3194 seems to incorrectly suggest that IP utilization is strictly hierarchical. In fact, it's a segmented flat space where the utilization of a specific segment is only minimally affected by how any other part is utilized. The RCF uses phone numbers as an example, however, unlike telephone numbers which are strictly hierarchical, network numbers are not totally hierarchically dependent on each other unless you are truly anal about routing aggregation at each and every level. While I would agree that route aggregation is a concern, in most cases a provider assigns space to downstream customers and as such routing for that space is aggregated at their level anyway. Essentially, there are two types of levels in the hierarchy of address usage. One is an allocation of an address block by ARIN or a provider, and the other is utilization by an end user. Any level of assignment simply concerns the current available space at that level and the assignments to the next lower level. The 80% criteria seemingly provides adequate available space for assignment at a particular level. Once an assignment has been made, there is no other concern for lower levels of the hierarchy other than to ensure that the recipient can justify the assignment. The 80% criteria then similarly applies to that assignment if the recipient is another provider, otherwise the end-user utilization criteria apply. Since a provider does not need to show composite utilization for all address space assigned to a lower level, only a certain level of assignment (80%) and justification for those assignments, the overall utilization is not the critical number. So where's the beef in this proposal? Keep in mind that if a particular end-user assignment meets the 25%-50% criteria (clearly generous), the assignment is supportable and the provider ticks off the assigned block from their total. Also, if a provider assigns space to themselves for use, each such assignment that meets the 25%-50% criteria is considered consumed with respect to assignment and there is no need by the provider to show any particular level of composite utilization. I also don't buy the argument that renumbering is required when an end-user needs more space. This would be the case only if IP addressing had to follow a strict hierarchical structure as suggested in the RFC. Perhaps I'm still missing something, but I still can't see any justification for jeopardizing additional IP space with this proposal. Chuck On Thu, 14 Aug 2003, Paul Wilson wrote: > For background on the HD ratio, including the justification of this approach > in preference to percentage-based utilisation measures, please see RFC3194. From cscott at gaslightmedia.com Thu Aug 14 15:36:28 2003 From: cscott at gaslightmedia.com (Charles Scott) Date: Thu, 14 Aug 2003 15:36:28 -0400 (EDT) Subject: [ppml] HD Ratio Applied to IPv4 In-Reply-To: <20030814012251.14776.qmail@smx.pair.com> Message-ID: Kevin: Please read my response to Paul. Also note that the word "utilization" in this case seems to be confusing. In one case, utilization refers to the relative amount of address space assigned, and in the other case the relative number of individual address in use. The former relates to assignments by providers, and the latter relates to end usage. When clarified, there is no requirement by a provider to show a composite percentage of individual addresses in use, only to show that a certain percentage of an allocation has been assigned and is justifiable. If anything should be proposed, it should be that ARIN be a bit more consistent with this terminology and come up with a term other than "utilization" for consumption of space through assignment so as to avoid confusing the term with end-user address utilzation. Chuck On Wed, 13 Aug 2003 sigma at smx.pair.com wrote: > > http://www.faqs.org/rfcs/rfc3194.html > > It boils down to the fact that at each level of reassignment, there is > waste and an inability to ensure the 80% utilization at each such level. > That RFC is good reading, IMHO. > > Kevin > > > For background on the HD ratio, including the justification of this approach > > in preference to percentage-based utilisation measures, please see RFC3194. > > > > Paul Wilson > > APNIC > > > > > Behalf Of Charles Scott > > > > > > Kevin: > > > I'm sorry, I'm just not getting this. It would seem that > > > any particular level of assignment needs to stand on it's > > > own. Why then would more levels of assignment below a > > > particular level make that one level more challenging to manage. > > > Also, the larger the assignment, the larger 20% of the > > > assignment becomes, so it would seem to be easier to manage > > > larger size blocks unless the size of the sub-assignments for > > > some reason become proportionately > > > lager relative to the size of the total block as one manages > > > larger and > > > larger blocks. > > > I don't say the above rhetorically... > From ibaker at codecutters.org Thu Aug 14 16:18:49 2003 From: ibaker at codecutters.org (Ian Baker) Date: Thu, 14 Aug 2003 21:18:49 +0100 Subject: [ppml] POC verification process References: Message-ID: <015801c362a1$4fb31920$642fa8c0@codecutters.org> William's idea seems to be very valid - although I still dispute that, in general, a (random) address in Organization A will need to connect to a (random) address in Organization B. Except in relatively contrived circumstances (contrived enough that I can't think of one, off of the top of my head!) Shame that pinching the 172 private block would kill backwards-compatibility - I've still only come across one solitary organization that used it over the 192.168 and 10 blocks..! To be honest, though, I'm still having difficulty in trying to see why the already-allocated public IP addresses couldn't be used in a network that is never intended to be publicly addressable (which I believe was the initial argument?) I'm making an assumption here (more below) I'm afraid that I don't really agree with Bill's argument about "masking" part of the public Internet - for this to be the case, we would have to assume nothing on the company boundary and no proxies - there is no reason (short of deliberate misconfiguration) for a LAN client to address any internal site with anything other than an internal address. I really can't see an organization wanting to transmit all internal requests to (e.g.) the company web site via an external ISP. Waste of bandwidth. (That assumption - that noone would deliberately configure an external address for an internal server) OTOH, if we were to adopt William's suggestion, then there would be no /possibility/ of conflict, and each organization could use NAT, as mentioned previously, for their interconnections. It might start to get interesting, though, when we come to backup and DR connections - wouldn't each organization in the register require a minimum of two addresses (maybe three, if the DR is a fully hot standby)? Ian ----- Original Message ----- From: To: Sent: Thursday, August 14, 2003 12:45 AM Subject: Re: [ppml] POC verification process > > Overall this situation seems to indicate that we need additional ip blocks > to be reserved as non-routabled ip space (that everybody would also knew > about and would filter at the router level). I'd say /1 and /2 are good > choices for it. The idea would be to specify that 10.x is to be used for > LAN while /1 or /2 is said to be used for WAN (meaning global scale) > private networks. In addition somebody can keep track of all these private > "WANs" and registries involved (like we already have WIANA discussed before) > so that different industries not start to have duplicate private network > operators (or if they do so we at least knew who they are). > > On Wed, 13 Aug 2003, Bill Van Emburg wrote: > > > What each of you who is following an argument similar to Ian's appears > > to be missing is that it is a very real problem for enterprises that are > > interconnected to avoid conflicting IP space, even within RFC 1918 > > addresses. In any case, they certainly don't globally coordinate their > > use of the private IP space. > > > > It is also not possible to simply grab a slice of public IP space, even > > though the networks involved will not connect to the Internet. This is > > because the enterprise would lose the ability to communicate with a > > piece of the Internet, since they would be routing that slice of > > addresses to a private network instead. > > > > At a previous venture, we used a slice of public IP space assigned to us > > for a network that would never see Internet-routed packets. The reason > > for this was that we were interconnecting the private networks of > > multiple customers. Each customer made use of the private IP space, and > > their various uses of it conflicted with each other. All of them needed > > to get packets to our back end network. The only way to ensure that a > > conflict of addressing could be avoided was to use addresses that would > > never be used on any customer's private network, and that would never > > need to be routed from our own internal network to the Internet. The > > only way to do *that* is with a slice of public IP space that we *know* > > is never going to be used by anyone else -- one that we had assigned to us. > > > > Do you understand the issue? I happen to think that the idea presented > > here is an excellent one, as it handles one of the largest examples of > > such a case. I would venture to guess that I was not the first one to > > think of doing as we did in my example above.... > From owen at delong.com Fri Aug 15 01:41:28 2003 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Aug 2003 22:41:28 -0700 Subject: [ppml] PUBLIC ADDRESSES FOR PRIVATE NETWORKS In-Reply-To: <015801c362a1$4fb31920$642fa8c0@codecutters.org> References: <015801c362a1$4fb31920$642fa8c0@codecutters.org> Message-ID: <2147483647.1060900888@imac-en0.delong.sj.ca.us> I've seen multiple organizations use 172.16 as well as 192.168 and 10. It's not uncommon to use them for different classes of private network needs. I know of at least one case where an organization used 10 net to provide private addresses to their customers that needed to connect to a particular service over a private secured channel. They allocated particular 10 space to each customer purchasing that service, and, it was up to the customer to resolve any internal conflicts with it. In my opinion, if he really wanted to, Michael could find a way to make that work for his industry. In any case, it certainly doesn't belong on the POC verification thread, so I've changed the subject hoping that others will follow suit. (I'm interested in the POC verification thread). Owen --On Thursday, August 14, 2003 9:18 PM +0100 Ian Baker wrote: > William's idea seems to be very valid - although I still dispute that, in > general, a (random) address in Organization A will need to connect to a > (random) address in Organization B. Except in relatively contrived > circumstances (contrived enough that I can't think of one, off of the top > of my head!) > > Shame that pinching the 172 private block would kill > backwards-compatibility - I've still only come across one solitary > organization that used it over the 192.168 and 10 blocks..! > > To be honest, though, I'm still having difficulty in trying to see why the > already-allocated public IP addresses couldn't be used in a network that > is never intended to be publicly addressable (which I believe was the > initial argument?) I'm making an assumption here (more below) > > I'm afraid that I don't really agree with Bill's argument about "masking" > part of the public Internet - for this to be the case, we would have to > assume nothing on the company boundary and no proxies - there is no reason > (short of deliberate misconfiguration) for a LAN client to address any > internal site with anything other than an internal address. I really can't > see an organization wanting to transmit all internal requests to (e.g.) > the company web site via an external ISP. Waste of bandwidth. (That > assumption - that noone would deliberately configure an external address > for an internal server) > > OTOH, if we were to adopt William's suggestion, then there would be no > /possibility/ of conflict, and each organization could use NAT, as > mentioned previously, for their interconnections. It might start to get > interesting, though, when we come to backup and DR connections - wouldn't > each organization in the register require a minimum of two addresses > (maybe three, if the DR is a fully hot standby)? > > Ian > > ----- Original Message ----- > From: > To: > Sent: Thursday, August 14, 2003 12:45 AM > Subject: Re: [ppml] POC verification process > > >> >> Overall this situation seems to indicate that we need additional ip >> blocks to be reserved as non-routabled ip space (that everybody would >> also knew about and would filter at the router level). I'd say /1 and /2 >> are good choices for it. The idea would be to specify that 10.x is to be >> used for LAN while /1 or /2 is said to be used for WAN (meaning global >> scale) private networks. In addition somebody can keep track of all >> these private "WANs" and registries involved (like we already have WIANA >> discussed > before) >> so that different industries not start to have duplicate private network >> operators (or if they do so we at least knew who they are). >> >> On Wed, 13 Aug 2003, Bill Van Emburg wrote: >> >> > What each of you who is following an argument similar to Ian's appears >> > to be missing is that it is a very real problem for enterprises that >> > are interconnected to avoid conflicting IP space, even within RFC 1918 >> > addresses. In any case, they certainly don't globally coordinate their >> > use of the private IP space. >> > >> > It is also not possible to simply grab a slice of public IP space, even >> > though the networks involved will not connect to the Internet. This is >> > because the enterprise would lose the ability to communicate with a >> > piece of the Internet, since they would be routing that slice of >> > addresses to a private network instead. >> > >> > At a previous venture, we used a slice of public IP space assigned to >> > us for a network that would never see Internet-routed packets. The >> > reason for this was that we were interconnecting the private networks >> > of multiple customers. Each customer made use of the private IP >> > space, and their various uses of it conflicted with each other. All >> > of them needed to get packets to our back end network. The only way >> > to ensure that a conflict of addressing could be avoided was to use >> > addresses that would never be used on any customer's private network, >> > and that would never need to be routed from our own internal network >> > to the Internet. The only way to do *that* is with a slice of public >> > IP space that we *know* is never going to be used by anyone else -- >> > one that we had assigned to > us. >> > >> > Do you understand the issue? I happen to think that the idea presented >> > here is an excellent one, as it handles one of the largest examples of >> > such a case. I would venture to guess that I was not the first one to >> > think of doing as we did in my example above.... >> > From lee.howard at mci.com Fri Aug 15 13:14:08 2003 From: lee.howard at mci.com (Lee Howard) Date: Fri, 15 Aug 2003 13:14:08 -0400 (EDT) Subject: [ppml] public addresses for private networks In-Reply-To: <3F3AEB7C.9070802@quadrix.com> Message-ID: You make a good point that I have also encountered. . . . Let's say I set up an internet to interconnect all of the baked-goods industry. Some of those Hostess stores may also have Internet connections. If one router at a bakery has a connection to the Baked Goods Network and a connection to the Internet, the addresses between BGN and the Internet must not conflict. We can't use RFC1918 space, because there are millions of bakeries on the BGN and we've used up all of that space. Or because Hostess and Little Debbie both refused to renumber from their space, so we've already NATed them (I find this justification debatable). One proposal I've seen at the IETF is: http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-03.txt This suggests an additional network reservation of a /8 for numbering private provider networks. The idea as I understand it is for each organization to use RFC1918 space internally, but the interconnections would be numbered from this new space. I am agnostic on this draft, I merely point out its existence. Lee On Wed, 13 Aug 2003, Bill Van Emburg wrote: > Date: Wed, 13 Aug 2003 21:53:00 -0400 > From: Bill Van Emburg > To: ppml at arin.net > Subject: Re: [ppml] POC verification process > > What each of you who is following an argument similar to Ian's appears > to be missing is that it is a very real problem for enterprises that are > interconnected to avoid conflicting IP space, even within RFC 1918 > addresses. In any case, they certainly don't globally coordinate their > use of the private IP space. > > It is also not possible to simply grab a slice of public IP space, even > though the networks involved will not connect to the Internet. This is > because the enterprise would lose the ability to communicate with a > piece of the Internet, since they would be routing that slice of > addresses to a private network instead. > > At a previous venture, we used a slice of public IP space assigned to us > for a network that would never see Internet-routed packets. The reason > for this was that we were interconnecting the private networks of > multiple customers. Each customer made use of the private IP space, and > their various uses of it conflicted with each other. All of them needed > to get packets to our back end network. The only way to ensure that a > conflict of addressing could be avoided was to use addresses that would > never be used on any customer's private network, and that would never > need to be routed from our own internal network to the Internet. The > only way to do *that* is with a slice of public IP space that we *know* > is never going to be used by anyone else -- one that we had assigned to us. > > Do you understand the issue? I happen to think that the idea presented > here is an excellent one, as it handles one of the largest examples of > such a case. I would venture to guess that I was not the first one to > think of doing as we did in my example above.... > From Gregory_Zeibari at cable.comcast.com Mon Aug 18 14:26:04 2003 From: Gregory_Zeibari at cable.comcast.com (Zeibari, Gregory) Date: Mon, 18 Aug 2003 14:26:04 -0400 Subject: [ppml] IP Address Management Tools Message-ID: just an FYI... We have been working with a Company named Diamond IP Technologies, to develop such a tool to help us manage all of our private and public IP space, called NetControl. Please contact Michael Dooley directly at mdooley at diamondip.com, 610-423-4770 for more information. Thanks. Greg -----Original Message----- From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] Sent: Monday, August 11, 2003 10:27 AM To: ppml at arin.net Subject: [ppml] IP Address Management Tools A few weeks ago, John Lewis said: >It doesn't help that there seems to be no suitable tool for tracking IP >utilization to the degree that ARIN applications require...at least none >that I've seen, and I've installed and tested several of the free >ones...and never got anywhere trying to get info or a test drive out of a >commercial one. This means for the average ISP, ARIN application time is >also IP utilization audit time. Not a fun time for whoever does it. >If someone were to develop an affordable (to the average small ISP) tool >for IP allocation tracking, and applying for more space was reduced to >filling out a few text fields on the ARIN application and including a >report from your allocation tracking system, I think there'd be alot less >complaining about the 3-month's supply policy by ISPs when they get to >their 3rd allocation and finally get slapped down by the 3-month policy. I suggest that ARIN should provide such a tool in furtherance of its purposes such as numbers 4, 5 and 8. You can read the full text of those numbered purposes at this URL: http://www.arin.net/library/corp_docs/amend_june_19_1997.pdf I would like to see a discussion of this on the agenda at the next members meeting. I envisage this tool as something which uses a proper hierarchical data model for IP addresse, not a relational data model, and which uses an appropriate programming language which could be incorporated into commercial software packages or adopted by enterprise IT departments. That probably means a Java framework combined with Python for scripting glue. http://www.jython.org Some things which are definitely not appropriate are MySQL and PERL. There are already several hack jobs that people have thrown together using PERL and MySQL but they don't do the job well enough, would never be adopted by enterprise IT departments or commercial network management packages. In addition, MySQL is a RELATIONAL database but IP address ranges are hierarchical in nature and are better suited to an object-oriented or a hierarchical database model. The intention is not to do another hack job but to provide a reference implementation that other people will adopt and integrate into their larger systems. ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From eric at atlantech.net Mon Aug 18 15:53:57 2003 From: eric at atlantech.net (Eric Van Tol) Date: Mon, 18 Aug 2003 15:53:57 -0400 Subject: [ppml] IP Address Management Tools Message-ID: <4CBD2D346320D541AB8BF4C0140EF7CD40D897@staq7.hq.atlantech.net> Hello all, Changing my status from a lurker to a participant on this list, I would like to inject that we developed such a system in-house which manages all aspects of IP address management, as well. This system handles provisioning/deprovisioning of IP networks for customers and internal usage, reports usage by type of service, provides utilization statistics per service/subnet/customer, handles automatic updating of SWIP, network architecture information (ASNs, VLAN IDs, assigned routers, etc.), and many other aspects of IP management. The system was built almost entirely based upon the ARIN requirements for requesting new IP address space. As the ARIN requirements became somewhat clearer, the means by which to gather and store the data became much harder to deal with. A team of three very talented in-house programmers designed the system for us and it took them about a month or so to complete. Eric Van Tol Sr. Network Engineer Atlantech Online, Inc. http://www.atlantech.net 301.589.3060 voice 301.589.3936 fax NOC ===> http://noc.atlantech.net -----Original Message----- From: Zeibari, Gregory [mailto:Gregory_Zeibari at cable.comcast.com] Sent: Monday, August 18, 2003 2:26 PM To: 'Michael.Dillon at radianz.com'; ppml at arin.net Subject: RE: [ppml] IP Address Management Tools just an FYI... We have been working with a Company named Diamond IP Technologies, to develop such a tool to help us manage all of our private and public IP space, called NetControl. Please contact Michael Dooley directly at mdooley at diamondip.com, 610-423-4770 for more information. Thanks. Greg -----Original Message----- From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] Sent: Monday, August 11, 2003 10:27 AM To: ppml at arin.net Subject: [ppml] IP Address Management Tools A few weeks ago, John Lewis said: >It doesn't help that there seems to be no suitable tool for tracking IP >utilization to the degree that ARIN applications require...at least none >that I've seen, and I've installed and tested several of the free >ones...and never got anywhere trying to get info or a test drive out of a >commercial one. This means for the average ISP, ARIN application time is >also IP utilization audit time. Not a fun time for whoever does it. >If someone were to develop an affordable (to the average small ISP) tool >for IP allocation tracking, and applying for more space was reduced to >filling out a few text fields on the ARIN application and including a >report from your allocation tracking system, I think there'd be alot less >complaining about the 3-month's supply policy by ISPs when they get to >their 3rd allocation and finally get slapped down by the 3-month policy. I suggest that ARIN should provide such a tool in furtherance of its purposes such as numbers 4, 5 and 8. You can read the full text of those numbered purposes at this URL: http://www.arin.net/library/corp_docs/amend_june_19_1997.pdf I would like to see a discussion of this on the agenda at the next members meeting. I envisage this tool as something which uses a proper hierarchical data model for IP addresse, not a relational data model, and which uses an appropriate programming language which could be incorporated into commercial software packages or adopted by enterprise IT departments. That probably means a Java framework combined with Python for scripting glue. http://www.jython.org Some things which are definitely not appropriate are MySQL and PERL. There are already several hack jobs that people have thrown together using PERL and MySQL but they don't do the job well enough, would never be adopted by enterprise IT departments or commercial network management packages. In addition, MySQL is a RELATIONAL database but IP address ranges are hierarchical in nature and are better suited to an object-oriented or a hierarchical database model. The intention is not to do another hack job but to provide a reference implementation that other people will adopt and integrate into their larger systems. ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From billd at cait.wustl.edu Mon Aug 18 16:36:17 2003 From: billd at cait.wustl.edu (Bill Darte) Date: Mon, 18 Aug 2003 15:36:17 -0500 Subject: [ppml] IP Address Management Tools Message-ID: <7D6FB5D2AE48D84983C354E50E83C2560363BF@kronos.cait.wustl.edu> Eric, (and all others contributing to this thread) So... the question for you all is......... Are you interested in putting such software in the public domain?...or as shareware?....or making the design elements available?..etc. Bill Darte ARIN Advisory Council > -----Original Message----- > From: Eric Van Tol [mailto:eric at atlantech.net] > Sent: Monday, August 18, 2003 2:54 PM > To: ppml at arin.net > Subject: RE: [ppml] IP Address Management Tools > > > Hello all, > Changing my status from a lurker to a participant on this > list, I would > like to inject that we developed such a system in-house which manages > all aspects of IP address management, as well. This system handles > provisioning/deprovisioning of IP networks for customers and internal > usage, reports usage by type of service, provides utilization > statistics > per service/subnet/customer, handles automatic updating of > SWIP, network > architecture information (ASNs, VLAN IDs, assigned routers, etc.), and > many other aspects of IP management. > > The system was built almost entirely based upon the ARIN requirements > for requesting new IP address space. As the ARIN requirements became > somewhat clearer, the means by which to gather and store the > data became > much harder to deal with. A team of three very talented in-house > programmers designed the system for us and it took them about > a month or > so to complete. > > Eric Van Tol > Sr. Network Engineer > Atlantech Online, Inc. > http://www.atlantech.net > 301.589.3060 voice > 301.589.3936 fax > > NOC ===> http://noc.atlantech.net > > -----Original Message----- > From: Zeibari, Gregory [mailto:Gregory_Zeibari at cable.comcast.com] > Sent: Monday, August 18, 2003 2:26 PM > To: 'Michael.Dillon at radianz.com'; ppml at arin.net > Subject: RE: [ppml] IP Address Management Tools > > > just an FYI... > > We have been working with a Company named Diamond IP Technologies, to > develop such a tool to help us manage all of our private and public IP > space, called NetControl. > > Please contact Michael Dooley directly at mdooley at diamondip.com, > 610-423-4770 for more information. > > Thanks. > Greg > > -----Original Message----- > From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] > Sent: Monday, August 11, 2003 10:27 AM > To: ppml at arin.net > Subject: [ppml] IP Address Management Tools > > > A few weeks ago, John Lewis said: > > >It doesn't help that there seems to be no suitable tool for > tracking IP > > >utilization to the degree that ARIN applications require...at least > none > >that I've seen, and I've installed and tested several of the free > >ones...and never got anywhere trying to get info or a test > drive out of > a > > >commercial one. This means for the average ISP, ARIN > application time > is > > >also IP utilization audit time. Not a fun time for whoever does it. > > >If someone were to develop an affordable (to the average small ISP) > tool > >for IP allocation tracking, and applying for more space was > reduced to > >filling out a few text fields on the ARIN application and > including a > >report from your allocation tracking system, I think there'd be alot > less > > >complaining about the 3-month's supply policy by ISPs when > they get to > >their 3rd allocation and finally get slapped down by the 3-month > policy. > > I suggest that ARIN should provide such a tool in furtherance of its > purposes such as numbers 4, 5 and 8. You can read the full > text of those > > numbered purposes at this URL: > http://www.arin.net/library/corp_docs/amend_june_19_1997.pdf > > I would like to see a discussion of this on the agenda at the next > members > meeting. > > I envisage this tool as something which uses a proper > hierarchical data > model for IP addresse, not a relational data model, and which uses an > appropriate programming language which could be incorporated into > commercial software packages or adopted by enterprise IT departments. > That > probably means a Java framework combined with Python for > scripting glue. > > http://www.jython.org > > Some things which are definitely not appropriate are MySQL and PERL. > There > are already several hack jobs that people have thrown together using > PERL > and MySQL but they don't do the job well enough, would never > be adopted > by > enterprise IT departments or commercial network management > packages. In > addition, MySQL is a RELATIONAL database but IP address ranges are > hierarchical in nature and are better suited to an > object-oriented or a > hierarchical database model. The intention is not to do > another hack job > > but to provide a reference implementation that other people will adopt > and > integrate into their larger systems. > > ------------------------------------------------------- > Michael Dillon > Capacity Planning, Prescot St., London, UK > Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com > Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 > From hank.harris at visualware.com Mon Aug 18 16:55:12 2003 From: hank.harris at visualware.com (Hank Harris) Date: Mon, 18 Aug 2003 13:55:12 -0700 Subject: [ppml] IP Address Management Tools In-Reply-To: Message-ID: You should go to www.visualware.com and look at their DesktopResponse and VisualPulse products. The first will do what you are looking for. Hank -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Zeibari, Gregory Sent: Monday, August 18, 2003 11:26 AM To: 'Michael.Dillon at radianz.com'; ppml at arin.net Subject: RE: [ppml] IP Address Management Tools just an FYI... We have been working with a Company named Diamond IP Technologies, to develop such a tool to help us manage all of our private and public IP space, called NetControl. Please contact Michael Dooley directly at mdooley at diamondip.com, 610-423-4770 for more information. Thanks. Greg -----Original Message----- From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] Sent: Monday, August 11, 2003 10:27 AM To: ppml at arin.net Subject: [ppml] IP Address Management Tools A few weeks ago, John Lewis said: >It doesn't help that there seems to be no suitable tool for tracking IP >utilization to the degree that ARIN applications require...at least none >that I've seen, and I've installed and tested several of the free >ones...and never got anywhere trying to get info or a test drive out of a >commercial one. This means for the average ISP, ARIN application time is >also IP utilization audit time. Not a fun time for whoever does it. >If someone were to develop an affordable (to the average small ISP) tool >for IP allocation tracking, and applying for more space was reduced to >filling out a few text fields on the ARIN application and including a >report from your allocation tracking system, I think there'd be alot less >complaining about the 3-month's supply policy by ISPs when they get to >their 3rd allocation and finally get slapped down by the 3-month policy. I suggest that ARIN should provide such a tool in furtherance of its purposes such as numbers 4, 5 and 8. You can read the full text of those numbered purposes at this URL: http://www.arin.net/library/corp_docs/amend_june_19_1997.pdf I would like to see a discussion of this on the agenda at the next members meeting. I envisage this tool as something which uses a proper hierarchical data model for IP addresse, not a relational data model, and which uses an appropriate programming language which could be incorporated into commercial software packages or adopted by enterprise IT departments. That probably means a Java framework combined with Python for scripting glue. http://www.jython.org Some things which are definitely not appropriate are MySQL and PERL. There are already several hack jobs that people have thrown together using PERL and MySQL but they don't do the job well enough, would never be adopted by enterprise IT departments or commercial network management packages. In addition, MySQL is a RELATIONAL database but IP address ranges are hierarchical in nature and are better suited to an object-oriented or a hierarchical database model. The intention is not to do another hack job but to provide a reference implementation that other people will adopt and integrate into their larger systems. ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From Michael.Dillon at radianz.com Tue Aug 19 05:08:48 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 19 Aug 2003 10:08:48 +0100 Subject: [ppml] IP Address Management Tools Message-ID: >You should go to www.visualware.com and look at their >DesktopResponse and VisualPulse products. The first will do what >you are looking for. I really did not intend my request to open the door for mindless vendors flogging their wares. These products have nothing whatsoever to do with IP address management. To reiterate, John Lewis said this: >It doesn't help that there seems to be no suitable tool for >tracking IP utilization to the degree that ARIN applications >require...at least none that I've seen, and I've installed >and tested several of the free ones...and never got anywhere >trying to get info or a test drive out of a >commercial one. And I suggested the following because I would like the members to think about this and discuss it at the next members meeting. I suggest that ARIN should provide such a tool in furtherance of its purposes such as numbers 4, 5 and 8. You can read the full text of those numbered purposes at this URL: http://www.arin.net/library/corp_docs/amend_june_19_1997.pdf I would like to see a discussion of this on the agenda at the next members meeting. I envisage this tool as something which uses a proper hierarchical data model for IP addresse, not a relational data model, and which uses an appropriate programming language which could be incorporated into commercial software packages or adopted by enterprise IT departments. That probably means a Java framework combined with Python for scripting glue. http://www.jython.org Some things which are definitely not appropriate are MySQL and PERL. There are already several hack jobs that people have thrown together using PERL and MySQL but they don't do the job well enough, would never be adopted by enterprise IT departments or commercial network management packages. In addition, MySQL is a RELATIONAL database but IP address ranges are hierarchical in nature and are better suited to an object-oriented or a hierarchical database model. The intention is not to do another hack job but to provide a reference implementation that other people will adopt and integrate into their larger systems. --Michael Dillon From ibaker at codecutters.org Tue Aug 19 05:46:19 2003 From: ibaker at codecutters.org (Ian Baker) Date: Tue, 19 Aug 2003 10:46:19 +0100 Subject: [ppml] IP Address Management Tools References: Message-ID: <045d01c36636$c0c92260$642fa8c0@codecutters.org> ----- Original Message ----- From: To: Sent: Tuesday, August 19, 2003 10:08 AM Subject: RE: [ppml] IP Address Management Tools > I really did not intend my request to open the door for mindless vendors > flogging their wares. I think you might need to take a deep breath, there (although I understand your comment) > I suggest that ARIN should provide such a tool in furtherance of > its purposes such as numbers 4, 5 and 8. You can read the full > text of those numbered purposes at this URL: > http://www.arin.net/library/corp_docs/amend_june_19_1997.pdf > > I would like to see a discussion of this on the agenda at the > next members meeting. > > I envisage this tool as something which uses a proper > hierarchical data model for IP addresse, not a > relational data model, and which uses an appropriate > programming language which could be incorporated into > commercial software packages or adopted by enterprise IT > departments. That probably means a Java framework > combined with Python for scripting glue. > http://www.jython.org Hmm. Call me a meddling software guy, but mandating a particular technology over stipulating a thorough design is usually the recipe for a failed project. I would suggest that you might be better off getting together with a couple of designers and programmers and sorting the algorithms and metadata first (on first glance both fairly trivial tasks, given the crudity of the database model). A reference implemntation - in my personal view - is only useful once you have defined *external* interfaces, so that people aren't necessarily stuck with a single bit of technology that may or may not fall by the wayside just when the system itself is being adopted. At any rate, that's the sort of successful project work that I've seen over the years. I can think off-hand of several billion-dollar failures caused by picking a technology and then trying to bend the design to fit. Regards, Ian From arin-member at quadrix.com Tue Aug 19 10:46:19 2003 From: arin-member at quadrix.com (Bill Van Emburg) Date: Tue, 19 Aug 2003 10:46:19 -0400 Subject: [ppml] IP Address Management Tools In-Reply-To: References: Message-ID: <3F42383B.5000107@quadrix.com> I've recently run into another product that might fit the need, QIP. It was created by a company called, Quadritek, and sold to Lucent in 1999. If you go to http://www.quadritek.com, it'll take you to the right place within a Lucent web site. I haven't used the product, but it looks interesting for this type of application, and it's been used by enterprises for a while. -- -- Bill Van Emburg Quadrix Solutions, Inc. (mailto:bve at quadrix.com) (http://quadrix.com) The eBusiness Solutions Company Hank Harris wrote: > You should go to www.visualware.com and look at their > DesktopResponse and VisualPulse products. The first will do what > you are looking for. > > Hank > > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf > Of > Zeibari, Gregory > Sent: Monday, August 18, 2003 11:26 AM > To: 'Michael.Dillon at radianz.com'; ppml at arin.net > Subject: RE: [ppml] IP Address Management Tools > > > just an FYI... > > We have been working with a Company named Diamond IP > Technologies, to > develop such a tool to help us manage all of our private and > public IP > space, called NetControl. > > Please contact Michael Dooley directly at mdooley at diamondip.com, > 610-423-4770 for more information. > > Thanks. > Greg > > -----Original Message----- > From: Michael.Dillon at radianz.com > [mailto:Michael.Dillon at radianz.com] > Sent: Monday, August 11, 2003 10:27 AM > To: ppml at arin.net > Subject: [ppml] IP Address Management Tools > > > A few weeks ago, John Lewis said: > > >>It doesn't help that there seems to be no suitable tool for > > tracking IP > >>utilization to the degree that ARIN applications require...at > > least none > >>that I've seen, and I've installed and tested several of the > > free > >>ones...and never got anywhere trying to get info or a test drive > > out of a > > >>commercial one. This means for the average ISP, ARIN > > application time is > > >>also IP utilization audit time. Not a fun time for whoever does > > it. > > >>If someone were to develop an affordable (to the average small > > ISP) tool > >>for IP allocation tracking, and applying for more space was > > reduced to > >>filling out a few text fields on the ARIN application and > > including a > >>report from your allocation tracking system, I think there'd be > > alot less > > >>complaining about the 3-month's supply policy by ISPs when they > > get to > >>their 3rd allocation and finally get slapped down by the 3-month > > policy. > > I suggest that ARIN should provide such a tool in furtherance of > its > purposes such as numbers 4, 5 and 8. You can read the full text > of those > numbered purposes at this URL: > http://www.arin.net/library/corp_docs/amend_june_19_1997.pdf > > I would like to see a discussion of this on the agenda at the > next members > meeting. > > I envisage this tool as something which uses a proper > hierarchical data > model for IP addresse, not a relational data model, and which > uses an > appropriate programming language which could be incorporated into > commercial software packages or adopted by enterprise IT > departments. That > probably means a Java framework combined with Python for > scripting glue. > http://www.jython.org > > Some things which are definitely not appropriate are MySQL and > PERL. There > are already several hack jobs that people have thrown together > using PERL > and MySQL but they don't do the job well enough, would never be > adopted by > enterprise IT departments or commercial network management > packages. In > addition, MySQL is a RELATIONAL database but IP address ranges > are > hierarchical in nature and are better suited to an > object-oriented or a > hierarchical database model. The intention is not to do another > hack job > but to provide a reference implementation that other people will > adopt and > integrate into their larger systems. > From db6906 at sbc.com Tue Aug 19 12:34:54 2003 From: db6906 at sbc.com (BARGER, DAVE (SBIS)) Date: Tue, 19 Aug 2003 11:34:54 -0500 Subject: [ppml] IP Address Management Tools Message-ID: <6CE0DC2F2ED2B94F80357B939C5674010F1B3933@sbis0.sbcis.sbc.com> We have been using Lucent's QIP and Network Allocator product since 1999. Network Allocator 3.0 includes a lot of customization that we asked Lucent to do over the years, including automated assign/remove swips. These tools have served our needs very well. It is an excellent subnet managment tool, and also allows you to manage /32 assignments, DNS, and DHCP (although we use different platforms/products for DNS/DHCP). Managing over 800k subnets and 500k customer records, it scales rather nicely. I'll be at the October meeting, and would be glad to demo it if anyone is interested. Dave Barger Senior Technical Director Network Engineering IP Management SBC Internet Services 214-473-2098 (office) 877-514-7507 (pager) -----Original Message----- From: Bill Van Emburg [mailto:arin-member at quadrix.com] Sent: Tuesday, August 19, 2003 9:46 AM To: hank.harris at visualware.com Cc: Zeibari, Gregory; Michael.Dillon at radianz.com; ppml at arin.net Subject: Re: [ppml] IP Address Management Tools I've recently run into another product that might fit the need, QIP. It was created by a company called, Quadritek, and sold to Lucent in 1999. If you go to http://www.quadritek.com, it'll take you to the right place within a Lucent web site. I haven't used the product, but it looks interesting for this type of application, and it's been used by enterprises for a while. -- -- Bill Van Emburg Quadrix Solutions, Inc. (mailto:bve at quadrix.com) (http://quadrix.com) The eBusiness Solutions Company Hank Harris wrote: > You should go to www.visualware.com and look at their > DesktopResponse and VisualPulse products. The first will do what > you are looking for. > > Hank > > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf > Of > Zeibari, Gregory > Sent: Monday, August 18, 2003 11:26 AM > To: 'Michael.Dillon at radianz.com'; ppml at arin.net > Subject: RE: [ppml] IP Address Management Tools > > > just an FYI... > > We have been working with a Company named Diamond IP > Technologies, to > develop such a tool to help us manage all of our private and > public IP > space, called NetControl. > > Please contact Michael Dooley directly at mdooley at diamondip.com, > 610-423-4770 for more information. > > Thanks. > Greg > > -----Original Message----- > From: Michael.Dillon at radianz.com > [mailto:Michael.Dillon at radianz.com] > Sent: Monday, August 11, 2003 10:27 AM > To: ppml at arin.net > Subject: [ppml] IP Address Management Tools > > > A few weeks ago, John Lewis said: > > >>It doesn't help that there seems to be no suitable tool for > > tracking IP > >>utilization to the degree that ARIN applications require...at > > least none > >>that I've seen, and I've installed and tested several of the > > free > >>ones...and never got anywhere trying to get info or a test drive > > out of a > > >>commercial one. This means for the average ISP, ARIN > > application time is > > >>also IP utilization audit time. Not a fun time for whoever does > > it. > > >>If someone were to develop an affordable (to the average small > > ISP) tool > >>for IP allocation tracking, and applying for more space was > > reduced to > >>filling out a few text fields on the ARIN application and > > including a > >>report from your allocation tracking system, I think there'd be > > alot less > > >>complaining about the 3-month's supply policy by ISPs when they > > get to > >>their 3rd allocation and finally get slapped down by the 3-month > > policy. > > I suggest that ARIN should provide such a tool in furtherance of > its > purposes such as numbers 4, 5 and 8. You can read the full text > of those > numbered purposes at this URL: > http://www.arin.net/library/corp_docs/amend_june_19_1997.pdf > > I would like to see a discussion of this on the agenda at the > next members > meeting. > > I envisage this tool as something which uses a proper > hierarchical data > model for IP addresse, not a relational data model, and which > uses an > appropriate programming language which could be incorporated into > commercial software packages or adopted by enterprise IT > departments. That > probably means a Java framework combined with Python for > scripting glue. > http://www.jython.org > > Some things which are definitely not appropriate are MySQL and > PERL. There > are already several hack jobs that people have thrown together > using PERL > and MySQL but they don't do the job well enough, would never be > adopted by > enterprise IT departments or commercial network management > packages. In > addition, MySQL is a RELATIONAL database but IP address ranges > are > hierarchical in nature and are better suited to an > object-oriented or a > hierarchical database model. The intention is not to do another > hack job > but to provide a reference implementation that other people will > adopt and > integrate into their larger systems. > From memsvcs at arin.net Thu Aug 21 11:16:47 2003 From: memsvcs at arin.net (Member Services) Date: Thu, 21 Aug 2003 11:16:47 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-10: Apply the HD Ratio to All Future IPv4 Allocations Message-ID: <200308211516.LAA29608@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Chicago, Illinois, scheduled for October 22-23, 2003. All feedback received on the mailing list about this policy proposal will be included in the discussions that will take place at the upcoming Public Policy Meeting. This policy proposal discussion will take place on the ARIN Public Policy Mailing List (ppml at arin.net). Subscription information is available at http://www.arin.net/mailing_lists/index.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal regarding purpose and scope of whois directory. 1. ARIN shall maintain and publish a directory of contact information for the purposes of facilitating the operation of internconnected IP networks. 2. This directory will contain contact information for all organizations and individuals within the ARIN region who have received IP allocations or AS numbers directly from ARIN or its predecessors. 3. Organizations and individuals must guarantee to ARIN that contact addresses published in the whois directory will reach a person who is ready, willing and able to communicate regarding network operations and interconnect issues and who is able to act on that communication. 4. Any other organizations may elect to be listed in the whois directory as long as they make the guarantee detailed in item 3. 5. All contacts listed in the whois directory will be contacted every 3 months to verify that the contact addresses are still valid. 6. Any invalid contact information will be removed from the directory within 60 days of the first attempted contact from item 5. 7. ARIN will publish the whois directory in three forms using the whois protocol on port 43, bulk copies available by FTP and using the LDAP protocol. Why do this? Well, first of all I think that ARIN needs to have a clear policy statement of why we are collecting and publishing this directory. After that, items 2, 3 and 4 specify what information goes into the directory. Specifically, it excludes all organizations and individuals who have not received resources directly from ARIN unless they ask to be included. It also forces organizations to make a commitment to make sure that the contact information provides access to people who can do something about interconnect issues (peering), denial of service technical issues, abuse, etc. As currently, these addresses could be role accounts, P.O. boxes, voicemail numbers etc. Then items 5 and 6 specify that the data will be tested regularly and cleared out if it is stale. I think this is enough detail for the policy level to deal with. Most of the existing data will disappear after the 1st test period because people will either not respond or will not agree to the commitments in item 3. I don't intend for the entire database to be tested on the same day. I would hope that operationally this would be spread out over the 3 month period. And in 7, I am specifying that ARIN add an LDAP server to publish this directory because I feel that we should provide a real choice to people who need to access this directory. I suggest that a good way to start is to set up OpenLDAP and use the FIRS work done in the IETF's CRISP working group and then see how this all works out in practice. I believe that in the long run we will need to add back some kind of status information about the large number of address assignments that will no longer show up in whois and LDAP is ideally suited to doing this without a lot of anguish. In general, I see no reason why this could not be implemented by January 2004. I wouldn't expect 100% of the existing contacts to be tested by that time, but I would expect the testing to be well under way. Because the first round involves clearing out a much larger number of records, it could very well take until the middle of 2004 to have fully dealt with every one. A lot of this work could be alleviated if ISPs would provide lists of assignments for which they will take responsibility so that ARIN can remove those SWIP records wholesale without testing. ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From memsvcs at arin.net Thu Aug 21 11:28:00 2003 From: memsvcs at arin.net (Member Services) Date: Thu, 21 Aug 2003 11:28:00 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-10: Apply the HD Ratio to All Future IPv4 Allocations In-Reply-To: <200308211516.LAA29608@ops.arin.net> from "Member Services" at Aug 21, 2003 11:16:47 am Message-ID: <200308211528.LAA01371@ops.arin.net> Many apologies, the subject and text in the first post are mismatched. Please disregard and use this one. ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Chicago, Illinois, scheduled for October 22-23, 2003. All feedback received on the mailing list about this policy proposal will be included in the discussions that will take place at the upcoming Public Policy Meeting. This policy proposal discussion will take place on the ARIN Public Policy Mailing List (ppml at arin.net). Subscription information is available at http://www.arin.net/mailing_lists/index.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Proposal to apply the HD ratio to all future IPv4 allocations. 1. All requests for additional IPv4 address space shall require the efficient utilization of all previous allocations including all space reassigned to customers, if any. 2. The HD(Host Density) ratio of all previous allocations shall be greater than or equal to .966 and the HD ratio of the most recent allocation shall be greater than or equal to .930 in order to receive additional space. 3. The HD ratio is calculated as log10(utilized IPv4 addresses)/log10(totall addresses in all previous allocations). In this formula, log10 refers to the base 10 logarithm. Discussion of the proposal. For more details on the HD ratio, please refer to RFC 3194 http://www.faqs.org/rfcs/rfc3194.html and to a proposal by Paul Wilson posted to the APNIC mailing list on the 7th of August 2003 http://www.faqs.org/rfcs/rfc3194.html The basic thrust of my proposal is to replace the rigid 80% usage criterion by the more flexible HD ratio and to shift the emphasis away from the last allocated block to include the total allocated address space. To that end, the .930 criterion for the last block is a lot looser than the existing requirements for the last block. This recognizes that the economy is more dependent than ever on the smooth running of our networks and we should not artificially force members to operate with virtually no safety buffers for implementing new addresses. Paul Wilson's paper contains ample discussions of the justification for using the HD ratio. I prefer to retain the same name for the ratio as RFC 3194 and although I have proposed that we use the .966 number that he suggests, I believe there may be valid arguments for reducing this slightly, perhaps to .960. It would be good for ARIN to have more detailed discussion of the HD ratio on file however I don't believe that needs to be in the policy itself. However, I would suggest that the ARIN website should contain a copy of RFC 3194, a copy of Paul Wilson's paper, and a summary of any ARIN member discussions regarding application of the HD ratio to IPv4 addresses. Timetable for implementation I suggest that this proposal should be implemented within 30 days of a decision by a members meeting. ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From louie at equinix.com Thu Aug 21 11:34:49 2003 From: louie at equinix.com (Louis Lee) Date: Thu, 21 Aug 2003 08:34:49 -0700 Subject: [ppml] Policy Proposal 2003-10: Apply the HD Ratio to All Future IPv4 Allocations In-Reply-To: <200308211528.LAA01371@ops.arin.net> References: <200308211516.LAA29608@ops.arin.net> <200308211528.LAA01371@ops.arin.net> Message-ID: <20030821153448.GB26371@nemo.corp.equinix.com> On Thu, Aug 21, 2003 at 11:28:00AM -0400, Member Services wrote: > > Proposal to apply the HD ratio to all future IPv4 allocations. > > 1. All requests for additional IPv4 address space shall > require the efficient utilization of all previous > allocations including all space reassigned to customers, > if any. > The basic thrust of my proposal is to replace the rigid > 80% usage criterion by the more flexible HD ratio and to > shift the emphasis away from the last allocated block to > include the total allocated address space. To that end, > the .930 criterion for the last block is a lot looser > than the existing requirements for the last block. This > recognizes that the economy is more dependent than ever > on the smooth running of our networks and we should not > artificially force members to operate with virtually no > safety buffers for implementing new addresses. Is it the intent of the proposal author to differentiate ARIN-allocated space from ARIN-assigned space? It looks to be that way, but I'd rather make sure. Louie ------------------------------------------------------- Louis Lee louie at equinix.com Staff Network Engineer company: 650/513-7000 Equinix, Inc. desk: 650/513-7162 http://www.equinix.com/ fax: 650/513-7903 From memsvcs at arin.net Thu Aug 21 11:37:57 2003 From: memsvcs at arin.net (Member Services) Date: Thu, 21 Aug 2003 11:37:57 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Directory Message-ID: <200308211537.LAA02945@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Chicago, Illinois, scheduled for October 22-23, 2003. All feedback received on the mailing list about this policy proposal will be included in the discussions that will take place at the upcoming Public Policy Meeting. This policy proposal discussion will take place on the ARIN Public Policy Mailing List (ppml at arin.net). Subscription information is available at http://www.arin.net/mailing_lists/index.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal regarding purpose and scope of whois directory. 1. ARIN shall maintain and publish a directory of contact information for the purposes of facilitating the operation of internconnected IP networks. 2. This directory will contain contact information for all organizations and individuals within the ARIN region who have received IP allocations or AS numbers directly from ARIN or its predecessors. 3. Organizations and individuals must guarantee to ARIN that contact addresses published in the whois directory will reach a person who is ready, willing and able to communicate regarding network operations and interconnect issues and who is able to act on that communication. 4. Any other organizations may elect to be listed in the whois directory as long as they make the guarantee detailed in item 3. 5. All contacts listed in the whois directory will be contacted every 3 months to verify that the contact addresses are still valid. 6. Any invalid contact information will be removed from the directory within 60 days of the first attempted contact from item 5. 7. ARIN will publish the whois directory in three forms using the whois protocol on port 43, bulk copies available by FTP and using the LDAP protocol. Why do this? Well, first of all I think that ARIN needs to have a clear policy statement of why we are collecting and publishing this directory. After that, items 2, 3 and 4 specify what information goes into the directory. Specifically, it excludes all organizations and individuals who have not received resources directly from ARIN unless they ask to be included. It also forces organizations to make a commitment to make sure that the contact information provides access to people who can do something about interconnect issues (peering), denial of service technical issues, abuse, etc. As currently, these addresses could be role accounts, P.O. boxes, voicemail numbers etc. Then items 5 and 6 specify that the data will be tested regularly and cleared out if it is stale. I think this is enough detail for the policy level to deal with. Most of the existing data will disappear after the 1st test period because people will either not respond or will not agree to the commitments in item 3. I don't intend for the entire database to be tested on the same day. I would hope that operationally this would be spread out over the 3 month period. And in 7, I am specifying that ARIN add an LDAP server to publish this directory because I feel that we should provide a real choice to people who need to access this directory. I suggest that a good way to start is to set up OpenLDAP and use the FIRS work done in the IETF's CRISP working group and then see how this all works out in practice. I believe that in the long run we will need to add back some kind of status information about the large number of address assignments that will no longer show up in whois and LDAP is ideally suited to doing this without a lot of anguish. In general, I see no reason why this could not be implemented by January 2004. I wouldn't expect 100% of the existing contacts to be tested by that time, but I would expect the testing to be well under way. Because the first round involves clearing out a much larger number of records, it could very well take until the middle of 2004 to have fully dealt with every one. A lot of this work could be alleviated if ISPs would provide lists of assignments for which they will take responsibility so that ARIN can remove those SWIP records wholesale without testing. ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From louie at equinix.com Thu Aug 21 11:53:49 2003 From: louie at equinix.com (Louis Lee) Date: Thu, 21 Aug 2003 08:53:49 -0700 Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Directory In-Reply-To: <200308211537.LAA02945@ops.arin.net> References: <200308211537.LAA02945@ops.arin.net> Message-ID: <20030821155348.GD26371@nemo.corp.equinix.com> On Thu, Aug 21, 2003 at 11:37:57AM -0400, Member Services wrote: > > Policy Proposal regarding purpose and scope of whois directory. > 2. This directory will contain contact information for all > organizations and individuals within the ARIN region who > have received IP allocations or AS numbers directly from > ARIN or its predecessors. To make the text a little better, I propose that "IP allocations or AS numbers" be changed to "Internet numbering resources" so that IP assignments are included if this better- reflects the intent of the proposal's author. Louie ------------------------------------------------------- Louis Lee louie at equinix.com Staff Network Engineer company: 650/513-7000 Equinix, Inc. desk: 650/513-7162 http://www.equinix.com/ fax: 650/513-7903 From forrest at almighty.c64.org Thu Aug 21 14:13:16 2003 From: forrest at almighty.c64.org (Forrest) Date: Thu, 21 Aug 2003 13:13:16 -0500 (CDT) Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks Message-ID: Hi everyone, I was just curious if this proposal is any closer to being approved? I've noticed that the wording has been changed to reduce the minimum block size to /22 instead of /24. I haven't seen any discussion on this for awhile. Forrest From jmcburnett at msmgmt.com Thu Aug 21 14:18:30 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Thu, 21 Aug 2003 14:18:30 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks Message-ID: <9BF6F06C4BC90746ADD6806746492A332AEE27@msmmail01.msmgmt.com> Forrest, According to one of the ARIN staff members I spoke to said this was still in the works.. But I have not seen the wording change.. Thanks, Jim Richard? Einar? -> -> ->Hi everyone, I was just curious if this proposal is any ->closer to being ->approved? I've noticed that the wording has been changed to ->reduce the ->minimum block size to /22 instead of /24. I haven't seen any ->discussion ->on this for awhile. -> ->Forrest -> -> From forrest at almighty.c64.org Thu Aug 21 14:24:36 2003 From: forrest at almighty.c64.org (Forrest) Date: Thu, 21 Aug 2003 13:24:36 -0500 (CDT) Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks In-Reply-To: <9BF6F06C4BC90746ADD6806746492A332AEE27@msmmail01.msmgmt.com> Message-ID: Here's the link to the proposal currently on the ARIN website. http://www.arin.net/policy/2002_3.html Personally I'm a little disappointed that the proposal is only to reduce the minimum to /22, though I suppose with all the opposition against doing anything at all it was probably done to find a middle ground. My feelings on this personally are that since the current minimum that "the internet" accepts is /24, the micro-assignment policy really should be reduced to /24, especially since LACNIC and APNIC both have micro-allocation policies that have /24 as a minimum. Forrest On Thu, 21 Aug 2003, McBurnett, Jim wrote: > > Forrest, > According to one of the ARIN staff members I spoke to > said this was still in the works.. But I have not seen > the wording change.. > Thanks, > Jim > > Richard? Einar? > > > -> > -> > ->Hi everyone, I was just curious if this proposal is any > ->closer to being > ->approved? I've noticed that the wording has been changed to > ->reduce the > ->minimum block size to /22 instead of /24. I haven't seen any > ->discussion > ->on this for awhile. > -> > ->Forrest > -> > -> > -- Visit my Commodore 64 Website http://almighty.c64.org/ From mury at goldengate.net Thu Aug 21 15:19:38 2003 From: mury at goldengate.net (Mury) Date: Thu, 21 Aug 2003 14:19:38 -0500 (CDT) Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Directory In-Reply-To: <200308211537.LAA02945@ops.arin.net> Message-ID: Sounds good to me with two exceptions. Under #5 I think testing every 3 months is a little overboard. Maybe once a year is more reasonable. Under #3 and #4 I don't understand the 'guarantee' word and concept. Perhaps the word guarantee should be replaced with something more appropriate. What exactly happens to the resource holder if they don't keep the info up to date? They merely get their contact info removed from the directory? I know the argument over policy enforcement has been thrown around with little resolution, but I think there either needs to be a consequence with real teeth or nothing at all. For example, add language that forces the removal of the resources from the entity not providing current contact info, or just write the policy to say the resource holder shall provide contact info... remove the guarantee language and remove #6. My two cents. Mury On Thu, 21 Aug 2003, Member Services wrote: > ARIN welcomes feedback and discussion about the following policy > proposal in the weeks leading to the ARIN Public Policy Meeting > in Chicago, Illinois, scheduled for October 22-23, 2003. All feedback > received on the mailing list about this policy proposal will be > included in the discussions that will take place at the upcoming > Public Policy Meeting. > > This policy proposal discussion will take place on the ARIN Public > Policy Mailing List (ppml at arin.net). Subscription information is > available at http://www.arin.net/mailing_lists/index.html > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal regarding purpose and scope of whois directory. > > 1. ARIN shall maintain and publish a directory of contact information for > the purposes of facilitating the operation of internconnected IP networks. > > 2. This directory will contain contact information for all organizations > and individuals within the ARIN region who have received IP allocations or > AS numbers directly from ARIN or its predecessors. > > 3. Organizations and individuals must guarantee to ARIN that contact > addresses published in the whois directory will reach a person who is > ready, willing and able to communicate regarding network operations and > interconnect issues and who is able to act on that communication. > > 4. Any other organizations may elect to be listed in the whois directory > as long as they make the guarantee detailed in item 3. > > 5. All contacts listed in the whois directory will be contacted every 3 > months to verify that the contact addresses are still valid. > > 6. Any invalid contact information will be removed from the directory > within 60 days of the first attempted contact from item 5. > > 7. ARIN will publish the whois directory in three forms using the whois > protocol on port 43, bulk copies available by FTP and using the LDAP > protocol. > > Why do this? > > Well, first of all I think that ARIN needs to have a clear policy > statement of why we are collecting and publishing this directory. > > After that, items 2, 3 and 4 specify what information goes into the > directory. Specifically, it excludes all organizations and individuals who > have not received resources directly from ARIN unless they ask to be > included. It also forces organizations to make a commitment to make sure > that the contact information provides access to people who can do > something about interconnect issues (peering), denial of service technical > issues, abuse, etc. As currently, these addresses could be role accounts, > P.O. boxes, voicemail numbers etc. > > Then items 5 and 6 specify that the data will be tested regularly and > cleared out if it is stale. I think this is enough detail for the policy > level to deal with. Most of the existing data will disappear after the 1st > test period because people will either not respond or will not agree to > the commitments in item 3. I don't intend for the entire database to be > tested on the same day. I would hope that operationally this would be > spread out over the 3 month period. > > And in 7, I am specifying that ARIN add an LDAP server to publish this > directory because I feel that we should provide a real choice to people > who need to access this directory. I suggest that a good way to start is > to set up OpenLDAP and use the FIRS work done in the IETF's CRISP working > group and then see how this all works out in practice. I believe that in > the long run we will need to add back some kind of status information > about the large number of address assignments that will no longer show up > in whois and LDAP is ideally suited to doing this without a lot of > anguish. > > In general, I see no reason why this could not be implemented by January > 2004. I wouldn't expect 100% of the existing contacts to be tested by that > time, but I would expect the testing to be well under way. Because the > first round involves clearing out a much larger number of records, it > could very well take until the middle of 2004 to have fully dealt with > every one. A lot of this work could be alleviated if ISPs would provide > lists of assignments for which they will take responsibility so that ARIN > can remove those SWIP records wholesale without testing. > > ------------------------------------------------------- > Michael Dillon > Capacity Planning, Prescot St., London, UK > Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com > Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 > From ahp at hilander.com Thu Aug 21 15:24:14 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Thu, 21 Aug 2003 13:24:14 -0600 Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Directory In-Reply-To: <200308211537.LAA02945@ops.arin.net> References: <200308211537.LAA02945@ops.arin.net> Message-ID: <2147483647.1061472253@[192.168.1.101]> --On Thursday, August 21, 2003 11:37 AM -0400 Member Services wrote: > > 7. ARIN will publish the whois directory in three forms using the whois > protocol on port 43, bulk copies available by FTP and using the LDAP > protocol. Could we please have a show of hands of the number of people who would use LDAP as opposed to other methods to access whois data if it were available? Thanks, Alec ARIN AC Chair -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pkcs7-signature Size: 2288 bytes Desc: not available URL: From jmcburnett at msmgmt.com Thu Aug 21 15:24:55 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Thu, 21 Aug 2003 15:24:55 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks Message-ID: <9BF6F06C4BC90746ADD6806746492A3348FD@msmmail01.msmgmt.com> All, Let me add some comments here: QUOTE: Use IP space from one of their upstreams on both connections. This can lead to load balancing issues, and also makes the end-user more dependent on the ISP who assigned the space. The ISP's business problems, for instance could force downtime and/or renumbering. END QUOTE: No offense to any ISP, but this not only happened to us, but it is STILL causing us problems. My IP block is from an ISP that has poor enforcement of their AUP, and as such I got lumped into it. They would not SWIP my block, (QUOTE: " that is something we cannot do") and would not reverse DNS while I was bringing up my DNS servers. When another ISP issued an ALL MAIL from X SPACE will be blocked, we got hurt badly. I hate to see the /22 in this, as I am multi-homed and I don't foresee the ability to use it in a year. But I understand the routing table issue. The one item I do not see mentioned is Cost. At one point there was discussion about a reduced price to end-users, that were not reselling/leasing etc the space. What is the status of this? Thanks, Jim ->-----Original Message----- ->From: Forrest [mailto:forrest at almighty.c64.org] ->Sent: Thursday, August 21, 2003 2:25 PM ->To: ppml at arin.net ->Subject: RE: [ppml] Policy Proposal 2002-3: Micro-Assignments for ->Multihomed Networks -> -> -> ->Here's the link to the proposal currently on the ARIN website. -> ->http://www.arin.net/policy/2002_3.html -> ->Personally I'm a little disappointed that the proposal is ->only to reduce ->the minimum to /22, though I suppose with all the opposition ->against doing ->anything at all it was probably done to find a middle ground. -> ->My feelings on this personally are that since the current ->minimum that ->"the internet" accepts is /24, the micro-assignment policy ->really should ->be reduced to /24, especially since LACNIC and APNIC both have ->micro-allocation policies that have /24 as a minimum. -> ->Forrest -> -> -> -> ->On Thu, 21 Aug 2003, McBurnett, Jim wrote: -> ->> ->> Forrest, ->> According to one of the ARIN staff members I spoke to ->> said this was still in the works.. But I have not seen ->> the wording change.. ->> Thanks, ->> Jim ->> ->> Richard? Einar? ->> ->> ->> -> ->> -> ->> ->Hi everyone, I was just curious if this proposal is any ->> ->closer to being ->> ->approved? I've noticed that the wording has been changed to ->> ->reduce the ->> ->minimum block size to /22 instead of /24. I haven't seen any ->> ->discussion ->> ->on this for awhile. ->> -> ->> ->Forrest ->> -> ->> -> ->> -> ->-- ->Visit my Commodore 64 Website ->http://almighty.c64.org/ -> -> From ahp at hilander.com Thu Aug 21 15:34:08 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Thu, 21 Aug 2003 13:34:08 -0600 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks In-Reply-To: <9BF6F06C4BC90746ADD6806746492A3348FD@msmmail01.msmgmt.com> References: <9BF6F06C4BC90746ADD6806746492A3348FD@msmmail01.msmgmt.com> Message-ID: <2147483647.1061472848@[192.168.1.101]> --On Thursday, August 21, 2003 3:24 PM -0400 "McBurnett, Jim" wrote: > > The one item I do not see mentioned is Cost. > At one point there was discussion about a reduced price to end-users, > that were not reselling/leasing etc the space. What is the status of > this? Cost generally is not addressed by the public policy process because it is a matter for the ARIN membership to consider, not the public policy community as a whole. Alec -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pkcs7-signature Size: 2288 bytes Desc: not available URL: From ron at aol.net Thu Aug 21 15:47:11 2003 From: ron at aol.net (Ron da Silva) Date: Thu, 21 Aug 2003 15:47:11 -0400 Subject: [ppml] public addresses for private networks In-Reply-To: References: <3F3AEB7C.9070802@quadrix.com> Message-ID: <20030821194711.GK9769@aol.net> On Fri, Aug 15, 2003 at 01:14:08PM -0400, Lee Howard wrote: > You make a good point that I have also encountered. . . . > > Let's say I set up an internet to interconnect all of the baked-goods > industry. Some of those Hostess stores may also have Internet > connections. If one router at a bakery has a connection to the > Baked Goods Network and a connection to the Internet, the addresses > between BGN and the Internet must not conflict. > > We can't use RFC1918 space, because there are millions of bakeries > on the BGN and we've used up all of that space. Or because Hostess > and Little Debbie both refused to renumber from their space, so we've > already NATed them (I find this justification debatable). > > One proposal I've seen at the IETF is: > http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-03.txt > This suggests an additional network reservation of a /8 for numbering > private provider networks. The idea as I understand it is for each > organization to use RFC1918 space internally, but the interconnections > would be numbered from this new space. > > I am agnostic on this draft, I merely point out its existence. A double NAT between the RFC1918 domains? -ron From ahp at hilander.com Thu Aug 21 16:58:46 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Thu, 21 Aug 2003 14:58:46 -0600 Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Directory (fwd) Message-ID: <2147483647.1061477926@[192.168.1.101]> An embedded message was scrubbed... From: hardie at qualcomm.com Subject: Re: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Directory Date: Thu, 21 Aug 2003 13:54:21 -0700 Size: 3442 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pkcs7-signature Size: 2288 bytes Desc: not available URL: From ahp at hilander.com Thu Aug 21 17:03:32 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Thu, 21 Aug 2003 15:03:32 -0600 Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Directory (fwd) In-Reply-To: <2147483647.1061477926@[192.168.1.101]> References: <2147483647.1061477926@[192.168.1.101]> Message-ID: <2147483647.1061478211@[192.168.1.101]> I should have pointed out that this is a message Ted Hardie sent to me and asked that I forward to ppml on his behalf. Alec --On Thursday, August 21, 2003 2:58 PM -0600 "Alec H. Peterson" wrote: > Alec, > There is a good bit of work going on in the IETF related to > a replacement protocol for administrative directory services. CRISP, > as the working group is known, is currently in the process of selecting > between two candidate protocols, IRIS and FIRS. One of the lessons > learned by the group so far is that the phrase "using the LDAP protocol" > is near worthless for describing what must actually happen to publish > whois-like data. FIRS is based on LDAP, but it has required 7 fairly > long documents so far to begin the process of demonstrating how > a service based on LDAP can work in this environment. This is > not simple stuff, and a realistic question to the membership would > have to take into account more than what access protocol is used. > The key question, indeed, may be whether you expect that off-the-shelf > LDAP clients will be able to access the service. CRISP no longer > expects this. I also encourage your membership to read: > draft-newton-ldap-whois-03 for a description of the effort to put domain > name administrative data into a "stock" LDAP directory. > I do not believe I currently have the right to send mail to ppml from > this account, but you are welcome to forward this message there if you > feel it would be valuable. Note, however, that I am speaking as an > individual, not as CRISP chair. > regards, > Ted Hardie > > At 1:24 PM -0600 08/21/2003, Alec H. Peterson wrote: >> --On Thursday, August 21, 2003 11:37 AM -0400 Member Services >> wrote: >> >>> >>> 7. ARIN will publish the whois directory in three forms using the whois >>> protocol on port 43, bulk copies available by FTP and using the LDAP >>> protocol. >> >> Could we please have a show of hands of the number of people who >> would use LDAP as opposed to other methods to access whois data if >> it were available? >> >> Thanks, >> >> Alec >> ARIN AC Chair >> >> >> Content-Type: application/pkcs7-signature >> >> Attachment converted: Macintosh HD:Untitled 95 (????/----) (000914AA) > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pkcs7-signature Size: 2288 bytes Desc: not available URL: From forrest at almighty.c64.org Thu Aug 21 17:05:59 2003 From: forrest at almighty.c64.org (Forrest) Date: Thu, 21 Aug 2003 16:05:59 -0500 (CDT) Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks In-Reply-To: <9BF6F06C4BC90746ADD6806746492A3348FD@msmmail01.msmgmt.com> Message-ID: I understand the routing table issue as well, unfortunately I've yet to see any data that would indicate that a micro-allocation policy would cause the routing table to greatly increase in size. If routing table size was such an issue, why aren't more organizations filtering based on the minimum allocation size right now? There are tons of organizations right now polluting the global routing tables by announcing their large aggregate and announcing every /24 within. A micro-allocation policy could actually cause an overall decrease in # of routes by enabling people to filter more efficiently. If there was a specific /8 set aside that the micro-allocations come from, you could filter out all the garbage more specific /24's from the other space without disrupting anyone's ability to multihome. I welcome any comments, and if I'm completely wrong here please correct me. Forrest On Thu, 21 Aug 2003, McBurnett, Jim wrote: > All, > Let me add some comments here: > QUOTE: > Use IP space from one of their upstreams on both connections. > This can lead to load balancing issues, and also makes the > end-user more dependent on the ISP who assigned the space. > The ISP's business problems, for instance could force > downtime and/or renumbering. > END QUOTE: > > No offense to any ISP, but this not only happened to us, but it > is STILL causing us problems. > > My IP block is from an ISP that has poor enforcement of their > AUP, and as such I got lumped into it. They would not SWIP my > block, (QUOTE: " that is something we cannot do") and would not > reverse DNS while I was bringing up my DNS servers. > > When another ISP issued an ALL MAIL from X SPACE will be blocked, > we got hurt badly. > > I hate to see the /22 in this, as I am multi-homed and I don't foresee > the ability to use it in a year. But I understand the routing table issue. > > The one item I do not see mentioned is Cost. > At one point there was discussion about a reduced price to end-users, that were > not reselling/leasing etc the space. What is the status of this? > > Thanks, > Jim > From jsw at five-elements.com Thu Aug 21 17:44:47 2003 From: jsw at five-elements.com (Jeff S Wheeler) Date: 21 Aug 2003 17:44:47 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks Message-ID: <1061502286.24987.333.camel@intrepid.jsw.louisville.ky.us> On Thu, 2003-08-21 at 15:24, McBurnett, Jim wrote: > I hate to see the /22 in this, as I am multi-homed and I don't foresee > the ability to use it in a year. But I understand the routing table issue. I'm sure small, multi-homed shops that need provider independent space will simply inflate their utilization figures to demonstrate need of a /22, perhaps wasting a little address space in the process. I can live with that as /24 assignments are an overwhelmingly large portion of the routing table today, and a few slightly larger blocks will probably cut into the growth of /24s a bit. The key thing to understand here is, when you create limitations like this, ISPs will fudge their numbers to meet the arbitrary minimum network sizes so they can get the type of assignment they need. How many organizations have /20s today that could do with a /22? These largely arbitrary limits, while well-intentioned, only make the ARIN difficult to work with. -- Jeff S Wheeler OT: I wish the mailing list would set Reply-To: ppml at arin.net From einarb at arin.net Thu Aug 21 18:06:25 2003 From: einarb at arin.net (Einar Bohlin) Date: Thu, 21 Aug 2003 18:06:25 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks In-Reply-To: <9BF6F06C4BC90746ADD6806746492A332AEE27@msmmail01.msmgmt.com> Message-ID: <000001c36830$76d2ef00$3d8888c0@arin.net> Hi Jim, The authors modified the text of the proposal and that text was posted on PPML in March to encourage discussion. The proposal is slated to be presented in Chicago at the Public Policy Meeting, October 22-23. Regards, Einar Bohlin - Policy Analyst, ARIN einarb at arin.net 703 227-9867 > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of > McBurnett, Jim > Sent: Thursday, August 21, 2003 2:19 PM > To: Forrest; ppml at arin.net > Subject: RE: [ppml] Policy Proposal 2002-3: Micro-Assignments for > Multihomed Networks > > > Forrest, > According to one of the ARIN staff members I spoke to > said this was still in the works.. But I have not seen > the wording change.. > Thanks, > Jim > > Richard? Einar? > > > -> > -> > ->Hi everyone, I was just curious if this proposal is any > ->closer to being > ->approved? I've noticed that the wording has been changed to > ->reduce the > ->minimum block size to /22 instead of /24. I haven't seen any > ->discussion > ->on this for awhile. > -> > ->Forrest > -> > -> From william at elan.net Thu Aug 21 15:38:11 2003 From: william at elan.net (william at elan.net) Date: Thu, 21 Aug 2003 12:38:11 -0700 (PDT) Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks In-Reply-To: <2147483647.1061472848@[192.168.1.101]> Message-ID: > --On Thursday, August 21, 2003 3:24 PM -0400 "McBurnett, Jim" > wrote: > > > > > The one item I do not see mentioned is Cost. > > At one point there was discussion about a reduced price to end-users, > > that were not reselling/leasing etc the space. What is the status of > > this? > > Cost generally is not addressed by the public policy process because it is > a matter for the ARIN membership to consider, not the public policy > community as a whole. I think we had discussion about this last year and it was agreed that while proposal can not specifically mention any particular cost, it can in fact say that cost is to be lower for micro-assignments according to its size. (i.e. you can make general direction for cost changes in proposals but not particular numbers) And since we're on the subject of micro-assignments (again!), I'd like to know current situation too and if AC will be supporting any kind of micro-assignment proposal. As I already mentioned last meeting, in my opinion 2002-3 will work just fine, with exception that its a little too open to abuse (but that can be dealt with separatly and having minimum /22 generally it will not be as easy). The 2002-3 proposal in general was also approved by greater majority of those who were interested in this subject last year so I think its clear indication that it should go forward. However AC said something about bring in their own proposal instead to reduce minimum assignment for multi-homed organizations to /21 from /20 (while still leaving /21 as requirement, i.e. the only difference is that instead of getting /20 same companies that qualify even now would get /21). I've privately said to some members of AC that this is not what people who want micro-assignments would like and that at the very least requirements should be /23 with assignment of /22 and that I think separate micro- assignment policy is better then just changing IPv4 multi-homed policy (see http://www.arin.net/policy/ipv4.html#multihomed). So I would like to know if there is any work being done by AC on itself regarding micro-assignents or changing multi-homed policy or if next meeting we can expect 2002-3 proposal to be discussed in full instead. -- William Leibzon Elan Networks william at elan.net From william at elan.net Thu Aug 21 16:03:00 2003 From: william at elan.net (william at elan.net) Date: Thu, 21 Aug 2003 13:03:00 -0700 (PDT) Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks In-Reply-To: <1061502286.24987.333.camel@intrepid.jsw.louisville.ky.us> Message-ID: On 21 Aug 2003, Jeff S Wheeler wrote: > > On Thu, 2003-08-21 at 15:24, McBurnett, Jim wrote: > > I hate to see the /22 in this, as I am multi-homed and I don't foresee > > the ability to use it in a year. But I understand the routing table issue. > > I'm sure small, multi-homed shops that need provider independent space > will simply inflate their utilization figures to demonstrate need of a > /22, perhaps wasting a little address space in the process. I can live > with that as /24 assignments are an overwhelmingly large portion of the > routing table today, and a few slightly larger blocks will probably cut > into the growth of /24s a bit. This "honesty" coming from the person responsible for taking somebody elses ip block (hijacking four old micro-assignments in fact) is very interesting... (for reference, see http://www.completewhois.com/hijacked/gang_ings.htm). Obviously you have no problem lying to ARIN either about ownership of ip block or in the future about size of ip block you may need. Unfortunetly policies created by ARIN are all designed based that people using them would be fairly honest (and if this is a problem - we can work on it). > The key thing to understand here is, when you create limitations like > this, ISPs will fudge their numbers to meet the arbitrary minimum > network sizes so they can get the type of assignment they need. How many > organizations have /20s today that could do with a /22? Hopefully, not as many as you Jeff Wheeler thinks (do not ever assume everyone else operates the same way you are). I can tell that all companies I've dealt with that have /20s all had enough use of those ip blocks and have not exadurated numbers when getting them. > These largely arbitrary limits, while well-intentioned, only make the > ARIN difficult to work with. ARIN is already very difficult to work with (and this is topic for completely different discussion), the current proposal for 2002-3 will not change difficulty in working with ARIN. If anything on that issue I support ARIN being difficult and doing hard checking about micro-assignment requests. -- William Leibzon Elan Networks william at elan.net From jsw at five-elements.com Thu Aug 21 19:36:25 2003 From: jsw at five-elements.com (Jeff S Wheeler) Date: 21 Aug 2003 19:36:25 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks In-Reply-To: References: Message-ID: <1061508985.24987.344.camel@intrepid.jsw.louisville.ky.us> On Thu, 2003-08-21 at 16:03, william at elan.net wrote: > This "honesty" coming from the person responsible for taking somebody elses > ip block (hijacking four old micro-assignments in fact) is very interesting... The majority of your "hijackers" do so not because they are unwilling to be accountable for the activities conducted on their networks (or they would steal ASNs and domain names as well); nor because they aren't able to pay the ARIN fees associated with legitimately obtaining addresses. They do so because the ARIN's allocation policies prevent their small networks from getting provider-independent space. I can assure you that if the ARIN more easily made PI space available to BGP-speaking organizations, your "hijacking" problem would be limited only to those who announce and withdraw different address blocks for brief timeframes to conduct their business -- and these groups do so on unfiltered BGP sessions working with transit providers who don't have the infrastructure to watch out for themselves and their customers. The ARIN cannot control that, but it can improve the process for obtaining legitimate, accountable address space. You of all people, "William", should realize that my unique perspective is valuable to the PPML readership and to the policy-making process. -- Jeff S Wheeler From william at elan.net Thu Aug 21 18:55:56 2003 From: william at elan.net (william at elan.net) Date: Thu, 21 Aug 2003 15:55:56 -0700 (PDT) Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks In-Reply-To: <1061508985.24987.344.camel@intrepid.jsw.louisville.ky.us> Message-ID: On 21 Aug 2003, Jeff S Wheeler wrote: > On Thu, 2003-08-21 at 16:03, william at elan.net wrote: > > This "honesty" coming from the person responsible for taking somebody elses > > ip block (hijacking four old micro-assignments in fact) is very interesting... > The majority of your "hijackers" do so not because they are unwilling to > be accountable for the activities conducted on their networks (or they > would steal ASNs and domain names as well); nor because they aren't able > to pay the ARIN fees associated with legitimately obtaining addresses. > They do so because the ARIN's allocation policies prevent their small > networks from getting provider-independent space. I disagree. If you notice at the list at http://www.completewhois.com/hijacked/ of the ips hijacked in ARIN geographical area, the majority are legacy /16 ip blocks. Its not likely somebody would hijack /16 if they only needed portable /24. And since I've been doing investigations based on abuse complaints, I can tell that there is a pattern for some to hijack one ip block, use it until it is blackholed and then hijack another one as well as pattern of certain individuals and groups of setting up different new companies for purposes of hiding their activities. There are, of course, those that hijacked ip blocks just go get portable space and where there is no pattern of abuse, but even there (like 3sheep group) they don't seem to stop at just one or two /24s and if their activites are not noticed, they continue to do it and go for more larger ip blocks (and I've checked usage on those ip blocks, its usually minimum a lot less then typical isp with /24 assigned from upstream). > I can assure you that if the ARIN more easily made PI space available to > BGP-speaking organizations, your "hijacking" problem would be limited While problem with hijacking of ip blocks may decrease a little with availability of PI space in ARIN region, I do not believe this decrease would be that significant. And we do have an example with another RIR - as you know APNIC policies are such that its pretty easy to get portable ip block from them, nevertheless there is a signifacant number of small portable ip blocks that have been hijacked from APNIC space. Just like with ARIN majority of these are legacy ip block assignments (made directly AUNIC at that time). > only to those who announce and withdraw different address blocks for > brief timeframes to conduct their business -- and these groups do so on > unfiltered BGP sessions working with transit providers who don't have > the infrastructure to watch out for themselves and their customers. The above problem is indeed something that needs to be seriously looked at. At this time there is no numbers available to indicate how bad this problem is, but we do need to get some statistics, find which ISPs luck proper policies of accepting bgp feeds from their customers, find which ip blocks are being used this way, etc. This is in fact on my agenda in the future, but first I'll be working on working specific bogons list, so from myself examination of short term bgp-only ip hijacking will not happen until next year, but if I do find enough interesting data there, then I might do presentation on in on one of next nanogs (but this would be at least year from now). > The ARIN cannot control that, but it can improve the process for > obtaining legitimate, accountable address space. >From the ARIN side, the best way to deal with above problem would be to work futher on security related to BGP, such as sponsoring more work on BBN's S-BGP proposal > You of all people, "William", should realize that my unique perspective > is valuable to the PPML readership and to the policy-making process. To Jeff Wheeler: I appreciate your honesty in regards to why you have done this and have no problem with you continuing to express your opinion on ppml and work within ARIN structures to get their policies changed and then afterwards you can properly apply for portable ip block if you have enough justification for it. And If you notice and have read ppml, you'd know that for several years I've been one of the biggest proponents of portable allocations directly by ARIN on this list and have brought this topic up many times. I'll continue to advocate futher on it until there is enough change at ARIN to provide valuable services not focused on larger ISPs but on smaller companies as well. -- William Leibzon Elan Networks william at elan.net From billd at cait.wustl.edu Fri Aug 22 09:56:48 2003 From: billd at cait.wustl.edu (Bill Darte) Date: Fri, 22 Aug 2003 08:56:48 -0500 Subject: [ppml] Current Info - Policy Proposal 2002-3: Micro-Assignments for Mult ihomed Networks Message-ID: <7D6FB5D2AE48D84983C354E50E83C2560363CF@kronos.cait.wustl.edu> Hello All, The following verbiage and procedure discussion is in play within the ARIN AC. Please review and make comments as you see fit. This proposal (or something following from it) will be presented for discussion at the Chicago Public Policy Meeting. ******************************* If an end-user is not multi-homed, the minimum justified block of IP address space assigned by ARIN is a /20. If assignments smaller than /20 are needed, end-users should contact their upstream provider. If an end-user is multi-homed, and has an ARIN assigned ASN, the minimum justified block of IP address space assigned by ARIN is a /22. Such assignment will be made from a reserve block for this purpose. If multi-homed assignments smaller than a /22 are needed, end users should contact their upstream provider. ****************************** It has further been argued that should this policy (or something following from it) be endorsed at the meeting, then an assessment of the impact of this policy's implementation by # of requests and route table impact for 2 consecutive 6 mos. periods. If the impact is not believed to be problematic, then a proposal should be made to lower the minimum to /23 with the same assessment. Given no problems for /23 then a proposal for /24 as a minimum would be made. Also, an assessment of the number of allocations that are still multihomed after 12 months should be made to determine whether there is any change in status of these end nets. Bill Darte ARIN Advisory Council From eric at atlantech.net Fri Aug 22 10:54:52 2003 From: eric at atlantech.net (Eric Van Tol) Date: Fri, 22 Aug 2003 10:54:52 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihomed Networks Message-ID: <4CBD2D346320D541AB8BF4C0140EF7CD40D89D@staq7.hq.atlantech.net> With this reasoning, I suppose it would be okay to go out and steal cars because some people find it too difficult to purchase a car on their own, or lack the finances to purchase one. Interesting "unique perspective" you have...I doubt that ARIN really wants to (or cares to) make the process easier so that illegitimate "businesses" won't cause problems for everyone else. -eric -----Original Message----- From: Jeff S Wheeler [mailto:jsw at five-elements.com] Sent: Thursday, August 21, 2003 7:36 PM To: ppml at arin.net Subject: RE: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihomed Networks On Thu, 2003-08-21 at 16:03, william at elan.net wrote: > This "honesty" coming from the person responsible for taking somebody elses > ip block (hijacking four old micro-assignments in fact) is very interesting... The majority of your "hijackers" do so not because they are unwilling to be accountable for the activities conducted on their networks (or they would steal ASNs and domain names as well); nor because they aren't able to pay the ARIN fees associated with legitimately obtaining addresses. They do so because the ARIN's allocation policies prevent their small networks from getting provider-independent space. I can assure you that if the ARIN more easily made PI space available to BGP-speaking organizations, your "hijacking" problem would be limited only to those who announce and withdraw different address blocks for brief timeframes to conduct their business -- and these groups do so on unfiltered BGP sessions working with transit providers who don't have the infrastructure to watch out for themselves and their customers. The ARIN cannot control that, but it can improve the process for obtaining legitimate, accountable address space. You of all people, "William", should realize that my unique perspective is valuable to the PPML readership and to the policy-making process. -- Jeff S Wheeler From bicknell at ufp.org Fri Aug 22 11:31:36 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 22 Aug 2003 11:31:36 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihomed Networks In-Reply-To: <4CBD2D346320D541AB8BF4C0140EF7CD40D89D@staq7.hq.atlantech.net> References: <4CBD2D346320D541AB8BF4C0140EF7CD40D89D@staq7.hq.atlantech.net> Message-ID: <20030822153136.GA34331@ussenterprise.ufp.org> In a message written on Fri, Aug 22, 2003 at 10:54:52AM -0400, Eric Van Tol wrote: > With this reasoning, I suppose it would be okay to go out and steal cars > because some people find it too difficult to purchase a car on their > own, or lack the finances to purchase one. While I don't want to defend his reasoning, an interesting new problem has occured. Many ISP's, including my employer have recently had customers who found ARIN's processes so "difficult" that they "bought" an IP address range on EBay (or other locations). These were in fact stolen. Sadly, these customers had no idea IP's couldn't be bought or sold, or that they were being sold stolen goods. So, to extend your analogy, while it's not ok to steal cars, if car manufactures drove up the cost of cars and / or parts, or otherwise made them difficult to come by it would cause more people to steal cars and try and sell them as legitimate used autos. I do think that legitimate (but clueless) business people are being driven away from ARIN to "chop shops" to get IP's is a problem that needs to be addressed. There are several prongs to that attack though: * Enforcement, get the people who are stealing address space in the first place. * Education, make it clear to non-techies what they need to do to get address space. This is going to be an uphill battle. * Smaller allocations. ARIN needs to allocate down to /24's to end users. Business people are tried of their provider going Chapter 7 and being forced to renumber. I know some places that had to renumber 3-4 times in a single year, at great expense, because their providers had their own problems. Many can't justify a /19, but are quite happy to buy one because it's far cheaper than renumbering. * Streamlined processes. A business, getting their first /24 from arin should be able to get it all from a web site. Fill out a form, enter a credit card for the payment, and boom in e-mail you get a /24. Make them send in tons of paperwork, drag it out for weeks, give them a process with uncertian deadlines and they will turn to the theif on e-bay who promises them IP's as soon as they get paid. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From ahp at hilander.com Fri Aug 22 11:58:33 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Fri, 22 Aug 2003 09:58:33 -0600 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihomed Networks In-Reply-To: <20030822153136.GA34331@ussenterprise.ufp.org> References: <4CBD2D346320D541AB8BF4C0140EF7CD40D89D@staq7.hq.atlantech.net> <20030822153136.GA34331@ussenterprise.ufp.org> Message-ID: <2147483647.1061546313@[192.168.1.101]> Leo, We have gone over these exact issues many times. The fact remains that ARIN serves diverse constituencies. I encourage you to read Bill Darte's recent post, I think it strikes a very reasonable compromise, by proposing to immediately lower the minimum allocation to a /22, with a timetable for further reductions in the minimum allocation size based on the change in routing table growth. We have been working on some sort of a minimum allocation change for years now, it would be great if we could actually move forward with a compromise, instead of both sides of the discussion acting with an all or nothing attitude. Alec Chair, ARIN AC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pkcs7-signature Size: 2288 bytes Desc: not available URL: From jsw at five-elements.com Fri Aug 22 12:04:22 2003 From: jsw at five-elements.com (Jeff S Wheeler) Date: 22 Aug 2003 12:04:22 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihomed Networks In-Reply-To: <4CBD2D346320D541AB8BF4C0140EF7CD40D89D@staq7.hq.atlantech.net> References: <4CBD2D346320D541AB8BF4C0140EF7CD40D89D@staq7.hq.atlantech.net> Message-ID: <1061568262.835.425.camel@intrepid.jsw.louisville.ky.us> On Fri, 2003-08-22 at 10:54, Eric Van Tol wrote: > With this reasoning, I suppose it would be okay to go out and steal cars > because some people find it too difficult to purchase a car on their > own, or lack the finances to purchase one. Unfortunately in this case, a majority of the people using "hijacked" IP address space are doing so because they are too small to legitimately obtain assignments from the ARIN. Using your analogy, it is impossible for many people to buy cars. Those people need one to get to work. Oh, and don't forget to mention, there are thousands upon thousands of abandoned cars, which no one will miss, and which are are in fine working order, on the side of the road. The only thing wrong with them is that they aren't registered to you (yet). I think you fail to understand that a large majority of the "hijackers" William has identified have not done so because they want to avoid being accountable. Those who want to avoid accountability are abusing the BGP system, advertising and withdrawing routes periodically without any ARIN (or other registry) being involved at all. True, William has discovered some groups who churn through blocks, and that is deplorable, however a change in assignment policy is certainly not going to prevent that. What you CAN do is remove the need for folks to "hijack" space, use out-of-region registrars, and so on. I have gone to a great deal of trouble to explain the motivation of "hijackers", and given my easily implementable suggestion on how to eliminate that problem: make the ARIN easier to work with. Reduce minimum allocation sizes such that any small organization which needs PI space, can get PI space. I think most people would agree that the IPv4 space would not be exhausted by letting BGP-speakers with ARIN ASNs get /24 (or larger) CIDR assignments. As those organizations grow I think it is reasonable to issue them a second similar assignment of whatever size they can justify, and presumably if the need a third they can renumber from one or simply apply for a /20, etc. This implementation would not substantially increase route table growth (since these small orgs are announcing Provider Assigned space today), and defines a clear path for the small orgs to grow into the more familar ARIN PI assignment policy. -- Jeff S Wheeler From forrest at almighty.c64.org Fri Aug 22 12:08:51 2003 From: forrest at almighty.c64.org (Forrest) Date: Fri, 22 Aug 2003 11:08:51 -0500 (CDT) Subject: [ppml] Current Info - Policy Proposal 2002-3: Micro-Assignments for Mult ihomed Networks In-Reply-To: <7D6FB5D2AE48D84983C354E50E83C2560363CF@kronos.cait.wustl.edu> Message-ID: I think this is a very reasonable proposal, especially if the wording is added that would potentially reduce the minimum allocation in the future. The biggest argument against a micro-allocation policy I've heard is that it would greatly expand the routing table, even though there has been no data showing that to be the case. I think lowering the minimum allocation in steps would eliminate most of those fears and I would definitely like to see the minimum eventually lowered to /24. Forrest On Fri, 22 Aug 2003, Bill Darte wrote: > Hello All, > > The following verbiage and procedure discussion is in play within the ARIN > AC. Please review and make comments as you see fit. > This proposal (or something following from it) will be presented for > discussion at the Chicago Public Policy Meeting. > > ******************************* > If an end-user is not multi-homed, the minimum justified block of IP > address space assigned by ARIN is a /20. If assignments smaller than /20 > are needed, end-users should contact their upstream provider. > > If an end-user is multi-homed, and has an ARIN assigned ASN, > the minimum justified block of IP address space assigned by ARIN is a /22. > Such > assignment will be made from a reserve block for this purpose. If > multi-homed > assignments smaller than a /22 are needed, end users should contact their > upstream provider. > > ****************************** > > It has further been argued that should this policy (or something following > from it) > be endorsed at the meeting, then an assessment of the impact of this > policy's > implementation by # of requests and route table impact for 2 consecutive 6 > mos. periods. If the impact is not believed to be problematic, then a > proposal should be made to lower the minimum to /23 with the same > assessment. > Given no problems for /23 then a proposal for /24 as a minimum would be > made. > > Also, an assessment of the number of allocations > that are still multihomed after 12 months should be made > to determine whether there is any change in status of these end nets. > > Bill Darte > ARIN Advisory Council > From marla_azinger at eli.net Fri Aug 22 12:25:11 2003 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 22 Aug 2003 09:25:11 -0700 Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory Message-ID: <5BD887EB4A582A439038636F7A93A5A701E5A131@wava00s2kexch01.eli.czn.com> Ok...so I dont get accused of not commenting until I get to the mic at the conference....here are my concerns.... I'm not sure what to think about this one yet. 1. Can someone verify if this is or is not supposed to be a seperate list from all the SWIP Records in the WHOIS database? 2. In the end...does this policy mean that if I want the End Users and ISP's that I Re-assign and RE-allocate to will not have their abuse, technical and whatever else contact info visibile unless I take extra steps to ensure "I want them visible"? If this does mean I have to take extra steps....I give up...because as a person that sends these in daily....I'm already jumping through to many hoops. 3. When you mention validating the POC info every three months....is this to be done with just Direct Allocation from ARIN? Or do you really mean the whole WHOIS database? If its the whole database...and its done in the same manner it was done this last year by ARIN....where you have to update records that are really already updated.............Every 3 months is excessive and I dont see this being easily supported. Marla Azinger IP Analyst for: Electric Lightwave Frontier Communications Citizens -----Original Message----- From: Mury [mailto:mury at goldengate.net] Sent: Thursday, August 21, 2003 12:20 PM To: Member Services Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Directory Sounds good to me with two exceptions. Under #5 I think testing every 3 months is a little overboard. Maybe once a year is more reasonable. Under #3 and #4 I don't understand the 'guarantee' word and concept. Perhaps the word guarantee should be replaced with something more appropriate. What exactly happens to the resource holder if they don't keep the info up to date? They merely get their contact info removed from the directory? I know the argument over policy enforcement has been thrown around with little resolution, but I think there either needs to be a consequence with real teeth or nothing at all. For example, add language that forces the removal of the resources from the entity not providing current contact info, or just write the policy to say the resource holder shall provide contact info... remove the guarantee language and remove #6. My two cents. Mury On Thu, 21 Aug 2003, Member Services wrote: > ARIN welcomes feedback and discussion about the following policy > proposal in the weeks leading to the ARIN Public Policy Meeting > in Chicago, Illinois, scheduled for October 22-23, 2003. All feedback > received on the mailing list about this policy proposal will be > included in the discussions that will take place at the upcoming > Public Policy Meeting. > > This policy proposal discussion will take place on the ARIN Public > Policy Mailing List (ppml at arin.net). Subscription information is > available at http://www.arin.net/mailing_lists/index.html > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal regarding purpose and scope of whois directory. > > 1. ARIN shall maintain and publish a directory of contact information for > the purposes of facilitating the operation of internconnected IP networks. > > 2. This directory will contain contact information for all organizations > and individuals within the ARIN region who have received IP allocations or > AS numbers directly from ARIN or its predecessors. > > 3. Organizations and individuals must guarantee to ARIN that contact > addresses published in the whois directory will reach a person who is > ready, willing and able to communicate regarding network operations and > interconnect issues and who is able to act on that communication. > > 4. Any other organizations may elect to be listed in the whois directory > as long as they make the guarantee detailed in item 3. > > 5. All contacts listed in the whois directory will be contacted every 3 > months to verify that the contact addresses are still valid. > > 6. Any invalid contact information will be removed from the directory > within 60 days of the first attempted contact from item 5. > > 7. ARIN will publish the whois directory in three forms using the whois > protocol on port 43, bulk copies available by FTP and using the LDAP > protocol. > > Why do this? > > Well, first of all I think that ARIN needs to have a clear policy > statement of why we are collecting and publishing this directory. > > After that, items 2, 3 and 4 specify what information goes into the > directory. Specifically, it excludes all organizations and individuals who > have not received resources directly from ARIN unless they ask to be > included. It also forces organizations to make a commitment to make sure > that the contact information provides access to people who can do > something about interconnect issues (peering), denial of service technical > issues, abuse, etc. As currently, these addresses could be role accounts, > P.O. boxes, voicemail numbers etc. > > Then items 5 and 6 specify that the data will be tested regularly and > cleared out if it is stale. I think this is enough detail for the policy > level to deal with. Most of the existing data will disappear after the 1st > test period because people will either not respond or will not agree to > the commitments in item 3. I don't intend for the entire database to be > tested on the same day. I would hope that operationally this would be > spread out over the 3 month period. > > And in 7, I am specifying that ARIN add an LDAP server to publish this > directory because I feel that we should provide a real choice to people > who need to access this directory. I suggest that a good way to start is > to set up OpenLDAP and use the FIRS work done in the IETF's CRISP working > group and then see how this all works out in practice. I believe that in > the long run we will need to add back some kind of status information > about the large number of address assignments that will no longer show up > in whois and LDAP is ideally suited to doing this without a lot of > anguish. > > In general, I see no reason why this could not be implemented by January > 2004. I wouldn't expect 100% of the existing contacts to be tested by that > time, but I would expect the testing to be well under way. Because the > first round involves clearing out a much larger number of records, it > could very well take until the middle of 2004 to have fully dealt with > every one. A lot of this work could be alleviated if ISPs would provide > lists of assignments for which they will take responsibility so that ARIN > can remove those SWIP records wholesale without testing. > > ------------------------------------------------------- > Michael Dillon > Capacity Planning, Prescot St., London, UK > Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com > Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 > From william at elan.net Fri Aug 22 09:41:16 2003 From: william at elan.net (william at elan.net) Date: Fri, 22 Aug 2003 06:41:16 -0700 (PDT) Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihomed Networks In-Reply-To: <20030822153136.GA34331@ussenterprise.ufp.org> Message-ID: > In a message written on Fri, Aug 22, 2003 at 10:54:52AM -0400, Eric Van Tol wrote: > > With this reasoning, I suppose it would be okay to go out and steal cars > > because some people find it too difficult to purchase a car on their > > own, or lack the finances to purchase one. > > While I don't want to defend his reasoning, an interesting new > problem has occured. > > Many ISP's, including my employer have recently had customers who > found ARIN's processes so "difficult" that they "bought" an IP > address range on EBay (or other locations). These were in fact > stolen. Sadly, these customers had no idea IP's couldn't be bought > or sold, or that they were being sold stolen goods. While I know exact cases when ip blocks were "sold", in majority I've seen its done directly by users of these ip blocks. I'd actually be very interested in finding who is actively trying to sell ip space and where they adverise it. If you have any info, send it to me privately. > So, to extend your analogy, while it's not ok to steal cars, if car > manufactures drove up the cost of cars and / or parts, or otherwise > made them difficult to come by it would cause more people to steal > cars and try and sell them as legitimate used autos. > > I do think that legitimate (but clueless) business people are being > driven away from ARIN to "chop shops" to get IP's is a problem that > needs to be addressed. There are several prongs to that attack though: I don't think this is significant number. I've seen cases when somebody asks to buy ip block on one of may webhosting mailing lists I'm at, but this is really rare. And about these people being clueless - its more then that, of the several cases where I know somebody did in fact buy ip blocks, I'd say only one did the person buying ip block not know it was not allowed - they knew it was a shady deal and still went for it. Their business practices in other areas are also such that how they did it with ip block did not surprised me. On the other hand, lately I've heard some intersting stories about some making excuses to their upstreams when they loose ip block and saying to upstream they originally bought it and did not directly hijacked it (while I'm almost 100% certain they did) - this is basicly so that their upstreams would not turn them off or that they could find new upstreams even if company known to have used hijacked ip blocks. > * Enforcement, get the people who are stealing address space in the > first place. I'd love to see some move there. Biggest victim of ip hijacking activites is ARIN (they are being tricked and lied to and then have to conduct investigation after problems are reported; plus they loose potential income as well) but as far as I know ARIN has not done anything on legal grounds against people who stole these blocks. > * Education, make it clear to non-techies what they need to do to > get address space. This is going to be an uphill battle. Make it clear to techies as well, that its NOT OK to take unused ip block even if it seems so easy. But as far as ARIN, what would help is clear statement on ARIN website that ips can not be sold and any such transactions are illegal. > * Smaller allocations. ARIN needs to allocate down to /24's to end > users. Business people are tried of their provider going Chapter 7 > and being forced to renumber. I know some places that had to renumber > 3-4 times in a single year, at great expense, because their providers > had their own problems. Many can't justify a /19, but are quite happy > to buy one because it's far cheaper than renumbering. Microassiments are long overdue for ARIN region and everybody else is doing it, lets hope starting next year this will change. > * Streamlined processes. A business, getting their first /24 from arin > should be able to get it all from a web site. Fill out a form, enter > a credit card for the payment, and boom in e-mail you get a /24. Make > them send in tons of paperwork, drag it out for weeks, give them a > process with uncertian deadlines and they will turn to the theif on > e-bay who promises them IP's as soon as they get paid. This I can not agree with, if process is too easy, it opens this up for abuse (spammers come in buy ip block, use it and then create new name and buy another ip block). And if its so easy to get ip block with credit card transation, we'll have people using stolen credit cards. This is a big problem for dedicated server isps that make things too easy and I'v see it firsthand. I do have have an interesting way of detecting potential credit card fraud though - I have both non-secure and secure forms on the website for requesting info about services and website makes it clear you can not buy service, just do pre-authorization and still afterwards forms would need to be completed and faxed - nevertheless I still get at least one person per week going through non-secure webform and entering credit card info there - I've checked on these and not one of these was legit - all legit people at the very least went and used secure form - but almost no scammer did; and services they request are as much as $1000/mo too - so these people would have no problem scamming ARIN if it made it too easy and totally through the web. -- William Leibzon Elan Networks william at elan.net From william at elan.net Fri Aug 22 10:12:09 2003 From: william at elan.net (william at elan.net) Date: Fri, 22 Aug 2003 07:12:09 -0700 (PDT) Subject: [ppml] Current Info - Policy Proposal 2002-3: Micro-Assignments for Mult ihomed Networks In-Reply-To: <7D6FB5D2AE48D84983C354E50E83C2560363CF@kronos.cait.wustl.edu> Message-ID: This proposal is similar enough to 2002-3 and in fact this it is very encoraging considering it is coming from AC and they even put provisions for futher reductions. If we could have the exact timeframe as far as when reductions of minimum size are evaluated (i.e. as part of main code to say "the minimum assignment size will be reavaluated every year" it would be even better. On Fri, 22 Aug 2003, Bill Darte wrote: > Hello All, > > The following verbiage and procedure discussion is in play within the ARIN > AC. Please review and make comments as you see fit. > This proposal (or something following from it) will be presented for > discussion at the Chicago Public Policy Meeting. > > ******************************* > If an end-user is not multi-homed, the minimum justified block of IP > address space assigned by ARIN is a /20. If assignments smaller than /20 > are needed, end-users should contact their upstream provider. > > If an end-user is multi-homed, and has an ARIN assigned ASN, > the minimum justified block of IP address space assigned by ARIN is a /22. > Such > assignment will be made from a reserve block for this purpose. If > multi-homed > assignments smaller than a /22 are needed, end users should contact their > upstream provider. > > ****************************** > > It has further been argued that should this policy (or something following > from it) > be endorsed at the meeting, then an assessment of the impact of this > policy's > implementation by # of requests and route table impact for 2 consecutive 6 > mos. periods. If the impact is not believed to be problematic, then a > proposal should be made to lower the minimum to /23 with the same > assessment. > Given no problems for /23 then a proposal for /24 as a minimum would be > made. > > Also, an assessment of the number of allocations > that are still multihomed after 12 months should be made > to determine whether there is any change in status of these end nets. > > Bill Darte > ARIN Advisory Council From bicknell at ufp.org Fri Aug 22 13:23:37 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 22 Aug 2003 13:23:37 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihomed Networks In-Reply-To: <2147483647.1061546313@[192.168.1.101]> References: <4CBD2D346320D541AB8BF4C0140EF7CD40D89D@staq7.hq.atlantech.net> <20030822153136.GA34331@ussenterprise.ufp.org> <2147483647.1061546313@[192.168.1.101]> Message-ID: <20030822172337.GA38742@ussenterprise.ufp.org> In a message written on Fri, Aug 22, 2003 at 09:58:33AM -0600, Alec H. Peterson wrote: > The fact remains that ARIN serves diverse constituencies. I encourage you > to read Bill Darte's recent post, I think it strikes a very reasonable > compromise, by proposing to immediately lower the minimum allocation to a > /22, with a timetable for further reductions in the minimum allocation size > based on the change in routing table growth. Respectfully, the problem is that ARIN does not yet serve the constituency that needs this proposal, and those it does serve today in general have incentives to act in the opposite manor. The people who need these small blocks today can't get them from ARIN, and are not ARIN members. They don't get to vote. Insted, they get their addresses from an upstream provider that has direct incentives (from charging a fee for address allocations to wanting the customer to be in their own non-portable space to make it more painful for the customer to leave) to prevent proposals like this from succeeding. They are the ones who get to vote. It also seems to be futher hampered by the fact that only a small group of ISP's go to the meeting and raise their voice, often for better or worse making it the loudest one by default. To address the proposal itself, I'm happy to start with a /22 and move to a /24 limit as necessary. The problem is that the proposal wants to tie that to routing table growth. Since ARIN doesn't control the size of the routing table, that should be a non-starter. More to the point, it does not put any objective measure on the routing table impact -- which due to my beliefs from the previous paragraph will mean an increase by so much as 1 route will be used to argue against it in the future. There is a hidden implication the routing table size should stay the same, or decrease. That's bogus. It will clearly increase in the short term (as people renumber they will have to announce both in many cases), and it should have a long term impact to increase the routing table (as it becomes easier for people to set up their redundnat networks the way they should be set up). It also doesn't supply a measurement interval that's meaningful, during the time proposed we'll still be in the initial cut over period, with the double announcements and the like. That's not a good time to judge success or failure. It is up to ARIN to give ISP's and large end users the IP space they need. Period. The measure of success is that the people who need IP's can get them with a reasonable amount of effort, in a reasonable amount of time. The issue of routing table size should not be in any of ARIN's proposals, just like issues of which ISP's filter which routes should not be in them either. The routing table size question is great in some other forms, and answers to it may influence how ARIN's members vote on some proposals, but it has no business being in a proposal. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From billd at cait.wustl.edu Fri Aug 22 13:47:23 2003 From: billd at cait.wustl.edu (Bill Darte) Date: Fri, 22 Aug 2003 12:47:23 -0500 Subject: [ppml] Current Info - Policy Proposal 2002-3: Micro-Assignmen ts for Mult ihomed Networks Message-ID: <7D6FB5D2AE48D84983C354E50E83C2560363D8@kronos.cait.wustl.edu> The presentation of the policy would be accompanied by the promise to re-evaluate after 6 and then 12 mos. as it says in my original post. Given that this change is not accompanied by significant negative impacts, then a proposal to lower the boundary another bit would ensue with another 6 and 12 month review...etc. I personally do not feel that the codification of such in the policy is appropriate. Bill Darte ARIN Advisory Council > -----Original Message----- > From: william at elan.net [mailto:william at elan.net] > Sent: Friday, August 22, 2003 9:12 AM > To: Bill Darte > Cc: ARIN Public Policy (E-mail) > Subject: Re: [ppml] Current Info - Policy Proposal 2002-3: > Micro-Assignments for Mult ihomed Networks > > > This proposal is similar enough to 2002-3 and in fact this it is very > encoraging considering it is coming from AC and they even put > provisions > for futher reductions. If we could have the exact timeframe as far as > when reductions of minimum size are evaluated (i.e. as part > of main code > to say "the minimum assignment size will be reavaluated every > year" it > would be even better. > > On Fri, 22 Aug 2003, Bill Darte wrote: > > > Hello All, > > > > The following verbiage and procedure discussion is in play > within the ARIN > > AC. Please review and make comments as you see fit. > > This proposal (or something following from it) will be presented for > > discussion at the Chicago Public Policy Meeting. > > > > ******************************* > > If an end-user is not multi-homed, the minimum justified > block of IP > > address space assigned by ARIN is a /20. If assignments > smaller than /20 > > are needed, end-users should contact their upstream provider. > > > > If an end-user is multi-homed, and has an ARIN assigned ASN, > > the minimum justified block of IP address space assigned by > ARIN is a /22. > > Such > > assignment will be made from a reserve block for this purpose. If > > multi-homed > > assignments smaller than a /22 are needed, end users should > contact their > > upstream provider. > > > > ****************************** > > > > It has further been argued that should this policy (or > something following > > from it) > > be endorsed at the meeting, then an assessment of the impact of this > > policy's > > implementation by # of requests and route table impact for > 2 consecutive 6 > > mos. periods. If the impact is not believed to be > problematic, then a > > proposal should be made to lower the minimum to /23 with the same > > assessment. > > Given no problems for /23 then a proposal for /24 as a > minimum would be > > made. > > > > Also, an assessment of the number of allocations > > that are still multihomed after 12 months should be made > > to determine whether there is any change in status of these > end nets. > > > > Bill Darte > > ARIN Advisory Council > From cscott at gaslightmedia.com Fri Aug 22 13:57:14 2003 From: cscott at gaslightmedia.com (Charles Scott) Date: Fri, 22 Aug 2003 13:57:14 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory In-Reply-To: <5BD887EB4A582A439038636F7A93A5A701E5A131@wava00s2kexch01.eli.czn.com> Message-ID: On Fri, 22 Aug 2003, Azinger, Marla wrote: > 2. In the end...does this policy mean that if I want the End Users and > ISP's that I Re-assign and RE-allocate to will not have their abuse, > technical and whatever else contact info visibile unless I take extra steps > to ensure "I want them visible"? If this does mean I have to take extra > steps....I give up...because as a person that sends these in daily....I'm > already jumping through to many hoops. If I understand this the way I'd like to see it :), only those receiving allocations direct from ARIN would be required to be listed in the database. Providers receiving allocations from ARIN may opt to have assignments to their customers listed, provided that those listings have current good contact data. This makes sense as it offers the ability to have contacts listed for assignments so issues can be resolved directly at that level where possible, but still requires the allocation recipient to be ultimately responsible. I see this as an excellent compromise to permit a hierarchy of responsibility where possible and practical, but as an option, and only where verifiable. I therefore support some level of consequence should contacts not be verifiable. > 3. When you mention validating the POC info every three months....is this > to be done with just Direct Allocation from ARIN? Or do you really mean the > whole WHOIS database? If its the whole database...and its done in the same > manner it was done this last year by ARIN....where you have to update > records that are really already updated.............Every 3 months is > excessive and I dont see this being easily supported. If the WHOIS database is limited to the responsible parties as indicated above, then the process should be efficient once it's established. I feel the 3 month verification cycle is proper and appropriate. If verification is as simple as replying to an email that contains a verification code the process should have minimal impact. (Although, I wonder if there may need to be some additional verification code that is not supplied in the verification request to ensure the proper party responds.) Chuck From cscott at gaslightmedia.com Fri Aug 22 14:05:50 2003 From: cscott at gaslightmedia.com (Charles Scott) Date: Fri, 22 Aug 2003 14:05:50 -0400 (EDT) Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihomed Networks In-Reply-To: <1061568262.835.425.camel@intrepid.jsw.louisville.ky.us> Message-ID: On 22 Aug 2003, Jeff S Wheeler wrote: > On Fri, 2003-08-22 at 10:54, Eric Van Tol wrote: > > With this reasoning, I suppose it would be okay to go out and steal cars > > because some people find it too difficult to purchase a car on their > > own, or lack the finances to purchase one. > > Unfortunately in this case, a majority of the people using "hijacked" IP > address space are doing so because they are too small to legitimately > obtain assignments from the ARIN. > > Using your analogy, it is impossible for many people to buy cars. Those > people need one to get to work. Oh, and don't forget to mention, there > are thousands upon thousands of abandoned cars, which no one will miss, > and which are are in fine working order, on the side of the road. The > only thing wrong with them is that they aren't registered to you (yet). I hate to perpetuate analogies to cars, but... there is public transportation, there are taxis, there are busses, there are trains. Many people can't or don't buy cars or don't use them for all transportation. It makes no sense to force reduction of the cost of cars to the point at which everyone would use them. Doing so would in many ways jeopardize safety and efficiency. There will always be people who can't afford to buy or operate cars, who shouldn't operate cars, or who simply prefer not to. Stealing cars because you don't like the smell on the bus doesn't seem to be adequate justification for theft. Chuck From marla_azinger at eli.net Fri Aug 22 14:09:58 2003 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 22 Aug 2003 11:09:58 -0700 Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory Message-ID: <5BD887EB4A582A439038636F7A93A5A701E5A135@wava00s2kexch01.eli.czn.com> 2. If we dont include the name of the company that is actually "using" an IP block such as one of my End User's than I dont see much use of the whole WHOIS database. If all ARIN WHOIS shows is the Directly Allocated Recipient then my company for example wouldnt be able to handle the number of calls coming in. Right now people daily use the "true users" info off of the WHOIS database in order to resolve issues....and then if that doesnt work we are contacted and get involved. I suppose if you want to make it an option as to whether or not "the true user POC info is included" on WHOIS....maybe that would be ok.....but I shouldnt have to take any extra steps to ensure all of our End User and ISP's info is included on WHOIS. 3. I still strongly believe a 3 month POC validation is excessive. Once a year would be more realistic. I also strongly believe that in no way should it be done the same way it was done this last year. I have wasted way to much time on a daily basis sending in an "update org template" for companies that the information has not changed. I'm still sending in the damn things for companies that the info hasnt changed. I shouldnt have to do this unless someone has proved the info is not valid. Marla -----Original Message----- From: Charles Scott [mailto:cscott at gaslightmedia.com] Sent: Friday, August 22, 2003 10:57 AM To: Azinger, Marla Cc: 'Mury'; Member Services; ppml at arin.net Subject: RE: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory On Fri, 22 Aug 2003, Azinger, Marla wrote: > 2. In the end...does this policy mean that if I want the End Users and > ISP's that I Re-assign and RE-allocate to will not have their abuse, > technical and whatever else contact info visibile unless I take extra steps > to ensure "I want them visible"? If this does mean I have to take extra > steps....I give up...because as a person that sends these in daily....I'm > already jumping through to many hoops. If I understand this the way I'd like to see it :), only those receiving allocations direct from ARIN would be required to be listed in the database. Providers receiving allocations from ARIN may opt to have assignments to their customers listed, provided that those listings have current good contact data. This makes sense as it offers the ability to have contacts listed for assignments so issues can be resolved directly at that level where possible, but still requires the allocation recipient to be ultimately responsible. I see this as an excellent compromise to permit a hierarchy of responsibility where possible and practical, but as an option, and only where verifiable. I therefore support some level of consequence should contacts not be verifiable. > 3. When you mention validating the POC info every three months....is this > to be done with just Direct Allocation from ARIN? Or do you really mean the > whole WHOIS database? If its the whole database...and its done in the same > manner it was done this last year by ARIN....where you have to update > records that are really already updated.............Every 3 months is > excessive and I dont see this being easily supported. If the WHOIS database is limited to the responsible parties as indicated above, then the process should be efficient once it's established. I feel the 3 month verification cycle is proper and appropriate. If verification is as simple as replying to an email that contains a verification code the process should have minimal impact. (Although, I wonder if there may need to be some additional verification code that is not supplied in the verification request to ensure the proper party responds.) Chuck From cscott at gaslightmedia.com Fri Aug 22 14:27:38 2003 From: cscott at gaslightmedia.com (Charles Scott) Date: Fri, 22 Aug 2003 14:27:38 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory In-Reply-To: <5BD887EB4A582A439038636F7A93A5A701E5A135@wava00s2kexch01.eli.czn.com> Message-ID: On Fri, 22 Aug 2003, Azinger, Marla wrote: > 2. If we dont include the name of the company that is actually "using" an > IP block such as one of my End User's than I dont see much use of the whole > WHOIS database. The corollary to which is... If we don't have valid contact data and some chain of responsibility then I don't see much use of the whole WHOIS database. (other than as a source of addresses to spam) I'd rather have less data that's valid than more data that's useless. Chuck From marla_azinger at eli.net Fri Aug 22 14:37:08 2003 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 22 Aug 2003 11:37:08 -0700 Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory Message-ID: <5BD887EB4A582A439038636F7A93A5A701E5A136@wava00s2kexch01.eli.czn.com> 2. Well, I guess I dont find the majority of the data I send in useless. Plus, the manor of less data that you are referring to is already included in the database...so wouldnt it just be best to leave it up to the judment of the person looking to get ahold of a POC to decide for themselves whether they want to contact the ARIN Directly Allocated USER or the Re-allocated user? Does taking away choices really resolve the end goal to have valid POC's? I dont think it does...it just minimizes the options people have....and in alot of cases (especially with my company) will slow down the response they get on issues if they dont have the ability to go straight to the "actual user". Marla -----Original Message----- From: Charles Scott [mailto:cscott at gaslightmedia.com] Sent: Friday, August 22, 2003 11:28 AM To: Azinger, Marla Cc: 'Mury'; Member Services; ppml at arin.net Subject: RE: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory On Fri, 22 Aug 2003, Azinger, Marla wrote: > 2. If we dont include the name of the company that is actually "using" an > IP block such as one of my End User's than I dont see much use of the whole > WHOIS database. The corollary to which is... If we don't have valid contact data and some chain of responsibility then I don't see much use of the whole WHOIS database. (other than as a source of addresses to spam) I'd rather have less data that's valid than more data that's useless. Chuck From mury at goldengate.net Fri Aug 22 14:50:56 2003 From: mury at goldengate.net (Mury) Date: Fri, 22 Aug 2003 13:50:56 -0500 (CDT) Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory In-Reply-To: <5BD887EB4A582A439038636F7A93A5A701E5A135@wava00s2kexch01.eli.czn.com> Message-ID: > 3. I still strongly believe a 3 month POC validation is excessive. Once a > year would be more realistic. I also strongly believe that in no way should > it be done the same way it was done this last year. I have wasted way to > much time on a daily basis sending in an "update org template" for > companies that the information has not changed. I'm still sending in the > damn things for companies that the info hasnt changed. I shouldnt have to > do this unless someone has proved the info is not valid. I also still strongly agree with this. From ahp at hilander.com Fri Aug 22 14:48:58 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Fri, 22 Aug 2003 12:48:58 -0600 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihomed Networks In-Reply-To: <20030822172337.GA38742@ussenterprise.ufp.org> References: <4CBD2D346320D541AB8BF4C0140EF7CD40D89D@staq7.hq.atlantech.net> <20030822153136.GA34331@ussenterprise.ufp.org> <2147483647.1061546313@[192.168.1.101]> <20030822172337.GA38742@ussenterprise.ufp.org> Message-ID: <2147483647.1061556538@[192.168.1.101]> --On Friday, August 22, 2003 13:23 -0400 Leo Bicknell wrote: > > Respectfully, the problem is that ARIN does not yet serve the > constituency that needs this proposal, and those it does serve today > in general have incentives to act in the opposite manor > > The people who need these small blocks today can't get them from > ARIN, and are not ARIN members. They don't get to vote. Instead, > they get their addresses from an upstream provider that has direct > incentives (from charging a fee for address allocations to wanting > the customer to be in their own non-portable space to make it more > painful for the customer to leave) to prevent proposals like this > from succeeding. They are the ones who get to vote. It also seems > to be futher hampered by the fact that only a small group of ISP's > go to the meeting and raise their voice, often for better or worse > making it the loudest one by default. One does not need to be an ARIN member to participate in the process. All one needs to do is join the ARIN mailing lists and/or attend the meetings. ARIN serves those who receive address space in North America, and implements policy based on input from those who choose to participate in the process. How do you propose ARIN serve a constituency that does not make its voice heard? > > It is up to ARIN to give ISP's and large end users the IP space > they need. Period. The measure of success is that the people who > need IP's can get them with a reasonable amount of effort, in a > reasonable amount of time. ARIN is responsible for a critical internet resource. Are you suggesting that the proper maintenance of that resource to ensure it continues to be available and useful is not one of ARIN's goals? Alec Chair, ARIN AC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pkcs7-signature Size: 2288 bytes Desc: not available URL: From cscott at gaslightmedia.com Fri Aug 22 15:00:03 2003 From: cscott at gaslightmedia.com (Charles Scott) Date: Fri, 22 Aug 2003 15:00:03 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory In-Reply-To: <5BD887EB4A582A439038636F7A93A5A701E5A136@wava00s2kexch01.eli.czn.com> Message-ID: Marla: I appreciate your point, but I believe it is accommodated in the proposal. The option is still there to include however much detail is desired, only with this you'll have some chance that there will be an answer when you call or mail the listed contacts. Forcing all detail when doing so is likely to force marginally reliable data (the current situation) seems counterproductive. Chuck On Fri, 22 Aug 2003, Azinger, Marla wrote: > 2. Well, I guess I dont find the majority of the data I send in useless. > Plus, the manor of less data that you are referring to is already included > in the database...so wouldnt it just be best to leave it up to the judment > of the person looking to get ahold of a POC to decide for themselves whether > they want to contact the ARIN Directly Allocated USER or the Re-allocated > user? Does taking away choices really resolve the end goal to have valid > POC's? I dont think it does...it just minimizes the options people > have....and in alot of cases (especially with my company) will slow down the > response they get on issues if they dont have the ability to go straight to > the "actual user". > > Marla From billd at cait.wustl.edu Fri Aug 22 15:11:17 2003 From: billd at cait.wustl.edu (Bill Darte) Date: Fri, 22 Aug 2003 14:11:17 -0500 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks Message-ID: <7D6FB5D2AE48D84983C354E50E83C2560363DA@kronos.cait.wustl.edu> > The people who need these small blocks today can't get them from > ARIN, and are not ARIN members. They don't get to vote. Insted, > they get their addresses from an upstream provider that has direct > incentives (from charging a fee for address allocations to wanting > the customer to be in their own non-portable space to make it more > painful for the customer to leave) to prevent proposals like this > from succeeding. They are the ones who get to vote. It also seems > to be futher hampered by the fact that only a small group of ISP's > go to the meeting and raise their voice, often for better or worse > making it the loudest one by default. > > To address the proposal itself, I'm happy to start with a /22 and > move to a /24 limit as necessary. The problem is that the proposal > wants to tie that to routing table growth. Since ARIN doesn't > control the size of the routing table, that should be a non-starter. > History suggests that assignment policy has an impact on route tables and they have an impact on routability. Making changes to the assignment boundary suggests to me that we should be cautious. Introducing policy that is untenable because it is mismatched with filtering policies is non-productive. The policy statement does not tie the process to the routing table...it introduces caution and prudence. More to the point, it does not put any objective measure on the > routing table impact -- which due to my beliefs from the previous > paragraph will mean an increase by so much as 1 route will be used > to argue against it in the future. There is a hidden implication > the routing table size should stay the same, or decrease. That's > bogus. In defining Objective measurements, there would argument.... the AC discussions ran more along the lines of looking for 'significant' if not catostrophic impacts. No one is trying to find trivial fault in order to argue against the policy. If the AC were clearly against this policy, it would have simply been defeated. It will clearly increase in the short term (as people > renumber they will have to announce both in many cases), and it > should have a long term impact to increase the routing table (as > it becomes easier for people to set up their redundnat networks the > way they should be set up). It also doesn't supply a measurement > interval that's meaningful, during the time proposed we'll still > be in the initial cut over period, with the double announcements > and the like. That's not a good time to judge success or failure. Well you got pretty near contructive criticism here.... do you have a timeframe to suggest that you think is meaningful or reasonable for judgement? > > It is up to ARIN to give ISP's and large end users the IP space > they need. Period. The measure of success is that the people who > need IP's can get them with a reasonable amount of effort, in a > reasonable amount of time. > > The issue of routing table size should not be in any of ARIN's > proposals, just like issues of which ISP's filter which routes > should not be in them either. The routing table size question is > great in some other forms, and answers to it may influence how > ARIN's members vote on some proposals, but it has no business being > in a proposal. It is not in the proposal.... it is in the process of assessing the viability of a proposal. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org > From Stacy_Taylor at icgcomm.com Fri Aug 22 15:01:46 2003 From: Stacy_Taylor at icgcomm.com (Taylor, Stacy) Date: Fri, 22 Aug 2003 13:01:46 -0600 Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA04DAE335@denexg21.icgcomm.com> I also concur with Marla and Mury. Stacy -----Original Message----- From: Mury [mailto:mury at goldengate.net] Sent: Friday, August 22, 2003 11:51 AM To: Azinger, Marla Cc: 'Charles Scott'; Member Services; ppml at arin.net Subject: RE: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory > 3. I still strongly believe a 3 month POC validation is excessive. Once a > year would be more realistic. I also strongly believe that in no way should > it be done the same way it was done this last year. I have wasted way to > much time on a daily basis sending in an "update org template" for > companies that the information has not changed. I'm still sending in the > damn things for companies that the info hasnt changed. I shouldnt have to > do this unless someone has proved the info is not valid. I also still strongly agree with this. From bicknell at ufp.org Fri Aug 22 15:29:11 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 22 Aug 2003 15:29:11 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks In-Reply-To: <7D6FB5D2AE48D84983C354E50E83C2560363DA@kronos.cait.wustl.edu> References: <7D6FB5D2AE48D84983C354E50E83C2560363DA@kronos.cait.wustl.edu> Message-ID: <20030822192911.GA45462@ussenterprise.ufp.org> In a message written on Fri, Aug 22, 2003 at 02:11:17PM -0500, Bill Darte wrote: > No one is trying to find trivial fault in order to argue against the policy. > If the AC were clearly against > this policy, it would have simply been defeated. I think the AC is in general for smaller allocations, please don't interpret my frustration as a belief otherwise. However I fully understand the AC needs to find community support before acting, and my impression is that is the problem with this issue. Further, it's not that the community is vocally against it, but rather that very few people will stand up and be for it. > Well you got pretty near contructive criticism here.... do you have a > timeframe to suggest > that you think is meaningful or reasonable for judgement? I think it would be at least two years before we know the impact of such a proposal. That gives enough time for people to be aware it's available, incorporate that into their own plans, implment cut overs, and return old space they are no longer using. > It is not in the proposal.... it is in the process of assessing the > viability of a proposal. My apologies. I misinterpreted earlier e-mail that the comments were part of the policy itself, but I see now they were adjunct comments. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org From billd at cait.wustl.edu Fri Aug 22 15:45:07 2003 From: billd at cait.wustl.edu (Bill Darte) Date: Fri, 22 Aug 2003 14:45:07 -0500 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks Message-ID: <7D6FB5D2AE48D84983C354E50E83C2560363DF@kronos.cait.wustl.edu> > -----Original Message----- > From: Leo Bicknell [mailto:bicknell at ufp.org] > Sent: Friday, August 22, 2003 2:29 PM > To: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2002-3: Micro-Assignments > forMultihome d Networks > > > In a message written on Fri, Aug 22, 2003 at 02:11:17PM > I think the AC is in general for smaller allocations, please don't > interpret my frustration as a belief otherwise. However I fully > understand the AC needs to find community support before acting, > and my impression is that is the problem with this issue. Further, > it's not that the community is vocally against it, but rather that > very few people will stand up and be for it. > > > Well you got pretty near contructive criticism here.... do > you have a > > timeframe to suggest > > that you think is meaningful or reasonable for judgement? > > I think it would be at least two years before we know the impact > of such a proposal. That gives enough time for people to be aware > it's available, incorporate that into their own plans, implment cut > overs, and return old space they are no longer using. So, you would argue that we should look for negative impact throughout a two year period in order to ensure that the policy was viable before migrating the boundary to /23? Could we improve the time to 'understanding and adoption' by some vehicle you could propose? Bill Darte ARIN Advisory Council From bicknell at ufp.org Fri Aug 22 15:51:13 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 22 Aug 2003 15:51:13 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks In-Reply-To: <7D6FB5D2AE48D84983C354E50E83C2560363DF@kronos.cait.wustl.edu> References: <7D6FB5D2AE48D84983C354E50E83C2560363DF@kronos.cait.wustl.edu> Message-ID: <20030822195113.GA46870@ussenterprise.ufp.org> In a message written on Fri, Aug 22, 2003 at 02:45:07PM -0500, Bill Darte wrote: > So, you would argue that we should look for negative impact throughout a two > year period > in order to ensure that the policy was viable before migrating the boundary > to /23? Could we > improve the time to 'understanding and adoption' by some vehicle you could > propose? No, I would argue we should go right to /24 now, let the industry deal with whatever problems come up, and in two years look at how we did. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From billd at cait.wustl.edu Fri Aug 22 15:59:19 2003 From: billd at cait.wustl.edu (Bill Darte) Date: Fri, 22 Aug 2003 14:59:19 -0500 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks Message-ID: <7D6FB5D2AE48D84983C354E50E83C2560363E1@kronos.cait.wustl.edu> > In a message written on Fri, Aug 22, 2003 at 02:45:07PM > -0500, Bill Darte wrote: > > So, you would argue that we should look for negative impact > throughout a two > > year period > > in order to ensure that the policy was viable before > migrating the boundary > > to /23? Could we > > improve the time to 'understanding and adoption' by some > vehicle you could > > propose? > > No, I would argue we should go right to /24 now, let the industry deal > with whatever problems come up, and in two years look at how we did. Sorry, can't support that.... we would do the 'invisible constituency' a disservice to assign addresses that are unusable. Bill Darte ARIN Advisory Council > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org > From ahp at hilander.com Fri Aug 22 16:37:52 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Fri, 22 Aug 2003 14:37:52 -0600 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks In-Reply-To: <20030822195113.GA46870@ussenterprise.ufp.org> References: <7D6FB5D2AE48D84983C354E50E83C2560363DF@kronos.cait.wustl.edu> <20030822195113.GA46870@ussenterprise.ufp.org> Message-ID: <2147483647.1061563072@[192.168.1.101]> --On Friday, August 22, 2003 15:51 -0400 Leo Bicknell wrote: > > No, I would argue we should go right to /24 now, let the industry deal > with whatever problems come up, and in two years look at how we did. I really don't care for this 'let the industry deal with it' attitude. We all make up the industry, which is exactly why caution is mandated. Alec -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pkcs7-signature Size: 2288 bytes Desc: not available URL: From forrest at almighty.c64.org Fri Aug 22 16:45:29 2003 From: forrest at almighty.c64.org (Forrest) Date: Fri, 22 Aug 2003 15:45:29 -0500 (CDT) Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks In-Reply-To: <7D6FB5D2AE48D84983C354E50E83C2560363E1@kronos.cait.wustl.edu> Message-ID: On Fri, 22 Aug 2003, Bill Darte wrote: > > No, I would argue we should go right to /24 now, let the industry deal > > with whatever problems come up, and in two years look at how we did. > > Sorry, can't support that.... we would do the 'invisible constituency' a > disservice to assign addresses > that are unusable. > > Bill Darte > ARIN Advisory Council > I tend to agree, it's pretty pointless to dole out /24's to multihomed organizations if nobody is going to accept the routes. A /22 minimum seems to be logical in that I haven't seen any providers filtering out routes shorter than or equal to /22. A micro-allocation policy ultimately requires buy-in from all of the people that will be accepting the routes. On a side note, I see in the minutes from the May 8, 2003 Advisory Council Meeting that it was suggested that APNIC and LACNIC both be contacted to find out how their micro-allocation policies are working out for them. Does anyone know if that's been done, and if so what the results were? Here's a link to those meeting minutes. http://www.arin.net/library/minutes/ac/ac2003_0508.html Thanks Forrest From bicknell at ufp.org Fri Aug 22 17:00:54 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 22 Aug 2003 17:00:54 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks In-Reply-To: <7D6FB5D2AE48D84983C354E50E83C2560363E1@kronos.cait.wustl.edu> References: <7D6FB5D2AE48D84983C354E50E83C2560363E1@kronos.cait.wustl.edu> Message-ID: <20030822210054.GA49535@ussenterprise.ufp.org> In a message written on Fri, Aug 22, 2003 at 02:59:19PM -0500, Bill Darte wrote: > Sorry, can't support that.... we would do the 'invisible constituency' a > disservice to assign addresses > that are unusable. Do you actually believe that this will result in a marked increase in the number of routes. Indeed, I'll throw out a number, do you think this proposal has the potention to cause even 10% growth in the routing table? Most of the people who want this today have space from an upstream they are advertising to a second upstream. That is, the route is already there. There will be some new people who get space under this proposal who never had space (routed) before, but with a 120,000 entry routing table that would need to be 12,000 people requesting new space to generate a 10% bump. ARIN's current rate is 214 requests per month, in the busiest month, that's 2568 per year. To reach even the 12,000 number you'd have to have over a 450% increase. Frankly, with ARIN's current staff I doubt they could complete enough requests to cause an issue to the routing table in a year without adding staff. That alone would be a safeguard. The routing table danger here has been grossly blown out of proportion. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From billd at cait.wustl.edu Fri Aug 22 17:26:54 2003 From: billd at cait.wustl.edu (Bill Darte) Date: Fri, 22 Aug 2003 16:26:54 -0500 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks Message-ID: <7D6FB5D2AE48D84983C354E50E83C2560363E2@kronos.cait.wustl.edu> In a message written on Fri, Aug 22, 2003 at 02:59:19PM -0500, Bill Darte wrote: > Sorry, can't support that.... we would do the 'invisible constituency' a > disservice to assign addresses > that are unusable. Do you actually believe that this will result in a marked increase in the number of routes. Indeed, I'll throw out a number, do you think this proposal has the potention to cause even 10% growth in the routing table? Actually I do not. Yet there are those who do. I have not seen evidence either way with exception that we have witnessed no attributable increase when first the AC lowered the boundary to its present level. Most of the people who want this today have space from an upstream they are advertising to a second upstream. That is, the route is already there. There will be some new people who get space under this proposal who never had space (routed) before, but with a 120,000 entry routing table that would need to be 12,000 people requesting new space to generate a 10% bump. ARIN's current rate is 214 requests per month, in the busiest month, that's 2568 per year. To reach even the 12,000 number you'd have to have over a 450% increase. Frankly, with ARIN's current staff I doubt they could complete enough requests to cause an issue to the routing table in a year without adding staff. That alone would be a safeguard. Of course we would want a safeguard against doing in ARIN's ability to operate effectively too.... there are many constituencies to accomodate. The routing table danger here has been grossly blown out of proportion. I for one fully expect and hope that you are correct. I too wish to identify and support that invisible constituency if it exists and needs supporting. I have little evidence of that either. Bill Darte ARIN AC From william at elan.net Fri Aug 22 18:36:22 2003 From: william at elan.net (william at elan.net) Date: Fri, 22 Aug 2003 15:36:22 -0700 (PDT) Subject: [ppml] ARIN text on requirements of reporting customer reassignments in whois needs to be more clear Message-ID: I've been in discussions with somebody and it seems some ISPs (Level3 for example) when reading ARIN policies come to conclusion that while they have to report reassignments to ARIN, this does not mean they have to do it to the public. My underestanding is different (as I undetstood especially after discussions of 2003-3) and I also pointed out that at http://www.arin.net/policy/ipv4.html#requirements it does say "This information must be visible via WHOIS prior to submitting a request for a new allocation". However that this is not mentioned anywhere else is a problem (particularly that its not mentioned at http://www.arin.net/policy/ipv4.html#reassign). While I'm not certain if we need completely new policy proposal to just clairify it (can ARIN just add comments from #requirements to #reassign to make for purposes of not introducing new policy but clarifying existing one, but without this actually being voted word-word on the meeting?) it does need to be addressed. I also noticed that new policy proposal 2003-11 (which is actually named "Purpose and Scope of WHOIS Directory" !) does not mention this either, and the closest we do have is 2003-5 which focuses requirements of ISPs when they maintain their own reassignment server. But something does need to be done to make it clear to ISPs that they are in fact required to provide customer reassigment information in whois and not only to ARIN staff. Below are discussions I had so you could understand why they are problems with current wording. ---------- Forwarded message ---------- > > My understanding of ARIN policy is that they are required to provide > > this information, but that it does NOT have to be provided to the > > public. It just has to be provided to ARIN. > That is not correct. I've been involved with discussions at ARIN > mailing lists about this and at the meeting. It is clear that policy > is that ISP are supposed to report data in whois and must report > accurate data on their customers (with exception that address for ip > block assigned to individuals can be blanked out). http://arin.net/policy/ipv4.html has no specific mention that the data must be made available to anyone other than ARIN itself. The implication at http://arin.net/policy/ipv4.html#reassign seems to be that the reassignment information is primarily for ARIN to determine current utilization. Requesters must satisfy the following requirements for ARIN to determine whether allocated space is being used efficiently: 1. Provide utilization information via SWIP or RWhois for all /29 and shorter prefix lengths. SWIP and RWhois reassignments should show each client's organizational information. The format below should be used to provide the required information for utilization of blocks smaller than /29 and for describing internal networks. There's no mention anywhere that this information must or should be public. Also, from http://arin.net/library/guidelines/swip.html: Introduction Internet Service Providers (ISPs) that receive IP address space from ARIN directly or indirectly (as a downstream customer of another ISP) MUST use either Shared WHOIS Project known as SWIP or a Referral WHOIS server known as RWhois to provide reassignment information for /29 and larger blocks to ARIN. This specifically says "provide reassignment information.... TO ARIN" (emphasis mine). Again, I'm not saying I don't agree that the information SHOULD be publicly available, but I don't see anything in the text to support the argument that it must be. From jlewis at lewis.org Sat Aug 23 00:37:18 2003 From: jlewis at lewis.org (jlewis at lewis.org) Date: Sat, 23 Aug 2003 00:37:18 -0400 (EDT) Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks In-Reply-To: <20030822195113.GA46870@ussenterprise.ufp.org> Message-ID: On Fri, 22 Aug 2003, Leo Bicknell wrote: > No, I would argue we should go right to /24 now, let the industry deal > with whatever problems come up, and in two years look at how we did. Supporting this (IMO) is http://www.arin.net/policy/2001_2.html Multihoming is already justification for an ISP to assign a /24 to a customer. Therefore, multihomed networks already can get /24's from one of their providers and announce them via BGP into the global routing table. With the exception of any networks still filtering on RIR allocation boundaries, everyone is already seeing these /24 routes. Why not let these networks get their /24's directly from ARIN and give them the flexibility and peace of mind that they won't have to renumber if they choose to leave that provider, if that provider goes bankrupt, or if that provider decides to stop doing business in their area? It seems to me this should cause no impact on the global routing table size. ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jamoore2 at vt.edu Sun Aug 24 00:18:01 2003 From: jamoore2 at vt.edu (James T. Moore) Date: Sun, 24 Aug 2003 00:18:01 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihomedNetworks References: <4CBD2D346320D541AB8BF4C0140EF7CD40D89D@staq7.hq.atlantech.net> <1061568262.835.425.camel@intrepid.jsw.louisville.ky.us> Message-ID: <009101c369f6$b564a890$0464a8c0@vmnet1.mogul.dyndns.org> > What you CAN do is remove the need for folks to "hijack" space, use > out-of-region registrars, and so on. > IMO, I do not think the actions of a few ignorant or rogue organizations should be factored into ARIN's decision to adjust the direct assignment size. I don't think that ignorance of the proper procedures for requesting space or in the case where an organization "buys" a hijacked IP block is a reasonable excuse. Most likely the ignorant orgnazation already has an ISP who is aware of the proper procedures and who can assign them address space and inform the customers of the policy if the customer asks.A rogue organiazation will eventually need to contact an ISP to setup a BGP session to advertise their stolen address space and the ISP should know better and should block the advertisement and explain the situation and proper policies to the customer. With these thoughts in mind, I would like to see a policy describing an enforcement plan to control organizations which advertise routes to hijacked networks. Our company is multihomed on a /24 with address space from one of our providers with no complaints. I found the process of requesting an ASN from ARIN easy and straight forward. Just my 2 cents, J.T. Moore From jlewis at lewis.org Mon Aug 25 11:16:00 2003 From: jlewis at lewis.org (jlewis at lewis.org) Date: Mon, 25 Aug 2003 11:16:00 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-10: Apply the HD Ratio to All Future IPv4 Allocations In-Reply-To: <200308211528.LAA01371@ops.arin.net> Message-ID: On Thu, 21 Aug 2003, Member Services wrote: > 2. The HD(Host Density) ratio of all previous allocations shall be greater > than or equal to .966 and the HD ratio of the most recent allocation shall > be greater than or equal to .930 in order to receive additional space. > > 3. The HD ratio is calculated as log10(utilized IPv4 > addresses)/log10(totall addresses in all previous allocations). In this > formula, log10 refers to the base 10 logarithm. Is there a good reason to abandon the relatively simple 80% rule in favor of a mathematically more complicated formula that effectively drops the % utilization rules by a noticable amount? > The basic thrust of my proposal is to replace the rigid 80% usage > criterion by the more flexible HD ratio and to shift the emphasis away > from the last allocated block to include the total allocated address > space. I'd never even noticed that issue until just now. http://www.arin.net/policy/ipv4.html#additional ISPs must have efficiently utilized all previous allocations, and at least 80% of their most recent allocation... ... Please note that until your prior utilization is verified to meet the 80% requirement, ARIN can neither process nor approve a request for additional addresses. I'd always assumed the 80% applied to all of your IP space. From the above, it's not clear. The first bit clearly says it applies to your most recent allocation. The second bit suggests to me that it applies to all prior allocations. If it doesn't, then what's the definition of "efficiently utilized all previous allocations"? > To that end, the .930 criterion for the last block is a lot looser > than the existing requirements for the last block. This recognizes that > the economy is more dependent than ever on the smooth running of our > networks and we should not artificially force members to operate with > virtually no safety buffers for implementing new addresses. If that's the reason for suggesting a 0.930 HD requirement on the most recent allocation, why not just come out and say 50% for the most recent allocation? ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From cscott at gaslightmedia.com Mon Aug 25 14:22:27 2003 From: cscott at gaslightmedia.com (Charles Scott) Date: Mon, 25 Aug 2003 14:22:27 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-10: Apply the HD Ratio to All Future IPv4 Allocations In-Reply-To: Message-ID: On Mon, 25 Aug 2003 jlewis at lewis.org wrote: > On Thu, 21 Aug 2003, Member Services wrote: > > Is there a good reason to abandon the relatively simple 80% rule in favor > of a mathematically more complicated formula that effectively drops the % > utilization rules by a noticable amount? I'd have to agree with you here. I've challenged the applicability of HD to this situation and did not receive any responses. I would think there would have to be good reson to make changes that waste additional space. I still think there's confusion between allocations, assignments, and (the dual-purpose word) utilization. Perhaps if that was cleared up, this policy would no longer have any traction. Chuck From bicknell at ufp.org Mon Aug 25 15:00:13 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 25 Aug 2003 15:00:13 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks In-Reply-To: References: <20030822195113.GA46870@ussenterprise.ufp.org> Message-ID: <20030825190013.GC89421@ussenterprise.ufp.org> In a message written on Sat, Aug 23, 2003 at 12:37:18AM -0400, jlewis at lewis.org wrote: > Supporting this (IMO) is http://www.arin.net/policy/2001_2.html To be clear, it supports the assertion that everyone getting a /24 will not hurt the routing table, not that ARIN should assign /24's. Perhaps the way to do this is to just conservatively limit the "test program". That is, move ARIN's boundry to /24, but if ARIN will be limited to no more than 200 networks per month between /20 (the current limit) and /24), for the first year, at which time the proposal must be renewed to be continued. So, that's a maximum exposure of 2400 new routes globally (about 2% increase, worst case). If that actually happens after a year it can be voted down as a failed experiment, but if as I believe the real rate is an addital 20-50 requests per month on average giving us modest growth it can be reapproved, possibly without the cap moving forward. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org From jlewis at lewis.org Mon Aug 25 15:32:32 2003 From: jlewis at lewis.org (jlewis at lewis.org) Date: Mon, 25 Aug 2003 15:32:32 -0400 (EDT) Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks In-Reply-To: <20030825190013.GC89421@ussenterprise.ufp.org> Message-ID: On Mon, 25 Aug 2003, Leo Bicknell wrote: > In a message written on Sat, Aug 23, 2003 at 12:37:18AM -0400, jlewis at lewis.org wrote: > > Supporting this (IMO) is http://www.arin.net/policy/2001_2.html > > To be clear, it supports the assertion that everyone getting a /24 > will not hurt the routing table, not that ARIN should assign /24's. Unless there are many networks filtering on RIR boudaries (anyone know how many do this?), what's the routing table / routing table growth difference between a network getting their /24 from C&W vs from ARIN if they are going to have their own ASN and announce it to multiple providers as a /24 either way? The only obvious downside I see is application fraud by networks wanting to get their own /24 without satisfying the multihomed requirement. Maybe add in that if a network is not consistently multihomed for X months, they have to give up the block, or it begins to go up considerably in price. > Perhaps the way to do this is to just conservatively limit the "test > program". That is, move ARIN's boundry to /24, but if ARIN will > be limited to no more than 200 networks per month between /20 (the > current limit) and /24), for the first year, at which time the proposal > must be renewed to be continued. That would just cause a flood of applications on the first of each month, assuming there are considerably more than 200 nets that would take advantage of this policy change, and they're aware of the 200/month limit. > So, that's a maximum exposure of 2400 new routes globally (about 2% > increase, worst case). If that actually happens after a year it can be > voted down as a failed experiment, but if as I believe the real rate > is an addital 20-50 requests per month on average giving us modest > growth it can be reapproved, possibly without the cap moving forward. Why do you think there will be any growth? Short of the fraud issue mentioned above, all these /24's are already in the global routing table. One place there would be growth is the in-addr.arpa DNS delegations...but I haven't heard anyone complaining or worrying about that. ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bicknell at ufp.org Mon Aug 25 15:51:41 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 25 Aug 2003 15:51:41 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks In-Reply-To: References: <20030825190013.GC89421@ussenterprise.ufp.org> Message-ID: <20030825195141.GA91617@ussenterprise.ufp.org> In a message written on Mon, Aug 25, 2003 at 03:32:32PM -0400, jlewis at lewis.org wrote: > Unless there are many networks filtering on RIR boudaries (anyone know how > many do this?), what's the routing table / routing table growth difference > between a network getting their /24 from C&W vs from ARIN if they are > going to have their own ASN and announce it to multiple providers as a /24 > either way? Hidden in your question is a number of subquestions, and I think it's important to enumerate: 1) Will the routing table size be an issue? As long as there are several providers who don't filter, and they don't have problems then I don't believe this is a huge issue. Some providers may be filtering and/or get broken by this change because they are running too close to the edge and/or are too cheap to upgrade. I suspect for pretty much all the major carriers this is a complete non-issue. 2) Will people filter /24's in non-portable space? The answer is almost surely yes, some people seem to always filter based on ARIN (and other regisitries) minimum assigned size, and want to never allow more specifics. 3) Will people filter /24's assigned by ARIN? In general, probably not. If ARIN clearly states it is assigning /24's from a particular block, I believe almost everyone will support that feature. The filtering crowd tends to overlap a lot with the "support the standards" crowd. That said, there are people who will do type #2 filtering, and not #3 filtering, and thus would see much more "growth" with a proposal that implements type #3. However, I come back to my point in #1, if many (most?) providers do just fine without filtering I see little reason to worry much that the filteres will have great issue. Indeed, they probably even have more headroom on this issue, on the whole. > The only obvious downside I see is application fraud by networks wanting > to get their own /24 without satisfying the multihomed requirement. > Maybe add in that if a network is not consistently multihomed for X > months, they have to give up the block, or it begins to go up considerably > in price. In my mind there should be no multi-homing requirement. It's to hard to police. Rather, make this option expensive enough that, on the whole, only those who need it will purchase. For instance, if you can get IP's for "Free" from your upstream, or fill out arin paperwork and pay, say, $1000 per year, virtually all the people who don't need it won't pay for it. > That would just cause a flood of applications on the first of each month, > assuming there are considerably more than 200 nets that would take > advantage of this policy change, and they're aware of the 200/month limit. I was thinking of a holdover system, that is first come first served, process 200 and then wait until the next month to pick it up. That said, feel free to review ARIN's numbers on how many they request today. I'm quite sure 200 is way high, and aside from a possible small initial inrush has no chance of actually limiting things. > Why do you think there will be any growth? Short of the fraud issue > mentioned above, all these /24's are already in the global routing table. There will be short term growth, as both networks are announced as people move from one to the other. I think there will also be long term growth, as people who were unsure if they could properly multihome with a non-portable /24 (eg, due to others filtering on a /19-/20 boundry) begin to multihome with these new ARIN assigned blocks. So yes, I see growth. Growth measured in fractions of a percent, or maybe even the first digit or two in the extreme case...nothing that will cause the net to come to a standstill. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jsw at five-elements.com Tue Aug 26 02:20:51 2003 From: jsw at five-elements.com (Jeff S Wheeler) Date: 26 Aug 2003 02:20:51 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks In-Reply-To: <20030825195141.GA91617@ussenterprise.ufp.org> References: <20030825190013.GC89421@ussenterprise.ufp.org> <20030825195141.GA91617@ussenterprise.ufp.org> Message-ID: <1061878850.692.76.camel@intrepid.jsw.louisville.ky.us> On Mon, 2003-08-25 at 15:51, Leo Bicknell wrote: > I was thinking of a holdover system, that is first come first served, > process 200 and then wait until the next month to pick it up. > > That said, feel free to review ARIN's numbers on how many they request > today. I'm quite sure 200 is way high, and aside from a possible small > initial inrush has no chance of actually limiting things. Leo, I like your limited-growty-exposure concept and mechanism, however I fear that the combination of limiting applications to 200/month, granting /24 requests to non-multihomers, and creating a lengthy queue will disappoint many. I suggest that a target maximum number of new assignments per month, combined with a flexible maximum assignment length, might be a better approach. Perhaps accepting applications for /21s or /22s for a month and tweaking the length afterward would be more effective. I agree that organizations who do not possess an ASN can certainly benefit from portable address space, however I think that organizations with an ASN are more able and likely to benefit from it. A requirement for having an ASN is to be multi-homed, or to have "a unique routing policy". I think possession of an ASN is an acceptable way to determine if an organization is multi-homed. The only worry that I have with that case is, will people falsify ASN applications just to get portable space? Clearly we do not want that, as AS numbers are also limited and if memory serves, they are projected to run out before IP addresses. :-/ I believe that some organizations may receive a /24 micro-assignment and need to grow to an intermediate size, e.g. /22. The growth path for such organizations should be clearly understood. Perhaps a six-month time to renumber out of an old micro-assignment block in order to receive more space from the ARIN, either under the micro-assignment policy or the traditional initial assignment path? I would also like to repeat my comment that I don't think it is valuable for the ARIN to issue /24s to multi-homed networks when there is enough address space available to issue them slightly larger networks. This will reduce the rate of follow-up assignment requests when organizations outgrow their initial request, and allow ISPs to filter those pesky /24s in whatever block is utilized for this new initiative. I suggest that a minimum assignment size of /22 would be more beneficial, and that if a multi-homed organization can today justify a /24, there is little harm in giving them some room to grow. As far as ISP filtering goes, if an assignment rate of 200/month is sustainable, and the mean assignment size under this policy is /22, then a /10 would satisfy the program for twenty months. I think carving out a new /10 from existing space available to the ARIN for assignment and setting its minimum assignment length to /22 will help control route table growth from new assignment recipients. -- Jeff S Wheeler From bicknell at ufp.org Tue Aug 26 09:50:17 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 26 Aug 2003 09:50:17 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks In-Reply-To: <1061878850.692.76.camel@intrepid.jsw.louisville.ky.us> References: <20030825190013.GC89421@ussenterprise.ufp.org> <20030825195141.GA91617@ussenterprise.ufp.org> <1061878850.692.76.camel@intrepid.jsw.louisville.ky.us> Message-ID: <20030826135017.GB29112@ussenterprise.ufp.org> In a message written on Tue, Aug 26, 2003 at 02:20:51AM -0400, Jeff S Wheeler wrote: > I agree that organizations who do not possess an ASN can certainly > benefit from portable address space, however I think that organizations > with an ASN are more able and likely to benefit from it. A requirement > for having an ASN is to be multi-homed, or to have "a unique routing > policy". I think possession of an ASN is an acceptable way to determine > if an organization is multi-homed. The only worry that I have with that > case is, will people falsify ASN applications just to get portable > space? Clearly we do not want that, as AS numbers are also limited and > if memory serves, they are projected to run out before IP addresses. :-/ As a practical matter I'm quite ok with requiring someone to have an ASN, via the current process to do that, before getting an allocation. Indeed, I think virtually all applications for IP space from ARIN should be made by someone who has an ASN. I understand there are some reasons people without a need for an ASN might need address space, but that seems more like the exception than the rule. > I would also like to repeat my comment that I don't think it is valuable > for the ARIN to issue /24s to multi-homed networks when there is enough > address space available to issue them slightly larger networks. This > will reduce the rate of follow-up assignment requests when organizations > outgrow their initial request, and allow ISPs to filter those pesky /24s > in whatever block is utilized for this new initiative. I suggest that a > minimum assignment size of /22 would be more beneficial, and that if a > multi-homed organization can today justify a /24, there is little harm > in giving them some room to grow. I'm not sure I agree. I do think we should give people who expect to grow room to grow, however many of the people who most need this sort of policy don't need a lot of space. Most of the people running high availability sites do it behind some sort of load balancers and the like and actually only use a very small number of IP's. One need look only as far as some of the largest sites, I see www.ebay.com resolves to 8 IP's right now, and www.cnn.com to 16, for example. Again, this policy is really targeted at end users who need to multihome, not at small ISP's. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From mury at goldengate.net Tue Aug 26 17:30:03 2003 From: mury at goldengate.net (Mury) Date: Tue, 26 Aug 2003 16:30:03 -0500 (CDT) Subject: [ppml] Spamming off of this list In-Reply-To: <7D6FB5D2AE48D84983C354E50E83C2560363CF@kronos.cait.wustl.edu> Message-ID: I'd like to ask that this person be removed from this mailing list for spamming to list members. Does ARIN have guidelines in place that forbids this pathetic practice? bhall at incognito.com Brian Hall | Product Manager Incognito Software Inc. T: 604.688.4332 x111 | F: 604.688-4339 Thank you. Mury From baptista at dot-god.com Tue Aug 26 17:34:40 2003 From: baptista at dot-god.com (Joe Baptista) Date: Tue, 26 Aug 2003 17:34:40 -0400 (EDT) Subject: [ppml] Spamming off of this list In-Reply-To: Message-ID: is he spamming or are you getting an autoresponder. it may not be intentional. Joe Baptista - only at www.baptista.god another useless fact .... The simple act of walking requires the use of 200 muscles in the human body. On Tue, 26 Aug 2003, Mury wrote: > > I'd like to ask that this person be removed from this mailing list for > spamming to list members. Does ARIN have guidelines in place that forbids > this pathetic practice? > > bhall at incognito.com > Brian Hall | Product Manager > Incognito Software Inc. > T: 604.688.4332 x111 | F: 604.688-4339 > > Thank you. > > Mury > > From jlewis at lewis.org Tue Aug 26 18:15:14 2003 From: jlewis at lewis.org (jlewis at lewis.org) Date: Tue, 26 Aug 2003 18:15:14 -0400 (EDT) Subject: [ppml] Spamming off of this list In-Reply-To: Message-ID: On Tue, 26 Aug 2003, Mury wrote: > > I'd like to ask that this person be removed from this mailing list for > spamming to list members. Does ARIN have guidelines in place that forbids > this pathetic practice? > > bhall at incognito.com > Brian Hall | Product Manager > Incognito Software Inc. > T: 604.688.4332 x111 | F: 604.688-4339 Is it really spam if you post in a thread on a mailing list and someone responds privately saying they have a product related to your post that you might be interested in? I'm not so sure I'd call it spam. The 1.2mb bmp attachment (making the message 1.7mb) was somewhat irresponsible/cluefree. bmp isn't what I'd call a common or appropriate format. I converted it to a 65kb jpeg with cjpeg and no options in order to see WTH it was. ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From ibaker at codecutters.org Tue Aug 26 18:40:22 2003 From: ibaker at codecutters.org (Ian Baker) Date: Tue, 26 Aug 2003 23:40:22 +0100 Subject: [ppml] Spamming off of this list References: Message-ID: <018f01c36c23$0b8e5bc0$642fa8c0@codecutters.org> Erm, what? Should I check my server logs, or did I miss a US-only phenomenon? SoBig perchance? Regards, Ian From bicknell at ufp.org Tue Aug 26 22:30:44 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 26 Aug 2003 22:30:44 -0400 Subject: [ppml] Spamming off of this list In-Reply-To: References: Message-ID: <20030827023044.GA60861@ussenterprise.ufp.org> In a message written on Tue, Aug 26, 2003 at 06:15:14PM -0400, jlewis at lewis.org wrote: > > bhall at incognito.com > > Brian Hall | Product Manager > > Incognito Software Inc. > > T: 604.688.4332 x111 | F: 604.688-4339 > > Is it really spam if you post in a thread on a mailing list and someone > responds privately saying they have a product related to your post that > you might be interested in? I'm not so sure I'd call it spam. I received one of these, of note: * The message had no "References" header, or any other indication it was a "reply" other than "Re:" in the subject line. * My sent-mail archive indicates I've never sent a message to the list with the subject Mr Hall's message indicated "Re: IP management". Given the lack of anything to indicate it was a reply, I'd say he harvested addresses, and sent out a message thinly disguised as a reply. That is spam. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From lee.howard at mci.com Wed Aug 27 10:44:55 2003 From: lee.howard at mci.com (Lee Howard) Date: Wed, 27 Aug 2003 10:44:55 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory In-Reply-To: Message-ID: On Fri, 22 Aug 2003, Charles Scott wrote: > Date: Fri, 22 Aug 2003 14:27:38 -0400 (EDT) > From: Charles Scott > To: "Azinger, Marla" > Cc: 'Mury' , Member Services , > ppml at arin.net > Subject: RE: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS > Di rectory > > On Fri, 22 Aug 2003, Azinger, Marla wrote: > > > 2. If we dont include the name of the company that is actually "using" an > > IP block such as one of my End User's than I dont see much use of the whole > > WHOIS database. > > The corollary to which is... If we don't have valid contact data and > some chain of responsibility then I don't see much use of the whole WHOIS > database. (other than as a source of addresses to spam) > I'd rather have less data that's valid than more data that's useless. > > Chuck To what extent are the following statements true? WHOIS without naming the end user is not much use. End user information without contact information, as currently allowed as reassign-simple, is not much use. Except for spammer address-harvesting and showing utilization to ARIN, WHOIS is not much use. Thanks, Lee From jlewis at lewis.org Wed Aug 27 11:05:41 2003 From: jlewis at lewis.org (jlewis at lewis.org) Date: Wed, 27 Aug 2003 11:05:41 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory In-Reply-To: Message-ID: On Wed, 27 Aug 2003, Lee Howard wrote: > To what extent are the following statements true? Depends on what you're hoping to get out of whois. > WHOIS without naming the end user is not much use. > > End user information without contact information, as currently allowed > as reassign-simple, is not much use. Without a clear name or contact info, whois could still tell you how large an assignment covering a particular IP is. For abuse tracking, if you receive spam from a few IPs in the same range, it's handy to be able to see how large that range is, and apply policy to the entire range rather than wait to be spammed from each IP in it. > Except for spammer address-harvesting and showing utilization to ARIN, > WHOIS is not much use. IMO, there should be names and contact info at least at the allocation level. If you're being spammed, attacked, hacked from an IP, or have a BGP customer wanting to announce routes to you, etc., it's nice to be able to do a whois and see who's responsible for that IP space. ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From arin-member at quadrix.com Wed Aug 27 11:18:35 2003 From: arin-member at quadrix.com (Bill Van Emburg) Date: Wed, 27 Aug 2003 11:18:35 -0400 Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory In-Reply-To: References: Message-ID: <3F4CCBCB.6000706@quadrix.com> Lee Howard wrote: > On Fri, 22 Aug 2003, Charles Scott wrote: > > >>Date: Fri, 22 Aug 2003 14:27:38 -0400 (EDT) >>From: Charles Scott >>To: "Azinger, Marla" >>Cc: 'Mury' , Member Services , >> ppml at arin.net >>Subject: RE: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS >> Di rectory >> >>On Fri, 22 Aug 2003, Azinger, Marla wrote: >> >> >>>2. If we dont include the name of the company that is actually "using" an >>>IP block such as one of my End User's than I dont see much use of the whole >>>WHOIS database. >> >> The corollary to which is... If we don't have valid contact data and >>some chain of responsibility then I don't see much use of the whole WHOIS >>database. (other than as a source of addresses to spam) >> I'd rather have less data that's valid than more data that's useless. >> >>Chuck > > > To what extent are the following statements true? > > WHOIS without naming the end user is not much use. > Not true at all. As long as *someone* in the upline for that block is listed, and that organization's info and contacts are kept up to date, then you can reasonably assume that it is possible for that organization to, sooner or later, figure out who the end user is. That, at least, is the beginnings of accountability. Is it enough? No. But it is far better than a totally anonymous Internet! (And, mind you, I am a strong proponent of privacy!) > End user information without contact information, as currently allowed > as reassign-simple, is not much use. > Also not true at all! If the information is current, you now know who is responsible. There are plenty of mechanisms for tracking down the correct contacts, not the least of which is contacting their ISPs from whom they received their blocks. > Except for spammer address-harvesting and showing utilization to ARIN, > WHOIS is not much use. > Also, not true at all. Despite the existance of substantial amounts of garbage, there is a lot of useful info there. Most of the larger ISPs, and I'd venture to guess probably most of ARIN's direct customers, have accurate information in WHOIS. That certainly gives you a place to start. BTW -- I have found that, while I get substantial amounts of spam from my NetSol WHOIS contacts, I get virtually none from my ARIN contacts. Perhaps this problem has not become as big as it has been portrayed? Now that I've answered these questions, I'd just like to add that I believe that having correct info for ARIN's direct customers is absolutely critical; that having correct info for allocations to other ISPs is important, saves time and is highly desirable; and that having correct end user information is desirable, but I don't think there is enough reason to force contact information to be included in that info. Why shouldn't I, as my customers' ISP, be able to handle all issues relating to their Internet access, including being the listed contact? If I take responsibility to manage that communication and involve the customer as appropriate, I should be allowed to do so! It seems to me that this issue does not have to be extremely complex. In fact, the only thing that is critically wrong here is that there is no enforcement of the requirement to maintain accurate information in the WHOIS database. Data integrity should be the primary goal, and I believe it simply will not be achieved without some kind of enforcement. The question is, how do we provide for that enforcement capability? -- -- Bill Van Emburg Quadrix Solutions, Inc. From mury at goldengate.net Wed Aug 27 14:16:58 2003 From: mury at goldengate.net (Mury) Date: Wed, 27 Aug 2003 13:16:58 -0500 (CDT) Subject: [ppml] Spamming off of this list In-Reply-To: Message-ID: It's spam. It's not an autoresponder. It is intentional. It is unsolicited. He points out that he's emailing me because of my concerns regarding IP management policies and assignments. I challenge someone to find a recent post where I expressed concern of how to manage my IPs. And even if I did post something like that it's still SPAM. Now if I were to post something that said please contact me off list if you have a product to suite my needs, then that's solicited and IMHO ok. One more thing. While it's normally fine for someone at an ISP to receive a 1.7M attachment there are times when I'm traveling at receiving close to 2M of unwanted images is not cool. His email follows. Mury Date: Tue, 26 Aug 2003 13:58:45 -0700 From: "Hall, Brian" To: "'mury at goldengate.net'" Subject: Re: IP management Parts/Attachments: 1.1 OK 24 lines Text (charset: ISO-8859-1) 1.2 Shown ~46 lines Text (charset: ISO-8859-1) 2 OK 1.2 MB Image ---------------------------------------- [ The following text is in the "iso-8859-1" character set. ] [ Your display is set for the "US-ASCII" character set. ] [ Some characters may be displayed incorrectly. ] Based on your stated concerns with IP management policies and assignments, you may be interested in our Address Commander product. For more information, please visit: www.incognito.com. Incognito Software develops IP management, DHCP and DNS solutions. You may also be interested in this article on IP management in the August 2003 issued of CED magazine, which conveys Incognito's view of an effective IP management solution (www.cedmagazine.com/ced/2003/0803/08d.htm). A graphical view of Address Commander functionality is provided below. Please do not hesitate to contact me if you have any questions. Thank you for your time. Cheers, Brian Hall | Product Manager Incognito Software Inc. T: 604.688.4332 x111 | F: 604.688-4339 <> [ Part 2, Image/BMP 1.6MB. ] [ Not Shown. Use the "V" command to view or save this part. ] On Tue, 26 Aug 2003, Joe Baptista wrote: > is he spamming or are you getting an autoresponder. it may not be > intentional. > > Joe Baptista - only at www.baptista.god > > another useless fact .... > The simple act of walking requires the use of 200 muscles in the > human body. > > On Tue, 26 Aug 2003, Mury wrote: > > > > > I'd like to ask that this person be removed from this mailing list for > > spamming to list members. Does ARIN have guidelines in place that forbids > > this pathetic practice? > > > > bhall at incognito.com > > Brian Hall | Product Manager > > Incognito Software Inc. > > T: 604.688.4332 x111 | F: 604.688-4339 > > > > Thank you. > > > > Mury > > > > > From mury at goldengate.net Wed Aug 27 14:21:36 2003 From: mury at goldengate.net (Mury) Date: Wed, 27 Aug 2003 13:21:36 -0500 (CDT) Subject: [ppml] Spamming off of this list In-Reply-To: Message-ID: Where is this post?! Am I losing it. As far as I know I've only made one comment since May 6th and that was regarding [ppml] Policy Proposal 2003-11: I figured since I received the alleged SPAM and as far as I remember I didn't post anything on that topic everyone was receiving the spam. So if it's a case that my memory sucks that bad, or this guy accidentally included me, then all is forgiven. Mury On Tue, 26 Aug 2003 jlewis at lewis.org wrote: > On Tue, 26 Aug 2003, Mury wrote: > > > > > I'd like to ask that this person be removed from this mailing list for > > spamming to list members. Does ARIN have guidelines in place that forbids > > this pathetic practice? > > > > bhall at incognito.com > > Brian Hall | Product Manager > > Incognito Software Inc. > > T: 604.688.4332 x111 | F: 604.688-4339 > > Is it really spam if you post in a thread on a mailing list and someone > responds privately saying they have a product related to your post that > you might be interested in? I'm not so sure I'd call it spam. > > The 1.2mb bmp attachment (making the message 1.7mb) was somewhat > irresponsible/cluefree. bmp isn't what I'd call a common or appropriate > format. I converted it to a 65kb jpeg with cjpeg and no options in order > to see WTH it was. > > ---------------------------------------------------------------------- > Jon Lewis *jlewis at lewis.org*| I route > System Administrator | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > From mury at goldengate.net Wed Aug 27 14:36:53 2003 From: mury at goldengate.net (Mury) Date: Wed, 27 Aug 2003 13:36:53 -0500 (CDT) Subject: [ppml] Spamming off of this list In-Reply-To: <20030827023044.GA60861@ussenterprise.ufp.org> Message-ID: So I wasn't the only one. Two other people emailed me privately to say they had received it and considered it spam. In addition, the spammer is a liar... or extrememly ignorant. He has since emailed me again spouting a bunch of BS. Yes, he is apparantly trying to politely back peddle, but in reality he's lying about how he got the list and why he sent the message. Instead of lying and defending himself, he should have said "I was wrong and I'm sorry." So for those that questioned it, yes it was spam. So back to my question, does ARIN have a mailing list policy regarding this? Can this person be removed from the mailing list? Hell, their IPs should be revoked if it happens a 2nd time. His followup letter follows. Mury Date: Tue, 26 Aug 2003 14:38:25 -0700 From: "Hall, Brian" To: 'Mury' Subject: RE: [ppml] Spamming off of this list Parts/Attachments: 1 OK 36 lines Text (charset: ISO-8859-1) 2 Shown ~66 lines Text (charset: ISO-8859-1) ---------------------------------------- [ The following text is in the "iso-8859-1" character set. ] [ Your display is set for the "US-ASCII" character set. ] [ Some characters may be displayed incorrectly. ] Mury, I did not spam, certainly not by any definition I've ever heard used. I did send extremely brief message, individually, to several people (less than 10 total) who actively expressed interest in a means of automating the IP management and IP assignment functions. That said, I apologize for any incovenience. You will not receive anything more unless you explicitly request it. Cheers, Brian On Tue, 26 Aug 2003, Leo Bicknell wrote: > In a message written on Tue, Aug 26, 2003 at 06:15:14PM -0400, jlewis at lewis.org wrote: > > > bhall at incognito.com > > > Brian Hall | Product Manager > > > Incognito Software Inc. > > > T: 604.688.4332 x111 | F: 604.688-4339 > > > > Is it really spam if you post in a thread on a mailing list and someone > > responds privately saying they have a product related to your post that > > you might be interested in? I'm not so sure I'd call it spam. > > I received one of these, of note: > > * The message had no "References" header, or any other indication > it was a "reply" other than "Re:" in the subject line. > > * My sent-mail archive indicates I've never sent a message to the > list with the subject Mr Hall's message indicated "Re: IP > management". > > Given the lack of anything to indicate it was a reply, I'd say he > harvested addresses, and sent out a message thinly disguised as a > reply. That is spam. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org > From cscott at gaslightmedia.com Wed Aug 27 14:46:16 2003 From: cscott at gaslightmedia.com (Charles Scott) Date: Wed, 27 Aug 2003 14:46:16 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory In-Reply-To: Message-ID: On Wed, 27 Aug 2003, Lee Howard wrote: > To what extent are the following statements true? > > WHOIS without naming the end user is not much use. Since you asked... I don't agree with this. While others may want data all the way to the end user, all I care about is if there's someone I can contact who's going to take responsibility for some issue. I've spent too much time trying to contact and get response from end-user contact addresses and phone numbers and 2nd/3rd tier providers using ARIN whois data. If there is a desire to maintain data down to the end-user level, I'd prefer to at least know if the contact data is valid. > End user information without contact information, as currently allowed > as reassign-simple, is not much use. At least if the end-user was there but had no contact information I wouldn't waste time trying to contact them. Perhaps there's a compromise in this. If (1) whois data for top level allocations is mandatory (2) contact data verification for top level allocations is mandatory, (3) contact data verification is optional for provider assignments and end users, (4) records required to have contact verification and records that have opted to have contact verification are clearly marked as being subject to verification, (5) a process periodically verifies all such records and clearly marks those that don't verify, and (6) there is an optional method to query only verified records, then I think we have the best of all worlds. I do like the concept of opting lower-level records into contact verification. With that, a provider who wants to can opt to insist that their customers have verification on their records as a condition of use and therefore offload most work associated with network issues for those assignments. Those who don't will of course be responsible themselves. The last component would potentially be some way of dealing with contacts that verify but are not responsive when contacted. If that happens to be a direct allocation from ARIN, then it would become an issue involving ARIN. If it's an assignment or end-user, then the next higher verified contact would be the one involved. > Except for spammer address-harvesting and showing utilization to ARIN, > WHOIS is not much use. I'm sure you asked this rhetorically. The Internet would be a pretty useless place without some ability to contact network operators. Clearly, accountability is important, if nowhere else but at the allocation level. Chuck From william at elan.net Wed Aug 27 11:58:43 2003 From: william at elan.net (william at elan.net) Date: Wed, 27 Aug 2003 08:58:43 -0700 (PDT) Subject: [ppml] Spamming off of this list In-Reply-To: Message-ID: I've received exactly same email from bhall at incognito.com as well and I also did not comment on ip database tools but on other issues. And ARIN does have policy for mailing lists, its at http://www.arin.net/policy/arin_mail_aup.html and it states: "Marketing of products or advertising of any kind, whether for business or employment purposes, is not allowed. Attempts to obtain email addresses for any purpose other than for which the list was designed is prohibited." So Brian definetly qualifies for removal (ARIN listmaster - where are you?) On Wed, 27 Aug 2003, Mury wrote: > > So I wasn't the only one. Two other people emailed me privately to say > they had received it and considered it spam. In addition, the spammer is > a liar... or extrememly ignorant. He has since emailed me again spouting > a bunch of BS. Yes, he is apparantly trying to politely back peddle, but > in reality he's lying about how he got the list and why he sent the > message. Instead of lying and defending himself, he should have said "I > was wrong and I'm sorry." > > So for those that questioned it, yes it was spam. So back to my question, > does ARIN have a mailing list policy regarding this? Can this person be > removed from the mailing list? Hell, their IPs should be revoked if it > happens a 2nd time. > > His followup letter follows. > > Mury > > > Date: Tue, 26 Aug 2003 14:38:25 -0700 > From: "Hall, Brian" > To: 'Mury' > Subject: RE: [ppml] Spamming off of this list > Parts/Attachments: > 1 OK 36 lines Text (charset: ISO-8859-1) > 2 Shown ~66 lines Text (charset: ISO-8859-1) > ---------------------------------------- > > [ The following text is in the "iso-8859-1" character set. ] > [ Your display is set for the "US-ASCII" character set. ] > [ Some characters may be displayed incorrectly. ] > > > Mury, > > I did not spam, certainly not by any definition I've ever heard used. > I did send extremely brief message, individually, to several people (less > than 10 total) who actively expressed interest in a means of automating > the IP management and IP assignment functions. > > That said, I apologize for any incovenience. > > You will not receive anything more unless you explicitly request it. > > Cheers, > > Brian > > On Tue, 26 Aug 2003, Leo Bicknell wrote: > > > In a message written on Tue, Aug 26, 2003 at 06:15:14PM -0400, jlewis at lewis.org wrote: > > > > bhall at incognito.com > > > > Brian Hall | Product Manager > > > > Incognito Software Inc. > > > > T: 604.688.4332 x111 | F: 604.688-4339 > > > > > > Is it really spam if you post in a thread on a mailing list and someone > > > responds privately saying they have a product related to your post that > > > you might be interested in? I'm not so sure I'd call it spam. > > > > I received one of these, of note: > > > > * The message had no "References" header, or any other indication > > it was a "reply" other than "Re:" in the subject line. > > > > * My sent-mail archive indicates I've never sent a message to the > > list with the subject Mr Hall's message indicated "Re: IP > > management". > > > > Given the lack of anything to indicate it was a reply, I'd say he > > harvested addresses, and sent out a message thinly disguised as a > > reply. That is spam. > > > > -- > > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > > PGP keys at http://www.ufp.org/~bicknell/ > > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org > > From mury at goldengate.net Wed Aug 27 15:02:12 2003 From: mury at goldengate.net (Mury) Date: Wed, 27 Aug 2003 14:02:12 -0500 (CDT) Subject: [ppml] Spamming off of this list (fwd) Message-ID: Despite saying he will never email me again, here's his 3rd email. Of course he paints me as the screwed up one. Ya, I go overboard on this stuff, because even with using Postini to filter email, spam still wastes 5 hours a week of my time. Anyone that knows the definition of vitriolic and can use it correctly in a sentence should know the definition of SPAM. Unfortunately knowledge does not always lead to wisdom. To the rest of you I'm sorry for wasting your time with this. The only reason I have continued posting to the list is because a few of you questioned me when I said he was spamming. I believe ARIN is in the process of removing him from the list. Mury ---------- Forwarded message ---------- Date: Wed, 27 Aug 2003 11:50:13 -0700 From: "Hall, Brian" To: 'Mury' Subject: RE: [ppml] Spamming off of this list Mury, I must say that I simply fail to see how my direct email message to you should lead to your vitriolic responses. As I read your posts to this group, it certainly appeared that issues related to ARIN reporting and contact information (and the corresponding need for archiving, tracking, etc)., at the very least, justified my assumption that you/your organization might be interested in a tool that would automate and streamline such efforts. Now, I have apologized for sending you the message. I have stated that you will not receive anything more unless you explicitly request it. Tying up the mailing list with your rants is simply counter-productive. Yours sincerely, Brian Hall -----Original Message----- From: Mury [mailto:mury at goldengate.net] Sent: Wednesday, August 27, 2003 11:37 AM To: ARIN Public Policy (E-mail) Subject: Re: [ppml] Spamming off of this list So I wasn't the only one. Two other people emailed me privately to say they had received it and considered it spam. In addition, the spammer is a liar... or extrememly ignorant. He has since emailed me again spouting a bunch of BS. Yes, he is apparantly trying to politely back peddle, but in reality he's lying about how he got the list and why he sent the message. Instead of lying and defending himself, he should have said "I was wrong and I'm sorry." So for those that questioned it, yes it was spam. So back to my question, does ARIN have a mailing list policy regarding this? Can this person be removed from the mailing list? Hell, their IPs should be revoked if it happens a 2nd time. His followup letter follows. Mury Date: Tue, 26 Aug 2003 14:38:25 -0700 From: "Hall, Brian" To: 'Mury' Subject: RE: [ppml] Spamming off of this list Parts/Attachments: 1 OK 36 lines Text (charset: ISO-8859-1) 2 Shown ~66 lines Text (charset: ISO-8859-1) ---------------------------------------- [ The following text is in the "iso-8859-1" character set. ] [ Your display is set for the "US-ASCII" character set. ] [ Some characters may be displayed incorrectly. ] Mury, I did not spam, certainly not by any definition I've ever heard used. I did send extremely brief message, individually, to several people (less than 10 total) who actively expressed interest in a means of automating the IP management and IP assignment functions. That said, I apologize for any incovenience. You will not receive anything more unless you explicitly request it. Cheers, Brian On Tue, 26 Aug 2003, Leo Bicknell wrote: > In a message written on Tue, Aug 26, 2003 at 06:15:14PM -0400, jlewis at lewis.org wrote: > > > bhall at incognito.com > > > Brian Hall | Product Manager > > > Incognito Software Inc. > > > T: 604.688.4332 x111 | F: 604.688-4339 > > > > Is it really spam if you post in a thread on a mailing list and someone > > responds privately saying they have a product related to your post that > > you might be interested in? I'm not so sure I'd call it spam. > > I received one of these, of note: > > * The message had no "References" header, or any other indication > it was a "reply" other than "Re:" in the subject line. > > * My sent-mail archive indicates I've never sent a message to the > list with the subject Mr Hall's message indicated "Re: IP > management". > > Given the lack of anything to indicate it was a reply, I'd say he > harvested addresses, and sent out a message thinly disguised as a > reply. That is spam. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org > From bhall at incognito.com Wed Aug 27 15:02:48 2003 From: bhall at incognito.com (Hall, Brian) Date: Wed, 27 Aug 2003 12:02:48 -0700 Subject: [ppml] Spamming off of this list Message-ID: I must say that if you post to a publicly accessible mailing list on such topics as archiving, auditing, utilization, reporting and/or administrative tasks associated with ARIN, there exists a potential that you may receive a direct email message from a person or person(s) that informs you of a solution that might make life better for you/your company. Certainly you will be hard pressed to make the case that it is spam. That said -- and so that we can return this last back to its purpose and move off the topic of spamming -- I wish to say that if anyone who may have received a message from me and they did not want to then you have my fullest apologies. No one on this list (now or in the future) will receive a message from me unless they explicitly request one. Yours sincerely Brian Hall -----Original Message----- From: Mury [mailto:mury at goldengate.net] Sent: Wednesday, August 27, 2003 11:37 AM To: ARIN Public Policy (E-mail) Subject: Re: [ppml] Spamming off of this list So I wasn't the only one. Two other people emailed me privately to say they had received it and considered it spam. In addition, the spammer is a liar... or extrememly ignorant. He has since emailed me again spouting a bunch of BS. Yes, he is apparantly trying to politely back peddle, but in reality he's lying about how he got the list and why he sent the message. Instead of lying and defending himself, he should have said "I was wrong and I'm sorry." So for those that questioned it, yes it was spam. So back to my question, does ARIN have a mailing list policy regarding this? Can this person be removed from the mailing list? Hell, their IPs should be revoked if it happens a 2nd time. His followup letter follows. Mury Date: Tue, 26 Aug 2003 14:38:25 -0700 From: "Hall, Brian" To: 'Mury' Subject: RE: [ppml] Spamming off of this list Parts/Attachments: 1 OK 36 lines Text (charset: ISO-8859-1) 2 Shown ~66 lines Text (charset: ISO-8859-1) ---------------------------------------- [ The following text is in the "iso-8859-1" character set. ] [ Your display is set for the "US-ASCII" character set. ] [ Some characters may be displayed incorrectly. ] Mury, I did not spam, certainly not by any definition I've ever heard used. I did send extremely brief message, individually, to several people (less than 10 total) who actively expressed interest in a means of automating the IP management and IP assignment functions. That said, I apologize for any incovenience. You will not receive anything more unless you explicitly request it. Cheers, Brian On Tue, 26 Aug 2003, Leo Bicknell wrote: > In a message written on Tue, Aug 26, 2003 at 06:15:14PM -0400, jlewis at lewis.org wrote: > > > bhall at incognito.com > > > Brian Hall | Product Manager > > > Incognito Software Inc. > > > T: 604.688.4332 x111 | F: 604.688-4339 > > > > Is it really spam if you post in a thread on a mailing list and someone > > responds privately saying they have a product related to your post that > > you might be interested in? I'm not so sure I'd call it spam. > > I received one of these, of note: > > * The message had no "References" header, or any other indication > it was a "reply" other than "Re:" in the subject line. > > * My sent-mail archive indicates I've never sent a message to the > list with the subject Mr Hall's message indicated "Re: IP > management". > > Given the lack of anything to indicate it was a reply, I'd say he > harvested addresses, and sent out a message thinly disguised as a > reply. That is spam. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From billd at cait.wustl.edu Wed Aug 27 15:11:38 2003 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 27 Aug 2003 14:11:38 -0500 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks Message-ID: <7D6FB5D2AE48D84983C354E50E83C2560363F1@kronos.cait.wustl.edu> > That said, feel free to review ARIN's numbers on how many they request > today. I'm quite sure 200 is way high, and aside from a > possible small > initial inrush has no chance of actually limiting things. > > > Why do you think there will be any growth? Short of the fraud issue > > mentioned above, all these /24's are already in the global > routing table. > > There will be short term growth, as both networks are announced as > people move from one to the other. I think there will also be long > term growth, as people who were unsure if they could properly > multihome with a non-portable /24 (eg, due to others filtering on > a /19-/20 boundry) begin to multihome with these new ARIN assigned > blocks. > > So yes, I see growth. Growth measured in fractions of a percent, or > maybe even the first digit or two in the extreme case...nothing that > will cause the net to come to a standstill. I always love these pronouncements, either within the AC or beyond,...... everyone has an opinion on what the outcomes of a lowering of minimum assignment policy will be....on route table size, demand for IP blocks of the minimum size, and filtering..... There is always a diversity of opinion and very little evidence to support the contentions. I simply hate making decisions with too little or no facts to rely on..... especially when experts within the same realm cannot agree. Fascinating..... Bill Darte ARIN Advisory Council > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org > From mjb at visi.com Wed Aug 27 15:24:00 2003 From: mjb at visi.com (Matt Baxter) Date: Wed, 27 Aug 2003 14:24:00 -0500 Subject: [ppml] Spamming off of this list In-Reply-To: References: Message-ID: <20030827192400.GA19115@visi.com> On Wed, Aug 27, 2003 at 12:02:48PM -0700, Hall, Brian wrote: > I must say that if you post to a publicly accessible mailing list on such > topics as archiving, auditing, utilization, reporting and/or administrative > tasks associated with ARIN, there exists a potential that you may receive a > direct email message from a person or person(s) that informs you of a > solution that might make life better for you/your company. Certainly you > will be hard pressed to make the case that it is spam. Not at all. In many a anti-spam discussion spam is defined as UCE/UBE. Unsolicited Bulk/Comericial Email. What Mury recieved was clearly UCE, and therefore spam. There ya go, case made, and I wasn't all that hard pressed to do so. Oh, and consider this my "opt-out". -- Matt Baxter mjb at visi.com From bicknell at ufp.org Wed Aug 27 16:03:25 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 27 Aug 2003 16:03:25 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks In-Reply-To: <7D6FB5D2AE48D84983C354E50E83C2560363F1@kronos.cait.wustl.edu> References: <7D6FB5D2AE48D84983C354E50E83C2560363F1@kronos.cait.wustl.edu> Message-ID: <20030827200325.GA94581@ussenterprise.ufp.org> In a message written on Wed, Aug 27, 2003 at 02:11:38PM -0500, Bill Darte wrote: > There is always a diversity of opinion and very little evidence to support > the contentions. > > I simply hate making decisions with too little or no facts to rely on..... > especially when experts within the same realm cannot agree. Unfortunately many of these things come down to predicting the future, and worse predicting the outcome of actions that have never really been tried before. Sadly, we're mostly stuck in a situation where trial and error is the best option, which is often very hard for an engineer to accept. :) -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org From william at elan.net Wed Aug 27 13:17:00 2003 From: william at elan.net (william at elan.net) Date: Wed, 27 Aug 2003 10:17:00 -0700 (PDT) Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory In-Reply-To: Message-ID: On Wed, 27 Aug 2003 jlewis at lewis.org wrote: > > WHOIS without naming the end user is not much use. Its not always about end-user its about seeing who is responsible for this ip block and will respond in case of problems. But naming the end-user is also important, for example in situations when you're trying to find correlation between different ip blocks. > > End user information without contact information, as currently allowed > > as reassign-simple, is not much use. > > Without a clear name or contact info, whois could still tell you how large > an assignment covering a particular IP is. For abuse tracking, if you > receive spam from a few IPs in the same range, it's handy to be able to > see how large that range is, and apply policy to the entire range rather > than wait to be spammed from each IP in it. I completely agree with above statement. Plus would like to add that seeing name and if possible address in the ip block (at the very least city) can also tell a lot both for abuse as well as how the ips has devided network (which can be usefull for example for routing). > > Except for spammer address-harvesting and showing utilization to ARIN, > > WHOIS is not much use. This statement is just plain WRONG WRONG WRONG. Whois is very usefull tool for identifying ownership of the resources (past, present, claimed), identifying when and how resource was allocated (date are very important as well) and tying one resource to another. And on many occasions I was able to show that domains or ips below to the same company (or used by them) even when addresses or names were different, just by similarities of how records were created and by multiple references from one resource to another. That whois is used for harvesting emails is unfortunete and that is why we need WHOIS AUP (see my proposal 2003-9) however ARIN whois is in fact primarily used for various types of reports about abuse from and other uses include trying to locate proper person in the NOC (sometimes its urgent - for example hacking incident), trying to verify ownership of ip block by upstream ISPS, etc. For majority of when ARIN whois data is used, having it accurate and having POCs present is very important, so we should definetly have a policy that defines in more detail ARIN procedures in cases of reports of incorrect data as well as info for those listed to make sure they understand that they MUST have valid information for others to be able to contact them. Having said the above, I can not really support 2003-11 as it is written right now. I actually liked ideas presented by Andrew Dul (as part of what AC has been working on, see http://www.arin.net/mailing_lists/ppml/1807.html) I think it would be in the best interest of everybody if AC instead of again trying to do it in private, actually presented their proposal right now and we could all work out best combination of 2003-11 and that proposal and come up with something acceptable to the majority of those interested in policy about validation of data in whois database. -- William Leibzon (a really big fan of whois :) william at elan.net From ibaker at codecutters.org Wed Aug 27 16:45:08 2003 From: ibaker at codecutters.org (Ian Baker) Date: Wed, 27 Aug 2003 21:45:08 +0100 Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory References: Message-ID: <005d01c36cdc$1cbe8a00$642fa8c0@codecutters.org> ----- Original Message ----- From: "Charles Scott" To: "Lee Howard" Cc: ; "Member Services" Sent: Wednesday, August 27, 2003 7:46 PM Subject: RE: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory > > > On Wed, 27 Aug 2003, Lee Howard wrote: > > > To what extent are the following statements true? > > > > WHOIS without naming the end user is not much use. > > Since you asked... I don't agree with this. While others may want data > all the way to the end user, all I care about is if there's someone I can > contact who's going to take responsibility for some issue. I've spent too > much time trying to contact and get response from end-user contact > addresses and phone numbers and 2nd/3rd tier providers using ARIN whois > data. If there is a desire to maintain data down to the end-user level, > I'd prefer to at least know if the contact data is valid. I agree and disagree (there, that's clear, then!). Personally, I would find end-user information useful, but agree that a lack of valid contacts hurts when (e.g.) reporting abuse. How about a combination - the end user is listed, allowing those who wish to find then to do so, but a pointer is added to the owning organization? From my examination of bulk WHOIS, this appears to be how the data is arranged and should therefore be relatively easy and safe to implement. > > End user information without contact information, as currently allowed > > as reassign-simple, is not much use. > > At least if the end-user was there but had no contact information I > wouldn't waste time trying to contact them. > Perhaps there's a compromise in this. If (1) whois data for top level > allocations is mandatory (2) contact data verification for top level > allocations is mandatory, (3) contact data verification is optional for > provider assignments and end users, (4) records required to have contact > verification and records that have opted to have contact verification are > clearly marked as being subject to verification, (5) a process > periodically verifies all such records and clearly marks those that don't > verify, and (6) there is an optional method to query only verified > records, then I think we have the best of all worlds. That's similar thinking, but I'm wondering if that's too rigid a regime - more implementation than policy. Make points 5) and 6) a recommendation and we're in full agreement. > I do like the concept of opting lower-level records into contact > verification. With that, a provider who wants to can opt to insist that > their customers have verification on their records as a condition of use > and therefore offload most work associated with network issues for those > assignments. Those who don't will of course be responsible themselves. > The last component would potentially be some way of dealing with > contacts that verify but are not responsive when contacted. If that > happens to be a direct allocation from ARIN, then it would become an > issue involving ARIN. If it's an assignment or end-user, then the next > higher verified contact would be the one involved. Agreed. > > Except for spammer address-harvesting and showing utilization to ARIN, > > WHOIS is not much use. > > I'm sure you asked this rhetorically. The Internet would be a pretty > useless place without some ability to contact network operators. Clearly, > accountability is important, if nowhere else but at the allocation level. Agreed, but some of us find the geographical data useful (just to declare one of my own interests, in addition to anti-abuse measures) Regards, Ian From cscott at gaslightmedia.com Wed Aug 27 17:54:20 2003 From: cscott at gaslightmedia.com (Charles Scott) Date: Wed, 27 Aug 2003 17:54:20 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory In-Reply-To: <005d01c36cdc$1cbe8a00$642fa8c0@codecutters.org> Message-ID: Ian: Not sure what you mean by making 5) and 6) a reccomendation. If you mean that verification should be optional for direct ARIN allocations, then I'm not sure what good the rest of it is. Perhaps I missed your point. I don't see item 6) as such a big deal, just thought it would be nice to opt to see only verified reccords if you wanted to. Simply a search option. As for rigid, I think verification is important to the proposal and to serving a main purpose of the whois database. Much of the rest of my points are intended to make it less rigid in that it still permits unverified contact data for assignments and end-user reccords, still permits access to the full amount of data if people want to use unverified contact data, permits people to lessen their workload in one of two ways (by either not doing the assignment reccords or by possibly avoiding handling the calls if their verified). Chuck On Wed, 27 Aug 2003, Ian Baker wrote: > > Perhaps there's a compromise in this. If (1) whois data for top level > > allocations is mandatory (2) contact data verification for top level > > allocations is mandatory, (3) contact data verification is optional for > > provider assignments and end users, (4) records required to have contact > > verification and records that have opted to have contact verification are > > clearly marked as being subject to verification, (5) a process > > periodically verifies all such records and clearly marks those that don't > > verify, and (6) there is an optional method to query only verified > > records, then I think we have the best of all worlds. > > That's similar thinking, but I'm wondering if that's too rigid a regime - > more implementation than policy. > > Make points 5) and 6) a recommendation and we're in full agreement. From ibaker at codecutters.org Wed Aug 27 19:27:35 2003 From: ibaker at codecutters.org (Ian Baker) Date: Thu, 28 Aug 2003 00:27:35 +0100 Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory References: Message-ID: <00bb01c36cf2$cea919e0$642fa8c0@codecutters.org> ----- Original Message ----- From: "Charles Scott" To: "Ian Baker" Cc: Sent: Wednesday, August 27, 2003 10:54 PM Subject: Re: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory > > Ian: > Not sure what you mean by making 5) and 6) a reccomendation. If you mean > that verification should be optional for direct ARIN allocations, then I'm > not sure what good the rest of it is. Perhaps I missed your point. > I don't see item 6) as such a big deal, just thought it would be nice to > opt to see only verified reccords if you wanted to. Simply a search > option. > As for rigid, I think verification is important to the proposal and to > serving a main purpose of the whois database. Much of the rest of my > points are intended to make it less rigid in that it still permits > unverified contact data for assignments and end-user reccords, still > permits access to the full amount of data if people want to use unverified > contact data, permits people to lessen their workload in one of two ways > (by either not doing the assignment reccords or by possibly avoiding > handling the calls if their verified). Chuck, I was thinking simply that mandating end-user records could be quite a mammoth task, and one that could stall the other, very worthy, points. I haven't run the latest bulk data through the scanner yet, but (from a dim memory) I think this would be on the order of a million organizations to contact and correlate. A "click on the link" type of response /might/ work, but I suspect that many people would just mentally filter it as yet-another-spam. Manual replies would take some processing and, I suspect, a fair degree of manual intervention. Just thinking practicalities, really - I'd like to see mandatory verification for the larger allocations, and "verification of end-user contact details, where possible". As goes filtering - I see your point, but would suggest a simple "last verified" date field, and filters for (e.g.) "verified witing the last three months", "verified in the last six months", and so on. I'm not familiar enough with the actual systems in-use to know how much development effort that would entail, and the possible impact on hardware sizing. Regards, Ian > On Wed, 27 Aug 2003, Ian Baker wrote: > > > > Perhaps there's a compromise in this. If (1) whois data for top level > > > allocations is mandatory (2) contact data verification for top level > > > allocations is mandatory, (3) contact data verification is optional for > > > provider assignments and end users, (4) records required to have contact > > > verification and records that have opted to have contact verification are > > > clearly marked as being subject to verification, (5) a process > > > periodically verifies all such records and clearly marks those that don't > > > verify, and (6) there is an optional method to query only verified > > > records, then I think we have the best of all worlds. > > > > That's similar thinking, but I'm wondering if that's too rigid a regime - > > more implementation than policy. > > > > Make points 5) and 6) a recommendation and we're in full agreement. > > From cscott at gaslightmedia.com Thu Aug 28 08:10:26 2003 From: cscott at gaslightmedia.com (Charles Scott) Date: Thu, 28 Aug 2003 08:10:26 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory In-Reply-To: <00bb01c36cf2$cea919e0$642fa8c0@codecutters.org> Message-ID: On Thu, 28 Aug 2003, Ian Baker wrote: > Chuck, > I was thinking simply that mandating end-user records could be quite a > mammoth task, and one that could stall the other, very worthy, points. > > I haven't run the latest bulk data through the scanner yet, but (from a dim > memory) I think this would be on the order of a million organizations to > contact and correlate. A "click on the link" type of response /might/ work, > but I suspect that many people would just mentally filter it as > yet-another-spam. > > Manual replies would take some processing and, I suspect, a fair degree of > manual intervention. Ian: Of course I was not suggesting that end-user records be mandated nor necessarilly verified. I was suggesting that a particular provider might want to require their own customers to have verified reccords as part of their policy. I would think that an automatic E-Mail to the listed contact for each reccord that needs to be verified and some means to automatically reply would not be too much of a burdon on ARIN. My only concern is that there be some way that whomever receives the E-Mail can verify that they are the correct person/entity in case the mail ends up with someone else. I like the web based verify link in the message, but wonder if there's an easy piece of information that could be entered into a field on that page that would verify the person responding. Perhaps even just the contact handle would select out most bogus responses. Thinking about manual intervention, for provider assignments that opted into verification and don't verify, a message could be sent to their provider and the reccord marked as unverified. Only direct ARIN allocations that don't verify would require some action by ARIN, thus minimizing the load on ARIN. Chuck From ibaker at codecutters.org Thu Aug 28 09:58:42 2003 From: ibaker at codecutters.org (Ian Baker) Date: Thu, 28 Aug 2003 14:58:42 +0100 Subject: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory References: Message-ID: <005301c36d6c$80b8dc00$642fa8c0@codecutters.org> ----- Original Message ----- From: "Charles Scott" To: "Ian Baker" Cc: Sent: Thursday, August 28, 2003 1:10 PM Subject: Re: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory > On Thu, 28 Aug 2003, Ian Baker wrote: > > > Chuck, > > I was thinking simply that mandating end-user records could be quite a > > mammoth task, and one that could stall the other, very worthy, points. > > > > I haven't run the latest bulk data through the scanner yet, but (from a dim > > memory) I think this would be on the order of a million organizations to > > contact and correlate. A "click on the link" type of response /might/ work, > > but I suspect that many people would just mentally filter it as > > yet-another-spam. > > > > Manual replies would take some processing and, I suspect, a fair degree of > > manual intervention. > > Ian: > Of course I was not suggesting that end-user records be mandated nor > necessarilly verified. I was suggesting that a particular provider might > want to require their own customers to have verified reccords as part of > their policy. > I would think that an automatic E-Mail to the listed contact for each > reccord that needs to be verified and some means to automatically reply > would not be too much of a burdon on ARIN. My only concern is that > there be some way that whomever receives the E-Mail can verify that they > are the correct person/entity in case the mail ends up with someone else. > I like the web based verify link in the message, but wonder if there's an > easy piece of information that could be entered into a field on that page > that would verify the person responding. Perhaps even just the contact > handle would select out most bogus responses. > Thinking about manual intervention, for provider assignments that opted > into verification and don't verify, a message could be sent to their > provider and the reccord marked as unverified. Only direct ARIN > allocations that don't verify would require some action by ARIN, thus > minimizing the load on ARIN. Chuck, That's my view too (maybe I was being too judgemental about the wording!) Generating a token for use in a URL is fairly straightforward (and hopefully uses something not easily publicly available, such as a combination of contact email and ARIN organization code. This approach seems to be fairly common, both in mailing lists, and, IIRC, Verisign (who do something similar with their WHOIS reminders). OTOH, I've no way of knowing the "hit rate" - most such messages that I receive are spam, so there may be a credibility problem once one drops below the professional techies and into end-users that may have bought-in expertise. Regards, Ian From jsw at five-elements.com Thu Aug 28 13:21:41 2003 From: jsw at five-elements.com (Jeff S Wheeler) Date: 28 Aug 2003 13:21:41 -0400 Subject: [ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks In-Reply-To: <20030827200325.GA94581@ussenterprise.ufp.org> References: <7D6FB5D2AE48D84983C354E50E83C2560363F1@kronos.cait.wustl.edu> <20030827200325.GA94581@ussenterprise.ufp.org> Message-ID: <1062091301.6160.3.camel@intrepid.jsw.louisville.ky.us> On Wed, 2003-08-27 at 16:03, Leo Bicknell wrote: > In a message written on Wed, Aug 27, 2003 at 02:11:38PM -0500, Bill Darte wrote: > > There is always a diversity of opinion and very little evidence to support > > the contentions. > > > > I simply hate making decisions with too little or no facts to rely on..... > > especially when experts within the same realm cannot agree. > > Unfortunately many of these things come down to predicting the > future, and worse predicting the outcome of actions that have never > really been tried before. Sadly, we're mostly stuck in a situation > where trial and error is the best option, which is often very hard > for an engineer to accept. :) I'm sure you've followed the entire thread closely, Bill, and while I can understand your concerns that micro-assignment policy may spur new route table growth and perhaps even hasten address space exhaustion, I believe Leo's excellent suggestion to "rate-limit" micro-assignments will limit the global bgp-speaking community's exposure. You didn't seem to address this in your follow-up post, but I would like to hear your thoughts on the feasability of the "rate-limit" mechanism by the ARIN. I am confident that more route table growth will still be produced by irresponsible deaggregation than from any other source. I'm sure you can agree that a successful multi-homer micro-assignment policy, with a clear growth path into the traditional ARIN addressing policies, can reduce the number of advertised routes for non-contigious space, due to growth assignments from ISPs with conservative allocation policies. I further suggest that if the ARIN chooses to assign these blocks only within a documented /10 (or similarly-sized chunk of space which can be easily added to prefix-lists) and does not carve /24s out of it, ISPs can aggressively filter the micro-assignment space; making certain that recipients do not cause undue table growth through poor configuration. -- Jeff S Wheeler P.S. I sure wish the mailing list set a Reply-To: header. From stormpunk at www.stormpunk.com Thu Aug 28 18:28:22 2003 From: stormpunk at www.stormpunk.com (stormpunk) Date: Thu, 28 Aug 2003 16:28:22 -0600 Subject: [ppml] Spamming off of this list Message-ID: <200308282228.h7SMSMg11486@www.stormpunk.com>