OSPFv3 and stub interfaces without lladdr

[Ondrej Zajicek]

On Mon, Jun 01, 2015 at 10:39:39PM +0200, Christian Tacke wrote:
> 
> 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.

Hi

There are several implementation issues related to OSPF interfaces and addresses:

First, BIRD generally handle interfaces without any IP address as down
regardless of their admin status. This helps in some cases (like when
802.1x negotiation should happen before using the iface) but it is
limitation in cases when unnumbered interfaces should be used. Alhough
this is not an issue for you as you want to use stub interfaces with
global addresses, but it is is related problem.

Second, OSPFv2 and OSPFv3 share most code and because OSPFv2 has separate
interface-instance per network prefix, it depends mainly on address-
-notifications than on iface-notifications. The same design was carried
over to OSPFv3, only waiting for regular addresses was replaced by
waiting for link-local addresses. This also solves issues when link-local
address appears later than iface or is changed.


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

Well this was supposed to be handled by 'secondary' flag for an address,
but it seems like Linux IPv6 behavior is different than IPv4 behavior and
does not use secondary flags (muliple addresses from the same network are
attached to the iface) in IPv6.


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

Proper solution would be like:

1) Have separate ospf_if_notify() for OSPFv2 and OSPFv3 like
it is already done for ospf_ifa_notify[23]().

2) Add/remove OSPFv3 ifaces per interface based on events in 
ospf_if_notify3(), not in ospf_ifa_notify3().

3) If there is no link-local address, interface should be stub.
   If link-local address apprears/disappears, interface should
   be unstubbified/stubbified.

4) It is likely that there are code in OSPF assuming ospf_iface->addr
   is non-NULL, this should be fixed


It is a question what should be done when old link-local address
disappears but there is another one. I think that OSPFv3 uses mainly
Router ID and not IP address to identify neighbors so the address could
be changed withouth much disturbance to neighbors, but i would have to
check that.


If you want to make a patch doing this, i would be glad, otherwise i
would look at this issue in the future.


-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20150602/bf8ebe88/attachment.asc>