Tim Chown wrote: > On 22 Oct 2012, at 10:00, Arifumi Matsumoto <[email protected]> wrote: > >> 2012/10/17 Ray Hunter <[email protected]>: >>> 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. > > 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 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
