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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 19 March 2024 21:36 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898C9C14F69D; Tue, 19 Mar 2024 14:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.197
X-Spam-Level:
X-Spam-Status: No, score=-1.197 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, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 JSfdikI9DCYU; Tue, 19 Mar 2024 14:36:19 -0700 (PDT)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 C491DC14F616; Tue, 19 Mar 2024 14:36:19 -0700 (PDT)
Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-6e6adc557b6so5633030b3a.2; Tue, 19 Mar 2024 14:36:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710884179; x=1711488979; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=fQLaClRCV9Kk4N/Csj19Lrtiz5/x7yKPpVt/kmo8Rx4=; b=ME3c47ben+ShhmQROB7ULeRf49w+yEWzdmDgUk5oBs/3BzglWOrPAuc/uWZ/3j+blO yDDV6AqjT4j5PDJKPmMk9YE3ny3lIk3Sh0mUJi5E+icYyxqX+P5PWVTGkWJ9TRx3rRAI +QQlNZ3hwI6KPX4vaPjgv92QsDsLd7c1PBGamwCu3rbY5nZwQJ0ZryM61kg2UdjRWsWs uA9kamZuaWCwOV8ND1PzysOhlzy5l67EsxMDiu0/x9mLE1DljqpD6jF3/R0PbPDIsSXX +4Ha6cOaBlnIOyywSdgoYWzelvSoJ+XCyRL70AADG2uH7IUifNdR+gQbULeqlFXF5kms IVQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710884179; x=1711488979; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fQLaClRCV9Kk4N/Csj19Lrtiz5/x7yKPpVt/kmo8Rx4=; b=cMu5PeWb+ikbtLGcJ6PQrQ+gRbxUOShTae88m0FNgk6kxZLNkhQihmze1P98vqExqd IMhv0yZZ68NiDNMtGeikSqWCygIkTxymoI6QgaLlQJnlYh8PmhWGzFTeqiVrYcqyd37S 8AUKjacdjhZmwKx7h/R2Bq5U0H36tpyocX6b88w1UrcmE/vhBkm6aOdm5ZKYPKHkaj3g itXqHrS+w7ueE/QfpVp73AWHG8kQQuFD6cDQg16bHQeIMcucNaAxDf3sWu9ZrKG9+WSI lF0GlSPdKSyxnxr9VTjS4KrqNS0UcfghYatVAxImxPJ2fAA8dvSWI1KOCds5xjM9pTH9 Upiw==
X-Forwarded-Encrypted: i=1; AJvYcCX5g/FX9ec3QAYMK9EYWATcxctYhgZA3OqmXkMadRcyIMzQWRv+4V/A44qYjm15WIQLTVwONyVIEF5WWGiUsoznJ819WmWNjL4ZfInvKw==
X-Gm-Message-State: AOJu0Yw412fuCc3kpA60X+nPlbk9QV1FXQ8UW5JAr/WYFMmlLRdFM2x5 sGeQpkZ5b1btSVgB9hrnCcvmehcGs62fiFV8tsiFh3qf2YrCEXld
X-Google-Smtp-Source: AGHT+IHdtYvvBWzgrpXC2yEktCLAhZdhLNpz4BuZkigciOP4pKUpNjWs1yIjdNQUIC62ObKjlG6PlQ==
X-Received: by 2002:a05:6a20:2591:b0:1a3:6b99:33a6 with SMTP id k17-20020a056a20259100b001a36b9933a6mr5786832pzd.18.1710884178848; Tue, 19 Mar 2024 14:36:18 -0700 (PDT)
Received: from ?IPV6:2404:4400:541d:a600:44b7:2c2e:2bc6:8707? ([2404:4400:541d:a600:44b7:2c2e:2bc6:8707]) by smtp.gmail.com with ESMTPSA id p10-20020a056a000a0a00b006e6b45debe8sm10103190pfh.78.2024.03.19.14.36.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Mar 2024 14:36:18 -0700 (PDT)
Message-ID: <e853179d-6b9e-3670-ba62-1db0e6d35320@gmail.com>
Date: Wed, 20 Mar 2024 10:36:13 +1300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Toerless Eckert <tte@cs.fau.de>, ipv6@ietf.org
Cc: Lorenzo Colitti <lorenzo@google.com>, "Murray S. Kucherawy" <superuser@gmail.com>, Erik Kline <ek.ietf@gmail.com>, v6ops@ietf.org
References: <ZfjN-XGXZ599sxK3@faui48e.informatik.uni-erlangen.de> <CAL0qLwZfRt1o4o3Z0zC+XfO1U_=uGznpmqSaDrKjf06HXAYm5w@mail.gmail.com> <CAL0qLwZ2WELSG868Hcc=dYH_zcm+ecEbavt8Oq7GSTT8st0hWg@mail.gmail.com> <e9387f40-408a-15fb-3f2c-afaa05c5a7ce@gmail.com> <CAKD1Yr09GvBdHFqPAujGaJ-j4cLYX2yMLhMDB4b_GfEM-1SNYw@mail.gmail.com> <a530f09a-f7ed-5fb0-aea7-2eec4f56cc6f@gmail.com> <ZfoAZluV-bM02F4q@faui48e.informatik.uni-erlangen.de>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <ZfoAZluV-bM02F4q@faui48e.informatik.uni-erlangen.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/pliLor7A3Fy-I7uB84kKzCOnD30>
Subject: Re: [IPv6] [v6ops] IPv6 link-local and URLs @ IETF119
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Mar 2024 21:36:23 -0000

