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

[marcelo bagnulo braun <[e-mail]>]

Dan Wing escribió:
>  
>
>   
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of marcelo bagnulo braun
>> Sent: Friday, January 08, 2010 10:55 AM
>> To: Dan Wing
>> Cc: [e-mail]; 
>> 'Behcet Sarikaya'; [e-mail]; '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:[e-mail]] 
>>>> Sent: Friday, January 08, 2010 3:15 AM
>>>> To: Behcet Sarikaya
>>>> Cc: Dan Wing; [e-mail]; 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,

if the mobile node is dual stack, it should be running dsmip, i guess 
and i don't think it would make sense to expose dns64 information to 
it... but maybe more dsmip experts can correct me here

so i would focus on the ipv6 only mn case imho
>  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.
>
>   
correct, but what is the alternative?
I mean, if the dns64 creates the synthetic RR, it is because there is no 
real AAAA RR, so the target host is IPv4 only.
So, the only option for communication between the IPv6 only MN and the 
IPv4 only CN is to use a NAT64.
If there is no NAT64 available, the communication will fail, and this is 
not a problem of the type of prefix used for the communication.

So, i would argue that in this case, the communication fails, but not 
because the nat64 is harmful, but due to the lack of nat64.

So, my argument that the WKP shoudl solve this particular type of cases, 
in all the cases the communication could possibly work.

So, for dual stack MN, use dsmip
For IPv6 only nodes, use nat64/dns64 plus the WKP.

makes sense?

Regards, marcelo


> -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 <[e-mail]>
>>>>>> To: [e-mail]; Behave WG <[e-mail]>
>>>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/3gv6
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>       
>>>>> _______________________________________________
>>>>> Behave mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/behave
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>   
>>>       
>> _______________________________________________
>> Behave mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/behave
>>     
>
>
>