Re: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt

Philip Homburg <> Thu, 08 July 2021 09:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 761753A1B13 for <>; Thu, 8 Jul 2021 02:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SPF_HELO_TEMPERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L7z04tDAEMfE for <>; Thu, 8 Jul 2021 02:53:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A2E83A1B0E for <>; Thu, 8 Jul 2021 02:53:24 -0700 (PDT)
Received: from (localhost [::ffff:]) by with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #158) id m1m1Qie-0000FLC; Thu, 8 Jul 2021 11:53:20 +0200
Message-Id: <>
Subject: Re: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt
From: Philip Homburg <>
References: <> <> <> <> <> <> <> <> <6771.1625578366@localhost> <> <>
In-reply-to: Your message of "Thu, 8 Jul 2021 09:18:39 +1200 ." <>
Date: Thu, 08 Jul 2021 11:53:20 +0200
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: Thu, 08 Jul 2021 09:53:41 -0000

>> Instead of doing this, maybe we should pick a new character in an update of
>> RFC 4007 and deprecate '%' as a mistake?
>Even 9 years ago the WG concluded that '%' was too engrained in code and
>actual practice to deprecate it. Many libraries that handle IPv6 addresses
>support '%' and that means that innumerable pieces of software would be
>impacted, so deprecation seems impractical.
>If this was a mistake, it was made in 2005 when we approved RFC4007.

If we started changing 9 years ago, we would be done now. What I see is
that addresses with zone IDs are used rarely and locally. And lots of software
doen't even know how to deal with it. 

If we now introduce, for example, '-' in addition to '%' and require parsers
to accept both, but canonical output remains at '%' for a while then we
will have a sensible input format for URLs.

Keeping '%' as the only option means that URLs will remain a mess.

>> Aternatively, if we make fe80::ABCD%0 a valid address in the socket API
>I think you'll find that it already is. I use the netifaces module in Python
>and it returns things like [{'addr': '00:ff:19:f7:7d:9a'}], 23: [{'addr': 'fe8
>0::216a:f0d3:2303:3d1%6', 'netmask': 'ffff:ffff:ffff:ffff::/64', 'broadcast': 
>'fe80::ffff:ffff:ffff:ffff%6'}]. It's a bit obscure, though. Also (before
>Python 3.7) socket.getaddrinfo(socket.gethostname(),0) on Windows would
>return fe80::216a:f0d3:2303:3d1%6, but somebody changed that behaviour.

I guess I was too terse.

>From a socket API point of view writing an IPv6 address without zone ID is
equivalent to using zone ID 0. So 2001:db8::1 and 2001:db8::1%0 are the

However, in the case of link local, the opengroup specifically disallows
the use of zone ID 0.

If we would introduce a command like
'set-default-interface-for-link-local eth0'
that makes zone ID 0 available, then a URL like http://[fe80::abcd]/
could work. No change needed to browsers, no complex syntax.