dpdk: vendor 25.11 patch for ipv6 ll addr compliance

[christophefontaine]

As specified in RFC 4291 section 2.5.1, link local addresses must be generated based on a modified EUI-64 interface identifier.

Until this release is available, include this patch in grout.

Link: https://patches.dpdk.org/project/dpdk/list/?series=36703

Summary by CodeRabbit

• Bug Fixes

  • Fixed IPv6 link-local address generation to comply with RFC 4291 standards.

• Documentation

  • Updated documentation to reference RFC 4291, section 2.5.1 for IPv6 link-local compliance.

[coderabbitai]

📝 Walkthrough

Walkthrough

This change introduces a new patch file to align DPDK's IPv6 link-local address generation with RFC 4291. The patch modifies how the interface identifier is constructed from the MAC address by flipping the U/L (Universal/Local) bit using an XOR operation with 0x02. The corresponding test expectations are updated to reflect this modification. Documentation references are also updated to point to the relevant RFC section.

Pre-merge checks

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	Title clearly summarizes the main change: adding a DPDK 25.11 patch for IPv6 link-local address compliance.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f2b0972 and 3784ca0.

📒 Files selected for processing (2)

• subprojects/dpdk.wrap (1 hunks)
• subprojects/packagefiles/dpdk/net-ipv6-link-local-compliance-with-rfc-4291.diff (1 hunks)

🧰 Additional context used

🧠 Learnings (5)

📓 Common learnings

Learnt from: maxime-leroy
Repo: DPDK/grout PR: 309
File: modules/srv6/datapath/srv6_local.c:88-122
Timestamp: 2025-09-09T06:02:47.703Z
Learning: The DPDK function rte_ipv6_get_next_ext() only reads 2 bytes from the extension header, so a 2-byte precheck is sufficient before calling it.

Learnt from: maxime-leroy
Repo: DPDK/grout PR: 309
File: modules/srv6/datapath/srv6_local.c:97-101
Timestamp: 2025-09-09T09:22:31.596Z
Learning: In SRv6 IPv6 extension header parsing, when is_ipv6_ext[proto] is true, rte_ipv6_get_next_ext() will not return a negative value, making error checking unnecessary. An assert can be used as a defensive measure for future DPDK compatibility.

Learnt from: rjarry
Repo: DPDK/grout PR: 305
File: modules/ip6/control/route.c:407-413
Timestamp: 2025-08-27T15:33:22.299Z
Learning: DPDK rte_rib6_get_nxt() with RTE_RIB6_GET_NXT_ALL flag does not yield the default route ::/0 if configured. The explicit rte_rib6_lookup_exact() call for the default route is necessary to ensure complete route enumeration.

Learnt from: rjarry
Repo: DPDK/grout PR: 372
File: modules/infra/datapath/loop_input.c:53-56
Timestamp: 2025-11-05T14:28:28.817Z
Learning: In modules/infra/datapath/loop_input.c, the l3_edges array is intentionally indexed using network byte order (rte_be16_t) for EtherType values. Both loopback_input_add_type() registration and loopback_input_process() lookup use network byte order consistently, so no byte order conversion is needed when accessing l3_edges.

Learnt from: maxime-leroy
Repo: DPDK/grout PR: 309
File: modules/srv6/datapath/srv6_local.c:88-122
Timestamp: 2025-09-09T06:02:47.703Z
Learning: When parsing IPv6 routing headers in SRv6 processing, bounds checking for the full extension header length and validation of the routing header structure is needed before accessing fields like hdr_len, last_entry, segments_left, and type.

📚 Learning: 2025-09-09T09:22:31.596Z

Learnt from: maxime-leroy
Repo: DPDK/grout PR: 309
File: modules/srv6/datapath/srv6_local.c:97-101
Timestamp: 2025-09-09T09:22:31.596Z
Learning: In SRv6 IPv6 extension header parsing, when is_ipv6_ext[proto] is true, rte_ipv6_get_next_ext() will not return a negative value, making error checking unnecessary. An assert can be used as a defensive measure for future DPDK compatibility.

Applied to files:

• subprojects/packagefiles/dpdk/net-ipv6-link-local-compliance-with-rfc-4291.diff
• subprojects/dpdk.wrap

📚 Learning: 2025-09-09T06:02:47.703Z

Learnt from: maxime-leroy
Repo: DPDK/grout PR: 309
File: modules/srv6/datapath/srv6_local.c:88-122
Timestamp: 2025-09-09T06:02:47.703Z
Learning: The DPDK function rte_ipv6_get_next_ext() only reads 2 bytes from the extension header, so a 2-byte precheck is sufficient before calling it.

Applied to files:

• subprojects/packagefiles/dpdk/net-ipv6-link-local-compliance-with-rfc-4291.diff

📚 Learning: 2025-08-27T15:33:22.299Z

Learnt from: rjarry
Repo: DPDK/grout PR: 305
File: modules/ip6/control/route.c:407-413
Timestamp: 2025-08-27T15:33:22.299Z
Learning: DPDK rte_rib6_get_nxt() with RTE_RIB6_GET_NXT_ALL flag does not yield the default route ::/0 if configured. The explicit rte_rib6_lookup_exact() call for the default route is necessary to ensure complete route enumeration.

Applied to files:

• subprojects/packagefiles/dpdk/net-ipv6-link-local-compliance-with-rfc-4291.diff

📚 Learning: 2025-11-05T14:28:28.817Z

Learnt from: rjarry
Repo: DPDK/grout PR: 372
File: modules/infra/datapath/loop_input.c:53-56
Timestamp: 2025-11-05T14:28:28.817Z
Learning: In modules/infra/datapath/loop_input.c, the l3_edges array is intentionally indexed using network byte order (rte_be16_t) for EtherType values. Both loopback_input_add_type() registration and loopback_input_process() lookup use network byte order consistently, so no byte order conversion is needed when accessing l3_edges.

Applied to files:

• subprojects/packagefiles/dpdk/net-ipv6-link-local-compliance-with-rfc-4291.diff

🔇 Additional comments (4)

subprojects/packagefiles/dpdk/net-ipv6-link-local-compliance-with-rfc-4291.diff (3)

5-10: Test expectation correctly updated.

The test's expected IPv6 address correctly reflects the U/L bit flip: 0x04 ^ 0x02 = 0x06.

---

27-32: U/L bit flip correctly implements RFC 4291 modified EUI-64.

The XOR with 0x02 properly flips the universal/local bit as required for IPv6 link-local address generation from MAC addresses.

---

18-23: RFC reference update is accurate.

RFC 4291 section 2.5.1 specifies the "Modified EUI-64" method for forming IPv6 interface identifiers from IEEE 48-bit MAC (Ethernet) addresses, making it the correct modern reference to replace RFC 2464. No changes needed.

subprojects/dpdk.wrap (1)

9-10: Patch applies cleanly to DPDK v24.11.3.

Verification confirms the patch applies without conflicts or errors. No regressions detected.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}