Subject: RE: 3484bis and privacy addresses

From: Dave Thaler <[email-masked]>
Date: Mon, 2 Apr 2012 23:43:57 +0000

I prefer B, and this is what most existing implementations of RFC 3484 seem to already do (i.e., they follow the MAY not the SHOULD) whenever privacy addresses are enabled.  I have yet to hear of an implementation of RFC 3484 that actually follows the SHOULD (A) rather than the MAY (B), but maybe someone on this list knows of one.

To respond to Ray's "From the corporate World: option A as default, with local user controlled option to override":

In the corporate world, one requirement we've heard is to disable privacy addresses all together,
not just depreference them.   This is consistent with Brian Carpenter's response.

As such, the Windows implementation of RFC 3484 has always preferred privacy addresses when enabled, and lets the administrator enable/disable them.   Client OS's (Vista, Windows 7, etc.) have them enabled by default, but can be disabled by an enterprise administrator either manually or across the enterprise via Group Policy.   Server OS's (Server 2003, Server 2008, etc.) have them disabled by default, but can be enabled by an administrator.

-Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ray Hunter
Sent: Tuesday, March 27, 2012 10:00 AM
To: Brian Haberman
Cc: [email-masked]
Subject: Re: 3484bis and privacy addresses

>From the corporate World: option A as default, with local user controlled option to override.

RFC3484 (which references RFC3041) "Temporary addresses" are a menace to fault finding, audit, logging, firewall rules, filtering, QoS matching, conformance: anywhere where an ACL or stable address is used today. Sure we shouldn't use fixed/stable IP literals, but we do. And in many cases there aren't any practical alternatives in today's products, so the IP address is the lowest common denominator used to identify a machine (and dare I say even "a user" in some circumstances).

Also not sure if any DHCPv6 server implementations actually provide DHCPv6 assigned temporary addresses in practice.

My take on this is that a set of a few hundred individual persons who are worried about privacy are more likely to be able to control their own particular machines to correctly override the "default off" setting than a single corporate network manager is to be able to guarantee overriding a "default on" setting on 100% of 10000 machines attached to their network.

regards,
RayH

Brian Haberman wrote:
<div class="moz-text-flowed">All,
     The chairs would like to get a sense of the working group on changing the current (defined 3484) model of preferring public addresses over privacy addresses during the address selection process.  RFC 3484 prefers public addresses with the ability (MAY) of an implementation to reverse the preference.  The suggestion has been made to reverse that preference in 3484bis (prefer privacy addresses over public ones). Regardless, the document will allow implementers/users to reverse the default preference.

     Please state your preference for one of the following default options :

A. Prefer public addresses over privacy addresses

B. Prefer privacy addresses over public addresses

Regards,
Brian, Bob, & Ole

</div>

--
Ray Hunter
[email-masked]<mailto:[email-masked]>
Globis Consulting BV, Fazantlaan 23, 5613CB Eindhoven NL,
Registered at the KvK, Eindhoven, under number BV 17098279
mobile: +31 620 363864

---

From: Ray Hunter <[email-masked]>
Date: Tue, 03 Apr 2012 08:52:52 +0200

I can also live with Brian Carpenter's response.

> In terms of a general default in shipped IPv6 stacks, I prefer
> B, but it has to be qualified:
>
> There MUST be a user option to change this preference.
>
> There SHOULD be a network manager option to change this preference.
>
> The rationale for this is that we need privacy by default in shipped
> products, with the ability for the person deploying the product to
> override this.
>
>      Brian C
>    

Windows may have got it pretty much right for allowing network operators 
to control privacy addresses, and turning them off by default at least 
on servers. But with all due respect, the control mechanism mentioned by 
Dave only covers machines that are members of a (proprietary) Active 
Directory domain: It does not cover guest LANs, outsourced services, 
other operating systems, nor Bring Your Own Device, which are all 
increasing trends in the corporate World.

Network managers need that switch.

Can anyone show me where that's defined in an RFC?

regards,
RayH

