Windows Vista / 7 - pure IPv6 (NATPT)

[marcelo bagnulo braun]

  El 02/09/10 1:42, Brandon Applegate escribió:
> On Thu, 2 Sep 2010, Steinar H. Gunderson wrote:
>
>> Den 1. september 2010 22:05 skrev Brandon Applegate 
>> <brandon at burn.net> følgende:
>>> So in short, it appears that Windows 7 fails using the patched BIND 
>>> DNS64
>>> solution above, but works as expected using the built in DNS ALG in 
>>> IOS.
>>
>> Does the DNS ALG in IOS trigger on TCP DNS on these days? If not,
>> you're in for some fairly unpredictable behavior.
>>
>> (Last time I tested, it would just eat the DNS packets, hanging the 
>> request.)
>>
>> /* Steinar */
>> -- 
>> Software Engineer, Google Switzerland
>>
>
> Yes, I just tried it.  TCP gets eaten and EDNS doesn't do any better.  
> So yes, IOS DNS ALG (at least in the IOS I'm running) is nowhere near 
> ready to use in the real world.
>
> I really liked the BIND DNS64.  Would like to do some more captures to 
> see if I can figure out what is making Windows7 unhappy.  I'm guessing 
> it's the fact that the BIND DNS64 gives back the A record answers as 
> well as the synthesized AAAA when the question was only AAAA.  Linux 
> doesn't seem to care about this.  Windows gets tied in a knot 
> (initially, subsequent (after cache) queries work).


but this shouldn't be happening in the general case, afaict.
In section 5.1 of draft-ietf-behave-dns64-10 it reads:

" If there is (non-excluded) AAAA data available, DNS64 SHOULD NOT 
include synthetic AAAA RRs in the response"

The motivations for not complying with this SHOULD as well as the 
implications of failing to comply with this should and possible ways to 
deal with these implications are described in the apendix A of the spec, 
where it reads:


    Appendix A. Motivations and Implications of synthesizing AAAA Resource


              Records when real AAAA Resource Records exist

    The motivation for synthesizing AAAA RRs when real AAAA RRs exist is
    to support the following scenario:

       An IPv4-only server application (e.g. web server software) is
       running on a dual-stack host.  There may also be dual-stack server
       applications running on the same host.  That host has fully
       routable IPv4 and IPv6 addresses and hence the authoritative DNS
       server has an A and a AAAA record.

       An IPv6-only client (regardless of whether the client application
       is IPv6-only, the client stack is IPv6-only, or it only has an



Bagnulo, et al.          Expires January 6, 2011               [Page 29]

    <http://tools.ietf.org/html/draft-ietf-behave-dns64-10#page-30>
Internet-Draft                    DNS64                        July 2010


       IPv6 address) wants to access the above server.

       The client issues a DNS query to a DNS64 resolver.

    If the DNS64 only generates a synthetic AAAA if there's no real AAAA,
    then the communication will fail.  Even though there's a real AAAA,
    the only way for communication to succeed is with the translated
    address.  So, in order to support this scenario, the administrator of
    a DNS64 service may want to enable the synthesis of AAAA RRs even
    when real AAAA RRs exist.

    The implication of including synthetic AAAA RRs when real AAAA RRs
    exist is that translated connectivity may be preferred over native
    connectivity in some cases where the DNS64 is operated in DNS server
    mode.

    RFC3484  <http://tools.ietf.org/html/rfc3484>  [RFC3484  <http://tools.ietf.org/html/rfc3484>] rules use longest prefix match to select the
    preferred destination address to use.  So, if the DNS64 resolver
    returns both the synthetic AAAA RRs and the real AAAA RRs, then if
    the DNS64 is operated by the same domain as the initiating host, and
    a global unicast prefix (called an NSP in
    [I-D.ietf-behave-address-format  <http://tools.ietf.org/html/draft-ietf-behave-dns64-10#ref-I-D.ietf-behave-address-format>]) is used, then a synthetic AAAA RR
    is likely to be preferred.

    This means that without further configuration:

       In the "An IPv6 network to the IPv4 Internet" scenario, the host
       will prefer translated connectivity if an NSP is used.  If the
       Well-Known Prefix defined in [I-D.ietf-behave-address-format  <http://tools.ietf.org/html/draft-ietf-behave-dns64-10#ref-I-D.ietf-behave-address-format>] is
       used, it will probably prefer native connectivity.

       In the "IPv6 Internet to an IPv4 network" scenario, it is possible
       to bias the selection towards the real AAAA RR if the DNS64
       resolver returns the real AAAA first in the DNS reply, when an NSP
       is used (the Well-Known Prefix usage is not supported in this
       case)

       In the "An IPv6 network to IPv4 network" scenario, for local
       destinations (i.e., target hosts inside the local site), it is
       likely that the NSP and the destination prefix are the same, so we
       can use the order of RR in the DNS reply to bias the selection
       through native connectivity.  If the Well-Known Prefix is used,
       the longest prefix match rule will select native connectivity.

    The problem can be solved by properly configuring theRFC3484  <http://tools.ietf.org/html/rfc3484>
    [RFC3484  <http://tools.ietf.org/html/rfc3484>] policy table.


You can find the full spec at

http://tools.ietf.org/html/draft-ietf-behave-dns64-10

Regards, marcelo



>
> -- 
> Brandon Applegate - CCIE 10273
> PGP Key fingerprint:
> 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996
> "SH1-0151.  This is the serial number, of our orbital gun."
>