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.

Albert Erdmann
Network Administrator
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 can?t 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 isn?t 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, "[email protected]" <[email protected]> 
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 4.2.1.5 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 <[email protected]>,
[email protected] 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.

or

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
IPv6.


Regards,
rfg

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

Reply via email to