For reasons similar to those mentioned here by Dmitry Butskoy, I needed to make winbind exclude trusted domains. But like he said, "allow trusted domains = no" doesn't seem to affect winbind in this context.
So I built winbindd from source, commenting out the call to rescan_trusted_domains() as Dmitry mentioned here, and it works exactly how I want now!
Looking at the latest version of Samba, 3.5.6, it appears to still not apply that setting in this context. I think rescan_trusted_domains() ought to check lp_allow_trusted_domains() and return if it is false.
If anyone on the Samba team is reading this, I hope you will consider making that change. Hmm, maybe I should submit a patch...
Tuesday, January 4, 2011
Monday, January 3, 2011
Windows 7 source address selection and unique local addresses
I set up IPv6 on my Linux router, and everything works great, except my Windows 7 box cannot connect to ipv6.google.com, because it uses my unique-local address (ULA) instead of my 6to4 address as the source. Since ULAs are not globally routable, why would Windows even consider using it when connecting to a public address?
The same problem is described here, and the workaround of modifying the prefix policy table does fix it for me, but I too feel it is a hacked/broken solution. (It is however, definitely the correct fix for making Windows prefer IPv6 over IPv4 when connecting to dual stack hosts.)
A "better" workaround I think would be to add a prefix policy of fc00::/7 with its own label and a lower priority. I think that would make it prefer my 6to4 address. Unfortunately, when I run
So although I believe Windows is using the correct policy table as per RFC 3484, I think it is a bug for Windows to use a ULA as the source when connecting to a public address, and I think it is a bug that it will not let me add a prefix policy for fc00::/7.
Thoughts?
Update (2018-Nov):
Interestingly, in Sep 2012 (about 2 years after this blog post), RFC 6724 came out (replaces RFC 3484), and it does include a policy for fc00::/7 with its own label. Since current versions of Windows use the policy table defined in RFC 6724, this bug no longer exists.
Wow, I must be prophetic! :)
The same problem is described here, and the workaround of modifying the prefix policy table does fix it for me, but I too feel it is a hacked/broken solution. (It is however, definitely the correct fix for making Windows prefer IPv6 over IPv4 when connecting to dual stack hosts.)
A "better" workaround I think would be to add a prefix policy of fc00::/7 with its own label and a lower priority. I think that would make it prefer my 6to4 address. Unfortunately, when I run
netsh interface ipv6 add prefixpolicy fc00::/7 4 6it doesn't add it right :( It shows up as just ::/7, which is the same problem as described here.
So although I believe Windows is using the correct policy table as per RFC 3484, I think it is a bug for Windows to use a ULA as the source when connecting to a public address, and I think it is a bug that it will not let me add a prefix policy for fc00::/7.
Thoughts?
Update (2018-Nov):
Interestingly, in Sep 2012 (about 2 years after this blog post), RFC 6724 came out (replaces RFC 3484), and it does include a policy for fc00::/7 with its own label. Since current versions of Windows use the policy table defined in RFC 6724, this bug no longer exists.
Wow, I must be prophetic! :)
Subscribe to:
Posts (Atom)
