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