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

[hostmaster at uneedus.com]

Generally providers that share IPv4 addresses (client or servers) divide 
the port address ranges among their customers, so they do not have to log 
every communication for DMCA purposes.  A single webpage retreival might 
have over 100 image or other elements contained within it, requiring 100 
different connections for each page load.  A common division is a 1000 
port range for each customer, meaning each IP can only serve 64 customers. 
Each connection has a maximum NAT timeout value that may be as high as 3 
minutes or more.  Thus you can see that 10 page loads from a single host 
will max out the NAT timers, such that no more can be loaded.  As long as 
the entire site is under the control of a single entity, this kind of 
magic is not required, and the entire 64k port values can be used. 
However in the case of shared hosting where each customer must be able to 
be identified for DMCA purposes, running out of port numbers is in fact 
quite common.

ARIN rules do not require I must use IP sharing when doing so creates 
other costs such as DMCA logging of all connections.  Under ARIN policy, 1 
IPv4 address per customer is perfectly rational, and happens every day in 
the internet access service market.

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Sat, 2 Mar 2019, Ronald F. Guilmette wrote:

>
> 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
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>