Re: [BEHAVE] [3gv6] DNS64 Resolvers and Dual-Stack Hosts, draft-wing-behave-dns64-config-00

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] 
> Sent: Friday, January 08, 2010 3:15 AM
> To: Behcet Sarikaya
> Cc: Dan Wing; 3gv6@ietf.org; Behave WG
> Subject: Re: [BEHAVE] [3gv6] DNS64 Resolvers and Dual-Stack 
> Hosts, draft-wing-behave-dns64-config-00
> 
> Behcet Sarikaya escribió:
> > Hi Dan,
> >   I read your draft. 
> > Looking from mobility point of view, I think that on page 
> 4, to the protocols that have trouble with NAT64, MIPv6 
> should be added. 
> >   
> 
> I don't think the problem is specific to MIPv6. the problem 
> is general 
> to any configuration that:
> - Does not use the Well know prefix (i.e. if the WK prefix is used, 
> there is no problem and everything works just fine)
> - The node is using a dns server that is not in the same 
> domain that the 
> NAT64 the node is connected too.

But well-known prefix does not 'just work' if the local network
is not operating a NAT64 at all.  For example, if the local
network is dual-stack, it has no reason to operate a NAT64.
But if the dual-stack host is pointing to an off-site DNS64, 
and that off-site DNS64 is returning synthesized AAAA records
containing the well-known prefix, the dual-stack host will
be unable to connect to anything without timing out and
falling back to IPv4.

> For example you could have the same problem if you are 
> connected to the local network that is providing NAT64 
> services and you decide to use a DNS server that is 
> located in a different domain.

Yes, we should encourage hosts to Not Do That with DNS64.

I just read draft-haddad-mext-nat64-mobility-harmful-00, and I believe the
problems described in its Section 3 could be resolved by the MN following the
recommendation of draft-savolainen-mif-dns-server-selection -- namely, only
use a DNS response on the same interface as the DNS response itself.  This
means that the DNS query should be sent over the same interface as the tunnel
interface (to the foreign network), and the response is only valid for that
same interface.  This can be difficult on many stacks, though (because many
stacks do not concern themselves with which interface received a DNS
response).  That difficulty can be eased if all the networks are using NAT64
with their own network-specific prefix (NSP, as described in
draft-ietf-behave-address-format), as the different NSP allows RFC3484 address
selection rules can choose the correct interface.

-d

> Regards, marcelo
> 
> > However the solutions you proposed would not be good for 
> MIPv6. That's the problem I have with your draft. I have not 
> followed related discussions on Behave list, maybe some 
> solutions have already been proposed there.
> >
> > Regards,
> >
> > Behcet
> >
> >
> >
> > ----- Original Message ----
> >   
> >> From: Dan Wing <dwing@cisco.com>
> >> To: 3gv6@ietf.org; Behave WG <behave@ietf.org>
> >> Sent: Thu, January 7, 2010 4:26:46 PM
> >> Subject: [3gv6] DNS64 Resolvers and Dual-Stack Hosts, 
> draft-wing-behave-dns64-config-00
> >>
> >> draft-wing-behave-dns64-config-00 should be of interest to 
> both 3Gv6 and
> >> BEHAVE.  The draft is related to recent threads on both 
> mailing lists
> >> discussing a DNS64 recursive resolver being used by a 
> dual-stack host.
> >>
> >> Abstract:
> >>   Some networks are expected to support IPv4-only, dual-stack, and
> >>   IPv6-only hosts at the same time.  Such networks also 
> want to IPv6/
> >>   IPv4 translation for the IPv6-only host so it can access 
> servers on
> >>   the IPv4 Internet.  On such a network, the synthesized 
> AAAA responses
> >>   from a DNS64 can cause traffic to be translated.  This document
> >>   describes two solutions to avoid that translation:  
> modifying default
> >>   address selection on the host, and using DHCP to 
> configure different
> >>   DNS recursive resolvers.
> >>
> >> http://tools.ietf.org/html/draft-wing-behave-dns64-config-00
> >>
> >> Comments welcome.
> >>
> >> -d
> >>
> >> _______________________________________________
> >> 3gv6 mailing list
> >> 3gv6@ietf.org
> >> https://www.ietf.org/mailman/listinfo/3gv6
> >>     
> >
> >
> >
> >       
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> >
> >   
> 