Dave Thaler wrote:
>
> I prefer B, and this is what most existing implementations of RFC 3484 
> seem to already do (i.e., they follow the MAY not the SHOULD) whenever 
> privacy addresses are enabled.  I have yet to hear of an 
> implementation of RFC 3484 that actually follows the SHOULD (A) rather 
> than the MAY (B), but maybe someone on this list knows of one.
>
> To respond to Ray's "From the corporate World: option A as default, 
> with local user controlled option to override":
>
> As such, the Windows implementation of RFC 3484 has always preferred 
> privacy addresses when enabled, and lets the administrator 
> enable/disable them.   Client OS's (Vista, Windows 7, etc.) have them 
> enabled by default, but can be disabled by an enterprise administrator 
> either manually or across the enterprise via Group Policy.   Server 
> OS's (Server 2003, Server 2008, etc.) have them disabled by default, 
> but can be enabled by an administrator.
>
> -Dave
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Ray Hunter
> *Sent:* Tuesday, March 27, 2012 10:00 AM
> *To:* Brian Haberman
> *Cc:* [email-masked]
> *Subject:* Re: 3484bis and privacy addresses
>
> RFC3484 (which references RFC3041) "Temporary addresses" are a menace 
> to fault finding, audit, logging, firewall rules, filtering, QoS 
> matching, conformance: anywhere where an ACL or stable address is used 
> today. Sure we shouldn't use fixed/stable IP literals, but we do. And 
> in many cases there aren't any practical alternatives in today's 
> products, so the IP address is the lowest common denominator used to 
> identify a machine (and dare I say even "a user" in some circumstances).
>
> Also not sure if any DHCPv6 server implementations actually provide 
> DHCPv6 assigned temporary addresses in practice.
>
> My take on this is that a set of a few hundred individual persons who 
> are worried about privacy are more likely to be able to control their 
> own particular machines to correctly override the "default off" 
> setting than a single corporate network manager is to be able to 
> guarantee overriding a "default on" setting on 100% of 10000 machines 
> attached to their network.
>
> regards,
> RayH
>
> Brian Haberman wrote:
>
>      The chairs would like to get a sense of the working group on 
> changing the current (defined 3484) model of preferring public 
> addresses over privacy addresses during the address selection 
> process.  RFC 3484 prefers public addresses with the ability (MAY) of 
> an implementation to reverse the preference.  The suggestion has been 
> made to reverse that preference in 3484bis (prefer privacy addresses 
> over public ones). Regardless, the document will allow 
> implementers/users to reverse the default preference.
>
> [email-masked] <mailto:[email-masked]>

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 03 Apr 2012 10:44:35 -0700

At Mon, 2 Apr 2012 23:43:57 +0000,

> I prefer B, and this is what most existing implementations of RFC 3484 seem to already do (i.e., they follow the MAY not the SHOULD) whenever privacy addresses are enabled.  I have yet to hear of a…

When we first implemented RFC3484 for BSD variants at the KAME project
we followed the SHOULD and preferred public (non temporary) addresses
by default.  From a quick look it doesn't change, e.g., in the most
recent version of FreeBSD:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/in6_src.c?rev=1.87;content-type=text%2Fx-cvsweb-markup
		 /*
		 * Rule 7: Prefer public addresses.
		 * We allow users to reverse the logic by configuring
		 * a sysctl variable, so that privacy conscious users can
		 * always prefer temporary addresses.
		 */

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: james woodyatt <[email-masked]>
Date: Tue, 03 Apr 2012 15:50:28 -0700

On Apr 3, 2012, at 10:44 , JINMEI Tatuya / 神明達哉 <[email-masked]> wrote:
> At Mon, 2 Apr 2012 23:43:57 +0000, Dave Thaler <[email-masked]> wrote:
>> 

It may be worth noting here what I see on my Mac OS X 10.7 system at home (which exhibits basically the same behavior as recent iOS releases do):

    zeece ~ 508$ sysctl net.inet6.ip6 | egrep tempaddr
    net.inet6.ip6.use_tempaddr: 1
    net.inet6.ip6.prefer_tempaddr: 1

In other words, it deliberately diverges from the "SHOULD" recommendation here in RFC 3484, despite having been derived from the KAME stack which had zeroes as the default values here, not ones.  I have yet to see a persuasive reason to conform strictly to the recommended behavior.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 5 Apr 2012 12:29:12 +0530

