https://superuser.com/questions/1055584/how-does-ipv6-affect...
- Smaller headers
- Simpler routing
ON the other hand, theoretically IPv4 header length could vary depending on the presence of IP options, so you'd need to compute the offset to continue processing the packet.
(I say theoretically because conventional wisdom is that IP options are unreliable in the face of middleboxes, so they're mostly unused. But compliant IPv4 processors have to calculate the header size anyways...)
privacy nightmare
You're fear of IP tracking is outdated.
Yes, which is why I don't use IPv6.
https://blog.apnic.net/2022/01/31/defeating-ipv6-prefix-rota...
hope you dont have any tweets that offend your goverment lol
NAT is not a privacy or security feature. You can treat it like it is, but only at your own risk.
https://www.anvilsecure.com/blog/dhcp-games-with-smart-route...
https://datatracker.ietf.org/doc/html/rfc2993#page-22
https://threatpost.com/remote-attackers-internal-network-dev...
Is about device tracking and privacy
So, no. NAT gives you 0 privacy.
1:many NAT does.
1:many NAT requires an affirmative choice on where to route incoming packets that aren't part of an existing stream.
In adaptation to that, most attacks are malware spread by email, or attack browser vulnerabilities, or attack services running on network devices, especially remote management systems.
> 1:many NAT does.
This is technically correct but how often do you really see 1:1 NAT.
NAT doesn't make any choices on where a packet gets delivered. For packets that aren't part of an existing steam, NAT will simply not edit the packet. Unless there's a separate firewall that chooses to drop it, the packet will get delivered to whatever IP was already in the destination field, which could be the IP of one of your LAN machines.
A 1:1 NAT should generally just swap IP for IP and not know about streams or ports at all.
> Unless there's a separate firewall that chooses to drop it, the packet will get delivered to whatever IP was already in the destination field, which could be the IP of one of your LAN machines.
I would call that a routing rules error, even in the absence of a firewall.
How could a device have a hardware-embedded IP address, if the hardware vendor doesn't know which ISP you will use?
By putting the hardware part in the second half, and the ISP part in the first half.
You know, like how it works by default.
But then why were you asking "how" a device could have a permanent hardware identifier with its address? Just don't implement those optional RFCs.
And the comment you were replying to didn't say it had to be the entire address, and there's no reason for it to be.
I agree with what you said. It's just interesting how it illustrates how different things are now.
I remember a bunch of people being horrified by the idea of 1 device per IP. I think it's more a matter of who you were around then the group changing their mind, but maybe that happened too.
The fact that peer-to-peer applications can finally start working is an unquestionable advantage.