Re: [sunset4] future of dnssec?

Mark Andrews <marka@isc.org> Thu, 23 February 2017 21:50 UTC

Return-Path: <marka@isc.org>
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E27A129B1A for <sunset4@ietfa.amsl.com>; Thu, 23 Feb 2017 13:50:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 f4wVLE2pnt32 for <sunset4@ietfa.amsl.com>; Thu, 23 Feb 2017 13:50:33 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819E5129B14 for <sunset4@ietf.org>; Thu, 23 Feb 2017 13:50:32 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id EA58F24AE09; Thu, 23 Feb 2017 21:49:13 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D3B1616004F; Thu, 23 Feb 2017 21:49:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B40B4160070; Thu, 23 Feb 2017 21:49:12 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sFG74CGV--9n; Thu, 23 Feb 2017 21:49:12 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 384E516004F; Thu, 23 Feb 2017 21:49:12 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6925A6472627; Fri, 24 Feb 2017 08:49:08 +1100 (EST)
To: "Heatley, Nick" <nick.heatley@ee.co.uk>
From: Mark Andrews <marka@isc.org>
References: <6536E263028723489CCD5B6821D4B21334D566F0@UK30S005EXS06.EEAD.EEINT.CO.UK> <B5E8C545-55B9-4ECB-B0C8-C3EEFEECD320@fugue.com> <20170222143629.9E9C56454B08@rock.dv.isc.org> <8C2DC5DB-88CA-4541-BE50-C23088F77867@viagenie.ca> <20170222210305.97EB36455CD0@rock.dv.isc.org> <6536E263028723489CCD5B6821D4B21334D5732A@UK30S005EXS06.EEAD.EEINT.CO.UK> <20170223130652.4D3A664684D7@rock.dv.isc.org> <6536E263028723489CCD5B6821D4B21334D575CE@UK30S005EXS06.EEAD.EEINT.CO.UK>
In-reply-to: Your message of "Thu, 23 Feb 2017 14:11:36 -0000." <6536E263028723489CCD5B6821D4B21334D575CE@UK30S005EXS06.EEAD.EEINT.CO.UK>
Date: Fri, 24 Feb 2017 08:49:08 +1100
Message-Id: <20170223214908.6925A6472627@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sunset4/F8672dIPaEPjE2Plwm9EkRHn4Fg>
Cc: Marc Blanchet <marc.blanchet@viagenie.ca>, "sunset4@ietf.org" <sunset4@ietf.org>
Subject: Re: [sunset4] future of dnssec?
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list <sunset4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sunset4>, <mailto:sunset4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sunset4/>
List-Post: <mailto:sunset4@ietf.org>
List-Help: <mailto:sunset4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sunset4>, <mailto:sunset4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Feb 2017 21:50:40 -0000

In message <6536E263028723489CCD5B6821D4B21334D575CE@UK30S005EXS06.EEAD.EEINT.C
O.UK>, "Heatley, Nick" writes:
> It is not the phone where the blocker is, Mark.
> It is Core Network "policy, control and charging".
> Encapsulation obstructs any IP function that must be performed prior to t=
> he NAT to the outside.

Why does a telco *need* to look inside a encapsulated packet?  You
charge the customer based on the encapsulating packet.  If you
really need to look inside it isn't hard to take of the IPv6 header
while still remembering who the customer is based on the IPv6
addresses.

Oh dear we are a telco and we are going to play the 800lb gorrilla
and require that every device on the planet be updated do that we
can do NAT64.

RFC 6147 needs updates RFC 4034 as things currently stand.  It's
not a minor extension that only those using DNS64 need to support.
It update *every* validating product on the planet so some telco
don't need to unwrap a encapsulating header to get their accounting
correct.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org