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

Le 06/07/2021 à 18:32, Simon Hobson a écrit :
> Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
> 
>>> I suggest you look at it from a different angle. "on-link address" is
>>> defined as an address that is assigned to an interface on a specified
>>> link.
>>
>> But, each address is on a link.
>>
>> On-link means the address is on this link that we are assuming commonly.
>> The term off-link means that the address is not on this link we assume
>> commonly, but is on-link on another link.
> 
> Isn't it simpler than that ?
> On link == hosts can directly contact other hosts in the prefix via this link
> Not on link == hosts can only contact other hosts in the prefix via one or more intermediaries
> 
> Intermediary in this case is quite flexible and could include routing packets or mechanisms like proxy ND

I think it is a good informal explanation, that fits.

However, the formal definition of 'on-link' in RFC 4861 says that 
'on-link' is an address on a specified link.  But in RAs there is no 
means to specify a link.

There are indeed prefixes that are valid on a particular link, but links 
are not identified by particular prefixes.

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.

If, on the other hand, we silently assume that a longest-prefix-match 
algorithm is always used with a prefix length of precisely 64 bits, then 
indeed the longest prefix match algorithm can be used to say it 'covers' 
(or not covers) an address.

But it is no longer a longest-prefix-match but rather a mix-in of exact 
match on 64.

The problem with this assumption is that the RFC 4861 does not say this 
'64', but everyone else seems to assume it.

At that point, if this is agreed, I would like to suggest RFC4861 to 
explicitely say that all the definitions of 'on-link' and of 'cover by' 
rely on a silent yet fundamental assumptions that all IPv6 addresses 
have a boundary at 64.  And no longer be silent about it.

After that, I would like to suggest to remove that barrier.

Alex

> 
> I think any more is just making things complicated. If the link is of a type (e.g. unfiltered ethernet) where neighbours can find each other (e.g. using ND), then a prefix can be on-link. Otherwise (non-broadcast link technology, security filtering, etc), prefixes will need to be off-link.
> 
> 
> OK, so what have I missed here ?
> 
> Simon
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 