Skip to main content

DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
draft-ietf-behave-dns64-11

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>,
    behave mailing list <behave@ietf.org>,
    behave chair <behave-chairs@tools.ietf.org>
Subject: Protocol Action: 'DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers' to Proposed Standard (draft-ietf-behave-dns64-11.txt)

The IESG has approved the following document:
- 'DNS64: DNS extensions for Network Address Translation from IPv6
   Clients to IPv4 Servers'
  (draft-ietf-behave-dns64-11.txt) as a Proposed Standard

This document is the product of the Behavior Engineering for Hindrance
Avoidance Working Group.

The IESG contact persons are David Harrington and Wes Eddy.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-behave-dns64/

Ballot Text

Technical Summary

   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.

Working Group Summary

The document represents WG consensus.

Document Quality

several vendors are actively implementing the specification.
The document does not require a MIB, ABNF, or media type review.

It should be reviewed by the DNS Directorate.

Personnel

Responsible AD: David Harrington 
Dan Wing (dwing@cisco.com) is the document shepherd. 
The document doesn't require IANA experts.

RFC Editor Note

1. Please be sure IPv6 hex addresses are represented in lowercase hex, as per draft-ietf-6man-text-representation.
2. Some minor nits:
#1) Sec 2: r/mode" ./mode".
#2) Sec 5.1.3: r/. ./.
#3) Sec 5.1.7: 
 3a) r/from the A record/from the A record.
 3b) r/28 (AAAA)/28 (AAAA).
 3c) r/to 16/to 16.
 3d) r/([RFC2308]/([RFC2308]).
#4) Sec 7.1 & 7.2: r/h2.example.com/h2.example.com.
#5) Sec 7.1: r/is 64:FF9B::192.0.2.1/is 64:FF9B::192.0.2.1.

#6) Section 5.1.4 is inconsistent with section 5.1.1
The proposal is to change the "MAY build an answer section" in 5.1.4
to "by default MUST build an answer section", so it would read as
follows. 
OLD:
   If it receives an answer with at
   least one AAAA record containing an address outside any of the
   excluded range(s), then it MAY build an answer section for a response
   including only the AAAA record(s) that do not contain any of the
   addresses inside the excluded ranges.  That answer section is used in
   the assembly of a response as detailed in Section 5.4.
   Alternatively, it MAY treat the answer as though it were an empty
   answer, and proceed accordingly.  It MUST NOT return the offending
   AAAA records as part of a response.

NEW:
   When the DNS64 performs its initial AAAA query, if it receives an
   answer with only AAAA records containing addresses in the excluded
   range(s), then it MUST treat the answer as though it were an empty
.....................^^^^
   answer, and proceed accordingly.  If it receives an answer with at
   least one AAAA record containing an address outside any of the
   excluded range(s), then it by default SHOULD build an answer section
.................................^^^^^^^^^^^^^^
   for a response including only the AAAA record(s) that do not contain
   any of the addresses inside the excluded ranges.  That answer section
   is used in the assembly of a response as detailed in Section 5.4.
   Alternatively, it MAY treat the answer as though it were an empty
   answer, and proceed accordingly.  It MUST NOT return the offending
   AAAA records as part of a response.

RFC Editor Note