IP range for lease

Tue Jul 11 02:03:56 UTC 2023

> On Jul 10, 2023, at 06:58, Sylvain Baya <abscoco at gmail.com> wrote:
> 
> Dear NANOG-ers,
> Hope this email finds you in good health!
> 
> Please see my comments below, inline...
> 
> Le jeudi 6 juillet 2023, Owen DeLong via NANOG <nanog at nanog.org <mailto:nanog at nanog.org>> a écrit :
>> 
>> 
>> 
>> 
>> Karin,
>> 
>> Opinions regarding leasing vary throughout the industry. In my opinion, since the shift to provider assigned addresses during the CIDR efforts in the mid 1990s, the majority of addresses have been leased in one form or another. 
>> 
>  
> 
> Hi Owen,
> Thanks for your email, brother.
> ...do you mean that such activity was supported by
>  a policy? or it was just a disruption of a principle 
> which is fundamental; in order to guarantee that 
> the common INRs (Internet Number Resources) 
> are fairly distributed and not easily stockpilled? 

I mean that norms have evolved since the initial internet days:

Original: All addresses were obtained from Jon Postel and recorded in his notebook.
Next step: All addresses were obtained from NIC.DDN.MIL via email template submission.
Then: All addresses obtained from successor NICs.
Then: Addresses obtained from RIR or successor NIC.
Then: Addresses obtained from provider or RIR or NIC, but still permanent issue.
Then: Addresses obtained from RIR or NIC are (quasi-)permanent, but addresses obtained from provider are returned upon termination of services. (i.e. leased in association with connectivity)
Then: Sometimes you could arrange to keep the addresses from your previous provider by paying them a periodic (annual, monthly, etc.) fee.
Now: Essentially the same as the previous era, except that there are some providers who now provide leases without ever providing connectivity.

To the best of my knowledge, none of the previous methods were controversial or even received significant notice as they occurred. It was just sort of the natural evolution of address distribution as the internet grew.

Really, the difference between being able to pay a former provider to keep your addresses and being able to lease addresses from a non-provider doesn’t seem like a significant change from my perspective.

I don’t see any disruption of principle here. To the bets of my knowledge, there is only one RIR which has a policy which specifically precludes this form of leasing (APNIC). Other RIRs policies are silent on the subject.

The way number resource policy works is that it generally prohibits behaviors deemed unacceptable by the community rather than enumerating what is permitted. Therefore, silence is consent in most cases.

>> The only thing novel here is the leasing of addresses independent of connectivity services. 
>> 
> 
> So! it's a leasing of something not owned? and it 
> became worse with the idea of Monkey(ing it)-In-
> The-middle (MITM)...

I’m not sure I understand what you mean by that.

Virtually all providers on the planet currently lease addresses to their subscribers. This occurs on a daily basis. I’d be willing to bet that whatever address you are using at home are leased addresses from your provider (mine are not, but I will admit that I do have leased addresses from providers terminating the tunnels I use to route my real addresses).

Your objection here isn’t to leasing (everyone accepts leasing with connectivity for a very long time now,
as the internet was relatively smalll when that change occurred.)

Your objection is to connectivity independent leasing — leasing by entities that are not providing connectivity services to the lessee.

> What's the difference, please?

An odd question given that my stated position is that there is little to no difference between connectivity-based leasing and connectivity independent leasing.

> Are you trying to change a definition, in order to 
> convince this community that this sad practice 
> was started at the very beginning of the INRs  distribution?

I’m not trying to change anything. The definition of leasing is the plain English meaning of the term — Permitted use of a thing for a period of time specified in a contract in exchange for some value received (usually a fee).

This is true of apartments (monthly rent), IP addresses from ISPs (either built into the cost of your ISP services or billed as an add-on), and now IP addresses leased independent of connectivity.

> What's your understanding of "need-based"?

So long as the end recipient of the addresses has a legitimate technical need for them, what difference is it who provides the address to them, whether IANA, an RIR, an ISP, or another entity that has registered addresses they don’t currently need?

