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   
    * Origin: Ulthar (2:5005/49)