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 11:02 AM
> To: Dan Wing; 'Rémi Després'; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE : [BEHAVE] One comment on draft-korhonen-edns0-synthesis-
> flag-01
> 
> Dear Dan, all,
> 
> Apologies for the confusion.
> 
> I used "domain" to denote an administrative network domain (also called
> an Autonomous System).

As in, a BGP AS?

So, you are suggesting we (BEHAVE) should not concern itself with a
DNS64+NAT64
operated by an entity other than the ISP providing IPv6-only network
connectivity.

-d


> Cheers,
> Med
> 
> ________________________________________
> De : Dan Wing [[e-mail]]
> Date d'envoi : mardi 5 octobre 2010 19:29
> À : BOUCADAIR Mohamed NCPI/NAD/TIP; 'Rémi Després';
> [e-mail]
> Cc : [e-mail]; [e-mail]
> Objet : RE: [BEHAVE] One comment on draft-korhonen-edns0-synthesis-
> flag-01
> 
> > -----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.
> > ********************************
> 
> 
> *********************************
> 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.
> ********************************