[arin-ppml] Proposal - Remove Initial Small Assignment Requirements for IPv6

hostmaster at uneedus.com hostmaster at uneedus.com
Tue Sep 14 14:23:33 EDT 2021


I still think that IPv6 is here to stay, and have tried tests with IPv4 
disabled, and at this point I am guessing I can get about 75% of the 
normal surfing to work.  Of course arin.net works, as it is hard to push 
v6 without eating your own dog food.  I figure at this rate, I might get 
toward 90% in a couple of more years.  While there are those who refuse to 
have IPv6, the majority of new stuff seems to come up using other peoples 
servers such as AWS that already have IPv6 in place.

It will get harder to free up much more of the v4 space.  The bottom line 
is that we are working against a basic math problem, where there are fewer 
possible addresses than persons on the earth, and there is demand for more 
than one address per person. IPv6 solves the problem, IPv4 does not.

Everyone takes a different approach to the problem.  I understand that 
some players have only v6 in their main network, and only provide v4 on 
the edges as part of a translation means.

I strongly suspect that most CGnat is deployed outside of the US, where 
they of course can freely ignore silly laws like CALEA.

And of course there is no reason to simply provide routed v6 service in 
conjunction with your v4 being part of CGnat.  As more and more services 
are offered over time on IPv6, that helps you reduce the load on those 
boxes.

I understand the issues of running cameras on public addresses, and of 
course the need for strong auth of your users.  However, this is better 
than the so called cloud cameras, where you cannot control your own data. 
Of course remember that the term "cloud" simply means someone elses 
machine.  I would be more worried with hacking in a shared network like 
Ring where they also might share your images without your consent.

My customers would not put up with lack of public addresses, and I am not 
IPv4 constrained at this time.  I am hoping for more movement toward IPv6 
over time so I do not ever have to worry about lack of addresses.

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Tue, 14 Sep 2021, Joe Maimon wrote:

>
>
> hostmaster at uneedus.com wrote:
>> No, nat eliminates all the various translation tables, and the rewriting of 
>> headers that NAT requires.  This extra overhead shows in the form of slower 
>> connections when NAT is used.
> Yes of course. Except that modern hardware has made this definition of 
> "slower" meaningless in most if not all use cases.
>> 
>> Also, did you forget (if you are in the USA) CALEA?  If you translate all 
>> your customers traffic, CALEA requirements more or less mean you have to 
>> log all that traffic on those CGNAT boxes, which will alone defeat any of 
>> the cost savings of CGNAT.
> So? Already the case. Hasnt stopped CGNAT.
>> 
>> Smart ISP's with IPv4 shortages that use CGnat often do port mapping with 
>> their customers so that they do not have to log.  A certain range of ports 
>> are provided to each customer, so that no logging is required.
>
> Indeed. Awesome.
>
>> 
>> And since there are PLENTY of IPv6 addresses, why use effort processing 
>> IPv6 in a CGnat box?  That part makes no sense at all. Just route the 
>> packets and be done with it.
>
> Try it in the reverse. Use your cgnat box so that your can IPv6 only customer 
> nodes that can continue to access the rest of the Internet, primarily IPv4 
> nodes.
>
>> 
>> Honestly, the only reason I can see for NAT on IPv6 is so fallover in a 
>> multihome enviroment that can be handled the same as it is with IPv4 so 
>> that BGP is not required for fallover.
>
> The point is that at this time, we should not have to justify nat in order to 
> permit its standardization. Standardize it and let users figure it out.
>
>> 
>> Nat also assumes that noone wants to run their own internet services. While 
>> many things like cameras use a remote server to bypass the NAT leading to 
>> vendor tiein, things are clearly cleaner if each workstation or other 
>> device like a camera can run its own publically accessable services. Note 
>> that this does not mean that firewalls cannot be in place to block things 
>> that are not intended to be world readable. NAT is NOT a substitute for a 
>> firewall.
>
> It is in IPv4. And lets not encourage camera server and devices to be 
> globally accessible, we already know that is a disaster.
>
>> 
>> If you want NAT on the networks you manage, go for it.  All the tech bits 
>> to make NAT work in IPv6 are there.  Just do not expect the rest of us that 
>> would like to get back to the end-to-end model to support your choice, and 
>> I am sure some of your users will wish you did not make that choice, 
>> because of things they want that may not work in this enviroment.
>
> I expect exactly that. I expect you to support peoples ability to make this 
> choice, since the current alternative is
>
> a) dictatorial
> b) not working
> c) delaying IPv6 deployment
>
>> 
>> Some of the best proponents of v6 is the gaming community, which have been 
>> fighting the limitations of NAT for as long as they have been around.
>> 
>> Albert Erdmann
>> Network Administrator
>> Paradise On Line Inc.
>
> Supporting its existence is not actually the same as supporting its 
> widespread deployment.
>
> Better it be standardized and move on.
>
>
>> 
>> On Tue, 14 Sep 2021, Joe Maimon wrote:
>> 
>>> The problem is that No NAT for IPv6 is religious dogma, regardless of the 
>>> reason anyone may have for wanting it, which may have nothing at all to do 
>>> with address sharing. Even fixing multihoming and readdressing (to the 
>>> extent it may be possible) will not eliminate any and all motivations for 
>>> NAT. Its time to standardize NAT and move on.
>>> 
>>> Now imagine if all those CGNAT boxes are also doing a workable version of 
>>> NAT-PT. Deploying customers with any IPv4 becomes optional.
>
> That was supposed to also be read with the same meaning as "without any IPv4"
>
> Joe
>



More information about the ARIN-PPML mailing list