Steve, I think your interpretation of 4.3.2.2 is incorrect. That policy section was not the one that authorized the receipt of a (PA) /24 for multihoming. That was, and still is, 4.2.3.6: https://www.arin.net/policy/nrpm.html#four236, which states that "The ISP will then verify the customer's multihoming requirement and may assign the customer a /24, based on this policy."
4.3.2.2 states that the minimum allocation size (from ARIN) for multihomed end users was a /24. However, that did not allow you to get a /24 from ARIN just by becoming multihomed. If you were/are in that situation, you always had to (and still have to) get your /24 from your upstream if you don't meet ARIN's /24 utilizatinon criteria, and demonstrate efficient utilization before getting one from ARIN. If my understanding does not match how policy was implemented by staff prior to implementation of ARIN-2014-13 on 17 September 2014, someone please correct me, but that was the intent of the policy as I understand it. When discussing 2014-13, my sense of the community was that we did not want to authorize receipt of a /24 from ARIN solely based on multihoming, because that could possibly open up a land rush of organizations spun up solely for the purpose of getting a /24 from the free pool, holding it for the requisite time, and then selling it on the transfer market. I personally would be more amenable to considering a policy change to liberalize the requirements for getting a /24 if/when they're available from the transfer market only. -Scott On Thu, Nov 20, 2014 at 9:26 AM, Steve King <[email protected]> wrote: > Multi-homing was not a requirement. It was an alternate > justification. I can’t honestly meet the 50% utilization requirement for a > /24, but under the pre-September rules I qualified for a /24 under 4.3.2.2 > because I contract with multiple carriers and want to participate in BGP > for failover. > > > > Now that the language in 4.3.2.2 is gone, my reading is I have to either: > > > > a) Lie about my utilization. Not willing to do that. > > b) Beg for a BGP-transferrable block from a carrier, and even then, > deal with the fact that other ISPs are far more likely to aggregate and > filter specific routes to large carrier-assigned blocks. I end up with a > less reliable failover solution. > > > > The policy revision is a significant step backward for me. Maybe I’m > enough of an edge case to not matter. But ARIN-2014-13 stated 4.3.2.2 was > redundant given the lowered minimum allocation in 4.3.2.1. It was not > redundant. It covered a case that I think matters. > > > > The worst part is, I’m probably going to end up with two non-BGP > transferrable /24s from two carriers (we all know they hand them out like > candy with big circuits), so I’ll end up burning more IPV4 space than I > otherwise would. > > > > > > > > > *Steve King* > > ICON Aircraft > > > > *From:* John Von Stein [mailto:[email protected]] > *Sent:* Wednesday, November 19, 2014 9:18 PM > *To:* Richard J. Letts; Steve King; [email protected] > *Subject:* RE: Multi-homing justification removed? > > > > Speaking from recent / current experience, the multi-homing requirement is > a bit of a challenge for tweener-sized organizations like QxC. We are too > big for underlying fiber carriers to comfortably continue to supply our > need for IP addresses but not in the position to carry the financial, > technical or operational challenges of multi-homing. This was a very > significant cost commitment for QxC and I can imagine this is not > achievable for other like-sized ISPs. Granted, we are better off for it > now but had I known how much of a financial and technical hurdle this > really was then I probably would not have done it. I just needed more IP > addresses to continue to grow my biz and would have much rather spent the > money and manpower on marketing/sales/customer acquisition. Multi-homing > is a nice-to-have luxury that none of my customers are willing to pay for > so it is simply a cost of entry to get the IP addresses we need to continue > to grow our customer base. > > > > As such, I support dropping multi-homing as a prerequisite for an IP > allocation. > > > > Thank you, > > John W. Von Stein > > CEO > > > > [image: cid:sigimg0@791f5d9d52446f85c6fed00adec61823] > > > > 102 NE 2nd Street > > Suite 136 > > Boca Raton, FL 33432 > > Office: 561-288-6989 > > www.QxCcommunications.com <http://www.qxccommunications.com/> > > > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > > > > *From:* [email protected] [mailto:[email protected] > <[email protected]>] *On Behalf Of *Richard J. Letts > *Sent:* Wednesday, November 19, 2014 1:24 PM > *To:* Steve King; [email protected] > *Subject:* Re: [arin-ppml] Multi-homing justification removed? > > > > I believe the intent was there. > > > > orgs that have a justifiable/provable need for a /24 were been restricted > by their current/lone provider being unwilling to give them enough address > space. Not everyone has the ability to change providers, and if you can’t > change providers then you certainly would not be able to multihome.. > > > > *Richard Letts* > > > > *From:* [email protected] [mailto:[email protected] > <[email protected]>] *On Behalf Of *Steve King > *Sent:* Wednesday, November 19, 2014 9:47 AM > *To:* [email protected] > *Subject:* [arin-ppml] Multi-homing justification removed? > > > > The changes implemented in ARIN-2014-13, specifically the removal of > 4.3.2.2, appear to have removed the multi-homing justification for a /24 > for end users. Previously, the need to multi-home, and proof of contracts > with multiple upstream providers, was sufficient to justify a /24 to > participate in BGP. > > > > For reassignments from ISPs, the language remains in 4.2.3.6. Users can > justify a /24 via a requirement to multi-home rather than utilization > rate. However this revision appears to leave utilization rate as the only > criterion for direct end-user assignments. > > > > Was this the intent or possibly an overlooked side effect of the change? > > > > > > > > > *Steve King* > > ICON Aircraft > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. >
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
