[BEHAVE] auth48 changes to draft-ietf-behave-dns64
"Dan Wing" <dwing@cisco.com> Tue, 29 March 2011 09:09 UTC
Return-Path: <dwing@cisco.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EDB03A692D; Tue, 29 Mar 2011 02:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.492
X-Spam-Level:
X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBX5PrRfWBJP; Tue, 29 Mar 2011 02:09:23 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 685C73A67B7; Tue, 29 Mar 2011 02:09:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2971; q=dns/txt; s=iport; t=1301389850; x=1302599450; h=reply-to:from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=zCdA3Epcc9uj+3IxYlK3N4aeoNNUG/dA+4FBpjMkhgw=; b=Qg8dQDpOVj8F29sX1d4eUtY5wgU0tgLgOFFKdFZQrKsL2zaImxfiK5n4 g3JJNOr3qPMLzp7WQfjULz7ZOTu3JMw2f/21Jt4UPNLioYXeqWfJCzOsV 6OOZ/7YNc8ZCxjBIJwALO/pMnGOSDpTRSFLVvN6VFfFELl8OcdY5TY4yy c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAHWhkU2rRDoJ/2dsb2JhbACZcotTd6dPnEWFagQ
X-IronPort-AV: E=Sophos;i="4.63,260,1299456000"; d="scan'208";a="672318685"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 29 Mar 2011 09:10:50 +0000
Received: from dwingWS (sjc-vpn6-1034.cisco.com [10.21.124.10]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2T9AmCu016470; Tue, 29 Mar 2011 09:10:49 GMT
From: Dan Wing <dwing@cisco.com>
To: behave@ietf.org, ietf@ietf.org
Date: Tue, 29 Mar 2011 11:10:47 +0200
Message-ID: <041d01cbedf1$329be590$97d3b0b0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acvt8TD+IT7X5LVtQb+G1iyxHGHDLA==
Content-Language: en-us
Cc: 'David Harrington' <ietfdbh@comcast.net>, draft-ietf-behave-dns64@tools.ietf.org, behave-chairs@tools.ietf.org
Subject: [BEHAVE] auth48 changes to draft-ietf-behave-dns64
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: behave@ietf.org
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Mar 2011 09:09:24 -0000
During auth48 of draft-ietf-behave-dns64-11.txt, it was realized that two sections were not consistent. The text in Section 5.1.1 is clear: If there is (non-excluded) AAAA data available, DNS64 SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A for an analysis of the motivations for and the implications of not complying with this recommendation). By default, DNS64 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs exist That is, SHOULD NOT in the general case, and MUST NOT as a default case. This represents WG consensus. But then 5.1.4 says something slightly different: 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. It seems rather self-defeating to have excluded ranges and then ignore those. Then the only issue is: if there are both an excluded AAAA record and a non-excluded one, the above says you can either return the good one, or not return any AAAA records. 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. The critical changes are highlighted with "^": 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. We believe this is in line with the WG consensus in section 5.1.1. The updated files are here: http://www.rfc-editor.org/authors/rfc6147.txt http://www.rfc-editor.org/authors/rfc6147.xml http://www.rfc-editor.org/authors/rfc6147-diff.html We are soliciting feedback for this change until noon (Prague time) on Friday, April 1. Please send feedback to behave@ietf.org. -d