On Tue, Apr 23, 2019 at 10:28:46AM +0000, Kenth Eriksson wrote:
The second case is more complex. In OSPFv2, it always does not propagate /32 local addresses and it propagates /32 peer addresses only if configured as stub. In OSPFv3, this is not implemented and neither local /32 address nor peer /32 address are propagated (as Linux IPv6 does not have PtP addresses and we missed that when done OSPFv3-IPv4). But this we should fix and it should behave as in OSPFv2.
Does the description you give here comply to the intent in section 12.4.1.1 of RFC2328? The following statement of the RFC makes the intent a bit unclear to me; "...a Type 3 link (stub network) should be added."
The section 12.4.1.1 for 'unnumbered' case (Option 1) describes handling of *peer* IP address, it is silent about handling of *local* IP address.
Another issue is whether local /32 *should* be propagated for 'unnumbered' PtP links. We do not do that, but i think it should be configurable, and perhaps default yes in cases the local IP is not covered by range from other ifaces.
Configureable seems like a sensible thing to me. The default should be what the standard suggests.
I think the standard just does not consider the case of 'unnumbered' link with both local and remote address but without subnet and assumes 'real' unnumbered PtP link with no local IP address associated with the iface. -- 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."