[DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa

Warren Kumari <warren@kumari.net> Wed, 04 July 2018 20:26 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E8F127148 for <dnsop@ietfa.amsl.com>; Wed, 4 Jul 2018 13:26:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 lHqJ28uGUfi9 for <dnsop@ietfa.amsl.com>; Wed, 4 Jul 2018 13:26:45 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 043CA12F295 for <dnsop@ietf.org>; Wed, 4 Jul 2018 13:26:44 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id r10-v6so4110528uao.1 for <dnsop@ietf.org>; Wed, 04 Jul 2018 13:26:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=DMLz0q9DhpqrLsnmdpKqgu1aCU0KYO/AmVpJPuruIdk=; b=U2poU3G5Io6iqgb3oF6Njn2efDkBi1WrBoJeqUE5WcAQoU3h7tcw8OfFuAy8IEGFtO dxjoo16p3AfaFl7nOOBOs3S7mATeYdrGvtAz0kMk481QKl21jgPRR7OhX6sayfs06wgR YCV9VfgynZ4Kjfzr34L82V1o42R3H683VlRjX2dsVrOi1FMykq/FDOycETCD8IkogYBo bX/1x8x66m4Bz1iL19KPdbIefY7uIP6d0YoZwwiRzrfD4jJ3bSCth/+MX+GSxk8RnxcK OLOmWysZY8b9LBt6kPGC5dGEEZh5jQfW2xxZZcGdwGwhoxlcXz6vWeqzsYlJEkqEQ6HX EQlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DMLz0q9DhpqrLsnmdpKqgu1aCU0KYO/AmVpJPuruIdk=; b=aMS3XzpVbYuDprww6qayJ1o+YXs1K7fnEniGWWH41EFSF3/L1mQJyDpP7WaPD0Y8jl kiRHrmrQZcIzcN9UP072msAlZ+xl96bxnITJaXtdGaQ94bC+qdcW8u5gLN1wCjF9r7mE y+yc0JCTDExHkiEJYPH0ppI14nNkg1zvcMT4WxHhKVJoFHcWnkYDWoey6LZGdFhouM+A Q7OUT22DhpbyL6AkJ3BN8IKTXgA6BJL3L/KaC94lSdAhj/gvphiapFUWnymhnZnrkBrn b6eBTFewOyAIdT9UIiYLsvn3FmuQWjO7SDsPCNOlkd7LaGA77Ij+3HPlFnDRsXVm9d6V 8NSg==
X-Gm-Message-State: APt69E23VV3RCNVfmDLmMlah7il/BZYjKHr+kvV87h3UR47nhkJpvqiK JdLJuIGCoqLAcSAUZ1NAKYBZk8HzJZoLache0Of8t5R4ZTc=
X-Google-Smtp-Source: AAOMgpcUzU8JXgh1vetNljyMHuIjduaDcSYGaPrGC42LhywJShNlLgFB2ophl8qtYK/bzfKkmrXMfWaifhcb95JIt+M=
X-Received: by 2002:ab0:1407:: with SMTP id b7-v6mr2010714uae.200.1530736003060; Wed, 04 Jul 2018 13:26:43 -0700 (PDT)
MIME-Version: 1.0
From: Warren Kumari <warren@kumari.net>
Date: Wed, 4 Jul 2018 16:26:06 -0400
Message-ID: <CAHw9_iK605yw--xE0NutaF=r+MfmmT2cBj9eNnSOh4Swkx=_QQ@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b52b7f0570323f94"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NYyD3k2cD9pRenjL3lwBqpEr0E0>
Subject: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jul 2018 20:26:48 -0000

Dear DNSOP,

Stuart Cheshire & David Schinazi have asked me to AD sponsor the
draft-cheshire-sudn-ipv4only-dot-arpa document
​[0]​
.

>From the document:
"The specification for how a client discovers its network's NAT64 prefix
[RFC7050] defines the special name 'ipv4only.arpa' for this purpose, but
declares it to be a non-special name in that specification Domain Name
Reservation Considerations section.
Consequently, despite the well articulated special purpose of the name,
'ipv4only.arpa' was not recorded in the Special-Use Domain Names registry
as a name with special properties.
This document formally declares the actual special properties of the name,
and adds similar declarations for the corresponding reverse mapping names."

RFC7050 ("Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis") is
worth reading before reading this. If you are mainly a DNS person,
​this may be...surprising.


When reading draft-cheshire-sudn-ipv4only-dot-arpa there are a few things
​worth
 keeping in mind:

1: This is a fairly specialized function - it is used by NAT64 clients to
discover the prefix used for synthesis ("normal" people / applications
never need to resolve this). The main people who will deal with this are
mobile / stack vendors, and NAT64 providers.
2: RFC7050 has a large amount of text around DNSSEC, what to do with
DNSSEC, etc. Note that this DNSSEC is for the FQDN of the *NAT64 device*,
not the ipv4only.arpa name.
3: Devices use this mechanism to discover the IPv6 prefix used for IPv6
address synthesis - different interfaces (e.g cellular and wifi) will have
different prefixes. This means that clients
must
​ ​
do this query using the resolver learned on / appropriate for that
interface. This is the main bit which is weird for a DNS person - the
response from the resolver for your cellular interface connected to
T-Mobile contains T-Mobile's NAT64 prefix; the response from the resolver
learnt over your wifi connection to the IETF network contains the NAT64
prefix you use on the IETF network. DNS isn't really being used here for
resolving names, rather DNS is being used a signalling mechanism (a rude
t-shirt springs to mind here).

What this draft does is:
1: record this in
​ ​
the SUDN registry; RFC7050 answered the RFC6761 questions, but didn't
actually ask the IANA to update the registry.
2: requests that the IANA make ipv4only.arpa be an insecure delegation (see
#2 above) -
​this removes some special handling and complexity.​

3: specifies that you have to use the resolvers learn on an interface for
these queries. The whole purpose of these queries is to learn the *local*
NAT64 prefix - asking a public recursive isn't going to help you here.
4: This is under .arpa (and is already in wide use) - it doesn't have the
sticky policy problems that many SUD names have.

I've
​agreed
 to AD sponsor this, but would really appreciate your review and input.
RFC7050 is deployed - this improves / clarifies things.

1: The authors have previously presented this document at DNSOP meetings -
there was some discussion, but no real interest in adopting or shouts of
outrage about it.
2: I've asked the DNSOP chairs if I can use the DNSOP list for discussion
of this
​ ​
(and they agreed)
3: This was originally a product of the (now closed) BEHAVE WG - I've
spoken with Spencer (the BEHAVE AD) who has no objections.
4: I've asked the IESG and there were no objections either.
5: As this touches .arpa I'm also asking the IAB for input.
6: Dave Thaler (who was the document shepherd for RFC7050) has kindly
agreed to be shepherd for this document too.

W

[0]: note that they asked this before the current "ipv4only.arpa's
delegation should be insecure." thread -
https://mailarchive.ietf.org/arch/msg/dnsop/zbcQhok-dCE8kh6C6KofBL1tAXY

--
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf