[IPv6]Re: Alternative URL compatible notation for IPv6 addresses with Zone ID – addition to draft-carpenter-6man-zone-ui?

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 10 June 2024 20:34 UTC

Message-ID: <d59c1416-ab9a-4164-8340-b5eaec862211@gmail.com>
Date: Tue, 11 Jun 2024 08:34:38 +1200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: ipv6@ietf.org
References: <A0557154-7A0F-44C8-B423-04E336530438@tiesel.net>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <A0557154-7A0F-44C8-B423-04E336530438@tiesel.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Message-ID-Hash: RFKTZ5MPKJ7IZL6HHZON2XCDWXDVNSXP
Precedence: list
Subject: [IPv6]Re: Alternative URL compatible notation for IPv6 addresses with Zone ID – addition to draft-carpenter-6man-zone-ui?
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/024vYELfze31uvfVirC8Lah0Nv8>

Philipp,

I'm going to answer your last question first:

> Any opinions whether it makes sense as an addition to draft-carpenter-6man-zone-ui or there is interest putting it in a separate draft?

I think it would be out of place in the current draft, whihc in effect address all types of app *except* browsers. So, a separate draft, if you want. (Or, conceivably, merge with draft-schinazi-httpbis-link-local-uri-bcp.)

On 11-Jun-24 01:55, Philipp S. Tiesel wrote:
> Hi,
> 
> as a lot of discussions about rfc6874bis centered about the fundamental
> incompatibility of the % notation and URLs, why not define a URL compatible
> notation that does not break the same origin policy?
> 
> Basic idea:
> - Take IPv6 address in rfc5952 format
> - replace “:” with “-“
> - prepend interface name (separated by “.”)
> - append a well-known domain like .ll-ip6.arpa.
> 
> So fe80::23:42 on en5 becomes en5.fe80--23-42.ll-ip6.arpa.
> 
> Why all that hassle?
> - It is completely implementable within the hosts' resolver stack.

That could also be done with a bogus top level domain or even using .local

> - It is does not require changes to the browsers’ trust logic

Are you sure about that? Remember that the resolver in this case (exactly as for mDNS) must return an (address, interface_number) 2-tuple. I don't know when the browsers apply their CORS checking, but I do know for sure that on Linux, at least one browser (Chrome) fails to pass that interface_number to the socket API.

(I know that from testing a proof-of-concept of draft-schinazi-httpbis-link-local-uri-bcp.)

> - It looks like a wildcard DNS record to existing HTTP servers.

Which most existing servers will object too (as they already object to a raw IPv6 address, of course).

Regards
     Brian
> 
> Any opinions whether it makes sense as an addition to draft-carpenter-6man-zone-ui or there is interest putting it in a separate draft?
> 
> AVE!
>     Philipp S. Tiesel
> 
> --
> Philipp S. Tiesel
> https://philipp.tiesel.net/
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests:
> --------------------------------------------------------------------

[IPv6]Alternative URL compatible notation for IPv… Philipp S. Tiesel
[IPv6]Re: Alternative URL compatible notation for… Brian E Carpenter