on-link and off-link addresses, side discussion

[Alexandre Petrescu <[e-mail]>]

Le 02/07/2021 à 00:46, Jen Linkova a écrit :
[...]
> 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.

In the RA, where the 'on-link' prefixes are present, there is no
identifier of a link.  If there were, then we could say that that
prefix, and the SLAAC-formed addresses, were 'on-link' on the specified
link.

And, there is no address that is not on a link.  All addresses are on a
link.  Even on virtual interfaces, the 'on-link' addresses are on-link
on that virtual link.

> There are different ways to indicate that the address is on-link and 
> one of them is "the address is covered by an on-link prefix,

Conceptually, yes, but the relationship 'covered by' can not be
implemented correctly unless we specify a prefix length to input into a
matching algorithm.  It is not the plen of the prefix in the PIO, it is
a length used in a search algorithm.

Only the persons who believe that length is 64, and always 64, consider
that 'covered by' is an implementable operation.

> e,g, as indicated by the on-link flag in the Prefix Information
> option". L bit just indicates that addresses covered by the prefix
> shall be considered on-link. That's it.
> 
>> This 'on-link' and 'off-link' discussion relates a lot to the 
>> difficulties we have in suggesting at IETF that a new extension is 
>> needed to tell that a prefix advertised on a link might not be for
>> that link to be used for SLAAC, but for putting in a routing table
>> entry.  A little bit similar to RFC4191's RIOs.
> 
> OK, disclaimer: I'm writing this before my first coffee...but...L
> flag has nothing to do with SLAAC, A flag is used for that. L=1, A=0
> would just mean 'addresses on that prefix are on-link but do not use
> the prefix for auto-configuration'.

'addresses on that prefix', you mean addresses whose plen is always 64, 
I think.

> 
> Smth like:
> 
> 2001:db8:1::/64----node1-------node2 If node2 receives a PIO for
> 2001:db8:1::/64 with L=1, A=0 it would assume that 2001:db8:1::f00,
> for example, is on-link and would try to resolve its link-layer
> address using ND. If node1 acts as an ND proxy, it would work.

Fair enough.  The concept of ND proxy blurs a little bit all that I have 
written above.

> 
>> But when told that the RIO of RFC4191 might be appropriate for the
>> V2V case that I needed I always reply that what we need is an RIO
>> that is always outside the link (I dont use the term 'off-link'),
>> and always at least 2-hops away, never 1-hop away.  SO there I dont
>> use either the on/off-link terms.
> 
> Sorry, I've not been following that discussion. Wouldn't "L=1, A=0 + 
> ND proxy" do what you want?
Err, no.

What I need is a prefix in an PIO (or a RIO) of an RA that is on a link 
('on-link') situated always at least one IP hop away; it is never 
'on-link' on this link where the RA is sent. These prefixes are never 
used to form addresses elsewhere than where they are 'on-link'.

The topology is below.  Each vertical and horizontal lines are 'links'. 
  The triple dot separate links with IP routers.

R2 sends an RA towards R1 containing the P prefixes below each other 
router.  These prefixes are at least one IP hop away from R2's link on 
which it sends that RA.

        RA[P2, ...Pn] <--
     R1------------------R2---...---Rn
     |                   |P2        |Pn
     |                   |          |
   Host1               Host2      Hostn

Alex