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