OSPFv3 and stub interfaces without lladdr

[Christian Tacke]

Hi,

On Sun, May 31, 2015 at 01:34:46 +0200, Hans van Kranenburg wrote:
> In favor of intuitive behaviour for users, I'd vote to have bird6
> just happily treat stub without ipv6 link local the same way as it
> does with IPv4 on stub interfaces. So addresses on the lo in linux,
> and e.g. also the openvpn example (which I fixed in the same way,
> putting some fe80 on the link to satisfy bird) would work out of the
> box as stub.

We (Hans, _robbat2 and me) looked further into this,
especially we started to look into the sources.  We
learned, that the current situation is not as easy as one
might hope.  As this looks like a bigger rewrite, we need
to understand the current behaviour.  And that is a bit
strange:

The idea seems be to have only one ospf-interface ("show
ospf interface") per real interface / lladdr.  And the
networks connected to that single ospf-interface.  This is
in contrast to ipv4, where one has one ospf-interface per
each primary address on the interface.

First note: If there are multiple lladdr on one real
interface, multiple ospf-interfaces are created. We gussed,
that the assumption was, that there is only one lladdr per
interface.
--> Is this assumption covered by any RFC? I doubt so.
--> Is this behaviour intended, or is this a bug?

If we want to create (one or many) stub ospf-interface(s)
for an interface without lladdr, the arising questions are:
--> create one ospf-interface or many?
--> If one, which address should be used for it?

All of this gets more complex, when considering, that this
has to be torn down and replaced by the "classic" stuff, if
a lladdr gets added to the interface.

Thoughts?


> If not, adding more logging, like the following suggestion would be
> useful to prevent users from wasting too much time and getting
> frustrated: "bird6: ospfX: Not adding OSPFv3 interface $FOO to area
> a.b.c.d because it has no link local address configured".

If the above is too complex, then yes, better logging would
certainly help.


Cheers

Christian

-- 
www.cosmokey.com