Re: on-link and off-link addresses, side discussion

Simon Hobson <> Fri, 09 July 2021 15:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 570633A252F for <>; Fri, 9 Jul 2021 08:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y3RH-2pzD7mq for <>; Fri, 9 Jul 2021 08:36:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B11013A252E for <>; Fri, 9 Jul 2021 08:36:27 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at
Received: from [] (unknown []) by (Postfix) with ESMTPSA id F18FA1BC66 for <>; Fri, 9 Jul 2021 15:36:16 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: on-link and off-link addresses, side discussion
From: Simon Hobson <>
In-Reply-To: <>
Date: Fri, 09 Jul 2021 16:36:16 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: 6man <>
X-Mailer: Apple Mail (2.2104)
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: Fri, 09 Jul 2021 15:36:38 -0000

Philip Homburg <> wrote:
>> Further, the definition says that "a node considers an address to
>> be on-link it is covered by a particular prefix".  That operation,
>> 'being covered by', is not specified.
>> One might think of the use of a longest prefiix match algorithm.
>> A longest prefix match algorithm is defined in that RFC to be used
>> to determine which prefix (from a set of prefixes) 'covers' an
>> address.
>> On another hand, the definition of 'on-link' says it wants to
>> identify whether a _particular_ prefix 'covers' an address (not to
>> try to identify whether an address matches better one prefix or
>> another).  That is a distinct algorithm from the longest prefix
>> match algorithm.
>> To give an example: by using a longest-prefix-match algorithm in
>> a normal way (identify which prefix out of a set of prefixes matches
>> better one particular address) one will always 'cover' an address
>> with almost any prefix.  All allocated prefixes start with this
>> '000' triple bits.  So they all cover any address; but in that
>> 'cover' operation one specifically adds that it covers up to 3
>> bits.  The 'cover' operation is successful, but just up to 3.
> I'm confused about what you are trying to say.

Thanks, I was beginning to wonder if it was just me !

> The way I understand it is as follows:
> An RA may contain a prefix that has the onlink bit set. The interface
> is implicitly defined as the interface over which the RA arrives at the
> host, so there is no need to make this explicit. Information in an RA only
> applies to the interface over which the RA arrives.

That was my interpretation as well.

> Then 'covered by the prefix'. Covered by the prefix 2001:db8::/80 means that
> if the first 80 bits of an address are the same as the first 80 bits of the
> prefix, then the address is said to be covered by the prefix. For onlink,
> there is no 64-bit boundary. Any prefix length should work. The prefix
> length determines how many bits are compared to decide on a match.


> Then, in theory there could be overlapping prefixes, some might be onlink,
> some might be not onlink. So in theory we could define a longest matching rule.
> However, this leads to code complexity and there don't seem to be any
> practical use cases for overlapping prefixes, so leaving this undefined
> and assuming that routers do not generate RAs with overlapping prefixes
> seems fine.

I had assumed (yes I know, that's dangerous) that overlapping prefixes would be as allowed as overlapping IPv4 subnets - as in not allowed. It would at the very least be rather poor network design since it would create completely avoidable issues like you described.