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>]

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.

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