Re: [BEHAVE] One comment on draft-korhonen-edns0-synthesis-flag-01

Dear Rémi, all,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de Rémi Després
Envoyé : mardi 5 octobre 2010 11:00
À : teemu.savolainen@nokia.com
Cc : behave@ietf.org; washam.fan@gmail.com; dwing@cisco.com
Objet : Re: [BEHAVE] One comment on draft-korhonen-edns0-synthesis-flag-01

Hi Teemu.

1.
Isn't the format of the proposed option a subject that needs standardization? (See (*) below.)

2.
An alternative could be a DHCP option that provides the "NAT64 prefix" (the WKP or NSP prefix used by NAT64s to synthesize IPv6 addresses of external IPv4 hosts). It could IMHO coexist with the DNS based solution of draft-korhonen to facilitate deployments where DHCP servers are easier to upgrade than DNS servers. 

3.
In hosts that access Internet via IPv6-only-routing networks, knowing the NAT64 prefix is indeed useful to synthesize IPv6 addresses of IPv4 referrals, as indicated in the draft. But it also permits hosts to recognize which incoming connections were originated by IPv4-only remote hosts. This permits to present them as IPv4 connections as the socket API. 

Med: This approach can be useful to avoid a NAT64 only if the NAT64 is located in the same domain as the IPv6 client. Please refer to http://tools.ietf.org/html/draft-xu-behave-hybrid-type-prefix-00#section-1.1 for more details. Note that referrals will fail if the synthesised IPv6 address does not belong to the same domain as the IPv6-only host.
FWIW, a DHCPv6 option to provision an IPv6-enabled host with an IPv6 prefix and a format to use when synthesising an IPv4-Converted IPv6 address is described in http://tools.ietf.org/html/draft-boucadair-dhcpv6-shared-address-option-01#section-4 (this option has been defined for encapsulation schemes where we don't have the referral issue. New format type values can be defined according to the behave address format ID).

Point 3, is IMHO a simple approach to eliminate conflicts between NAT64s and IPv4-only or dual-stack applications.  

Regards,
RD   

Le 4 oct. 2010 à 22:41, <teemu.savolainen@nokia.com> <teemu.savolainen@nokia.com> a écrit :
> ...
> The idea behind this draft is to describe the lightest solution possible and one that does not require new elements on the network (to access networks or to the server side). I think this could be implemented e.g. in a browser that wishes to increase its chances of success when encountering IPv4 literals in IPv6-only networks, or e.g. by a DNS resolver service in an OS. Introducing STUN would require that someone would have to operate it and it would introduce additional protocol into play (e.g. support to browser/OS).
> 
> The DNS approach would probably also allow some level of caching (in a host or in a recursive DNS server) hence generating less traffic.

> The I-D is Informational (for now) as the lightweight solution should not require any standards work:)

(*)

> (If IANA would define a well-known name should it then be STD?) The other, more explicit and more reliable, proposals are then the ones that require something from the infrastructure (and are for STD).
> 
> Best regards,
> 
> Teemu
> 
>> -----Original Message-----
>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
>> Behalf Of ext Christian Huitema
>> Sent: 04. lokakuuta 2010 22:36
>> To: Dan Wing; 'Washam Fan'; behave@ietf.org
>> Subject: Re: [BEHAVE] One comment on draft-korhonen-edns0-synthesis-
>> flag-01
>> 
>> Dan,
>> 
>> I suppose your comment now applies to draft-savolainen-heuristic-nat64-
>> discovery-00. The draft describes a heuristic for discovering the local
>> NAT64, and the prefix used for address translation -- WKP or NSP. The
>> draft does so by performing a "DNS query to a well-known IPv4 only
>> domain name."
>> 
>> My main objection to this is the reliance on DNS for discovering
>> network connectivity information. This will fail if the NAT64 does not
>> operate a DNS64 translator, or if the local host gets its addresses
>> from a different DNS server than the one tied to the NAT64, e.g.
>> something like Open DNS.
>> 
>> Did the authors look at using STUN, or a variant of STUN, to perform
>> this heuristic discovery?
>> 
>> -- Christian Huitema
>> 
>> 
>> _______________________________________________
>> 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

_______________________________________________
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.
********************************