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

> -----Original Message-----
> From: behave-bounces@ietf.org 
> [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun
> Sent: Friday, January 08, 2010 10:55 AM
> To: Dan Wing
> Cc: draft-haddad-mext-nat64-mobility-harmful@tools.ietf.org; 
> 'Behcet Sarikaya'; 3gv6@ietf.org; 'Behave WG'
> Subject: Re: [BEHAVE] [3gv6] DNS64 Resolvers and Dual-Stack 
> Hosts,draft-wing-behave-dns64-config-00
> 
> Dan Wing escribió:
> >  
> >
> >   
> >> -----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.
> >   
> are you assuming that the mobile node is dual stack of IPv6 only?

I'm not sure it matters:

Let's assume the mobile node is dual-stack, and encounters a 
dual-stack network that is not operating a NAT64.  If that 
mobile node (for whatever reason) sends a query to a DNS64
somewhere on the Internet which returns an AAAA with the
well-known prefix (64:FF9B::/96) such as, for example, 
64:FF9B::192.0.2.1, the mobile node will send a TCP SYN to
64:FF9B::192.0.2.1 which won't route anywhere.  The mobile
node will timeout its attempted TCP connection.

Let's assume the mobile node is IPv6-only, and encounters a
dual-stack network that is not operating a NAT64.  If that
mobile node (for whatever reason) sends a query to a DNS64
somewhere on the Internet which returns an AAAA with the
well-known prefix (64:FF9B::/96) such as, for example, 
64:FF9B::192.0.2.1, the mobile node will send a TCP SYN to
64:FF9B::192.0.2.1 which won't route anywhere.  The mobile
node will timeout its attempted TCP connection.

-d

> Regards, marcelo
> 
> 
> 
> > 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
> >>>
> >>>   
> >>>       
> >
> >
> >   
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave