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

[Rémi Després <[e-mail]>]

Hi Med,

Comment below.

Le 5 oct. 2010 à 14:07, <[e-mail]> a écrit :
> ...
> 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.

Well, this approach isn't really to "avoid" NAT64, it is rather to improve IPv4 connectivity across them.
It doesn't concern scenarios where it is useful to know whether remote ISPs operate 64s or not.

The question at hand is only "If an ISP only routes IPv6 and supports NAT64/DNS64, what should it provide to its customers for IPv4 connectivity to be good enough." 


Different considerations apply to incoming and outgoing host connections.

An INCOMING connection via a NAT64 implies that the NAT64 maps some IPv4 address (or address + port prefix, or address + port) to the host IPv6 address. The mapping may be static or the result of some hole punching in the NAT, but it has to preexist. 
If the host knows the IPv6 prefix used in its local-ISP NAT64,  it can recognize which incoming connections come from IPv4-only hosts, and use that information. 

For an OUTGOING connection to an IPv4-only host:
- If its destination address is obtained from the DNS, the local DNS64 has synthesized the address. Knowing the NTA64 prefix of its local ISP, the host can determine that the destination is IPv4-only.
- If the destination address is NOT obtained from the DNS, it has, to be made in the same way to all hosts, to be an IPv4 referral. It can be locally translated to an IPv6 destination by prepending to it the NTA64 prefix of its local ISP (a point of draft-korhonen).

Are there other important NAT64 scenarios for the v4tov6transition?
Not in my understanding, but an explanation of what would be missing would of course be welcome.


Kind regards,
RD

> 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, <[e-mail]> <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On
>>> Behalf Of ext Christian Huitema
>>> Sent: 04. lokakuuta 2010 22:36
>>> To: Dan Wing; 'Washam Fan'; [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/behave
>> _______________________________________________
>> Behave mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/behave
> 
> 
> _______________________________________________
> Behave mailing list
> [e-mail]
> 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.
> ********************************
>