Re: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-D Action:draft-ietf-behave-dns64-01.txt]

[<mohamed.boucadair at orange-ftgroup.com>]

Hi Dan, all,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:dwing at cisco.com] 
Envoyé : jeudi 5 novembre 2009 19:07
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : 'Christian Huitema'; teemu.savolainen at nokia.com; ajs at shinkuro.com; behave at ietf.org; draft-boucadair-behave-dns-a64 at tools.ietf.org
Objet : RE: draft-boucadair-behave-dns-a64-00.txt [was RE: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt]

 

> -----Original Message-----
> From: mohamed.boucadair at orange-ftgroup.com
> [mailto:mohamed.boucadair at orange-ftgroup.com]
> Sent: Thursday, November 05, 2009 6:49 AM
> To: Dan Wing
> Cc: 'Christian Huitema'; teemu.savolainen at nokia.com; ajs at shinkuro.com; 
> behave at ietf.org; draft-boucadair-behave-dns-a64 at tools.ietf.org
> Subject: RE: draft-boucadair-behave-dns-a64-00.txt [was RE: 
> [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt]
> 
> 
> Dear Dan,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> -----Message d'origine-----
> De : Dan Wing [mailto:dwing at cisco.com] Envoyé : vendredi 30 octobre 
> 2009 18:09 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : 'Christian 
> Huitema'; teemu.savolainen at nokia.com; ajs at shinkuro.com; 
> behave at ietf.org; draft-boucadair-behave-dns-a64 at tools.ietf.org
> Objet : RE: draft-boucadair-behave-dns-a64-00.txt [was RE: 
> [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt]
> 
>  
> 
> > -----Original Message-----
> > From: mohamed.boucadair at orange-ftgroup.com
> > [mailto:mohamed.boucadair at orange-ftgroup.com]
> > Sent: Sunday, October 25, 2009 6:34 AM
> > To: Dan Wing
> > Cc: 'Christian Huitema'; teemu.savolainen at nokia.com; 
> ajs at shinkuro.com; 
> > behave at ietf.org; draft-boucadair-behave-dns-a64 at tools.ietf.org
> > Subject: RE: draft-boucadair-behave-dns-a64-00.txt [was RE: 
> > [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt]
> > 
> > 
> > Hi Dan, all,
> > 
> > I'm aware about that mode. In fact it is also part of 
> draft-boucadair 
> > spec.
> 
> Where?  I cannot find the string "CD", "DO", or "bit".
> 
> Med: Yes. What I meant is that draft-boucadair assumes that 
> draft-behave-dns64 can be seen as the first step of 
> deployment. Therefore, the dsn64 spec applies. 
> 
> 
> > The procedure described in
> > draft-ietf-behave-dns64 is assumed as the first step. 
> > draft-boucadair is a step forward to solve some pending issues as 
> > elaborated in 01 version of draft-boucadair. Please refer 
> to Section 
> > Q/A of the updated draft for more discussion.
> > 
> > Do you have in mind explicit "disadvantages"?
> 
> DNS64 already supports the ability for a host to get an 
> un-synthesized response (that is, effectively send a query 
> that does not invoke the DNS64 function).  A dual-stack host 
> can simply do that -- without needing changes to the DNS64 
> specification and without needing a new RR.
> 
> Med: Yes, but the dual stack host does not have any means to 
> prefer native records from synthesised ones. Consequently, 
> the traffic may go through the translators even if this can 
> be avoided. This is typically one of the contributions of A64 
> record. As Eric said earlier A64 records is just like an AAAA 
> records but with a priority lower than a records for a 
> dual-stack host.

I would be interested in how we might detect a dual-stack host
is querying a DNS64; afterall, if we can detect that, and we
can have the DNS64 not do its AAAA synthesis in that case, I 
believe we would achieve the same goal as A64 -- correct?

Med: as far as dual stack are concerned, my answer to your question is: YES (an alternative solution would be to use the solution defined in http://tools.ietf.org/html/draft-boucadair-behave-dns64-discovery-00#section-3.1). But, we still have other issues as listed in the draft. Below an excerpt from draft-boucadair-behave-dns-a64-01:

 2.  [I-D.ietf-behave-dns64] points out in appendix A.4 the needs to
       introduce IPv4-mapped IPv6 address in DNS server that are
       authoritative for a specific QNAME.  The IPv6 prefix used to
       build this IPv4-mapped IPv6 address has been chosen by the
       administrator of the requested QNAME and is not necessarily known
       by the operator providing the Internet access service to the
       requesting host.  So to solve this problem, a mechanism is needed
      to exchange information between Internet access provider to
       distinguish an IPv4-mapped IPv6 address from a native IPv6
       address.  Exchanging A64 records for IPv4-mapped IPv6 address
       instead of AAAA records between DNS recursors and authoritative
       server solves this issue;

   3.  [I-D.ietf-behave-dns64] describes in appendix B cases where both
       IPv4-mapped IPv6 address and native IPv6 can be returned in AAAA
       records and points out that without a specific mechanism to
       distinguish between them the standard process may choose the
       IPv4-mapped IPv6 address.  Using A64 records for IPv4-mapped IPv6
       address solves this issue;

   4.  A dual-stack application receiving an IPv4-mapped IPv6 address is
       not aware that the destination application entity is using an
       IPv4 address.  That application entity may not be able to
       understand any reference in the packet payload to an IPv6
       address.  With the introduction of A64 records, it is possible to
       develop a new API so that updated (i.e., A64-compliant) dual-
       stack applications are able to learn that the IPv6 address comes
       from an A64 records and is an IPv4-mapped IPv6 address.
       Operating systems with this new API may embed a sDN64 function to
       deal with non updated IPv6 applications (i.e., non A64 compliant
       applications).


Cheers,
Med


> -d
> 
> > Cheers,
> > Med
> > 
> > -----Message d'origine-----
> > De : Dan Wing [mailto:dwing at cisco.com] Envoyé : jeudi 22 
> octobre 2009 
> > 19:09 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : 'Christian Huitema'; 
> > teemu.savolainen at nokia.com; ajs at shinkuro.com; behave at ietf.org; 
> > draft-boucadair-behave-dns-a64 at tools.ietf.org
> > Objet : draft-boucadair-behave-dns-a64-00.txt [was RE: 
> > [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt]
> > 
> > > FYI, we have submitted a draft to describe the A64 record for 
> > > IPv4-mapped IPv6 addresses. An updated version of the 
> draft will be 
> > > submitted soon
> > 
> > draft-boucadair-behave-dns-a64-00 requires the DNS64 and 
> the host to 
> > implement a new DNS resource record, A64, in order to learn if the 
> > DNS64 synthesized a response.
> > 
> > Instead, have you considered just having the host query an existing 
> > DNS64 with the CD and DO bits set (which disables the DNS64's AAAA 
> > synthesis) and have the host do its own
> > DNS64 processing?  See item #3 in
> > http://tools.ietf.org/html/draft-ietf-behave-dns64-01#section-5.5
> > 
> > If you have considered that technique, I expect you found 
> some sort of 
> > disadvantage to that technique.  Please share.
> > 
> > -d
> > 
> > 
> > *********************************
> > 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.
> ********************************
> 


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