Re: [BEHAVE] 回复 : draft-korhonen-behave-nat64-learn-analysis-00

Hi Xiaohu,

DNS-based solutions apply only when the outgoing communication involves the DNS. If DNS is not involved, an IPv6 host may not be able to select the appropriate IPv6 address and therefore NAT64 function can be used to reach a dual stack host. This can be critical in scenarios where NAT64 traversal is required.  As an example, referral can enclose indication about the source of the address and its scope (e.g., http://tools.ietf.org/html/draft-carpenter-behave-referral-object-01). Such indication would let a remote peer select among a set of candidate IPv6 addresses and avoid useless invocation of NAT64. 

I already raised this point to Jouni:

* I agree with the edns0 recommendation. Edns0 is superior to my own A64 proposal. I thought an enhancement might be needed for the edns0 to allow using IPv4-Converted IPv6 address in authoritative servers. But it seems this is not in scope of the scenarios covered in this I-D. 

* I don't think recommending only DNS-based solution are sufficient and that complementary solutions such as the referral object/DHCPv6 option may be considered.

Cheers,
Med

-----Message d'origine-----
De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de xuxiaohu 41208
Envoyé : lundi 18 octobre 2010 19:58
À : Rémi Després
Cc : jouni korhonen; Behave WG
Objet : [BEHAVE] 回复 : draft-korhonen-behave-nat64-learn-analysis-00

Hi,

Are the recommended solutions tightly coupled with DNS64?

Xiaohu 

----- 原邮件 -----
发件人: Rémi Després <remi.despres@free.fr>
日期: 星期一, 十月 18日, 2010 下午1:29
主题: [BEHAVE] draft-korhonen-behave-nat64-learn-analysis-00
收件人: jouni korhonen <jouni.nospam@gmail.com>, Teemu Savolainen <teemu.savolainen@nokia.com>
抄送: Behave WG <behave@ietf.org>

> Hi, Jouni and Teemu,
> 
> 1.
> As previously discussed on this list, this draft is IMHO important.
> I hope it can quickly be discussed and become a WG document.
> 
> 2. 
> In the list of CONs of section 4.1.2, it has "Requires a host 
> resolver changes and a mechanism/additions to the host resolver 
> API (or flags, hints etc) to deliver a note to the querying 
> application that the address is synthesized and what is the NSP 
> prefix length."
> 
> An alternative, that IMHO should be considered, is that the 
> resolver API directly presents an IPv4 address to the application. 
> Thus, in my understanding, dual-stack-compatible applications 
> wouldn't need to be modified.
> 
> Regards, 
> RD  
> 
> 
> _______________________________________________
> 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

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************