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

From: [email-masked]
Date: Fri, 1 Oct 2010 07:00:04 -0700 (PDT)

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-11.txt
	Pages           : 32
	Date            : 2010-10-01

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

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 1 Oct 2010 10:06:55 -0400

Dear colleagues,

> 	Filename        : draft-ietf-behave-dns64-11.txt

This version is to address issues raised during IESG review.

Best regards,

A

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

---

From: Mark Andrews <[email-masked]>
Date: Mon, 11 Oct 2010 15:55:51 +1100

Why is synthesis prohibited when a answer validates as insecure and
there are no relevent signatures in the answer which would cause
down stream validation to fail if synthesis occured just because
DO and CD were set in the query?  i.e the answer appears to come
from a unsigned zone.

Just for reference named uses the presence of DO + signatures to
decide whether to return AAAA record to AAAA queries over IPv4 when
filter-aaaa is enabled (only return AAAA records over IPv4).  DNS64
as similar DNSSEC constraints.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Oct 2010 10:28:02 -0400

> DO and CD were set in the query?  i.e the answer appears to come

Well, one reason is because nobody ever asked about this before, as
far as I can tell.  But also, it seems to me that it's just simpler to
specify this way.

Given that we're past both WG and IETF LC, I'd prefer to leave this
alone as it stands.  We got extensive comments from the DNS
directorate review that make me believe we'll need to start work on a
bis document more or less as soon as this is published.  That said, if
people really want to change the above at this date, I believe the
document ought to go through another LC, since it's a substantive
change to the algorithm.

A

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 13 Oct 2010 11:27:24 +1100

In message <[email-masked]>, Andrew Sullivan writes:
> bis document more or less as soon as this is published.

Fine we can leave this for a bis.

More fodder for the bis.  To comply this this document we MUST
filter out excluded addresses from replies, this really is a over
specification.  One should do minimal damage to responses and
filtering excluded addresses in replies is not doing minimal damage.
Not every AAAA query is being made so that a connection can be made.
If we took this approach we would not return AAAA lookups on a IPv4
only network.

If we don't end up performing AAAA synthesis then the original
response to the AAAA query should be returned.  If people put garbage
into the DNS then the garbage should be returned.  DNS64 is not the
place to specify filtering of responses.

> That said, if