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

[Simon Hobson <[e-mail]>]

Philip Homburg <[e-mail]> 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.

Agreed.

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


Simon