Dear Michiel,

27 Jan 19 00:10, you wrote to me:

 VS>> Of course it does more! No packet filter *hides* *src*
 VS>> *addresses* of your internal hosts,

 MV> So what? A device on the LAN that communicates with the outside world
 MV> uses a public address.

Are you pulling my leg, or don't you really understand the difference? A 
*thousand* devices on the LAN use *one* public address (or maybe a dozen public 
addresses) when communicating with the outside world.

 MV> In the case of IPv4 with NAT it is a public WAN
 MV> address of the router. In case of IPv6 it is a public address in the
 MV> prefix range assigned to the router.

But the devices on the LAN become uniqely mappable from the outside. That's the 
point. In the case without NAT (a global IP address per internal host), the bad 
guys will have to resort to canvas fingerprinting, cookie abuse or other less 
reliable techniques.

 MV> In either case the address used
 MV> is "exposed".

 VS>> and that is exactly what security people love NAT for.

 MV> Hmmm... I would rather not put my faith in the hands of a "security
 MV> expert" that believes in "security through obscurity"...

Do you call *any* attempt to keep sensitive information private "security 
through obscurity"? Would you also, for example, call  RFC4941 mechanism 
"security through obscurity"? Then you probably misunderstand the terminology.

Besides, speaking about private addresses proper, you often have no choice: 
this requirement has made it into too many security checklists and would be too 
difficult to get rid of even if we wanted.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322