Earlier quoted context omitted.
NAT and a Firewall are two different concepts. What's wrong with a firewall that blocks everything by default, yet all your devices have a public IP?
Maybe you don't want to reveal your internal infrastructure to the world? Seems like basic opsec.
I spent a week without IPv4 to understand IPv6 transition mechanisms
91–100 of 511 posts
Re: I spent a week without IPv4 to understand IPv6 transition mechanisms
#92Earlier quoted context omitted.
There's no chance of anybody guessing your infrastructure just by looking at your subnet. (Minimum is /64, which is HUGE!)
Every packet leaving an IPv6 network that isn't NATed has an effective node ID in the packet. No need to guess just look at the packets.
Re: I spent a week without IPv4 to understand IPv6 transition mechanisms
#93Earlier quoted context omitted.
It just makes little sense. With IPv6 instead of NAT deciding that port 2000 maps to 192.168.1.3 port 22, you have a firewall that may or not choose to route to xx:yy:zz or not, and to allow an incoming connection over port 22 to that host or not. If you don't want to accept incoming connections to a given machine or network on IPv6 without NAT that's very easy to have.
Maybe people don't want to disclose the number and purposes of interior machines?
Re: I spent a week without IPv4 to understand IPv6 transition mechanisms
#94Re: I spent a week without IPv4 to understand IPv6 transition mechanisms
#95Earlier quoted context omitted.
NAT and a Firewall are two different concepts. What's wrong with a firewall that blocks everything by default, yet all your devices have a public IP?
Maybe you don't want to reveal your internal infrastructure to the world? Seems like basic opsec.
Re: I spent a week without IPv4 to understand IPv6 transition mechanisms
#96Earlier quoted context omitted.
It just makes little sense. With IPv6 instead of NAT deciding that port 2000 maps to 192.168.1.3 port 22, you have a firewall that may or not choose to route to xx:yy:zz or not, and to allow an incoming connection over port 22 to that host or not. If you don't want to accept incoming connections to a given machine or network on IPv6 without NAT that's very easy to have.
Maybe people don't want to disclose the number and purposes of interior machines?
Now, sometimes NAT is needed anyway: QubesOS supports IPv6 using NAT because it splits things up into many different VMs on one computer. But that's a pretty rare case.
Re: I spent a week without IPv4 to understand IPv6 transition mechanisms
#97Re: I spent a week without IPv4 to understand IPv6 transition mechanisms
#98Question from a (relative) IPv6 newbie that wasn't addressed in TFA: Let's say I have a very small home lab. I have a handful of hosts that get their IP addresses via DHCP from my router. In the router, DHCP and DNS are tightly coupled such that the router essentially always knows the MAC address, IP address and hostname of each device. Now I want to run IPv6 on this network as a first-class citizen. Since DHCPv6 is…
Re: I spent a week without IPv4 to understand IPv6 transition mechanisms
#99Earlier quoted context omitted.
> what would be the best way forward to keep it that way in a IPv6-only future? Firewalls. You configure what traffic should be allowed from who to who. Default deny incoming traffic, and its the same behavior as when you had a NAT. Something having a routable IP address doesn't mean it needs to receive all traffic addressed to it.
My ISP does not allow BYOM (bring your own modem) and assigns me a /64 net, so I have a hard time running an (ipv6) router behind it that would do the firewalling.. I guess I'm stuck with ipv4 for the time being...
Re: I spent a week without IPv4 to understand IPv6 transition mechanisms
#100> You should stop thinking of NAT as a security mechanism and think of it as the emergency address exhaustion prevention that it is. I hate this attitude. This is isomporphic to saying "stop thinking of system call interfaces as a security mechanism and think of them as an address space sharing mechanism". It's not technically wrong, but it's wrong in practice. Even the most naive NAT can't misroute an inbound packet…
heck, they even inventend protocols to do automatic NAT setup (UPNP) because configuring NAT by hand confuses people a lot.