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

[<[e-mail]>]

Dear Dan, all,

Apologies for the confusion.

I used "domain" to denote an administrative network domain (also called an Autonomous System).

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