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

[Ronald F. Guilmette]

In message <505CC598-C864-4BEC-893B-6BBF0DE974B4 at netconsonance.com>, 
Jo Rhett <jrhett at netconsonance.com> wrote:

>You aren't taking into account limitations of IPv4 64k ports and
>reuse timers.

I cannot intelligently comment of RFD resue timer issues, as I am
fundamentally ignorant of that whole areas and/or how it might be
relevant to the choice of larger or smaller allocations.  Perhaps
you will enlighten me.  I suspect however that whatever issues lie
there will not be materially different if IPv4 allocattions, going
forward, are either /22s or /24s.  (But I would be happy to see some
actal quantification of the diffence between these two choices.)

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?  Answer: One.  How many IPv4 port numbers does it take to
support mail service for 10,000 dmains?  Answer: One.  How many IPv4
port numbers does it take to support DNS service for 10,000 domains?
Answer: One.

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.

>This {IPv4} protocol was created in the 1970s, and port reuse has
>been sped up but cannot be solved.

See above.  Your concern about the inherent port number limitations of
IPv4 seems to arise exclusively with respect to the use of IPv4 addresses
as _clients_.  As I noted above, use of IPv4 addresses as _servers_
does not appear to suffer unduly due to IPv4 port limitations.

With respect to the use of IPv4 addresses as clients, I do concede that
limiting an allocation to just a /24 would indeed limit the user of
such a block to no more than 65,536 * 256 = 16,777,216, i.e. a maximum
of nearly seventeen million simultaneous outbound client connections.
But that having been said, 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.

Although it is probable that some large organizations may have a need
to support more than seventeen million simultaneous outbound client
connections, all of them being strictly of the IPv4 kind, 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.

>> For anyone needing to support big batches of end-luser clients, there
>>is IPv6.
>
>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.

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
clients to IPv6 and/or to make efficient use of their limited IPv4 blocks,
spcifically for servers configured to support multiple domains on a single
IPv4 address and on a single IPv4 port.


Regards,
rfg