Add support for dynamic routing on ipv6 (ospfv3 and ripng) by saba8814 · Pull Request #1577 · kernelkit/infix

saba8814 · 2026-08-03T13:10:57Z

Description

Checklist

Tick relevant boxes, this PR is-a or has-a:

jovatn · 2026-08-04T07:27:38Z

I'd like to initiate a discussion on the support for OSPF address-family leaf.
I think we need a deviation to limit it to only "IPv6" as FRR does not yet support IPv4 routes over OSPFv3. Note: the purpose of the address-family setting is limited to OSPFv3 and let's you specify whether the instance is for carrying IPv6 or IPv4 routes as defined in RFC5838.

Thus, I believe we should add a deviation for the address-family leaf which could either

skip support for it, or
be configurable with ipv6 as only option, or
make it static/read-only

Note: If we ever wish to support IPv4 over OSFPv3 (as of RFC5838 )that will impact flags in OSPF hello messages. Perhaps we should skip support for the leaf until add support for RFC5358, if ever.

saba8814 · 2026-08-04T07:48:28Z

I'd like to initiate a discussion on the support for OSPF address-family leaf. I think we need a deviation to limit it to only "IPv6" as FRR does not yet support IPv4 routes over OSPFv3. Note: the purpose of the address-family setting is limited to OSPFv3 and let's you specify whether the instance is for carrying IPv6 or IPv4 routes as defined in RFC5838.

Thus, I believe we should add a deviation for the address-family leaf which could either

skip support for it, or

be configurable with ipv6 as only option, or

make it static/read-only

Note: If we ever wish to support IPv4 over OSFPv3 (as of RFC5838 )that will impact flags in OSPF hello messages. Perhaps we should skip support for the leaf until add support for RFC5358, if ever.

Great point @jovatn .
My vote is to restrict it to ipv6 rather than skip it. That way if when add RFC 5838 support we just edit the must(yang validation), but if we remove the leaf now and add it again later that would be a breaking change and we will need migration script as well . But we will see what rest of the team thinks about it.

Why Infix supported OSPFv2 and RIPv2 for IPv4 only. Dual-stack deployments need dynamic routing for IPv6 as well. This wires up FRR's ripngd and ospf6d behind the existing ietf-rip/ietf-ospf models so IPv6 routing is configured the same way as IPv4, over NETCONF/RESTCONF and the CLI. What to Expect - RIPng: mirror of the RIPv2 feature set on IPv6 (basic, passive interfaces, multi-hop, redistribution), driven through netd. - OSPFv3: address-family ipv6 with areas, NSSA/stub, interface types (broadcast, point-to-point, hybrid), cost/priority/timers, BFD, default-route advertisement and redistribution (incl. RIPng <-> OSPFv3). - Operational state via statd (show ipv6 ospf [neighbor|interface|route]) - Full test coverage for both protocols. Limitations - OSPFv3 requires an explicit-router-id (no IPv4 to derive one from). - ospf6d has no totally-NSSA, no default-cost, and no non-broadcast / static-neighbor interfaces; these are rejected/omitted accordingly. - OSPFv3 next-hops are IPv6 link-local, so paths are verified by traceroute rather than by RIB next-hop matching. Signed-off-by: Ejub Sabic <ejub1946@outlook.com>

Signed-off-by: Ejub Sabic <ejub1946@outlook.com>

troglobit · 2026-08-04T08:36:37Z

I'd like to initiate a discussion on the support for OSPF address-family leaf.

I think we need a deviation to limit it to only "IPv6" as FRR does not yet support IPv4 routes over OSPFv3. Note: the purpose of the address-family setting is limited to OSPFv3 and let's you specify whether the instance is for carrying IPv6 or IPv4 routes as defined in RFC5838.

Thus, I believe we should add a deviation for the address-family leaf which could either

skip support for it, or

be configurable with ipv6 as only option, or

make it static/read-only

Note: If we ever wish to support IPv4 over OSFPv3 (as of RFC5838 )that will impact flags in OSPF hello messages. Perhaps we should skip support for the leaf until add support for RFC5358, if ever.

Agreed, deviate as not supported for now.

Signed-off-by: Ejub Sabic <ejub1946@outlook.com>

mattiaswal · 2026-08-19T07:46:36Z

