> On Mar 18, 2022, at 7:37 AM, Mike Burns <m...@iptrading.com> wrote: > > > Hi Owen, Andrew, and Scott, > > Transfer approval of a larger-than-minimum block size requires detailed > documentation of the use of at least 50% of the block in 24 months, and that > detailed documentation must be officer-attested. I’m sure we all agree that > nobody can approach ARIN for a large initial block without providing > believable documentation to ARIN, and the attestation provides actionability > against fraud.
I don’t doubt that believable documentation is required. But my concern, as I stated in the very first reply to this thread that everyone ignored, is: > If you’re going to remove that, what is to stop me from opening a new LIR and > stating that I want pre-qualification for a transfer of a /8 to lease out, > because I have sales projections that I can lease out a /9 within 24 months, > a /10 within 12 months, and a /11 within 6 months? And if I fail to meet my > sales projections, I can sell some or all of the /8 after 12 months > (presumably at a profit, as prices just keep going up). > > It seems that there should be some limit on initial block size if we’re going > to rely exclusively on recipients’ leasing projections instead of requiring > use on an operational network. I take your point about a /8 being infeasible to acquire on the market, but the same point applies at whatever the maximum available size currently is. -Scott > Further transfers require proof of utilization of the original transfers. > > This persistent fear of “speculation”, whatever that word means in this > context, is belied by the RIPE experience. Will somebody please answer the > RIPE experience before bringing up the “speculation” argument? > It’s over 10 years now. The experiment has been performed. We have the data. > It’s time to point to evidence instead of holding policy in thrall to > assertions of the dangers of speculation. > > Remember the biggest damper on speculation is the reality of the market. You > can’t just whip up a /8 to be transferred, and if you could, you are looking > at spending almost a billion dollars! Do you really think a billion dollar > investment in an asset that all the smart people say will be valueless at > some point isn’t a damper on speculation? Do you think ARIN would approve an > initial transfer of a /8 on the mere promise it will be leased out in two > years? > > I trust the market and I trust ARIN staff enough to dampen “speculation”. As > always, should something damaging appear, we retain the ability to change > policy. > > Regards, > Mike > > > From: ARIN-PPML <arin-ppml-boun...@arin.net> On Behalf Of Owen DeLong via > ARIN-PPML > Sent: Thursday, March 17, 2022 8:20 PM > To: Andrew Dul <andrew....@quark.net> > Cc: arin-ppml@arin.net > Subject: Re: [arin-ppml] Revised and Retitled - Draft Policy ARIN-2021-6: > Permit IPv4 Leased Addresses for Purposes of Determining Utilization for > Future Allocations > > I favor the kind of limitations Scott has expressed. I was commenting on the > arguments made by Fernando and have not yet had the bandwidth to review the > actual policy text in detail. > > Owen > > > > On Mar 17, 2022, at 16:17 , Andrew Dul <andrew....@quark.net> wrote: > > The draft policy as currently written does not provide any additional limits > against speculation. As drafted, it allows any organization (including those > who do not operate networks) to obtain IPv4 addresses for the purpose of > leasing. > > With that policy change what types of limits does the community think would > be needed? > > Thanks, > Andrew > > On 3/17/2022 3:00 PM, Scott Leibrand wrote: > +1 to both Owen and David Farmer's comments. Leasing IPv4 space is likely the > best solution for some networks that need those addresses to operate their > network. If an organization wants to acquire and lease out IPv4 space without > providing bundled IPv4 transit, that should be allowed by policy. It might be > useful for ARIN policy to try to slightly dampen speculation by requiring > that organizations seeking to acquire large blocks of IPv4 space demonstrate > that their current holdings are being efficiently used by the organization > they're registered to in whois. I am not sure if this policy proposal does > that to my satisfaction, but once we ensure it does so, I would likely > support it. > > -Scott > > On Thu, Mar 17, 2022 at 1:33 PM Owen DeLong via ARIN-PPML > <arin-ppml@arin.net> wrote: > > > > On Mar 16, 2022, at 15:22 , Fernando Frediani <fhfredi...@gmail.com> wrote: > > Hi David > If I understand correctly you seem to have a view that there should be a ARIN > policy to permit IPv4 leasing just because it is a reality and we kind of > have to accept it in our days. No we don't, and that's for many different > reasons. > Well, of course, you are free to deny reality as much as you want. Many > people do. It’s not particularly helpful in the discussion, however. > > > I am used to see people saying the brokers are doing a good thing for the > community by facilitating the things which in reality is the opposite. It may > look like a good things, but the real beneficiaries are only them who profit > from it without much concern of what is fair or not to most organizations > involved. > > You are actually mistaken here. I used to think as you do, actually. I was > very resistant to the first “specified transfer” policies because of some of > the reasons you describe. However, what you are failing to recognize is that: > + Brokers and specified transfers were going to happen with or without the > RIRs. If they happened without the RIRs, > there’d be no accurate record of who was using which address space and the > provenance of addresses would be > very difficult to support or defend. > > * Benefit to the community from brokers: (ethical) brokers are familiar with > the rules in the RIRs in which > they operate and can assist their customers in accurate and compliant > registration updates and > aid in keeping the allocation database(s) accurate. > > + With the economic realities of IPv4 addresses becoming progressively more > and more expensive and the advent > of ISPs with limited IPv4 resources available, it is inevitable that more and > more IP service providers will be > doing one or more of the following: > > + Separate surcharges for IPv4 addresses > + Expecting customers to supply their own IPv4 addresses > + Surcharges for IPv4 services > + IPv4 “installation charges” large enough to cover the procurement of > addresses > > * Brokers assist ISPs and customers in many of the above circumstances. > > + With a variety of organizations holding IPv4 addresses that may or may not > even known they have them and whose > IPv4 resources may vastly exceed their needs, it is (arguably) desirable to > have those addresses be transferred to parties > that have current need for IPv4 addresses. > > * Brokers provide a valuable service to the community identifying and > marketing these resources > * Paid transfers provide an incentive for entities to make more efficient use > of the resources they have in order > to monetize the resources they no longer need. Brokers are frequently able to > assist in this process. > > + With the high cost of acquisition, IPv4 addresses have become a capital > intensive part of any network-dependent > business model that must support IPv4. Further, there is some risk that this > capital outlay may be fore a resource > which will abruptly and quickly lose its value and no longer be needed well > before it can be amortized as a capital > expenditure. As such, it may make sense for some entities to transfer that > risk to another organization by using > a lease structure instead of purchasing the addresses outright. > > * Brokers that provide IPv4 leasing in an ethical and policy compliant way > provide a valuable service > to these businesses. Yes, their price per address may eventually be more than > it would have cost > them to purchase the addresses, but the same is true of virtually any rental > situation. On the other hand, > that excess helps offset the risk that the lessor is taking by owning a > resource that may or may not remain > valuable and may or may not continue to produce revenue. > IP Leasing is very different from IP Transfer which I see not problem they > continue doing it. IP Transfer at least we have some guarantees that the > directly receiving organization really justify for them and that is a quiet > important (I would say fundamental) point to look at, because that is fairer > to everyone involved. What guarantees we have when a IP Leasing is done in > that sense, that fairness start to lack here. > If we set the policies up correctly, we should have the same exact guarantees > on a lease. > > If $ISP acquires a /10 through transfer and then issues various subordinate > prefixes to their customer, the only guarantee > you have that $ISP’s customers who receive the addresses really justify them > is that $ISP says so. We generally trust $ISP > to act in good faith. > > If $LESSOR acquires a /10 through transfer and then leases various > subordinate prefixes to their customers, we have pretty > much the same guarantee with the additional bit that $CUSTOMER is at least > willing to pay enough for the addresses to $LESSOR > to make the lease make sense. In general, I think it is somewhat safe to > assume that $CUSTOMER is not going to make a > monthly recurring payment to $LESSOR for something they don’t intend to use. > If one’s intent is to deprive the market and > inflate the price, then the risk profile for such a transaction is vastly > more favorable if you purchase rather than lease. > > Sure, there could be lessors that don’t get reasonable justification for > allocations from their customers, but there are most > certainly ISPs in that category as well. Either way, you’ve got very little > assurance. A lessor can provide just as much > justification to an RIR for the addresses they will allocate to leases as an > ISP can for addresses they will lease to their > customers. The only difference is a lease with connectivity from the same > company or a lease from a company other than > the one(s) providing connectivity. > People see the brokers are doing a favor to organizations in general by > facilitating they get some chunks of IPv4, but that in reality makes the cost > of IPv4 for both leasing and transfer more and more expensive as it makes > organization even more dependent from these those crumbs that seem to be > offered with good intention but in reality it is feeding a system that is > contrary the interests to most organizations involved. > Just as you are free to mount, balance, and rotate your own tires, or, you > can go to a tire store and have them perform that service for a fee, brokers > provide a service for a fee. If you want to obtain addresses in the transfer > market without a broker, you’re still free to do that. Brokers are not > driving the cost of IPv4… The scarcity and difficulty of operating with IPv4 > is driving the cost of IPv4. Brokers are along for the ride providing a > service and collecting a fee for that service. Whether that fee is reasonable > or not is (and should be) entirely in the eye of the customer. Customers are > always free to walk away and find a different supplier or look for their > addresses independently. > It may sound a cliche but IPv4 is over and organizations must learn how to > survive with what they have, reinvent themselves and make better used of > their IPv4 resources, deploy a proper CGNAT, deploy IPv6 either they like it > or not, etc. If an organization have so little or none and need some minimal > amount is fine they seek for a Transfer of a minimal amount with the help of > brokers. > I agree. However, the increasing cost of IPv4 is a natural and organic part > of that process and sticking our heads in the sand and pretending that it is > not the economic reality of how the current world works will not help anyone. > Not the community, not organizations that are short on IPv4 resources, and > not the RIRs who are only useful so long as their databases provide a > reasonably accurate reflection of the actual utilization of the address space > and who controls it. > > A broker is an LIR just like an ISP. Since ISPs are now charging for > addresses independent of connectivity and bandwidth, it only makes sense that > customers can shop for them separately from different suppliers. Just like > you can buy tires for your car from the dealership or from some other store > that sells and supports tires, IPv4 addresses are moving that way as well. > The RIRs can either recognize this and adapt to it with policies that make > sense and preserve some of the things you’ve outlined as concerns above, or, > they can simply deny the reality of IPv4 leasing and lose track of how > addresses are actually managed for some significant chunks of the internet. > Encouraging IP Leasing as if it were something normal just "because it exists > today" is a shot in the foot that in the long term only worsens the existing > scenario, it feeds a market without much discretion increasing final prices > for everyone and what is the worst of all, creates even more unfairness for > everyone who has always submitted to the rules we have until today for > distributing addresses to those who really have a real justification to keep > control of that resource that does not belong to them. > I don’t believe that a policy that merely allows IPv4 leasing can be said to > encourage it. Rather, it permits it, recognizes that it exists and is not > going to stop existing just because policy pretends it can’t exist. > > The market is not likely to be significantly swayed by policy in terms of > pricing, with the exception that AFRINIC has been able to preserve a devalued > price on addresses within their region due to their restrictive lack of a > transfer policy for moving addresses to/from AFRINIC. However, while this has > the effect of keeping AFRINIC IPv4 addresses less expensive on the open > market, it also leads to a significant amount of utilization of those > addresses outside of policy and quite a bit of hoarding of addresses by some > of AFRINIC’s largest members. ARIN’s counsel has advised against naming names > here, so I won’t, but if you want names, contact me off list. > > Owen > > > Regards > Fernando > On 16/03/2022 13:09, David Farmer via ARIN-PPML wrote: > Yes, bundling IPv4 addresses with bandwidth is permitted, and in the past was > common practice, heck even the expected practice. However, the fact that IPv4 > address demand isn't decreasing significantly, the costs to acquire new IPv4 > addresses are increasing significantly, and with the increasing > commoditization of bandwidth, it is no longer economically viable to bundle > bandwidth, and its associated connectivity, with IPv4 addressing. This is > driving a structural separation of bandwidth, connectivity, and IPv4 > addressing, from each other, instead of bundling them together as in the past. > > Let me state that differently; ISPs are being driven, buy cost conscience > consumers, to separate the costs of bandwidth and the costs of the IPv4 > addresses needed to utilize the bandwidth from each other. Minimally this > separation is achieved by accounting for the costs on separate line items of > a common bill from a single provider. However, price competition for > bandwidth and IPv4 addresses separately will inevitably drive a structural > separation between the two. Consumers will want the best price they can get > for bandwidth and the best price they can get for IPv4 addresses, regardless > of whether they come from a single provider or not. > > Some may argue this is being driven by the existence of address brokers, and > their desire to make money, I disagree. While address brokers making money is > the grease that keeps this machine working, the need for the machine is > driven by; IPv4 free pool exhaustion, the increasing cost of IPv4 addresses, > and the lack of adoption of IPv6. > In other words, address brokers wouldn't exist if there wasn't a demand for > their services. > > In short, the economic conditions that allowed for and even encouraged the > bundling of IPv4 addresses with bandwidth and connectivity no longer exist, > that world is gone. While I have not personally yet determined if I support > this particular policy text, nevertheless, the time has come to recognize the > next step in this inextricable evolution of IPv4 address policy by the ARIN > policy community and permit IPv4 leasing. > > Thanks. > > On Fri, Mar 11, 2022 at 5:05 PM John Santos <j...@egh.com> wrote: > I disagree. The addresses are useless unless they ALSO purchase access and > routing from another network operator. How is this cheaper? > > It is and always has been allowed to lease bundled access of addresses and > connectivity from a LIR, without any expense for purchasing those addresses. > > > On 3/11/2022 12:13 PM, Tom Fantacone wrote: > > I support the proposal as written. > > > > It facilitates the provision of a valuable service to a large swath of the > > ARIN > > community, namely the ability of network operators with an operational need > > to > > lease IPv4 addresses from 3rd party lessors at a fraction of the cost of > > purchasing those addresses. Too often we have seen network operators > > justify > > their need for IPv4 space only to find that they can't afford to make the > > purchase. They end up using CGNAT or some other sub-optimal solution. > > > > Bill, regarding your point "B", by providing IPv4 leasing, these 3rd > > parties are > > certainly performing a function that ARIN does not. > > > > > > > > ---- On Thu, 10 Mar 2022 17:46:36 -0500 *William Herrin <b...@herrin.us>* > > wrote ---- > > > > On Wed, Mar 9, 2022 at 8:24 PM ARIN <i...@arin.net > > <mailto:i...@arin.net>> > > wrote: > > > * ARIN-2021-6: Permit IPv4 Leased Addresses for Purposes of > > Determining > > Utilization for Future Allocations > > > > I continue to OPPOSE this proposal because: > > > > A) It asks ARIN to facilitate blatant and unapologetic rent-seeking > > behavior with changes to public policy. > > > > B) It proposes that third parties perform precisely and only the > > functions that ARIN itself performs without any credible compliance > > mechanism to assure the third party performs to ARIN's standards or in > > accordance with the community's established number policy. > > > > Regards, > > Bill Herrin > > > > > > -- > > William Herrin > > b...@herrin.us <mailto:b...@herrin.us> > > https://bill.herrin.us/ <https://bill.herrin.us/> > > _______________________________________________ > > ARIN-PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net > > <mailto:ARIN-PPML@arin.net>). > > Unsubscribe or manage your mailing list subscription at: > > https://lists.arin.net/mailman/listinfo/arin-ppml > > <https://lists.arin.net/mailman/listinfo/arin-ppml> > > Please contact i...@arin.net <mailto:i...@arin.net> if you experience > > any > > issues. > > > > > > > > > > _______________________________________________ > > ARIN-PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > > Unsubscribe or manage your mailing list subscription at: > > https://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact i...@arin.net if you experience any issues. > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > > > -- > =============================================== > David Farmer Email:far...@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues.
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
