Re: [DNSOP] Status of "let localhost be localhost"?

Stuart Cheshire <cheshire@apple.com> Wed, 09 August 2017 16:31 UTC

Return-Path: <cheshire@apple.com>
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 C3A4913240E for <dnsop@ietfa.amsl.com>; Wed, 9 Aug 2017 09:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 Y8T_SUhrr7Jg for <dnsop@ietfa.amsl.com>; Wed, 9 Aug 2017 09:31:33 -0700 (PDT)
Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885C113240C for <dnsop@ietf.org>; Wed, 9 Aug 2017 09:31:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1502296293; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=A/LG1IIsHxQ9vz7l9hIl5Zl4OVNTukgtwb3zOWmVgss=; b=S8OzzYj/czYrWA1L4ZDS9Lh0K4Om2EbEjVrbECgLk5uGSJQIYTmmaYaF+26ENwbJ U95Bf/LbGd1eUgM8+y3b3Q1VdON/v46VMthR+F5XhX0FYUPYbT3ebk74qjZ4oCAj d+AkHamybT3HJovQenDm9AFvQeMCM2ooya1ISs/NfRmn3ryuPlqptxW/KOMGRn7K 0vtFj7JAmy9X7+U9Dg9sDLNd4BMbcJSCKPQOhjd3gsAP3sV8CokCrHUyC+GZ3pTx nPRc2A7YnS1QIkz0sI7FyvzZeLouMB4FpS6Gu2HDDJ7CiudM7NOR3OdiBPM8FLcs haWJP3VPwtsbOQZeLDzUkA==;
Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id D7.76.06195.5E83B895; Wed, 9 Aug 2017 09:31:33 -0700 (PDT)
X-AuditID: 11973e16-8b5f19c000001833-c6-598b38e5a0e0
Received: from jimbu.apple.com (jimbu.apple.com [17.151.62.37]) by relay5.apple.com (Apple SCV relay) with SMTP id D9.49.10385.5E83B895; Wed, 9 Aug 2017 09:31:33 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"
Received: from da0602a-dhcp180.apple.com ([17.226.23.180]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OUF00B69F8K0600@jimbu.apple.com>; Wed, 09 Aug 2017 09:31:33 -0700 (PDT)
Sender: cheshire@apple.com
From: Stuart Cheshire <cheshire@apple.com>
In-reply-to: <20170802180221.n7ezh5yzr5cuxklz@mycre.ws>
Date: Wed, 09 Aug 2017 09:31:33 -0700
Cc: Robert Edmonds <edmonds@mycre.ws>, Ted Lemon <mellon@fugue.com>, Richard Barnes <rlb@ipv.sx>, Mike West <mkwst@google.com>, william manning <chinese.apricot@gmail.com>, Jacob Hoffman-Andrews <jsha@eff.org>
Content-transfer-encoding: quoted-printable
Message-id: <820AEB88-C38C-4547-8F42-3C7C7E3D7ACC@apple.com>
References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <CAKXHy=ctB=LZkX9j=8-Jy0NkTAs2tAesa4gmFhfp94O5=9U4TA@mail.gmail.com> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <CACfw2hiX7U74n9+defcYiD7jLKZeLhtLM6WP5YM_WuAoA8ecYQ@mail.gmail.com> <CAL02cgRg6k7=b7berKr9J+9aL8PTS81nJ_yXQO8QTYqgiqXSbg@mail.gmail.com> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> <CAL02cgQ2z9Fze-Q2QWQ=+PHJEO_S3bTaq1fPJ6XSEwFUQ=ftvw@mail.gmail.com> <CAKXHy=eV0OBW+S308rdiHZ523foOgxYNB3i07RkeFJiTjMYQEQ@mail.gmail.com> <D9568E51-3C48-4BA3-9797-3F7756E857C9@fugue.com> <20170802180221.n7ezh5yzr5cuxklz@mycre.ws>
To: dnsop <dnsop@ietf.org>
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUi2FAYofvUojvSoHeDkMXsHQ1sFnffXGax WL7+L7vFzCs/2SzerDnCZHF21Wdmi6l9tg7sHu8+PWf1aLqwjN1j56y77B4LNpV6LFnyk8lj 8sZZLB6Lbh1nDGCP4rJJSc3JLEst0rdL4Mo4dHszc8EK4Yo9P9waGD/ydzFyckgImEi8vTmT vYuRi0NIYDWTRNuJ78wwidnbOtlBbCGBDYwS7+8kgti8AoISPybfY+li5OBgFlCXmDIlF6K3 kUmiefsyVpAaYQEpiVcrPzND2DYSbd0XmUBsNgEtiRefr7CB2JwC5hIrX2wCq2ERUJX4dfU6 M8ggZoHrjBLf2zvAGpgFtCWevLvACrHYRmLevj4miG0PWSQ+XngN1i0CtO3ZrEcsEFfLStya fQlskoTAInaJv7/Xs01gFJ6F5PJZCJfPQrJjASPzKkah3MTMHN3MPHO9xIKCnFS95PzcTYyg 2JluJ7aD8eEqq0OMAhyMSjy8CaLdkUKsiWXFlbmHGKU5WJTEefuyuiKFBNITS1KzU1MLUovi i0pzUosPMTJxcEo1MLI67Y3Luss7eYOQ3GvfmilcR79xXKly4tPcKymzapvHKfuEQhGbVW+z tLYt6jGIDrU3mJK5S6pml+5djcBWobl653TufDjuyTr92R6VNbdDl54KecHO5RrxdDPTwQ2T W9Vvbs3JMBE8U/O2+9372ADfz8kT3YwPeqctZnDmPnF54YG2KNd7C5RYijMSDbWYi4oTAfTS b3d+AgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUiON1OVfepRXekwdKzfBazdzSwWdx9c5nF Yvn6v+wWM6/8ZLN4s+YIk8XZVZ+ZLab22Tqwe7z79JzVo+nCMnaPnbPusnss2FTqsWTJTyaP yRtnsXgsunWcMYA9ytAmLb+oPLEoRaEouaDEVqk4IzElvzze0tjI1CGxoCAnVS85P1dJ384m JTUnsyy1SN8uwTDj0O3NzAUrhCv2/HBrYPzI38XIySEhYCIxe1snO4gtJLCBUeL9nUQQm1dA UOLH5HssXYwcHMwC6hJTpuR2MXIBlTQySTRvX8YKUiMsICXxauVnZgjbRqKt+yITiM0moCXx 4vMVNhCbU8BcYuWLTWA1LAKqEr+uXmcGGcQscJ1R4nt7B1gDs4C2xJN3F1ghFttIzNvXxwSx 7SGLxMcLr8G6RYC2PZv1iAXialmJW7MvMU9gFJiF5NhZCMfOQjJ2ASPzKkaBotScxEpTPXjg bGIERU5DYcQOxv/LrA4xCnAwKvHwcgh3RwqxJpYVV+YeYpTgYFYS4b1sBhTiTUmsrEotyo8v Ks1JLT7E6AP0zURmKdHkfGBU55XEGxpbGFuaWBgYmFiameAQVhLn3b+lI1JIID2xJDU7NbUg tQhmHBMHp1QD4xQ9lt/yG24vYPsyKTbvydfaQ3fL7Q5t2Xyyb+OppOaILy8Xm6W6R3yK+R1k +/+b9kLf3Q2NDR/iNidqB+7ddWfj6YlTfd2M3xw3cb4b4Chy1v7FClnbDRI/zPczzghSNr77 Z+6crTss/ia+zah4vffWhieZkWd0JzLwJ7wP/MiftbvosK/KI1slFmAyMtRiLipOBAD1rRQO yQIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZUC2YFuhyUdMkxEAncNGtEmDHtY>
Subject: Re: [DNSOP] Status of "let localhost be localhost"?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 09 Aug 2017 16:31:35 -0000

I’m puzzled by much of this discussion.

We want a way for an application to indicate that it wants a loopback connection to another port on the local host.

People widely use “localhost” for this.

But other people argue that a mere RFC can’t guarantee that a host doesn’t violate the assumption that “localhost” means “local host”.

So, to indicate that it wants a loopback connection to another port on the local host, an application needs to use “127.0.0.1”. By, by the same logic, a mere RFC can’t guarantee that a host doesn’t violate the assumption that “127.0.0.1” means loopback. Who knows what a host OS will do with that address, if it does not follow the relevant RFCs? [*]

Forgive me, I forgot, “127.0.0.1” is obsolete. I should have written, “::1”. I’ll try again:

So, to indicate that it wants a loopback connection to another port on the local host, an application needs to use “::1”. By, by the same logic, a mere RFC can’t guarantee that a host doesn’t violate the assumption that “::1” means loopback. Who knows what a host OS will do with that address, if it does not follow the relevant RFCs?

So, “127.0.0.1” and “::1” are not suitable, both because a host OS might choose not to follow the relevant RFCs, and more importantly, they’re both address-family-specific.

What we really need is some symbolic way for an application to indicate unambiguously that it wants a loopback connection to another port on the local host.

We should reserve a specific string and define that it has this meaning. Some operating systems will follow the specification, and will work as expected, and others will not, which is a bug. Don’t use those products.

A nice mnemonic string would be good. Something memorable, which conveys the meaning, “local host”.

I suggest “localhost”.

Stuart Cheshire

[*] If you think it’s stupid to suggest a host might not treat “127.0.0.1” as meaning loopback, why is that any more stupid than suggesting that a host might not treat “localhost” as meaning loopback? Both are just as arbitrary.