On Apr 3, 2012, at 10:44 , JINMEI Tatuya / 神明達哉 <jin...@isc.org> wrote:
> At Mon, 2 Apr 2012 23:43:57 +0000, Dave Thaler <dtha...@microsoft.com> 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.
> 
> 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.
>                */


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 <j...@apple.com>
member of technical staff, core os networking



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to