On Mar 27, 2011, at 8:58 AM, Arifumi Matsumoto wrote: > Hi, > > Sorry for replying to an oooold thread. > > A privacy address will also be generated for a ULA prefix, > because it is treated just like a global prefix, right ?
I would think so, but there might be less need for this kind of privacy in a local environment. Bob > > On 2011/01/04, at 4:30, Brian E Carpenter wrote: > >> Pekka, >> >> Wouldn't the rule "Use ULA prefix inside the site and PA prefix (with >> privacy addresses if desired) otherwise" be simpler? And, by default, >> it would prevent the "inside" address being exported by mistake. >> >> Regards >> Brian >> >> >> On 2011-01-03 23:21, Pekka Savola wrote: >>> On Mon, 3 Jan 2011, Mark Smith wrote: >>>>> "do not use privacy addresses when communicating inside the site [a >>>>> set of >>>>> designated destination prefixes], use it by default otherwise" >>>>> >>>> >>>> I'd be curious what the benefits are. >>>> >>>> The only reason I could think of as to why to do this is to be able to >>>> associate internal application access logs with internal hosts. At face >>>> value that sounds useful, however if you really care about auditing >>>> application access and use, it isn't the hosts you need to worry about, >>>> but the people behind them - and they can usually easily change hosts. >>>> So I think those applications should be using proper AAA to identify the >>>> user, rather than using IPv6 host identifiers as very poor substitutes >>>> for user identities. >>> >>> One use case is administrators running ssh, vnc or some such remote >>> management to the client OS. The conclusion from looking at various >>> similar cases was that systems need to have a well-known (non-privacy) >>> IP where they can be reached and run TCP services at, or the privacy IP >>> needs to be stored in DNS (not much point in that..). >>> >>> Also, many site-internal access control mechanisms (for example, >>> hosts.allow for ssh, some others for e.g. web browsing) use >>> host-specific IPs in addition to other checks. In some cases these >>> could be substituted with stronger upper-layer identities e.g with >>> certificates. >>> >>> On the other hand, user identification due to static EU64 is a little >>> bit of concern e.g. with web surfing, but this also applies to other >>> applications so the issue does not go away with application-specific >>> tuning. >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
