And the corresponding distributing protocol format was already there in the previous version. :)
http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-00 We just dropped this bit in the latest -01 version. Best regards, On 2011/07/27, at 5:37, Arifumi Matsumoto wrote: > All, > > let me re-post the candidate extended policy table format below. > >> For example, if we extend the policy table to have Privacy column like below, >> >> Prefix Precedence Label Privacy >> ::1/128 60 0 OFF >> fc00::/7 50 1 OFF >> ::/0 40 2 ON >> ::ffff:0:0/96 30 3 OFF >> 2002::/16 20 4 OFF >> 2001::/32 10 5 OFF >> ::/96 1 10 OFF >> fec0::/10 1 11 OFF >> >> a temporary address will be used only when a destination address longest >> matches ::/0 entry in this table. > > This is rather simple form of privacy extension control. > Only the destination prefix determines whether the privacy extension for the > source prefix should be used or not. > In this case, even if a host has multiple prefixes, the source prefix does > not have effect on it. > > It seems to me that this satisfies the needs we discussed just now. > > > If we want to use both destination and source prefixes to control the usage > of privacy extension, > we need additional mechanisms like Label. > > > Or, any other implementation form ? > > > On 2011/06/29, at 14:28, Arifumi Matsumoto wrote: > >> Hi Suresh, >> >> On 2011/06/29, at 4:32, Suresh Krishnan wrote: >> >>> Hi Tim, >>> There is already a programmatic switch for this in RFC5014 >>> (IPV6_PREFER_SRC_TMP/IPV6_PREFER_SRC_PUBLIC). Applications wishing to >>> override system policy may do so by using this API. >> >> Yes. An application can control which kind of address to choose by that API. >> >> Our question is whether we should have a way to configure host-wide policy >> about when to use temporary address or not. >> >> For example, if we extend the policy table to have Privacy column like below, >> >> Prefix Precedence Label Privacy >> ::1/128 60 0 OFF >> fc00::/7 50 1 OFF >> ::/0 40 2 ON >> ::ffff:0:0/96 30 3 OFF >> 2002::/16 20 4 OFF >> 2001::/32 10 5 OFF >> ::/96 1 10 OFF >> fec0::/10 1 11 OFF >> >> a temporary address will be used only when a destination address longest >> matches ::/0 entry in this table. >> >> Please note that this is about address selection and not about whether a >> host should generate temporary address for a received RA prefix. >> >> As Tim mentioned, if we agree to have this kind of new tool, after that, we >> should discuss about policy distribution of this added column. >> >> Best regards, >> >>> >>> Cheers >>> Suresh >>> >>> ________________________________________ >>> From: [email protected] [[email protected]] On Behalf Of Tim Chown >>> [[email protected]] >>> Sent: Tuesday, June 28, 2011 10:38 AM >>> To: [email protected] >>> Subject: rfc3484-bis issue 2: privacy addresses >>> >>> The second issue is surrounding IPv6 privacy addresses (RFC4941). >>> >>> Section 3.1 of RFC4941 states: >>> "this document assumes that when a node initiates outgoing >>> >>> communication, temporary addresses can be given preference over >>> public addresses when the device is configured to do so. >>> [ADDR_SELECT<http://tools.ietf.org/html/rfc4941#ref-ADDR_SELECT>] mandates >>> implementations to provide a mechanism, which >>> allows an application to configure its preference for temporary >>> addresses over public addresses. It also allows for an >>> implementation to prefer temporary addresses by default, so that the >>> connections initiated by the node can use temporary addresses without >>> requiring application-specific enablement." >>> >>> >>> This suggests there should be a mechanism for a host to choose whether to >>> use temporary or public addresses. RFC3484 talks about preferring >>> temporary or public addresses in Rule 7. In practice, implementations seem >>> to prefer privacy addresses (to initiate connections) when they are >>> enabled. At the moment, RFC3484-bis says nothing different or new for >>> privacy addresses. >>> >>> >>> Should there be a configuration switch for privacy extensions somewhere, >>> and if so how is this controlled - locally or via a policy distribution >>> mechanism? >>> >>> >>> In IETF80, the suggestion to 'tell' a host whether it should use privacy >>> addresses by using an RA flag was not well received. There was at least one >>> comment at IETF80 that the privilege to carry the traffic and the privilege >>> to turn on/off the privacy extension should be different. >>> >>> >>> Comments please. >>> >>> >>> Tim >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> [email protected] >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> >> -- >> Arifumi Matsumoto >> NGN System Architecture Project >> NTT Service Integration Laboratories >> E-mail: [email protected] >> TEL +81-422-59-3334 FAX +81-422-59-6364 >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
