On Thu, 2019-04-18 at 13:55 +0200, Ondrej Zajicek wrote: > CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you recognize the sender > and know the content is safe. > > > On Mon, Apr 15, 2019 at 12:56:24PM +0000, Kenth Eriksson wrote: > > > > Does OSPFv3 (RFC5340 / RFC5838) handle unnumbered (/32) > > > > differently > > > > from OSPFv2? > > > > > > Not in a significant way. > > > > > > > So a /32 shall be implicitly re-distributed in the OSPF area both > > for > > OSPFv2 and OSPFv3? I think that differs from how Quagga did it for > > unnumbered interfaces. > > Well, we are mixing two cases here: > > 1) Just /32 (or /128) stub addresses (with no peer) > > 2) 'Unnumbered' PtP addresses with /32 local and /32 peer address. > > The first case is always propagated in the OSPF area for both OSPFv2 > and > OSPFv3 as any other prefix. > > 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." > 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. > > You say it differs from Quagga, what is their behavior? > I'm not sure there is a difference after you explained that unnumbered /32 with peer was treated different compared to /32 without peer. But when I looked into the frr git repo, I can see that unnumbered interface support was added in in git sha 525c183906c47c491611f294db218d53a561a3b9. Prior to that commit I think quagga always re-distributed unnumbered interfaces as well. > -- > Elen sila lumenn' omentielvo > > Ondrej 'Santiago' Zajicek (email: santi...@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."
