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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Tuesday, October 05, 2010 5:07 AM
> To: Rémi Després; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [BEHAVE] One comment on draft-korhonen-edns0-synthesis-
> flag-01
> 
> 
> Dear Rémi, all,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] De la
> part de Rémi Després
> Envoyé : mardi 5 octobre 2010 11:00
> À : [e-mail]
> Cc : [e-mail]; [e-mail]; [e-mail]
> 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.

I don't understand what you're referring to when you say "this approach" --
is that referring to only (3)?  Or to 1, 2, and 3?

I also don't understand what is meant by 'same domain of the IPv6 client',
specifically the phrase 'same domain'.  Let's consider a DNS64 and NAT64
operated by some entity on the Internet as a service, such as operated 
SixXS (for example) or operated by alumni.example.edu.  I chose those
examples because it is clear that DNS64 and NAT64 is not operated by
the same Internet Service Provider that is providing IPv6-only access
service to the IPv6-only host.

Are those services in the same domain as the IPv6-only client?

Does the BEHAVE working group consider those NAT64+DNS64 services
in scope?  Or important to consider when evaluating a solution?

-d



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