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

Ted Lemon <mellon@fugue.com> Wed, 02 August 2017 13:17 UTC

Return-Path: <mellon@fugue.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 B9A7E126B7E for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 06:17:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.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 V4l3DzYz0lcW for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 06:17:36 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 2EA811320AF for <dnsop@ietf.org>; Wed, 2 Aug 2017 06:17:36 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id a77so26355635qkb.0 for <dnsop@ietf.org>; Wed, 02 Aug 2017 06:17:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=b2bjcT/YBspJ5PUveymnQgJPGzS4/f2e8kSDy9RYAC8=; b=pnhzP4kjCeqK4vDqhvC5JlMy1ZcaUxrTtHvXaDF4pymxHjOyMaIWL2iNHFkBKXVzAi gz3wSRnYGrFrI2mzEfzzJqcxBe9dql8mMhyScwHUFPw404ZBLM2SxvHaycDqhX0XJ1M8 i6ajm0HcdljhUJSznZVyKv8rbCk3ebuRkjeYZRX0rcwmC8lcI9+rpa8ZS2VpnQpKb42/ vlzdkvwWR+u7TzPTjhU/W79oD2Np5/Qh66AThZE490ZgDI552oVIsbcyLVnZHUvlA1XN Ugi19Vm64uylbOXPufila8oAEELkbA2UxbPsdHfu77vkN9NlRUqxEjsSJr429eDfUILb rXgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=b2bjcT/YBspJ5PUveymnQgJPGzS4/f2e8kSDy9RYAC8=; b=GgAy/DovTx4CveXDHaGFcSKkVPE81x9Stg+bioXJ56m5g9UNRQ0Kn53VtMvaJ97/lJ Xz/rCO6yD9fJJ97JFXsWe+FBF0ZVawWkriHkE+iDbq0I8ETJAC+6Yvez/3I9MGKUg/jp VPJqev7Bfm8dN1etWZHg84ns5rl9M8tNyTxvLm1N0HSLdV42eqlYDGBPO+oJu0LbOMyl MuNxaXDv9khOKpf3CQ3WEERz2LPUAUmKZbC8LsnkqaXnFiJcUdn1TobvEfmwG/ReT2k2 lboNtWRjk9IVefKlVqWiK0Jdsc/kF4U/dmQgMjgv4UvbfymeVj6ZCKjhR3C6oDiHaSmn vUQA==
X-Gm-Message-State: AIVw112FCZ88ed0s4C5a5STsIdu0xAhBc6jIBLR2XLBnpnTm6d6ebzpg 1jTCME8mZbe9iA9k
X-Received: by 10.55.33.195 with SMTP id f64mr31542068qki.208.1501679855297; Wed, 02 Aug 2017 06:17:35 -0700 (PDT)
Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 58sm25302050qtu.88.2017.08.02.06.17.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 06:17:34 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <D9568E51-3C48-4BA3-9797-3F7756E857C9@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C886CD2B-B7E6-4FDA-B608-26047921BF62"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 2 Aug 2017 09:17:26 -0400
In-Reply-To: <CAKXHy=eV0OBW+S308rdiHZ523foOgxYNB3i07RkeFJiTjMYQEQ@mail.gmail.com>
Cc: Richard Barnes <rlb@ipv.sx>, dnsop <dnsop@ietf.org>, Jacob Hoffman-Andrews <jsha@eff.org>, william manning <chinese.apricot@gmail.com>
To: Mike West <mkwst@google.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>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/haPGJoezduhtgarWWXQJKP4FIDM>
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, 02 Aug 2017 13:17:38 -0000

On Aug 2, 2017, at 9:07 AM, Mike West <mkwst@google.com> wrote:
> I was typing basically this when Richard's message came in. So I'll simply add that Problem 8 in https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-09#section-5 <https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-09#section-5> suggests that we already know that this kind of hard-coding will cause issues for future migrations. Just as we'd like to discourage folks from hard-coding `127.0.0.1` to be certain that they're talking to the loopback interface, it seems reasonable to discourage folks from hard-coding `::1`.

I don't think I agree.   It's entirely possible that at some future time, [::1] will have symbolic meaning but will not refer to a transport protocol destination address.   But we are arguing that "localhost" should be treated specially by every piece of software that looks at it, when its default meaning is "look up localhost in the DNS and connect to one of the addresses that you get in response."   The default meaning of "[::1]" is "connect to the local host."   There isn't even an implicit indirection there.

So if you have a host running IPv10, where [::1] doesn't have an explicit meaning, one of two things will be the case: either the piece of software looking at [::1] will do an explicit transformation from [::1] to the right thing, or it won't.   If it does, things just work.   If it doesn't, they fail safe: the connection fails.   With localhost, if the software does the wrong thing, it does not fail safe.