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 ? 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 > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
