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

> On 19 jul 2013, at 11:30, Marco Sommani <marco.somm...@iit.cnr.it> wrote:
> 
>> On 18/lug/2013, at 22:09, Brian E Carpenter <brian.e.carpen...@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.somm...@iit.cnr.it

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to