I said: > But if the client has the old RFC 3483 policy table, > ::ffff:0:0/96 has the lowest precedence so Teredo would win over > IPv4, which is a Bad Thing. There isn't much to be done about > that unless the user has netsh skills.
s/3483/3484/ Brian On 18/11/2014 13:01, Brian E Carpenter wrote: > On 18/11/2014 07:12, Phil Mayers wrote: >> On 17/11/2014 17:43, Darren Pilgrim wrote: >> >>>> Any ideas what's going on? Microsoft, anyone care to comment? >>> Microsoft released an Windows Update for the prefix policy table. The >>> update dropped Teredo's precedence to lower than IPv4. >> Just to be clear - are you suggesting they did this instead of >> sunsetting Teredo altogether? >> >> In any case, I was always under the impression this was the day-one >> experience - Teredo would only be used to talk to another Teredo DNS >> name or an IPv6-only name in the absence of native IPv6. Am I mistaken? > > I think that was always the intention, but unmanaged tunnels are > liable to behave undesirably. From what Dave Thaler said during > the discussion at the IETF last week on deprecating 6to4, MS > clearly sees Teredo for Xbox-to-Xbox as operational and Teredo > for regular client/server use as undesirable, same as you do. > Dave therefore wanted no change to the RFC 6724 default policy > table, which I assume is exactly what Windows now ships. > > Then, even if the Teredo interface comes up, since > ::ffff:0:0/96 has higher precedence than 2001::/32, Teredo will > not be tried unless there is no IPv4 address at all for the > target host. > > But if the client has the old RFC 3483 policy table, > ::ffff:0:0/96 has the lowest precedence so Teredo would win over > IPv4, which is a Bad Thing. There isn't much to be done about > that unless the user has netsh skills. > > Brian >
