On Wed, Jul 25, 2018 at 4:49 PM, Aaron Falk <[email protected]> wrote:
> > I would argue that the default should be BCP for the network architecture > in question, whatever that is, and leave the determination of BCP to those > SMEs. > > That might work, too. > > I assume by 'network architecture' we are talking about 'access > technologies', yes? > I was intentionally being very generic. You're unlikely to come up with privacy addresses (as such) on v4, given the paucity of the address space, but the NAT itself can do useful things to hide the identity of an individual user if the network behind the NAT is large enough. > If those BCPs are stated somewhere, that seems reasonable. I'm not sure > whether this has been considered in depth or in an > access-technology-specific way. Any citations? > RFC 7217 has no BCP number, but it is a proposed standard and is widely-accepted best practice for v6 operators using SLAAC. The DHCPv6 bis document (full disclosure: which I reviewed for secdir) contains some language around user privacy. For v4 with NAT, there's 1631: q[ On the other hand, NAT itself can be seen as providing a kind of privacy mechanism. This comes from the fact that machines on the backbone cannot monitor which hosts are sending and receiving traffic (assuming of course that the application data is encrypted) ] and the document that obsoleted it, 3022, which reorders the q[ Traditional NAT can be viewed as providing a privacy mechanism as sessions are uni-directional from private hosts and the actual addresses of the private hosts are not visible to external hosts. ] Curious to know what the IESG thinks about this one (or indeed anything related to NAT) now, but any further discussion along those lines can probably be taken to ietf@. ;-) Kyle
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
