From memsvcs at arin.net Thu Mar 4 16:53:41 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 4 Mar 2004 16:53:41 -0500 (EST) Subject: [ppml] AC Initial Review: Purpose and scope of ARIN Whois directory Message-ID: <200403042153.QAA01854@ops.arin.net> This message contains the ARIN Advisory Council's finding regarding the initial 10-day review of proposed policy, "Purpose and scope of ARIN Whois directory". During the initial review period the AC has to decide whether a proposed policy merits further discussion or if it should be closed. The AC has three options, the AC can: 1) support moving the proposed policy (as is) forward in the evaluation process. 2) reach an agreement with the author to work together on the proposed policy and to move it forward in the evaluation process. 3) decide not to support moving the proposed policy forward in the evaluation process. Policies that are moved forward in the evaluation process are formally numbered, posted online for discussion, and presented at ARIN's Public Policy Meeting. In the event that the Advisory Council and the author can not reach an agreement, or that the Advisory Council decides not to support the proposed policy, then the author may elect to use the petition process to advance their proposal. The following is a link to the ARIN Internet Resource Policy Evaluation Process; for petition details please refer to the section called "Petition Process": http://www.arin.net/policy/ipep.html Concerning the proposed policy, Purpose and scope of ARIN Whois directory by Michael Dillon, which was posted to PPML on 2/19/2004, the AC does not support moving the proposed policy forward in the evaluation process. The following quoted text is presented on the behalf of the ARIN AC: "It was the consensus of the Advisory Council that the need for this policy was not clear, as ARIN procedures already require whois data to be accurate. Furthermore, it seems that extending the whois directory to arbitrary organizations and requiring verification by the staff may expose ARIN to additional risks if inaccurate information is published anyway." As mentioned above the author may elect to use the petition process. The deadline for initiating a petition per the ARIN Internet Resource Policy Evaluation Process is 40 days prior to the meeting; the petition deadline for this meeting cycle is March 10, 2004. If the author chooses not to petition or the petition is unsuccessful then the proposed policy is closed. If a petition is successful, then the policy proposal will be numbered and posted prior to the 30 day deadline for the upcoming meeting. Member Services American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Thu Mar 4 16:55:46 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 4 Mar 2004 16:55:46 -0500 (EST) Subject: [ppml] AC Initial Review: Defining Utilization of IPv4 addresses Message-ID: <200403042155.QAA02053@ops.arin.net> This message contains the ARIN Advisory Council's finding regarding the initial 10-day review of proposed policy, "Defining Utilization of IPv4 addresses". During the initial review period the AC has to decide whether a proposed policy merits further discussion or if it should be closed. The AC has three options, the AC can: 1) support moving the proposed policy (as is) forward in the evaluation process. 2) reach an agreement with the author to work together on the proposed policy and to move it forward in the evaluation process. 3) decide not to support moving the proposed policy forward in the evaluation process. Policies that are moved forward in the evaluation process are formally numbered, posted online for discussion, and presented at ARIN's Public Policy Meeting. In the event that the Advisory Council and the author can not reach an agreement, or that the Advisory Council decides not to support the proposed policy, then the author may elect to use the petition process to advance their proposal. The following is a link to the ARIN Internet Resource Policy Evaluation Process; for petition details please refer to the section called "Petition Process": http://www.arin.net/policy/ipep.html Concerning the proposed policy, Defining Utilization of IPv4 addresses, which was posted to PPML on 2/19/2004, and noting that the AC is not making a statement of endorsement, the AC supports moving the proposed policy (as is) forward in the evaluation process. The next step is that the policy proposal will be numbered and posted prior to the 30 day deadline for the upcoming meeting. Member Services American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Thu Mar 4 16:55:20 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 4 Mar 2004 16:55:20 -0500 (EST) Subject: [ppml] AC Initial Review: Use of HD-Ratio for IPv4 Allocations Member Message-ID: <200403042155.QAA02004@ops.arin.net> This message contains the ARIN Advisory Council's finding regarding the initial 10-day review of proposed policy, " Use of HD-Ratio for IPv4 Allocations". During the initial review period the AC has to decide whether a proposed policy merits further discussion or if it should be closed. The AC has three options, the AC can: 1) support moving the proposed policy (as is) forward in the evaluation process. 2) reach an agreement with the author to work together on the proposed policy and to move it forward in the evaluation process. 3) decide not to support moving the proposed policy forward in the evaluation process. Policies that are moved forward in the evaluation process are formally numbered, posted online for discussion, and presented at ARIN's Public Policy Meeting. In the event that the Advisory Council and the author can not reach an agreement, or that the Advisory Council decides not to support the proposed policy, then the author may elect to use the petition process to advance their proposal. The following is a link to the ARIN Internet Resource Policy Evaluation Process; for petition details please refer to the section called "Petition Process": http://www.arin.net/policy/ipep.html Concerning the proposed policy, Use of HD-Ratio for IPv4 Allocations by Michael Dillon, which was posted to PPML on 2/19/2004, and noting that the AC is not making a statement of endorsement, the AC supports moving the proposed policy (as is) forward in the evaluation process. The next step is that the policy proposal will be numbered and posted prior to the 30 day deadline for the upcoming meeting. Member Services American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Thu Mar 4 16:54:47 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 4 Mar 2004 16:54:47 -0500 (EST) Subject: [ppml] AC Initial Review: Connective Private Network Allocations Message-ID: <200403042154.QAA01959@ops.arin.net> This message contains the ARIN Advisory Council's finding regarding the initial 10-day review of proposed policy, "Connective Private Network Allocations". During the initial review period the AC has to decide whether a proposed policy merits further discussion or if it should be closed. The AC has three options, the AC can: 1) support moving the proposed policy (as is) forward in the evaluation process. 2) reach an agreement with the author to work together on the proposed policy and to move it forward in the evaluation process. 3) decide not to support moving the proposed policy forward in the evaluation process. Policies that are moved forward in the evaluation process are formally numbered, posted online for discussion, and presented at ARIN's Public Policy Meeting. In the event that the Advisory Council and the author can not reach an agreement, or that the Advisory Council decides not to support the proposed policy, then the author may elect to use the petition process to advance their proposal. The following is a link to the ARIN Internet Resource Policy Evaluation Process; for petition details please refer to the section called "Petition Process": http://www.arin.net/policy/ipep.html Concerning the proposed policy, Connective Private Network Allocations by Marla Azinger, which was posted to PPML on 2/19/2004, and noting that the AC is not making a statement of endorsement, the AC has reached an agreement with the author to work together on this proposed policy and move it forward in the evaluation process. It is the intent of the AC that this proposed policy be combined with another, Unique Addresses for Private Interconnections by Bill Copeland, and that the AC and authors work together to create a single policy proposal which will be posted prior to the 30 day deadline for the upcoming meeting. Member Services American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Thu Mar 4 16:54:10 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 4 Mar 2004 16:54:10 -0500 (EST) Subject: [ppml] AC Initial Review: Unique Addresses for Private Interconnections Message-ID: <200403042154.QAA01904@ops.arin.net> This message contains the ARIN Advisory Council's finding regarding the initial 10-day review of proposed policy, "Unique Addresses for Private Interconnections". During the initial review period the AC has to decide whether a proposed policy merits further discussion or if it should be closed. The AC has three options, the AC can: 1) support moving the proposed policy (as is) forward in the evaluation process. 2) reach an agreement with the author to work together on the proposed policy and to move it forward in the evaluation process. 3) decide not to support moving the proposed policy forward in the evaluation process. Policies that are moved forward in the evaluation process are formally numbered, posted online for discussion, and presented at ARIN's Public Policy Meeting. In the event that the Advisory Council and the author can not reach an agreement, or that the Advisory Council decides not to support the proposed policy, then the author may elect to use the petition process to advance their proposal. The following is a link to the ARIN Internet Resource Policy Evaluation Process; for petition details please refer to the section called "Petition Process": http://www.arin.net/policy/ipep.html Concerning the proposed policy, Unique Addresses for Private Interconnections by Bill Copeland, which was posted to PPML on 2/19/2004, and noting that the AC is not making a statement of endorsement, the AC has reached an agreement with the author to work together on this proposed policy and move it forward in the evaluation process. It is the intent of the AC that this proposed policy be combined with another, Connective Private Network Allocations by Marla Azinger, and that the AC and authors work together to create a single policy proposal which will be posted prior to the 30 day deadline for the upcoming meeting. Member Services American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Mon Mar 8 18:29:58 2004 From: memsvcs at arin.net (Member Services) Date: Mon, 8 Mar 2004 18:29:58 -0500 (EST) Subject: [ppml] Last Call for Comment: Policy Proposal 2002-2 Message-ID: <200403082329.SAA05341@ops.arin.net> This is a last call for comments on this policy proposal. The Advisory Council will review the comments collected during this last call period. The AC determined that there was community support for this policy proposal. The proposal text was revised by the AC in response to comments received at the Public Policy Meeting. Please send your comments to ppml at arin.net. This last call will expire at 23:59 EST on March 22, 2004. Member Services American Registry for Internet Numbers (ARIN) ####################################### Policy Proposal 2002-2: Experimental Internet Resource Allocations There have been a number of experimental address allocations undertaken in the Internet over the past decade. These experimental address allocations have been made by the IANA in coordination with the IETF, on an ad hoc basis. There is currently no systematic means of receiving other Numbering Resources on a temporary basis as part of a recognized experiment in Internet technology deployment. The following policy is proposed: ARIN will allocate Numbering Resources to entities requiring temporary Numbering Resources for a fixed period of time under the terms of recognized experimental activity. "Numbering Resources" refers to unicast IPv4 or IPv6 address space and Autonomous System numbers. The following criteria for this policy are proposed: 1. Documentation of recognized experimental activity A Recognized Experimental Activity is one where the experiment's objectives and practices are described in a publicly accessible document. It is a normal requirement that a Recognized Experimental Activity also includes the undertaking that the experiment's outcomes be published in a publicly accessible document at the end of the experiment. The conditions for determining the end of the experiment are to be included in the document. Applicants for an experimental allocation are expected to demonstrate an understanding that when the experiment ends, the allocation will be returned; a successful experiment may need a new allocation under normal policies in order to continue in production or commercial use, but will not retain the experimental allocation. A "publicly accessible document" is a document that is publicly and openly available free of charges and free of any constraints of disclosure. ARIN will not recognize an experimental activity under this policy if the entire research experiment cannot be publicly disclosed. ARIN has a strong preference for the recognition of experimental activity documentation in the form of a document which has been approved for publication by the IESG or by a similar mechanism as implemented by the IETF. 2. Technical Coordination ARIN requires that a recognized experimental activity is able to demonstrate that the activity is technically coordinated. Technical coordination specifically includes consideration of any potential negative impact of the proposed experiment on the operation of the Internet and its deployed services, and consideration of any related experimental activity. ARIN will review planned experimental activities to ensure that they are technically coordinated. This review will be conducted with ARIN and/or third-party expertise and will include liaison with the IETF. 3. Coordination over Resource Use When the IETF's standards development process proposes a change in the use of Numbering Resources on an experimental basis the IETF should use a liaison mechanism with the Regional Internet Registries (RIRs) of this proposal. The RIRs will jointly or severally respond to the IETF using the same liaison mechanism. 4. Resource Allocation Term and Renewal The Numbering Resources are allocated on a lease/license basis for a period of one year. The allocation can be renewed on application to ARIN providing information as per Detail One. The identity and details of the applicant and the allocated Numbering Resources will be published under the conditions of ARIN's normal publication policy. At the end of the experiment, resources allocated under this policy will be returned to the available pool. 5. Single Resource Allocation per Experiment ARIN will make one-off allocations only, on an annual basis to any applicant. Additional allocations to an organization already holding experimental activity resources relating to the specified activity outside the annual cycle will not be made unless justified by a subsequent complete application. It's important for the requesting organization to ensure they have sufficient resources requested as part of their initial application for the proposed experimental use. 6. Resource Allocation Fees ARIN may charge an administration fee to cover each allocation made of these experimental resources. This fee simply covers registration and maintenance, rather than the full allocation process for standard ARIN members. This administration fee should be as low as possible as these requests do not have to undergo the same evaluation process as those requested in the normal policy environment. 7. Resource Allocation Size The Numbering Resources requested come from the global Internet Resource space, and are not from private or other non- routable Internet Resource space. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, their experimental documentation should have clearly described and justified why this is required. 8. Commercial Use Prohibited If there is any evidence that the temporary resource is being used for commercial purposes, or is being used for any activities not documented in the original experiment description provided to ARIN, ARIN reserves the right to immediately withdraw the resource and reassign it to the free pool. 9. Resource Request Appeal or Arbitration ARIN reserves the ability to assess and comment on the objectives of the experiment with regard to the requested amount of Numbering Resources and its technical coordination. ARIN reserves the ability to modify the requested allocation as appropriate, and in agreement with the proposer. In the event that the proposed modifications are not acceptable, the requesting organization may request an appeal or arbitration using the normal ARIN procedures. In this case, the original proposer of the experimental activity may be requested to provide additional information regarding the experiment, its objectives and the manner of technical coordination, to assist in the resolution of the appeal. From Michael.Dillon at radianz.com Wed Mar 10 10:04:43 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 10 Mar 2004 15:04:43 +0000 Subject: [ppml] Petition Request for Whois Proposal Message-ID: This is a formal petition to advance the policy proposal entitled "Purpose and Scope of ARIN Whois Directory". The full text of the proposal is posted on the ARIN website at this URL: http://www.arin.net/mailing_lists/ppml/2593.html According to the Internet Resource Policy Evaluation Process, people who wish to document their support for the petition must do the following within the next five (5) days: 1) post a response to the Public Policy Mailing List stating their support for the proposal, and 2) send email to petition at arin.net with full point of contact information, including their telephone number and organizational affiliation. The ARIN President will verify whether people from at least four different organizations support the petitioned policy proposal. If you have any questions about this process you may wish to refer to the ARIN website at http://www.arin.net/policy/ipep.html for the full text explaining the petition process. ------------------------------------------------------- Michael Dillon Capacity Management, 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From steve at blighty.com Wed Mar 10 10:31:42 2004 From: steve at blighty.com (Steve Atkins) Date: Wed, 10 Mar 2004 07:31:42 -0800 Subject: [ppml] Petition Request for Whois Proposal In-Reply-To: References: Message-ID: <20040310153142.GA31972@gp.word-to-the-wise.com> On Wed, Mar 10, 2004 at 03:04:43PM +0000, Michael.Dillon at radianz.com wrote: > This is a formal petition to advance the policy proposal entitled > "Purpose and Scope of ARIN Whois Directory". The full text of > the proposal is posted on the ARIN website at this URL: > http://www.arin.net/mailing_lists/ppml/2593.html > > According to the Internet Resource Policy Evaluation Process, people > who wish to document their support for the petition > must do the following within the next five (5) days: > > 1) post a response to the Public Policy Mailing List > stating their support for the proposal, and > 2) send email to petition at arin.net with full point of > contact information, including their telephone number > and organizational affiliation. I'd like to document my opposition to this proposal. It is already hard enough to investigate online fraud and other abuse without intentional removal of contact information for allocated address space. Those who would be responding to requests for information at the large providers are already horribly overworked, and this would be putting yet more burden on them. I can see some argument for private individuals not wanting, for example, their home addresses listed in the ARIN database. But it is easy for them to use a listed contact point that will accept legal service on their behalf. If ISPs want to take responsibility for the actions of all their customers there's nothing to stop them offering that service to their customers - so the ISP can be the contact point for legal service, if they should wish to offer that service. That seems a much better option for ISPs than being forced into that role by an ARIN policy change. Cheers, Steve From Michael.Dillon at radianz.com Wed Mar 10 11:18:05 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 10 Mar 2004 16:18:05 +0000 Subject: [ppml] Petition Request for Whois Proposal Message-ID: >I'd like to document my opposition to this proposal. It is already >hard enough to investigate online fraud and other abuse without >intentional removal of contact information for allocated address >space. You don't really need to do this here. This proposal needs to get 5 supporters to send email to petition at arin.net with full point of contact information, including their telephone number and organizational affiliation or it won't even be on the agenda for discussion. >Those who would be responding to requests for information at the large >providers are already horribly overworked, and this would be putting >yet more burden on them. I don't see how we put an increased burden on providers by updating the whois directory to only contain contact info that people guarantee to ARIN 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. Currently, the whois directory is filled with lots of blind alleys and contact information that simply is not useful in order to make contact with someone who can fix a problem. I want to make the whois directory smaller so that if you have an issue, you can forward it confidently to the whois contact and forget about it because it will be dealt with properly by a clueful recipient. In my opinion, that is the purpose of having a whois directory in the first place, not to facilitate cat'n'mouse games or telephone tag. Also, please remember that this policy refers to ARIN's whois directory of organizations who are using IP addresses. It has absolutely nothing to do with any other sort of whois directory such as the many domain name registries. --Michael Dillon From owen at delong.com Wed Mar 10 11:54:08 2004 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Mar 2004 08:54:08 -0800 Subject: [ppml] Petition Request for Whois Proposal In-Reply-To: References: Message-ID: <2147483647.1078908848@imac-en0.delong.sj.ca.us> I support this petition. While I don't often find myself in agreement with Michael, I do feel that there is work to be done on both the WHOIS AUP and the data validation process thereof. I don't necessarily think that the wording in this proposal is completely right yet, but, I think we should continue to work on it. Owen --On Wednesday, March 10, 2004 3:04 PM +0000 Michael.Dillon at radianz.com wrote: > This is a formal petition to advance the policy proposal entitled > "Purpose and Scope of ARIN Whois Directory". The full text of > the proposal is posted on the ARIN website at this URL: > http://www.arin.net/mailing_lists/ppml/2593.html > > According to the Internet Resource Policy Evaluation Process, people > who wish to document their support for the petition > must do the following within the next five (5) days: > > 1) post a response to the Public Policy Mailing List > stating their support for the proposal, and > 2) send email to petition at arin.net with full point of > contact information, including their telephone number > and organizational affiliation. > > The ARIN President will verify whether people from at > least four different organizations support the petitioned > policy proposal. > > If you have any questions about this process you may wish to refer > to the ARIN website at http://www.arin.net/policy/ipep.html for the > full text explaining the petition process. > > ------------------------------------------------------- > Michael Dillon > Capacity Management, 66 Prescot St., London, E1 8HG, UK > Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com > Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 > -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Wed Mar 10 11:57:32 2004 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Mar 2004 08:57:32 -0800 Subject: [ppml] Petition Request for Whois Proposal In-Reply-To: <20040310153142.GA31972@gp.word-to-the-wise.com> References: <20040310153142.GA31972@gp.word-to-the-wise.com> Message-ID: <2147483647.1078909052@imac-en0.delong.sj.ca.us> Your statements make more sense to me in the context of the already approved residential customer privacy policy. This policy doesn't remove information, except for one paragraph which I agree should be reworked. There should not be a statement that reassignments/suballocations would not be documented. I could live with MAY not, but, will not is a mistake. The end assignee should have the option of taking responsibility for the address space assigned to them. If they choose not to, the ISP should have the options of taking responsibility or not assigning. Just my $0.02. Owen --On Wednesday, March 10, 2004 7:31 AM -0800 Steve Atkins wrote: > On Wed, Mar 10, 2004 at 03:04:43PM +0000, Michael.Dillon at radianz.com > wrote: > >> This is a formal petition to advance the policy proposal entitled >> "Purpose and Scope of ARIN Whois Directory". The full text of >> the proposal is posted on the ARIN website at this URL: >> http://www.arin.net/mailing_lists/ppml/2593.html >> >> According to the Internet Resource Policy Evaluation Process, people >> who wish to document their support for the petition >> must do the following within the next five (5) days: >> >> 1) post a response to the Public Policy Mailing List >> stating their support for the proposal, and >> 2) send email to petition at arin.net with full point of >> contact information, including their telephone number >> and organizational affiliation. > > I'd like to document my opposition to this proposal. It is already > hard enough to investigate online fraud and other abuse without > intentional removal of contact information for allocated address > space. > > Those who would be responding to requests for information at the large > providers are already horribly overworked, and this would be putting > yet more burden on them. > > I can see some argument for private individuals not wanting, for example, > their home addresses listed in the ARIN database. But it is easy for > them to use a listed contact point that will accept legal service on > their behalf. > > If ISPs want to take responsibility for the actions of all their customers > there's nothing to stop them offering that service to their customers - > so the ISP can be the contact point for legal service, if they should > wish to offer that service. That seems a much better option for ISPs > than being forced into that role by an ARIN policy change. > > Cheers, > Steve > -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From steve at blighty.com Wed Mar 10 11:53:07 2004 From: steve at blighty.com (Steve Atkins) Date: Wed, 10 Mar 2004 08:53:07 -0800 Subject: [ppml] Petition Request for Whois Proposal In-Reply-To: References: Message-ID: <20040310165307.GA708@gp.word-to-the-wise.com> On Wed, Mar 10, 2004 at 04:18:05PM +0000, Michael.Dillon at radianz.com wrote: > >I'd like to document my opposition to this proposal. It is already > >hard enough to investigate online fraud and other abuse without > >intentional removal of contact information for allocated address > >space. > > You don't really need to do this here. This proposal needs to get > 5 supporters to send email to petition at arin.net with full point > of contact information, including their telephone number and > organizational affiliation or it won't even be on the agenda > for discussion. Yup, did that. I thought it polite to reply here as well, though. (Feel free to take it off-list if you want to go into more detail about the elements I see problems with.) I also thought it worthwhile to raise the issue that some legitimate (I believe) usage of ARIN data, while still being 'operational' usage in a broad sense, isn't about the physical infrastructure. > >Those who would be responding to requests for information at the large > >providers are already horribly overworked, and this would be putting > >yet more burden on them. > > I don't see how we put an increased burden on providers by > updating the whois directory to only contain contact > info that people guarantee to ARIN 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. If they were also to accept legal liability for the actions of their customers, or at least act as a true point of contact for legal service, then it wouldn't be something I'd see as big a problem with - mostly because it would be clear to the ISPs up-front the additional costs they would be incurring. > Currently, the whois directory is filled with lots of blind alleys > and contact information that simply is not useful in order to > make contact with someone who can fix a problem. Indeed. The fact that the data ARIN maintains is of variable quality is a problem. And, yes, something needs to change, and I can see the reasoning behind this proposal. A simplified way to identify the correct PoC for a specific category of operational issue would be a great thing. However, just to give one example, one lawyer I'm working with will be sending out upwards of a hundred cease and desist letters in the next week or so to addresses based, primarily, on ARIN data. If the contact information were purged from the ARIN database then the process would involved issuing subpoenas or search warrants to the provider in order for them to release the contact information for their customers. Ask any abuse desk how painful and time consuming responding to subpoenas is. Also a common goal when investigating online fraud and other 'abuse' issues is to identify which of hundreds of possibly related IP addresses are actually responsible for the behaviour and which are innocent third-parties (such as, say, the owner of a compromised machine that's being misused). ARIN data is of a lot of value in separating those groups - and that benefits everyone who isn't breaking the law, including those innocent third parties and their ISPs, by reducing everyones overheads, and eliminating them altogether in the case of the innocent third-parties. > I want to make the whois directory smaller so that if you > have an issue, you can forward it confidently to the whois > contact and forget about it because it will be dealt with > properly by a clueful recipient. In my opinion, that is the > purpose of having a whois directory in the first place, not > to facilitate cat'n'mouse games or telephone tag. You seem to have an expectation that the ISP will completely handle an issue, and manage any communication needed between the person operating the IP space and the person trying to notify them of a problem. That's putting a significant overhead on the ISP even in simple technical cases, let alone in complex, non-technical cases. Of course, any ISP who _chooses_ to act as a point of contact for some subset of their leased-line or colo customers can already do so by, amongst other ways, allowing their customers to list the ISP as their contact address. > Also, please remember that this policy refers to ARIN's whois > directory of organizations who are using IP addresses. It has > absolutely nothing to do with any other sort of whois directory > such as the many domain name registries. Yes, understood. Cheers, Steve From msalim at localweb.com Wed Mar 10 12:13:21 2004 From: msalim at localweb.com (A. Michael Salim) Date: Wed, 10 Mar 2004 12:13:21 -0500 (EST) Subject: [ppml] Petition Request for Whois Proposal In-Reply-To: Message-ID: Hi, > http://www.arin.net/mailing_lists/ppml/2593.html I took a quick look and on the face of it I am in full agreement and support. It is about time we started re-visiting the WHOIS mess. IMHO the existing WHOIS system, which is so readily accessible, is being misused by at least three groups of people: a) marketeers wishing to build mailing lists to spam or sell b) militant anti-spammers to harrass perceived end-contacts c) aggressive attorneys or legal representatives wishing to scare or brow-beat ISP's into disconnecting their client's enemies. This one particularly irks me and I have lost count of the number of times I have received baseless threats from "attorneys" because of some perceived or claimed infringement on the part of some client that we happen to host on our network. So much so that there are now precedents that say it is OK for them to do so! Mike Dillon, if you need additional supporters for your petition please let me know so that it gets on the agenda. best regards Mike Salim From william at elan.net Wed Mar 10 14:58:01 2004 From: william at elan.net (william(at)elan.net) Date: Wed, 10 Mar 2004 11:58:01 -0800 (PST) Subject: [ppml] Petition Request for Whois Proposal In-Reply-To: Message-ID: I support the petition. While I do not agree with the policy proposal as it stands right now, I do think its bad that AC has decided to abandon the effort for policy that could provide for better accuracy of ARIN whois database. On Wed, 10 Mar 2004 Michael.Dillon at radianz.com wrote: > This is a formal petition to advance the policy proposal entitled > "Purpose and Scope of ARIN Whois Directory". The full text of > the proposal is posted on the ARIN website at this URL: > http://www.arin.net/mailing_lists/ppml/2593.html > > According to the Internet Resource Policy Evaluation Process, people > who wish to document their support for the petition > must do the following within the next five (5) days: > > 1) post a response to the Public Policy Mailing List > stating their support for the proposal, and > 2) send email to petition at arin.net with full point of > contact information, including their telephone number > and organizational affiliation. > > The ARIN President will verify whether people from at > least four different organizations support the petitioned > policy proposal. > > If you have any questions about this process you may wish to refer > to the ARIN website at http://www.arin.net/policy/ipep.html for the > full text explaining the petition process. > > ------------------------------------------------------- > Michael Dillon > Capacity Management, 66 Prescot St., London, E1 8HG, UK > Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com > Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From ddiller at cogentco.com Wed Mar 10 18:02:40 2004 From: ddiller at cogentco.com (Dave Diller) Date: Wed, 10 Mar 2004 18:02:40 -0500 Subject: [ppml] 2001-2 Revisited Message-ID: <404F9E90.6020106@cogentco.com> For those not already way-too-intimitely familiar with it, here is the current text of 2001-2: --- This policy allows a downstream customer's multi-homing requirement to serve as justification for a /24 reassignment from their upstream ISP, regardless of host requirements. Downstream customers must provide contact information for all of their upstream providers to the ISP from whom they are requesting a /24. The ISP will then verify the customer's multi-homing requirement and may assign the customer a /24, based on this policy. Customers may receive a /24 from only one of their upstream providers under this policy without providing additional justification. --- Now, it pretty explicitly states one /24 *per customer* in total is all that is allowable. No ifs, ands, or buts about it. It appears to have been tailor-made for the law office with a justifiable /27 that wishes to multi-home, and it works well for that purpose. How are people handling it when they have *a* customer with separate, multihomed, geographically discrete offices? By the literal text of this policy, this is not sufficient justification to provide them with a /24 *per discrete site*. If the definition is commonly being stretched to include this - and I think it is reasonable to do so, given the spirit of the policy - then the policy should be amended to explicitly indicate that this is an acceptable caveat. -Dave Diller PacketMuriqui & IP Flinger From jamoore2 at vt.edu Wed Mar 10 19:56:39 2004 From: jamoore2 at vt.edu (James T. Moore) Date: Wed, 10 Mar 2004 19:56:39 -0500 Subject: [ppml] 2001-2 Revisited References: <404F9E90.6020106@cogentco.com> Message-ID: <026701c40703$b69486e0$0264a8c0@vmnet1.mogul.dyndns.org> I am getting ready to enter this situation from the customer point of view. Our plans are to assign part of our /24 to the new site and anounce the full /24 from both sites and route communication from one site to the other over IPsec tunnels. I don't see this as justifying the allocation of another /24, when the /24 is soley used to insure that the advertised routes are not filtered. J.T. Moore ----- Original Message ----- From: "Dave Diller" To: Sent: Wednesday, March 10, 2004 6:02 PM Subject: [ppml] 2001-2 Revisited > For those not already way-too-intimitely familiar with it, here is the current > text of 2001-2: > > --- > This policy allows a downstream customer's multi-homing requirement to serve as > justification for a /24 reassignment from their upstream ISP, regardless of > host requirements. Downstream customers must provide contact information for > all of their upstream providers to the ISP from whom they are requesting a /24. > The ISP will then verify the customer's multi-homing requirement and may assign > the customer a /24, based on this policy. Customers may receive a /24 from only > one of their upstream providers under this policy without providing additional > justification. > --- > > Now, it pretty explicitly states one /24 *per customer* in total is all that is > allowable. No ifs, ands, or buts about it. It appears to have been > tailor-made for the law office with a justifiable /27 that wishes to > multi-home, and it works well for that purpose. > > How are people handling it when they have *a* customer with separate, > multihomed, geographically discrete offices? By the literal text of this > policy, this is not sufficient justification to provide them with a /24 *per > discrete site*. If the definition is commonly being stretched to include this > - and I think it is reasonable to do so, given the spirit of the policy - then > the policy should be amended to explicitly indicate that this is an acceptable > caveat. > > -Dave Diller > PacketMuriqui & IP Flinger > From jsw at five-elements.com Wed Mar 10 21:03:00 2004 From: jsw at five-elements.com (Jeff S Wheeler) Date: Wed, 10 Mar 2004 21:03:00 -0500 Subject: [ppml] 2001-2 Revisited In-Reply-To: <026701c40703$b69486e0$0264a8c0@vmnet1.mogul.dyndns.org> References: <404F9E90.6020106@cogentco.com> <026701c40703$b69486e0$0264a8c0@vmnet1.mogul.dyndns.org> Message-ID: <1078970580.30114.234.camel@repulse.jsw.louisville.ky.us> On Wed, 2004-03-10 at 19:56, James T. Moore wrote: > I don't see this as justifying the allocation of another > /24, when the /24 is soley used to insure that the > advertised routes are not filtered. Depending on what /8 your /24 comes from, some networks will filter it anyway. Verio's policy, for example, is to only accept /22 or shorter from 128/2. -- jsw From tme at multicasttech.com Thu Mar 11 12:16:28 2004 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 11 Mar 2004 12:16:28 -0500 Subject: [ppml] 2001-2 Revisited In-Reply-To: <404F9E90.6020106@cogentco.com> Message-ID: How does this better than 2002-3, which was approved (albeit in amended form) ? The intent for 2002-3 was that you would get a /24 _from ARIN_, which IMHO is better than from your upstream. Now, it was changed to a /22, and I haven't submitted my proposal yet (so I don't know if it has ever been exercised), but given 2002-3, why do we need 2001-2 ? On Wednesday, March 10, 2004, at 06:02 PM, Dave Diller wrote: > For those not already way-too-intimitely familiar with it, here is the > current text of 2001-2: > > --- > This policy allows a downstream customer's multi-homing requirement to > serve as justification for a /24 reassignment from their upstream ISP, > regardless of host requirements. Downstream customers must provide > contact information for all of their upstream providers to the ISP > from whom they are requesting a /24. The ISP will then verify the > customer's multi-homing requirement and may assign the customer a /24, > based on this policy. Customers may receive a /24 from only one of > their upstream providers under this policy without providing > additional justification. > --- > > Now, it pretty explicitly states one /24 *per customer* in total is > all that is allowable. No ifs, ands, or buts about it. It appears to > have been tailor-made for the law office with a justifiable /27 that > wishes to multi-home, and it works well for that purpose. > > How are people handling it when they have *a* customer with separate, > multihomed, geographically discrete offices? By the literal text of > this policy, this is not sufficient justification to provide them with > a /24 *per discrete site*. If the definition is commonly being > stretched to include this - and I think it is reasonable to do so, > given the spirit of the policy - then the policy should be amended to > explicitly indicate that this is an acceptable caveat. > > -Dave Diller > PacketMuriqui & IP Flinger > > Regards Marshall Eubanks T.M. Eubanks e-mail : marshall.eubanks at telesuite.com http://www.telesuite.com From Michael.Dillon at radianz.com Thu Mar 11 12:31:54 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 11 Mar 2004 17:31:54 +0000 Subject: [ppml] Please respond to my petition Message-ID: Please respond to my petition to get the whois proposal on the agenda at the Vancouver policy meeting. The petition details are here http://www.arin.net/mailing_lists/ppml/2610.html and tell you how you have to formally reply to be counted as supporting the petition. Some of the people who have supported the petition so far, actually disagree with some of the details of the proposal. Supporting the petition only means that you want this to be discussed at the meeting; it is not necessarily an endorsement of the policy. In any case, starting in September, a lot of whois information will no longer be publicly available regardless of what ARIN does. That's because APNIC has decided not to publish *ANY* customer assignment information whatsoever. http://www.apnic.net/mailing-lists/sig-db/archive/2003/09/msg00001.html My proposal for ARIN at least attempts to balance the anonymity of end users with the needs for the Internet community to get some detail on the geographic dispersion of IP addresses. In this respect, I think it is far superior to the APNIC actions. Under APNIC rules you will get no information. Under the proposed new ARIN rules you will get something like this: 128.0.2.0/29 Private User Waukegan, IL, US or maybe 128.0.3.0/29 Organisme Sans But Lucratif Ste-Hyacinthe, PQ, CA Which would you prefer? --Michael Dillon P.S. the French bit means non-profit organization. It would be nice if we had some agreed classifications to put in this field, but plain text is better than nothing. From josmon at rigozsaurus.com Thu Mar 11 13:30:52 2004 From: josmon at rigozsaurus.com (John Osmon) Date: Thu, 11 Mar 2004 11:30:52 -0700 Subject: [ppml] 2001-2 Revisited In-Reply-To: References: <404F9E90.6020106@cogentco.com> Message-ID: <20040311183052.GA30371@rufus.rigozsaurus.com> On Thu, Mar 11, 2004 at 12:16:28PM -0500, Marshall Eubanks wrote: > How does this better than 2002-3, which was approved (albeit in amended > form) ? The intent for 2002-3 was that you would get a /24 > _from ARIN_, which IMHO is better than from your upstream. > > Now, it was changed to a /22, and I haven't submitted my proposal yet > (so I don't know if it has ever been exercised), but given 2002-3, why > do we need 2001-2 ? I too would rather have ARIN space, but some entities don't feel that way. I have a customer that utilizes a /21 of our space because they don't think they can afford the ARIN fees necessary to obtain their own space. 2001-2 covers the situation where someone *wants* to use their upstream's IP space for a /24 -- even if they might not hit address jstification guidelines. There are legitimate reasons for this case -- distinct from the legitimate reasons for 2002-3. From ahp at hilander.com Thu Mar 11 13:34:11 2004 From: ahp at hilander.com (Alec H. Peterson) Date: Thu, 11 Mar 2004 11:34:11 -0700 Subject: [ppml] Please respond to my petition In-Reply-To: References: Message-ID: <2147483647.1079004851@[192.168.0.103]> Michael, The petition is out there. You have already chastised somebody for responding negatively to your petition. If people want to support it the instructions are out there. Alec --On Thursday, March 11, 2004 5:31 PM +0000 Michael.Dillon at radianz.com wrote: > Please respond to my petition to get the whois proposal on the > agenda at the Vancouver policy meeting. The petition details > are here http://www.arin.net/mailing_lists/ppml/2610.html > and tell you how you have to formally reply to be counted > as supporting the petition. > > Some of the people who have supported the petition so > far, actually disagree with some of the details of the > proposal. Supporting the petition only means that you > want this to be discussed at the meeting; it is not > necessarily an endorsement of the policy. > > In any case, starting in September, a lot of whois information > will no longer be publicly available regardless of what ARIN > does. That's because APNIC has decided not to publish > *ANY* customer assignment information whatsoever. > > http://www.apnic.net/mailing-lists/sig-db/archive/2003/09/msg00001.html > > My proposal for ARIN at least attempts to balance the > anonymity of end users with the needs for the Internet > community to get some detail on the geographic dispersion > of IP addresses. In this respect, I think it is far superior to > the APNIC actions. > > Under APNIC rules you will get no information. Under the > proposed new ARIN rules you will get something like this: > > 128.0.2.0/29 > Private User > Waukegan, IL, US > > or maybe > > 128.0.3.0/29 > Organisme Sans But Lucratif > Ste-Hyacinthe, PQ, CA > > Which would you prefer? > > --Michael Dillon > > P.S. the French bit means non-profit organization. It would be nice if we > had some agreed classifications to put in this field, but plain text is > better than nothing. > From ddiller at cogentco.com Thu Mar 11 13:37:40 2004 From: ddiller at cogentco.com (Dave Diller) Date: Thu, 11 Mar 2004 13:37:40 -0500 Subject: [ppml] 2001-2 Revisited (and 2002-3 too ;) In-Reply-To: References: Message-ID: <4050B1F4.3090507@cogentco.com> > How does this better than 2002-3, which was approved (albeit in amended > form) ? The intent for 2002-3 was that you would get a /24 > _from ARIN_, which IMHO is better than from your upstream. > > Now, it was changed to a /22, and I haven't submitted my proposal yet > (so I don't know if it has ever been exercised), but given 2002-3, why > do we need 2001-2 ? > By my read, 2002-3 won't work for someone who can only justify a handful of IPs at each of several sites. It requires the same justification as any other request for IPs from ARIN, just with different bit boundaries. No multihoming special-case caveats like 2001-2. Speaking of 2002-3, how will it be put into practice? There seem to be two ways it could play out: * Current MH policy is "Used a /21? Here's a /20". 2002-3 could simply be shifting that two bits to "Used a /23? Here's a /22". * Single-homed policy is "Used a /20? Here's a /20". 2002-3 could both move the bits down as well as unify the policies. It dsoesn't say which of the two wil be put into play - whether the /21-->/20 is an integral part of the MH policy concept or simply a now-outmoded exception. At risk of steering the topic astray, clarification on the mechanics would be useful. -dd From randy at psg.com Thu Mar 11 13:39:32 2004 From: randy at psg.com (Randy Bush) Date: Thu, 11 Mar 2004 08:39:32 -1000 Subject: [ppml] Petition Request for Whois Proposal References: Message-ID: <20040311183935.F17CAFD9@smtp2.arin.net> thought it may need some modification, i support this sufficiently to formally support it. randy From jmcburnett at msmgmt.com Thu Mar 11 13:37:49 2004 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Thu, 11 Mar 2004 13:37:49 -0500 Subject: [ppml] 2001-2 Revisited Message-ID: <9BF6F06C4BC90746ADD6806746492A33E93812@msmmail01.msmgmt.com> -> ->I too would rather have ARIN space, but some entities don't feel that ->way. I have a customer that utilizes a /21 of our space because they ->don't think they can afford the ARIN fees necessary to obtain their ->own space. -> ->2001-2 covers the situation where someone *wants* to use their ->upstream's IP space for a /24 -- even if they might not hit address ->jstification guidelines. There are legitimate reasons for this ->case -- distinct from the legitimate reasons for 2002-3. -> Case in point, I have a /24 from my upstream, and I multi-home. But it would take me 33 months worth of $$ to pay for the block from ARIN at the rate I pay my upstream.... and the VP of Finance will not approve that.. Now if we are going to change primary providers at the end of the current contract, that is different........ Jim From tme at multicasttech.com Thu Mar 11 14:20:18 2004 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 11 Mar 2004 14:20:18 -0500 Subject: [ppml] 2001-2 Revisited (and 2002-3 too ;) In-Reply-To: <4050B1F4.3090507@cogentco.com> Message-ID: <21D91F13-7391-11D8-90AE-003065FC3726@multicasttech.com> On Thursday, March 11, 2004, at 01:37 PM, Dave Diller wrote: > >> How does this better than 2002-3, which was approved (albeit in >> amended form) ? The intent for 2002-3 was that you would get a /24 >> _from ARIN_, which IMHO is better than from your upstream. >> Now, it was changed to a /22, and I haven't submitted my proposal yet >> (so I don't know if it has ever been exercised), but given 2002-3, >> why do we need 2001-2 ? > > By my read, 2002-3 won't work for someone who can only justify a > handful of IPs at each of several sites. It requires the same > justification as any other request for IPs from ARIN, just with Of course, this was NOT the original intention and was not in the original proposal. > different bit boundaries. No multihoming special-case caveats like > 2001-2. > > Speaking of 2002-3, how will it be put into practice? There seem to > be two ways it could play out: > > * Current MH policy is "Used a /21? Here's a /20". 2002-3 could > simply be shifting that two bits to "Used a /23? Here's a /22". > > * Single-homed policy is "Used a /20? Here's a /20". 2002-3 could > both move the bits down as well as unify the policies. > > It dsoesn't say which of the two wil be put into play - whether the > /21-->/20 is an integral part of the MH policy concept or simply a > now-outmoded exception. At risk of steering the topic astray, > clarification on the mechanics would be useful. > > -dd > > > Regards Marshall Eubanks T.M. Eubanks e-mail : marshall.eubanks at telesuite.com http://www.telesuite.com From Michael.Dillon at radianz.com Fri Mar 12 06:08:22 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 12 Mar 2004 11:08:22 +0000 Subject: [ppml] Please respond to my petition Message-ID: >The petition is out there. You have already chastised somebody for >responding negatively to your petition. If people want to support it the >instructions are out there. You are stepping awfully close to the borderline of abusing your position on the ARIN Advisory Council. You were not elected to tell people what they can and cannot discuss on the *PUBLIC* policy mailing list. This list is for anyone and everyone who wants to air their views about ARIN's policies whether or not they are ARIN members or elected ARIN officials. And I didn't chastise anyone for responding negatively to the petition. I was trying to point out that there wasn't much point in getting into a debate about the policy at this point. You, of all people, should be encouraging people to work the new process which your advisory council put in place for developing new policy. It would be appropriate for you to post a message clarifying and explaining this new process and explaining that the purpose of the petition step is to take policies out of discussion unless there is some support for having any discussion in the first place. At least, that is my understanding of it. In my message to which you responded, I was trying to sell the idea of putting the whois policy back on the agenda. Seems to me that is a perfectly legitimate discussion to have on the *PUBLIC* policy mailing list and my message was quite aligned to the petition stage of the new polic process. So tell me, agent Mulder, just where are these instructions that speak of? Where's the evidence? --Michael Dillon a.k.a. the URL Kid From ahp at hilander.com Fri Mar 12 09:23:36 2004 From: ahp at hilander.com (Alec H. Peterson) Date: Fri, 12 Mar 2004 07:23:36 -0700 Subject: [ppml] Please respond to my petition In-Reply-To: References: Message-ID: <2147483647.1079076216@[192.168.0.101]> --On Friday, March 12, 2004 11:08 +0000 Michael.Dillon at radianz.com wrote: > > You are stepping awfully close to the borderline > of abusing your position on the ARIN Advisory Council. > You were not elected to tell people what they can and > cannot discuss on the *PUBLIC* policy mailing list. You know something Michael, you are absolutely right. That is not what I was elected to do. However, I did not do that. To quote: > The petition is out there. You have already chastised somebody for > responding negatively to your petition. If people want to support it the > instructions are out there. To paraphrase, I merely stated that you have already made your petition public and it would be 'nice' to just let people weigh in on it without continuing to make the same points. I made no comment or request based on the content of the actual discussion, but rather procedural issues surrounding the discussion. Nevertheless, that in and of itself was probably inappropriate, and for that I apologize. The AC has already weighed in on the issue and I should not have gotten involved again at this stage. However, to continue: > > This list is for anyone and everyone who wants to > air their views about ARIN's policies whether or not they > are ARIN members or elected ARIN officials. EXACTLY!!!!! > > And I didn't chastise anyone for responding negatively > to the petition. I was trying to point out that there > wasn't much point in getting into a debate about the > policy at this point. But you see Michael, by doing this you went and did exactly what you claim I did (tried to regulate the discussion on the list based on content). It is no more your place to perform such regulation than it is mine. The fact of the matter is that Steve's message was completely relevant. I did not care for your comments and I should have responded directly to them instead of making a tangential point in another thread. To your point two paragraphs up, the PPML is for discussions about anything related to public policy, regardless of whether or not it is related to a formal, numbered policy proposal. So in conclusion, the fact of the matter is that nobody should be regulating the discussion. Not you, nor I. I want nothing more than to have a public policy process that gets participation from as many different parties as possible. I did not appreciate your attempts to suppress the opinion of a well informed party, regardless of his stance on the issue. Thanks, Alec From memsvcs at arin.net Tue Mar 16 14:17:59 2004 From: memsvcs at arin.net (Member Services) Date: Tue, 16 Mar 2004 14:17:59 -0500 (EST) Subject: [ppml] Petition Request for Whois Proposal Message-ID: <200403161917.OAA25058@ops.arin.net> RE: Author's petition of proposed policy 'Purpose and Scope of ARIN WHOIS Directory' - Petition was found successful The proposed policy, Purpose and Scope of ARIN WHOIS Directory, was posted to the ARIN Public Policy Mailing List (PPML) on February 19, 2004. The ARIN Advisory Council conducted an initial review and decided not to support moving the proposal forward in the evaluation process. The author elected to petition and posted to PPML on March 10, 2004, in an attempt to advance the proposal in the evaluation process. In accordance with the ARIN Internet Resource Policy Evaluation Process, the ARIN President will verify whether people from at least four different organizations support a petitioned policy proposal. * If a petition receives the required support, the policy proposal will be considered formal and will follow the remainder of the evaluation process. * If a petition fails to receive the required support within five days, the policy proposal will be considered closed. The ARIN President has determined that the petition of the policy proposal, Purpose and Scope of ARIN WHOIS Directory, was successful. ARIN staff will assign the policy proposal a number and formally post the proposal to the Public Policy Mailing List at least 30 days prior to the upcoming Public Policy Meeting; the proposal will also be placed on the ARIN website. Member Services American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Wed Mar 17 14:41:42 2004 From: memsvcs at arin.net (Member Services) Date: Wed, 17 Mar 2004 14:41:42 -0500 (EST) Subject: [ppml] Policy Proposal 2004-2: Use of HD-Ratio for IPv4 Allocations Message-ID: <200403171941.OAA01253@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Vancouver, Canada, scheduled for April 19-20, 2004. According to the ARIN Internet Resource Policy Evaluation Process the Advisory Council will evaluate policy proposals after the Public Policy Meeting. The feedback and discussion of policy proposals on the Public Policy Mailing List will be included in the AC's evaluation. Subscription information for the ARIN Public Policy Mailing List is available at http://www.arin.net/mailing_lists/index.html The ARIN Internet Resource Policy Evaluation Process is available at: http://www.arin.net/policy/ipep.html ARIN's Policy Proposal Archive is available at: http://www.arin.net/policy/proposal_archive.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2004-2: Use of HD-Ratio for IPv4 Allocations Author: Michael Dillon Author's Organization: Radianz, Inc. Policy term: permanent Policy statement: 1. Anyone who has already been allocated 4096 IPv4 addresses or more may choose to have additional requests for IPv4 addresses evaluated using an HD (Host Density) Ratio calculation to determine sufficient utilization instead of a fixed percentage threshold. 2. All requests for additional IPv4 address space subject to the HD Ratio shall require the efficient utilization of the sum total of all existing allocations. The HD Ratio on the sum total of all existing allocations must be greater than or equal to .966. 3. In addition, the HD ratio of the most recent allocation must be greater than or equal to .930. 4. The HD ratio is calculated as log(utilized IPv4 addresses) divided by log(total addresses in all previous allocations). In this formula, log refers to the natural logarithm. Rationale: The HD ratio was proposed as a way to determine allocation usage thresholds for IPv6 address allocations. For more details on this, please refer to RFC 3194 . There is some detailed background discussion about applying the HD ratio to IPv4 allocations in a proposal by Paul Wilson posted to the APNIC mailing list on Aug 7, 2003 http://www.apnic.net/mailing-lists/sig-policy/archive/2003/08/msg00000.html and he presented the it to the annual APNIC policy meeting using these slides http://www.apnic.net/meetings/16/programme/sigs/docs/policy/addpol-pres-wilson-hd-ratio.pdf I am not suggesting that ARIN should adopt the APNIC proposal and although Paul invents a new name for the HD ratio, I prefer to keep the original term. The basic thrust of this 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 is because the utilization threshold establishes a time buffer between the beginning of an ARIN application for additional addresses and the final deployment of new addresses in the operational network. By using a looser criterion as network size grows, we are also expanding this time buffer. This recognizes that the economy is more dependent than ever on the smooth running of our networks and we should not artificially force larger members to operate with virtually no safety buffers for implementing new addresses. This safety buffer size is important because larger networks have more involved processes for changes to their network and these processes take time. Paul Wilson's paper contains ample discussions of the technical justification for using the HD ratio. 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. I will also be preparing some slides with graphs and tables that can be displayed on the ARIN website prior to the policy meeting. Please note the following points. a) This policy only applies to organizations that already have IP space equivalent to a /20 block or larger. b) The policy does not specify the source of the 4096 or more addresses therefore it could apply to an ISP who comes to ARIN for the very first time and exchanges an upstream allocation for their own PI space. c) The policy does not use the term "ISP" therefore it can also apply to any other organization with a large network which is growing larger and therefore needs another allocation. d) The policy only applies to organizations who opt-in. This means that if your IP address management tools can't handle the HD ratio you can ignore it. If you find the HD ratio confusing or complex then you can ignore it. If you are crafty and fund a study which finds that your organization would benefit in some way from the old rules about an 80% threshhold then you can ignore this new policy. The new policy provides a benefit to those organizations which need it without penalizing those which do not. e) This policy proposal cannot be understood in isolation. You do need to read the RFC and Paul Wilson's discussion paper. f) The .966 calculation in point 2 covers the entire aggregate of address space including the block covered by the .930 calculation in point 3. You have to meet both targets to pass this policy's test. Timetable for implementation: 30 days after ratification From memsvcs at arin.net Wed Mar 17 14:43:12 2004 From: memsvcs at arin.net (Member Services) Date: Wed, 17 Mar 2004 14:43:12 -0500 (EST) Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity Message-ID: <200403171943.OAA01408@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Vancouver, Canada, scheduled for April 19-20, 2004. According to the ARIN Internet Resource Policy Evaluation Process the Advisory Council will evaluate policy proposals after the Public Policy Meeting. The feedback and discussion of policy proposals on the Public Policy Mailing List will be included in the AC's evaluation. Subscription information for the ARIN Public Policy Mailing List is available at http://www.arin.net/mailing_lists/index.html The ARIN Internet Resource Policy Evaluation Process is available at: http://www.arin.net/policy/ipep.html ARIN's Policy Proposal Archive is available at: http://www.arin.net/policy/proposal_archive.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2004-3: Global Addresses for Private Network Inter- Connectivity Author: Marla Azinger and Bill Copeland Policy statement: Interfaces that connect private networks may be assigned globally unique address space. Hosts within the administrative control of a single organization should still use private address space in accordance with RFC-1918 and RFC-2050. This policy is not intended to override other policies with regard to justification, minimum size, fees, or any other standard procedure. Rationale: RFC-1918 and RFC-2050 are somewhat ambiguous concerning the use of registered IP addresses when connecting separate private networks. Further, with the complexity of today's private interconnections, it is not feasible to coordinate RFC-1918 private space among many enterprises. Therefore, this proposal seeks to expressly allow the use of registered space on the interfaces between private networks. Many private networking scenarios present the address assignment problem that this proposal seeks to resolve. These include private network interconnections, Virtual Private Networks (VPNs) using a common layer 3 transport, and service provider RFC-2547 networks that establish multiple VPNs. In the RFC-2547 case, the VPNs are isolated via separate routing tables. However, the use of extranets, partnerships, and other shared applications between VPNs complicate the address assignment on the PE-CE links. RFC Considerations Per RFC-2050: "In order for the Internet to scale using existing technologies, use of regional registry services should be limited to the assignment of IP addresses for organizations meeting one or more of the following conditions: a) the organization has no intention of connecting to the Internet-either now or in the future-but it still requires a globally unique IP address. The organization should consider using reserved addresses from RFC-1918. If it is determined this is not possible, they can be issued unique (if not Internet routable) IP addresses. b) the organization is multi-homed with no favored connection. c) the organization's actual requirement for IP space is very large, for example, the network prefix required to cover the request is of length /18 or shorter." Based on experience, ARIN has interpreted the RFC consistently to mean that organizations not connected to the global, public Internet do not need globally unique IP address space. However, there is no specific policy for the situation described in this proposal. In addition, RFC-1918 says: "Hosts within enterprises that use IP can be partitioned into three categories: Category 1: hosts that do not require access to hosts in other enterprises or the Internet at large; hosts within this category may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Category 2: hosts that need access to a limited set of outside services (e.g., E-mail, FTP, netnews, remote login) which can be handled by mediating gateways (e.g., application layer gateways). For many hosts in this category an unrestricted external access (provided via IP connectivity) may be unnecessary and even undesirable for privacy/security reasons. Just like hosts within the first category, such hosts may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Category 3: hosts that need network layer access outside the enterprise (provided via IP connectivity); hosts in the last category require IP addresses that are globally unambiguous." It is clear that routers need access to each other, and the layer 3 VPN requires non-conflicting addresses between routers. To be specific and conservative, non-conflicting addresses between PE-CE links are required. So, while it is true that one VPN customer organization's router (host) may not need to reach another VPN customer organization's router (host), the VPN provider needs to reach both routers. In some cases, VPN customer organizations do need to be able to reach each other, as in the case of business partnerships or extranets. It should be noted that the authors of RFC-1918 made some consideration of this scenario, and the RFC seems to suggest that the private space it reserves should not be used for interconnected enterprises. However, there is no ARIN policy to allow for allocation for these enterprises. To recognize earlier work in this area, an Internet Draft was prepared to resolve the policy vacuum, known as internet-draft-guichard-pe-ce, by Jim Guichard et al. The draft proposed to use a large block, e.g., /8, to be used by all service providers for private interconnection purposes. The draft failed to reach consensus support. Finally, it should be noted that even if another addressing scheme is used, a router used to connect to a VPN may also be connected to the Internet. Network Address Translation (NAT) cannot be used in two instances on a single router in common practice. Any address space outside of RFC-1918 must be considered routable. Therefore, if the network local to the router uses RFC-1918 space and NAT is used to translate addresses back to the Internet, it cannot use another instance of NAT back to the VPN. Actual Network Case Study There are many different situations in which it seems public IP addresses are needed to support a widely used private network. For example, the E-911 networks facilitate confidential communication among Police Stations, Fire Stations, Sheriff Stations, State Trooper Stations and various other Emergency Response Programs. Background: Every city and state deploys E-911 services separately. This has created multiple private networks within every County in the United States. There is now an increasing effort to allow these separate entities to communicate with each other. This may be achieved by putting these individual E-911 networks onto one larger connected private network while at the same time leaving each individual network with its own autonomy. Since every separate private network is maintaining it's very own private network and utilizing the private IP blocks within it's own network...there are no private IP's easily identified for use in this connected private network. Also, due to the delicate nature of this E-911 network it is imperative that no IP range is utilized more than once. This leaves us with only one option. This option is to use public IP's on the E- 911 Connective Networks. Technical Translation: In some cases these are private networks, and in other cases these are Virtual Private Networks (VPN) using a common layer 3 transport. When these networks connect, there is the possibility that addresses assigned in good faith on one network may overlap addresses assigned in good faith on the other. This will cause routing instability and reachability problems. How this has been handled in the past? With or without the knowledge of the upstream provider, public IP addresses are already being used for these private networks. There is currently one specific company working with ELI for creating several of these "E-911 connected" private networks. This company has already obtained several different blocks from multiple large ISPs. Why bring this proposal to the table now? Two reasons exist: 1) to make the entire community aware of this situation, and, 2) to provide a clearly documented solution that is supported by ARIN and the Internet community. Meeting Considerations: Apr 2004 1st Day of Conference: Vote on yes or no to implement use of Public IP's for Private use when requirements are met. The initial vote should solely be based on "should we allow this to happen for company X if they fit the approved requirements list." Apr 2004 2nd Day of Conference: Vote on requirements and supporting questions detailed below in *proposal step 2. The second day/session will be used to vote in or out what will comprise the "approved requirements and who does the assigning". *Policy proposal step 2 Several issues remain should this proposal pass. 1. Should a special block of IP addresses be set aside for this application as suggested in the earlier work by Jim Guichard? a. Pro: This approach will potentially consume fewer addresses. b. Con: Networks using IP addresses for this purpose already exist and the operators will not want to renumber. A grandfather clause would be needed to protect those that are already using IP addresses in this manner. 2. Who should assign these IP's? Upstream and ARIN? a. Upstream Pro: Sometimes this is appropriate if the private network has an ISP that can accommodate the request. b. Upstream Con: Some service providers are their own ISP and need to resort to ARIN for additional address space. c. ARIN Pro: This is the only choice for major service providers. d. ARIN Con: This choice incurs more administrative overhead for ARIN. 3. What are the qualifications for an operator to be allocated IP addresses for this application? The following are acceptable applications of this proposal. a. Emergency Use (Police enforcement organizations, Fire departments, 911 dispatch units) b. Life support line (i.e. crisis hot lines and hospitals) c. Layer 3 VPN service providers d. RFC-2547 public service providers e. Other private networks not under the same administrative control that must interconnect. References: internet-draft-guichard-pe-ce-addr-03.txt. "Address Allocation for PE-CE links within a Provider Provisioned VPN Network," Jim Guichard, et al. ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-guichard-pe-ce-addr-03.txt RFC2050. "INTERNET REGISTRY IP ALLOCATION GUIDELINES," Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg, Jon Postel. http://www.arin.net/library/rfc/rfc2050.txt RFC2547. "BGP/MPLS VPNs," Eric Rosen, Rakov Rekhter. http://www.ietf.org/rfc/rfc2547.txt RFC1918. "Address Allocation for Private Internets," Yakov Rekhter, Robert Moskowitz, Daniel Karrenberg, Geert Jan de Groot, Eliot Lear. http://www.arin.net/library/rfc/rfc1918.txt Timetable for implementation: This policy should be applied immediately, contingent upon final approval by the Board. From memsvcs at arin.net Wed Mar 17 14:40:07 2004 From: memsvcs at arin.net (Member Services) Date: Wed, 17 Mar 2004 14:40:07 -0500 (EST) Subject: [ppml] Policy Proposal 2004-1: Defining Utilization of IPv4 Addresses Message-ID: <200403171940.OAA00858@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Vancouver, Canada, scheduled for April 19-20, 2004. According to the ARIN Internet Resource Policy Evaluation Process the Advisory Council will evaluate policy proposals after the Public Policy Meeting. The feedback and discussion of policy proposals on the Public Policy Mailing List will be included in the AC's evaluation. Subscription information for the ARIN Public Policy Mailing List is available at http://www.arin.net/mailing_lists/index.html The ARIN Internet Resource Policy Evaluation Process is available at: http://www.arin.net/policy/ipep.html ARIN's Policy Proposal Archive is available at: http://www.arin.net/policy/proposal_archive.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2004-1: Defining Utilization of IPv4 Addresses Author: Michael Dillon Author's Organization: Radianz, Inc. Policy term: permanent Policy statement: 1. When an ISP applies for IPv4 address space, ARIN analyzes the utilization rate of any existing IPv4 address blocks allocated to the ISP. 2. For the purposes of calculating the utilization rate of ARIN allocations, any IPv4 address range that is assigned or allocated by the ISP to another organization will be counted as utilized if it meets the following two conditions. 3. The assigned or allocated address range must be of a size that is justified by ARIN policy. 4. The ISP must require the other organization to use their addresses efficiently, in particular by using VLSM and CIDR technologies. 5. The utilization rate of an address block is calculated as the number of utilized addresses divided by the total number of addresses in the block. Rationale: Currently, there is no clear definition of utilization in ARIN's IPv4 policy. The result is that different organizations interpret this in different ways. This policy change is an attempt to level the playing field so that noone has an unfair competitive advantage due to the vagueness of the policy. This policy change only provides a clear definition for the utilization rate of address blocks allocated by ARIN to ISPs. It does not address the utilization rate of address blocks assigned to end users which would presumably be calculated differently by counting end devices, network and broadcast addresses. Timetable for implementation: 30 days after ratification From memsvcs at arin.net Wed Mar 17 14:44:57 2004 From: memsvcs at arin.net (Member Services) Date: Wed, 17 Mar 2004 14:44:57 -0500 (EST) Subject: [ppml] Policy Proposal 2004-4: Purpose and scope of ARIN Whois Directory Message-ID: <200403171944.OAA01723@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Vancouver, Canada, scheduled for April 19-20, 2004. According to the ARIN Internet Resource Policy Evaluation Process the Advisory Council will evaluate policy proposals after the Public Policy Meeting. The feedback and discussion of policy proposals on the Public Policy Mailing List will be included in the AC's evaluation. Subscription information for the ARIN Public Policy Mailing List is available at http://www.arin.net/mailing_lists/index.html The ARIN Internet Resource Policy Evaluation Process is available at: http://www.arin.net/policy/ipep.html ARIN's Policy Proposal Archive is available at: http://www.arin.net/policy/proposal_archive.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2004-4: Purpose and scope of ARIN Whois directory Author: Michael Dillon Author's Organization: Radianz, Inc. Policy term: permanent Policy statement: 1. ARIN shall maintain and publish a directory of contact information for the purposes of facilitating the operation of interconnected 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 periodically and the directory will indicate information which may be stale if contact cannot be made promptly. 6. Additionally, the whois directory will contain, directly or indirectly, a record of all address blocks sub-allocated or assigned by the entities mentioned in item 3. 7. The records mentioned in item 6 will not identify the organization or individual receiving the address block or their exact location. These records will only indicate an organizational type, the nearest municipality providing postal service to the end user, state/province and country. Rationale: ARIN doesn't really have a policy regarding whois. Most of what we have today is adopted based on a long tradition that nobody understands anymore. In looking back at historical sources it appears that whois was originally set up so that ARPANET site managers could justify their ARPANET connectivity funding by enumerating the people/projects that were making use of the ARPANET. Times have changed and tradition is no longer sufficient reason for doing things. This proposal attempts to put in place a simple statement of the purpose and scope of a whois directory. It is my opinion that if we cannot all agree on some sort of simple policy similar to what I am proposing, then we probably should scrap the whois directory entirely. Nothing in this policy should be construed to restrain ARIN staff's ability to maintain and use whatever databases they may need in the performance of their duties including IP address allocation. This policy only refers to the data which is made freely available to the public. If this policy is adopted it will also alleviate concerns from the cable and DSL industry in regard to residential user privacy. a) ARIN policy doesn't currently state that ARIN will maintain or publish a whois directory. This policy fixes that. b) This proposal also explicitly states the purpose of the whois directory as being targeted at internetworking and operational issues. It is not intended to help anti-spamming collectives bypass the ISPs who are responsible for operating a network. In fact one of the goals is to make it harder for anti-spamming groups to attack end users. This whois policy would force them to report network abuse to the ISP employees who are responsible for finding and fixing network abuse issues. c) The proposal does not recognize research as part of the scope of the whois directory, however items 6 and 7 do provide for data which allows some mapping and analysis of address usage and therefore the research community will not be left out in the cold. d) This policy only directly puts a mandate on those organizations who have, or should have, an ARIN relationship to supply data. e) The policy also allows any responsible party to add their contact data to the ARIN database. However, this is done with their consent and by binding them to act responsibly, i.e. you can't list your organization and then ignore all abuse reports. The words "Ready, willing and able to communicate" are important here. f) The ARIN staff are charged to keep the directory up to date and to give us some indication when the contact process seems to be going awry. However, it refrains from giving detailed directions to the staff and relies on their prudence in setting out the timing and the process of this verification. g) I interpret "facilitating the operation of interconnected IP networks" to include the provision of data that allows some mapping and statistical analysis of the address space. For that reason, some small amount of data is required to enumerate and distinguish sub-allocations and assignments. h) This policy covers rwhois as well. ARIN is charged to maintain the whois directory but can certainly delegate some of this task to rwhois users. And when the policy specifies that all address blocks must be represented in the directory it also allows for this information to be published indirectly, for instance, through rhwois. However the policy does not require rwhois technology since it is in such a sad state of repair. It also refrains from prescribing LDAP at this time ;-) i) The classification system for organization types has been intentionally left unspecified. Obviously, it needs to include "individual" as a type but it could include NAICS sector codes, e.g. "NAICS 25" is the construction industry. It could also include NTEE codes for non-profits e.g. "NTEE H" is Medical research. And it could include some simple codes like "Company", "Non-Profit", "Education", "Government" for users who don't know about the various classification systems. j) End users are truly anonymous, no name, no address, no zip/postal code. In other words, people who are not involved in network operations are not identified in any way by the whois directory. Timetable for implementation: 30 days after ratification From memsvcs at arin.net Wed Mar 17 14:44:57 2004 From: memsvcs at arin.net (Member Services) Date: Wed, 17 Mar 2004 14:44:57 -0500 (EST) Subject: [ppml] Policy Proposal 2004-4: Purpose and scope of ARIN Whois Directory Message-ID: <200403171944.OAA01723@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Vancouver, Canada, scheduled for April 19-20, 2004. According to the ARIN Internet Resource Policy Evaluation Process the Advisory Council will evaluate policy proposals after the Public Policy Meeting. The feedback and discussion of policy proposals on the Public Policy Mailing List will be included in the AC's evaluation. Subscription information for the ARIN Public Policy Mailing List is available at http://www.arin.net/mailing_lists/index.html The ARIN Internet Resource Policy Evaluation Process is available at: http://www.arin.net/policy/ipep.html ARIN's Policy Proposal Archive is available at: http://www.arin.net/policy/proposal_archive.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2004-4: Purpose and scope of ARIN Whois directory Author: Michael Dillon Author's Organization: Radianz, Inc. Policy term: permanent Policy statement: 1. ARIN shall maintain and publish a directory of contact information for the purposes of facilitating the operation of interconnected 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 periodically and the directory will indicate information which may be stale if contact cannot be made promptly. 6. Additionally, the whois directory will contain, directly or indirectly, a record of all address blocks sub-allocated or assigned by the entities mentioned in item 3. 7. The records mentioned in item 6 will not identify the organization or individual receiving the address block or their exact location. These records will only indicate an organizational type, the nearest municipality providing postal service to the end user, state/province and country. Rationale: ARIN doesn't really have a policy regarding whois. Most of what we have today is adopted based on a long tradition that nobody understands anymore. In looking back at historical sources it appears that whois was originally set up so that ARPANET site managers could justify their ARPANET connectivity funding by enumerating the people/projects that were making use of the ARPANET. Times have changed and tradition is no longer sufficient reason for doing things. This proposal attempts to put in place a simple statement of the purpose and scope of a whois directory. It is my opinion that if we cannot all agree on some sort of simple policy similar to what I am proposing, then we probably should scrap the whois directory entirely. Nothing in this policy should be construed to restrain ARIN staff's ability to maintain and use whatever databases they may need in the performance of their duties including IP address allocation. This policy only refers to the data which is made freely available to the public. If this policy is adopted it will also alleviate concerns from the cable and DSL industry in regard to residential user privacy. a) ARIN policy doesn't currently state that ARIN will maintain or publish a whois directory. This policy fixes that. b) This proposal also explicitly states the purpose of the whois directory as being targeted at internetworking and operational issues. It is not intended to help anti-spamming collectives bypass the ISPs who are responsible for operating a network. In fact one of the goals is to make it harder for anti-spamming groups to attack end users. This whois policy would force them to report network abuse to the ISP employees who are responsible for finding and fixing network abuse issues. c) The proposal does not recognize research as part of the scope of the whois directory, however items 6 and 7 do provide for data which allows some mapping and analysis of address usage and therefore the research community will not be left out in the cold. d) This policy only directly puts a mandate on those organizations who have, or should have, an ARIN relationship to supply data. e) The policy also allows any responsible party to add their contact data to the ARIN database. However, this is done with their consent and by binding them to act responsibly, i.e. you can't list your organization and then ignore all abuse reports. The words "Ready, willing and able to communicate" are important here. f) The ARIN staff are charged to keep the directory up to date and to give us some indication when the contact process seems to be going awry. However, it refrains from giving detailed directions to the staff and relies on their prudence in setting out the timing and the process of this verification. g) I interpret "facilitating the operation of interconnected IP networks" to include the provision of data that allows some mapping and statistical analysis of the address space. For that reason, some small amount of data is required to enumerate and distinguish sub-allocations and assignments. h) This policy covers rwhois as well. ARIN is charged to maintain the whois directory but can certainly delegate some of this task to rwhois users. And when the policy specifies that all address blocks must be represented in the directory it also allows for this information to be published indirectly, for instance, through rhwois. However the policy does not require rwhois technology since it is in such a sad state of repair. It also refrains from prescribing LDAP at this time ;-) i) The classification system for organization types has been intentionally left unspecified. Obviously, it needs to include "individual" as a type but it could include NAICS sector codes, e.g. "NAICS 25" is the construction industry. It could also include NTEE codes for non-profits e.g. "NTEE H" is Medical research. And it could include some simple codes like "Company", "Non-Profit", "Education", "Government" for users who don't know about the various classification systems. j) End users are truly anonymous, no name, no address, no zip/postal code. In other words, people who are not involved in network operations are not identified in any way by the whois directory. Timetable for implementation: 30 days after ratification From memsvcs at arin.net Wed Mar 17 14:40:07 2004 From: memsvcs at arin.net (Member Services) Date: Wed, 17 Mar 2004 14:40:07 -0500 (EST) Subject: [ppml] Policy Proposal 2004-1: Defining Utilization of IPv4 Addresses Message-ID: <200403171940.OAA00858@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Vancouver, Canada, scheduled for April 19-20, 2004. According to the ARIN Internet Resource Policy Evaluation Process the Advisory Council will evaluate policy proposals after the Public Policy Meeting. The feedback and discussion of policy proposals on the Public Policy Mailing List will be included in the AC's evaluation. Subscription information for the ARIN Public Policy Mailing List is available at http://www.arin.net/mailing_lists/index.html The ARIN Internet Resource Policy Evaluation Process is available at: http://www.arin.net/policy/ipep.html ARIN's Policy Proposal Archive is available at: http://www.arin.net/policy/proposal_archive.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2004-1: Defining Utilization of IPv4 Addresses Author: Michael Dillon Author's Organization: Radianz, Inc. Policy term: permanent Policy statement: 1. When an ISP applies for IPv4 address space, ARIN analyzes the utilization rate of any existing IPv4 address blocks allocated to the ISP. 2. For the purposes of calculating the utilization rate of ARIN allocations, any IPv4 address range that is assigned or allocated by the ISP to another organization will be counted as utilized if it meets the following two conditions. 3. The assigned or allocated address range must be of a size that is justified by ARIN policy. 4. The ISP must require the other organization to use their addresses efficiently, in particular by using VLSM and CIDR technologies. 5. The utilization rate of an address block is calculated as the number of utilized addresses divided by the total number of addresses in the block. Rationale: Currently, there is no clear definition of utilization in ARIN's IPv4 policy. The result is that different organizations interpret this in different ways. This policy change is an attempt to level the playing field so that noone has an unfair competitive advantage due to the vagueness of the policy. This policy change only provides a clear definition for the utilization rate of address blocks allocated by ARIN to ISPs. It does not address the utilization rate of address blocks assigned to end users which would presumably be calculated differently by counting end devices, network and broadcast addresses. Timetable for implementation: 30 days after ratification From memsvcs at arin.net Wed Mar 17 14:41:42 2004 From: memsvcs at arin.net (Member Services) Date: Wed, 17 Mar 2004 14:41:42 -0500 (EST) Subject: [ppml] Policy Proposal 2004-2: Use of HD-Ratio for IPv4 Allocations Message-ID: <200403171941.OAA01253@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Vancouver, Canada, scheduled for April 19-20, 2004. According to the ARIN Internet Resource Policy Evaluation Process the Advisory Council will evaluate policy proposals after the Public Policy Meeting. The feedback and discussion of policy proposals on the Public Policy Mailing List will be included in the AC's evaluation. Subscription information for the ARIN Public Policy Mailing List is available at http://www.arin.net/mailing_lists/index.html The ARIN Internet Resource Policy Evaluation Process is available at: http://www.arin.net/policy/ipep.html ARIN's Policy Proposal Archive is available at: http://www.arin.net/policy/proposal_archive.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2004-2: Use of HD-Ratio for IPv4 Allocations Author: Michael Dillon Author's Organization: Radianz, Inc. Policy term: permanent Policy statement: 1. Anyone who has already been allocated 4096 IPv4 addresses or more may choose to have additional requests for IPv4 addresses evaluated using an HD (Host Density) Ratio calculation to determine sufficient utilization instead of a fixed percentage threshold. 2. All requests for additional IPv4 address space subject to the HD Ratio shall require the efficient utilization of the sum total of all existing allocations. The HD Ratio on the sum total of all existing allocations must be greater than or equal to .966. 3. In addition, the HD ratio of the most recent allocation must be greater than or equal to .930. 4. The HD ratio is calculated as log(utilized IPv4 addresses) divided by log(total addresses in all previous allocations). In this formula, log refers to the natural logarithm. Rationale: The HD ratio was proposed as a way to determine allocation usage thresholds for IPv6 address allocations. For more details on this, please refer to RFC 3194 . There is some detailed background discussion about applying the HD ratio to IPv4 allocations in a proposal by Paul Wilson posted to the APNIC mailing list on Aug 7, 2003 http://www.apnic.net/mailing-lists/sig-policy/archive/2003/08/msg00000.html and he presented the it to the annual APNIC policy meeting using these slides http://www.apnic.net/meetings/16/programme/sigs/docs/policy/addpol-pres-wilson-hd-ratio.pdf I am not suggesting that ARIN should adopt the APNIC proposal and although Paul invents a new name for the HD ratio, I prefer to keep the original term. The basic thrust of this 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 is because the utilization threshold establishes a time buffer between the beginning of an ARIN application for additional addresses and the final deployment of new addresses in the operational network. By using a looser criterion as network size grows, we are also expanding this time buffer. This recognizes that the economy is more dependent than ever on the smooth running of our networks and we should not artificially force larger members to operate with virtually no safety buffers for implementing new addresses. This safety buffer size is important because larger networks have more involved processes for changes to their network and these processes take time. Paul Wilson's paper contains ample discussions of the technical justification for using the HD ratio. 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. I will also be preparing some slides with graphs and tables that can be displayed on the ARIN website prior to the policy meeting. Please note the following points. a) This policy only applies to organizations that already have IP space equivalent to a /20 block or larger. b) The policy does not specify the source of the 4096 or more addresses therefore it could apply to an ISP who comes to ARIN for the very first time and exchanges an upstream allocation for their own PI space. c) The policy does not use the term "ISP" therefore it can also apply to any other organization with a large network which is growing larger and therefore needs another allocation. d) The policy only applies to organizations who opt-in. This means that if your IP address management tools can't handle the HD ratio you can ignore it. If you find the HD ratio confusing or complex then you can ignore it. If you are crafty and fund a study which finds that your organization would benefit in some way from the old rules about an 80% threshhold then you can ignore this new policy. The new policy provides a benefit to those organizations which need it without penalizing those which do not. e) This policy proposal cannot be understood in isolation. You do need to read the RFC and Paul Wilson's discussion paper. f) The .966 calculation in point 2 covers the entire aggregate of address space including the block covered by the .930 calculation in point 3. You have to meet both targets to pass this policy's test. Timetable for implementation: 30 days after ratification From memsvcs at arin.net Wed Mar 17 14:43:12 2004 From: memsvcs at arin.net (Member Services) Date: Wed, 17 Mar 2004 14:43:12 -0500 (EST) Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity Message-ID: <200403171943.OAA01408@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Vancouver, Canada, scheduled for April 19-20, 2004. According to the ARIN Internet Resource Policy Evaluation Process the Advisory Council will evaluate policy proposals after the Public Policy Meeting. The feedback and discussion of policy proposals on the Public Policy Mailing List will be included in the AC's evaluation. Subscription information for the ARIN Public Policy Mailing List is available at http://www.arin.net/mailing_lists/index.html The ARIN Internet Resource Policy Evaluation Process is available at: http://www.arin.net/policy/ipep.html ARIN's Policy Proposal Archive is available at: http://www.arin.net/policy/proposal_archive.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2004-3: Global Addresses for Private Network Inter- Connectivity Author: Marla Azinger and Bill Copeland Policy statement: Interfaces that connect private networks may be assigned globally unique address space. Hosts within the administrative control of a single organization should still use private address space in accordance with RFC-1918 and RFC-2050. This policy is not intended to override other policies with regard to justification, minimum size, fees, or any other standard procedure. Rationale: RFC-1918 and RFC-2050 are somewhat ambiguous concerning the use of registered IP addresses when connecting separate private networks. Further, with the complexity of today's private interconnections, it is not feasible to coordinate RFC-1918 private space among many enterprises. Therefore, this proposal seeks to expressly allow the use of registered space on the interfaces between private networks. Many private networking scenarios present the address assignment problem that this proposal seeks to resolve. These include private network interconnections, Virtual Private Networks (VPNs) using a common layer 3 transport, and service provider RFC-2547 networks that establish multiple VPNs. In the RFC-2547 case, the VPNs are isolated via separate routing tables. However, the use of extranets, partnerships, and other shared applications between VPNs complicate the address assignment on the PE-CE links. RFC Considerations Per RFC-2050: "In order for the Internet to scale using existing technologies, use of regional registry services should be limited to the assignment of IP addresses for organizations meeting one or more of the following conditions: a) the organization has no intention of connecting to the Internet-either now or in the future-but it still requires a globally unique IP address. The organization should consider using reserved addresses from RFC-1918. If it is determined this is not possible, they can be issued unique (if not Internet routable) IP addresses. b) the organization is multi-homed with no favored connection. c) the organization's actual requirement for IP space is very large, for example, the network prefix required to cover the request is of length /18 or shorter." Based on experience, ARIN has interpreted the RFC consistently to mean that organizations not connected to the global, public Internet do not need globally unique IP address space. However, there is no specific policy for the situation described in this proposal. In addition, RFC-1918 says: "Hosts within enterprises that use IP can be partitioned into three categories: Category 1: hosts that do not require access to hosts in other enterprises or the Internet at large; hosts within this category may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Category 2: hosts that need access to a limited set of outside services (e.g., E-mail, FTP, netnews, remote login) which can be handled by mediating gateways (e.g., application layer gateways). For many hosts in this category an unrestricted external access (provided via IP connectivity) may be unnecessary and even undesirable for privacy/security reasons. Just like hosts within the first category, such hosts may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Category 3: hosts that need network layer access outside the enterprise (provided via IP connectivity); hosts in the last category require IP addresses that are globally unambiguous." It is clear that routers need access to each other, and the layer 3 VPN requires non-conflicting addresses between routers. To be specific and conservative, non-conflicting addresses between PE-CE links are required. So, while it is true that one VPN customer organization's router (host) may not need to reach another VPN customer organization's router (host), the VPN provider needs to reach both routers. In some cases, VPN customer organizations do need to be able to reach each other, as in the case of business partnerships or extranets. It should be noted that the authors of RFC-1918 made some consideration of this scenario, and the RFC seems to suggest that the private space it reserves should not be used for interconnected enterprises. However, there is no ARIN policy to allow for allocation for these enterprises. To recognize earlier work in this area, an Internet Draft was prepared to resolve the policy vacuum, known as internet-draft-guichard-pe-ce, by Jim Guichard et al. The draft proposed to use a large block, e.g., /8, to be used by all service providers for private interconnection purposes. The draft failed to reach consensus support. Finally, it should be noted that even if another addressing scheme is used, a router used to connect to a VPN may also be connected to the Internet. Network Address Translation (NAT) cannot be used in two instances on a single router in common practice. Any address space outside of RFC-1918 must be considered routable. Therefore, if the network local to the router uses RFC-1918 space and NAT is used to translate addresses back to the Internet, it cannot use another instance of NAT back to the VPN. Actual Network Case Study There are many different situations in which it seems public IP addresses are needed to support a widely used private network. For example, the E-911 networks facilitate confidential communication among Police Stations, Fire Stations, Sheriff Stations, State Trooper Stations and various other Emergency Response Programs. Background: Every city and state deploys E-911 services separately. This has created multiple private networks within every County in the United States. There is now an increasing effort to allow these separate entities to communicate with each other. This may be achieved by putting these individual E-911 networks onto one larger connected private network while at the same time leaving each individual network with its own autonomy. Since every separate private network is maintaining it's very own private network and utilizing the private IP blocks within it's own network...there are no private IP's easily identified for use in this connected private network. Also, due to the delicate nature of this E-911 network it is imperative that no IP range is utilized more than once. This leaves us with only one option. This option is to use public IP's on the E- 911 Connective Networks. Technical Translation: In some cases these are private networks, and in other cases these are Virtual Private Networks (VPN) using a common layer 3 transport. When these networks connect, there is the possibility that addresses assigned in good faith on one network may overlap addresses assigned in good faith on the other. This will cause routing instability and reachability problems. How this has been handled in the past? With or without the knowledge of the upstream provider, public IP addresses are already being used for these private networks. There is currently one specific company working with ELI for creating several of these "E-911 connected" private networks. This company has already obtained several different blocks from multiple large ISPs. Why bring this proposal to the table now? Two reasons exist: 1) to make the entire community aware of this situation, and, 2) to provide a clearly documented solution that is supported by ARIN and the Internet community. Meeting Considerations: Apr 2004 1st Day of Conference: Vote on yes or no to implement use of Public IP's for Private use when requirements are met. The initial vote should solely be based on "should we allow this to happen for company X if they fit the approved requirements list." Apr 2004 2nd Day of Conference: Vote on requirements and supporting questions detailed below in *proposal step 2. The second day/session will be used to vote in or out what will comprise the "approved requirements and who does the assigning". *Policy proposal step 2 Several issues remain should this proposal pass. 1. Should a special block of IP addresses be set aside for this application as suggested in the earlier work by Jim Guichard? a. Pro: This approach will potentially consume fewer addresses. b. Con: Networks using IP addresses for this purpose already exist and the operators will not want to renumber. A grandfather clause would be needed to protect those that are already using IP addresses in this manner. 2. Who should assign these IP's? Upstream and ARIN? a. Upstream Pro: Sometimes this is appropriate if the private network has an ISP that can accommodate the request. b. Upstream Con: Some service providers are their own ISP and need to resort to ARIN for additional address space. c. ARIN Pro: This is the only choice for major service providers. d. ARIN Con: This choice incurs more administrative overhead for ARIN. 3. What are the qualifications for an operator to be allocated IP addresses for this application? The following are acceptable applications of this proposal. a. Emergency Use (Police enforcement organizations, Fire departments, 911 dispatch units) b. Life support line (i.e. crisis hot lines and hospitals) c. Layer 3 VPN service providers d. RFC-2547 public service providers e. Other private networks not under the same administrative control that must interconnect. References: internet-draft-guichard-pe-ce-addr-03.txt. "Address Allocation for PE-CE links within a Provider Provisioned VPN Network," Jim Guichard, et al. ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-guichard-pe-ce-addr-03.txt RFC2050. "INTERNET REGISTRY IP ALLOCATION GUIDELINES," Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg, Jon Postel. http://www.arin.net/library/rfc/rfc2050.txt RFC2547. "BGP/MPLS VPNs," Eric Rosen, Rakov Rekhter. http://www.ietf.org/rfc/rfc2547.txt RFC1918. "Address Allocation for Private Internets," Yakov Rekhter, Robert Moskowitz, Daniel Karrenberg, Geert Jan de Groot, Eliot Lear. http://www.arin.net/library/rfc/rfc1918.txt Timetable for implementation: This policy should be applied immediately, contingent upon final approval by the Board. From memsvcs at arin.net Fri Mar 19 16:21:05 2004 From: memsvcs at arin.net (Member Services) Date: Fri, 19 Mar 2004 16:21:05 -0500 (EST) Subject: [ppml] ARIN XIII - Policy Proposals Message-ID: <200403192121.QAA10066@ops.arin.net> ARIN will hold its next Public Policy Meeting in Vancouver, Canada, on April 19-20, 2004. Meeting and registration details can be found at: http://www.arin.net/ARIN-XIII/index.html Policy discussions at this meeting will be centered around policy proposals recently introduced to the Public Policy Mailing List (PPML), and those carried over from the previous Public Policy Meeting. Policy Proposals recently introduced on PPML: 2004-1 Defining Utilization of IPv4 Addresses 2004-2 Use of HD-Ratio for IPv4 Allocations 2004-3 Global Addresses for Private Network Inter-Connectivity 2004-4 Purpose and scope of ARIN WHOIS Directory Policy Proposals carried over from the previous Public Policy Meeting: 2003-4 IPv6 Policy Changes 2003-9 WHOIS Acceptable Use Policy (AUP) 2003-16 POC Verification Leading up to the meeting, policy proposals are open for discussion on PPML. Each of the policy proposals has been previously posted to this mailing list as an independent thread to facilitate discussion. A summary of the active policy proposals under discussion is available at: http://www.arin.net/policy/proposal_archive.html The entire Internet community is invited and encouraged to participate in these policy discussions. Your active participation in these discussions is vital to the process and will help to form policies that are beneficial to all. Mailing list subscription information is available at: http://www.arin.net/mailing_lists/index.html Member Services American Registry for Internet Numbers (ARIN) From stephen at sprunk.org Sun Mar 21 21:34:46 2004 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 21 Mar 2004 20:34:46 -0600 Subject: [ppml] Re: ASN-based prefixes for leaf ASes References: <200403191612.i2JGCnp13620@boreas.isi.edu> Message-ID: <014701c40fb7$46e1a000$6401a8c0@ssprunk> Thus spake "Bill Manning" > sure, fine. Just pointing out the ASN based, prefix assignment > hack is -very- old and has been abandoned by the IETF in > favor of the processes we currently use. That doesn't mean abandoning it completely was a good idea. That system also didn't provide a mechanism for non-leaf ASes to get non-ASN-based allocations, which severely limited its scalability. We've jumped from one extreme to the other, when perhaps using both systems in parallel might be most efficient. > % > % draft-savola-multi6-asn-pi-01.txt > % > % (Well, I don't like that proposition either..) > % > % p.s. the correct forum may be multi6. > % > > % > Actually, the correct forum would be the RIR public policy mtgs. > % > % Not yet IMHO, see above. > > actually, I think it is imprudent to not include the > RIR public policy fourm in any discussions on new address > assignment plans. YMMV of course. I agree and invite input from ARIN members. NOTE: Please include in your comments whether you're a leaf or non-leaf AS. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From stephen at sprunk.org Mon Mar 22 03:50:24 2004 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 22 Mar 2004 02:50:24 -0600 Subject: [ppml] Re: ASN-based prefixes for leaf ASes References: <200403191612.i2JGCnp13620@boreas.isi.edu> <014701c40fb7$46e1a000$6401a8c0@ssprunk> Message-ID: <004f01c40feb$eff3ccc0$6401a8c0@ssprunk> Thus spake "Stephen Sprunk" > I agree and invite input from ARIN members. NOTE: Please include in your > comments whether you're a leaf or non-leaf AS. I forgot that PPML wasn't copied on the original message... To clarify: My proposal was that automatic /48 allocations be made to anyone with an ASN, based on the premise that every AS will advertise at least one PI block. These allocations would not allow sub-assignment (i.e. by non-leaf ASes). Non-leaf ASes might use their ASN-based allocation for internal use, or might ignore the ASN-based allocation in favor of "normal" TLA allocations to minimize the number of advertised prefixes; the ASN-based allocation should not count against non-leaf ASes for measuring utilization of "normal" TLA allocations. Leaf ASes would not be granted "normal" TLA allocations without either evidence their ASN-based prefix was substantially consumed or reasonable technical justification for multiple prefixes, e.g. for varying BGP policies. Some may note this is somewhat similar to 3ffe:: allocations to 6bone sites, which were deprecated once RIR-based IPv6 allocations were standardized. The major difference is that I propose it mainly apply to leaf ASes. IMHO, ASN-based allocations still make sense for leaf ASes, and forcing leaf ASes through the RIR process for initial allocations is suboptimal if one accepts the premise that every AS will advertise at least one PI prefix. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From william at elan.net Mon Mar 22 05:42:02 2004 From: william at elan.net (william(at)elan.net) Date: Mon, 22 Mar 2004 02:42:02 -0800 (PST) Subject: [ppml] Re: ASN-based prefixes for leaf ASes In-Reply-To: <004f01c40feb$eff3ccc0$6401a8c0@ssprunk> Message-ID: On Mon, 22 Mar 2004, Stephen Sprunk wrote: > Thus spake "Stephen Sprunk" > > I agree and invite input from ARIN members. NOTE: Please include in your > > comments whether you're a leaf or non-leaf AS. > > I forgot that PPML wasn't copied on the original message... To clarify: > > My proposal was that automatic /48 allocations be made to anyone with an > ASN, based on the premise that every AS will advertise at least one PI > block. If I remember right /48 is not a PI block (or rather it may not be within ARIN region which uses different terminology), /48 are expected to be allocated by ISPs (LIRs) to customers with their own network (rather when its individual device and then its /64) but its provider-dependent (i.e. PA) as far as its being assigned by ISP where as PI would be micro-allocation directly by RIR Now if you compare the policies for IPv4 ARIN does have a policy that multihoming (i.e. = has ASN) is an automatic justification for /24 from one of the upstreams. Its not unreasonable to expect this to be extended to IPv6 and say that multihoming is justification for /48 from one of the upstreams or from RIR - however saying that is redundant as running independent network with multiple devices is already justification for /48 from the LIR or upstream no matter if network it is multihomed or not :) Now as far as assigning /48 for every ASN, lets not do it just yet - some ASNs may need larger blocks then just /48 and besides that there are way too many ASNs out there that are not used at all (getting close to 50%) and for those that are used some are used for special network preferences by the same provider that may not need separate /48. So just having ASN out in whois does not mean they really need an /48 - that ASN holder must actually ask for it! However, what I would be for is allowing for micro-allocations from ARIN (and this can/should be larger then /48 probably) so as to boostart use of IPv6. Currently if ASN holder is not a member of ARIN, they should request ip block from their ISP or become member of ARIN and pay for that IPv6 block $2500/year, I think we should allow for companies with ASN to be able to directly request IPv6 space from ARIN (micro-allocation) if their ISP does not have yet have IPv6 space and that "ipv6 startup micro-allocations" should cost less then regular full ipv6 blocks - possibly no extra money if they are already paying yearly maintanance fee of $100/yr for ASN). -- William Leibzon Elan Networks william at elan.net From Michael.Dillon at radianz.com Mon Mar 22 07:25:32 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 22 Mar 2004 12:25:32 +0000 Subject: [ppml] Re: ASN-based prefixes for leaf ASes Message-ID: >My proposal was that automatic /48 allocations be made to anyone with an >ASN, based on the premise that every AS will advertise at least one PI >block. And what is wrong with giving every AS an automatic /32? Or to put it in a more systematic manner, let's offer every AS holder some IPv6 space now. Let's ask them to identify how many networks they currently connect in order to estimate the number of /48's that would be used to connect the same number of networks. Then let's round this up to the next highest CIDR block boundary up to a maximum size of /32 and then give them that much IPv6 space, today. The basic principle is that because an AS holder is using IPv4 today, they will almost certainly use IPv6 at some future date. Therefore they have a justified requirement for IPv6 address space. And if an ISP is going to start offering IPv6 services, it is likely that they will eventually be offering those services to all customers. By counting the number of networks/sites they connect today, we have a rough estimate of the number of IPv6 sites that they will connect. But this offer is only a kickstart offer for one IPv6 allocation therefore the offer should be for no more than one /32. This does not mean that the RIRs have to create a swamp. They could reserve a /32 for each AS but only allocate the smaller block. Now, with these assumptions, we have enough information to calulate the amount of IPv6 space that would be used up. Could someone please do the caculations and let us know what percentage of the currently defined unicast IPv6 space would be consumed by such a kickstart program? --Michael Dillon From stephen at sprunk.org Mon Mar 22 08:52:29 2004 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 22 Mar 2004 07:52:29 -0600 Subject: [ppml] Re: ASN-based prefixes for leaf ASes References: Message-ID: <004a01c41016$018efed0$6401a8c0@ssprunk> Thus spake "william(at)elan.net" > On Mon, 22 Mar 2004, Stephen Sprunk wrote: > > My proposal was that automatic /48 allocations be made to anyone with an > > ASN, based on the premise that every AS will advertise at least one PI > > block. > > If I remember right /48 is not a PI block (or rather it may not be within > ARIN region which uses different terminology), /48 are expected to be > allocated by ISPs (LIRs) to customers with their own network (rather when > its individual device and then its /64) but its provider-dependent > (i.e. PA) as far as its being assigned by ISP where as PI would be > micro-allocation directly by RIR /48 is the size ISPs are supposed to hand out to leaf sites (with or without an ASN), so that's the logical size of direct allocations to leaf sites. This also allows encoding a 32-bit ASN in the prefix while only consuming a /16 overall. I say 32-bit ASN because it's clear the 16-bit space will run out before IPv6 is retired; this could be changed to a 16-bit ASN if we really want to assign a /32 to each leaf AS, but that seems like overkill. > Now as far as assigning /48 for every ASN, lets not do it just yet - some > ASNs may need larger blocks then just /48 It's hard to envision a leaf AS needing more than 64k subnets, but in that case they could request a "normal" allocation from their RIR. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From memsvcs at arin.net Mon Mar 22 15:51:52 2004 From: memsvcs at arin.net (Member Services) Date: Mon, 22 Mar 2004 15:51:52 -0500 (EST) Subject: [ppml] Last Call for Comment: Policy Proposal 2003-5 Message-ID: <200403222051.PAA11305@ops.arin.net> This is a last call for comments on this policy proposal. The Advisory Council will review the comments collected during this last call period. The AC determined that there was community support for this policy proposal. The proposal text was revised by the author in response to comments received at the Public Policy Meeting and mailing list discussions. Please send your comments to ppml at arin.net. This last call will expire at 23:59 EST on April 5, 2004. Member Services American Registry for Internet Numbers (ARIN) ####################################### Policy Proposal 2003-5: Distributed Information Server Use Requirements Author: Mark Kosters Policy term: permanent Policy statement: The proposed minimal requirements for an organization to setup a distributed information service to advertise reassignment information are: The distributed information service must be operational 24 hours a day, 7 days a week to both the general public and ARIN staff. The service is allowed reasonable downtime for server maintenance according to generally accepted community standards. The distributed information service must allow public access to reassignment information. The service may restrict the number of queries allowed per time interval from a host or subnet to defend against DDOS attacks, remote mirroring attempts, and other nefarious acts. The distributed information service must return reassignment information for the IP address queried. The service may allow for privacy protections for customers. For residential users, the service may follow ARIN's residential privacy policy that includes displaying only the city, state, zip code, and country. For all other reassignments, the service shall follow ARIN's privacy policy for publishing data in a public forum. The distributed information service may return results for non-IP queries. The distributed information service must respond to a query with the minimal set of attributes per object as defined by ARIN staff. The distributed information service may include optional attributes per object that are defined locally. The distributed information service must return results that are up-to-date on reassignment information. Rationale: RWhois, a distributed lookup service, was created in part to allow ISPs to locally operate and control their own reassignment information. The purpose of placing this data in a RWhois server was two-fold: 1) Allow RIR staff to examine reassignment utilization 2) Allow access to the general public on reassignment information. Many ISPs have opted to use RWhois servers for their reassignment information over sending SWIPs to ARIN. But some of the ISPs who have selected to use RWhois servers for their reassignment information have not kept the servers operational 24x7, contents of the database up to-date, or are restricting access only to ARIN staff. This lack of a uniform set of operations of RWhois servers has resulted in confusion for end-users and ARIN staff. This policy proposal will describe the set of minimal requirements of operating a RWhois server for those ISPs who decide to use RWhois to manage their IP reassignment information. In the future, there may be other distributed lookup services that ARIN may allow ISPs to use. These new services must be approved by ARIN before being allowed to serve as a repository for reassignment information. Timetable for implementation: This policy should be applied immediately, contingent upon final approval by the Board. From memsvcs at arin.net Mon Mar 22 16:30:55 2004 From: memsvcs at arin.net (Member Services) Date: Mon, 22 Mar 2004 16:30:55 -0500 (EST) Subject: [ppml] Policy Proposal 2003-4: IPv6 Policy Changes Message-ID: <200403222130.QAA19092@ops.arin.net> This policy proposal was previously discussed on this mailing list and at the ARIN XII Public Policy Meeting. Based on the feedback received from those discussions, the language of this policy proposal has been modified. This proposal is open for discussion on this mailing list and will be on the agenda at the Public Policy Meeting next month in Vancouver. Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2003-4: IPv6 Policy Changes Author: ARIN Advisory Council Policy term: permanent Policy statement: A. 5.1.1(d), which currently reads: "d) have a plan for making at least 200 /48 assignments to other organizations within two years" will have the timeframe changed from "two years" to "five years". B. 5.1.1(d) will have prepended "be an existing, known ISP in the ARIN region or..." Rationale: These changes to the initial allocation criteria are to acknowledge the slow pace of IPv6 deployment in the ARIN region. Also they further stress the availability of IPv6 allocations to existing service providers in the ARIN region. The following is section 5.1.1 as it currently is in the ARIN IPv6 Address Allocation and Assignment Policy document: 5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: a) be an LIR; b) not be an end site; c) plan to provide IPv6 connectivity to organizations to which it will assign /48s, by advertising that connectivity through its single aggregated address allocation; and d) have a plan for making at least 200 /48 assignments to other organizations within two years. The ARIN IPv6 Address Allocation and Assignment Policy is available here: http://www.arin.net/policy/ipv6_policy.html Timetable for implementation: 30 days after ratification From memsvcs at arin.net Mon Mar 22 16:31:46 2004 From: memsvcs at arin.net (Member Services) Date: Mon, 22 Mar 2004 16:31:46 -0500 (EST) Subject: [ppml] Policy Proposal 2003-16: POC Verification Message-ID: <200403222131.QAA19215@ops.arin.net> This policy proposal was previously discussed on this mailing list and at the ARIN XII Public Policy Meeting. Based on the feedback received from those discussions, the language of this policy proposal has been modified. This proposal is open for discussion on this mailing list and will be on the agenda at the Public Policy Meeting next month in Vancouver. Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2003-16: POC Verification Author: ARIN Advisory Council Policy term: permanent ----------------------------------------------------------------- Policy statement: ARIN will provide a form on their Web site to allow the Internet community at large to notify ARIN that a POC may be inaccurate. The status of POC verification will be displayed in WHOIS including the last verified date. POC Verification States: - Not Verified: Verification of the POC has never been attempted or requested. This would be the initial state of every existing or new POC. - Verified: The POC has been verified at some time in the past and there are no outstanding notifications. - In-Process: ARIN is currently investigating the accuracy of the POC. - Delinquent: ARIN has attempted but been unable to verify the accuracy of the POC. Last Verified Date: - The WHOIS database will list the date when the POC data was last verified unless the POC is in "Not Verified" status. Verification Process: Verification requests for a POC should only be accepted if the POC has never been verified or if more than six months have passed since the last verification. During the verification process, ARIN staff shall make all reasonable efforts to contact and verify the POC based on procedures to be set forth by ARIN management. Such procedures shall be published on the ARIN web site and may be updated by ARIN management as the need arises. ARIN shall publish a list in machine-parseable form identifying the current verification status of all POCs. The details of this publication procedure are left to ARIN management. ----------------------------------------------------------------- Rationale: 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. Timetable for implementation: 30 days after ratification From Michael.Dillon at radianz.com Tue Mar 23 05:22:05 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 23 Mar 2004 10:22:05 +0000 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-5 Message-ID: I think that this proposal is flawed in two separate ways and should not go forward at this time. In one sense it specifies too much detail and therefore covers areas that are better covered in other policies. And in another sense it attempts to use policy to solve technical problems which is a bad way to use policies. >The distributed information service must return reassignment >information for the IP address queried. The service may allow >for privacy protections for customers. For residential users, the >service may follow ARIN's residential privacy policy that includes >displaying only the city, state, zip code, and country. For all >other reassignments, the service shall follow ARIN's privacy policy >for publishing data in a public forum. This much detail should not be in this policy. Any distributed information service should publish no more and no less than the information that ARIN itself publishes. In other words the distributed information service is a choice of mechanism for publishing a whois directory. You can SWIP into ARIN's database or you can publish using your own distributed information service. Also, the exact details of what should be published are currently under review and it is bad policy to slip this in here when it could very well be overridden in a month or so. >Many ISPs have opted to use RWhois servers for their reassignment >information over sending SWIPs to ARIN. But some of the ISPs who have >selected to use RWhois servers for their reassignment information have >not kept the servers operational 24x7, contents of the database up >to-date, or are restricting access only to ARIN staff. Anybody who has ever set up or operated an RWhois server knows that this is an awkward and mostly undocumented system. It looks very much like someone slapped together a quick prototype and it got shipped. The root of the problem here is a technical issue and a "THOU SHALT" policy is not the way to fix it. It's like beating your children because they won't eat their supper and I don't like to see this attitude creep into ARIN's policies. If you really want a policy fix to this, you will get rid of RWhois entirely and allow ISPs to publish a whois directory using other technologies that are supported, documented and available from more than one source. LDAP is a possibility but not the only one. You could also define a standard HTTP and assuming it was backed by an application, not static files, then we could use the HTTP redirect feature to get the same kind of distributed lookup that RWhois has not been able to deliver. --Michael Dillon From william at elan.net Tue Mar 23 16:08:30 2004 From: william at elan.net (william(at)elan.net) Date: Tue, 23 Mar 2004 13:08:30 -0800 (PST) Subject: [ppml] Last Call for Comment: Policy Proposal 2003-5 In-Reply-To: Message-ID: On Tue, 23 Mar 2004 Michael.Dillon at radianz.com wrote: > I think that this proposal is flawed in two separate > ways and should not go forward at this time. In one > sense it specifies too much detail and therefore covers > areas that are better covered in other policies. And > in another sense it attempts to use policy to solve > technical problems which is a bad way to use policies. On one hand I agree that current text is not perfect, but on the other hand it is unfortunetly the situation that such policy is badly needed and we can probably fix the text later on if it becomes a problem > >The distributed information service must return reassignment > >information for the IP address queried. The service may allow > >for privacy protections for customers. That should be or possibly it can possibly end with ".. for customers as specific in arin policies concerning publishing of reassignment information in whois records or in public forum" > >For residential users, the > >service may follow ARIN's residential privacy policy that includes > >displaying only the city, state, zip code, and country. For all > >other reassignments, the service shall follow ARIN's privacy policy > >for publishing data in a public forum. The specific detail should be made available on speicial webpage which explains about rwhois server. I've previously tried to tell arin that they need to separate what is needed as far as policies and what is needed as far as better documentation for those using or setring up rwhois server. > This much detail should not be in this policy. > Any distributed information service should publish > no more and no less than the information that ARIN > itself publishes. In other words the distributed > information service is a choice of mechanism for > publishing a whois directory. You can SWIP into > ARIN's database or you can publish using your own > distributed information service. I agree. > Also, the exact details of what should be published > are currently under review and it is bad policy to > slip this in here when it could very well be overridden > in a month or so. > > >Many ISPs have opted to use RWhois servers for their reassignment > >information over sending SWIPs to ARIN. But some of the ISPs who have > >selected to use RWhois servers for their reassignment information have > >not kept the servers operational 24x7, contents of the database up > >to-date, or are restricting access only to ARIN staff. Again this belongs on the special webpage that should explain in detail what is needed to run and setup rwhois server, this is not a policy text. > If you really want a policy fix to this, you will > get rid of RWhois entirely and allow ISPs to > publish a whois directory using other technologies > that are supported, documented and available from > more than one source. LDAP is a possibility but > not the only one. You could also define a standard > HTTP and assuming it was backed by an application, > not static files, then we could use the HTTP redirect > feature to get the same kind of distributed lookup > that RWhois has not been able to deliver. It comes close to what I have written before once that we should have policy(ies) that specify what data is to be published on reassignments and reallocations (this is what we currently call "whois" data but it maybe better if we create another more general term) then we have protocols that can be used either by ARIN or by ISPs to provide access to such data and each protocol is documented separately and approved by AC. Possibly policy should also exist on how this "approval" process goes for new protocol to be used. As to my specific comments, LDAP is ok and during CRISP it was even developed into working prototype (the question is how many will be using it - what is needed is that the approval process also specify that if new protocol is proposed to be used for reassignment data that it should be approved if certain number of existing arin members respond that they have immediate plans to use this). Straight HTTP is not ok - but CRISP is being developed into XML and just like IPP (internet printing protocol) it maybe possible to serve it through http server. -- William Leibzon Elan Networks william at elan.net From Michael.Dillon at radianz.com Wed Mar 24 06:18:44 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 24 Mar 2004 11:18:44 +0000 Subject: [ppml] Background info for HD ratio proposal Message-ID: Policy Proposal 2004-2 proposes that we change the 80% threshold for additional IPv4 address allocations to a sliding scale formula based on the same type of Host Density (HD) Ratio as we currently use for IPv6 allocations. The formal policy proposal is on the ARIN site http://www.arin.net/policy/2004_2.html and is up for a vote at the Vancouver meeting. This is a significant change to the way that IPv4 allocation is done and I have prepared some additional background documents to explain and clarify the proposal. If you go to the ARIN page mentioned above, at the bottom there is a link to the background documents page. There you can find a brief slide presentation, a spreadsheet, some PERL scripts and some tables. Please take a few moments to look through this material. If there is anything unclear about the proposal, I will try my best to answer questions on this list. And if Paul Wilson is lurking here, hopefully he will say hello to let us know. My proposal is heavily dependent on the paper that he wrote for APNIC. Oh, and thanks to Einar Bohlin on the ARIN staff for his patience in sorting out some technical issues of getting this material online. Thank you, ------------------------------------------------------- Michael Dillon Capacity Management, 66 Prescot St., London, E1 8HG, 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 Wed Mar 24 09:35:02 2004 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 24 Mar 2004 08:35:02 -0600 Subject: [ppml] HD ratio proposal vs. Changing percentage burden Message-ID: <50C9C45A7E8DCE41A19F7A94715BABFD029FE5@kronos.cait.wustl.edu> Michael Dillon wrote... > > Policy Proposal 2004-2 proposes that we change the 80% threshold > for additional IPv4 address allocations to a sliding scale > formula based on the same type of Host Density (HD) Ratio as > we currently use for IPv6 allocations. The formal policy proposal > is on the ARIN site http://www.arin.net/policy/2004_2.html > and is up for a vote at the Vancouver meeting. > > This is a significant change to the way that IPv4 allocation > is done and I have prepared some additional background > documents to explain and clarify the proposal. If you go > to the ARIN page mentioned above, at the bottom there is > a link to the background documents page. There you can > find a brief slide presentation, a spreadsheet, some PERL > scripts and some tables. Please take a few moments to look > through this material. If there is anything unclear about > the proposal, I will try my best to answer questions on > this list. Reading your paragraph above, I was (again) struck by the contrast between the complexity of HD Ratio allocation and its utility. "A slide presentation, a spreadsheet, some PERL scripts and some tables"... and "if anything is unclear...I will try my best to answer questions" Seems to me that most people who must deal with the IP provisioning (allocation & assignment) process are looking for administrative ease and fairness in such policy. HD Ratio trades administrative ease off for fairness. Using HD Ratio increases the efficiencies (fairness) of provisioning policy by providing a more accurate assessment of utilization. This applies to all users, but its real value (relative to the 80% rule)is when large blocks are provisioned finely through a more extensive hierarchy. Not every segment of the industry 'truly' benefits but everyone would be subject to the increase complexity...all this as I understand it. Another way of achieving the same utility may be to change the 'percent utilization burden' for various entities with more or less extended provisioning hierarchy. You have a small hierarchy therefore you live with 80% (current standard)..others with increased hierarchy suffer a burden of only 70% and still others with the most extensive hierarchy use 60% as their threshold. Is there a way to measure the extensiveness of hierarchy...simply? This process would presume that you could conveniently (simply) measure or fairly assume hierarchy...and one would have to overcome the perception that organizations were being unfairly treated differently. The latter issues is really the same with HD Ratios, but is masked by its mathematical elegance and complexity...IMO. Both cases for change require an educational process and acceptance by the 'majority' of those active in ARIN policy matters in order to overcome the inertia of the status quo. Can hierarchy be measured simply?...or can it be assumed fairly? Seems that all else related to HD Ration flows from this question. Paul Wilson provides a chart http://www.apnic.net/mailing-lists/sig-policy/archive/2003/08/msg00000.html that "proposes a set of assumed hierarchical depths which may be reasonably expected within hierarchically-managed address spaces of certain sizes." Is there clear and concise empirical evidence to support these assumptions? Also, could you comment on why HD Ratio would be the preferred approach to change? Is the educational burden less to overcome the status quo of administrative ease than simply changing the percent utilization burden? I have no preference (officially), I'm just a little confused by these alternatives to change. Bill Darte ARIN AC From Michael.Dillon at radianz.com Wed Mar 24 09:50:33 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 24 Mar 2004 14:50:33 +0000 Subject: [ppml] Re: HD ratio proposal vs. Changing percentage burden Message-ID: >"A slide presentation, a spreadsheet, some PERL scripts and some tables"... >and "if anything is unclear...I will try my best to answer questions" Not everybody learns things the same way. Some people like to see graphs and charts and tables of numbers and a simple ratio calculation implemented in running code rather than abstractly described. The background pages are for them. >HD Ratio trades administrative ease off for fairness. Nope. The HD Ratio retains administrative ease, just changes the calculation of the threshold for entering a new application. And it increases fairness by recognizing that IP addresses are not like the peas on your dinner plate. If you leave peas behind on your plate, you are wasting food, plain and simple. But if you leave IP addresses unassigned to network devices you are not necessarily wasting any at all because the CIDR addressing structure requires that all subnet requirements be rounded up to be some integral number of blocks, each of which contains a power-of-2 addresses. And although sometimes you can use 3 /26's instead of a /24, this triples the number of route table entries you consume and therefore it does not scale. The HD Ratio helps people scale their networks. >Not every segment of the industry >'truly' benefits but everyone would be subject to the increase >complexity...all this as I understand it. That is true of last year's HD Ratio proposal but this year I made a lot of changes based on comments that I received from many people. That's why the word "choose" is in clause 1 of the proposal, and I quote: 1. Anyone who has already been allocated 4096 IPv4 addresses or more may choose to have additional requests for IPv4 addresses evaluated using an HD (Host Density) Ratio calculation to determine sufficient utilization instead of a fixed percentage threshold. >Also, could you comment on why HD Ratio would be the preferred approach to >change? Is the educational burden less to overcome the status quo of >administrative ease than simply changing the percent utilization burden? To date I have not seen any other proposal to change the 80% threshold. Now that we are using the HD Ratio for IPv6 allocations, I believe that the preferred approach is to bring IPv4 into alignment. Eventually we all will be using the HD Ratio. This policy proposal is a beginning because it offers the choice to change but does not mandate a schedule for change. It allows the breathing space necessary for everybody to learn how HD Ratio works and implement it at their own speed. --Michael Dillon From adb at onramp.ca Wed Mar 24 10:47:20 2004 From: adb at onramp.ca (Anthony DeBoer) Date: Wed, 24 Mar 2004 10:47:20 -0500 Subject: [ppml] Re: ASN-based prefixes for leaf ASes In-Reply-To: ; from william@elan.net on Mon, Mar 22, 2004 at 02:42:02AM -0800 References: <004f01c40feb$eff3ccc0$6401a8c0@ssprunk> Message-ID: <20040324104720.A22081@onramp.ca> william(at)elan.net wrote: > Now if you compare the policies for IPv4 ARIN does have a policy that > multihoming (i.e. = has ASN) is an automatic justification for /24 from > one of the upstreams. ... Speaking of which, is there no swamp space left unallocated, or available for reclamation? Using a /24 from an upstream has disadvantages; many backbones filter /24s in newer address space, and if the site later changes upstreams and drops the original one, they'll need to renumber. Ideally, since ARIN has to deal with the new multihomed site anyway to issue an ASN, a truly portable /24 could be issued along with it. -- Anthony DeBoer Onramp Technical Support From cscott at gaslightmedia.com Wed Mar 24 10:52:04 2004 From: cscott at gaslightmedia.com (Charles Scott) Date: Wed, 24 Mar 2004 10:52:04 -0500 (EST) Subject: [ppml] Background info for HD ratio proposal In-Reply-To: Message-ID: Michael: I'm sorry, but I keep having problems grasping the logic of this policy. What bothers me the most is that it's based on a concept that has some merit for address utilization but for which there has not been any compelling evidence that it has merit for address allocation. I do accept the problems with utilizing address space in a hierarchical manner and the need to do that with IP address space (*) but am concerned that extrapolating that to address allocation without any compelling logic is flawed. I would therefore support this policy if it specifically applied to end-user address utilization only, but am reluctant to support any broader scope. Chuck Scott * I still think that since address utilization efficiency can be significantly improved by overlaying a good initial deployment plan with other address space to fill in areas where address needs expand more than planned without significant concern for internal routing tables. The concept of efficiency is a pervasive thread through much existing ARIN policy and should always be a consideration of any policy change. Regardless, address utilization efficiency is different from address allocation efficiency. On Wed, 24 Mar 2004 Michael.Dillon at radianz.com wrote: > Policy Proposal 2004-2 proposes that we change the 80% threshold > for additional IPv4 address allocations to a sliding scale > formula based on the same type of Host Density (HD) Ratio as > we currently use for IPv6 allocations. The formal policy proposal > is on the ARIN site http://www.arin.net/policy/2004_2.html > and is up for a vote at the Vancouver meeting. . . . From John.Sweeting at teleglobe.com Wed Mar 24 11:03:35 2004 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Wed, 24 Mar 2004 11:03:35 -0500 Subject: [ppml] Re: HD ratio proposal vs. Changing percentage burden Message-ID: <1797AB680DD0D211898700902717803210ABD5F4@camtmms01.Teleglobe.CA> Michael, I can see your logic here but I have a few questions that I could not find the answers to in any of the materials (it could be that I just overlooked it): 1. How would the requestor prove utilization? Today a block that is further assigned or allocated and swipped is considered 100% utilized but that does not seem to be the case with the HD ratio, would you please share your views on this. 2. What is the significance of only allowing someone to use the HD after they qualify for a /20? just curious on this one. Thanks. -----Original Message----- From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] Sent: Wednesday, March 24, 2004 9:51 AM To: ppml at arin.net Subject: [ppml] Re: HD ratio proposal vs. Changing percentage burden >"A slide presentation, a spreadsheet, some PERL scripts and some tables"... >and "if anything is unclear...I will try my best to answer questions" Not everybody learns things the same way. Some people like to see graphs and charts and tables of numbers and a simple ratio calculation implemented in running code rather than abstractly described. The background pages are for them. >HD Ratio trades administrative ease off for fairness. Nope. The HD Ratio retains administrative ease, just changes the calculation of the threshold for entering a new application. And it increases fairness by recognizing that IP addresses are not like the peas on your dinner plate. If you leave peas behind on your plate, you are wasting food, plain and simple. But if you leave IP addresses unassigned to network devices you are not necessarily wasting any at all because the CIDR addressing structure requires that all subnet requirements be rounded up to be some integral number of blocks, each of which contains a power-of-2 addresses. And although sometimes you can use 3 /26's instead of a /24, this triples the number of route table entries you consume and therefore it does not scale. The HD Ratio helps people scale their networks. >Not every segment of the industry >'truly' benefits but everyone would be subject to the increase >complexity...all this as I understand it. That is true of last year's HD Ratio proposal but this year I made a lot of changes based on comments that I received from many people. That's why the word "choose" is in clause 1 of the proposal, and I quote: 1. Anyone who has already been allocated 4096 IPv4 addresses or more may choose to have additional requests for IPv4 addresses evaluated using an HD (Host Density) Ratio calculation to determine sufficient utilization instead of a fixed percentage threshold. >Also, could you comment on why HD Ratio would be the preferred approach to >change? Is the educational burden less to overcome the status quo of >administrative ease than simply changing the percent utilization burden? To date I have not seen any other proposal to change the 80% threshold. Now that we are using the HD Ratio for IPv6 allocations, I believe that the preferred approach is to bring IPv4 into alignment. Eventually we all will be using the HD Ratio. This policy proposal is a beginning because it offers the choice to change but does not mandate a schedule for change. It allows the breathing space necessary for everybody to learn how HD Ratio works and implement it at their own speed. --Michael Dillon From HRyu at norlight.com Wed Mar 24 11:04:54 2004 From: HRyu at norlight.com (Hyunseog Ryu) Date: Wed, 24 Mar 2004 10:04:54 -0600 Subject: [ppml] Re: ASN-based prefixes for leaf ASes Message-ID: I believe there is a policy for micro-allocation from ARIN. Hyun ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hyunseog Ryu / CCDA, MCSE, CCIE candidate(written test passed) Senior Network Engineer/Applications Engineering Norlight Telecommunications, Inc. 13935 Bishops Drive Brookfield, WI 53005 Tel. +1.262.792.7965 Fax. +1.262.792.7733 email: hryu at norlight.com Anthony DeBoer To: ppml at arin.net Sent by: cc: (bcc: Hyunseog Ryu/Brookfield/Norlight) owner-ppml at arin.n Fax to: et Subject: Re: [ppml] Re: ASN-based prefixes for leaf ASes 03/24/2004 09:47 AM william(at)elan.net wrote: > Now if you compare the policies for IPv4 ARIN does have a policy that > multihoming (i.e. = has ASN) is an automatic justification for /24 from > one of the upstreams. ... Speaking of which, is there no swamp space left unallocated, or available for reclamation? Using a /24 from an upstream has disadvantages; many backbones filter /24s in newer address space, and if the site later changes upstreams and drops the original one, they'll need to renumber. Ideally, since ARIN has to deal with the new multihomed site anyway to issue an ASN, a truly portable /24 could be issued along with it. -- Anthony DeBoer Onramp Technical Support From Michael.Dillon at radianz.com Wed Mar 24 11:49:57 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 24 Mar 2004 16:49:57 +0000 Subject: [ppml] Re: HD ratio proposal vs. Changing percentage burden Message-ID: >1. How would the requestor prove utilization? Today a block that is further >assigned or allocated and swipped is considered 100% utilized but that does >not seem to be the case with the HD ratio, would you please share your views >on this. I think that proof still has to be a private matter done under NDA between ARIN and the requestor as it is today. ARIN can and does ask for more information than is required in the whois if they need it to understand the situation. The definition of utilization is not changed by this policy. It would be the same as today. This policy counts utilized blocks the same way as before but it applies a different ratio calculation. >2. What is the significance of only allowing someone to use the HD after >they qualify for a /20? just curious on this one. If you look at the second slide in the presentation here http://www.arin.net/policy/documents/2004_2/HDRSlides/index.html you will see that if we don't have a starting size, then people with /24 and /23 blocks would have a higher threshold than today. Since this new policy is intended to help larger and growing networks like most ISPs have, I decided to start make it applicable at the /20 level which is the starting level for ISP allocations. --Michael Dillon From owen at delong.com Wed Mar 24 12:43:14 2004 From: owen at delong.com (Owen DeLong) Date: Wed, 24 Mar 2004 09:43:14 -0800 Subject: [ppml] Re: HD ratio proposal vs. Changing percentage burden In-Reply-To: References: Message-ID: <2147483647.1080121394@imac-en0.delong.sj.ca.us> Since it's now optional to use HD or the old calculation in your policy, I think the starting point is no longer necessary. Only the most mathematically challenged would choose HD below a /20. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Sat Mar 27 12:28:20 2004 From: owen at delong.com (Owen DeLong) Date: Sat, 27 Mar 2004 09:28:20 -0800 Subject: [ppml] Policy Proposal 2004-4: Purpose and scope of ARIN Whois Directory In-Reply-To: <200403171944.OAA01723@ops.arin.net> References: <200403171944.OAA01723@ops.arin.net> Message-ID: <2147483647.1080379700@imac-en0.delong.sj.ca.us> > 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. > I think that "Any" is two vague. How about something along the lines of: 4. When an ARIN resource is reassigned or reallocated to an organization, that organizations contact information may be published in the whois directory, so long as they make the guarantee detailed in item 3. > 5. All contacts listed in the whois directory will be contacted > periodically and the directory will indicate information which may > be stale if contact cannot be made promptly. > While I agree with the intent of this statement, I think it might be better expressed as: 5. ARIN will make periodic attempts to verify contact information and make a public notation on any entry which cannot be verified in a timely manner. > 6. Additionally, the whois directory will contain, directly or > indirectly, a record of all address blocks sub-allocated or > assigned by the entities mentioned in item 3. > > 7. The records mentioned in item 6 will not identify the organization or > individual receiving the address block or their exact location. These > records will only indicate an organizational type, the nearest > municipality providing postal service to the end user, state/province > and country. > I have serious problems with this, and, I think paragraph 7 should be stricken from this policy. I think that the combination of paragraph 6 and paragraph 4 more than adequately addresses this issue without any need for preventing good data from being available in paragraph 7. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jsw at five-elements.com Sat Mar 27 17:10:34 2004 From: jsw at five-elements.com (Jeff S Wheeler) Date: Sat, 27 Mar 2004 17:10:34 -0500 Subject: [ppml] Policy Proposal 2004-4: Purpose and scope of ARIN Whois Directory In-Reply-To: <2147483647.1080379700@imac-en0.delong.sj.ca.us> References: <200403171944.OAA01723@ops.arin.net> <2147483647.1080379700@imac-en0.delong.sj.ca.us> Message-ID: <1080425433.32206.80.camel@repulse.jsw.louisville.ky.us> On Sat, 2004-03-27 at 12:28, Owen DeLong wrote: > > 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. I haven't been following this proposal, so perhaps I'm asking a stupid question, but; does this mean that customers who don't have a qualified staff can't have their address space SWIP'd to them? How will ISPs show customer utilization of space if the customers are a small office without in-house I.T. staff; or co-location customers who may not be up to the job of fielding questions about "interconnect issues?" No one is going to comply with the above paragraph. They may as well ignore the entire proposal. Frankly, I don't see what the problem is with WHOIS today. You are far more likely to have problems with a SWIP'd entity who has no clued staff than you are with an ISP who is willing to hide abusive customers; and in any of these cases, you will end up dealing with the ISP anyway. Is the entire purpose of this proposal to force Level(3) to open their whois records to the public? -- jsw From william at elan.net Sat Mar 27 18:35:18 2004 From: william at elan.net (william(at)elan.net) Date: Sat, 27 Mar 2004 15:35:18 -0800 (PST) Subject: [ppml] Policy Proposal 2004-4: Purpose and scope of ARIN Whois Directory In-Reply-To: <1080425433.32206.80.camel@repulse.jsw.louisville.ky.us> Message-ID: On Sat, 27 Mar 2004, Jeff S Wheeler wrote: > On Sat, 2004-03-27 at 12:28, Owen DeLong wrote: > > > 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. > > I haven't been following this proposal, so perhaps I'm asking a stupid > question, but; does this mean that customers who don't have a qualified > staff can't have their address space SWIP'd to them? How will ISPs show > customer utilization of space if the customers are a small office > without in-house I.T. staff; or co-location customers who may not be up > to the job of fielding questions about "interconnect issues?" I think the intention is that for customers that do not have appropriate IT staff personal to be listed in ARIN directory, the ISPs should be considered primary contact in case of any problems and either list their own contacts or more appropriatly just do simple reassignment in which case ISP's orgid contacts are the ones listed in arin whois output. > Is the entire purpose of this proposal to force Level(3) to open their > whois records to the public? I do not see this as intent of this proposal, however different proposal 2003-5 on rwhois from last year that is currently under review of BoT will force L3 to open up their directory (at least that is what I was told by person who replied to me when I brought this up on ppml about month or two ago). -- William Leibzon Elan Networks william at elan.net From owen at delong.com Sun Mar 28 13:34:48 2004 From: owen at delong.com (Owen DeLong) Date: Sun, 28 Mar 2004 10:34:48 -0800 Subject: [ppml] Policy Proposal 2004-4: Purpose and scope of ARIN Whois Directory In-Reply-To: <1080425433.32206.80.camel@repulse.jsw.louisville.ky.us> References: <200403171944.OAA01723@ops.arin.net> <2147483647.1080379700@imac-en0.delong.sj.ca.us> <1080425433.32206.80.camel@repulse.jsw.louisville.ky.us> Message-ID: <2147483647.1080470088@imac-en0.delong.sj.ca.us> The proposal contains other language allowing for the ISP to take responsibility and SWIP the space with the ISPs contact information. If you read the whole proposal, you'll see it. Also, what you are attributing to me is actually, I believe, text I quoted from Michael Dillon's post. Owen --On Saturday, March 27, 2004 5:10 PM -0500 Jeff S Wheeler wrote: > On Sat, 2004-03-27 at 12:28, Owen DeLong wrote: >> > 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. > > I haven't been following this proposal, so perhaps I'm asking a stupid > question, but; does this mean that customers who don't have a qualified > staff can't have their address space SWIP'd to them? How will ISPs show > customer utilization of space if the customers are a small office > without in-house I.T. staff; or co-location customers who may not be up > to the job of fielding questions about "interconnect issues?" > > No one is going to comply with the above paragraph. They may as well > ignore the entire proposal. Frankly, I don't see what the problem is > with WHOIS today. You are far more likely to have problems with a > SWIP'd entity who has no clued staff than you are with an ISP who is > willing to hide abusive customers; and in any of these cases, you will > end up dealing with the ISP anyway. > > Is the entire purpose of this proposal to force Level(3) to open their > whois records to the public? > > -- jsw > > -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at radianz.com Mon Mar 29 09:04:10 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 29 Mar 2004 15:04:10 +0100 Subject: [ppml] Policy Proposal 2004-4: Purpose and scope of ARIN Whois Directory Message-ID: >> > 3. Organizations and individuals must guarantee to ARIN that contact >I haven't been following this proposal, so perhaps I'm asking a stupid >question, but; does this mean that customers who don't have a qualified >staff can't have their address space SWIP'd to them? No, it doesn't affect SWIP. You can still SWIP everything that you do now, however, ARIN will no longer publish all of the SWIPs in the whois directory. ARIN has always reserved the right to ask for more information than is shown in the whois directory if they need that information to analyse your utilization. >Is the entire purpose of this proposal to force Level(3) to open their >whois records to the public? Not at all. This proposal will force all ISPs to either accept responsibility as a contact point for all of the address space that they have allocated from ARIN, or mandate their customers (through contracts presumably) to take the responsibility themselves. People will no longer get false positives when querying the whois looking for a contact person. They will no longer have to backtrack up the allocation hierarchy looking for someone who will respond to their queries and solve the problem. This proposal will not solve all problems but it will ensure that the public whois directory has legitimate contact information for people who are ready, willing and able to communicate regarding network operations and interconnect issues and who is able to act on that communication. --Michael Dillon From Michael.Dillon at radianz.com Mon Mar 29 09:19:59 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 29 Mar 2004 15:19:59 +0100 Subject: [ppml] Policy Proposal 2004-4: Purpose and scope of ARIN Whois Directory Message-ID: >> 4. Any other organizations may elect to be listed in the whois >> directory as long as they make the guarantee detailed in item 3. >I think that "Any" is two vague. How about something along the lines of: >4. When an ARIN resource is reassigned or reallocated to an >organization, that organizations contact information may be published >in the whois directory, so long as they make the guarantee detailed in >item 3. Perhaps I should not have used "Any" Any other organization which has received a reassignment or reallocation of ARIN address space may elect to be listed in the whois directory as long as they make the guarantee detailed in item 3. I think that once a proposal is accepted by the members, the AC are free to tinker with the wording to clear up ambiguities like this. >> 5. All contacts listed in the whois directory will be contacted >While I agree with the intent of this statement, I think it might be better >expressed as: Again, my main intent was to require ARIN to regularly check the data validity and tell us where those checks were not being promptly validated. And I wanted to do this without specifying any details of how this would be done so as not to get into micro-managing ARIN staff through policy. If the AC can fix up wording to be clearer and less ambiguous, I'm all for it. >> 7. The records mentioned in item 6 will not identify the organization or >> individual receiving the address block or their exact location. These >> records will only indicate an organizational type, the nearest >> municipality providing postal service to the end user, state/province >> and country. >I have serious problems with this, and, I think paragraph 7 should be >stricken from this policy. I think that the combination of paragraph 6 >and paragraph 4 more than adequately addresses this issue without any >need for preventing good data from being available in paragraph 7. I don't understand your objections here.If we strike paragraph 7 then we have nothing to specify what is in these entries. An ISP could comply simply by listing the CIDR block that was allocated and no other information at all. This is an area where I think we need to be explicit and unambiguous. 6 and 7 do not refer to contact info, but to data published by ISPs that says, "here is the extent of our network", "this is where we are connecting sites to the global public Internet and how big they are". I'd actually like to see the ISPs get together and agree on some notation for these entries that would allow for better statistical analyses than we have today. You might want to reread points c), g), i) and j) in the notes attached to the proposed policy wording. --Michael Dillon From owen at delong.com Mon Mar 29 14:03:39 2004 From: owen at delong.com (Owen DeLong) Date: Mon, 29 Mar 2004 11:03:39 -0800 Subject: [ppml] Policy Proposal 2004-4: Purpose and scope of ARIN Whois Directory In-Reply-To: References: Message-ID: <2147483647.1080558219@imac-en0.delong.sj.ca.us> >>> 7. The records mentioned in item 6 will not identify the organization > or >>> individual receiving the address block or their exact location. > These >>> records will only indicate an organizational type, the nearest >>> municipality providing postal service to the end user, > state/province >>> and country. > >> I have serious problems with this, and, I think paragraph 7 should be >> stricken from this policy. I think that the combination of paragraph 6 >> and paragraph 4 more than adequately addresses this issue without any >> need for preventing good data from being available in paragraph 7. > > I don't understand your objections here.If we strike paragraph > 7 then we have nothing to specify what is in these entries. An ISP > could comply simply by listing the CIDR block that was allocated > and no other information at all. > Are we talking about the same paragraph 7 above? As I read the paragraph, it doesn't do anything to require information, simply prohibits certain information from being placed in the data. I quote: "The records mentioned in item 6 will not identify the organization or individual receiving the address block or their exact location." While I understand that there has been some support for residential customer privacy rules, this goes far beyond that contemplated in any of the proposals that have received support. I think the required contents of a whois record are adequately addressed in other policies. However, if you don't, and your intent here is to require certain things, then, I think paragraph 7 is in need of a pretty major rewrite. > This is an area where I think we need to be explicit and > unambiguous. 6 and 7 do not refer to contact info, but to > data published by ISPs that says, "here is the extent of our > network", "this is where we are connecting sites to the global > public Internet and how big they are". I'd actually like to see > the ISPs get together and agree on some notation for these entries > that would allow for better statistical analyses than we have > today. > OK... That's not how I understood the policy, and, I think if you re-read it from the frame of reference described above you will see that there is significant ambiguity in what 6 and 7 were referring to. I still think there is no need to prohibit the ISPs from including details. I don't like making them optional, but, there seems to be community support for that. However, there's a big difference between a right to privacy and enforced annonymity. > You might want to reread points c), g), i) and j) in the notes > attached to the proposed policy wording. > I might. However, the notes, as I understand it, do not take on the force of policy, and, as such, the policy is sufficiently ambiguous that I think it should be fixed. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From william at elan.net Mon Mar 29 16:41:05 2004 From: william at elan.net (william(at)elan.net) Date: Mon, 29 Mar 2004 13:41:05 -0800 (PST) Subject: [ppml] Policy Proposal 2004-4: Purpose and scope of ARIN Whois Directory In-Reply-To: Message-ID: On Mon, 29 Mar 2004 Michael.Dillon at radianz.com wrote: > >> > 3. Organizations and individuals must guarantee to ARIN that contact > > >I haven't been following this proposal, so perhaps I'm asking a stupid > >question, but; does this mean that customers who don't have a qualified > >staff can't have their address space SWIP'd to them? > > No, it doesn't affect SWIP. You can still SWIP everything that > you do now, however, ARIN will no longer publish all of the > SWIPs in the whois directory. ARIN has always reserved the > right to ask for more information than is shown in the whois > directory if they need that information to analyse your utilization. I don't agree with this. I would like to see SWIPs published for every legitimate record and ISPs make a decsision and either accept responsibility and in that case use simple reassignment and list their own contacts or they make sure customer accepts responsibility and is contactable and then its full reassignment or reallocation. -- William Leibzon Elan Networks william at elan.net From marla_azinger at eli.net Wed Mar 31 15:10:06 2004 From: marla_azinger at eli.net (Azinger, Marla) Date: Wed, 31 Mar 2004 12:10:06 -0800 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private N etwork Inter-Connectivity Message-ID: <10ECB7F03C568F48B9213EF9E7F790D207C9E7@wava00s2ke2k01.corp.pvt> Hello- In preperation for the 1/2 hour slot provided at the conference on this proposal...does anyone have any comments and/or input to this one? In order to make good use of the 1/2 hour this is slotted for... we would like to be fully prepared ahead of time for any angles that this discussion might take on. So your comments ahead of time either Pro or Con are greatly appreciated. Thank you for your time Marla Azinger -----Original Message----- From: Member Services [mailto:memsvcs at arin.net] Sent: Wednesday, March 17, 2004 11:43 AM To: ppml at arin.net Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Vancouver, Canada, scheduled for April 19-20, 2004. According to the ARIN Internet Resource Policy Evaluation Process the Advisory Council will evaluate policy proposals after the Public Policy Meeting. The feedback and discussion of policy proposals on the Public Policy Mailing List will be included in the AC's evaluation. Subscription information for the ARIN Public Policy Mailing List is available at http://www.arin.net/mailing_lists/index.html The ARIN Internet Resource Policy Evaluation Process is available at: http://www.arin.net/policy/ipep.html ARIN's Policy Proposal Archive is available at: http://www.arin.net/policy/proposal_archive.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2004-3: Global Addresses for Private Network Inter- Connectivity Author: Marla Azinger and Bill Copeland Policy statement: Interfaces that connect private networks may be assigned globally unique address space. Hosts within the administrative control of a single organization should still use private address space in accordance with RFC-1918 and RFC-2050. This policy is not intended to override other policies with regard to justification, minimum size, fees, or any other standard procedure. Rationale: RFC-1918 and RFC-2050 are somewhat ambiguous concerning the use of registered IP addresses when connecting separate private networks. Further, with the complexity of today's private interconnections, it is not feasible to coordinate RFC-1918 private space among many enterprises. Therefore, this proposal seeks to expressly allow the use of registered space on the interfaces between private networks. Many private networking scenarios present the address assignment problem that this proposal seeks to resolve. These include private network interconnections, Virtual Private Networks (VPNs) using a common layer 3 transport, and service provider RFC-2547 networks that establish multiple VPNs. In the RFC-2547 case, the VPNs are isolated via separate routing tables. However, the use of extranets, partnerships, and other shared applications between VPNs complicate the address assignment on the PE-CE links. RFC Considerations Per RFC-2050: "In order for the Internet to scale using existing technologies, use of regional registry services should be limited to the assignment of IP addresses for organizations meeting one or more of the following conditions: a) the organization has no intention of connecting to the Internet-either now or in the future-but it still requires a globally unique IP address. The organization should consider using reserved addresses from RFC-1918. If it is determined this is not possible, they can be issued unique (if not Internet routable) IP addresses. b) the organization is multi-homed with no favored connection. c) the organization's actual requirement for IP space is very large, for example, the network prefix required to cover the request is of length /18 or shorter." Based on experience, ARIN has interpreted the RFC consistently to mean that organizations not connected to the global, public Internet do not need globally unique IP address space. However, there is no specific policy for the situation described in this proposal. In addition, RFC-1918 says: "Hosts within enterprises that use IP can be partitioned into three categories: Category 1: hosts that do not require access to hosts in other enterprises or the Internet at large; hosts within this category may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Category 2: hosts that need access to a limited set of outside services (e.g., E-mail, FTP, netnews, remote login) which can be handled by mediating gateways (e.g., application layer gateways). For many hosts in this category an unrestricted external access (provided via IP connectivity) may be unnecessary and even undesirable for privacy/security reasons. Just like hosts within the first category, such hosts may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Category 3: hosts that need network layer access outside the enterprise (provided via IP connectivity); hosts in the last category require IP addresses that are globally unambiguous." It is clear that routers need access to each other, and the layer 3 VPN requires non-conflicting addresses between routers. To be specific and conservative, non-conflicting addresses between PE-CE links are required. So, while it is true that one VPN customer organization's router (host) may not need to reach another VPN customer organization's router (host), the VPN provider needs to reach both routers. In some cases, VPN customer organizations do need to be able to reach each other, as in the case of business partnerships or extranets. It should be noted that the authors of RFC-1918 made some consideration of this scenario, and the RFC seems to suggest that the private space it reserves should not be used for interconnected enterprises. However, there is no ARIN policy to allow for allocation for these enterprises. To recognize earlier work in this area, an Internet Draft was prepared to resolve the policy vacuum, known as internet-draft-guichard-pe-ce, by Jim Guichard et al. The draft proposed to use a large block, e.g., /8, to be used by all service providers for private interconnection purposes. The draft failed to reach consensus support. Finally, it should be noted that even if another addressing scheme is used, a router used to connect to a VPN may also be connected to the Internet. Network Address Translation (NAT) cannot be used in two instances on a single router in common practice. Any address space outside of RFC-1918 must be considered routable. Therefore, if the network local to the router uses RFC-1918 space and NAT is used to translate addresses back to the Internet, it cannot use another instance of NAT back to the VPN. Actual Network Case Study There are many different situations in which it seems public IP addresses are needed to support a widely used private network. For example, the E-911 networks facilitate confidential communication among Police Stations, Fire Stations, Sheriff Stations, State Trooper Stations and various other Emergency Response Programs. Background: Every city and state deploys E-911 services separately. This has created multiple private networks within every County in the United States. There is now an increasing effort to allow these separate entities to communicate with each other. This may be achieved by putting these individual E-911 networks onto one larger connected private network while at the same time leaving each individual network with its own autonomy. Since every separate private network is maintaining it's very own private network and utilizing the private IP blocks within it's own network...there are no private IP's easily identified for use in this connected private network. Also, due to the delicate nature of this E-911 network it is imperative that no IP range is utilized more than once. This leaves us with only one option. This option is to use public IP's on the E- 911 Connective Networks. Technical Translation: In some cases these are private networks, and in other cases these are Virtual Private Networks (VPN) using a common layer 3 transport. When these networks connect, there is the possibility that addresses assigned in good faith on one network may overlap addresses assigned in good faith on the other. This will cause routing instability and reachability problems. How this has been handled in the past? With or without the knowledge of the upstream provider, public IP addresses are already being used for these private networks. There is currently one specific company working with ELI for creating several of these "E-911 connected" private networks. This company has already obtained several different blocks from multiple large ISPs. Why bring this proposal to the table now? Two reasons exist: 1) to make the entire community aware of this situation, and, 2) to provide a clearly documented solution that is supported by ARIN and the Internet community. Meeting Considerations: Apr 2004 1st Day of Conference: Vote on yes or no to implement use of Public IP's for Private use when requirements are met. The initial vote should solely be based on "should we allow this to happen for company X if they fit the approved requirements list." Apr 2004 2nd Day of Conference: Vote on requirements and supporting questions detailed below in *proposal step 2. The second day/session will be used to vote in or out what will comprise the "approved requirements and who does the assigning". *Policy proposal step 2 Several issues remain should this proposal pass. 1. Should a special block of IP addresses be set aside for this application as suggested in the earlier work by Jim Guichard? a. Pro: This approach will potentially consume fewer addresses. b. Con: Networks using IP addresses for this purpose already exist and the operators will not want to renumber. A grandfather clause would be needed to protect those that are already using IP addresses in this manner. 2. Who should assign these IP's? Upstream and ARIN? a. Upstream Pro: Sometimes this is appropriate if the private network has an ISP that can accommodate the request. b. Upstream Con: Some service providers are their own ISP and need to resort to ARIN for additional address space. c. ARIN Pro: This is the only choice for major service providers. d. ARIN Con: This choice incurs more administrative overhead for ARIN. 3. What are the qualifications for an operator to be allocated IP addresses for this application? The following are acceptable applications of this proposal. a. Emergency Use (Police enforcement organizations, Fire departments, 911 dispatch units) b. Life support line (i.e. crisis hot lines and hospitals) c. Layer 3 VPN service providers d. RFC-2547 public service providers e. Other private networks not under the same administrative control that must interconnect. References: internet-draft-guichard-pe-ce-addr-03.txt. "Address Allocation for PE-CE links within a Provider Provisioned VPN Network," Jim Guichard, et al. ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-guichard-pe-ce-addr- 03.txt RFC2050. "INTERNET REGISTRY IP ALLOCATION GUIDELINES," Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg, Jon Postel. http://www.arin.net/library/rfc/rfc2050.txt RFC2547. "BGP/MPLS VPNs," Eric Rosen, Rakov Rekhter. http://www.ietf.org/rfc/rfc2547.txt RFC1918. "Address Allocation for Private Internets," Yakov Rekhter, Robert Moskowitz, Daniel Karrenberg, Geert Jan de Groot, Eliot Lear. http://www.arin.net/library/rfc/rfc1918.txt Timetable for implementation: This policy should be applied immediately, contingent upon final approval by the Board.