From billd at cait.wustl.edu Thu Nov 1 11:56:54 2001 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 1 Nov 2001 10:56:54 -0600 Subject: Policy 6 - Single organizations with multiple aggregation poi nts Message-ID: [* When applying for additional address space, from an RIR, for new networks or additional space for existing networks the organization must show greater than 50% utilization for the last block granted by the RIR and their allocations as a whole. Any reserved blocks must be allocated to a discrete network before the RIR will grant additional address space. This requirement defeats the purpose. If overall usage is measured then the minimum assignment by the RIR, currently /20 needs to be increased. If I am expected to rob from one network to support address depletion in another the blocks must be globally routable. mark huff integra telecom] The reference to 50% is "average" across all allocations... Therefore 3 nets of 20%, 40% and 90% would meet the hurdle... So... I encourage that 'average utilization' be incorporated. Bill Darte AC From John.Sweeting at teleglobe.com Thu Nov 1 12:54:13 2001 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Thu, 1 Nov 2001 12:54:13 -0500 Subject: Policy 6 - Single organizations with multiple aggregation poi nts Message-ID: <170E5E7779BCD3118C2A0008C7F40C190320119D@usresms03.teleglobe.com> One other critical point that you are missing is that: * An organization which would like to use this policy must apply for this policy to be applied to their maintainer account. Organizations wishing to continue with using multiple maintainer accounts would be free to do so. -----Original Message----- From: Bill Darte [mailto:billd at cait.wustl.edu] Sent: Thursday, November 01, 2001 11:57 AM To: 'Huff, Mark'; 'Andrew Dul'; ppml at arin.net Subject: RE: Policy 6 - Single organizations with multiple aggregation poi nts [* When applying for additional address space, from an RIR, for new networks or additional space for existing networks the organization must show greater than 50% utilization for the last block granted by the RIR and their allocations as a whole. Any reserved blocks must be allocated to a discrete network before the RIR will grant additional address space. This requirement defeats the purpose. If overall usage is measured then the minimum assignment by the RIR, currently /20 needs to be increased. If I am expected to rob from one network to support address depletion in another the blocks must be globally routable. mark huff integra telecom] The reference to 50% is "average" across all allocations... Therefore 3 nets of 20%, 40% and 90% would meet the hurdle... So... I encourage that 'average utilization' be incorporated. Bill Darte AC From huberman at gblx.net Thu Nov 1 13:02:44 2001 From: huberman at gblx.net (David R Huberman) Date: Thu, 1 Nov 2001 11:02:44 -0700 (MST) Subject: Policy 6 - Single organizations with multiple aggregation poi nts In-Reply-To: <170E5E7779BCD3118C2A0008C7F40C190320119D@usresms03.teleglobe.com> Message-ID: > One other critical point that you are missing is that: > > * An organization which would like to use this policy must apply for this > policy to be applied to their maintainer account. > > Organizations wishing to continue with using multiple maintainer accounts > would be free to do so. I still don't see why this language need even be included. ARIN analysts should automatically see that a provider is aggregating their address space - such aggregation is readily apparent when a requestor provides detailed utilization information. The onus should be on the ARIN staff to apply this policy where it is relevant, not for the requestor to have to prompt the staff. [That doesn't preclude the requestor from mentioning it, of course...] /david From John.Sweeting at teleglobe.com Thu Nov 1 13:08:19 2001 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Thu, 1 Nov 2001 13:08:19 -0500 Subject: Policy 6 - Single organizations with multiple aggregation poi nts Message-ID: <170E5E7779BCD3118C2A0008C7F40C190320119F@usresms03.teleglobe.com> David, I believe the point was that not every organization that currently has multiple maintainer accounts would want to fall under this policy so in order for them to have this new policy apply to them, they would ahve to request it. -----Original Message----- From: David R Huberman [mailto:huberman at gblx.net] Sent: Thursday, November 01, 2001 1:03 PM To: Sweeting, John Cc: ppml at arin.net Subject: RE: Policy 6 - Single organizations with multiple aggregation poi nts > One other critical point that you are missing is that: > > * An organization which would like to use this policy must apply for this > policy to be applied to their maintainer account. > > Organizations wishing to continue with using multiple maintainer accounts > would be free to do so. I still don't see why this language need even be included. ARIN analysts should automatically see that a provider is aggregating their address space - such aggregation is readily apparent when a requestor provides detailed utilization information. The onus should be on the ARIN staff to apply this policy where it is relevant, not for the requestor to have to prompt the staff. [That doesn't preclude the requestor from mentioning it, of course...] /david From jfleming at anet.com Thu Nov 1 13:21:50 2001 From: jfleming at anet.com (Jim Fleming) Date: Thu, 1 Nov 2001 12:21:50 -0600 Subject: Policy 6 - Single organizations with multiple aggregation poi nts References: Message-ID: <01ba01c16302$14c4a2c0$3e00a8c0@pamela> ----- Original Message ----- From: "David R Huberman" To: "Sweeting, John" Cc: Sent: Thursday, November 01, 2001 12:02 PM Subject: RE: Policy 6 - Single organizations with multiple aggregation poi nts > > One other critical point that you are missing is that: > > > > * An organization which would like to use this policy must apply for this > > policy to be applied to their maintainer account. > > > > Organizations wishing to continue with using multiple maintainer accounts > > would be free to do so. > > I still don't see why this language need even be included. ARIN analysts > should automatically see that a provider is aggregating their address > space - such aggregation is readily apparent when a requestor provides > detailed utilization information. The onus should be on the ARIN staff to > apply this policy where it is relevant, not for the requestor to have to > prompt the staff. [That doesn't preclude the requestor from mentioning it, > of course...] > Why isn't the entire process automated at this point in time ? There are web tools that interface to databases, and programs can analyze the existing allocations. Why are humans still making subjective decisions ? It all boils down to fairness. Which list do you think is more fair ? The "toy" IPv4 Internet Early Experimentation Allocations ? http://www.iana.org/assignments/ipv4-address-space or The Proof-of-Concept IPv8 Allocations ? http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt Why would people pay for Address Space, when it is FREE ? Jim Fleming http://www.DOT-BIZ.com http://www.in-addr.info 3:219 INFO From huberman at gblx.net Thu Nov 1 13:18:26 2001 From: huberman at gblx.net (David R Huberman) Date: Thu, 1 Nov 2001 11:18:26 -0700 (MST) Subject: Policy 6 - Single organizations with multiple aggregation poi nts In-Reply-To: <170E5E7779BCD3118C2A0008C7F40C190320119F@usresms03.teleglobe.com> Message-ID: Hi John, > I believe the point was that not every organization that currently has > multiple maintainer accounts would want to fall under this policy so in > order for them to have this new policy apply to them, they would ahve to > request it. Then if the language is intended for organizations currently managing multiple maintainers, shouldn't we just say something like: * Current members presently managing multiple maintainer accounts should contact the ARIN Hostmaster if they wish for this policy to apply to one or more of their current accounts. Just a suggestion /david From andrew at internap.com Thu Nov 1 13:29:16 2001 From: andrew at internap.com (Andrew Dul) Date: Thu, 1 Nov 2001 10:29:16 -0800 (PST) Subject: Policy 6 - Single organizations with multiple aggregation poi nts In-Reply-To: Message-ID: On Thu, 1 Nov 2001, David R Huberman wrote: > Hi John, > > > I believe the point was that not every organization that currently has > > multiple maintainer accounts would want to fall under this policy so in > > order for them to have this new policy apply to them, they would ahve to > > request it. That indeed was the intent. I was trying to clarify that groups that wanted to use this needed to ask and that this would not 'applied' without a group requesting it. > > Then if the language is intended for organizations currently managing > multiple maintainers, shouldn't we just say something like: > > * Current members presently managing multiple maintainer accounts > should contact the ARIN Hostmaster if they wish for this policy > to apply to one or more of their current accounts. > > Just a suggestion > /david > > I like this new language. From billd at cait.wustl.edu Thu Nov 1 14:13:29 2001 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 1 Nov 2001 13:13:29 -0600 Subject: Policy 6 - Single organizations with multiple aggregation poi nts Message-ID: I like this wording better too, because the onus should not be on ARIN staff to identify and recommend one relationship over another. bd -----Original Message----- From: Andrew Dul [mailto:andrew at internap.com] Sent: Thursday, November 01, 2001 12:29 PM To: David R Huberman Cc: Sweeting, John; ppml at arin.net Subject: RE: Policy 6 - Single organizations with multiple aggregation poi nts On Thu, 1 Nov 2001, David R Huberman wrote: > Hi John, > > > I believe the point was that not every organization that currently has > > multiple maintainer accounts would want to fall under this policy so in > > order for them to have this new policy apply to them, they would ahve to > > request it. That indeed was the intent. I was trying to clarify that groups that wanted to use this needed to ask and that this would not 'applied' without a group requesting it. > > Then if the language is intended for organizations currently managing > multiple maintainers, shouldn't we just say something like: > > * Current members presently managing multiple maintainer accounts > should contact the ARIN Hostmaster if they wish for this policy > to apply to one or more of their current accounts. > > Just a suggestion > /david > > I like this new language. From John.Sweeting at teleglobe.com Thu Nov 1 14:49:59 2001 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Thu, 1 Nov 2001 14:49:59 -0500 Subject: Policy 6 - Single organizations with multiple aggregation poi nts Message-ID: <170E5E7779BCD3118C2A0008C7F40C19032011A3@usresms03.teleglobe.com> David, I like the wording, I will be sure to bring this up when the AC holds it's conference call on the 9th. It seems that Bill D. liked it also. Thanks. John -----Original Message----- From: David R Huberman [mailto:huberman at gblx.net] Sent: Thursday, November 01, 2001 1:18 PM To: Sweeting, John Cc: ppml at arin.net Subject: RE: Policy 6 - Single organizations with multiple aggregation poi nts Hi John, > I believe the point was that not every organization that currently has > multiple maintainer accounts would want to fall under this policy so in > order for them to have this new policy apply to them, they would ahve to > request it. Then if the language is intended for organizations currently managing multiple maintainers, shouldn't we just say something like: * Current members presently managing multiple maintainer accounts should contact the ARIN Hostmaster if they wish for this policy to apply to one or more of their current accounts. Just a suggestion /david From John.Sweeting at teleglobe.com Mon Nov 5 10:40:47 2001 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Mon, 5 Nov 2001 10:40:47 -0500 Subject: Policy 6 - Single organizations with multiple aggregation poi nts Message-ID: <170E5E7779BCD3118C2A0008C7F40C19032011BA@usresms03.teleglobe.com> Just a quick reminder that we would like all comments/suggestions submitted to this list NLT 1200 AM (midnight) EST on November 8th. Thank you. -----Original Message----- From: Sweeting, John [mailto:John.Sweeting at teleglobe.com] Sent: Wednesday, October 31, 2001 10:24 AM To: 'Andrew Dul '; 'ppml at arin.net ' Subject: RE: Policy 6 - Single organizations with multiple aggregation poi nts Hello to all, I would like to inform the mailing list members of the results of the ARIN Advisory Council's discussion of this policy from our meeting last night, October 30th. The AC has agreed to support and forward this policy to the BOT in principle but would like your input as to the final wording of the proposal. The AC will hold a conference call on 9 November, 1100 AM EST, to finalize the wording and vote on endorsing this proposal to the BOT. Once we have agreed to the final wording, the proposal will be sent out to this list for final comments (IAW the ARIN Policy process it will be posted for 10 working days). Our goal is to have this all completed so that the BOT will be able to finalize this proposal during their December 11th meeting. We would like to have all recommendations and comments sent to this list NLT than 1200 AM (midnight) EST on November 8th. I will send out reminders over the next week to remind you all of this deadline. The AC would like to recognize Andrew for his involvement in the policy process and thank him for his time and commitment. Thank you. John -----Original Message----- From: Andrew Dul To: ppml at arin.net Sent: 10/31/01 9:25 AM Subject: Re: Policy 6 - Single organizations with multiple aggregation points Here is the revised text after discussions yesterday. ------ ARIN VIII - Policy Proposal 6 Single organizations with multi-homed discrete networks Criteria for the application of this policy: * The organization should be a single entity, and not a consortium of smaller independent entities. (Example: Not a group of independent network operators who form a group specifically for this policy) * This policy applies only to organizations that have been previously granted address space by an RIR. This policy does not apply to organizations with only legacy address space. * The organization must have multiple (at least two) discrete multi-homed networks. * The organization should have a compelling criteria for creating discrete networks. Examples: 1) regulatory restrictions for data transmission 2) geographic distance and diversity between networks 3) autonomous multi-homed discrete networks * An organization which would like to use this policy must apply for this policy to be applied to their maintainer account. Requirements for additional allocations from RIR: * The organization must record allocations or assignments down to the current RIR bit boundary (currently /29 for ARIN) and record them in an approved RIR public database. * The organization must keep detailed records of how it has allocated space to each discrete network. This should include the block allocated, any reserved blocks, and date of allocation/reservation. The discrete network allocation information should also be present in a public database (Example: routing registry, rWhois, or SWIP). * The organization must not allocate additional space to a discrete network unless all the blocks allocated to that network show utilization greater than 80% individually and as a whole. * The organization must not allocate a CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to a new network. * The organization must not allocate an additional CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to an existing network, unless previous growth rates for that network indicate that it is likely to utilize a larger CIDR block before the time the organization will be requesting an additional block from the RIR. The suggested minimum allocation size for an additional block for a network is the current minimum assignment size of the RIR. * When allocating a block larger than the minimum assignment size to an existing network the organization should use the smallest allocation possible out of a larger reserved block. This requirement is to reduce the number of routes the organization will announce from that autonomous system. Example: A fast growing network is allocated a /20 out of a reserved /19, when the /20 is 80% utilized the announcement is expanded to a /19 and the /20 announcement is removed. This practice also allows the reserved /20 to be used by another discrete network should the 'fast growing network' not use the address space as anticipated. * When applying for additional address space, from an RIR, for new networks or additional space for existing networks the organization must show greater than 50% utilization for the last block granted by the RIR and their allocations as a whole. Any reserved blocks must be allocated to a discrete network before the RIR will grant additional address space. * The organization must follow guidelines of RFC 2050 (or its replacement) and the policy of the granting RIR for allocations that are assigned or allocated to downstream networks. This includes record keeping of allocation and reassignment requests and network utilization documents for audits by the RIR. From louie at equinix.com Mon Nov 5 12:26:20 2001 From: louie at equinix.com (Louis Lee) Date: Mon, 5 Nov 2001 09:26:20 -0800 Subject: Policy 6 - Single organizations with multiple aggregation points In-Reply-To: <170E5E7779BCD3118C2A0008C7F40C19032011BA@usresms03.teleglobe.com>; from John.Sweeting@teleglobe.com on Mon, Nov 05, 2001 at 10:40:47AM -0500 References: <170E5E7779BCD3118C2A0008C7F40C19032011BA@usresms03.teleglobe.com> Message-ID: <20011105092620.A6509@nemo.corp.equinix.com> > From: Andrew Dul > Sent: 10/31/01 9:25 AM > Subject: Re: Policy 6 - Single organizations with multiple > aggregation points > > Here is the revised text after discussions yesterday. > > ------ > > ARIN VIII - Policy Proposal 6 > Single organizations with multi-homed discrete networks > > Criteria for the application of this policy: > * The organization must have multiple (at least two) discrete > multi-homed networks. > > * The organization should have a compelling criteria for > creating discrete networks. > Examples: 1) regulatory restrictions for data transmission > 2) geographic distance and diversity between networks > 3) autonomous multi-homed discrete networks So it was proposed that the original text with "must" be changed to "should" in the above point. Having either one indicates that there is a judgement over the "compelling-ness" of the criteria in the organization's network design. How about if we alter it to say: * The organization must state its criteria for creating discrete networks. [keep examples] Of course, I'm playing devil's advocate here, since I like having the "compelling criteria" text in there. It would force the organization to think twice about their network design before requesting for this policy to be applied to them. On another point, do we need to briefly define "discrete multi-homed networks" or "discrete networks"? I understand what Andrew means by it, but there seemed to have been some confusion during last week's meetings. In addition, many organizations reading this text may not have the benefit of our discussions for clarification. Your thoughts? > * The organization must keep detailed records of how it has > allocated space to each discrete network. This should include > the block allocated, any reserved blocks, and date of > allocation/reservation. The discrete network allocation > information should also be present in a public database > (Example: routing registry, rWhois, or SWIP). > > * The organization must not allocate additional space to a > discrete network unless all the blocks allocated to that > network show utilization greater than 80% individually and > as a whole. Louie ----------------------------------------------------------------- Louis Lee louie at equinix.com Network Engineer office: 650/316-6162 Equinix, Inc. fax: 650/316-6903 http://www.equinix.com/ From barbara at gblx.net Mon Nov 5 13:42:36 2001 From: barbara at gblx.net (Barbara Roseman) Date: Mon, 5 Nov 2001 11:42:36 -0700 (MST) Subject: Policy 2001-2, Multihoming is sufficient justification for /24 from provider Message-ID: During the ARIN Advisory Council meeting of October 30th the AC voted to accept this policy and forward it to the ARIN BOT with the following amendments Original Proposal: A downstream customer's multihoming requirement will serve as justification for a /24 reassignment from their upstream ISP regardless of host requirements. -Customer must cite their asn as justification for address space -Customer may receive space from only one of its upstream providers without additional justification This a last call for community comment on this policy prior to the ARIN Board of Trustees review of the proposed policy. This policy will be posted on the ARIN website and the ARIN Public Policy email list. Please send your comments to ppml at arin.net. This last call will expire on 23:59 EST 19 Nov 01, 2001. --- Barbara Roseman Sr. Manager, FACT Global Crossing Office: +1 408-542-0147 Cell: +1 917-498-1677 broseman at gblx.net From huberman at gblx.net Mon Nov 5 13:42:27 2001 From: huberman at gblx.net (David R Huberman) Date: Mon, 5 Nov 2001 11:42:27 -0700 (MST) Subject: Policy 6 - Single organizations with multiple aggregation poi nts In-Reply-To: <200111051829.fA5ITL950771@duchess.groovy.com> Message-ID: Hello CJ, In further discussions in the thread, it was made clear to me the language was intended for members already managing multiple maintainer accounts. This fact was not known to me when I wrote my reply you quoted.. In subsequent posts, I suggested alternative policy language which seems to have been adopted. In the case of organizations not currently managing multiple maintainer accounts *and* aggregating their address space, I still believe it is the responsibility of the ARIN RSG to point the requestor to the new policy and clearly explain their options. ARIN's mission is very much educational - a basic part of that mission is relying on the RSG to educate requestors about policies [especially new ones]. /david From huberman at gblx.net Mon Nov 5 14:06:26 2001 From: huberman at gblx.net (David R Huberman) Date: Mon, 5 Nov 2001 12:06:26 -0700 (MST) Subject: Policy 6 - Single organizations with multiple aggregation poi nts In-Reply-To: <200111051850.fA5IoY950985@duchess.groovy.com> Message-ID: > In the case of organizations not currently managing multiple maintainer > accounts *and* aggregating their address space, I still believe it is the > responsibility of the ARIN RSG to point the requestor to the new policy > and clearly explain their options. ARIN's mission is very much educational > - a basic part of that mission is relying on the RSG to educate requestors > about policies [especially new ones]. > > Not sure what you mean by "aggregating their address space". The > distinct reason for this policy is that folks like Andrew can't > aggregate their address space because they have multiple non > contiguous networks. If an ISP doesn't have multiple maintainers > and has a contiguous network (and aggregating its address space) > then I don't see how that organization fits into this policy. My responses stem from my experiences as an analyst at ARIN. There were other organizations, besides Internap, who also fit into this policy. Many only managed one address pool from ARIN, but struggled under the rules - hence my vocal support for this policy. /david From barbara at gblx.net Mon Nov 5 15:16:18 2001 From: barbara at gblx.net (Barbara Roseman) Date: Mon, 5 Nov 2001 13:16:18 -0700 (MST) Subject: corrected: Policy 2001-2, Multihoming is sufficient justification for /24 from provider (fwd) Message-ID: During the ARIN Advisory Council meeting of October 30th the AC voted to accept this policy and forward it to the ARIN BOT with the following amendments Original Proposal: A downstream customer's multihoming requirement will serve as justification for a /24 reassignment from their upstream ISP regardless of host requirements. -Customer must cite their asn as justification for address space -Customer may receive space from only one of its upstream providers without additional justification This a last call for community comment on this policy prior to the ARIN Board of Trustees review of the proposed policy. This policy will be posted on the ARIN website and the ARIN Public Policy email list. Please send your comments to ppml at arin.net. This last call will expire on 23:59 EST 19 Nov 16, 2001. --- Barbara Roseman Sr. Manager, FACT Global Crossing Office: +1 408-542-0147 Cell: +1 917-498-1677 broseman at gblx.net From ebohlin at UU.NET Mon Nov 5 17:40:10 2001 From: ebohlin at UU.NET (Einar Bohlin) Date: Mon, 5 Nov 2001 17:40:10 -0500 Subject: corrected: Policy 2001-2, Multihoming is sufficient justification for /24 from provider (fwd) In-Reply-To: ; from barbara@gblx.net on Mon, Nov 05, 2001 at 01:16:18PM -0700 References: Message-ID: <20011105174010.A11663@uu.net> The following requirement makes the policy unworkable and should be replaced: "-Customer must cite their asn as justification for address space" There's a catch-22 here in that ARIN won't give the customer an ASN until the customer has a net, and the ISP won't be able to give the customer the /24 until the customer can show their ASN. This won't work. It should be "-Customer cites intent to multihome as justification for address space". This lets ARIN continue to do their job of registering AS numbers, and allows ISPs to conduct business with their customers. FYI I tried to see the original wording, but the link on the ARIN main site is broken (LAST CALL: Policy 2001-2... points to ASO election results). Regards, Einar Bohlin IP Planning Analyst WorldCom, Inc. Phone: USA 703 886-7362 email: einar.bohlin at wcom.com On Mon, Nov 05, 2001 at 01:16:18PM -0700, Barbara Roseman wrote: > During the ARIN Advisory Council meeting of October 30th the AC voted to > accept this policy and forward it to the ARIN BOT with the following > amendments > > Original Proposal: A downstream customer's multihoming requirement will > serve as justification for a /24 reassignment from > their upstream ISP regardless of host requirements. > > -Customer must cite their asn as justification for address space > -Customer may receive space from only one of its upstream providers > without additional justification > > This a last call for community comment on this policy prior to the > ARIN Board of Trustees review of the proposed policy. This policy > will be posted on the ARIN website and the ARIN Public Policy email > list. Please send your comments to ppml at arin.net. This last call > will expire on 23:59 EST 19 Nov 16, 2001. > > > --- > Barbara Roseman > Sr. Manager, FACT > Global Crossing > Office: +1 408-542-0147 > Cell: +1 917-498-1677 > broseman at gblx.net > > > > > From barbara at gblx.net Mon Nov 5 17:56:07 2001 From: barbara at gblx.net (Barbara Roseman) Date: Mon, 5 Nov 2001 15:56:07 -0700 (MST) Subject: corrected: Policy 2001-2, Multihoming is sufficient justification for /24 from provider (fwd) In-Reply-To: <20011105174010.A11663@uu.net> Message-ID: On Mon, 5 Nov 2001, Einar Bohlin wrote: > The following requirement makes the policy unworkable > and should be replaced: > > "-Customer must cite their asn as justification for address space" > > There's a catch-22 here in that ARIN won't give > the customer an ASN until the customer has a net, > and the ISP won't be able to give the customer the /24 > until the customer can show their ASN. This > won't work. ARIN will provide an ASN to anyone who can document their intent to multihome, usually by showing contracts with providers, invoices for equipment, and network plans. > > It should be "-Customer cites intent to multihome as > justification for address space". This lets ARIN > continue to do their job of registering AS numbers, > and allows ISPs to conduct business with their customers. > ISPs would end up having to do the same justification work as ARIN does to prove intent to multihome, which seems an unreasonable burden on the ISPs. If the customer already has the ASN in hand, the ISP can rely on ARIN having already vetted the multihoming plan. > FYI I tried to see the original wording, but the > link on the ARIN main site is broken (LAST CALL: > Policy 2001-2... points to ASO election results). >From the PPML archive: http://www.arin.net/mailinglists/ppml/0321.html > > Regards, > > Einar Bohlin > IP Planning Analyst > WorldCom, Inc. > Phone: USA 703 886-7362 > email: einar.bohlin at wcom.com > From John.Sweeting at teleglobe.com Mon Nov 5 18:03:10 2001 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Mon, 5 Nov 2001 18:03:10 -0500 Subject: corrected: Policy 2001-2, Multihoming is sufficient justifica tion for /24 from provider (fwd) Message-ID: <170E5E7779BCD3118C2A0008C7F40C19032011D3@usresms03.teleglobe.com> That would leave a big hole for anyone to say that they intend to become multi-homed. They should already have address space assigned to them but probably in a much smaller block, such as a /28 or so, and then once they become multi-homed they would want a /24 so they would have a better chance of not being filtered. My feeling is that they should have an ASN before being able to justify a /24 under this policy. -----Original Message----- From: Einar Bohlin [mailto:ebohlin at UU.NET] Sent: Monday, November 05, 2001 5:40 PM To: ppml at arin.net Subject: Re: corrected: Policy 2001-2, Multihoming is sufficient justification for /24 from provider (fwd) The following requirement makes the policy unworkable and should be replaced: "-Customer must cite their asn as justification for address space" There's a catch-22 here in that ARIN won't give the customer an ASN until the customer has a net, and the ISP won't be able to give the customer the /24 until the customer can show their ASN. This won't work. It should be "-Customer cites intent to multihome as justification for address space". This lets ARIN continue to do their job of registering AS numbers, and allows ISPs to conduct business with their customers. FYI I tried to see the original wording, but the link on the ARIN main site is broken (LAST CALL: Policy 2001-2... points to ASO election results). Regards, Einar Bohlin IP Planning Analyst WorldCom, Inc. Phone: USA 703 886-7362 email: einar.bohlin at wcom.com On Mon, Nov 05, 2001 at 01:16:18PM -0700, Barbara Roseman wrote: > During the ARIN Advisory Council meeting of October 30th the AC voted to > accept this policy and forward it to the ARIN BOT with the following > amendments > > Original Proposal: A downstream customer's multihoming requirement will > serve as justification for a /24 reassignment from > their upstream ISP regardless of host requirements. > > -Customer must cite their asn as justification for address space > -Customer may receive space from only one of its upstream providers > without additional justification > > This a last call for community comment on this policy prior to the > ARIN Board of Trustees review of the proposed policy. This policy > will be posted on the ARIN website and the ARIN Public Policy email > list. Please send your comments to ppml at arin.net. This last call > will expire on 23:59 EST 19 Nov 16, 2001. > > > --- > Barbara Roseman > Sr. Manager, FACT > Global Crossing > Office: +1 408-542-0147 > Cell: +1 917-498-1677 > broseman at gblx.net > > > > > From ebohlin at UU.NET Mon Nov 5 19:28:07 2001 From: ebohlin at UU.NET (Einar Bohlin) Date: Mon, 5 Nov 2001 19:28:07 -0500 Subject: corrected: Policy 2001-2, Multihoming is sufficient justification for /24 from provider (fwd) In-Reply-To: ; from barbara@gblx.net on Mon, Nov 05, 2001 at 03:56:07PM -0700 References: <20011105174010.A11663@uu.net> Message-ID: <20011105192806.B28228@uu.net> I wasn't going to keep pushing this, but I see it as a little monkeywrench in a system full of little monkeywrenches. :> ARIN will provide an ASN to anyone who can document their intent to > multihome, usually by showing contracts with providers, invoices f or > equipment, and network plans. > That seems a little much. I though you had to have minimum two connections (and give contacts for verification) and list the net(s) that comprise the AS. No net, no AS, no need for an ASN makes sense to me. > ISPs would end up having to do the same justification work as ARIN does to > prove intent to multihome, which seems an unreasonable burden on t he ISPs. > If the customer already has the ASN in hand, the ISP can rely on A RIN > having already vetted the multihoming plan. I'm not saying ISPs do anything more than ask, "are you going to be multihomed?" and getting a yes or no reply. Just like today. I'm for keeping the process simple. To me, when the customer says they are multihoming, that should be enough. Then either they have an ASN or they will be getting one. Why should the fact that they are getting one in the future stop me from assigning the net now? Because they might be trying to get an unjustified /24? That's ridiculous, there's easier ways to do that. Also, there is the value of one ASN vs one /24 to think about. Today an ASN is more valuable than a /24, so why push customers to get an ASN they might not need? Example, customer says, "yes, we're multihoming". We assign a /24. When we configure them we ask for the ASN which we need for the config; if they've changed their minds about multihoming, we revisit their IP need based on host count and adjust as necessary. Just like we do today. We should not say that a customer has to go get an ASN in order to get IPs. Regards, Einar Bohlin IP Planning Analyst WorldCom, Inc. Phone: USA 703 886-7362 email: einar.bohlin at wcom.com On Mon, Nov 05, 2001 at 03:56:07PM -0700, Barbara Roseman wrote: > On Mon, 5 Nov 2001, Einar Bohlin wrote: > > > The following requirement makes the policy unworkable > > and should be replaced: > > > > "-Customer must cite their asn as justification for address space" > > > > There's a catch-22 here in that ARIN won't give > > the customer an ASN until the customer has a net, > > and the ISP won't be able to give the customer the /24 > > until the customer can show their ASN. This > > won't work. > > ARIN will provide an ASN to anyone who can document their intent to > multihome, usually by showing contracts with providers, invoices for > equipment, and network plans. > > > > > It should be "-Customer cites intent to multihome as > > justification for address space". This lets ARIN > > continue to do their job of registering AS numbers, > > and allows ISPs to conduct business with their customers. > > > > ISPs would end up having to do the same justification work as ARIN does to > prove intent to multihome, which seems an unreasonable burden on the ISPs. > If the customer already has the ASN in hand, the ISP can rely on ARIN > having already vetted the multihoming plan. > > > > FYI I tried to see the original wording, but the > > link on the ARIN main site is broken (LAST CALL: > > Policy 2001-2... points to ASO election results). > > >From the PPML archive: > > http://www.arin.net/mailinglists/ppml/0321.html > > > > > Regards, > > > > Einar Bohlin > > IP Planning Analyst > > WorldCom, Inc. > > Phone: USA 703 886-7362 > > email: einar.bohlin at wcom.com > > > From martind at UU.NET Mon Nov 5 19:59:54 2001 From: martind at UU.NET (Dawn Martin) Date: Mon, 5 Nov 2001 19:59:54 -0500 Subject: corrected: Policy 2001-2, Multihoming is sufficient justifica tion for /24 from provider (fwd) In-Reply-To: <170E5E7779BCD3118C2A0008C7F40C19032011D3@usresms03.teleglobe.com>; from "Sweeting, John" on Nov 05, 2001 at 06:03:10PM References: <170E5E7779BCD3118C2A0008C7F40C19032011D3@usresms03.teleglobe.com> Message-ID: <20011105195954.C2565@uu.net> ARIN's current justifications are: a) Unique Routing Policy Please explain how your routing policy is different from your provider. b) Multi-homed Site If your organization is currently multi-homed, please explain exactly how you are connected to the Internet to include the following information: i) Exterior gateway protocol to be used ii) The IP network addresses that will make up your AS iii) Technical point of contact information for each of your upstream providers/peers should include: In this discussion we are talking about b. Most of our cutomers are using BGP, for ARIN to issue the ASN the customer HAS to have the IP blocks and the tech contacts. So, if we require the customer to have an ASN to get the block and ARIN requires them to have a netblock before they get the ASN. Where do they go? APNIC? Either, this policies wording needs to change or ARIN's jusitifcation for an AS number needs to change. Which is it? I would rather see this policies wording changed. -Dawn Martin Quoth Sweeting, John (John.Sweeting at teleglobe.com): > That would leave a big hole for anyone to say that they intend to become > multi-homed. They should already have address space assigned to them but > probably in a much smaller block, such as a /28 or so, and then once they > become multi-homed they would want a /24 so they would have a better chance > of not being filtered. My feeling is that they should have an ASN before > being able to justify a /24 under this policy. > > -----Original Message----- > From: Einar Bohlin [mailto:ebohlin at UU.NET] > Sent: Monday, November 05, 2001 5:40 PM > To: ppml at arin.net > Subject: Re: corrected: Policy 2001-2, Multihoming is sufficient > justification for /24 from provider (fwd) > > > The following requirement makes the policy unworkable > and should be replaced: > > "-Customer must cite their asn as justification for address space" > > There's a catch-22 here in that ARIN won't give > the customer an ASN until the customer has a net, > and the ISP won't be able to give the customer the /24 > until the customer can show their ASN. This > won't work. > > It should be "-Customer cites intent to multihome as > justification for address space". This lets ARIN > continue to do their job of registering AS numbers, > and allows ISPs to conduct business with their customers. > > FYI I tried to see the original wording, but the > link on the ARIN main site is broken (LAST CALL: > Policy 2001-2... points to ASO election results). > > Regards, > > Einar Bohlin > IP Planning Analyst > WorldCom, Inc. > Phone: USA 703 886-7362 > email: einar.bohlin at wcom.com > > > On Mon, Nov 05, 2001 at 01:16:18PM -0700, Barbara Roseman wrote: > > During the ARIN Advisory Council meeting of October 30th the AC voted to > > accept this policy and forward it to the ARIN BOT with the following > > amendments > > > > Original Proposal: A downstream customer's multihoming requirement will > > serve as justification for a /24 reassignment from > > their upstream ISP regardless of host requirements. > > > > -Customer must cite their asn as justification for address space > > -Customer may receive space from only one of its upstream providers > > without additional justification > > > > This a last call for community comment on this policy prior to the > > ARIN Board of Trustees review of the proposed policy. This policy > > will be posted on the ARIN website and the ARIN Public Policy email > > list. Please send your comments to ppml at arin.net. This last call > > will expire on 23:59 EST 19 Nov 16, 2001. > > > > > > --- > > Barbara Roseman > > Sr. Manager, FACT > > Global Crossing > > Office: +1 408-542-0147 > > Cell: +1 917-498-1677 > > broseman at gblx.net > > > > > > > > > > From John.Sweeting at teleglobe.com Tue Nov 6 09:28:08 2001 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Tue, 6 Nov 2001 09:28:08 -0500 Subject: corrected: Policy 2001-2, Multihoming is sufficient justifica tion for /24 from provider (fwd) Message-ID: <170E5E7779BCD3118C2A0008C7F40C19032011D5@usresms03.teleglobe.com> agree, the customer should have the ASN from ARIN before being considered for approval under this policy by their providers. -----Original Message----- From: CJ Wittbrodt [mailto:cjw at duchess.groovy.com] Sent: Monday, November 05, 2001 7:04 PM To: Sweeting, John Cc: 'Einar Bohlin'; ppml at arin.net Subject: Re: corrected: Policy 2001-2, Multihoming is sufficient justifica tion for /24 from provider (fwd) You know ISPs already get this informationfrom their customers to determine whether they are multihomed or not and they already give the customer a /24 based on that. They have to provide that justification before they can get more address space from ARIN. If the customer has to go to ARIN, prove it's multihoming to get an ASN, then it should be able to use that ASN and justification to get the block. I think what we need is clarification of what ARIN requires of someone requesting an ASN. Sure someone could lie but if they are going to they already are to get the ASN. I suspect that ARIN requires some proof like signed contracts, etc, to verify that they are going to multihome. Wouldn't that be enough? ---CJ From: "Sweeting, John" Subject: RE: corrected: Policy 2001-2, Multihoming is sufficient justifica tion for /24 from provider (fwd) That would leave a big hole for anyone to say that they intend to become multi-homed. They should already have address space assigned to them but probably in a much smaller block, such as a /28 or so, and then once they become multi-homed they would want a /24 so they would have a better chance of not being filtered. My feeling is that they should have an ASN before being able to justify a /24 under this policy. -----Original Message----- From: Einar Bohlin [mailto:ebohlin at UU.NET] Sent: Monday, November 05, 2001 5:40 PM To: ppml at arin.net Subject: Re: corrected: Policy 2001-2, Multihoming is sufficient justification for /24 from provider (fwd) The following requirement makes the policy unworkable and should be replaced: "-Customer must cite their asn as justification for address space" There's a catch-22 here in that ARIN won't give the customer an ASN until the customer has a net, and the ISP won't be able to give the customer the /24 until the customer can show their ASN. This won't work. It should be "-Customer cites intent to multihome as justification for address space". This lets ARIN continue to do their job of registering AS numbers, and allows ISPs to conduct business with their customers. FYI I tried to see the original wording, but the link on the ARIN main site is broken (LAST CALL: Policy 2001-2... points to ASO election results). Regards, Einar Bohlin IP Planning Analyst WorldCom, Inc. Phone: USA 703 886-7362 email: einar.bohlin at wcom.com On Mon, Nov 05, 2001 at 01:16:18PM -0700, Barbara Roseman wrote: > During the ARIN Advisory Council meeting of October 30th the AC voted to > accept this policy and forward it to the ARIN BOT with the following > amendments > > Original Proposal: A downstream customer's multihoming requirement will > serve as justification for a /24 reassignment from > their upstream ISP regardless of host requirements. > > -Customer must cite their asn as justification for address space > -Customer may receive space from only one of its upstream providers > without additional justification > > This a last call for community comment on this policy prior to the > ARIN Board of Trustees review of the proposed policy. This policy > will be posted on the ARIN website and the ARIN Public Policy email > list. Please send your comments to ppml at arin.net. This last call > will expire on 23:59 EST 19 Nov 16, 2001. > > > --- > Barbara Roseman > Sr. Manager, FACT > Global Crossing > Office: +1 408-542-0147 > Cell: +1 917-498-1677 > broseman at gblx.net > > > > > From barbara at gblx.net Tue Nov 6 13:04:46 2001 From: barbara at gblx.net (Barbara Roseman) Date: Tue, 6 Nov 2001 11:04:46 -0700 (MST) Subject: corrected: Policy 2001-2, Multihoming is sufficient justifica tion for /24 from provider (fwd) In-Reply-To: <170E5E7779BCD3118C2A0008C7F40C19032011D5@usresms03.teleglobe.com> Message-ID: The current ARIN ASN registration guidelines read as follows: "In order to be assigned an ASN, each requesting organization must provide ARIN with verification that it has one of the following: "A unique routing policy (its policy differs from its border gateway peers) "A multi-homed site. "ASNs are issued based on current need. An organization should request an ASN only when it is already multi-homed or will immediately become multi-homed." The "immediately become multi-homed" section seems most relevant to this discussion. I would suggest that for the purposes of the ASN request template, an acceptable statement for b) ii) could be "/24 to be provided by upstream provider x or y". I agree with Cathy that we need to get Registration Services to make the call on this one so we aren't creating what Einar identified as a Catch 22. -Barb On Tue, 6 Nov 2001, Sweeting, John wrote: > agree, the customer should have the ASN from ARIN before being considered > for approval under this policy by their providers. > > -----Original Message----- > From: CJ Wittbrodt [mailto:cjw at duchess.groovy.com] > Sent: Monday, November 05, 2001 7:04 PM > To: Sweeting, John > Cc: 'Einar Bohlin'; ppml at arin.net > Subject: Re: corrected: Policy 2001-2, Multihoming is sufficient > justifica tion for /24 from provider (fwd) > > > > You know ISPs already get this informationfrom their customers > to determine whether they are multihomed or not and they already > give the customer a /24 based on that. They have to provide > that justification before they can get more address space from > ARIN. If the customer has to go to ARIN, prove it's multihoming > to get an ASN, then it should be able to use that ASN and justification > to get the block. I think what we need is clarification of what > ARIN requires of someone requesting an ASN. Sure someone could lie > but if they are going to they already are to get the ASN. I suspect > that ARIN requires some proof like signed contracts, etc, to verify > that they are going to multihome. Wouldn't that be enough? > > ---CJ > > From: "Sweeting, John" > Subject: RE: corrected: Policy 2001-2, Multihoming is sufficient > justifica > tion for /24 from provider (fwd) > That would leave a big hole for anyone to say that they intend to become > multi-homed. They should already have address space assigned to them but > probably in a much smaller block, such as a /28 or so, and then once > they > become multi-homed they would want a /24 so they would have a better > chance > of not being filtered. My feeling is that they should have an ASN before > being able to justify a /24 under this policy. > > -----Original Message----- > From: Einar Bohlin [mailto:ebohlin at UU.NET] > Sent: Monday, November 05, 2001 5:40 PM > To: ppml at arin.net > Subject: Re: corrected: Policy 2001-2, Multihoming is sufficient > justification for /24 from provider (fwd) > > > The following requirement makes the policy unworkable > and should be replaced: > > "-Customer must cite their asn as justification for address space" > > There's a catch-22 here in that ARIN won't give > the customer an ASN until the customer has a net, > and the ISP won't be able to give the customer the /24 > until the customer can show their ASN. This > won't work. > > It should be "-Customer cites intent to multihome as > justification for address space". This lets ARIN > continue to do their job of registering AS numbers, > and allows ISPs to conduct business with their customers. > > FYI I tried to see the original wording, but the > link on the ARIN main site is broken (LAST CALL: > Policy 2001-2... points to ASO election results). > > Regards, > > Einar Bohlin > IP Planning Analyst > WorldCom, Inc. > Phone: USA 703 886-7362 > email: einar.bohlin at wcom.com > From mborchers at splitrock.net Tue Nov 6 15:15:18 2001 From: mborchers at splitrock.net (Borchers, Mark) Date: Tue, 6 Nov 2001 14:15:18 -0600 Subject: corrected: Policy 2001-2, Multihoming is sufficient justifica tion for /24 from provider (fwd) Message-ID: Isn't the intent of the policy simply to give ISP's the leeway to assign /24's to multihomed customers in contradiction of other policies intended to conserve address space? Thus, the policy is not so much a guarantee of space to the end site as it is a way to indemnify ISP's in the business of accounting for usage. As such, perhaps ARIN need not get into the issue of whether it's OK to assign the space before the customer has their ASN. ASN's are more finite than address space and the bar for qualifying for them should be higher. Keep the requirement in place to have the /24, and let ISP's work with their customers as they are in the process of obtaining ASN's. It would be up to the ISP whether to actually assign the space, assign it on a conditional basis, or just reserve it. > The current ARIN ASN registration guidelines read as follows: > > "In order to be assigned an ASN, each requesting organization > must provide > ARIN with verification that it has one of the following: > > "A unique routing policy (its policy differs from its border gateway > peers) > "A multi-homed site. > > "ASNs are issued based on current need. An organization > should request an > ASN only when it is already multi-homed or will immediately become > multi-homed." > > The "immediately become multi-homed" section seems most > relevant to this > discussion. I would suggest that for the purposes of the ASN request > template, an acceptable statement for b) ii) could be "/24 > to be provided > by upstream provider x or y". > > I agree with Cathy that we need to get Registration Services > to make the > call on this one so we aren't creating what Einar identified > as a Catch > 22. > > -Barb > > On Tue, 6 Nov 2001, Sweeting, John wrote: > > > agree, the customer should have the ASN from ARIN before > being considered > > for approval under this policy by their providers. > > > > > -----Original Message----- > > From: CJ Wittbrodt [mailto:cjw at duchess.groovy.com] > > Sent: Monday, November 05, 2001 7:04 PM > > To: Sweeting, John > > Cc: 'Einar Bohlin'; ppml at arin.net > > Subject: Re: corrected: Policy 2001-2, Multihoming is sufficient > > justifica tion for /24 from provider (fwd) > > > > > > > > You know ISPs already get this informationfrom their customers > > to determine whether they are multihomed or not and they already > > give the customer a /24 based on that. They have to provide > > that justification before they can get more address space from > > ARIN. If the customer has to go to ARIN, prove it's multihoming > > to get an ASN, then it should be able to use that ASN and > justification > > to get the block. I think what we need is clarification of what > > ARIN requires of someone requesting an ASN. Sure someone could lie > > but if they are going to they already are to get the ASN. I suspect > > that ARIN requires some proof like signed contracts, etc, to verify > > that they are going to multihome. Wouldn't that be enough? > > > > ---CJ > > > > From: "Sweeting, John" > > Subject: RE: corrected: Policy 2001-2, Multihoming is sufficient > > justifica > > tion for /24 from provider (fwd) > > That would leave a big hole for anyone to say that they > intend to become > > multi-homed. They should already have address space > assigned to them but > > probably in a much smaller block, such as a /28 or so, > and then once > > they > > become multi-homed they would want a /24 so they would > have a better > > chance > > of not being filtered. My feeling is that they should > have an ASN before > > being able to justify a /24 under this policy. > > > > -----Original Message----- > > From: Einar Bohlin [mailto:ebohlin at UU.NET] > > Sent: Monday, November 05, 2001 5:40 PM > > To: ppml at arin.net > > Subject: Re: corrected: Policy 2001-2, Multihoming is sufficient > > justification for /24 from provider (fwd) > > > > > > The following requirement makes the policy unworkable > > and should be replaced: > > > > "-Customer must cite their asn as justification for > address space" > > > > There's a catch-22 here in that ARIN won't give > > the customer an ASN until the customer has a net, > > and the ISP won't be able to give the customer the /24 > > until the customer can show their ASN. This > > won't work. > > > > It should be "-Customer cites intent to multihome as > > justification for address space". This lets ARIN > > continue to do their job of registering AS numbers, > > and allows ISPs to conduct business with their customers. > > > > FYI I tried to see the original wording, but the > > link on the ARIN main site is broken (LAST CALL: > > Policy 2001-2... points to ASO election results). > > > > Regards, > > > > Einar Bohlin > > IP Planning Analyst > > WorldCom, Inc. > > Phone: USA 703 886-7362 > > email: einar.bohlin at wcom.com > > > > From MSchoenecker at yipes.com Tue Nov 6 18:33:58 2001 From: MSchoenecker at yipes.com (Mike Schoenecker) Date: Tue, 6 Nov 2001 16:33:58 -0700 Subject: Policy 6 Message-ID: <424769F9B8BE6249825C23CFCA0A4247BE0405@denexh01.yipes.com> Thanks, I know that this was a controversial issue but it definitely opens the door for opportunity. From jfleming at anet.com Wed Nov 7 10:17:38 2001 From: jfleming at anet.com (Jim Fleming) Date: Wed, 7 Nov 2001 09:17:38 -0600 Subject: 0:212 .BIZ IPv8 Address Space Management, will be in good hands.... Message-ID: <06ff01c1679f$57e87e40$3e00a8c0@pamela> It looks like the 0:212 .BIZ IPv8 Address Space Management (ASM), will be in good hands. After over 7 years, .BIZ appears to be moving beyond the Proof-of-Concept Phase. http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt 0:212 [whois.pacificroot.com] Domain Name: in-addr.biz Registrant: ARNI Leah Gallegos P.O. Box 9305 virginia beach, VA 23450-9305 United States Telephone: 757-631-9838 Fax: 000-000-0000 Email: admin at biztld.net Created: 20001025.2020 Last Modified: 20001025.2020 DNS Servers: ns1.pacificroot.com ns2.pacificroot.com ------------------------------------------ Domain name: in-addr.biz Registrant: Strateji.NET Ersel Demirel (ersel at nyc.com) 12018665604 FAX: none 4506Parkave.#2 Weehawken, NJ 07087 US DOMAIN CREATED : 2001-11-07 00:00:00 DOMAIN EXPIRES : 2003-11-07 00:00:00 NAMESERVERS: dns1.enom.com dns2.enom.com -------------------------------------------- "ICANN represents that it has no authority to implement new TLDs" http://www.icann.org/tlds/correspondence/esi-v-icann-13nov00.htm It all boils down to fairness. Which list do you think is more fair ? The "toy" IPv4 Internet Early Experimentation Allocations ? http://www.iana.org/assignments/ipv4-address-space or The Proof-of-Concept IPv8 Allocations ? http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt Why would people pay for Address Space, when it is FREE ? Jim Fleming http://www.DOT-BIZ.com http://www.in-addr.info 3:219 INFO From memsvcs at arin.net Mon Nov 12 14:33:51 2001 From: memsvcs at arin.net (Member Services) Date: Mon, 12 Nov 2001 14:33:51 -0500 (EST) Subject: Last Call for Comment: Policy Proposal 2001-2 Message-ID: <200111121933.OAA24638@ops.arin.net> The ARIN Advisory Council voted to forward to the ARIN Board of Trustees the following policy. This a last call for community comment on this policy prior to the ARIN Board of Trustees review of the proposed policy. This policy will be posted on the ARIN website and the ARIN Public Policy email list. Please send your comments to ppml at arin.net. This last call will expire at 23:59 EST on November 23, 2001. Ray Plzak President American Registry for Internet Numbers (ARIN) *** Last Call - Policy Proposal 2001-2 *** A downstream customer's multihoming requirement will serve as justification for a /24 reassignment from their upstream ISP regardless of host requirements. - Customer must provide contact information for their upstream providers - Customer may receive space from only one of its upstream providers without additional justification. From memsvcs at arin.net Mon Nov 12 14:35:12 2001 From: memsvcs at arin.net (Member Services) Date: Mon, 12 Nov 2001 14:35:12 -0500 (EST) Subject: Last Call for Comment: Policy Proposal 2001-3 Message-ID: <200111121935.OAA24838@ops.arin.net> The ARIN Advisory Council voted to forward to the ARIN Board of Trustees the following policy. This a last call for community comment on this policy prior to the ARIN Board of Trustees review of the proposed policy. This policy will be posted on the ARIN website and the ARIN Public Policy email list. Please send your comments to ppml at arin.net. This last call will expire at 23:59 EST on November 23, 2001. Ray Plzak President American Registry for Internet Numbers (ARIN) *** Last Call - Policy Proposal 2001-3 *** Extend the existing IPv4 micro-allocation policy for exchange points, gTLDs, ccTLDs, RIRs, and ICANN to include IPv6 micro-allocations. ARIN's current IPv4 micro-allocation policy is documented at: http://www.arin.net/regserv/ip-assignment.html The assignment size under this policy will be a /64, or multiple /64s, if justified. From memsvcs at arin.net Mon Nov 12 14:36:20 2001 From: memsvcs at arin.net (Member Services) Date: Mon, 12 Nov 2001 14:36:20 -0500 (EST) Subject: Call for Comment: Policy Proposal 2001-6 Message-ID: <200111121936.OAA24951@ops.arin.net> The ARIN Advisory Council voted to forward to the ARIN Board of Trustees the following policy. This a last call for community comment on this policy prior to the ARIN Board of Trustees review of the proposed policy. This policy will be posted on the ARIN website and the ARIN Public Policy email list. Please send your comments to ppml at arin.net. This last call will expire at 23:59 EST on November 23, 2001. Ray Plzak President American Registry for Internet Numbers (ARIN) *** Last Call - Policy Proposal 2001-6 *** ARIN currently has an allocation policy that is 'blind' to route Filtering and global routablity, yet in order for address space to be usable it must be accepted and routed by the community at large. This fact can create allocation concerns for organizations that have multiple discrete multi-homed networks. Organizations may design their networks in this manner for a number of reasons including regulatory restrictions (Federal FCC mandated inter-lata restrictions), geographic diversity/distance between networks, and routing policy. Current RIR allocation policy requires that before a single organization can obtain additional address space it must show 80% utilization (through SWIP or rWhois) per RFC 2050. Currently, some organizations have circumvented this requirement by Creating "multiple maintainers" with ARIN and request address space for networks as though they were separate organizations. This practice creates both practical and financial concerns for ARIN. In practice it appears that organizations can just 'buy' additional address space without regard to utilization on other networks and this in turn increases ARIN's revenue dependence on a small number of organizations. Current allocation requirements can become unreasonable when operating a set of discrete networks for organizations which intend on following the current allocations policy. Discrete networks must often have separate unique globally routable address space and will often grow at different rates. This growth differential can lead to a situation where one discrete network is completely allocated but another network has not yet been fully utilized. Under the current allocation policy the organization would need to Request additional address space from the RIR; however, given a strict interpretation of the existing policy, the RIR may not be able to grant additional address space to the organization, due to the 80% utilization requirement. This constraint can easily be seen when you consider an organization with two geographically discrete autonomous networks. The organization initially requested a /19 from the RIR for its two networks with the intent to route a single /20 from each network. Network A's utilization grows considerably faster than Network B. Network A is currently showing 90% utilization and needs additional address space for new customers being added to this network. Network B's address space is being utilized but currently only shows 40% utilization. This would produce an allocation utilization percentage of 65% which is below the requirement for additional address space by a RIR. We propose for organizations which meet the following criteria to be granted the opportunity to request additional address space under the requirements listed below. Criteria for the application of this policy: * The organization should be a single entity, and not a consortium of smaller independent entities. (Example: Not a group of independent network operators who form a group specifically for this policy) * This policy applies only to organizations that have been previously granted address space by an RIR. This policy does not apply to organizations with only legacy address space. * The organization must have multiple (at least two) discrete multi-homed networks. * The organization should have compelling criteria for creating discrete networks. Examples: 1) regulatory restrictions for data transmission 2) geographic distance and diversity between networks 3) autonomous multi-homed discrete networks * An organization which would like to use this policy must apply for this policy to be applied to their maintainer account. Requirements for additional allocations from RIR: * The organization must record allocations or assignments down to the current RIR bit boundary (currently /29 for ARIN) and record them in an approved RIR public database. * The organization must keep detailed records of how it has allocated space to each discrete network. This should include the block allocated, any reserved blocks, and date of allocation/reservation. The discrete network allocation information should also be present in a public database (Example: routing registry, rWhois, or SWIP). * The organization must not allocate additional space to a discrete network unless all the blocks allocated to that network show utilization greater than 80% individually and as a whole. * The organization must not allocate a CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to a new network. * The organization must not allocate an additional CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to an existing network, unless previous growth rates for that network indicate that it is likely to utilize a larger CIDR block before the time the organization will be requesting an additional block from the RIR. The suggested minimum allocation size for an additional block for a network is the current minimum assignment size of the RIR. * When allocating a block larger than the minimum assignment size to an existing network the organization should use the smallest allocation possible out of a larger reserved block. This requirement is to reduce the number of routes the organization will announce from that autonomous system. Example: A fast growing network is allocated a /20 out of a reserved /19, when the /20 is 80% utilized the announcement is expanded to a /19 and the /20 announcement is removed. This practice also allows the reserved /20 to be used by another discrete network should the 'fast growing network' not use the address space as anticipated. * When applying for additional address space, from an RIR, for new networks or additional space for existing networks the organization must show greater than 50% utilization for the last block granted by the RIR and their allocations as a whole. Any reserved blocks must be allocated to a discrete network before the RIR will grant additional address space. * The organization must follow guidelines of RFC 2050 (or its replacement)and the policy of the granting RIR for allocations that are assigned or allocated to downstream networks. This includes record keeping of allocation and reassignment requests and network utilization documents for audits by the RIR. * Current members presently managing multiple maintainer accounts should contact the ARIN Hostmaster if they wish for this policy to apply to one or more of their current accounts. From memsvcs at arin.net Mon Nov 12 14:37:28 2001 From: memsvcs at arin.net (Member Services) Date: Mon, 12 Nov 2001 14:37:28 -0500 (EST) Subject: Subject: Last Call for Comment: Policy Proposal 2001-7 Message-ID: <200111121937.OAA25221@ops.arin.net> The ARIN Advisory Council voted to forward to the ARIN Board of Trustees the following policy. This a last call for community comment on this policy prior to the ARIN Board of Trustees review of the proposed policy. This policy will be posted on the ARIN website and the ARIN Public Policy email list. Please send your comments to ppml at arin.net. This last call will expire at 23:59 EST on November 23, 2001. Ray Plzak President American Registry for Internet Numbers (ARIN) *** Last Call - Policy Proposal 2001-7 *** It is proposed ARIN provide a bulk copy of WHOIS output, minus point of contact information, on the ARIN FTP site for download by any organization that wishes to obtain the data providing they agree to ARIN's acceptable use policy. From huberman at gblx.net Tue Nov 13 10:41:52 2001 From: huberman at gblx.net (David R Huberman) Date: Tue, 13 Nov 2001 08:41:52 -0700 (MST) Subject: FreeIPdb released Message-ID: Hello, As promised, Global Crossing API is pleased to announce the release of FreeIPdb Version 1.0 at: http://www.freeipdb.org FreeIPdb is an open-source suite of tools allowing you to manage your IPv4 and IPv6 address space and address space assignments in the most efficient manner possible. Future versions will incorporate RWHOIS, SWIP, and inetnum capabilities. Enjoy the tools and please subscribe to the mailing lists for support and to provide us feedback. /david *--------------------------------* | Global Crossing API | | Manager, Global IP Addressing | | (703) 627-5800 | | huberman at gblx.net | *--------------------------------* From jfleming at anet.com Tue Nov 13 11:08:04 2001 From: jfleming at anet.com (Jim Fleming) Date: Tue, 13 Nov 2001 10:08:04 -0600 Subject: FreeIPdb released References: Message-ID: <006701c16c5d$619b2380$3200a8c0@pamela> This will be very useful for all of the new Address Space Managers (ASMs). Jim Fleming http://www.IPv8.info IPv16....One Better !! Why would people pay for Address Space, when it is FREE ? http://www.DOT-BIZ.com http://www.in-addr.info 3:219 INFO ----- Original Message ----- From: "David R Huberman" To: ; Sent: Tuesday, November 13, 2001 9:41 AM Subject: FreeIPdb released > Hello, > > As promised, Global Crossing API is pleased to announce the release of > FreeIPdb Version 1.0 at: > > http://www.freeipdb.org > > FreeIPdb is an open-source suite of tools allowing you to manage your IPv4 > and IPv6 address space and address space assignments in the most efficient > manner possible. > > Future versions will incorporate RWHOIS, SWIP, and inetnum capabilities. > > Enjoy the tools and please subscribe to the mailing lists for support and > to provide us feedback. > > /david > > *--------------------------------* > | Global Crossing API | > | Manager, Global IP Addressing | > | (703) 627-5800 | > | huberman at gblx.net | > *--------------------------------* > > From Trevor.Paquette at TeraGo.ca Tue Nov 13 13:48:26 2001 From: Trevor.Paquette at TeraGo.ca (Trevor Paquette) Date: Tue, 13 Nov 2001 11:48:26 -0700 Subject: Last Call for Comment: Policy Proposal 2001-2 In-Reply-To: <200111121933.OAA24638@ops.arin.net> Message-ID: <001a01c16c73$c7d04ac0$3102a8c0@teraint.net> By adopting this policy I think the following points should be made: 1) IPv4 exhaustion v4 space will be used at a higher rate, with an increase of wasted space. More and more companies are beginning to rely on the internet to conduct their day to day business operations (Raise your hand if you've heard complaints from customers when email is not delivered within 5 minutes after they hit 'send'). As such, these companies will begin to look at providing their own redundant links to the Internet (via multi-homing) and not depend on the redundancy of their upstream provider. This 'always connected' (vs 'always on') requirement will increase IP requests to upstream providers. 2) Potential for abuse of the policy to secure IP space. I can see companies begin to abuse Policy 2001-2 to secure a /24 and use very little address space out of that block. Some companies will lie about being or becoming multi-homed in order to secure more IP space then they really need. In today's world, revenue is king. If I have to tell a customer because they are no longer multi-homed (or they lied about it), that I have to pull their IP space; and they threaten to terminate their service with us; guess who is going to win. The customer. Very few Senior Executives understand or care about IP Policy; their job is to make the company money, keep the revenues flowing. If that means the customer gets to keep their /24; so be it. 3) The current AS limit. As a few folks have mentioned before that AS numbers are a much scarcer commodity then IP space. I agree with that statement. Policy 2001-2 will make the AS space run out faster. (Do we need to propose an new policy or an RFC on increasing AS size?) 4) Reclaimation How does an ISP reclaim the IP space (here comes the key phrase) "without losing that customer", should the customer decide one day that they no longer want to be multi-homed? Is it up to the ISP that gave the IP space in the first place to periodically check to make sure that the customer is in fact still multi-homed? (which brings up point 2 again) Remember, I'm not saying that these points will happen. I'm saying that these are very possible scenarios. My apologies if this has been discussed before; I was in Nassau during the hurricane (very little Internet access in Nassau, even more so during the storm and the days following it) and I just got home to start catching up on things. Trev -- Trevor Paquette |TeraGo Networks Inc. |Work:(403)668-5321 Trevor.Paquette at TeraGo.ca|300, 300 Manning Rd NE|Cell:(403)703-8738 Lead Systems Architect |Calgary, AB, Canada |Main:(403)668-5300 http://www.terago.ca | T2E 4K8 | Fax:(403)668-5344 From Trevor.Paquette at TeraGo.ca Tue Nov 13 14:30:15 2001 From: Trevor.Paquette at TeraGo.ca (Trevor Paquette) Date: Tue, 13 Nov 2001 12:30:15 -0700 Subject: Subject: Last Call for Comment: Policy Proposal 2001-7 In-Reply-To: <200111121937.OAA25221@ops.arin.net> Message-ID: <002201c16c79$a27e18a0$3102a8c0@teraint.net> As per the consensus at the Public Policy meeting, I think this policy should be passed as is to the BoT. -- Trevor Paquette |TeraGo Networks Inc. |Work:(403)668-5321 Trevor.Paquette at TeraGo.ca|300, 300 Manning Rd NE|Cell:(403)703-8738 Lead Systems Architect |Calgary, AB, Canada |Main:(403)668-5300 http://www.terago.ca | T2E 4K8 | Fax:(403)668-5344 From jfleming at anet.com Tue Nov 13 15:02:38 2001 From: jfleming at anet.com (Jim Fleming) Date: Tue, 13 Nov 2001 14:02:38 -0600 Subject: Subject: Last Call for Comment: Policy Proposal 2001-7 References: <002201c16c79$a27e18a0$3102a8c0@teraint.net> Message-ID: <030101c16c7e$26000860$3200a8c0@pamela> ----- Original Message ----- From: "Trevor Paquette" To: Sent: Tuesday, November 13, 2001 1:30 PM Subject: RE: Subject: Last Call for Comment: Policy Proposal 2001-7 > As per the consensus at the Public Policy meeting, I think > this policy should be passed as is to the BoT. > > -- > > Trevor Paquette |TeraGo Networks Inc. |Work:(403)668-5321 > Trevor.Paquette at TeraGo.ca|300, 300 Manning Rd NE|Cell:(403)703-8738 > Lead Systems Architect |Calgary, AB, Canada |Main:(403)668-5300 > http://www.terago.ca | T2E 4K8 | Fax:(403)668-5344 > > If I recall, ICANN uses a capital C, when they write consensus. It is good to see that ARIN has a different style consensus, but the outcome is the same as ICANN. It all boils down to fairness. Which list do you think is more fair ? The "toy" IPv4 Internet Early Experimentation Allocations ? http://www.iana.org/assignments/ipv4-address-space or The Proof-of-Concept IPv8 Allocations ? http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt Why would people pay for Address Space, when it is FREE ? Jim Fleming http://www.DOT-BIZ.com http://www.in-addr.info 3:219 INFO From dgolding at sockeye.com Tue Nov 13 18:56:38 2001 From: dgolding at sockeye.com (Daniel Golding) Date: Tue, 13 Nov 2001 18:56:38 -0500 Subject: Last Call for Comment: Policy Proposal 2001-2 In-Reply-To: <001a01c16c73$c7d04ac0$3102a8c0@teraint.net> Message-ID: to address the issues raised by Trevor Paquette... In regard to your first point, I strongly disagree that this policy will cause an increase in wasted IP space. Currently, it is common knowledge that a /24 is, more or less, globally routable. Thus, customers generally demand, and generally receive /24s upon requests, for the purpose of multihoming. In those circumstances where ISPs demand additional justification for the /24 allocation, the customer will either provide it (if they have it), or lie in order to receive it. As there are numerous legitimate multihomed enterprises that can not justify a /24 via current standard, we have a significant amount of false justification. This isn't because people are dishonest - it's because there is a business requirement in many cases to multihome, and an exaggerated justification is the only way to do it. Any policy that encourages normally honest people to deceive ARIN or an upstream ISP in order to achieve a legitimate purpose is, ipso facto, contrary to the good of the internet community, as open and honest communications between issuer and issue is essential. Therefore, IPv4 exhaustion will not occur any sooner - it will occur at the same rate. However, the general level of honesty and open communication will rise, which is a worthy goal. In regard to your second point, I disagree that customers will take advantage of this policy to illegitimately secure IP space. There is almost no reason for a customer to request a /24 unless they intend to multihome. Even if they feel they need it, checking for the issuance of an AS, and receiving the customer's assurance that they will multihome should be sufficient. I don't think anyone will be going back to police their customers - however, it will be appropriate to ensure compliance with previous allocations at the time of a request for new allocation. If additional allocations are made for internal political reasons by an ISP, they will need to be able to justify them to ARIN. If an organization is so shortsighted that it would issue space to customers irresponsibly, this policy proposal will neither accentuate nor ameliorate that irresponsibility. In the end, such practices tend to "catch up" to ISPs - usually when they are trying to get additional space from ARIN. In regard to your third point, I'm confused. Is your assertion that making it easier to get globally routable blocks will promote multihoming? If so, you are correct in that assertion. However, ARIN is meeting the demands of it's membership in promoting multihoming. Your concerns in regard to AS number depletion are currently being addressed in the IETF IDR working group's draft: BGP support for four-octet AS number space, draft-ietf-idr-as4bytes-04.txt. At the current rate of AS depletion, there should be sufficient AS numbers for 4 to 6 years into the future. This draft should be implemented will before then. Your forth point is only tangentially related to this policy proposal. Ensuring that customers meet, and then continue to meet, requirements for the allocation of IP space has long been the responsibility of their upstream provider. Although this can be a difficult issue, service providers should continue their current policies in this regard, which generally adhere to the idea of requiring justification at time of issuance, and then requiring additional justification (As well as confirmation of previous justification) upon additional address request. This is the general model upon which ARIN related to it's member-customers, and is a good model for it's members to use in relation to their own customers. No one is being required to be an "IP Address Cop" to the detriment of their business. However, everyone is required to act responsibly to safeguard a public resource. This policy proposal does not alter that axiom. Needless to say, I support Policy Proposal 2001-2, and urge the ARIN BoD to adopt it at their earliest convenience. Sincerely, Daniel Golding > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > Trevor Paquette > Sent: Tuesday, November 13, 2001 1:48 PM > To: ppml at arin.net > Subject: RE: Last Call for Comment: Policy Proposal 2001-2 > > > > By adopting this policy I think the following points should be made: > > 1) IPv4 exhaustion > v4 space will be used at a higher rate, with an increase of > wasted space. > More and more companies are beginning to rely on the internet > to conduct > their day to day business operations (Raise your hand if you've heard > complaints from customers when email is not delivered within 5 minutes > after they hit 'send'). As such, these companies will begin to look at > providing their own redundant links to the Internet (via multi-homing) > and not depend on the redundancy of their upstream provider. > This 'always > connected' (vs 'always on') requirement will increase IP requests to > upstream providers. > > 2) Potential for abuse of the policy to secure IP space. > I can see companies begin to abuse Policy 2001-2 to secure a /24 > and use very little address space out of that block. Some > companies will > lie about being or becoming multi-homed in order to secure > more IP space > then they really need. > > In today's world, revenue is king. If I have to tell a customer because > they are no longer multi-homed (or they lied about it), that I have to > pull their IP space; and they threaten to terminate their service with > us; guess who is going to win. The customer. Very few Senior Executives > understand or care about IP Policy; their job is to make the company > money, keep the revenues flowing. If that means the customer gets to > keep their /24; so be it. > > 3) The current AS limit. > As a few folks have mentioned before that AS numbers are a much scarcer > commodity then IP space. I agree with that statement. Policy > 2001-2 will > make the AS space run out faster. (Do we need to propose an new policy > or an RFC on increasing AS size?) > > 4) Reclaimation > How does an ISP reclaim the IP space (here comes the key > phrase) "without > losing that customer", should the customer decide one day that they no > longer want to be multi-homed? Is it up to the ISP that gave > the IP space > in the first place to periodically check to make sure that the > customer is > in fact still multi-homed? (which brings up point 2 again) > > Remember, I'm not saying that these points will happen. I'm > saying that these > are very possible scenarios. > > My apologies if this has been discussed before; I was in Nassau during the > hurricane (very little Internet access in Nassau, even more so during the > storm and the days following it) and I just got home to start > catching up on > things. > > Trev > -- > > Trevor Paquette |TeraGo Networks Inc. |Work:(403)668-5321 > Trevor.Paquette at TeraGo.ca|300, 300 Manning Rd NE|Cell:(403)703-8738 > Lead Systems Architect |Calgary, AB, Canada |Main:(403)668-5300 > http://www.terago.ca | T2E 4K8 | Fax:(403)668-5344 > From MSchoenecker at yipes.com Tue Nov 13 20:00:58 2001 From: MSchoenecker at yipes.com (Mike Schoenecker) Date: Tue, 13 Nov 2001 18:00:58 -0700 Subject: Last Call for Comment: Policy Proposal 2001-2 Message-ID: <424769F9B8BE6249825C23CFCA0A4247C6E5ED@denexh01.yipes.com> Well put Dan. Reality at its finest. -----Original Message----- From: Daniel Golding [mailto:dgolding at sockeye.com] Sent: Tuesday, November 13, 2001 4:57 PM To: Trevor Paquette; ppml at arin.net Subject: RE: Last Call for Comment: Policy Proposal 2001-2 to address the issues raised by Trevor Paquette... In regard to your first point, I strongly disagree that this policy will cause an increase in wasted IP space. Currently, it is common knowledge that a /24 is, more or less, globally routable. Thus, customers generally demand, and generally receive /24s upon requests, for the purpose of multihoming. In those circumstances where ISPs demand additional justification for the /24 allocation, the customer will either provide it (if they have it), or lie in order to receive it. As there are numerous legitimate multihomed enterprises that can not justify a /24 via current standard, we have a significant amount of false justification. This isn't because people are dishonest - it's because there is a business requirement in many cases to multihome, and an exaggerated justification is the only way to do it. Any policy that encourages normally honest people to deceive ARIN or an upstream ISP in order to achieve a legitimate purpose is, ipso facto, contrary to the good of the internet community, as open and honest communications between issuer and issue is essential. Therefore, IPv4 exhaustion will not occur any sooner - it will occur at the same rate. However, the general level of honesty and open communication will rise, which is a worthy goal. In regard to your second point, I disagree that customers will take advantage of this policy to illegitimately secure IP space. There is almost no reason for a customer to request a /24 unless they intend to multihome. Even if they feel they need it, checking for the issuance of an AS, and receiving the customer's assurance that they will multihome should be sufficient. I don't think anyone will be going back to police their customers - however, it will be appropriate to ensure compliance with previous allocations at the time of a request for new allocation. If additional allocations are made for internal political reasons by an ISP, they will need to be able to justify them to ARIN. If an organization is so shortsighted that it would issue space to customers irresponsibly, this policy proposal will neither accentuate nor ameliorate that irresponsibility. In the end, such practices tend to "catch up" to ISPs - usually when they are trying to get additional space from ARIN. In regard to your third point, I'm confused. Is your assertion that making it easier to get globally routable blocks will promote multihoming? If so, you are correct in that assertion. However, ARIN is meeting the demands of it's membership in promoting multihoming. Your concerns in regard to AS number depletion are currently being addressed in the IETF IDR working group's draft: BGP support for four-octet AS number space, draft-ietf-idr-as4bytes-04.txt. At the current rate of AS depletion, there should be sufficient AS numbers for 4 to 6 years into the future. This draft should be implemented will before then. Your forth point is only tangentially related to this policy proposal. Ensuring that customers meet, and then continue to meet, requirements for the allocation of IP space has long been the responsibility of their upstream provider. Although this can be a difficult issue, service providers should continue their current policies in this regard, which generally adhere to the idea of requiring justification at time of issuance, and then requiring additional justification (As well as confirmation of previous justification) upon additional address request. This is the general model upon which ARIN related to it's member-customers, and is a good model for it's members to use in relation to their own customers. No one is being required to be an "IP Address Cop" to the detriment of their business. However, everyone is required to act responsibly to safeguard a public resource. This policy proposal does not alter that axiom. Needless to say, I support Policy Proposal 2001-2, and urge the ARIN BoD to adopt it at their earliest convenience. Sincerely, Daniel Golding > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > Trevor Paquette > Sent: Tuesday, November 13, 2001 1:48 PM > To: ppml at arin.net > Subject: RE: Last Call for Comment: Policy Proposal 2001-2 > > > > By adopting this policy I think the following points should be made: > > 1) IPv4 exhaustion > v4 space will be used at a higher rate, with an increase of > wasted space. > More and more companies are beginning to rely on the internet > to conduct > their day to day business operations (Raise your hand if you've heard > complaints from customers when email is not delivered within 5 minutes > after they hit 'send'). As such, these companies will begin to look at > providing their own redundant links to the Internet (via multi-homing) > and not depend on the redundancy of their upstream provider. > This 'always > connected' (vs 'always on') requirement will increase IP requests to > upstream providers. > > 2) Potential for abuse of the policy to secure IP space. > I can see companies begin to abuse Policy 2001-2 to secure a /24 > and use very little address space out of that block. Some > companies will > lie about being or becoming multi-homed in order to secure > more IP space > then they really need. > > In today's world, revenue is king. If I have to tell a customer because > they are no longer multi-homed (or they lied about it), that I have to > pull their IP space; and they threaten to terminate their service with > us; guess who is going to win. The customer. Very few Senior Executives > understand or care about IP Policy; their job is to make the company > money, keep the revenues flowing. If that means the customer gets to > keep their /24; so be it. > > 3) The current AS limit. > As a few folks have mentioned before that AS numbers are a much scarcer > commodity then IP space. I agree with that statement. Policy > 2001-2 will > make the AS space run out faster. (Do we need to propose an new policy > or an RFC on increasing AS size?) > > 4) Reclaimation > How does an ISP reclaim the IP space (here comes the key > phrase) "without > losing that customer", should the customer decide one day that they no > longer want to be multi-homed? Is it up to the ISP that gave > the IP space > in the first place to periodically check to make sure that the > customer is > in fact still multi-homed? (which brings up point 2 again) > > Remember, I'm not saying that these points will happen. I'm > saying that these > are very possible scenarios. > > My apologies if this has been discussed before; I was in Nassau during the > hurricane (very little Internet access in Nassau, even more so during the > storm and the days following it) and I just got home to start > catching up on > things. > > Trev > -- > > Trevor Paquette |TeraGo Networks Inc. |Work:(403)668-5321 > Trevor.Paquette at TeraGo.ca|300, 300 Manning Rd NE|Cell:(403)703-8738 > Lead Systems Architect |Calgary, AB, Canada |Main:(403)668-5300 > http://www.terago.ca | T2E 4K8 | Fax:(403)668-5344 > From mborchers at splitrock.net Wed Nov 14 09:42:10 2001 From: mborchers at splitrock.net (Borchers, Mark) Date: Wed, 14 Nov 2001 08:42:10 -0600 Subject: Last Call for Comment: Policy Proposal 2001-2 Message-ID: > In regard to your second point, I disagree that > customers will take > advantage of this policy to illegitimately secure IP space. > There is almost > no reason for a customer to request a /24 unless they intend > to multihome. Daniel, you are indeed fortunate, for you must have a customer base of superior rationality. In my experience, customers regard a /24 as evidence of their manhood and almost always lie to get it. From martind at UU.NET Wed Nov 14 10:40:42 2001 From: martind at UU.NET ( dawn martin) Date: Wed, 14 Nov 2001 10:40:42 -0500 Subject: Last Call for Comment: Policy Proposal 2001-2 In-Reply-To: Message-ID: <001301c16d22$b9c5fb00$0a0a0a0a@lteng122> It has been my experience that when a customer asks for a "Class C" it is more to do with a lack of knowledge. When I start getting host count information and make suggestions as to the correct size that is justified and explain, they usually have no problem. If the customer has been told by a consultant that they need at least a "Class C" block then we go into it further. If they are going to be multi-homed then I work with them in getting enough IP address space to be routable. In justifying a /24 they do have to provide a list of ALL address space issued to their network. If they are going to do BGP and they already have a /24 from another provider and don't have the host count to justify additional space, none should be given. I believe it is a matter of talking to our clients. I think that Daniel is right in that we won't be wasting any additional space and that we aren't trying to change our (ISP's) current operating procedures but we are trying to update ARIN's guidelines. -Dawn Martin -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Borchers, Mark Sent: Wednesday, November 14, 2001 9:42 AM To: 'Daniel Golding'; Trevor Paquette; ppml at arin.net Subject: RE: Last Call for Comment: Policy Proposal 2001-2 > In regard to your second point, I disagree that > customers will take > advantage of this policy to illegitimately secure IP space. > There is almost > no reason for a customer to request a /24 unless they intend > to multihome. Daniel, you are indeed fortunate, for you must have a customer base of superior rationality. In my experience, customers regard a /24 as evidence of their manhood and almost always lie to get it. From dgolding at sockeye.com Wed Nov 14 10:43:33 2001 From: dgolding at sockeye.com (Daniel Golding) Date: Wed, 14 Nov 2001 10:43:33 -0500 Subject: Last Call for Comment: Policy Proposal 2001-2 In-Reply-To: Message-ID: heh. In any case, I would find it somwhat hard to believe that this policy would cause more perfidy on the part of customers. I suspect it would cause less. Many of those deceptive customers are trying to get /24s so they can multihome. I can't address the manhood of splitrock's customer base, though :) - Dan > -----Original Message----- > From: Borchers, Mark [mailto:mborchers at splitrock.net] > Sent: Wednesday, November 14, 2001 9:42 AM > To: 'Daniel Golding'; Trevor Paquette; ppml at arin.net > Subject: RE: Last Call for Comment: Policy Proposal 2001-2 > > > > In regard to your second point, I disagree that > > customers will take > > advantage of this policy to illegitimately secure IP space. > > There is almost > > no reason for a customer to request a /24 unless they intend > > to multihome. > > Daniel, you are indeed fortunate, for you must have a > customer base of superior rationality. > > In my experience, customers regard a /24 as evidence of > their manhood and almost always lie to get it. > > From Trevor.Paquette at TeraGo.ca Wed Nov 14 11:02:52 2001 From: Trevor.Paquette at TeraGo.ca (Trevor Paquette) Date: Wed, 14 Nov 2001 09:02:52 -0700 Subject: Last Call for Comment: Policy Proposal 2001-2 In-Reply-To: <424769F9B8BE6249825C23CFCA0A4247C6E5ED@denexh01.yipes.com> Message-ID: <001001c16d25$d1757d40$3102a8c0@teraint.net> Excellent comments Dan, I always like seeing a different view. I sincerely hope you are right; I have seen customers that are very good about what size of an IP block they would like, and I have seen customers that love to hoard IPs. I hope that the hording customers don't use this policy as a further means to their ends. BTW for the record; I am not opposed to this policy, I support it. I just wanted to point out a few possible scenarios that may result by ARIN adopting this policy. > -----Original Message----- > From: Daniel Golding [mailto:dgolding at sockeye.com] > Sent: Tuesday, November 13, 2001 4:57 PM > To: Trevor Paquette; ppml at arin.net > Subject: RE: Last Call for Comment: Policy Proposal 2001-2 > > > to address the issues raised by Trevor Paquette... > > In regard to your first point, I strongly disagree that > this policy > will > cause an increase in wasted IP space. Currently, it is common > knowledge that > a /24 is, more or less, globally routable. Thus, customers > generally demand, > and generally receive /24s upon requests, for the purpose of > multihoming. In > those circumstances where ISPs demand additional > justification for the /24 > allocation, the customer will either provide it (if they have > it), or lie in > order to receive it. As there are numerous legitimate > multihomed enterprises > that can not justify a /24 via current standard, we have a significant > amount of false justification. This isn't because people are > dishonest - > it's because there is a business requirement in many cases to > multihome, and > an exaggerated justification is the only way to do it. Any policy that > encourages normally honest people to deceive ARIN or an > upstream ISP in > order to achieve a legitimate purpose is, ipso facto, > contrary to the good > of the internet community, as open and honest communications > between issuer > and issue is essential. > > Therefore, IPv4 exhaustion will not occur any sooner - it > will occur at the > same rate. However, the general level of honesty and open > communication will > rise, which is a worthy goal. > > In regard to your second point, I disagree that > customers will take > advantage of this policy to illegitimately secure IP space. > There is almost > no reason for a customer to request a /24 unless they intend > to multihome. > Even if they feel they need it, checking for the issuance of > an AS, and > receiving the customer's assurance that they will multihome should be > sufficient. I don't think anyone will be going back to police their > customers - however, it will be appropriate to ensure compliance with > previous allocations at the time of a request for new allocation. If > additional allocations are made for internal political > reasons by an ISP, > they will need to be able to justify them to ARIN. If an > organization is so > shortsighted that it would issue space to customers > irresponsibly, this > policy proposal will neither accentuate nor ameliorate that > irresponsibility. In the end, such practices tend to "catch > up" to ISPs - > usually when they are trying to get additional space from ARIN. > > In regard to your third point, I'm confused. Is your > assertion that > making > it easier to get globally routable blocks will promote > multihoming? If so, > you are correct in that assertion. However, ARIN is meeting > the demands of > it's membership in promoting multihoming. Your concerns in > regard to AS > number depletion are currently being addressed in the IETF IDR working > group's draft: BGP support for four-octet AS number space, > draft-ietf-idr-as4bytes-04.txt. At the current rate of AS > depletion, there > should be sufficient AS numbers for 4 to 6 years into the > future. This draft > should be implemented will before then. > > Your forth point is only tangentially related to this policy > proposal. > Ensuring that customers meet, and then continue to meet, > requirements for > the allocation of IP space has long been the responsibility of their > upstream provider. Although this can be a difficult issue, > service providers > should continue their current policies in this regard, which generally > adhere to the idea of requiring justification at time of > issuance, and then > requiring additional justification (As well as confirmation > of previous > justification) upon additional address request. This is the > general model > upon which ARIN related to it's member-customers, and is a > good model for > it's members to use in relation to their own customers. No > one is being > required to be an "IP Address Cop" to the detriment of their business. > However, everyone is required to act responsibly to safeguard a public > resource. This policy proposal does not alter that axiom. > > Needless to say, I support Policy Proposal 2001-2, and urge > the ARIN BoD to > adopt it at their earliest convenience. > > Sincerely, > > Daniel Golding > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > > Trevor Paquette > > Sent: Tuesday, November 13, 2001 1:48 PM > > To: ppml at arin.net > > Subject: RE: Last Call for Comment: Policy Proposal 2001-2 > > > > > > > > By adopting this policy I think the following points should be made: > > > > 1) IPv4 exhaustion > > v4 space will be used at a higher rate, with an increase of > > wasted space. > > More and more companies are beginning to rely on the internet > > to conduct > > their day to day business operations (Raise your hand if > you've heard > > complaints from customers when email is not delivered > within 5 minutes > > after they hit 'send'). As such, these companies will > begin to look at > > providing their own redundant links to the Internet (via > multi-homing) > > and not depend on the redundancy of their upstream provider. > > This 'always > > connected' (vs 'always on') requirement will increase IP > requests to > > upstream providers. > > > > 2) Potential for abuse of the policy to secure IP space. > > I can see companies begin to abuse Policy 2001-2 to secure a /24 > > and use very little address space out of that block. Some > > companies will > > lie about being or becoming multi-homed in order to secure > > more IP space > > then they really need. > > > > In today's world, revenue is king. If I have to tell a > customer because > > they are no longer multi-homed (or they lied about it), > that I have to > > pull their IP space; and they threaten to terminate > their service with > > us; guess who is going to win. The customer. Very few > Senior Executives > > understand or care about IP Policy; their job is to make > the company > > money, keep the revenues flowing. If that means the > customer gets to > > keep their /24; so be it. > > > > 3) The current AS limit. > > As a few folks have mentioned before that AS numbers are > a much scarcer > > commodity then IP space. I agree with that statement. Policy > > 2001-2 will > > make the AS space run out faster. (Do we need to propose > an new policy > > or an RFC on increasing AS size?) > > > > 4) Reclaimation > > How does an ISP reclaim the IP space (here comes the key > > phrase) "without > > losing that customer", should the customer decide one > day that they no > > longer want to be multi-homed? Is it up to the ISP that gave > > the IP space > > in the first place to periodically check to make sure that the > > customer is > > in fact still multi-homed? (which brings up point 2 again) > > > > Remember, I'm not saying that these points will happen. I'm > > saying that these > > are very possible scenarios. > > > > My apologies if this has been discussed before; I was in > Nassau during the > > hurricane (very little Internet access in Nassau, even more > so during the > > storm and the days following it) and I just got home to start > > catching up on > > things. > > > > Trev > > -- > > > > Trevor Paquette |TeraGo Networks Inc. |Work:(403)668-5321 > > Trevor.Paquette at TeraGo.ca|300, 300 Manning Rd NE|Cell:(403)703-8738 > > Lead Systems Architect |Calgary, AB, Canada |Main:(403)668-5300 > > http://www.terago.ca | T2E 4K8 | Fax:(403)668-5344 > > > > From asoni at sprint.net Thu Nov 15 11:00:03 2001 From: asoni at sprint.net (Anita Shah) Date: Thu, 15 Nov 2001 11:00:03 -0500 (EST) Subject: Last Call for Comment: Policy Proposal 2001-2 In-Reply-To: Message-ID: I haven't been an active participant in these discussions, but I completely agree with your points. I work for an ISP that scrutinizes customer network justifications in order to allocate IP address space responsibly. Our customers have resorted to lying in order to obtain a /24 only because they are multihomed. If they can falsify the justification, they will be receiving the addresses anyway. I would much rather see this proposal pass. Sincerely, Anita Shah On Tue, 13 Nov 2001, Daniel Golding wrote: > to address the issues raised by Trevor Paquette... > > In regard to your first point, I strongly disagree that this policy will > cause an increase in wasted IP space. Currently, it is common knowledge that > a /24 is, more or less, globally routable. Thus, customers generally demand, > and generally receive /24s upon requests, for the purpose of multihoming. In > those circumstances where ISPs demand additional justification for the /24 > allocation, the customer will either provide it (if they have it), or lie in > order to receive it. As there are numerous legitimate multihomed enterprises > that can not justify a /24 via current standard, we have a significant > amount of false justification. This isn't because people are dishonest - > it's because there is a business requirement in many cases to multihome, and > an exaggerated justification is the only way to do it. Any policy that > encourages normally honest people to deceive ARIN or an upstream ISP in > order to achieve a legitimate purpose is, ipso facto, contrary to the good > of the internet community, as open and honest communications between issuer > and issue is essential. > > Therefore, IPv4 exhaustion will not occur any sooner - it will occur at the > same rate. However, the general level of honesty and open communication will > rise, which is a worthy goal. > > In regard to your second point, I disagree that customers will take > advantage of this policy to illegitimately secure IP space. There is almost > no reason for a customer to request a /24 unless they intend to multihome. > Even if they feel they need it, checking for the issuance of an AS, and > receiving the customer's assurance that they will multihome should be > sufficient. I don't think anyone will be going back to police their > customers - however, it will be appropriate to ensure compliance with > previous allocations at the time of a request for new allocation. If > additional allocations are made for internal political reasons by an ISP, > they will need to be able to justify them to ARIN. If an organization is so > shortsighted that it would issue space to customers irresponsibly, this > policy proposal will neither accentuate nor ameliorate that > irresponsibility. In the end, such practices tend to "catch up" to ISPs - > usually when they are trying to get additional space from ARIN. > > In regard to your third point, I'm confused. Is your assertion that making > it easier to get globally routable blocks will promote multihoming? If so, > you are correct in that assertion. However, ARIN is meeting the demands of > it's membership in promoting multihoming. Your concerns in regard to AS > number depletion are currently being addressed in the IETF IDR working > group's draft: BGP support for four-octet AS number space, > draft-ietf-idr-as4bytes-04.txt. At the current rate of AS depletion, there > should be sufficient AS numbers for 4 to 6 years into the future. This draft > should be implemented will before then. > > Your forth point is only tangentially related to this policy proposal. > Ensuring that customers meet, and then continue to meet, requirements for > the allocation of IP space has long been the responsibility of their > upstream provider. Although this can be a difficult issue, service providers > should continue their current policies in this regard, which generally > adhere to the idea of requiring justification at time of issuance, and then > requiring additional justification (As well as confirmation of previous > justification) upon additional address request. This is the general model > upon which ARIN related to it's member-customers, and is a good model for > it's members to use in relation to their own customers. No one is being > required to be an "IP Address Cop" to the detriment of their business. > However, everyone is required to act responsibly to safeguard a public > resource. This policy proposal does not alter that axiom. > > Needless to say, I support Policy Proposal 2001-2, and urge the ARIN BoD to > adopt it at their earliest convenience. > > Sincerely, > > Daniel Golding > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > > Trevor Paquette > > Sent: Tuesday, November 13, 2001 1:48 PM > > To: ppml at arin.net > > Subject: RE: Last Call for Comment: Policy Proposal 2001-2 > > > > > > > > By adopting this policy I think the following points should be made: > > > > 1) IPv4 exhaustion > > v4 space will be used at a higher rate, with an increase of > > wasted space. > > More and more companies are beginning to rely on the internet > > to conduct > > their day to day business operations (Raise your hand if you've heard > > complaints from customers when email is not delivered within 5 minutes > > after they hit 'send'). As such, these companies will begin to look at > > providing their own redundant links to the Internet (via multi-homing) > > and not depend on the redundancy of their upstream provider. > > This 'always > > connected' (vs 'always on') requirement will increase IP requests to > > upstream providers. > > > > 2) Potential for abuse of the policy to secure IP space. > > I can see companies begin to abuse Policy 2001-2 to secure a /24 > > and use very little address space out of that block. Some > > companies will > > lie about being or becoming multi-homed in order to secure > > more IP space > > then they really need. > > > > In today's world, revenue is king. If I have to tell a customer because > > they are no longer multi-homed (or they lied about it), that I have to > > pull their IP space; and they threaten to terminate their service with > > us; guess who is going to win. The customer. Very few Senior Executives > > understand or care about IP Policy; their job is to make the company > > money, keep the revenues flowing. If that means the customer gets to > > keep their /24; so be it. > > > > 3) The current AS limit. > > As a few folks have mentioned before that AS numbers are a much scarcer > > commodity then IP space. I agree with that statement. Policy > > 2001-2 will > > make the AS space run out faster. (Do we need to propose an new policy > > or an RFC on increasing AS size?) > > > > 4) Reclaimation > > How does an ISP reclaim the IP space (here comes the key > > phrase) "without > > losing that customer", should the customer decide one day that they no > > longer want to be multi-homed? Is it up to the ISP that gave > > the IP space > > in the first place to periodically check to make sure that the > > customer is > > in fact still multi-homed? (which brings up point 2 again) > > > > Remember, I'm not saying that these points will happen. I'm > > saying that these > > are very possible scenarios. > > > > My apologies if this has been discussed before; I was in Nassau during the > > hurricane (very little Internet access in Nassau, even more so during the > > storm and the days following it) and I just got home to start > > catching up on > > things. > > > > Trev > > -- > > > > Trevor Paquette |TeraGo Networks Inc. |Work:(403)668-5321 > > Trevor.Paquette at TeraGo.ca|300, 300 Manning Rd NE|Cell:(403)703-8738 > > Lead Systems Architect |Calgary, AB, Canada |Main:(403)668-5300 > > http://www.terago.ca | T2E 4K8 | Fax:(403)668-5344 > > > Thanks, Anita J. Shah Sprint E|Solutions Service Delivery 703-689-5076 anita.j.shah at mail.sprint.com asoni at sprint.net From Greg.Sanche at attcanada.com Thu Nov 15 12:48:46 2001 From: Greg.Sanche at attcanada.com (Sanche, Greg) Date: Thu, 15 Nov 2001 10:48:46 -0700 Subject: Last Call for Comment: Policy Proposal 2001-2 Message-ID: I would like to echo Daniel & Anita recommendation, in order to satisfy today's small, medium and large business requirements, being able to provide a multi-home solution and enjoy the diversity and a more reliable solution for their critical Internet business needs. Regards, Greg -----Original Message----- From: Anita Shah [mailto:asoni at sprint.net] Sent: Thursday, November 15, 2001 11:00 AM To: Daniel Golding Cc: Trevor Paquette; ppml at arin.net Subject: RE: Last Call for Comment: Policy Proposal 2001-2 I haven't been an active participant in these discussions, but I completely agree with your points. I work for an ISP that scrutinizes customer network justifications in order to allocate IP address space responsibly. Our customers have resorted to lying in order to obtain a /24 only because they are multihomed. If they can falsify the justification, they will be receiving the addresses anyway. I would much rather see this proposal pass. Sincerely, Anita Shah On Tue, 13 Nov 2001, Daniel Golding wrote: > to address the issues raised by Trevor Paquette... > > In regard to your first point, I strongly disagree that this policy will > cause an increase in wasted IP space. Currently, it is common knowledge that > a /24 is, more or less, globally routable. Thus, customers generally demand, > and generally receive /24s upon requests, for the purpose of multihoming. In > those circumstances where ISPs demand additional justification for the /24 > allocation, the customer will either provide it (if they have it), or lie in > order to receive it. As there are numerous legitimate multihomed enterprises > that can not justify a /24 via current standard, we have a significant > amount of false justification. This isn't because people are dishonest - > it's because there is a business requirement in many cases to multihome, and > an exaggerated justification is the only way to do it. Any policy that > encourages normally honest people to deceive ARIN or an upstream ISP in > order to achieve a legitimate purpose is, ipso facto, contrary to the good > of the internet community, as open and honest communications between issuer > and issue is essential. > > Therefore, IPv4 exhaustion will not occur any sooner - it will occur at the > same rate. However, the general level of honesty and open communication will > rise, which is a worthy goal. > > In regard to your second point, I disagree that customers will take > advantage of this policy to illegitimately secure IP space. There is almost > no reason for a customer to request a /24 unless they intend to multihome. > Even if they feel they need it, checking for the issuance of an AS, and > receiving the customer's assurance that they will multihome should be > sufficient. I don't think anyone will be going back to police their > customers - however, it will be appropriate to ensure compliance with > previous allocations at the time of a request for new allocation. If > additional allocations are made for internal political reasons by an ISP, > they will need to be able to justify them to ARIN. If an organization is so > shortsighted that it would issue space to customers irresponsibly, this > policy proposal will neither accentuate nor ameliorate that > irresponsibility. In the end, such practices tend to "catch up" to ISPs - > usually when they are trying to get additional space from ARIN. > > In regard to your third point, I'm confused. Is your assertion that making > it easier to get globally routable blocks will promote multihoming? If so, > you are correct in that assertion. However, ARIN is meeting the demands of > it's membership in promoting multihoming. Your concerns in regard to AS > number depletion are currently being addressed in the IETF IDR working > group's draft: BGP support for four-octet AS number space, > draft-ietf-idr-as4bytes-04.txt. At the current rate of AS depletion, there > should be sufficient AS numbers for 4 to 6 years into the future. This draft > should be implemented will before then. > > Your forth point is only tangentially related to this policy proposal. > Ensuring that customers meet, and then continue to meet, requirements for > the allocation of IP space has long been the responsibility of their > upstream provider. Although this can be a difficult issue, service providers > should continue their current policies in this regard, which generally > adhere to the idea of requiring justification at time of issuance, and then > requiring additional justification (As well as confirmation of previous > justification) upon additional address request. This is the general model > upon which ARIN related to it's member-customers, and is a good model for > it's members to use in relation to their own customers. No one is being > required to be an "IP Address Cop" to the detriment of their business. > However, everyone is required to act responsibly to safeguard a public > resource. This policy proposal does not alter that axiom. > > Needless to say, I support Policy Proposal 2001-2, and urge the ARIN BoD to > adopt it at their earliest convenience. > > Sincerely, > > Daniel Golding > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > > Trevor Paquette > > Sent: Tuesday, November 13, 2001 1:48 PM > > To: ppml at arin.net > > Subject: RE: Last Call for Comment: Policy Proposal 2001-2 > > > > > > > > By adopting this policy I think the following points should be made: > > > > 1) IPv4 exhaustion > > v4 space will be used at a higher rate, with an increase of > > wasted space. > > More and more companies are beginning to rely on the internet > > to conduct > > their day to day business operations (Raise your hand if you've heard > > complaints from customers when email is not delivered within 5 minutes > > after they hit 'send'). As such, these companies will begin to look at > > providing their own redundant links to the Internet (via multi-homing) > > and not depend on the redundancy of their upstream provider. > > This 'always > > connected' (vs 'always on') requirement will increase IP requests to > > upstream providers. > > > > 2) Potential for abuse of the policy to secure IP space. > > I can see companies begin to abuse Policy 2001-2 to secure a /24 > > and use very little address space out of that block. Some > > companies will > > lie about being or becoming multi-homed in order to secure > > more IP space > > then they really need. > > > > In today's world, revenue is king. If I have to tell a customer because > > they are no longer multi-homed (or they lied about it), that I have to > > pull their IP space; and they threaten to terminate their service with > > us; guess who is going to win. The customer. Very few Senior Executives > > understand or care about IP Policy; their job is to make the company > > money, keep the revenues flowing. If that means the customer gets to > > keep their /24; so be it. > > > > 3) The current AS limit. > > As a few folks have mentioned before that AS numbers are a much scarcer > > commodity then IP space. I agree with that statement. Policy > > 2001-2 will > > make the AS space run out faster. (Do we need to propose an new policy > > or an RFC on increasing AS size?) > > > > 4) Reclaimation > > How does an ISP reclaim the IP space (here comes the key > > phrase) "without > > losing that customer", should the customer decide one day that they no > > longer want to be multi-homed? Is it up to the ISP that gave > > the IP space > > in the first place to periodically check to make sure that the > > customer is > > in fact still multi-homed? (which brings up point 2 again) > > > > Remember, I'm not saying that these points will happen. I'm > > saying that these > > are very possible scenarios. > > > > My apologies if this has been discussed before; I was in Nassau during the > > hurricane (very little Internet access in Nassau, even more so during the > > storm and the days following it) and I just got home to start > > catching up on > > things. > > > > Trev > > -- > > > > Trevor Paquette |TeraGo Networks Inc. |Work:(403)668-5321 > > Trevor.Paquette at TeraGo.ca|300, 300 Manning Rd NE|Cell:(403)703-8738 > > Lead Systems Architect |Calgary, AB, Canada |Main:(403)668-5300 > > http://www.terago.ca | T2E 4K8 | Fax:(403)668-5344 > > > Thanks, Anita J. Shah Sprint E|Solutions Service Delivery 703-689-5076 anita.j.shah at mail.sprint.com asoni at sprint.net From dnewcomb at virage.com Tue Nov 20 21:14:14 2001 From: dnewcomb at virage.com (Darrell Newcomb) Date: Tue, 20 Nov 2001 18:14:14 -0800 Subject: Last Call for Comment: Policy Proposal 2001-2 References: <001001c16d25$d1757d40$3102a8c0@teraint.net> Message-ID: <3BFB0DF6.6EF9F793@virage.com> I fully agree this proposal should be adopted as well. I think setting the easily acquired address space at /24 has a couple benefits not already directly mentioned: 1)Provides an upper bound for the "easy"(not actually justifiable) allocations. This should also still satisfy (a)the manhood of Splitrock's customers, (b)in the dark customers demanding a "Class C", and (c)removing the need for customers to lie(aka customer retention). 2)Gives providers one more tool to beat back unreasonable address space requests. Presenting the accepted practice of assigning /24's for multihoming from a 3rd party. In customer address assignment disputes I've found pointing a 3rd party or Authority to be very helpful in education and buy-in of customers. Darrell Trevor Paquette wrote: > > Excellent comments Dan, I always like seeing a different view. > > I sincerely hope you are right; I have seen customers that are > very good about what size of an IP block they would like, and > I have seen customers that love to hoard IPs. > > I hope that the hording customers don't use this policy as a > further means to their ends. > > BTW for the record; I am not opposed to this policy, I support it. > I just wanted to point out a few possible scenarios that may result > by ARIN adopting this policy. > > > -----Original Message----- > > From: Daniel Golding [mailto:dgolding at sockeye.com] > > Sent: Tuesday, November 13, 2001 4:57 PM > > To: Trevor Paquette; ppml at arin.net > > Subject: RE: Last Call for Comment: Policy Proposal 2001-2 > > > > > > to address the issues raised by Trevor Paquette... > > > > In regard to your first point, I strongly disagree that > > this policy > > will > > cause an increase in wasted IP space. Currently, it is common > > knowledge that > > a /24 is, more or less, globally routable. Thus, customers > > generally demand, > > and generally receive /24s upon requests, for the purpose of > > multihoming. In > > those circumstances where ISPs demand additional > > justification for the /24 > > allocation, the customer will either provide it (if they have > > it), or lie in > > order to receive it. As there are numerous legitimate > > multihomed enterprises > > that can not justify a /24 via current standard, we have a significant > > amount of false justification. This isn't because people are > > dishonest - > > it's because there is a business requirement in many cases to > > multihome, and > > an exaggerated justification is the only way to do it. Any policy that > > encourages normally honest people to deceive ARIN or an > > upstream ISP in > > order to achieve a legitimate purpose is, ipso facto, > > contrary to the good > > of the internet community, as open and honest communications > > between issuer > > and issue is essential. > > > > Therefore, IPv4 exhaustion will not occur any sooner - it > > will occur at the > > same rate. However, the general level of honesty and open > > communication will > > rise, which is a worthy goal. > > > > In regard to your second point, I disagree that > > customers will take > > advantage of this policy to illegitimately secure IP space. > > There is almost > > no reason for a customer to request a /24 unless they intend > > to multihome. > > Even if they feel they need it, checking for the issuance of > > an AS, and > > receiving the customer's assurance that they will multihome should be > > sufficient. I don't think anyone will be going back to police their > > customers - however, it will be appropriate to ensure compliance with > > previous allocations at the time of a request for new allocation. If > > additional allocations are made for internal political > > reasons by an ISP, > > they will need to be able to justify them to ARIN. If an > > organization is so > > shortsighted that it would issue space to customers > > irresponsibly, this > > policy proposal will neither accentuate nor ameliorate that > > irresponsibility. In the end, such practices tend to "catch > > up" to ISPs - > > usually when they are trying to get additional space from ARIN. > > > > In regard to your third point, I'm confused. Is your > > assertion that > > making > > it easier to get globally routable blocks will promote > > multihoming? If so, > > you are correct in that assertion. However, ARIN is meeting > > the demands of > > it's membership in promoting multihoming. Your concerns in > > regard to AS > > number depletion are currently being addressed in the IETF IDR working > > group's draft: BGP support for four-octet AS number space, > > draft-ietf-idr-as4bytes-04.txt. At the current rate of AS > > depletion, there > > should be sufficient AS numbers for 4 to 6 years into the > > future. This draft > > should be implemented will before then. > > > > Your forth point is only tangentially related to this policy > > proposal. > > Ensuring that customers meet, and then continue to meet, > > requirements for > > the allocation of IP space has long been the responsibility of their > > upstream provider. Although this can be a difficult issue, > > service providers > > should continue their current policies in this regard, which generally > > adhere to the idea of requiring justification at time of > > issuance, and then > > requiring additional justification (As well as confirmation > > of previous > > justification) upon additional address request. This is the > > general model > > upon which ARIN related to it's member-customers, and is a > > good model for > > it's members to use in relation to their own customers. No > > one is being > > required to be an "IP Address Cop" to the detriment of their business. > > However, everyone is required to act responsibly to safeguard a public > > resource. This policy proposal does not alter that axiom. > > > > Needless to say, I support Policy Proposal 2001-2, and urge > > the ARIN BoD to > > adopt it at their earliest convenience. > > > > Sincerely, > > > > Daniel Golding > > > > > -----Original Message----- > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > > > Trevor Paquette > > > Sent: Tuesday, November 13, 2001 1:48 PM > > > To: ppml at arin.net > > > Subject: RE: Last Call for Comment: Policy Proposal 2001-2 > > > > > > > > > > > > By adopting this policy I think the following points should be made: > > > > > > 1) IPv4 exhaustion > > > v4 space will be used at a higher rate, with an increase of > > > wasted space. > > > More and more companies are beginning to rely on the internet > > > to conduct > > > their day to day business operations (Raise your hand if > > you've heard > > > complaints from customers when email is not delivered > > within 5 minutes > > > after they hit 'send'). As such, these companies will > > begin to look at > > > providing their own redundant links to the Internet (via > > multi-homing) > > > and not depend on the redundancy of their upstream provider. > > > This 'always > > > connected' (vs 'always on') requirement will increase IP > > requests to > > > upstream providers. > > > > > > 2) Potential for abuse of the policy to secure IP space. > > > I can see companies begin to abuse Policy 2001-2 to secure a /24 > > > and use very little address space out of that block. Some > > > companies will > > > lie about being or becoming multi-homed in order to secure > > > more IP space > > > then they really need. > > > > > > In today's world, revenue is king. If I have to tell a > > customer because > > > they are no longer multi-homed (or they lied about it), > > that I have to > > > pull their IP space; and they threaten to terminate > > their service with > > > us; guess who is going to win. The customer. Very few > > Senior Executives > > > understand or care about IP Policy; their job is to make > > the company > > > money, keep the revenues flowing. If that means the > > customer gets to > > > keep their /24; so be it. > > > > > > 3) The current AS limit. > > > As a few folks have mentioned before that AS numbers are > > a much scarcer > > > commodity then IP space. I agree with that statement. Policy > > > 2001-2 will > > > make the AS space run out faster. (Do we need to propose > > an new policy > > > or an RFC on increasing AS size?) > > > > > > 4) Reclaimation > > > How does an ISP reclaim the IP space (here comes the key > > > phrase) "without > > > losing that customer", should the customer decide one > > day that they no > > > longer want to be multi-homed? Is it up to the ISP that gave > > > the IP space > > > in the first place to periodically check to make sure that the > > > customer is > > > in fact still multi-homed? (which brings up point 2 again) > > > > > > Remember, I'm not saying that these points will happen. I'm > > > saying that these > > > are very possible scenarios. > > > > > > My apologies if this has been discussed before; I was in > > Nassau during the > > > hurricane (very little Internet access in Nassau, even more > > so during the > > > storm and the days following it) and I just got home to start > > > catching up on > > > things. > > > > > > Trev > > > -- > > > > > > Trevor Paquette |TeraGo Networks Inc. |Work:(403)668-5321 > > > Trevor.Paquette at TeraGo.ca|300, 300 Manning Rd NE|Cell:(403)703-8738 > > > Lead Systems Architect |Calgary, AB, Canada |Main:(403)668-5300 > > > http://www.terago.ca | T2E 4K8 | Fax:(403)668-5344 > > > > > > > From narten at us.ibm.com Fri Nov 30 14:28:20 2001 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 30 Nov 2001 14:28:20 -0500 Subject: Last Call for Comment: Policy Proposal 2001-3 In-Reply-To: Message from "Mon, 12 Nov 2001 14:35:12 EST." <200111121935.OAA24838@ops.arin.net> Message-ID: <200111301928.fAUJSKE02395@rotala.raleigh.ibm.com> I'm technically past the deadline, but got behind and didn't notice this until now. I object to this policy being advanced to the BOT in its current form. I (as IPv6 WG chair) was not consulted on the wording of the recommendation, even though this topic was discussed during the IPv6 WG meeting in Miami. I do not believe that there was consensus for this policy as current written. Discussion during the WG meeting was more nuanced. There was clear support for allowing micro-allocations for exchanges (but also a call for a better definition of exchanges). But there was less clarity concerning microallocations for (say) root servers. Indeed, I believe the sense of the room was that the issue needed more study first, with input from other constituencies (e.g., root server operators) as to whether micro-allocations for root servers is desirable or necessary. Discussion of the topic concluded with: "It was decided by the working group that an exchange point operator must first be defined and then ARIN would move to make a policy. Discussion will take place on the mailing list." Consult the published minutes for more details. Thomas Member Services writes: > The ARIN Advisory Council voted to forward to the ARIN Board of > Trustees the following policy. > This a last call for community comment on this policy prior to the > ARIN Board of Trustees review of the proposed policy. This policy > will be posted on the ARIN website and the ARIN Public Policy email > list. Please send your comments to ppml at arin.net. This last call > will expire at 23:59 EST on November 23, 2001. > Ray Plzak > President > American Registry for Internet Numbers (ARIN) > *** Last Call - Policy Proposal 2001-3 *** > Extend the existing IPv4 micro-allocation policy for > exchange points, gTLDs, ccTLDs, RIRs, and ICANN to > include IPv6 micro-allocations. ARIN's current IPv4 > micro-allocation policy is documented at: > http://www.arin.net/regserv/ip-assignment.html > The assignment size under this policy will be a /64, or > multiple /64s, if justified. From narten at us.ibm.com Fri Nov 30 15:09:47 2001 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 30 Nov 2001 15:09:47 -0500 Subject: IPv6 Policy Proposal discussion Message-ID: <200111302009.fAUK9ld01310@rotala.raleigh.ibm.com> As reported at the Miami meeting, a new mailing list, global-v6, has been set up to discuss IPv6 address policy issues. Previously, each RIR (ARIN, APNIC, and RIPE) had been discussing the same general topic but on their own mailing lists. The goal of having all related discussion take place on a single list is to have APNIC, ARIN, and RIPE develop mutually agreeable policies that all three RIRs can adopt as their own. It is expected that much of the discussion that has previously been taking place on the v6wg at arin.net mailing list will instead take place on the global list. The v6wg list will remain in place, however, for discussion of topics more specific to ARIN. You MUST subscribe to the list individually; those of you subscribed to the v6wg list will NOT automatically be added to the global-v6 list. List details: To post: . To subscribe: http://www.apnic.net/net_comm/lists/ Archives: http://www.apnic.net/mailing-lists/global-v6 Finally, an updated IPv6 policy document will be made available shortly. It contains more details and takes into account discussions at the recent RIR meetings. The document will be posted to the global-v6 list and we hope to have some good discussions there. Thomas From plzak at arin.net Fri Nov 30 15:26:04 2001 From: plzak at arin.net (Ray Plzak) Date: Fri, 30 Nov 2001 15:26:04 -0500 Subject: Last Call for Comment: Policy Proposal 2001-3 In-Reply-To: <200111301928.fAUJSKE02395@rotala.raleigh.ibm.com> Message-ID: <005d01c179dd$3c07ec10$e6fc95c0@ano> Thomas, You are correct. This policy will not be forwarded to the Board until the IPv6 WG has a chance to discuss this in more detail. Thank you for your diligence. Ray Plzak President ARIN > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Thomas Narten > Sent: Friday, November 30, 2001 2:28 PM > To: ppml at arin.net > Subject: Re: Last Call for Comment: Policy Proposal 2001-3 > > > I'm technically past the deadline, but got behind and didn't > notice this until now. > > I object to this policy being advanced to the BOT in its > current form. I (as IPv6 WG chair) was not consulted on the > wording of the recommendation, even though this topic was > discussed during the IPv6 WG meeting in Miami. > > I do not believe that there was consensus for this policy as > current written. Discussion during the WG meeting was more > nuanced. There was clear support for allowing > micro-allocations for exchanges (but also a call for a better > definition of exchanges). But there was less clarity > concerning microallocations for (say) root servers. Indeed, I > believe the sense of the room was that the issue needed more > study first, with input from other constituencies (e.g., root > server operators) as to whether micro-allocations for root > servers is desirable or necessary. Discussion of the topic > concluded with: > > "It was decided by the working group that an exchange point > operator must first be defined and then ARIN would move to make a > policy. Discussion will take place on the mailing list." > > Consult the published minutes for more details. > > Thomas > > > Member Services writes: > > > The ARIN Advisory Council voted to forward to the ARIN Board of > > Trustees the following policy. > > > This a last call for community comment on this policy prior to the > > ARIN Board of Trustees review of the proposed policy. This policy > > will be posted on the ARIN website and the ARIN Public Policy email > > list. Please send your comments to ppml at arin.net. This last call > > will expire at 23:59 EST on November 23, 2001. > > > Ray Plzak > > President > > American Registry for Internet Numbers (ARIN) > > > *** Last Call - Policy Proposal 2001-3 *** > > > Extend the existing IPv4 micro-allocation policy for > > exchange points, gTLDs, ccTLDs, RIRs, and ICANN to > > include IPv6 micro-allocations. ARIN's current IPv4 > > micro-allocation policy is documented at: > > > http://www.arin.net/regserv/ip-assignment.html > > > The assignment size under this policy will be a /64, or > multiple /64s, > > if justified. > From jfleming at anet.com Fri Nov 30 17:08:17 2001 From: jfleming at anet.com (Jim Fleming) Date: Fri, 30 Nov 2001 16:08:17 -0600 Subject: IPv6 Policy Proposal discussion References: <200111302009.fAUK9ld01310@rotala.raleigh.ibm.com> Message-ID: <045d01c179eb$852ed940$a300a8c0@ipv16> This may help... http://www.dot-biz.com/IPv4/Tutorial/ The Netfilter Project: Packet Mangling for Linux 2.4 http://netfilter.samba.org Jim Fleming http://www.IPv8.info IPv16....One Better !! ----- Original Message ----- From: "Thomas Narten" To: Cc: ; Sent: Friday, November 30, 2001 2:09 PM Subject: IPv6 Policy Proposal discussion > As reported at the Miami meeting, a new mailing list, global-v6, has > been set up to discuss IPv6 address policy issues. Previously, each > RIR (ARIN, APNIC, and RIPE) had been discussing the same general topic > but on their own mailing lists. The goal of having all related > discussion take place on a single list is to have APNIC, ARIN, and > RIPE develop mutually agreeable policies that all three RIRs can adopt > as their own. > > It is expected that much of the discussion that has previously been > taking place on the v6wg at arin.net mailing list will instead take place > on the global list. The v6wg list will remain in place, however, for > discussion of topics more specific to ARIN. > > You MUST subscribe to the list individually; those of you subscribed > to the v6wg list will NOT automatically be added to the global-v6 > list. > > List details: > > To post: . > To subscribe: http://www.apnic.net/net_comm/lists/ > Archives: http://www.apnic.net/mailing-lists/global-v6 > > Finally, an updated IPv6 policy document will be made available > shortly. It contains more details and takes into account discussions > at the recent RIR meetings. The document will be posted to the > global-v6 list and we hope to have some good discussions there. > > Thomas >