BIRDv2 OSPF: Stub for loopback potentially broken: Invalid Prefix in LSA

[Ondrej Zajicek]

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