RE: 3484bis and privacy addresses

[Dave Thaler <[e-mail]>]

Hi Ray,

I appreciate the detailed response.  Thanks.

> If SA is a temporary address and SB is a public address, then prefer
>     SA.  Similarly, if SB is a temporary address and SA is a public
>     address, then prefer SB.
> 
> Sessions originated from a server on today's implementations e.g.
> Windows server OS currently do NOT use temporary addresses to source
> sessions.

Windows Server absolutely prefers temporary addresses to source sessions,
whenever temporary addresses are enabled.   Generation of temporary addresses
(which isn't related to RFC 3484) is not enabled by default, but the RFC 3484 
implementation in Windows Server definitely prefers temporary addresses
over public addresses.

> RFC3484 does NOT prefer temporary addresses as default behaviour today.
> 
> The current text does not make a distinction between a server and a client
> node, and says a machine should always prefer temporary addresses.

Correct.   We don't have WG consensus on making such a distinction.
And Windows doesn't either (it only makes a distinction on whether
RFC 3041 is enabled or disabled, where it's enabled by default on client
OSs and disabled by default on server OS's).

> If an implementor follows the current text, this would change default
> behaviour of some current implementations e.g. Windows Server.

As the person responsible for that implementation, I can assure you
that's not the case.

> Implementations for which application compatibility
>     considerations outweigh these privacy concerns MAY reverse the sense
>     of this rule and by default prefer public addresses over temporary
>     addresses.
> 
> Ah: but now there is a MAY which effectively allows the implementor to do
> anything they like if the implementor doesn't think Rule 7 is appropriate.

You cannot do "anything you like".  You're limited to two behaviors:
(a) Prefer public, and (b) Prefer temporary.  Both are legal and an implementation
can do either one.  That was already the case with RFC 3484, nothing new
here except which one is the MAY vs the SHOULD.

> Now imagine that I (as an end user) buy a machine of brand X that complies
> 100% with the RFC3484bis Standards Track document (or update an existing
> operating system version that implemented RFC3484 but now implements
> RFC3484bis).
> 
> Does the new version use temporary addresses by default? No idea. That was
> left up to the individual implementor.

Already true with RFC 3484.   Left up to the individual implementer.

If you want to know, then you want to configure it to use (possibly non-default)
values. 

> Does the new version exhibit the same default behaviour as the previous
> version based on RFC3484? No idea.

Already true with RFC 3484.   If you upgrade an OS, it may or may not
choose a different set of RFC 3484-compliant options.

If you want to know, then you want to configure it to use (possibly non-default)
values.

> Does the implementor have any idea what my or my employer's view is on
> privacy addresses (either default ON or default OFF)? Nope.

Actually the implementor often does due to proprietary mechaniams
(like Group Policy or manual configuration or whatever else), but 
neither RFC 3484 nor 3484bis specifies configuration mechanisms,
that's the job of companion docs like the DHCP option doc.   The core
doc can't mandate a specific mechanism, but needs to work independent
of what specific mechanism is being used to configure policy.

> Does the implementor have any idea what my or my employer's operational
> requirements are? e.g. ACLs? Nope.
> Is there a very good chance of taking the incorrect setting as default (in either
> direction)? Yes.
> 
> Is there a switch to reverse behaviour: either to turn it on when it should be
> off or off when it should be on?
> Sure, but the end user or system manager has to dig around in Brand X's
> proprietary mechanism to figure out how to change it.
> In mobile environments, they may not even have direct management access.

Your points here are not about RFC 3484bis per se, they're about a configuration
mechanism being standardized.   That's being done in parallel.

[...]
> > No, the prefix policy table is for configuring a specific subset of
> > rules (the ones using labels and preference).  Configurability for
> > other rules isn't part of the "prefix policy table", but is still configurable.
> 
> Yes. That's exactly my problem. As you say, the prefix policy table can only
> control a specific subset of the end node's behaviour.
> 
> The current text effectively gives complete freedom for implementors to do
> what they like on Rule 7: either Default ON or default OFF.
> 
> So why have Rule 7 at all?

Same reason for the other rules.
a) there's only two options that are understood enough to reason about:
    basically prefer privacy, and prefer stability.   Having a rule shows the
    precedence order among such rules in terms of when the difference
   matters.   And we have consensus on that.
b) they're implemented and deployed already, so we want to minimize
   changes from RFC 3484.

> The current text also only provides a subset of that freedom to system
> managers and end users (the policy table does not effect rule 7).

The current text provides freedom to reverse the sense of the rule.
The policy table isn't needed for that, the two are both configurable.

> Especially for influencing the setting by remote configuration e.g. from a
> trusted DHCPv6 server. The prefix policy table could be updated by
> DHCPv6 via draft-ietf-6man-addr-select-opt-03, but the behaviour of rule
> 7 can't be.

Again your comments seem to be about failings with the current
draft-ietf-6man-addr-select-opt document, not about RFC 3484bis.
I would agree with you here that draft-ietf-6man-addr-select-opt is
not ready for WGLC until it addresses more than just the prefix policy table.
But that need not hold up RFC 3484bis itself, which just defines the knobs
and leaves it for other docs to define a protocol to set the knobs via
DHCPv6, SNMP, netconf, CLI, and/or whatever else.

> >> Align and package all 3 together, and you have a far better solution.

I disagree that we need to hold publication of RFC3484bis for any other
protocol documents.   We need normative references in the reverse 
direction, not from RFC3484bis to any protocol document.

The WG wants to get RFC3484bis out asap because it actually
fixes problems that were in RFC 3484.

-Dave