Re: [sunset4] [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: 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 82903127B60 for <sunset4@ietfa.amsl.com>; Sat, 25 Nov 2017 15:45:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7] 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 qvzwQkTFZAUo for <sunset4@ietfa.amsl.com>; Sat, 25 Nov 2017 15:45:58 -0800 (PST)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 9EF73127F0E for <sunset4@ietf.org>; Sat, 25 Nov 2017 15:45:56 -0800 (PST)
Received: by mail-io0-x22d.google.com with SMTP id 79so25188833ioi.3 for <sunset4@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=KSQS2SZYm7by1FQBuowgHA1jVQG54RZEfL6f/iOqBBJ2IMBpgnpL7XH6K2MliM20Ct RmM29jCberWWegyT6Dm5WpYUpO1pqLj4FJD38wBLZZg4Kr8JCha1EEid8N5iiwIVDorr ShWrOqZveyiptbGBq7UHMpxpeMYaRWpBENjr1RsSkZ5XGljK3raExzqcf3IqW0iWosy7 GB/xCoVqrimNrWFZ7dAHJgmZb9w8mdBw5b6Usb6CV2hdH9VZGqM8LrpJsQiAzBVuju47 zre6b7KjNye0Ss8spYum3wK4EGgqe1VE1Z4khE5wgH3A0bOEj1D/1LJYuKeWSNpGMEtM WMBQ==
X-Gm-Message-State: AJaThX4NPYld7Tmu+B+bjv/rmYZEalsMUT/eC+uYzKsMTq5UpDevTVe4 DBzUChMmoSreBiNaEdsC4JaSxMDQumw=
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)
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/sunset4/zxJRlVbGGSyYdJmIkxKI1XYAbCY>
Subject: Re: [sunset4] [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.22
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: 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