Subject: [BEHAVE] [Fwd: I-D Action:draft-ietf-behave-dns64-00.txt]

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 04 Jul 2009 13:48:16 +0200

Hi,

We have submitted a new version of the dns64 draft.
comments are welcome

Regards, marcelo

-------- Mensaje original --------
Asunto: 	I-D Action:draft-ietf-behave-dns64-00.txt
Fecha: 	Sat, 4 Jul 2009 04:45:01 -0700 (PDT)
De: 	[email-masked]
Responder a: 	[email-masked]
Para: 	[email-masked]
CC: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
	Author(s)       : M. Bagnulo, et al.
	Filename        : draft-ietf-behave-dns64-00.txt
	Pages           : 26
	Date            : 2009-07-04

DNS64 is a mechanism for synthesizing AAAA records from A records.
DNS64 is used with an IPv6/IPv4 translator to enable client-server
communication between an IPv6-only client and an IPv4-only server,
without requiring any changes to either the IPv6 or the IPv4 node,
for the class of applications that work through NATs.  This document
specifies DNS64, and provides suggestions on how it should be
deployed in conjunction with IPv6/IPv4 translators.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-dns64-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Mark Andrews <[email-masked]>
Date: Mon, 06 Jul 2009 11:48:09 +1000

Could you please replace your mail client with one which generates
mime compliant messages? 

drugs:Reports 11:42 {1311} % show
(Message inbox:211657)
mhshow: invalid parameters for "message/external-body" type in message 211657's Content-Type field
drugs:Reports 11:47 {1312} % 

See RFC 2017 for how message/external-body should have been encoded.

Mark

In message <[email-masked]>, marcelo bagnulo braun writes:
> This is a multi-part message in MIME format.
> --------------070801090600090008080705
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> Hi,
> 
> --------------070801090600090008080705
> Content-Type: Message/External-body;
>  name="draft-ietf-behave-dns64-00.txt"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
>  filename="draft-ietf-behave-dns64-00.txt"
> 
> Content-Type: text/plain
> Content-ID: <[email-masked]>
> 
> 
> 
> --------------070801090600090008080705
> Content-Type: text/plain;
>  name="Parte del mensaje adjunto"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
>  filename="Parte del mensaje adjunto"
> 
> --------------070801090600090008080705
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
> 
> --------------070801090600090008080705--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Tue, 7 Jul 2009 13:34:47 -0400

> We have submitted a new version of the dns64 draft.

Overall I think it's progressing very nicely. The normative section is getting 
more precise.

- Section 5.1, 3rd paragraph:

   If the query results in no error but an empty answer section in the
   response, the DNS64 resolver attempts to retrieve A records for the
   name in question.  If this new A RR query results in an empty result
   or in an error, this result is returned to the client.

The conditions are not quite right. For example, suppose the answer section is 
not empty, but none of the RRs in the answer section really answer the query 
(e.g. a CNAME record is present, but no AAAA).

Suggestion: "If the query results in no error but the answer section does not 
contain a AAAA RR whose name matches that of the query, [...]. If this new A 
RR query results in an error or does not contain an A RR whose name matches 
that of the query, [...]."

Is there a short DNS term summarizing that idea?

- Section 5.1, 3rd paragraph:

   The DNS64 resolver then returns the synthesized AAAA
   records in the answer section to the client, removing the A records
   that form the basis of the synthesis.

This may be a naive question: what is the rationale for removing the A 
records? Did I miss that discussion?

Nit:

- Section 5.3.1:

         synthetic AAA RR from the IPv4 address contained in original A

s/AAA/AAAA/

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Jul 2009 13:51:05 -0400

> Is there a short DNS term summarizing that idea?

There isn't, I think.  What you want is that the A-record-chasing
branch of execution happens if and only if there is no AAAA record in
the answer to the AAAA query, rather than in the case where the answer
section is empty?  (This is still slightly too aggressive, because the
server might have answered with the CNAME and not followed the chain,
but the chain might have AAAA in it after all.  But I suspect that
case is going to be incredibly rare.)  Is that the idea?

> records? Did I miss that discussion?

The resolver asked for a AAAA record.  It would be pretty surprising
if it got an A record back in the answer.  

Thanks for your comments!

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 7 Jul 2009 14:10:12 -0400

On Tuesday 07 July 2009 13:51:05 Andrew Sullivan wrote:
> section is empty?

...and if there is no error code. Right.

> (This is still slightly too aggressive, because the
> but the chain might have AAAA in it after all.

Right. We have to assume that the DNS64 function is always behind a recursing 
function.

The general idea is to handle cases where the upstream server, for whatever 
reason, returns RRs in the answer section that do not answer the query.

> if it got an A record back in the answer.

Maybe, but it would still be legal (or would it not be?), and we can expect 
implementations to cope with extra answer RRs because they already do for e.g. 
CNAME and RRSIG.

Simon

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Jul 2009 14:28:36 -0400

> Right. We have to assume that the DNS64 function is always behind a recursing 

We can't assume that -- the "server mode" version of DNS64 (which I
personally think is awful, but better to define the least-awful than
to leave it up to people who think such things are a good idea) is
automatically not behind a recursive resolver.  (But I think maybe
your "always behind" here is actually just scope-limited for this
discussion.  I just wanted not to mislead others watching the thread.)

> CNAME and RRSIG.

CNAME and RRSIG are explicitly defined that way.  What you are
suggesting is that it would be ok to send any random RR with the same
RNAME in the answer section of the query.  Ed Lewis actually suggested
returning the A along with the AAAA at the mic in [mumble
minneapolis?], and I liked the idea; but the overall reaction I got
from implementers and operators was that this strategy would fail for
many implementations.  So I think we can't do it that way.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.