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

[Owen DeLong]

> On Sep 14, 2021, at 20:28 , Joe Maimon <jmaimon at chl.com> wrote:
> 
> 
> 
> Owen DeLong wrote:
>>> 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.
>> Why? It’s a local application only technology not useful on the broader internet, so why bother to standardize it? Why waste time of the standards bodies?
> 
> Because the standard bodies exist to serve the needs of the users of the network and it would behoove them to remember that.

Serving the needs of users doesn’t necessarily mean pandering to every vocal minority.

> We have already learned from IPv4 NAT that having standards is better than not.

We have also learned from IPv4 NAT that having a need for NAT sucks, that NAT sucks, and removing it from the world would be a service to all.

>> 
>>>> 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.
>> Actually, I’d suggest the following:
>> 	1.	NAT Is NOT a substitution for a firewall. It might be integral in the firewall in IPv4, but that’s not the same thing.
> 
> Reverse. The exact functionality of a firewall over an access list is state. Which is integral to NAT as deployed in IPv4.

Depends on the firewall. Some firewalls are not stateful.

> The state serves to allow construction of restrictive access lists by amplifying their permissiveness, which are what actually provides the firewall security.
> 
> Without state, ACL's are not workable for general usage, and that includes the default deny all implicit rule that might or might not exist in the ACL.

And yet they’re working just fine in my environment. Interesting.

> In short, firewall state exists primarily to permit traffic, not to disallow it. As does NAT.

NAT existis primarily to mutilate packet headers and obfuscate addressing. It has nothing to do with permitting or denying traffic.

> (I am sure you know this, but just in case anybody else is still reading this thread....)
> 
>> 	2.	Are cameras on the public internet a disaster because it was allowed,
> 
> As if there exists some process to allow or disallow certain devices to be connected to the public internet.

Not my point, but you knew that because you did actually read the rest of the sentence.

>>  or are they a disaster because MFRs were
>> 		able to assume that NAT would protect them from bad engineering and somehow everyone bought into the idea
>> 		that such an assumption and bad engineering was acceptable?
> 
> Neither, they are a disaster because a) security is not their manufactures (or users, or installers) strong suit or even focus and b) they dont get upgraded, just replaced.

Yes, but a) is true largely because they (manufacturers) haven’t had to think about it because they’ve been able to operate under this false assumption that NAT makes everything safe (it does NOT).

> Those championing IoT somehow think it will be better.

Nope… Not until manufacturers are forced to come to terms with transparent addressing and the need to harden hosts.

> I think it more likely that expecting dual specialty, both in the particular application deployed and in the networking and securing of it is never going to realistically occur in any sort of widespread meaningful fashion.

Then it doesn’t matter how badly we screw up the network with NAT, it’s still going to be completely buggered by security problems.

> And those whose specialty is networking and the securing of it would do well to take that into account.

And do what, exactly, with that information? Pretend that NAT is a solution or anything remotely resembling protection? HAH!

> 
>> 	3.	I’d argue that switching the expectation from “Everything is behind NAT, so it’s OK to be security-careless” to
>> 		“Everything is publicly addressable and might be reachable, therefore security is important” would be very
>> 		good for the industry as a whole, not to mention end users. Yes, there will be some pain points as this
>> 		transition occurs, but the end result is highly desirable.
> 
> The only thing that will change, maybe, is that SOHO ipv6 routers will ship with default deny all. At least the responsible ones. Hopefully.

That’s not a change, that’s the current state of things.

> Or worse, is that they will choose to use ULA/NAT or similar and utterly disregard (as they have demonstrated already with IPv6 deployment that they are completely capable of doing so) what you or other standards bodies or anyone else have to say on the matter. Unless they are bringing their pocketbooks to the table.

Fortunately, this hasn’t been implemented on most of them. At least we agree this would be worse.

>>> I expect exactly that. I expect you to support peoples ability to make this choice, since the current alternative is
>> So you expect everyone else to put in effort to support your choice of technology because you don’t like our choice… Sounds a lot like your reasons earlier claiming we shouldn’t expect v6 to be widely deployed any time soon.
> 
> Reverse. I request you (and others of similar bend) stop putting in effort to hamper those who choose to, particularly and specifically when those efforts are born from ideologically preferences for choices already rejected by large portions of the internet.
> 
> If you choose to actually help, more power to you. And since I believe that better mechanisms could serve to boost IPv6 rate of adoption, perhaps you should. Since thats what you want. Unless you only want it on your terms, or not at all.

I’m not hampering, I’m just encouraging standards bodies to focus on things that matter to me.

>> You’ve successfully argued against yourself here. The advantage goes to v6 without NAT because it is further along in deployment than any effort to standardize NATv6 (fortunately).
>> 
>> Owen
>> 
> 
> My argument is that NAT in IPv6 is more likely to increase deployment of IPv6. Whatever your feelings towards NAT, I expect you would take the win and comfort yourself with hope that eventually those choosing or needing to use it will dwindle away and deliver your p2p utopia back unto you. Which I think is actually quite possible.

Your argument is false. NAT does not increase deployment of IPv6 even where it exists. It does, however, degrade IPv6 into the lack of transparent addressing and second class citizenry that currently plagues IPv4.

Owen