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

[hostmaster at uneedus.com]

Each of the webserver instances are leased to others. They are in control 
of the Apache configuration on their individual Apache instance, and 
nearly all of them have multiple websites on them, run by the person 
leasing the server.  Under the DMCA, the person leasing is responsible for 
the DMCA complaints and if I receive one from someone that chooses to 
ignore the SWIP record and sends it to me (1st upstream), I simply forward 
it back to the customer for processing.  In any case I know of no way to 
have multiple instances of Apache (one controlled by each customer) 
running on the same machine without each instance being bound to its own 
IP address.

As to CALEA, you are NOT allowed to tell the customer that they are being 
monitored.  Thus, even if Apache allowed the monitoring to take place, you 
could not use that feature since changing the Apache config of a customer 
to permit it would be the same as telling them you are doing it. 
Besides, they might overwrite any changes you made with their next update 
if they maintain and edit local copies of these files on their computer 
and simply upload updates as needed or use other version control tools 
that would flag changes.  Apache is also not the only thing you must 
monitor with a CALEA Order.  You must provide ALL communication to and 
from the customer, including things like SMTP, FTP, POP3 and even SSH. 
Effectively, it is the same as an sniffer on the IP address of the 
ethernet, and in fact tcpdump is the tool we use here to capture the 
communications from their assigned IP after instructing the switch to 
allow it to be dumped to a monitoring machine.  As you point out in your 
posting it is the *transmission* function that is subject to CALEA. 
While you are not required to hand over emails and the like that are 
stored on the machine, any files transmitted over the connection to the 
internet are fair game, including email if they choose to download it 
across the internet connection in the clear. The CALEA order is directed 
to the internet connection of the person named in the order, and not the 
machine itself. One big loophole to CALEA being effective in this case is 
that if the machine encrypts the transmissions being sent to/from the 
internet, you are only required to provide the actual transmission of data 
to/from the internet, which is encrypted.  Same with SSH, Https and the 
secure versions of Imap and Pop3. In todays world, they are not getting 
very much in the clear.

While I understand that you would like to see all hosting done with the 
use of the fewest possible IPv4 address use to conserve it for the longest 
period of time.  However ARIN policy does not require this.

I do think that IPv4 will not be the primary protocol of the internet in 
10 years. IPv6 will win the battle in the long run. Most of the top 1000 
web sites already have it, and many of the access providers already 
provide it. Google is already at 25%. Ironically, due to the differences 
in SWIP for IPv4 and IPv6, it is required to give each IPv6 customer a 
full /64 in order to register their contact information in SWIP, while 
current rules for IPv4 allow (but do not require) SWIP registration all 
the way down to a /32.

Mobile app stores have moved to a IPv6 requirement. Even Facebook has said 
they moved most of their network to IPv6 to avoid CGNAT for a better and 
faster customer experence for those customers with IPv6 addresses.  They 
even reported that IPv6 can be faster than IPv4 based on their 
measurements.

ARIN tried to get the world's operators to get on board routing networks 
smaller than a /24 but had no luck.  Therefore asking ARIN to assign 
networks smaller than a /24 is a non starter.

I know that hosting can cram thousands of hosting accounts onto just one 
IP address.  The problem here is it is hundreds of wholesale hosting 
accounts each controled individually, each account hosting hundreds of 
domains.  That is a bit harder to operate on a single IP. We do give each 
wholesale customer their own IPv4 and IPv6 address as they request.

This discussion has drifted very far from choosing a /22 maximum, a /24 
maximum or other items in the Draft Proposal or its reasonable amendments 
would suggest. As previously discussed, it is really about if a /22 would 
have less abuse than the current policy.  Or a /23 or /24 as you suggested 
to make the wait list maximum as low as a /24.

The current ARIN assignment guidelines would have no problem with my 1 per 
customer IPv4 assignment as this is the "normal" standard worldwide. 
Since you believe everything should run under a single IP, I am guessing 
you will never have to go to ARIN for space, since you can clearly get 
that single IP from whoever your access provider is.  ARIN policy does not 
permit smaller than a /24. (4.2.1.5)

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Sun, 3 Mar 2019, Ronald F. Guilmette wrote:

>
> In message <Pine.LNX.4.64.1903030119350.26017 at localhost.localdomain>,
> hostmaster at uneedus.com wrote:
>
>> Strictly speaking, the laws talked about do not REQUIRE each customer have
>> his/her own IP address, but from a practical point of view, giving each
>> customer his/her own IP address is the easiest way to comply with these
>> laws.
>>
>> Examples include CALEA, which starts at 42 USC 1002.  This law requires
>> certain parties including internet access providers to provide under court
>> order the content of communications upon service of a Court Order.
>> Effectively, this is a wiretap.  Without each customer connection having
>> its own unique address, it is nearly impossible to comply with this law. A
>> wiretap order can be obtained against a website, and the law requires the
>> communication operator to deliver to the government JUST the communication
>> of the subject of the order.  In the case of shared hosting, without a
>> unique identifer such as an IP address, it would be very difficult to
>> comply with the order and redirect a copy of their communications to the
>> government that does not contain the communications of all your customers.
>
> I believe that I have understood you, but I also believe that it sounds
> like utter lunacy to me that nobody working on, say, Apache, has yet
> devised a solution for that seemingly simple (individual web site
> "wiretap") problem that would work in the case of shared hosting.
>
> It doesn't sound on the face of it like a terrifically hard problem.
>
> I guess that somebody should ask the Apache folks about that.  I guess
> that will be me, since it appers that nobody who is actually in the
> hosting business has yet bothered to do so.
>
>> The other well known example is the DMCA. which is at 17 USC 512 et seq.
>> It requires disabling or taking down content that someone swears is
>> violating their copyright, or the operator becomes responsible for the
>> infringement.
>
> Yeabut they can't just come to you and say "Please immediately take
> down SOMETHING" and not adeuqately specify what they mean, specifically,
> by "SOMETHING".  They've got to give you a URL, and that URL has to begin
> with a domain name, so you can just remove that one domain name from your
> Apache config and be done with it.  What's the problem?
>
>> If all the websites are hosted by a single server instance on the same
>> machine, of course this can be easily done by the operator by simply
>> knowing the URL of the content.  However, not all shared hosting happens
>> that way.  Those with high demand content might be hosted on a dedicated
>> server that is leased to another party.
>
> Great!  So then if you get a DMCA for that, then you just shut off power
> to that one server.  Problem solved, no?
>
>> For less demanding content, an
>> instance of the webserver running on a shared server might instead be
>> used.  In any case, each person leasing a server or webserver instance
>> controls completely what websites they choose to support.  If the IP is
>> shared as suggested, all the DMCA notices are going to be directed to the
>> owner of the server, who will not without engaging in a logging operation
>> know which instance (and therefore which customer) is hosting the
>> offending content.
>
> You're talking in circles.  You have a DMCA complaint.  It specifies
> a URL.  You are in the professional hosting business and yet you're
> seriously telling me that you can't for the life of you figure out
> how to shut off -just- that one revelant domain name without burning
> all sorts of other and unrelated stuff to the ground?
>
> Please do excuse my incredulity.
>
>> By keeping each customer on his/her own IP address,
>> the owner will know which customer is responsible since the report will
>> contain the IP.
>
> So your claim is that its actually legally impossible to do shared hosting,
> using Apache, anywhere in these United States, because if anyone tries
> to do that, they will have to burn their whole shop to the ground in order
> to eliminate that one pesky infringer who only owns one single domain name?
>
>> While this is the not the most efficient use of address space...
>
> That's got to be the understatement of the millenia.
>
> You've just asserted that even though Apache can host a few million web
> sites all on one IPv4 address, the dumbasses who write the laws in this
> country have cereated these requirements -and- that neither you nor anybody
> else in the hosting businsess has managed to figure out how to satisfy
> those requirements without unpacking each and every individual web site
> onto its own unique IP address.  (And of course these all have to be IPv4
> addresses, specifically.  IPv6 addresses just won't do, because otherwise
> 90% of the planet still won't be able to see the content.)
>
> I can't help being facinated by these assertions because I could have
> sworn that I saw, in some of the passive DNS data that I was looking at,
> really quite recently, evidence indicating that at least -some- hosting
> companies right here in the good old U.S. of A. *are* in fact packing
> in their web hosting clients, like sardines, thousands at a time, onto
> -single- shared IPv4 addresses.  But now you inform me that they can't
> possibly do that without violating feredal law.  So I guess it must
> all have been a big halicunation on my part.  Sorry.  My mistake.
>
> Well, anyway, this all is still beating around the bush.  I give you a /24
> and you *can* still host 256 separate customers on that, right?  For all
> those that only need to run clients, you give them IPv6 instead. Only
> the ones who really need to run their own servers, you give each of those
> persons or organizations -one- IPv4 address to do it on.  If one organization
> needs to have fifteen different corporate web sites, then fine.  They can
> do that all from that one IPv4 address, and much much more, as needed.
>
>> The other thing I disagree with is your suggestion that clients should be
>> on IPv6 and servers on IPv4.  In fact, without the use of translation
>> technology, the two protocols cannot directly talk to each other.
>
> Yes.  And?
>
> Are you telling me that no such translators have been deployed already,
> even here in 2019?
>
> And isn't there a nice simple one-to-one mapping of each and every IPv4
> address to its counterpart in the IPv6 space, so that translating from
> IPv6 down to IPv4 and/or back again is actually rather straightfoward
> and highly efficient, if not to say trivial?
>
>
> 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.
>