On 20-Mar-24 10:15, Toerless Eckert wrote:
> On Tue, Mar 19, 2024 at 08:24:18PM +1300, Brian E Carpenter wrote:
>> On 19-Mar-24 19:00, Lorenzo Colitti wrote:
>>> FWIW I don't think it makes sense to put scoped addresses in URLs, because the scope portion cannot be known in advance.
>>
>> As far as I'm concerned, we are no longer discussing draft-ietf-6man-rfc6874bis.
> 
> Was there any ask to the 6MAN WG and decision by the WG to drop the work ?

I am sure we'll discuss that tomorrow.

Personally, I will do no more work on draft-ietf-6man-rfc6874bis. If the WG wants to continue with the draft, I will ask to be removed as an author. The XML file is in the tracker (there is no kramdown).

     Brian

> 
> Cheers
>      Toerless
> 
>>     Brian
>>
>>>
>>> So it basically requires that the user who types in the URL to somehow figure out what interface needs to be used and what its scope ID is. The set of users that is capable of doing this is vanishingly small. I certainly don't - while I use linux which uses the interface name, I never remember that my wlan interface is called wlp0s20f3. My ethernet interface name is even worse, it's enxx<mac address>. I also don't necessarily know whether the device is on wifi or ethernet.
>>>
>>> There's a simple solution to this problem: if the user types in a link-local address the browser should *open the connection on the default network interface*, just like what it would do with any other connection. This will address the common "I need to configure my home router" use case. It wouldn't address the "I need to configure a home router on this other interface that isn't the default interface", but I think that is super rare.
>>>
>>> On Tue, Mar 19, 2024 at 11:21 AM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
>>>
>>>      Murray, Erik,
>>>
>>>      Please read both draft-schinazi-httpbis-link-local-uri-bcp and draft-carpenter-6man-zone-ui carefully. Or look at some relevant slides, especially slide 5 in the first talk:
>>>
>>>      6man: https://datatracker.ietf.org/meeting/119/materials/slides-119-6man-entering-ipv6-zone-identifiers-into-user-interfaces <https://datatracker.ietf.org/meeting/119/materials/slides-119-6man-entering-ipv6-zone-identifiers-into-user-interfaces>
>>>
>>>      iepg: https://datatracker.ietf.org/meeting/119/materials/slides-119-iepg-sessa-make-firefox-visit-an-ipv6-link-local-address <https://datatracker.ietf.org/meeting/119/materials/slides-119-iepg-sessa-make-firefox-visit-an-ipv6-link-local-address>
>>>
>>>      (which is proof of concept for both drafts)
>>>
>>>      Regards
>>>           Brian Carpenter
>>>
>>>      On 19-Mar-24 13:39, Murray S. Kucherawy wrote:
>>>       > Looping in Erik, the AD for the older of the two documents we're talking about here.
>>>       >
>>>       > On Tue, Mar 19, 2024 at 10:38 AM Murray S. Kucherawy <superuser@gmail.com <mailto:superuser@gmail.com> <mailto:superuser@gmail.com <mailto:superuser@gmail.com>>> wrote:
>>>       >
>>>       >     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 <mailto:tte@cs.fau.de> <mailto:tte@cs.fau.de <mailto: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
>>>       >
>>>      _______________________________________________
>>>      v6ops mailing list
>>>      v6ops@ietf.org <mailto:v6ops@ietf.org>
>>>      https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>>>
>