Subject: Policy for use of privacy addresses?

From: Tim Chown <[email-masked]>
Date: Tue, 2 Aug 2005 18:49:50 +0100

Hi,

I raised this question today but we were short of time.

My concern is that in an enterprise deployment, I might want to avoid the
complexity of privacy addresses (from the management perspective).

The context today was that in the proposal to distribute address selection
policy (RFC3484) by DHCP (which I think is a nice idea, as we need some
way to do that), how would one express preference for privacy over public
for source address (or vice versa), given privacy addresses aren't prefix
specific?  I think 3484 says use globals in preference to private addresses
by default.

In a managed DHC environment, privacy addresses can be returned by DHCPv6
for client use, but my reading of RFC3315 suggests (section 12) that the
request is client initiated, which implies there should/could be some policy
that could be distributed by DHCP itself to hint to the client that it can
make the request.

I appreciate Keith's point that per-application (non) usage may also be 
desirable, but there is an API being proposed for that?  It should probably
have some relationship to the site policy though?

I can also see in some environments that privacy usage may be quite normal,
e.g. in unmanged home networks or wifi hotspots, but I'm just curious as
to how their usage could be controlled in a managed enterprise.   Or would
one assume the DHC server allocting the privacy addresses is responsible
for tracking which hosts (via DUIDs?) are allocated which addresses over
time, and communicating that information to the management platforms?

-- 
Tim/::1

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Stig Venaas <[email-masked]>
Date: Wed, 3 Aug 2005 09:01:23 +0200

> complexity of privacy addresses (from the management perspective).

Right, I'm not sure if that necessary relates to source address selection
though. In such cases I think it better that the interfaces get no privacy
addresses at all.

[...]
> have some relationship to the site policy though?

In particular for privacy addresses I see a need for per-application
behaviour. One concern I have is how applications can distinguish
privacy addresses from others.

There are apps that need to e.g. find all addresses on an interface or
host, and then register some of those somewhere (or pass them as a
referral or otherwise to a peer/server). It probably would like to use
a stable address and not privacy address for this, but how does it
find which are which? Apps shouldn't need to try to guess from the
interface id...

In the above setting I also see issues with "normal" global vs ULA.
An application may need to distinguish them and somehow know which
to use. Distinguishing them is easy, knowing which of them to pass
may not be trivial.

Stig

---

From: Francis Dupont <[email-masked]>
Date: Wed, 03 Aug 2005 09:33:47 +0200

In your previous mail you wrote:

   
=> this point is supposed to be solved by RFC 3484 and related APIs but:
 - the private/public address switch (rule 7)  is not in the policy table
 - related APIs assume that every applications were changed in order to
   use them (so they are nearly useless).

Regards

[email-masked]

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 9 Aug 2005 17:57:15 +0900

Sorry for my late comment.
This is what I told Tim after dhc session, though.

>    use them (so they are nearly useless).

Of course, the privacy/public address switch isn't in the policy table,
you can control it by configuring policy table in not a beautiful way.

It's too simple. Just put a privacy address with 128-bit prefix-len
into the policy table.

Prefix                     Prec Label
2001:db8:1:1:a:b:c:d/128   1    1      <-- privacy address
2001:db8:1:1::/64          10   2
::/0                       10   2

In this case, the privacy address won't be used anymore to any dst by
default address selection.

Alternatively, you can specify public address with 128-bit prefix-len
and can prioritize public address over privacy one, or vice versa.

Prefix                     Prec Label
2001:db8:1:1:a:b:c:d/128   10   2      <-- public address
2001:db8:1:1::/64          1    1
::/0                       10   2

In this case, the privacy address will be used to connect to the hosts
on the same link, though.

As a privacy address is re-generated periodically, the policy table has
to be updated accordingly in the former case.

--
Arifumi Matsumoto <[email-masked]>
  Ubiquitous Computing Project
  NTT Information Sharing Platform Laboratories
  TEL: +81-422-59-3334 / FAX: +81-422-59-5652

---

From: Stig Venaas <[email-masked]>
Date: Tue, 9 Aug 2005 12:28:42 +0200

> to be updated accordingly in the former case.

This seems a bit ugly though (should be a way to refer to privacy address
so that you don't need to update the policy table yourself whenever you
get a new privacy address), and I think whether to use privacy source
address is mainly an application decision.

There is a proposed socket API for this which I think is more useful.
My main concern with applications and privacy addresses are applications
that get all addresses on an interface and then pass one or more of those
at the application layer to someone else (e.g. referrals). How does it
know which to pass. When an application gets a list of all addresses on
an interface, how does it determine which are privacy addresses and which
are not.

I also believe it would be useful to have a way the kernel can tell an
app that the addresses on an interface has changed. This would be useful
for privacy addresses and also for renumbering. E.g. something like the
netlink socket stuff which some systems use to tell applications of
routing changes.

Stig

---

From: Francis Dupont <[email-masked]>
Date: Tue, 09 Aug 2005 13:25:45 +0200

=> this is less than not a beautiful way...

=> first there are good implementations which don't match 001 prefixes
over 64 bits, second privacy addresses are highly temporary.

=> the policy table is not supposed to be so dynamic. IMHO we need a
proper solution for rules which can't be configured through the
policy table...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 09 Aug 2005 13:33:59 +0200

=> this API assumes that every applications are changed in order to use it.
IMHO something in the context of applications should be more useful
(in the context == in environment variables, for instance).

=> I believe that low end mechanisms can give this information (i.e.,
it can be in given flags when addresses are dumped).

=> PF_ROUTE has this. BTW I believe it is better to have a more abstract
view: managing addresses at this level is very (too?) painful...

Regards