[arin-ppml] Draft Policy ARIN-2019-2: Waiting List Block Size Restriction

[Jo Rhett]

Robert, I’d first like to ask that you back off on your tone. I have treated you with respect and focuses on the topic— remember that I am not your enemy. You’ll find I totally agree with your desires on most of what you’ve said, I’m just correctly some of your logic for reality in the comments below.

> I _am_ familiar with the IPv4 16-bit limit on port numbers, but I fail
> to see why that should affect the allocation size choice.  How many
> IPv4 port numbers does it take to support 10,000 unique and distinct
> web sites?

I have production services implemented by a small cluster of nodes which burn through more outbound TCP ports than can be accommodated for by less than a /26. And no that’s not a misconfiguration or something that can be optimized away as they are connecting to distinct services, thus making connection reuse impossible.

> How many IPv4 port numbers does it take to support mail service for 10,000 dmains?  Answer: One.

Only if all 10,00 domains only send mail to 6 different locations within the TIME_WAIT period. (also adjusted by max delivery per session parameters, etc etc etc)  You’d be chocked how many outbound tcp sessions are required for fairly small organization’s mail delivery. And before you answer: have you run a large scale (10mil plus messages an hour) multi-organization mail hub before? I have, and my comments are based on that experience. 10mil messages an hour required a dedicated /22 and we routinely slammed into that as a limit, ultimately moving to 16 distinct /24s for a combination of reasons.

And before you try and do the math, recall that needs to include reverse auth, DKIM auth, SPF auth, domain callbacks, greylisting/mandatory retry…  a single message delivery can utilize as many as 24 tcp/udp ports these days. 

> How many IPv4 port numbers does it take to support DNS service for 10,000 domains?

Only if those domains only request or forward queries for 6 outside references a second. That’s not reasonable for modern high-update, low TTL services. It’s completely off-based for modern kubernetes dynamic service clusters. And that’s only on the server side: modern clients can burn 100 query ports loading a single web page.

> Given these facts, I'm not persuaded that the portion of your comment
> relating to IPv4 port numbers either does have or should have any
> relevance to the selection of an appropriate initial IPv4 allocation size.

You aren’t making a valid argument, simply demonstrating your own lack of knowledge of how IP works in today’s services. You appear to be thinking of the 1980s when a single TCP connect was the session ;-) (I was there too, I’m not mocking you)   You are forgetting that IPs are used on both sides of the connection, and that most connections utilize related connections for auth/validation/security/load-balancing etc. Further, very few services return the entire content themselves, but instead build it from hundreds of other sources. Most of those connections are public in today’s microservice-based, globally load balanced architectures.

> Your concern about the inherent port number limitations of
> IPv4 seems to arise exclusively with respect to the use of IPv4 addresses as _clients_

I think I’ve already addressed this. I haven’t worked anywhere that a single connection to the public server didn’t require hundreds of related connections to other public services to deliver the page you see. Nor have I seen many web pages which don’t contain content loaded from less than 50 places. The world is more complex these days.

…and ARIN issues IPs to clients, so their needs must be considered in IP policy.

> I wonder if you can identify for me which
> organizations have a compelling need for MORE THAN that many simultaneous
> outbound IPv4 connections, and the reasons for that.

I haven’t worked for any organization in the last decade which hasn’t had hit the limits of a single /24 for outbound sessions (often 10x or 50x that). However, their needs for that are discussed under NDA with ARIN and not something I am legally allowed to publish on this channel.

> Although it is probable that some large organizations may have a need
> to support more than seventeen million simultaneous outbound client

Your math is off by a large facter here. Use (64k - reserved ports) * IP addresses / (session time + TIME_WAIT) and you’ll find a value much closer to the real life practical limit.

> I do suspect that any an all such organizations are already in possession of great gobs of IPv4 space at present anyway, and thus none of them would be materially or negatively affected by having further allocations limited to /24s.

You are making a wide-ranging judgement call based entirely on your own ignorance (not an insult) and not having faced the port exhaustion problem yourself. Just as an example, there are a decent amount of IoT startups which have only come into existence since after phase-III of exhaustion began. The big players aren’t the internet backbones that dominated usage in the 90s any more. These days, IP is really the only thing they have to offer.

>> While I wholeheartedly agree with that sentiment, there are shocking
>> amounts of US-based enterprises where IPv6 is still not available. This
>> means that anyone offering services to the enterprise requires IPv4.
> 
> For servers, yes, in small numbers as noted above.  For clients, no.

Enterprises are generally clients. 

> ARIN's choices at this moment can either encourage further IPv6 adoption or can continue to placate those who are too lazy or inept to migrate

While I agree with you (heart heart) in practice what has actually occurred is further and further bifurcation of the IP space. Please refer to the many, many papers and presentations on this topic. Yes, yes we should be embracing IPv6, and I personally am doing everything I can to drag organizations to that conclusion. But the overwhelming evidence is that enterprises and many regional networks are not playing ball.

Ronald, in summary: I get that you have only faced certain of the limitations of IP. And I get that you want a simple world. Understand that (A) it’s not as simple as we might all want it and (B) being rude and disrespectful to people while discarding the possibility of usage or needs outside your own experience does not help us create good policy. I spent an hour writing this message just to get you to calm down a bit, and stop writing to us like we’re all idiots… real life use cases are more complex than any of us can singularly understand. They can’t be wrapped into a single argument that assumes all data to answer a query is loaded on each host that receives a TCP connection. That’s just not how things work today, and attempting to write policy around these 1980s-style expectations isn’t going to work.

Please chill out, look, listen, and learn.

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.