> Why are they stocking INRs without any need to 
> properly use it?

There are so many possible explanations for this that it would be impossible to enumerate them all here, but some that come to mind:

A company received a /16 back when they were being issued as class Bs. They are still using 75+% of it, but they have several /24s that they would like to allow others to utilize while they don’t need them.

A company received a /8 back when they were being issued as class As. They are utilizing more than 50% of it, have no reason or desire to return it, and wish to monetize the parts they don’t currently need while preserving their ability to utilize them in the future.

> ...imho! the waiting list would be less longer with 
> those INRs withing the free pools.

I have no strong opinion one way or the other about the waiting list. Frankly, I don’t really care about IPv4 other than the extent to which it continues to damage the internet because of the necessity of accommodating those who have not yet deployed IPv6.

Efforts to preserve the viability or image of availability of IPv4 addresses through punitive or austerity measures only cause more harm in this regard.

>> However, once the RIRs and their communities normalized the sale of addresses through directed transfer policies, I think this was an 
>> 
> 
> Any RIR's policy you can share, to support your say?

ARIN NRPM 8.3, ARIN NRPM 8.4, APNIC 2.13 et. Seq,, RIPE 682, LACNIC 2.3.2.18, https://afrinic.net/resources/transfers

I think that covers all 5 RIRs.

Is that sufficient?

>> inevitable next step in the devolution of IPv4 into a monetized asset. 
>> 
> 
> What's the relation between leasing INRs and 
> transfering it?

Leasing is a financial contract to transfer an asset for a limited time in exchange for compensation.
A transfer can be done either for a specified time (lease) or permanently. Admittedly, with the exception of RIPE, which specifically enumerates procedures for temporary transfers registered with the RIR, the other RIRs treat leases (temporary transfers) as something strictly between the parties and not involving a transfer of the RIR relationship (other than to the extent that said transfers may be recorded in whois or RDAP through SWIP or other processes).
The transfers involving an RIR are generally permanent and usually relate to a sale of number resources.

So I think that your question would be better phrased as what is the relation between RIR transfers and leasing?

I believe I have answered that in the above paragraph.

> 
> Brother, you know that:
> * an INR transfer is a one time change in holdership
> * where leasing INRs is a proof that there is no 
> longer any need of the community's resource held.  

To the first point, yes, perhaps, with the likely exception of RIPE “temporary transfers”.

To the second point, not necessarily. There are many circumstances where a company may have excess resources that are not (practically) severable from the resources they are utilizing.

It’s relatively easy for a company holding a /16 to lease out 2,4, or even 30 /24s they don’t currently need for a period of time. It would be hard for them to return just those 30 /24s scattered through their address space while continuing to utilize the remaining 226 /24s that are in active use, for example.

Your statement here makes multiple assumptions that are invalid in a variety of circumstances and is, therefore, not actually correct.

Further, your failure to recognize that leasing related to connectivity is common practice which even you accept and distinguish it from connectivity-independent leasing, which is what you continue to simply call leasing further confuses the issue.

> 
> ...imho! the communities chose a good approach 
> in support to those who maintain Internet services
>  and build the Internet infrastructure. It should be 
> seen as an exceptional rule, not the usual...because
>  it's an alternative when need ends.

The approach chosen has leasing built in. The vast majority of internet number resources in use today are leased to their end users. In general, it’s RIR->LIR->End user. The LIR is leasing them from the RIR — They pay an annual fee to the RIR in order to secure a registration of the particular addresses. The End user then leases some fraction of those addresses from the LIR. (The LIR is usually an ISP). This lease may be bundled with their connectivity services from said LIR/ISP, or it may be billed separately (e.g. Comcast charges business customers that want static addresses $15/month for each block of 5 addresses issued).

That is the usual, whether you like it or not.

The only thing that is novel in this discussion is the idea that an LIR isn’t necessary an ISP.

