Re: [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt

Joe Abley <jabley@hopcount.ca> Sat, 25 November 2017 23:45 UTC

Return-Path: <jabley@hopcount.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E50127B60 for <ipv6@ietfa.amsl.com>; Sat, 25 Nov 2017 15:45:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 j3uGQ030iNN6 for <ipv6@ietfa.amsl.com>; Sat, 25 Nov 2017 15:45:57 -0800 (PST)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 7902E127B73 for <6man@ietf.org>; Sat, 25 Nov 2017 15:45:56 -0800 (PST)
Received: by mail-io0-x230.google.com with SMTP id i38so32759925iod.2 for <6man@ietf.org>; Sat, 25 Nov 2017 15:45:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G68r27NadI28O8vYjtH//gET3CZW+SX2XoXu1ua3LRE=; b=CEtOEOTGignHqylyzb5I3+sdWFyLric1tR/xzVhR/XLCofdhRmjla3pb33GOtreXYt RL8bLkRskJFrnhY9hAHHm67ZYPvI5vxNoYZxWp2u0T0c2zYo1P6SfQtObk3BkkYANAJv MM8UzCvyHugcEiKaG6fAsisX4zsN4C8TiR20M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G68r27NadI28O8vYjtH//gET3CZW+SX2XoXu1ua3LRE=; b=OOs6N9umrqbZIYoij7YJRLB0pxP/nKK4ngIiProLYuklDGR9nJs8DESdvzkWswhqzP dkayFRs8fcnnEqFbvThcC4MnpS8QpTcAR1MhYwzfnhdYj+vvqPjwCtRvQLyLlzc29p79 myzXAtAGuAHygHHqYIA2qCAm9Llf0NdJK1xg42ROojAZ1P8kxaQJiBRkHz5UgDbbcNSw HPKDPvwuXEi3w9rZNKi21jRFtUmnkP5GP4/eATE/qkxhd2oBnu+u8FRIVfnT+v+MiJtm YdD8EgWrboo0qLh+Dz65snAgyryR/SA5L5j2P6sweozg20sjDgBEnuZ+ADayN7ZwnUjU QUNw==
X-Gm-Message-State: AJaThX5RbrjYOFWzL1QoPaHoutCmCJL3YMIZSoEdCrypAjyzSxKpq+Ia GFlxGA6xvL+C4GoM/gU2CIqvCw==
X-Google-Smtp-Source: AGs4zMbuRuIyKP/D80dRHyhwqCglS6QhrQo/TjEnWpoLtqQlKH9iFxgSB1ppUYbpr6Ed2iGhafyx9Q==
X-Received: by 10.107.198.84 with SMTP id w81mr37726401iof.151.1511653555568; Sat, 25 Nov 2017 15:45:55 -0800 (PST)
Received: from ?IPv6:2607:f2c0:101:3:b07e:ddeb:fe18:44cf? (node-131dv5j4grjd2zso9b.ipv6.teksavvy.com. [2607:f2c0:101:3:b07e:ddeb:fe18:44cf]) by smtp.gmail.com with ESMTPSA id q6sm4972037ita.38.2017.11.25.15.45.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Nov 2017 15:45:53 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
Subject: Re: [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
From: Joe Abley <jabley@hopcount.ca>
X-Mailer: iPad Mail (15B202)
In-Reply-To: <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com>
Date: Sat, 25 Nov 2017 18:45:52 -0500
Cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, dnsop@ietf.org, 6man@ietf.org, Daniel Karrenberg <daniel@karrenberg.net>, "v6ops@ietf.org WG" <v6ops@ietf.org>, sunset4@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca>
References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> <B0A6AF83-099A-4D4D-83EB-BA4B45D00353@consulintel.es> <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com>
To: Fred Baker <fredbaker.ietf@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1OwBIF5BF3FyZMm3T9x5ThW_h84>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Nov 2017 23:45:59 -0000

Hi Fred,

[I haven't read Jordi's draft; I'm just responding to what I've read in this thread.]

On Nov 25, 2017, at 14:00, Fred Baker <fredbaker.ietf@gmail.com> wrote:

> One thing you might want to think about: the root servers are all IPv6-capable today and serve requests using IPv6, and the 1541 TLDs are all required by contract with ICANN to be IPv6-capable. I think you'll find yourself holding the burden of proof that the infrastructure isn't capable of IPv6-only operation today.

monster:~]% egrep -c '^[A-Z]' /usr/share/misc/iso3166 
249
[monster:~]% 

There are potentially 249 TLDs that are not operated under any such contract with ICANN, although I agree that the majority of ccTLDs have at least one nameserver that is v6-capable (maybe all, but I haven't checked and I wouldn't want to assume).

The important clients for all of these authoritative servers from the perspective of end-users are resolvers. I think it's uncontroversial to suggest without citation that not all resolvers used by end-users today are v6-capable, or downstream from a resolver that is v6-capable. So we are not ready to turn off v4 today unless significant collateral damage is considered acceptable (and surely it's not).

This is a relatively small problem to solve, though (note use of "relatively"). I think it would actually be practical to announce a sunset for v4 on gTLD and root servers at some suitable target date in the not too distant future, the implementation of which could be mainly handled within the root zone itself.

Aside from the techno-political v6-deployment motivations, I think there would be good engineering reasons to sunset v4 in root and TLD servers.

Such a move would open the door to the complete removal of v4 transport from all of those servers which would eliminate them as viable amplifiers in attacks against v4 targets. It would also provide greater motivation to deal with any unreliability in v6 operations in the DNS or connecting networks, fragmentation-related transport issues, etc which will surely otherwise see minimal attention so long as working v4 transport masks v6 problems.


Joe