[apps-discuss] apps-team review of draft-ietf-behave-v4v6-bih-06

Xiaodong Lee <lee@cnnic.cn> Thu, 22 September 2011 00:30 UTC

Return-Path: <lee@cnnic.cn>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CDBC421F8D2A for <apps-discuss@ietfa.amsl.com>; Wed, 21 Sep 2011 17:30:17 -0700 (PDT)
X-Quarantine-ID: <l22al61Cu9fQ>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID"
X-Spam-Flag: NO
X-Spam-Score: -1.196
X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MSGID_FROM_MTA_HEADER=0.803]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id l22al61Cu9fQ for <apps-discuss@ietfa.amsl.com>; Wed, 21 Sep 2011 17:30:17 -0700 (PDT)
Received: from cnnic.cn (smtp.cnnic.cn []) by ietfa.amsl.com (Postfix) with SMTP id D150721F8D25 for <apps-discuss@ietf.org>; Wed, 21 Sep 2011 17:30:15 -0700 (PDT)
Received: (eyou send program); Thu, 22 Sep 2011 08:32:33 +0800
Message-ID: <516651553.19518@cnnic.cn>
Received: from unknown (HELO []) ( by with SMTP; Thu, 22 Sep 2011 08:32:33 +0800
Message-ID: <4E7A8225.4060701@cnnic.cn>
Date: Thu, 22 Sep 2011 08:32:37 +0800
From: Xiaodong Lee <lee@cnnic.cn>
Organization: CNNIC
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: apps-discuss@ietf.org, iesg@ietf.org, bill.huang@chinamobile.com, denghui02@gmail.com, teemu.savolainen@nokia.com, dthaler@microsoft.com, dwing@cisco.com
X-Enigmail-Version: 1.3.2
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Subject: [apps-discuss] apps-team review of draft-ietf-behave-v4v6-bih-06
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: lee@cnnic.cn
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Sep 2011 00:30:17 -0000

I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-behave-v4v6-bih-06

Title: Dual Stack Hosts Using "Bump-in-the-Host" (BIH)

Reviewer: Xiaodong Lee

Review Date: 2011-09-21

Review Summary:
This draft is almost ready for publication but has a few issues that
should be clarified and fixed before publication.

Major Issues:
“BIH has the potential to interfere with the functioning of DNSSEC,
because BIH modifies DNS answers, and DNSSEC is designed to detect such
modifications and to treat modified answers as bogus.”  as in Section 7.4.

This document overall provides an valuable 4-6 translation solution.
However, the effects this draft will pose on DNS should be deliberately
considered. As described in BIH, ENR (Extension Name Resolve) is to
modify DNS request and response messages as in ” The Extension Name
Resolver (ENR) returns an answer in response to the IPv4 application’s
name resolution request.” , which means BIH has the potential to
interfere with the functioning of DNSSEC.

Yet circumstances alter cases due to the two different ENR
implementation options. In the case of the socket API layer
implementation option, there is no conflicts with DNSSEC. However, in
the case of the network layer implementation option, BIH modifies DNS
answers, and DNSSEC is designed to detect such modifications and to
treat modified answers as bogus. This draft recognizes the issue and
prefers the former as in “Hence the socket API layer option is
RECOMMENDED.” in section 2.3. Since this draft is intended for standard
track, RECOMMENDED is not strong enough, the socket API layer option
should be the “SHOULD” solution or specify that “One implementation
SHOULD NOT interferes DNSSEC mechanism”.

Minor Issues: NA

Nits: NA

Xiaodong LEE
Professor, Chinese Academy of Sciences