> ...the other alternative, consistent with the principle,
>  is not the leasing of INRs; but the returning.

If an LIR is issuing the addresses according to the same policies and needs basis as the RIR that issued them, then how is it inconsistent with the principle? Returning is not always practical and rarely desirable, especially if the organization in question may need the addresses later or if the addresses represent a temporary excess.

>> It doesn’t help that the earliest and most prolific adopters of this form of leasing have been snowshoe spammers. 
> 
> It helps to better understand how bad is the thing :'(

Well, it artificially gies the thing a bad name. However, it doesn’t have to be any worse than anything else we are doing.

> ...please, do consider the following scenario:
> 
> |1. you have a fundamental principle for INRs distribution within the regional RIR

It would be interesting if you could enumerate or explain this so-called fundamental principle to which you refer, because some of your subsequent statements are not necessarily consistent with what I perceive to be that principle. Ideally, if you could point to documentation supporting your interpretation, that would also be good.

> |2. for each resource holder, the RIR is responsible
> to enforce the Policy Manual

Yes… To a certain extent. However, this must always be done through contract enforcement processes.

> |3. a resource holder receives some INRs from a 
> regional RIR

That’s how it often works, though there are alternatives…
	A resource holder may have received their resources prior to the creation of the RIR system.
	A resource holder may have received their resources from an NIR or LIR.

> |4. that resource holder stops to comply to the 
> principle in "1"

Going to need more detail here… For the time being, since you haven’t defined the principle in 1 and you haven’t defined the violation in question or in what manner they stopped complying, it’s hard to provide any meaningful comment.

> |5. the INRs delegated to that resource holder are
> not used according to the community-based Policy
>  Manual

This seems like an assumption that isn’t necessarily established fact. Care to elaborate and provide any specifics?

> |6. in order to justify its use, that resource holder 
> assign part of the delegated INRs to its clients

ISPs assign part of their delegated INRs to their clients on a daily basis. I don’t see anything wrong here. Please explain the issue?

> |7. the clients are asked to comply the the Policy 
> Manual; including the fundamental principle in "1"

In that case, what, exactly is the issue?

> |8. .
> 
> How shall it end?

From what you have described above, it seems to me that you get the following ends:

1.	The LIR in question profits.
2.	The end-user in question gets IPv4 resources they might not have been able to acquire
	otherwise.
3.	The finite IPv4 address space is utilized more efficiently.
4.	The IPv4 route fragmentation problem goes from incredible quagmire to
	incredible quagmire * 1.000001.

Overall, this doesn’t strike me as being any worse than any other IPv4 bandaid.

>> However, there are leasing agencies that insist on getting proper justification from their customers and have strong anti-abuse policies. 
>> 
> 
> Great! btw! what's their need? who need a MITM 
> in the process, when it's possible to simply transfer
> the resource or simply send it back to the free pool?

Transferring resources is incredibly capital intensive. Not all resources can be effectively or efficiently transferred (e.g. 30 /24s scattered throughout a /16). That which cannot be transferred also cannot
be returned for the same technical reasons.

>> I would strongly encourage you to seek out such an organization to partner with if you choose to lease your addresses as there are a number of pitfalls you can encounter otherwise. 
> 
> ...risks are either ways! would you recommend 
> to someone to put its private keys within one 
> else personal's computer?

No, but everyone using Hosted RPKI already does this, so…

> Hi Karim,
> To summarise, if there is no longer a need, please 
> do either one of the following three things:
> 
> 1| send it back to the RIR;
> 2| change the word *lease* to *transfer* and 
> announce your willing to transfer the INRs you hold.
> 3| do not hesitate to discuss your alternatives with 
> the RIR's Staff. They are paid to support you!

And here we have someone else’s opinion. I don’t agree with SB, but that’s nothing new.

The difference is that while I recognize that SB has some valid points, I also recognize that there are a number of nuances and complexities in the real world that prevent universal application of his advice.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230710/f3119a4d/attachment.html>