Skip to content

Add support for dynamic routing on ipv6 (ospfv3 and ripng) - #1577

Draft
saba8814 wants to merge 2 commits into
kernelkit:mainfrom
saba8814:dynamic-routing-on-ipv6
Draft

Add support for dynamic routing on ipv6 (ospfv3 and ripng)#1577
saba8814 wants to merge 2 commits into
kernelkit:mainfrom
saba8814:dynamic-routing-on-ipv6

Conversation

@saba8814

@saba8814 saba8814 commented Aug 3, 2026

Copy link
Copy Markdown
Collaborator

Description

Checklist

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

  • Bugfix
    • Regression tests
    • ChangeLog updates (for next release)
  • Feature
    • YANG model change => revision updated?
    • Regression tests added?
    • ChangeLog updates (for next release)
    • Documentation added?
  • Test changes
    • Checked in changed Readme.adoc (make test-spec)
    • Added new test to group Readme.adoc and yaml file
  • Code style update (formatting, renaming)
  • Refactoring (please detail in commit messages)
  • Build related changes
  • Documentation content changes
    • ChangeLog updated (for major changes)
  • Other (please describe):

@saba8814 saba8814 self-assigned this Aug 3, 2026
@saba8814
saba8814 marked this pull request as draft August 3, 2026 13:11
@jovatn

jovatn commented Aug 4, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

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

saba8814 commented Aug 4, 2026

Copy link
Copy Markdown
Collaborator Author

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.

saba8814 added 2 commits August 4, 2026 10:24
@saba8814
routing: add IPv6 dynamic routing (RIPng and OSPFv3)
7bc0935 
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>
@saba8814
doc: updated RIPng and OSPFv3 documentation
c0138a4 
Signed-off-by: Ejub Sabic <ejub1946@outlook.com>
@saba8814
saba8814 force-pushed the dynamic-routing-on-ipv6 branch from 368dd90 to c0138a4 Compare August 4, 2026 08:26
@troglobit

troglobit commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@saba8814 saba8814

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@saba8814 @jovatn @troglobit