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

["Dan Wing" <dwing at cisco.com>]

> -----Original Message-----
> From: eric.burgey at orange-ftgroup.com 
> [mailto:eric.burgey at orange-ftgroup.com] 
> Sent: Wednesday, November 04, 2009 3:10 AM
> To: dwing at cisco.com; mohamed.boucadair at orange-ftgroup.com
> Cc: huitema at microsoft.com; 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]
> 
> Hello Dan,
> I hope that the answer to your question is more clear in the 
> new version of the draft:  "draft-boucadair-behave-dns-a64-01.txt"

The new Section 3.1 helps, yes.  Thanks.  In summary, it seems
A64 is intended to help a dual-stack host determine IPv6/IPv4 
translation will occur, and thus prefer native IPv4 connectivity 
instead of (the RFC3484 default) IPv6 connectivity through a 6/4 
translator.

There is text in DNS64 that points out a dual-stack host should
not query a DNS64,
http://tools.ietf.org/html/draft-ietf-behave-dns64-02#section-6,
which seems to eliminate a few -- but not all -- of the points
in http://tools.ietf.org/html/draft-boucadair-behave-dns-a64-01#section-3.1

> Just to summarize:
> Querying an existing DNS64 with CD and DO bits set is just a 
> specific request, but as we explain at the end of section 3.1 
> it is not enough.
>
> We need a specific record type to manage 
> static entries in DNS pointing to IPv4-mapped-IPv6 addresses.
> Such case append when NAT64 is used to interconnect IPv6 
> internet to an IPv4 network.
> As explain in section A.4 of "draft-ietf-behave-dns64-01" the 
> best way to address this scenario is to built a static entry 
> in the authoritative DNS server with an IPv4-mapped-IPv6 
> address built with the Pref64::/n used by the operator of 
> this domain. But if an AAAA record is used for this record a 
> dual-stack host would prefer this AAAA records compared to 
> the A record and all communications will pass through the 
> NAT64 and may experience trouble with the ALG mechanisms.
> An A64 records is just like an AAAA records but with a 
> priority lower than a A records for a dual-stack host. An A64 
> records may be used in an Authoritative server and is not 
> necessarily synthesized by the local DNS resolver.

Ok.  I understand the purpose now.  Thanks for the additional
text in -01 and for this email response.

-d


> Bets regards
> 
> 	Eric BURGEY
> 
> 
> -----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
>