Firewall policies are moving towards identity (user, user-group) +
context (location, Bring your Own Device (BYOD)) attributes to enforce
appropriate policies. In enterprises hosts with EAP kind of supplicants
can be tracked even when the IP changes but for guests, BYOD without
such supplicants IP address based authentication is still required and
for such users, switches acting as DHCP relay agent can influence the
DHCP server not to assign temporary addresses
(http://tools.ietf.org/html/draft-reddy-mif-dhcpv6-precedence-ops-00)

Regards

Tiru.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ray Hunter
Sent: Tuesday, March 27, 2012 10:30 PM
To: Brian Haberman
Cc: [email-masked]
Subject: Re: 3484bis and privacy addresses

>From the corporate World: option A as default, with local user
controlled option to override.

RFC3484 (which references RFC3041) "Temporary addresses" are a menace to
fault finding, audit, logging, firewall rules, filtering, QoS matching,
conformance: anywhere where an ACL or stable address is used today. Sure
we shouldn't use fixed/stable IP literals, but we do. And in many cases
there aren't any practical alternatives in today's products, so the IP
address is the lowest common denominator used to identify a machine (and
dare I say even "a user" in some circumstances).

My take on this is that a set of a few hundred individual persons who
are worried about privacy are more likely to be able to control their
own particular machines to correctly override the "default off" setting
than a single corporate network manager is to be able to guarantee
overriding a "default on" setting on 100% of 10000 machines attached to
their network.

regards,
RayH

Brian Haberman wrote: 

<div class="moz-text-flowed">All, 
     The chairs would like to get a sense of the working group on
changing the current (defined 3484) model of preferring public addresses
over privacy addresses during the address selection process.  RFC 3484
prefers public addresses with the ability (MAY) of an implementation to
reverse the preference.  The suggestion has been made to reverse that
preference in 3484bis (prefer privacy addresses over public ones).
Regardless, the document will allow implementers/users to reverse the
default preference. 

     Please state your preference for one of the following default
options : 

Regards, 
Brian, Bob, & Ole 

</div> 

-- 
Ray Hunter
[email-masked]

---

From: Ray Hunter <[email-masked]>
Date: Fri, 06 Apr 2012 11:30:05 +0200

Interesting draft. Thanks.

The elephant in the room is that DHCPv6 clients are still not deployed 
on all end nodes that would benefit from it.

Many other 6man drafts, such as draft-ietf-6man-addr-select-opt-03 also 
rely on DHCPv6.

Let's hope that the market now manages toquickly resolve what the IETF 
has not managed to resolve in over 10 years of discussion, and selects a 
universally available communication channel for passing configuration 
hints between the network and end nodes that move between networks.

Otherwise changing default behavior (like being discussed in the update 
from 3484 to 3484bis), or implementing new features in 6man, will likely 
make migration to IPv6 duringdual stack operation harder, or break 
existing stuff, or both.

regards,
RayH

> Tirumaleswar Reddy (tireddy) <mailto:[email-masked]>
> 5 April 2012 08:59
>
> appropriate policies. In enterprises hosts with EAP kind of 
> supplicants can be tracked even when the IP changes but for guests, 
> BYOD without such supplicants IP address based authentication is still 
> required and for such users, switches acting as DHCP relay agent can 
> influence the DHCP server not to assign temporary addresses 
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Ray Hunter
> *Sent:* Tuesday, March 27, 2012 10:30 PM
> *To:* Brian Haberman
> *Cc:* [email-masked]
> Ray Hunter <mailto:[email-masked]>
> 27 March 2012 19:00

---

From: Dave Thaler <[email-masked]>
Date: Tue, 10 Apr 2012 00:08:45 +0000

Brian Carpenter writes:
> On 2012-03-27 20:33, Brian Haberman wrote:
> ...
> > 
> In terms of a general default in shipped IPv6 stacks, I prefer B, but it has to be qualified:
>

That wording would be confusing, as there's a distinction between an
(unprivileged) user and a (privileged) admin.   It would be a security
vulnerability if an unprivileged user could change a system-wide setting.

> There SHOULD be a network manager option to change this preference.

Similarly, the term "network manager" is also confusing.  It would be a security vulnerability
if an untrusted user on the network could change a system-wide setting locally.

> The rationale for this is that we need privacy by default in shipped products, with the
> ability for the person deploying the product to override this.

I (and I gather from the +1's that many others) agree with having a config knob to
reverse the preference.   The doc already has text about that on a *per-app* basis,
but not system-wide.   The wording I propose to add is:

    "There SHOULD be an administrative option to change this preference, if the 
    implementation supports privacy addresses.  If there is no such option, there 
    MUST be an administrative option to disable privacy addresses."

-Dave

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Apr 2012 07:53:04 +0100

below...

>     MUST be an administrative option to disable privacy addresses."

That works for me. Perhaps there also needs to be a general statement in the
security considerations that all administrative changes and options MUST be
secured against illicit use.

   Brian

---

From: Dave Thaler <[email-masked]>
Date: Tue, 10 Apr 2012 22:32:46 +0000

Brian Carpenter writes:
> > The wording I propose to add is:
> > 
> That works for me. Perhaps there also needs to be a general statement in the security
> considerations that all administrative changes and options MUST be secured against illicit use.

Done.   Draft -02 now includes the wording above, and adds a general statement in the
security considerations section as you suggested.

-Dave

---

From: Ray Hunter <[email-masked]>
Date: Wed, 11 Apr 2012 15:50:42 +0200

With all due respect to everyone concerned, there's no way an end user 
or IT department can buy a bunch of machines based on the text currently 
contained in this proposed Standard Track document and

1) be able to predict how each machine will behave by defaultin advance 
of actually plugging it in.

2) be able to effectively manage a machine's behaviour remotely via an 
IETF defined control mechanism, because the various MAYs and SHOULDs 
cannot be overridden by the two things that are actually reasonably well 
defined by the IETF i.e.
the prefix policy table + draft-ietf-6man-addr-select-opt-03 for 
transporting that policy table.

