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: ipv6-boun...@ietf.org [ipv6-boun...@ietf.org] On Behalf Of Tim Chown >> [t...@ecs.soton.ac.uk] >> Sent: Tuesday, June 28, 2011 10:38 AM >> To: ipv6@ietf.org >> 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 >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > -- > Arifumi Matsumoto > NGN System Architecture Project > NTT Service Integration Laboratories > E-mail: arif...@nttv6.net > TEL +81-422-59-3334 FAX +81-422-59-6364 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
