[arin-ppml] Change of Use and ARIN (was: Re: AFRINIC And The Stability Of The Internet Number Registry System)

Mueller, Milton L milton at gatech.edu
Fri Sep 10 16:11:05 EDT 2021

You guys still banging around about this?
How about dealing with this conclusion of the article we wrote about it:

"The growth of Africa¡¯s internet to its full potential ¨C the continent¡¯s population is the same as China¡¯s, exceeds all of Europe, and is twice the size of North America¡¯s ¨C cannot be sustained by the remaining address resources of AFRINIC. Growth will only be possible if it imports large numbers of IPv4 addresses from the market, and/or relies more on IPv6 addresses. The tiny leftover portion of the IPv4 address space that AFRINIC controls is not going to sustain the kind of growth that is needed. This is a fight over crumbs. The collateral damage from this fight is not proportionate to the value of the stakes."

A Fight Over Crumbs: The AFRINIC crisis - Internet Governance Project<https://www.internetgovernance.org/2021/08/19/a-fight-over-crumbs-the-afrinic-crisis/>
AFRINIC is the Regional Internet Registry (RIR) for Africa: a nonprofit, nongovernmental Internet governance organization. Like RIPE, ARIN, APNIC and LACNIC, it operates a registry for unique internet protocol (IP) numbers that serve as network addresses. The registry records which organizations hold rights to which IP address blocks on that continent, and it also operates [¡­]

From: ARIN-PPML <arin-ppml-bounces at arin.net> on behalf of Owen DeLong via ARIN-PPML <arin-ppml at arin.net>
Sent: Friday, September 10, 2021 12:48 PM
To: John Curran <jcurran at arin.net>
Cc: arin-ppml at arin.net <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Change of Use and ARIN (was: Re: AFRINIC And The Stability Of The Internet Number Registry System)

On Sep 10, 2021, at 06:06 , John Curran <jcurran at arin.net<mailto:jcurran at arin.net>> wrote:

On 9 Sep 2021, at 2:44 PM, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:

On Sep 8, 2021, at 18:33 , John Curran <jcurran at arin.net<mailto:jcurran at arin.net>> wrote:

Under such a theory, the first LIR at ARIN could claim that they have technical need for more blocks to support their forthcoming leasing to all cloud providers in North America (a lot of need indeed)¡­   The fact that you have business relationship with a party does not make _their_ technical requirements somehow into _your_ technical requirements.

On the other hand. when an ISP connects a customer to the Internet, they often do need to supply some address space to the customer for use in the customer¡¯s network - it might be a single IP address for a customer CPE, or it could be an large block because the customer wants all of the devices on their internal network to now have Internet access ¨C i.e. precisely why they purchased Internet service.   The address space needed by the ISP is a valid technical need because ISP requires it for the connectivity service being provisioned, even if some of it is sub-assigned and utilized on customers network infrastructure.

Actually, they don¡¯t NEED to, they WANT to. They can simply refer their customer to the RIR to obtain the addresses directly. This is inconvenient and works against aggregation, but it is 100% technically possible.

The ISP is providing network services to the customer network and their services can¡¯t functional technically without the customer network being issued IP addresses¡­ it is rather obvious.

So either the customers NEED for addresses extends to the LIR and becomes the LIR¡¯s need or it doesn¡¯t.¡Ö

An ISP does not suddenly gain a technical need for more IP address space for their operational network based on some other party who has no connectivity to their network.

OK, so a connection, however tenuous, creates need, but without a connection, there¡¯s no need. Got it.

This is common practice, and nearly everyone in the ARIN ISP community is both aware of it and has submitted resource requests accordingly.

Yes, lots of things that are not necessarily policy are common practice. I¡¯m not claiming that this common practice doesn¡¯t fit within policy, but I am claiming that policy does not actually prescribe a need for connectivity to be integral to this extension of need and it does not actually proscribe the provision by an LIR of an address management service exclusive of connectivity.

You are incorrect.   Again - "Conservation of these common number spaces requires that Internet number resources be efficiently distributed to those organizations who have a technical need for them in support of operational networks."

One cannot have a _technical need_ for IP addresses based on other party¡¯s network unless there¡¯s some technical connection ¨C you can have a business need, but that¡¯s not the same thing.

Well, a technical connection doesn¡¯t have to be a connection that moves traffic. A contract to manage address resources is arguably a technical connection.

To me, the key provision of the Conservation clause isn¡¯t about how the connectivity to the addresses is arranged, but rather that a company isn¡¯t obtaining the addresses and storing them on a shelf somewhere, but instead deploying them to operational networks.

If there¡¯s some connectivity service involved, then it¡¯s fairly straightforward  to see how a technical need of a customer network can also been a technical need for the ISP/LIR.

We all agree that the typical ISP scenario is straight forward. What we are debating is whether there are other scenarios that also constitute a legitimate need under existing policy or not. I contend that there are. You, so far are attempting to deny the legitimacy of the other scenarios proposed.

You seem to be arguing that a plaintext reading of ARIN policy provides such a proscription, yet I cannot find it.

Please review above - it¡¯s rather clear.

An LIR may not assert that  they have a new _technical need_ for more IP address space as a result of signing a leasing contract.

An interesting assertion. If an LIR signs a contract agreeing to provide addresses to a customer for use on the customers operational network, how does that technical need change depending on whether or not the LIR is also providing a circuit connecting that network?

There is no need to indicate on the application whether the VPN in question will ever carry traffic or not. Leave that blank. ARIN might make assumptions, but those assumptions can¡¯t actually be verified one way or the other anyway.

Yes, I imagine that some will assert that there are connectivity services while knowing in fact that such representations are sham ¨C it¡¯s wrong to do, but the misrepresentation won¡¯t stop some people if they feel they won¡¯t get caught.

It¡¯s a connectivity service. It provides a connection between the networks. The fact that the connection isn¡¯t used to move (many) bits isn¡¯t a policy matter, technically.

If you really want to change ARIN¡¯s existing number resource policy to meet your creative new world view, please put in a policy proposal to make the change and let the community discuss and decide whether solely utilization due to leasing of address space to others should be considered a valid need for receiving additional number resource issuance.

No policy proposal is needed. Fig leaves are much easier and you¡¯ve already stated that they cover the situation adequately.

While I view the requirement for the fig leaf to be kind of silly, it makes some people happy and it costs next to nothing to implement, so why go to the trouble to pursue a policy modification that isn¡¯t all that likely to succeed due to the various emotional reactions that it would engender?

Some people would fine operating in such a manner as you describe (i.e. knowingly violating policy requiring connectivity by asserting sham connectivity services) to be perfectly fine, and others would not - it¡¯s more of an ethical question than anything else.

It¡¯s not sham connectivity, there¡¯s an actual connection and if one tries hard enough, one would be able to deliver packets through said connection. I¡¯m not sure why one would want to do so, but it¡¯s not a sham. It¡¯s a silly structure designed to comply with an asserted policy that apparently doesn¡¯t actually exist.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20210910/06d16302/attachment-0001.htm>

More information about the ARIN-PPML mailing list