Teredo sunset - did it happen?

Brian E Carpenter brian.e.carpenter at gmail.com
Tue Nov 18 01:10:31 CET 2014


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
> 


More information about the ipv6-ops mailing list