Reopening RFC6874?

Brian E Carpenter <> Wed, 16 June 2021 23:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF6873A0D46 for <>; Wed, 16 Jun 2021 16:58:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J2u9hjXKwYkl for <>; Wed, 16 Jun 2021 16:58:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CD4F3A0D45 for <>; Wed, 16 Jun 2021 16:58:30 -0700 (PDT)
Received: by with SMTP id 11so1966133plk.12 for <>; Wed, 16 Jun 2021 16:58:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=g4CUGDdU8Q739Az1uOmeNAdUEoEQKxDB96N+ayxn39k=; b=Z85Ge+It+nBpo+75XpHwVh7XTrshmQtIPC+oxa4l8GUw9tJMIBcd4eNIVd9Ux5rFMF jeUP30VRW/ZZ2YeT/vAVJ+UR2DHAYjIrzQyt2C2Ij8NMPcXjsSpS6myf2PfiCOZUWAdL aFXiWE+GzSDdpdDqpzZGl7m1TgPHydMrmbrjtycs3MmmrFlQuqQje8Osrhh3Ao7scYbf wu+U1/3qjefSYAtqJtB/0k3RSzOOGkj+JFrK7US1deFpvO9QOGJxoBnLNPHuFnVq9ngU gY/y5Tuk0+f69bbj4ezm76jpJ4UyEG/VE4VqFZHvJgUcY+dtq8tx8MjVjvsXOYIFeaGB bamQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=g4CUGDdU8Q739Az1uOmeNAdUEoEQKxDB96N+ayxn39k=; b=s6Lm/SyqOdb1CyPEaju/VA2DQNqECF2+bp9hzvEBhPe/PfXZc3eubyt7ha1BctM+os 1LW0AKZDT2L21kPX54Rj1YzaWSjk2SttUKl9FPjkgcda0x4OzgqpHpOTH0TCCMrNvyVM h0cbh+y2tJ7iKRWm1qhS4tsudHXjCkS4hOTvYWE7sGTecRBADF/D+cSsDI6ukMkLMaz9 4DFU6oHWrzmrZCCk8cdLv3MjejVc376gEoe8eLgjGj/PuMJtLhU+rZC27tau8Jw83OZ1 nCAUKdesIjImbwFs1wG8S/2jORH3qkwv6OGVEY6rGRqG9dFL59sFQLDOWtEfygzXxgIL /apw==
X-Gm-Message-State: AOAM532A0di6rpM3QmoNmB6b1BeFyzAviiIuU0rkS2jrBNC841Izv+90 NLMHC6FVFseA2m6NZ+zxk8U=
X-Google-Smtp-Source: ABdhPJxsugKoq7CG2+tR/ASRpz+vGTbHaeZn7sTCLnO2KKzA1WWNpMD5v1MtO0pqEpSWHB4kP84BVA==
X-Received: by 2002:a17:902:ea0d:b029:fb:973:956a with SMTP id s13-20020a170902ea0db02900fb0973956amr1880308plg.79.1623887909319; Wed, 16 Jun 2021 16:58:29 -0700 (PDT)
Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by with ESMTPSA id q9sm3084221pjd.9.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 16:58:28 -0700 (PDT)
To: 6man <>
Cc:, Stuart Cheshire <>
From: Brian E Carpenter <>
Subject: Reopening RFC6874?
Message-ID: <>
Date: Thu, 17 Jun 2021 11:58:25 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Jun 2021 23:58:36 -0000


It is probably necessary to re-open RFC6874 "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers."

Here's the problem. Web browsers do not correctly support Link Local literal addresses, because they cannot parse the zone identifier (aka the interface identifier).

There are of course no "average user" use cases for this, but there are several technical use cases. Rather than trying to summarise them, I refer you to the Firefox bug thread about this, which has been open for 10 years:
Officially it's status is WONTFIX, but every year or two discussion restarts.

There's also an issue at WHATWG:

My conclusion from the latest round of discussion of those two threads is that if we don't update RFC6874, nothing will change. So I propose that we do update RFC6874. As far as I can tell, the main issue is as follows:

The security considerations say:

>    An HTTP client, proxy, or other intermediary MUST remove any ZoneID
>    attached to an outgoing URI, as it has only local significance at the
>    sending host.

There is also non-normative text saying:

>    However,
>    URIs including a ZoneID have no meaning outside the originating node.
>    It would therefore be highly desirable for a browser to remove the
>    ZoneID from a URI before including that URI in an HTTP request.

As I understand it, those requirements are considered unreasonable and
too hard to code by browser implementors. Also, there is a use case
that Andrew Cardy can describe better than me where the deletion of the
Zone ID breaks a higher-level protocol. (CUPS printing; Michael Sweet
raised the issue on this list 8 years ago.)

Would the WG be interested in taking up this work? I think most of it
would consist of using the "delete" key on RFC6874.

   Brian Carpenter