teredo.ipv6.microsoft.com off?

[Marco Sommani]

On 19/lug/2013, at 10:50, Martin Millnert <martin at millnert.se> wrote:

> On 19 jul 2013, at 11:30, Marco Sommani <marco.sommani at iit.cnr.it> wrote:
> 
>> On 18/lug/2013, at 22:09, Brian E Carpenter <brian.e.carpenter at gmail.com> wrote:
>> 
>>> Wait... I had the impression that iff there was no other IPv6 connectivity,
>>> Teredo was used in older Windows because of the generic "prefer IPv6" rule.
>>> The default RFC 3484 table covers 6to4 but not Teredo.
>>> 
>>> Recent Windows deprefs Teredo of course.
>>> 
>>> Brian
>> 
>> Right. The policy table in RFC 3484 has no specific entry for prefix 2001::/32. This is corrected in the table of RFC 6724:
>> 
>>     Prefix        Precedence Label
>>     ::1/128               50     0
>>     ::/0                  40     1
>>     ::ffff:0:0/96         35     4
>>     2002::/16             30     2
>>     2001::/32              5     5
>>     fc00::/7               3    13
>>     ::/96                  1     3
>>     fec0::/10              1    11
>>     3ffe::/16              1    12
>> 
> 
> From what I recall from MS representatives, gethostbyname() etc does not send AAAA queries, if "nothing better is configured".  Would this be controlled by the table above (6724)?
> 
> /Martin - (native v6 FTW)


If I understand the RFC correctly, AAAA queries are sent anyway, but, if in the end the choice is between using the IPv4 source address or the Teredo source address, the IPv4 source is preferred, because its entry in the table (prefix ::ffff:0:0/96) has a greater precedence (35) than the Teredo prefix (5). The choice of the IPv4 source address has, as a consequence, tha fact that the destination address must be IPv4 too, so the AAAA record is ignored, even if it was returned by the DNS query.

-- 
Marco Sommani
Consiglio Nazionale delle Ricerche
Istituto di Informatica e Telematica
Via Giuseppe Moruzzi 1
56124 Pisa - Italia
work: +390506212127
mobile: +393487981019 
fax: +390503158327
mailto:marco.sommani at iit.cnr.it

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5466 bytes
Desc: not available
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20130719/63caacfb/attachment.p7s>