[arin-ppml] Draft Policy ARIN-2019-2: Waiting List Block Size Restriction
hostmaster at uneedus.com
hostmaster at uneedus.com
Sat Mar 2 18:24:03 EST 2019
I have suggested elimination of the Wait List, and sending all returns to
the IPv6 Deployment block, but I have seen noone that agrees with me.
I also suggested that directed transfers be a one shot deal, which would
also limit the options of the bad actors we speak of since they could
obtain space but cannot resell it. Again, no one seems to agree with this
suggestion. Both these suggestions have been ignored, likely because I
have not written a policy proposal to do either.
I would also suggest stronger measures at ARIN, such as no receiving
transfers of IPv4 space unless/until you have IPv6 space that is up and
running the same services you intend to use with the IPv4 block being
transferred to you.
I even once suggested that ARIN Online be made IPv6 only, to make sure
those who interact with ARIN have a IPv6 connection.
It has been 8 years since the last IPv4 blocks were given to ARIN, and yet
there are still many who do not want to ever move to IPv6. Some even
believe something else to replace IPv4 will suddenly pop up and "save"
them from IPv6. They need to get their head out of the sand. IPv6 IS the
route to the future, and bandaids like EZ-ip and others just need to go
away. IPv6 IS the future.
We are now voting on what is been presented in THIS policy. I think a
limit of /22 is better than no limit which is the current policy. Thus I
support the proposal and I do think it will reduce abuse when compared to
the current policy with no limit.
I have no desire to "Save" IPv4, and would actually like to get to the
point that it is a minority of traffic on the Internet. At that point,
since IPv4 will have costs over and above IPv6 such as CGNAT and buying
addresses, access providers may actually start charging more for IPv4.
Each of these baby steps like this one today do move us slowly toward
moving the entire internet to IPv6.
Paradise On Line Inc.
On Sat, 2 Mar 2019, Steven Ryerse wrote:
> Trying to pick a limit such as a /22 is arbitrary and an argument for and against that number or any other number can always be made.
> This is another attempt to somehow save IP v4 and we already know it cant be saved.
> The market is currently balancing out the IP v4 supply and it will continue to do so if it is allowed to, until the supply dries up and the demand will switch to IP v6.
> If a policy is being abused then the policy should be improved. The board should share info on what exactly is being abused and the community can come up with a solution even if it is imperfect.
> ARINs primary role is to further the internet and it isnt to be the Internet cop. ARIN should continue to apply the current policies and point out flaws so this community can find reasonable solutions.
> ARINs should continue to strive to perform it primary mission above all else, which is in large part how the Internet has become such a success story- imperfect though it may be.
> My 2 cents.
> Sent from my iPhone
>> On Mar 2, 2019, at 3:35 PM, "hostmaster at uneedus.com" <hostmaster at uneedus.com> wrote:
>> Many hosting and access providers like to give each paying customer their own IPv4 address, since it simplifies DMCA compliance. Otherwise the hosting provider needs to get into the middle of keeping logs for every customer. Even though SNI allows more than one https site per IP, it does not create a division for DMCA purposes. Often in actual fact, each "Customer" has further divided his/her hosting space to host for multiple websites, sometimes belonging to other people than the ones paying the bill to the hosting provider. This includes each customer using SNI to determine the identity of the many websites that each customer is hosting themselves.
>> /22 in the proposal is a maximum. They would still have to show how they intend to use the space in accordance with 4.2.2 if they want more than a /24.
>> I say lets try the /22, and if needed reduce it. Remember 188.8.131.52 sets the minimum at /24, so setting it at /24 is a one size fits all policy.
>> As for NAT and even web hosting, the 64k port limitation is also an issue as pointed out by others. While hosting many sites on a single IPv4 address can be done, it may not be considered rational when considering compliance with many laws that are required, including the DMCA. This is one of the factors that speak against the use of CGNAT for internet access customers, unless the customers are divided by port address ranges or like means. Otherwise the ISP has to get into the logging business, which can also turn into a big cost center.
>> Albert Erdmann
>> Network Administrator
>> Paradise On Line Inc.
>>> On Sat, 2 Mar 2019, Ronald F. Guilmette wrote:
>>> In message <Pine.LNX.4.64.1903021333190.3734 at localhost.localdomain>,
>>> hostmaster at uneedus.com wrote:
>>>> Our choices with this Draft Policy:
>>>> 1) Reject it because it does not completely eliminate the abuse, and allow
>>>> the current policy (with ALL its abuse) to continue.
>>>> 2) Adopt the policy even though not perfect at eliminating ALL the abuse,
>>>> but does cut back much of it.
>>> Please allow me to note that there is also a third option:
>>> 3) Adopt the policy, but select some different default allocation size,
>>> other than /22.
>>> Personally, I think that a /22 is the Wrong Way To Go and it would be better
>>> to change that to a single /24.
>>> I mean what do people even need lots of IPv4 for anymore anyway? A single
>>> web server with a single IPv4 address can easily support tens of thousands
>>> of distinct and unique web sites. A single mail server on a single IPv4
>>> address can likewise support mail services for tens of thousands of
>>> recipient and sender domain names. A single name server on a single IPv4
>>> address can also provide DNS service for tens of thusands of domain names.
>>> For anyone needing to support big batches of end-luser clients, there is
>>> 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:
>>> Please contact info at arin.net if you experience any issues.
>> 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:
>> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML