Subject: 6MAN WG Last Call: <draft-ietf-6man-addr-select-opt-06.txt>

From: Ole Trøan <[email-masked]>
Date: Wed, 10 Oct 2012 10:28:02 +0200

All,

This message starts a two week 6MAN Working Group on advancing:

	Title           : Distributing Address Selection Policy using DHCPv6
	Author(s)    : A. Matsumoto, T. Fujisaki, T. Chown
	Filename    : draft-ietf-6man-addr-select-opt-06.txt
	Pages        : 10
	Date           : 2012-09-21

      http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-06

as Proposed Standard.  Substantive comments and statements of support for advancing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on 24. October 2012.

Regards,

Ole Trøan & Bob Hinden

---

From: Ray Hunter <[email-masked]>
Date: Wed, 10 Oct 2012 12:00:33 +0200

I support this work.

Discussion
==========

Section 4.2
s/the default policy should be restored/the previously active policy 
should be restored/ ?

Nits & clarification
=============

Section 2
s/A address selection option contains/An Address Selection option contains/

s/Multiple policy table options in a Policy Table option constitute a 
single policy table./
Multiple Policy Table options in an Address Selection option constitute 
a single policy table./

s/zero padded/left aligned, big-endian, and zero padded on the right/

Section 3
s/in any messages other/in any DHCPv6 messages other/

Section 4.1
s/his requirement/their own requirements/

s/a) It receives distributed policy table, and replaces the existing
       policy tables with that.
    b) It preserves the default policy table, or manually configured
       policy./
a) replace the existing active policy table with the DHCPv6 distributed 
policy table .
b) preserve the existing active policy table, whether this be the 
default policy table, or user configured policy./

Section 4.3
s/node-global information by its nature/node-global information by their 
nature/

s/One of the reason is/One reason being/

s/multiple address selection policy/multiple address selection policies,/

s/the effect of both policy/the effect of both policies/

s/that absence of the distributed policy/that absence of a distributed 
policy/
a/mean preference/mean a preference/

s/deal with multiple received policy/deal with multiple received policies/

s/DHCPv6 clients need to convert this label to a representation 
specified by each implementation/DHCPv6 clients SHOULD convert this 
label to a representation appropriate for the local implementation/

s/So, the number of the options and the total size of the options should 
be taken care of. Since the number of selection rules could be large, an 
administrator configuring the policy to be distributed should consider 
the resulting DHCPv6 message size/
Network administrators SHOULD consider local limitations to the maximum 
DHCPv6 message size that can be reliably transported via their specific 
local infrastructure to end nodes; and therefore they SHOULD consider 
the number of options, the total size of the options, and the resulting 
DHCPv6 message size, when defining their Policy Table./

Section 6:

s/and the affected packets might be blocked at an outgoing ISP because 
of ingress filtering/and the affected packets might be blocked at an 
outgoing ISP because of ingress filtering, incur additional network 
charges, or be misdirected to an attacker's machine/

s/should be communicated through a secure/should communicate through a 
secure/

s/This issue will not be degraded regardless of the introduction of this 
option, or regardless/This issue will not be modified by the 
introduction of this option, regardless/

regards,
RayH

Ole Trøan wrote:
> Ole Trøan&  Bob Hinden

---

From: Rui Paulo <[email-masked]>
Date: Wed, 10 Oct 2012 12:21:23 -0700

>      http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-06

Support, but agree with Ray Hunter's discussion request / clarifications.

--
Rui Paulo

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 16 Oct 2012 17:53:59 +0900

Ray,
thank you for review and comments.

Responses below.

2012/10/10 Ray Hunter <[email-masked]>:
> I support this work.
>
> Discussion
> ==========
>
> Section 4.2
> s/the default policy should be restored/the previously active policy should
> be restored/ ?

It is assumed that the configuration will be either using distributed policy or
using manually configured policy as described in 4.1.
So, 4.2 is written like this.

Do you propose to change the above assumption ?

I really appreciate your reviewing and suggestions below.

2012/10/10 Ray Hunter <[email-masked]>:
> I support this work.
>
> Discussion
> ==========
>
> Section 4.2
> s/the default policy should be restored/the previously active policy should
> be restored/ ?
>
> Nits & clarification
> =============
>
> Section 2
> s/Multiple policy table options in a Policy Table option constitute a single
> policy table./
> Multiple Policy Table options in an Address Selection option constitute a
> single policy table./
>
> b) preserve the existing active policy table, whether this be the default
> policy table, or user configured policy./
>
>
> Section 4.3
> s/DHCPv6 clients need to convert this label to a representation specified by
> each implementation/DHCPv6 clients SHOULD convert this label to a
> representation appropriate for the local implementation/
>
> s/So, the number of the options and the total size of the options should be
> taken care of. Since the number of selection rules could be large, an
> administrator configuring the policy to be distributed should consider the
> resulting DHCPv6 message size/
> local infrastructure to end nodes; and therefore they SHOULD consider the
> number of options, the total size of the options, and the resulting DHCPv6
> message size, when defining their Policy Table./
>
> Section 6:
>
> s/and the affected packets might be blocked at an outgoing ISP because of
> ingress filtering/and the affected packets might be blocked at an outgoing
> ISP because of ingress filtering, incur additional network charges, or be
> misdirected to an attacker's machine/
>
> option, or regardless/This issue will not be modified by the introduction of
> this option, regardless/
>
> regards,
> RayH
>
> Ole Trøan wrote:
>>
>> All,
>>
>> as Proposed Standard.  Substantive comments and statements of support for
>> advancing this document should be directed to the mailing list.  Editorial
>> suggestions can be sent to the authors.  This last call will end on 24.
>> October 2012.
>>
>> Regards,
>>
>> Ole Trøan&  Bob Hinden
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Oct 2012 11:29:26 +0100

Hi,

I support this draft but have a couple of comments.

>    A:   Automatic Row Addition flag.  This flag toggles the Automatic
>         Row Addition flag at client hosts, which is described in the
>         section 2.1 in RFC 6724 [RFC6724].  If this flag is set to 1, it
>         does not change client host behavior, that is, a client MAY
>         automatically add additional site-specific rows to the policy
>         table.  If set to 0, the Automatic Row Addition flag is
>         disabled, and a client MAY NOT automatically add rows to the
>         policy table.

This text includes "MAY NOT" (in upper case). This is specifically not
covered by RFC 2119 because it's unclear. I think we want "MUST NOT"
instead. Or do we want "SHOULD NOT"? The existence of this flag is
a "SHOULD" in RFC 6724.

>    P:   Privacy Preference flag.  This flag toggles the Privacy
>         Preference flag at client hosts, which is described in the
>         section 5 in RFC 6724 [RFC6724].  If this flag is set to 1, it
>         does not change client host behavior, that is, a client SHOULD
>         prefer temporary addresses.  If set to 0, the Privacy Preference
>         flag is disabled, and a client SHOULD prefer public addresses.

I am a little bothered by those two SHOULDs. It seems to me that they subtly
modify what is said in RFC 6724, where the relevant text is quite subtle
already. I would prefer to see the two SHOULD clauses deleted. Alternatively,
s/SHOULD/will/ would better align the text with RFC 6724.

Nit: [I-D.ietf-6man-stable-privacy-addresses] is defined but not used.

Regards
   Brian Carpenter

---

From: t.petch <[email-masked]>
Date: Fri, 19 Oct 2012 15:17:00 +0100

s.7 IANA considerations request the allocation of a code for
OPTION_ADDRSEL_ZONE
Is this the now removed
OPTION_ZONE_INDEX ?
If not, what?

s.2 "POLICY TABLE OPITONS"

Tom Petch

----- Original Message -----
From: "Ole Trøan" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 10, 2012 9:28 AM

All,

as Proposed Standard.  Substantive comments and statements of support
for advancing this document should be directed to the mailing list.
Editorial suggestions can be sent to the authors.  This last call will
end on 24. October 2012.

Regards,

Ole Trøan & Bob Hinden

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 22 Oct 2012 17:25:12 +0900

This should be removed.
Thanks.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 22 Oct 2012 18:00:23 +0900

Hi,

I received the following e-mail directly.
Let me add Cc to the list.

2012/10/17 Ray Hunter <[email-masked]>:
> inline.
>>
>> Arifumi Matsumoto <mailto:[email-masked]>
>> 16 October 2012 10:53
>>
>> Ray,
>> 2012/10/10 Ray Hunter<[email-masked]>:
>>>
>>> I support this work.
>>>
>>> Discussion
>>> ==========
>>>
>>> Section 4.2
>>> should
> It is more of a question than a proposal.
>
> Some implementations (e.g. Windows) make a distinction between a
> manually-configured change to the policy table that will survive a reboot,
> and other changes that are only valid for this user session, using the
> concept of a "store". See "netsh interface ipv6 show prefixpolicy
> [[store=]{active | persistent}]"
>
> If there's been a manually-configured persistent policy set, if an [active]
> DHCPv6-derived policy table goes stale, it might be more appropriate to
> (re)activate the manually-configured persistent policy that is specific to
> this node, rather than the "default" policy table defined in section 2.1 of
> RFC6724.
>
> It's really a question of if we need to further clarify what is meant by
> "default policy" in Section 4.2 of draft-ietf-6man-addr-select-opt-06.
>
> Is it the manually configured node-specific default, or the RFC6724 section
> 2.1 default policy table, or is this behaviour simply implementation
> dependent and we should remain silent on an appropriate default?

IMHO, it should be complex to allow to receive distributed policy even
when the policy is manually configured. However, I agree that it should be
out-of-scope of this document. This document should just state the
requirements as in 4.1.

> Further clarification on section 2 /A address selection option contains zero
> or more policy table options/:
>
> I think it would also be useful if we added one sentence after this: /An
> Address Selection option containing zero Policy Table options SHOULD be
> interpreted as the RFC6724 Section 2.1 default policy table./
>
> This will allow administrators to easily and positively provide local nodes
> with a hint that they should use the default table of RFC6724, without
> having to redefine and transport this every time, or rely on time outs.

The reason for allowing zero policy table options is to deliver only the A
and P flags of the Address Selection option.

If we want to do this, we should add another flag for it.

However, IMHO, we should not add such a thing, to keep things simple.

Thank you.

> You're welcome.
>>> Nits&  clarification
>>> single
>>> be
>>> Ole Trřan wrote:
>>>> for
>>>> Ole Trřan&   Bob Hinden
>> Ray Hunter <mailto:[email-masked]>
>> 10 October 2012 12:00
>>
>> I support this work.
>>
>> Discussion
>> ==========
>>
>> Section 4.2
>> s/DHCPv6 clients need to convert this label to a representation specified
>> by each implementation/DHCPv6 clients SHOULD convert this label to a
>> ------------------------------------------------------------------------
>
>

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 22 Oct 2012 18:08:12 +0900

Brian,

> instead. Or do we want "SHOULD NOT"? The existence of this flag is

Oops. Thank you for pointing this out.

I think "SHOULD NOT" is better.
As we do not prohibit manual policy table configuration, so "MUST NOT"
should not work.

> s/SHOULD/will/ would better align the text with RFC 6724.

It sounds good to me.

> Nit: [I-D.ietf-6man-stable-privacy-addresses] is defined but not used.

I'll delete in the revision.

Thanks.

---

From: Tim Chown <[email-masked]>
Date: Mon, 22 Oct 2012 10:18:49 +0100

> As we do not prohibit manual policy table configuration, so "MUST NOT"

Yes, that sounds better.

>> s/SHOULD/will/ would better align the text with RFC 6724.

We're drifting into similar territory as the M and O flags here. There was pushback before against introducing an RA option to indicate whether privacy addresses should be used.  So again here I think the flag should be no more than a hint. 

It might be good to say 'prefer privacy addresses *where enabled*'.  I think if they're not enabled, e.g. on some server that shares a link with clients, then the server should not take this hint to enable privacy addresses.

The main use case here seemed to be that raised by Eric, i.e. to avoid the use of privacy addresses for ULAs within the same site.

> I'll delete in the revision.

I think the stable privacy address draft is good and hope it will progress, but I agree it's not needed here.  I guess the question is whether such addresses count as public or temporary. The idea of these addresses is to replace the SLAAC-based public address, so if we did add a note it would just be to clarify that.

Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 22 Oct 2012 10:22:00 +0100

> out-of-scope of this document. This document should just state the

The idea in the original discussions was that 'default policy' meant the default described in the RFC, rather than something local to the site.  After all, the reason a site may be using this DHCPv6 option is to change that default.

Tim

---

From: Ray Hunter <[email-masked]>
Date: Mon, 22 Oct 2012 15:38:16 +0200

> The idea in the original discussions was that 'default policy' meant the default described in the RFC, rather than something local to the site.  After all, the reason a site may be using this DHCPv…
Not necessarily. In the days of highly mobile nodes, the concept of site
is going to become vague.

Any manual configured policy on a node is likely to be node specific,
and not site specific. It might even be that the manual config detects
network settings before becoming active. e.g. based on local interface
address ranges. There's plenty examples of this today in e.g. Windows.

The network operator may want to positively hint to the end node that it
should be running the RFC6724 defined default policy on this network
(and not some manually configured policy used by this node when
connected to other networks.) I agree that it is possible to implement
this behavior by the network operator configuring an explicit DHCPv6
policy table that matches the RFC6724 default table, and the user
accepting this policy as defined in 4.1.

I believe in symmetry, so handling stale DHCPv6 information should
really be the reverse process of 4.1 

For example, when the DHCPv6 policy expires (due to a timeout, or the
end node disconnecting from the network), you could get a situation
where the user has accepted a DHCPv6 distributed policy from network X,
but they may revert to a connection to another network Y that does not
support DHCPv6 distributed policy, but does require a manually
configured policy. Then it would make sense to install the manually
configured policy. Equally, they may also still be connected to network
X and it's just the DHCPv6 that has timed out. In which case keeping the
DHCPv6 policy active might be the correct thing to do. Or they might be
connected to a completely new network, in which case the RFC6724 default
is appropriate.

I therefore think it probably should then be left to the end node
whether the end node should reactivate the manually configured (node
default) policy, or the RFC6724 defined default policy, or keep the
DHCPv6 learned policy active even though it has timed out.

Suggested text for Section 4.2

s/When the information from the DHCP server goes stale, the policy
received form the DHCP server should be removed and the default policy
should be restored./When the information from the DHCP server goes
stale, the policy received from the DHCP server should be deprecated./

Optionally add to 4.2. /Which policy should then become active is a
matter for the local implementation./ 

regards,
RayH

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 24 Oct 2012 15:03:25 +0900

Ray,

> stale, the policy received from the DHCP server should be deprecated./

I think the text above looks reasonable.

> matter for the local implementation./

I think we do not need this one.

Thanks.