> On Jul 10, 2023, at 06:58, Sylvain Baya <absc...@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@nanog.org 
> <mailto:nanog@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

Reply via email to