+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 <mailto:arin-ppml@arin.net>> wrote:
On Mar 16, 2022, at 15:22 , Fernando Frediani
<fhfredi...@gmail.com <mailto: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
<mailto: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 <mailto:b...@herrin.us>>* wrote ----
>
> On Wed, Mar 9, 2022 at 8:24 PM ARIN
<i...@arin.net
<mailto:i...@arin.net> <mailto: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> <mailto:b...@herrin.us
<mailto:b...@herrin.us>>
> https://bill.herrin.us/
<https://bill.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>
> <mailto: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>
>
<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> <mailto: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 <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.
--
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
<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.
--
===============================================
David Farmer Email:far...@umn.edu
<mailto:email%3afar...@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
<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 contacti...@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
<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
<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
<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 contacti...@arin.net <mailto:i...@arin.net> if you experience any
issues.
