Harald Alvestrand wrote : > Rémi Després wrote: >>> My desire to have privacy is, in itself, something I may want to keep >>> private. >> I am not sure I see the practical consequences. >> If my source address says "I am someone but you will not know who I >> am", isn't this sufficient? > > You're not thinking this through. > > Think of the case where there are 1000 users on a LAN, and one of them > desires to use the address privacy option for all the normal reasons. > > Then think about the policeman / bad guy / secret agent / mafioso with a > trace of all traffic from that LAN - he can immediately say that the 999 > were using non-privacy-enhanced addresses, and the resulting trace will > show him immediately what the 1000th was up to, no matter how many times > he changed his address. Right if the user keeps the same address for a series of outgoing connections. However things are different in the context in which I proposed, in earlier mails of the same thread, that the resolver would query the DNS for site prefixes. The concern was client hosts for which one desires both: (1) a privacy similar to that offered by NATs; (2) undisturbed E2E significance of addresses and ports. For this, the idea at hand is that these clients would use a fresh privacy address for each outgoing connection (with some more specification work left to avoid unreasonable Duplicate Address Detection). If this is done, the poor mafioso will believe that consecutive connections of a single host are connections initiated by various hosts (or at least will be unable to decide which connections come from the same host) :-). >>> If what you want to know is indeed "which site is at the other end", >>> wildcards at the /64 level will achieve that with no changes to >>> existing code. >> I am not familiar enough with wildcard operation in the DNS. >> If it provides for queries that concern only site prefixes, then you >> are right: no need for an agreed "wildcard IID". >> The result is the same with existing mechanisms, which is clearly better. > Read RFC 1034 - or perhaps better, RFC 4592. They've been around for a > while (although their behaviour still surprises many). Thanks. I will have a look. _______________________________________________ IETF mailing list IETF@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf