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

<> Mon, 26 September 2011 15:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42CBD21F8D05; Mon, 26 Sep 2011 08:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.617
X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CXfUTJioHskg; Mon, 26 Sep 2011 08:03:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 59EE121F8CF3; Mon, 26 Sep 2011 08:03:48 -0700 (PDT)
Received: from ( []) by (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8QF6Cpf030733; Mon, 26 Sep 2011 18:06:19 +0300
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 18:06:00 +0300
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 26 Sep 2011 17:05:59 +0200
Received: from ([]) by ([]) with mapi id 14.01.0339.002; Mon, 26 Sep 2011 17:05:53 +0200
Thread-Topic: apps-team review of draft-ietf-behave-v4v6-bih-06
Thread-Index: AQHMeL8kJ8Eq7AO5bUCBOUeEamEB1JVfv7EQ
Date: Mon, 26 Sep 2011 15:05:52 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Company Confidential; Project=None;
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Io6FujjSfNcXJGUP9WUdfQoJmpfVHi50dPq5KK9wdv8YNGkrNUplCvmjWdf9phYYMRXhwHrEJX4ib4MabW/xCLlvk8hG/TpdC8+bjCDJNRHJrq4pnSa2HqfNb2yNT6miQyGZIfcm+CuuXr5eddxJ15o/7GHyCGKTpwvHOZOvIpRrxesTFEPoly5rM5rT5pFjJ9ciw+Fla3i/aQw2KnR1QM/c/++CjTBtO0CeiVu4dZ2BzPUvEiP9JKVksK/HCT91wg==
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0261_01CC7C76.EA4DBC90"
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Sep 2011 15:06:00.0587 (UTC) FILETIME=[CD590DB0:01CC7C5D]
X-Nokia-AV: Clean
X-Mailman-Approved-At: Tue, 27 Sep 2011 08:27:25 -0700
Subject: Re: [apps-discuss] apps-team review of draft-ietf-behave-v4v6-bih-06
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Sep 2011 15:03:50 -0000

Thank you very much for review. 

Comments inline:

> -----Original Message-----
> From: ext Xiaodong Lee []
> Sent: 22. syyskuuta 2011 03:33
> To:;;;
>; Savolainen Teemu (Nokia-CTO/Tampere);
> Subject: apps-team review of draft-ietf-behave-v4v6-bih-06
> 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".

Current wording uses RECOMMENDED, as DNSSEC can be made to work on either
case. It is easier and simpler in the socket API level implementation case
(that's why RECOMMENDED), but even in the network layer implementation it
should be possible to configure the stub resolver to trust on ENR, which can
then perform the validation. The network layer implementation of course
cannot be simply dropped into any host, as DNSSEC-aware resolver on the host
must work properly with ENR (especially if DNSSEC-aware resolver needs to
trust ENR).

So..  if the current wording needs improvement, maybe SHOULD be fine e.g.
due simplicity and having less things that can go wrong, or we could leave
the recommendation totally out. In the tsv-area review there was request to
have pros/cons better explained. If a new pros/cons section would be
created, it could then be clear that DNSSEC support is easier to arrange in
socket API level implementation option.

Best regards,