That suggests to me that we're not yet completely on the right track.

IMHO If there's an implementation option in 3484bis, there should always 
be a corresponding control option in the (prefix) policy table, plus a 
way to effectively transport that policy table in e.g. 
draft-ietf-6man-addr-select-opt-03.

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

regards,
RayH

Dave Thaler wrote:
> Done.   Draft-02  now includes the wording above, and adds a general statement in the

---

From: Dave Thaler <[email-masked]>
Date: Wed, 11 Apr 2012 19:17:23 +0000

> -----Original Message-----
> From: Ray Hunter [mailto:[email-masked]]
> Sent: Wednesday, April 11, 2012 6:51 AM
> To: Dave Thaler
> Cc: Brian E Carpenter; [email-masked]
> Subject: Re: RE: 3484bis and privacy addresses
> 
> With all due respect to everyone concerned, there's no way an end user or IT
> department can buy a bunch of machines based on the text currently contained
> in this proposed Standard Track document and
> 
> 1) be able to predict how each machine will behave by defaultin advance of
> actually plugging it in.
> 
> 2) be able to effectively manage a machine's behaviour remotely via an IETF
> defined control mechanism, because the various MAYs and SHOULDs cannot be
> overridden by the two things that are actually reasonably well defined by the
> IETF i.e.
> the prefix policy table + draft-ietf-6man-addr-select-opt-03 for transporting that
> policy table.

I don't follow.  Can you provide a specific example of something you are concerned
about?

> IMHO If there's an implementation option in 3484bis, there should always be a
> corresponding control option in the (prefix) policy table, plus a way to
> effectively transport that policy table in e.g.

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. 

-Dave

> >> >  That works for me. Perhaps there also needs to be a general
> >> > statement in the security  considerations that all administrative changes
> and options MUST be secured against illicit use.
> >

---

From: Ray Hunter <[email-masked]>
Date: Fri, 13 Apr 2012 09:25:30 +0200

inline IMVHO [long answer]
> Dave Thaler <mailto:[email-masked]>
> 11 April 2012 21:17
Yes.

The new text:

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.
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.

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

That will almost certainly break stuff in production when new software 
versions are introduced.

Example: firewall access between a management server and a bunch of 
machines it manages in a data centre environment.
Example: DSCP bit setting based on ACL in MPLS environments.
Example: PCI credit card processing standards (Fixed IP address or 
static DHCP must be used for computers involved in credit card processing)
Example: helpdesk procedures for correlating long term problems via logs

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.

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.
Does the new version exhibit the same default behaviour as the previous 
version based on RFC3484? No idea.
Does the implementor have any idea what my or my employer's view is on 
privacy addresses (either default ON or default OFF)? Nope.
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.

Can the system manager change this setting remotely for machines that 
hop between networks e.g. a laptop that moves between work and home and 
various company networks? Undefined.

> 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?

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). 
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.

Meanwhile the implementor has zero idea of what policies an end user or 
system manager has to comply with, nor an end user's other production 
requirements (including compliance laws, firewalls, ACLs, help desk 
processes, or log processing).

Why should implementors have more freedom to decide on what is 
appropriate behaviour for address selection than the machine's system 
manager or end user?

On the flip side, why even bother with the prefix policy table if an end 
user or system manager still cannot make the machine behave according to 
their local operational requirements?

