Hello, I am using bird as an OSPFv3 daemon and I encountered a bug while playing with the wires. Therefore, I would like to propose this correcting patch. If you have any more formal way to do it, please tell me. I looked at your gitlab, but couldn't find any way to propose a patch. Cheers, Pierre Pfister ---------------Here is my own commit's commentary that explains the patch--------- [DEBUG] Keep latest source address as neighbor's address In RFC5340, it is stated: "For all link types except virtual links, the Neighbor IP address is set to the IPv6 source address in the IPv6 header of the received OSPF Hello packet." It is not said which source address should be kept among all received Hello packets from the same neighbor. In current implementation, the first is used. In some cases, the neighbor's source address can change. But, in OSPFv3, neighbors are always identified by their IDs. If we don't keep the latest address as the neighbor's address, all HELLO packets will be correctly considered, but further unicast packet sent to the router that changed its address may not be received, making the link state blocking indefinitly. Cases where the source address can change are: - A wire's end is moved from one port to another. - For some reason, a router decides to change its Active Interface, which choice is implementation dependent. ---------------Here is the patch as provided by git-------------- diff --git a/proto/ospf/hello.c b/proto/ospf/hello.c index 58e87bb..0fbedc3 100644 --- a/proto/ospf/hello.c +++ b/proto/ospf/hello.c @@ -152,6 +152,12 @@ ospf_hello_receive(struct ospf_packet *ps_i, struct ospf_iface *ifa, n->iface_id = ntohl(ps->iface_id); #endif } +#ifdef OSPFv3 + else if (!ipa_equal(n->ip, faddr)) { + OSPF_TRACE(D_EVENTS, "Neighbor address changed from %I to %I", n->ip, faddr); + n->ip = faddr; + } +#endif ospf_neigh_sm(n, INM_HELLOREC); pnrid = (u32 *) ((struct ospf_hello_packet *) (ps + 1));