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

Brian E Carpenter <> Thu, 08 July 2021 22:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD49C3A2489 for <>; Thu, 8 Jul 2021 15:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Status: No, score=-2.436 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, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 bTu-jK3P13Tn for <>; Thu, 8 Jul 2021 15:35:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 08F4E3A2488 for <>; Thu, 8 Jul 2021 15:35:10 -0700 (PDT)
Received: by with SMTP id f5so7931883pgv.3 for <>; Thu, 08 Jul 2021 15:35:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=JGVtxxF7cE0EoXJ656uDSqrUYTZk0ujqde/yr7mgk2Y=; b=t5GnbVEpcrf4aKDiWyUw/G4cbu4z3vWChbS8wm+Z7bLtDa+Wm8CVMdBg177YbC2lQq blLSDt4jxCuyfq1zm3OW0jBsl1LVAi0c269SE7AXfP09sHsDlAHQ1hzfIhCgDSfbBsst ao24mpyr1Eop5i7WH/fo4hDz2VRVHI9qq71JNieD+Wg3MhEvTBN/+n4bL5b4x9XBotXS 2Fll7LoGG1no/tWqN5acAqGmCy1eH7ZPFlT6zf39G6yuRmd3S6dwu2PPITHy89Zhfxah 6y4ytOwAjJqWzRMsVtIvft3SQBFwamxL7OnjgcK//UG/Dt50hv2VJx5GKJIIprlywMU4 f3qA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JGVtxxF7cE0EoXJ656uDSqrUYTZk0ujqde/yr7mgk2Y=; b=TRQaGS+OsRb64MpR8zecfQWTYXglZMDFfutmQCXF4LQ6s40ZgyPgTYFQDQJdR5MSRr 0rwB0Q+EAD5zLgX33UOD84tkVK5782mq70ogKewndcZ9R+bkr4HDj+WREZpb/zA5R+1H 3R4dABmrEGjYypytj1lwWTy+5/KR1rb1AvAxfMvjfm2iKINSCPwWOZh/GZzxbVxYxK0W +N82Cthdr2DuFGnq1DR0yuOOH5o166twlorausnDZnFJEVu7HrhahhevpBmKgvEWTb9O JnGJjt4vhW8tYkVDN3rnkljnaqdVSPdCzhpzXFEV5fIfVhIjidFL6nt8EyhnCiSVSbt+ D0ew==
X-Gm-Message-State: AOAM533uNpTZJxa2ERAGNXcR9pMbYD29u9DShNmjWo7kkDcwycVghzpm kGkI488Kx3JT5jAD0HOILWFoVfyWYqe/XA==
X-Google-Smtp-Source: ABdhPJxk0k0+tdlqriPy3/WOG/nRvMfQ+4KmwGjH72Kn7SEdjOLQRlXPXAJ/XTv7mXgh6kexnpfX4g==
X-Received: by 2002:a63:2b92:: with SMTP id r140mr33994703pgr.394.1625783709202; Thu, 08 Jul 2021 15:35:09 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by with ESMTPSA id 18sm10215414pje.22.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jul 2021 15:35:08 -0700 (PDT)
Subject: Re: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt
To: Philip Homburg <>,
References: <> <> <> <> <> <> <> <> <6771.1625578366@localhost> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Fri, 09 Jul 2021 10:35:03 +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
In-Reply-To: <>
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: Thu, 08 Jul 2021 22:35:13 -0000

On 08-Jul-21 21:53, Philip Homburg wrote:
>>> 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
> same. 
> However, in the case of link local, the opengroup specifically disallows
> the use of zone ID 0.

I think that derives from RFC4007:

'  An implementation should also support the concept of a "default" zone
   for each scope.  And, when supported, the index value zero at each
   scope SHOULD be reserved to mean "use the default zone".'

So you can't have a real zone/interface 0. As Michael said, WinSock
got this right (see my message just now). POSIX apparentlt didn't,
but it doesn't matter if you're writing code that is aware of
zone/interface indices.

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

It works today on Windows with Firefox or Chrome.
http://[fe80::2e3a:fdff:fea4:dde7]/ goes straight to my router's
web interface. Fails on Android, which I suppose inherited
Linux's brokenness on this point.

However, this is beside the point for use cases that *need*
to specify the zone/interface index. We'll make doubly sure
that is clear in the next version.