All I'm saying is that if you define a switch in a standard that an 
implementor can throw, give that same switch to the end user/system 
manager, and make sure the switch setting can also be transported over a 
commonly implemented non-proprietary management mechanism like DHCPv6. 
The end user can still decide whether he or she trusts the DHCPv6 server 
or the content of the DHCPv6 option as a local management preference.

> Ray Hunter <mailto:[email-masked]>
> 11 April 2012 15:50
> or IT department can buy a bunch of machines based on the text 
> currently contained in this proposed Standard Track document and
>
> 1) be able to predict how each machine will behave by defaultin 
> advance of actually plugging it in.
>
> cannot be overridden by the two things that are actually reasonably 
> well defined by the IETF i.e.
> IMHO If there's an implementation option in 3484bis, there should 
> always be a corresponding control option in the (prefix) policy table, 
> plus a way to effectively transport that policy table in e.g. 
> ------------------------------------------------------------------------

---

From: Dave Thaler <[email-masked]>
Date: Fri, 13 Apr 2012 21:57:23 +0000

Hi Ray,

I appreciate the detailed response.  Thanks.

> Windows server OS currently do NOT use temporary addresses to source

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.

> 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).

> 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.

> 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. 

> 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.

> 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.

> 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?

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.
> 

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.

> 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

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

---

From: Ray Hunter <[email-masked]>
Date: Sat, 14 Apr 2012 10:31:03 +0200

Thanks for the reply.

I understand the rush, but I don't think the current document is ready 
for production yet, and would expect a need for RFC3484ter, which should 
obviously be avoided if possible.

I have already seen at least two customers who have experienced fairly 
major incidents and service outages due to the behaviour of end nodes 
and servers changing between OS versions. I use Windows as an example as 
you know the code, but it could have been any OS to be fair. Moving from 
Windows XP + Windows Server 2003 to Windows 7 + Windows Server 2008 and 
leaving default values in place can trigger massive changes in traffic 
flows literally within minutes via use of 6to4 tunnels (e.g. when the 
server end is upgraded to the new OS), and which directly breaks MPLS 
DSCP Quality of Service settings, or firewall throughput. I've seen 
customer's mission-critical platinum applications suddenly get dumped in 
the default queue as the routers no longer set the DSCP bits on network 
ingress and so the downstream routers cannot act on the DSCP bits of the 
traffic in the tunnel, even if they can look inside the tunnel. And I've 
seen firewalls and other devices choke as they have a different 
switching path for IPv6 traffic, or worse still, it hits a 100% block 
rule. These incidents are very difficult to track, as the servers may be 
managed by completely different groups to the network, and it would not 
be obvious to most change and problem managers that the changes and 
problems were directly related.

So I understand very well the urgency of lowering the preference of 6to4.

I would submit that lowering the preference of 6to4 could actually be 
implemented much quicker in production by 
progressingdraft-ietf-6man-addr-select-opt-03 and allowing end users to 
configure their own machines, rather than waiting for implementors to 
ship new code based on 3484bis. As an end user, I therefore think 
draft-ietf-6man-addr-select-opt-03 is actually more urgent than RFC3484bis.

But 6to4 is just the first example of where implementers will 
incorrectly second guess an end user's requirements. There'll certainly 
be more similar examples, including operational problems caused by use 
of temporary addresses.

Forgive me if I read your reply wrongly, but you seem to point the blame 
for there being an incomplete solution for remote management squarely at 
draft-ietf-6man-addr-select-opt-03.

Yet I could equally point out that RFC3484/RFC3484bis defines the prefix 
policy table, and all draft-ietf-6man-addr-select-opt-03 does is 
transport the contents of the prefix policy table via DHCPv6.

So what would I like to see happen?
===========================

What about defining a conceptual "address selection policy table" in 
RFC3484bis in addition to the "prefix policy table"?

It would contain a complete list of the conceptual knobs and switches 
that influence the behaviour of RFC3484bis end nodes, conceptual 
variable names, conceptual variable type, what behaviour the variable 
sets (cross referenced to the section), default settings (where these 
are already agreed in the WG) etc.

Then draft-ietf-6man-addr-select-opt-03 would simply define how to 
transport those options over DHCPv6, rather than having to define the 
options themselves.

Equally, if an implementor wanted to set these options via a config 
file, or AD group policy, or any other management process, they'd have a 
check list of things to do as well.

