<div dir="auto">Fernando, </div><div dir="auto"><br></div><div dir="auto">You are using a very technical definition of leasing, and at least historically you are correct.</div><div dir="auto"><br></div><div dir="auto">However, with IPv4 runout the market place has changed significantly. For example, I recently worked on a national scale RFP for the research and education community, as part of it we asked the respondents about pricing for IPv4 blocks provided with their DIA Internet services, consistent with your view of how IP addresses should be provided. The responses ranged from $1 - $5 per IPv4 address per month for midsized blocks (/28 - /26) and $.30 - $5 per IPv4 address per month for larger blocks (/25 - /21).</div><div dir="auto"><br></div><div dir="auto">That a range of $600 to $10k a month for a /21, just for addresses and on top of the transit bandwidth charges, and only half of the respondents would even provide a block that big, the other half wouldn’t provide any blocks bigger than a /24.</div><div dir="auto"><br></div><div dir="auto">So, when I say all ISP are leasing addresses, this is the market reality I’m referring too. The very technical definition of leasing you are talking about has been overtaken by the facts of the IPv4 address market place. </div><div dir="auto"><br></div><div dir="auto">In my opinion, your very technical definition of leasing is an anachronism. The reality is if you want/need more than a /29 of addresses, and you don’t already have them, you will need to pay for them one way or another on top of your transit bandwidth, through the transfer market, leasing them from your transit provider, or leasing them from a 3rd party, this is today’s reality, like it or not.</div><div dir="auto"><br></div><div dir="auto">Thanks </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 8, 2023 at 18:23 Fernando Frediani <<a href="mailto:fhfrediani@gmail.com">fhfrediani@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div>
<p>Hi Willian. A customer who holds an ASN and is a ARIN member
should not get IP space to announce with their own ASN from the
ISP provider but directly with ARIN in all cases.<br>
Legal risk will always exists and it is not because it exists it
should not be taken, just need to evaluated and worked.<br>
</p>
<p>There has been a proposal presented not much a while ago that
intended to get that separation better worded and which was still
in the process of getting feedback and improvements, but AC
quickly dismissed it in a questionable way despite there has been
people interested in discussing and improving it. A pity. There
has not even been a chance to get a improved text in that sense.<br>
And honestly there will always be some way someone will find out
to try to circumvent rules and I don't think there will be a
perfect text, but a reasonable one that can cover most scenarios
can play a important role in reducing scenarios where resources
can be misused.<br>
</p>
<div>On 08/05/2023 19:45, William Herrin
wrote:<br>
</div>
<blockquote type="cite">
<pre style="font-family:monospace">On Mon, May 8, 2023 at 3:26 PM Fernando Frediani <a href="mailto:fhfrediani@gmail.com" target="_blank" style="font-family:monospace"><fhfrediani@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre style="font-family:monospace">Another thing which many here are targeting about IP leasing
in the sense of renting, speculation made by those who don't
build or offer any Internet infrastructure and services. In other
words someone holding IP space and not using it to build any
Internet infrastructure and services.
</pre>
</blockquote>
<pre style="font-family:monospace">Hi Fernando,
You may be missing my point. How do you differentiate in policy between:
Scenario 1: ISP A provides a T1 and a /24. ISP B provides a gigabit
ethernet. Customer routes with BGP on both but depreferences ISP A so
it never shows up in the Internet BGP tables.
Scenario 2: Pretextual ISP C (the defacto address leaser) provides a
/24 and a VPN (or virtual machine other nil-cost transit consuming
mechanism). ISP D provides a gigabit ethernet. Customer routes with
BGP on both but depreferences ISP C so it never shows up in the
Internet BGP tables.
Scenario 1 is considered reasonable and has been for the entire
lifetime of the RIRs.
Scenario 2 is the objectionable address leasing arrangement with a
tiny bit of fluff to bring it into technical compliance with ARIN
policy.
You can't tell ARIN to just exercise their judgement whether something
is defacto leasing. That creates legal risk to the organization where
they can't effectively act against the people they "know" to be
leasers.
You have to write a policy that outright breaks scenario #2 without
harming scenario #1.That's the utilization count approach. ISP A in
scenario #1 is not particularly bothered if ARIN gets a bee in their
bonnet about counting that /24 utilized. So they have to be at 81%
instead of 80%. Same difference.
ISP C in scenario #2, that's their entire business. If ARIN counts it
unutilized, they're out of business.
Get it?
Regards,
Bill Herrin
</pre>
</blockquote>
</div>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>=============================================== </div>