+
+### Differences from OSPFv2
+
+OSPFv3 runs on FRR's `ospf6d`, which does not implement every feature


Implementation detail, not for user facing documentation. Should describe what infix supoorts, not FRR.

mattiaswal · 2026-08-19T07:47:26Z

+OSPFv3 runs on FRR's `ospf6d`, which does not implement every feature
+available for OSPFv2:
+
+- OSPFv3 carries IPv6 routes only; IPv4-over-OSPFv3 (RFC 5838) is not


This is good to mention though, deviations from standards.

mattiaswal · 2026-08-19T08:10:23Z

+	return yang_type;
+}
+
+static int parse_ospf6_interfaces(struct lyd_node *areas, FILE *fp)


Isnt this a duplication of the parse_ospf_interfaces?

mattiaswal · 2026-08-19T08:11:29Z

+ * point-to-multipoint.  There is no NBMA/non-broadcast variant, so 'hybrid'
+ * maps to point-to-multipoint; non-broadcast is rejected by YANG for OSPFv3.
+ */
+static const char *ospf6_network_type(const char *yang_type)


Use ospf_network_type, unsupported types is rejected by YANG (stated above)

mattiaswal · 2026-08-19T08:12:48Z

+	return num_bfd_enabled;
+}
+
+static void parse_ospf6_redistribute(struct lyd_node *redistributes, FILE *fp)


Why not use parse_ospf_redistibute?

mattiaswal · 2026-08-19T08:20:37Z

-	if (rip->enabled)
-		DEBUG("Linux backend: RIP not supported without FRR");
+	if (rip->enabled || ripng->enabled)
+		DEBUG("Linux backend: RIP/RIPng not supported without FRR");


Change this to ERROR() instead.

mattiaswal · 2026-08-19T08:22:33Z

    insert(control_protocols, "control-plane-protocol", [control_protocol])


+def ospf6_interface_type(op):


No difference to ipv4

mattiaswal · 2026-08-19T08:22:48Z

+    return xlate.get(op)
+
+
+def add_routes6(ospf):


No difference to ipv4

mattiaswal · 2026-08-19T08:23:18Z

+        insert(ospf, "ietf-ospf:local-rib", "ietf-ospf:route", routes)
+
+
+def add_areas6(control_protocols):


Only difference is ipv6 and ospfv3? or am I missing something?

mattiaswal · 2026-08-19T08:25:06Z

@@ -0,0 +1,236 @@
+#!/usr/bin/env python3


Does this really need a new test? Isn't enought to add a parameter to ospf_basic?

This goes for all tests below.

mattiaswal · 2026-08-19T08:26:22Z

Great work, mostly remove code duplication and make the code more maintainable.

saba8814 self-assigned this Aug 3, 2026

saba8814 marked this pull request as draft August 3, 2026 13:11

saba8814 added 2 commits August 4, 2026 10:24

doc: updated RIPng and OSPFv3 documentation

c0138a4

Signed-off-by: Ejub Sabic <ejub1946@outlook.com>

saba8814 force-pushed the dynamic-routing-on-ipv6 branch from 368dd90 to c0138a4 Compare August 4, 2026 08:26

saba8814 added 2 commits August 4, 2026 13:07

fix: unsupport address-family

9c1ec91

Signed-off-by: Ejub Sabic <ejub1946@outlook.com>

frr: patch OSPFv3 default route loss after ospf6d restart

f636c35

Signed-off-by: Ejub Sabic <ejub1946@outlook.com>

saba8814 marked this pull request as ready for review August 11, 2026 10:38

jovatn requested review from mattiaswal and troglobit August 17, 2026 13:26

mattiaswal requested changes Aug 19, 2026

View reviewed changes


		### Differences from OSPFv2

		OSPFv3 runs on FRR's `ospf6d`, which does not implement every feature

		insert(control_protocols, "control-plane-protocol", [control_protocol])


		def ospf6_interface_type(op):

		insert(ospf, "ietf-ospf:local-rib", "ietf-ospf:route", routes)


		def add_areas6(control_protocols):

Uh oh!

Conversation

saba8814 commented Aug 3, 2026

Description

Checklist

Uh oh!

jovatn commented Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

saba8814 commented Aug 4, 2026

Uh oh!

troglobit commented Aug 4, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mattiaswal commented Aug 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jovatn commented Aug 4, 2026 •

edited

Loading