Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 28 February 2020 18:58 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70A23A1C99 for <ietf@ietfa.amsl.com>; Fri, 28 Feb 2020 10:58:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.395
X-Spam-Level:
X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 K_qzD5alcfOU for <ietf@ietfa.amsl.com>; Fri, 28 Feb 2020 10:58:39 -0800 (PST)
Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) (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 AE4023A1C4F for <ietf@ietf.org>; Fri, 28 Feb 2020 10:58:39 -0800 (PST)
Received: by mail-ot1-f52.google.com with SMTP id z9so3579932oth.5 for <ietf@ietf.org>; Fri, 28 Feb 2020 10:58:39 -0800 (PST)
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:cc; bh=TJtZtks3oGSbsHOBUyElcfU6pjWdqgqipD8ut9ILvGQ=; b=V32bCTexdqN3JoJXRhCOmnvUDcXCtiAKy+UTWkR8YW35KTtp9UYGfQpIOWeZdrS8C+ W0R0ne7NsFEpCviOKJdhjKLxdAqB6DD4fq5seVH92AiVmdQaOVOhIO9TAI3o+NjIuHbM Bmo/6zGmPERk0ji1E94ydc27CNOSRGL19z0na28a8kUIzfD7oijn2Vq6OtLk0upk2neO YG3Rkwe4EtKDWBVMwn3VS50JLx1CBv8mgUswK7YTRH7bO2LM8C5coT1VD2xVv8YjgwYt fwr7WAuWYks+GhbMIVzj4C4hP3fx9EeZeLcbHrxD5Lj7SJBUQzhtHtBI+T1uBtIFGwoR i+uQ==
X-Gm-Message-State: APjAAAXV+nUutbBQzLawj8le03gZnNHkFrCxQSeQQzS5Xp06CDEzZBGL 0c95WTZdlF2Z99QxceVU5gQN3s1k8CgSThjP39YwnGyc
X-Google-Smtp-Source: APXvYqyU92gJd5Nw0Pv8AQH4l1tLuR+scxnsr71A6HqV0uITW7epyI9eta93UKT/MgCulJIkXNYtnyy0F8FdQ/+laxQ=
X-Received: by 2002:a05:6830:154a:: with SMTP id l10mr4527482otp.44.1582916318543; Fri, 28 Feb 2020 10:58:38 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com> <CALx6S36wN7VEi_rxLC1ETcTvkGaPhs20KhQrGWAGGTrCL5OT+g@mail.gmail.com> <CAMm+Lwg+4xMv=EKLfvmZMCgrQz31+38Fv0bYKeJ0fTB5vbXiaw@mail.gmail.com> <8d3e7b714666db00e0c05a2e06959da6@strayalpha.com> <CAMm+LwjYeSTro_TJujtRPDfVKtVMg7JbDL6A5V3Tj447c2E7nA@mail.gmail.com> <74763844-FA56-43DC-981E-E366E2C24758@strayalpha.com> <CAMm+LwjeWXUmOEzvbUhrG1H8OMqG9EhcF3TzdZBA61LnySSPqw@mail.gmail.com> <CALx6S35ko4zfCWwtR+LTKR6NdH86pVx7E-JoF0Cf4RVZOSJtkA@mail.gmail.com> <CAMm+LwjxxTQmJMPxydMGC5GByHu2qkbd_+W1and=xOMhq2RV6g@mail.gmail.com> <CALx6S34ikDKdKeEfCJQF+ZGdNorsXZHRL=8u8bXdZ1NRpaLmvA@mail.gmail.com> <ce5ac3bd-c5e3-28a5-e4ec-b7c2432783f0@network-heretics.com>
In-Reply-To: <ce5ac3bd-c5e3-28a5-e4ec-b7c2432783f0@network-heretics.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 28 Feb 2020 13:58:27 -0500
Message-ID: <CAMm+LwjpOd5AB0_HYSYA7Ma-WeBhAv_XL9KLP6jiMSGqv9a5eQ@mail.gmail.com>
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
To: Keith Moore <moore@network-heretics.com>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e04183059fa76c79"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/_JmUXcSysQW9djQaiJV4yv-3uPg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2020 18:58:46 -0000

On Fri, Feb 28, 2020 at 1:48 PM Keith Moore <moore@network-heretics.com>
wrote:

> On 2/28/20 1:12 PM, Tom Herbert wrote:
>
> > Yes, but in BSD sockets, the most common networking API, "bind" takes
> > an address and port number argument, "connect" takes and address and
> > port number argument, getsockname and getpeername return the
> > respective pairs set on a socket. So the TCP 4-tuple is very visible
> > to applications and has been for many years. If there's a better way
> > to do this that hides this and makes it easier I say go for it, but
> > please don't call this a solved problem until you've achieved
> > ubiquitous deployment and we can obsolete the sockets API since no one
> > is using it anymore.
>
> And in particular any API that presumes that DNS will be reliable and
> have the correct address for a peer, or even that it exists at all, is
> going to suffer from a huge disconnect from reality.
>
> The beautiful thing about only needing an address and a port (and often,
> having a default port) is that it doesn't need any higher-layer
> infrastructure to make it work.   This is a feature, not a bug.


OK we are officially done.

DNS is correct by definition. The resolution of example.com is not a matter
for discussion, it is what the DNS resolution service you decide to trust
returns.

I have given the application layer view of the transport layer and below. I
really don't care if you think we are doing it wrong, that is how we is
going to continue to do it.


There are of course concerns that arise from attempting to use manually
configured DNS as the basis for discovery. Manual configuration is
unreliable which is why I intend to automate the process at some point.

There should be a single point of management for service hosts in a domain.
Hosts should register/deregister the services they provide as they come up
and down. This should also coordinate with the provision of certificates.
And the DNS config should be calculated from that. So all the
DANE/SPF/TXT/SRV records should be generated automatically.

But if you config manually and people can't reach your service, that is
because your DNS is configured to say your service is down. That is not a
protocol failure.