I agree with everything Owen and Albert have been saying in these latest threads. Keep up the good fight.
I've been running a dual stacked network for a college for over 10 years now and the rest of the world just needs to hurry up already. Heck, my home ISP (Mediacom) has given me IPv6 addresses for around 4 years too. You can't expect to keep running the same stuff for decades without a firmware/hardware upgrade. The "internet" is no different. Time to apply the upgrade, reboot, and more on. :) --Dan On Tue, Sep 14, 2021 at 2:47 PM Owen DeLong via ARIN-PPML <[email protected]> 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? > > >> 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. > 2. Are cameras on the public internet a disaster because it was > allowed, 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? > 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. > > >> 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 > > 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. > > 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 > > _______________________________________________ > 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.
