Re: [v6ops] IPv6 link-local and URLs @ IETF119

"Murray S. Kucherawy" <superuser@gmail.com> Tue, 19 March 2024 00:39 UTC

Return-Path: <superuser@gmail.com>
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 4FEE9C151997 for <v6ops@ietfa.amsl.com>; Mon, 18 Mar 2024 17:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 7VtwOifPIhKg for <v6ops@ietfa.amsl.com>; Mon, 18 Mar 2024 17:39:18 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 06F38C1CAF3A for <v6ops@ietf.org>; Mon, 18 Mar 2024 17:38:33 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-513dca8681bso696665e87.0 for <v6ops@ietf.org>; Mon, 18 Mar 2024 17:38:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710808711; x=1711413511; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pDdk1RyX/yE5m/svNm7VxuF8U21TaFweIxtEXuBPISo=; b=hZkbmtTLOotpCFpcLKHc4bgdLKy5/PxWMkuECkZTxjnU1zzm9quHz8mKEfxxXCwDKR ppAiAaxTVGNIJb0iJlDCCTxfLN8X4keWH5BdAmbiUaWH+kCOCQ7RcBq7pPl4NnYGovfQ 6KGfzYg40pt8JWYK33rpQAMOiZrlySPK5l3hgjFXbuBPS1U1f3EKtrvtynPGOI+4l/P+ 0nab21qLQ2SjnVWug7EshqNXKhq/0hY4K2MPDxv5mu49s4m2G/ItbYU47pgTHBjywq87 GRfojbQdsw9o+ydHVT8XLuSPLVawuKfjz2PJ6qS+YJSRMoQX3kgYHXlTo0q3YwjjRmqQ qPoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710808711; x=1711413511; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pDdk1RyX/yE5m/svNm7VxuF8U21TaFweIxtEXuBPISo=; b=WtO+LoT6T3cp/mqQ7Ag7q0a+3wlu438kHn5sWy8X6ac5QwnVyTwLZVLx0kL/v0cTYl +rq1zUIL7gQrrafVuLmtK81j2mwOnhnWs3OS1HGKWZW1XveLDSD3CsmJfrsaNjg0yMOD OpdZSdBs9sOTJ2fYhamDYdMH8pL2Ktn5/i8ojs6KxA1iKu2W0+mhOuISnc0tKIV/HbAj mNiy8GUcwdvPGIOO9QVeS4oheHKZ8Zr04U3oFTG1JdURbVKj6Xw9eOcw16h256QNPO6C COp5c3uKxx4pKqiGC6iuu20LZGXFviduz965DJhkIpFSjqiY5C/hArZ/Xx9biqmQ2Gai PlpQ==
X-Gm-Message-State: AOJu0YxheN7eXpN70Lbmw9jzn0Xb9/qPGvnGAWc9xazcmBYWtnEhcZH9 kHHbpjTG55xRr+rNLmMGGrn+Ev3LgFRQm2wp6yk5IHp4j+5LRUOVTtfN16Lo1QyCyHagSB4LgvC HQ0HM2W7KaCiyZw5lcoN99PXioEs=
X-Google-Smtp-Source: AGHT+IEOMYOtBp5PM6x5Py+qHehOPh/j7gnnqDZjLRBYALpfh4/ev9yJgMlxYIfrfOHxajfCrKBHDlw/r9xEbdzzPQo=
X-Received: by 2002:ac2:5f81:0:b0:513:c98c:7d02 with SMTP id r1-20020ac25f81000000b00513c98c7d02mr6729062lfe.6.1710808710889; Mon, 18 Mar 2024 17:38:30 -0700 (PDT)
MIME-Version: 1.0
References: <ZfjN-XGXZ599sxK3@faui48e.informatik.uni-erlangen.de>
In-Reply-To: <ZfjN-XGXZ599sxK3@faui48e.informatik.uni-erlangen.de>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Tue, 19 Mar 2024 10:38:18 +1000
Message-ID: <CAL0qLwZfRt1o4o3Z0zC+XfO1U_=uGznpmqSaDrKjf06HXAYm5w@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: v6ops@ietf.org, brian.e.carpenter@gmail.com, dschinazi.ietf@gmail.com
Content-Type: multipart/alternative; boundary="0000000000007dc9530613f8b146"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/5W5mogp2gJe5HynjVztlIIaOXBQ>
Subject: Re: [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: Tue, 19 Mar 2024 00:39:19 -0000

I may not be able to attend that session (HTTPBIS on Friday, according to
its agenda) due to other conflicts.  I'll try to get free.  However, there
are very likely to be people in that room able to represent the concern
that was raised to me, such as in the ARTART review, which motivated my
DISCUSS position.  I will reach out to them.

-MSK

On Tue, Mar 19, 2024 at 9:27 AM Toerless Eckert <tte@cs.fau.de> wrote:

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