Subject: Re: addrsel: privacy addresses within/out of a site

From: Arifumi Matsumoto <[email-masked]>
Date: Sun, 27 Mar 2011 15:58:42 +0900

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
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Sun, 27 Mar 2011 09:12:30 +0200

> 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

---

From: Fernando Gont <[email-masked]>
Date: Sun, 27 Mar 2011 19:57:01 -0300

Hi, Arifumi,

> because it is treated just like a global prefix, right ?

Yes. This would be another scenario in which
draft-gont-6man-managing-privacy-extensions would be of help. You'd
advertise the ULA prefix recommending Modified EUI-64 Identifiers, and
that's it.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1