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.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
