[v6ops] IPv6 link-local and URLs @ IETF119

Toerless Eckert <tte@cs.fau.de> Mon, 18 March 2024 23:28 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC5CC14CEE3 for <v6ops@ietfa.amsl.com>; Mon, 18 Mar 2024 16:28:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.66
X-Spam-Level:
X-Spam-Status: No, score=-6.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJ5HOpwKIps2 for <v6ops@ietfa.amsl.com>; Mon, 18 Mar 2024 16:28:00 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49DD8C14F617 for <v6ops@ietf.org>; Mon, 18 Mar 2024 16:27:59 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4Tz9y13s97znkPc; Tue, 19 Mar 2024 00:27:53 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4Tz9y12z01zkn8F; Tue, 19 Mar 2024 00:27:53 +0100 (CET)
Date: Tue, 19 Mar 2024 00:27:53 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: v6ops@ietf.org
Cc: brian.e.carpenter@gmail.com, dschinazi.ietf@gmail.com, superuser@gmail.com
Message-ID: <ZfjN-XGXZ599sxK3@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/8Wm1ZuBuKxW8AdDJac2yK35ovME>
Subject: [v6ops] IPv6 link-local and URLs @ IETF119
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Mar 2024 23:28:02 -0000

Dear v6ops

You may want to think going to http(bis) WG this week for the slot on
draft-schinazi-httpbis-link-local-uri-bcp. In it, he argues that rfc6874 should be
retired/made-historic, because it was never implemented in browsers.

For those who've been absent to the discussion:
  rfc6874 says URLs can represent IPv6 link-local addresses as [<ipv6addr>:<zone-name>]
    and David Drafts lays out why this is difficult for browsers
  rfc6874bis was held up (indefinitely) by Murray (ART AD) on the prmise that the
    browser vendors decided to not implement it rfc6874 nor bis.
  draft-carpenter-6man-zone-ui from Brian Carpenter was receiving various criticisms in 6MAN,
    leading to David to write his draft. Where he primarily promotes to use .local mDNS
    instead of IPv6 link local addresses

My take on this:

1. The only poor souls who should ever have to use IPv6 link-local addresses in a browser
   field are IPv6 Network Opertors (aka: here, this group), when interacting in a browser
   with a router (e.g.:web interface off a browser) and entering URLs. Everybody else
   should use names (including .local), so it is certainly a minority use-case, but
   i would hope an important minority use-case. Without network admins being able to
   troubleshoot even if/where DNS is not working, we can not provide running IPv6 networks.

2. I find Murray's DISCUSS on rfc6874bis not convincing, because scoped IPv6 link-local
   addresses in URLs are not only needed for browsers, but for any type of API in programming
   languages that use URI, such as restconf or the like. Besides, i do not see why we as
   the IETF should constrict what we deem to be necessary by the implementation problems
   of effectively very few browser cores in the industry, neglecting the broader use
   of URLs. The argument alone that the IETF should not be able to demand what's needed
   for an IPv6 network archtiecture because some application land work is hard is just
   what has continued to slow down adoption of anything IPv6 for now 2 decades.

3. That being said, i would love to see Davids draft progress to help eliminate the
   non-working of .local addresses in Browsers today (aka: create standadrd/demand for
   mDNS in browsers to work), because they actually do have a good
   amount of actual really cool IoT use-cases (not v6ops). I just don't want the work to call
   for retiring rfc6874. I just want it for rfc6874 to become only necessary where no other
   option helps.

Cheers
    Toerless