And if there are ever future extensions to RFC3484bis (e.g. a new rule 
to introduce dollar cost of network links or QoS factors into the 
address selection process), any new switches or new default behaviour 
could also be added to this conceptual "address selection policy table". 
If we'd already done this in RFC3484 it would have probably avoided a 
lot of pain with divergent implementations.

To be clear: I don't necessarily see the need to define new knobs or 
switches right now: just to clarify what existing knobs or switches will 
conceptually be called, what their conceptual types are (e.g. boolean), 
how/when they're set, what behaviour they influence, and their default 
behaviour (if agreed), plus a hint of how to add new knobs and switches 
in the future. This conceptual approach has been used very successfully 
in ND (RFC4861) and other standards, and I think it would address my 
current concerns of there being too much hard coding in address selection.

regards,
RayH
> 13 April 2012 23:57
> 13 April 2012 09:25
> 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 exhibit the same default behaviour as the 
> previous version based on RFC3484? No idea.
> Does the implementor have any idea what my or my employer's 
> operational requirements are? e.g. ACLs? Nope.
> 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.
> hop between networks e.g. a laptop that moves between work and home 
> and various company networks? Undefined.
>
>>> always be a
>> rules (the ones
> 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.
>
> 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.
>
> Meanwhile the implementor has zero idea of what policies an end user 
> or system manager has to comply with, nor an end user's other 
> production requirements (including compliance laws, firewalls, ACLs, 
> help desk processes, or log processing).
>
> On the flip side, why even bother with the prefix policy table if an 
> end user or system manager still cannot make the machine behave 
> according to their local operational requirements?
>
> manager, and make sure the switch setting can also be transported over 
> a commonly implemented non-proprietary management mechanism like 
> DHCPv6. The end user can still decide whether he or she trusts the 
> DHCPv6 server or the content of the DHCPv6 option as a local 
> management preference.
>
>
>
>
>>>>>>> >        implementation supports privacy addresses.  If there is 
>>>>>>> no such
>>> option, there
>> With all due respect to everyone concerned, there's no way an end 
>> user or IT department can buy a bunch of machines based on the text 
>> 2) be able to effectively manage a machine's behaviour remotely via 
>> an IETF defined control mechanism, because the various MAYs and 
>> SHOULDs cannot be overridden by the two things that are actually 
>> reasonably well defined by the IETF i.e.
>> always be a corresponding control option in the (prefix) policy 
>> table, plus a way to effectively transport that policy table in e.g.

---

From: Dave Thaler <[email-masked]>
Date: Sat, 14 Apr 2012 18:12:18 +0000

> Forgive me if I read your reply wrongly, but you seem to point the blame for
> there being an incomplete solution for remote management squarely at

No, I'm saying the issues you're raising are issues with draft-ietf-6man-addr-select-opt
not rfc3484bis.

> It would contain a complete list of the conceptual knobs and switches that
> influence the behaviour of RFC3484bis end nodes, conceptual variable
> names, conceptual variable type, what behaviour the variable sets (cross
> referenced to the section), default settings (where these are already agreed in
> the WG) etc.

Currently it does have a complete list in text.   For system-wide switches
that control sorting, there's only one.

> transport those options over DHCPv6, rather than having to define the

Agree that draft-ietf-6man-addr-select-opt should define how to transport
over DHCPv6 system-wide administrative options controlling sorting.
Currently we only have 1 and draft-ietf-6man-addr-select-opt is missing it.

> Equally, if an implementor wanted to set these options via a config file, or AD
> group policy, or any other management process, they'd have a check list of
> things to do as well.
>
> And if there are ever future extensions to RFC3484bis (e.g. a new rule to
> introduce dollar cost of network links or QoS factors into the address
> selection process), any new switches or new default behaviour could also be
> added to this conceptual "address selection policy table".
> If we'd already done this in RFC3484 it would have probably avoided a lot of
> pain with divergent implementations.
> 
> To be clear: I don't necessarily see the need to define new knobs or switches
> right now: just to clarify what existing knobs or switches will conceptually be
> called, what their conceptual types are (e.g. boolean), how/when they're set,
> what behaviour they influence, and their default behaviour (if agreed), plus a
> hint of how to add new knobs and switches in the future. This conceptual
> approach has been used very successfully in ND (RFC4861) and other
> standards, and I think it would address my current concerns of there being
> too much hard coding in address selection.

I take your comment as asking for a summary table in rfc 3484bis of
system-wide config options.   That could be done as a purely editorial
change, although if there's only 1 thing in the table it's less interesting.
But if others in the WG think this would be helpful, then yes we can do that.

-Dave