IETF Logo Mail Archive

Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 28 September 2017 07:58 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BCC1354F5 for <v6ops@ietfa.amsl.com>; Thu, 28 Sep 2017 00:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptRACVPs8v02 for <v6ops@ietfa.amsl.com>; Thu, 28 Sep 2017 00:58:27 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FE2135516 for <v6ops@ietf.org>; Thu, 28 Sep 2017 00:58:17 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 16DC6AF; Thu, 28 Sep 2017 09:58:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506585495; bh=aavzwkpslDHP7I7gJFl0tEs+FFaJ83M7YX/4XraBLew=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=IvaInKKLbODFsGC35c8bIJMGE/fcxSDjfGhRtXSdgZFrqtvM+SRgSGrptH+Zb9eDP 9bbykbFHwJjBKRFc5Q17trnHclTkPrSgP+9cUIGxjmrlorRACYKmoFtlBeEUnny6qv Iue5pAnJYDhH7zMiaOcZek6RM5TCJV+9eoP+NdeE=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0056F84; Thu, 28 Sep 2017 09:58:14 +0200 (CEST)
Date: Thu, 28 Sep 2017 09:58:14 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Mark Andrews <marka@isc.org>
cc: IPv6 Ops WG <v6ops@ietf.org>
In-Reply-To: <20170928074105.BCB99886E538@rock.dv.isc.org>
Message-ID: <alpine.DEB.2.20.1709280955490.18564@uplift.swm.pp.se>
References: <LO1P123MB01168388285206BB7C26F029EA7A0@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM> <46045DAA-9096-43BA-A5FD-571232767726@google.com> <CAKD1Yr3vziaHfkR+hQ7QHXaz7QraKH2HLUVXUW63GpnOAj4JoQ@mail.gmail.com> <E72C3FBE-57A4-4058-B9E5-F7392C9E9101@google.com> <LO1P123MB0116805F9A18932E2D0694FEEA780@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <CAD6AjGQdMFgv4727wHm41HmEyo2Z-PCabPHPSRSVwOi_rey7OQ@mail.gmail.com> <CAKD1Yr03zsuSBqPegs6RNbBqnJizUOLZwH+rNDi1Ocg4k+mARQ@mail.gmail.com> <20170928030630.DD2D08867238@rock.dv.isc.org> <alpine.DEB.2.20.1709280753080.18564@uplift.swm.pp.se> <20170928074105.BCB99886E538@rock.dv.isc.org>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/8CAsr2yN3gw4qv537kkI_K5Sfb4>
Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Sep 2017 07:58:29 -0000

On Thu, 28 Sep 2017, Mark Andrews wrote:

> You do know the RFC 7050 doesn't work with DNSSEC validation enabled. 
> RFC 7050 specifies CD=0.

Correct. I don't get your point. This is the local resolver on the device 
trying to figure out where the NAT64 prefix is. Of course it can't do 
validation on this specific query.

We all know DNS64+NAT64(+464XLAT) isn't optimal, but neither is your 
suggestion to "just run dual stack".

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email