Re: [BEHAVE] Some thoughts on DNS synthesis in DNS64, DNS46, and BIH

<teemu.savolainen@nokia.com> Wed, 10 November 2010 09:45 UTC

Return-Path: <teemu.savolainen@nokia.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 6E29F3A6A98 for <behave@core3.amsl.com>; Wed, 10 Nov 2010 01:45:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 Qj6oKUDwsVLk for <behave@core3.amsl.com>; Wed, 10 Nov 2010 01:45:52 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id F23203A6A8E for <behave@ietf.org>; Wed, 10 Nov 2010 01:45:51 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id oAA9kBfv003912; Wed, 10 Nov 2010 11:46:16 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Nov 2010 11:45:50 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Nov 2010 11:45:49 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 10 Nov 2010 10:45:49 +0100
From: teemu.savolainen@nokia.com
To: dthaler@microsoft.com, behave@ietf.org
Date: Wed, 10 Nov 2010 10:45:46 +0100
Thread-Topic: Some thoughts on DNS synthesis in DNS64, DNS46, and BIH
Thread-Index: AcuAapoW8Zqvt5tuQ1CaZ4ZlEK3POAAGASvgAA5JsbA=
Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F5F05D026B1@NOK-EUMSG-01.mgdnok.nokia.com>
References: <9B57C850BB53634CACEC56EF4853FF6534381706@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <9B57C850BB53634CACEC56EF4853FF6534381706@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_18034D4D7FE9AE48BF19AB1B0EF2729F5F05D026B1NOKEUMSG01mgd_"
MIME-Version: 1.0
X-OriginalArrivalTime: 10 Nov 2010 09:45:50.0001 (UTC) FILETIME=[0EC24210:01CB80BC]
X-Nokia-AV: Clean
Subject: Re: [BEHAVE] Some thoughts on DNS synthesis in DNS64, DNS46, and BIH
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Wed, 10 Nov 2010 09:45:59 -0000

Dave, I think your proposal is a very good one. I will bring it up tomorrow during BIH presentation. For me this seems like a good way to progress both in discussions and in draft updates.

Thank you,

Teemu

From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of ext Dave Thaler
Sent: 10. marraskuuta 2010 10:57
To: 'behave' (behave@ietf.org)
Subject: [BEHAVE] Some thoughts on DNS synthesis in DNS64, DNS46, and BIH

Thinking about the comments on BIH led me to the following observations.

draft-ietf-behave-dns64 section 5.1.4 ("Special exclusion set for AAAA records")
talks about how to handle the fact that some IPv6 addresses are not actually
usable by IPv6-only hosts, and recommends that the DNS64 be configurable
with a set of prefixes to ignore and synthesize anyway, and not return the
original response but only the synthesized one.  However there's currently
no text in the dns64 document that says that an admin shouldn't configure
::/0 as an exclusion range.

draft-xli-behave-dns46-for-stateless is supposed to be the DNS46 equivalent
of DNS64.  However, it currently doesn't contain any text equivalent to the
above exclusion set.  I think this is in error and it should have similar text
(really it should have minimal diffs from DNS64).   You could have bogus
A records with 127.0.0.1, 169.*, and other bogon ranges just like bogus AAAA records.

So really the possibilities for synthesis are:

a)      Never synthesize if you get any address regardless of validity

b)      Perform some hard-coded exclusions

c)      Perform configurable exclusions

d)      Perform dynamically detected (i.e. autoconfigured or learned) exclusions
based on some not-currently-defined mechanism

The contentious BIH topic is just a special case of dns46, and the same
possibilities apply.   My opinion is that BIH and dns46 should have text
equivalent to dns64 section 5.1.4.

An implementer of any DNS synthesis mechanism (whether DNS64, DNS46,
or the BIH use of DNS46) should just implement the ability to have
configurable exclusions (c in the above list).

The rest of the discussion is then just about guidance to those who configure
such things, and what is or is not appropriate to exclude.  And various
categories exist independent of DNS46 vs DNS64 vs BIH that can be
discussed as to whether they should be excluded by default, are ok
to configure to exclude, or should not be configured exclusions, listed
below in rough order of least-to-most contentious:


*        Addresses that should never appear in DNS or on the wire

*        Addresses that are known to be permanently unreachable (e.g.
net 10, ULA space) from the DNS synthesizer's network

*        Addresses that are observed to be problematic/flaky (maybe 6to4
in some cases?)

*        Addresses that would work but the admin would prefer to avoid
by policy

*        All addresses for a given IP version (which actually might be the
same as one of the previous 3)

-Dave