[BEHAVE] Fwd: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa

Warren Kumari <warren@kumari.net> Sun, 15 July 2018 17:21 UTC

Return-Path: <warren@kumari.net>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9DC130E4B for <behave@ietfa.amsl.com>; Sun, 15 Jul 2018 10:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 uHhsvvL2IAR1 for <behave@ietfa.amsl.com>; Sun, 15 Jul 2018 10:21:16 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 B6EA51294D0 for <behave@ietf.org>; Sun, 15 Jul 2018 10:21:15 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id t6-v6so29600602wrn.7 for <behave@ietf.org>; Sun, 15 Jul 2018 10:21:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=CcvhFNQ6KXZlZtK8fejmW/AHhbEa/HiXG3+Sf+1auNc=; b=aRAlpzudvuRVOHFhqJFky/0pJ9bGJPxVnuRQQaPmkRLd4qT9MY2hqd9AEypxIzd25d +mYiFwFI2JyR1TIXvxnRI8THW/BhbkzizwR9cLT1MSV3kVgq7aAhza6FIhJeCAMHpKhf uvCK+5+1rGfuZLArnUaeZijdbQPmkzLfBIsxaTdDMFqQWRfN9wGbCZkj0yeAtTkEmSjw P7LaCJ8chBg+827ZLFyY3BeBkcrhzpmd5qS+1ZkZJO17ObqI2ps1DnS/Wj3ssqssnAlf r6vLOjn5atm1kKFbbARUr0uspdh1PpOHMLoMteYZzXMdbXpTDnUt0s0zYh2uG47UGqna NQwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=CcvhFNQ6KXZlZtK8fejmW/AHhbEa/HiXG3+Sf+1auNc=; b=Z3J1ab8bgOPxHSCOvug7xHfnuusdP1rWTmOxZeJgE+9crEynAmDqXTkF2w0k4T6da2 dR9e9yobjh/Zcsx6p0V9MOhdFTvAFO12BnP2zQEJyCrjPHYo2bBlwS+KYJ0lv/qz5JV6 CD7rEswM6eBqKqWUM4YGKsomB5x2+97wulufqCkFTBweH687LxjmjdWSzgI++MxQ50kP LAJfLeosHB3p5bxu9jcXOElCjXSXwD8ct/pIIn26G135CGUdZ+c2nP8eecKjtqHdSIdS YY9ReoecF0V3dCGKn+cmt4SbvTh7TwyEygfyJOf32SDd7SYrqSgtR+R2yKkCy4WK77ti ut+Q==
X-Gm-Message-State: AOUpUlESUKAHDMNgn4YThub9DDougUYEGpXd05m+A3jTvPoSlmoVfijg n4kgXd0Sd6fA5v8dnlw9DM/VbrCertUGArh6Y5sG5MBZ
X-Google-Smtp-Source: AAOMgpckChG1SJqviA4mJDRmzAZ0y+45jaYNPS8x5oltiU2Gy0l1crfxx1vi/6rbLJ25yg0OpsaZybNJ7s1EjSI5+Hc=
X-Received: by 2002:adf:ba12:: with SMTP id o18-v6mr10531462wrg.249.1531675273620; Sun, 15 Jul 2018 10:21:13 -0700 (PDT)
MIME-Version: 1.0
References: <CAHw9_iK605yw--xE0NutaF=r+MfmmT2cBj9eNnSOh4Swkx=_QQ@mail.gmail.com>
In-Reply-To: <CAHw9_iK605yw--xE0NutaF=r+MfmmT2cBj9eNnSOh4Swkx=_QQ@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Sun, 15 Jul 2018 13:20:37 -0400
Message-ID: <CAHw9_i+UPqExtwJPFSbWsxn41v52kUavq=VOxJ=R6TGCbHm8Gg@mail.gmail.com>
To: behave@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/rhj1A7YJbavFJxF72aTBFsJslKQ>
Subject: [BEHAVE] Fwd: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Jul 2018 17:21:20 -0000

Dear BEHAVE,

I sent this to DNSOP a while back, but didn't think to send it to
behave as well - sorry.

Please see below, and if you have comments, please comment in the
DNSOP list (so that we don't have overlapping discussions)...


Thank you!
W


---------- Forwarded message ---------
From: Warren Kumari <warren@kumari.net>;
Date: Wed, Jul 4, 2018 at 4:26 PM
Subject: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa
To: dnsop <dnsop@ietf.org>;


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


--
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