Ping? I will commit the revised patch if there is no objection.

Fix the lines pointed out in the review.

In D23695#521499, @melifaro wrote:

In D23695#521458, @hrs wrote:

I have no strong objection to allow a prefix route with no gateway, but I think the case pointed out in Bug 194485 can be solved by just adding an address with the delegated prefix on the interface (EUI-64 always works as the interface id). Is there any specific reason for DHCP-PD (or another use case) to have an interface route?

Thank you for looking into this!

Indeed, I should have provided a more accurate description. The problem is a bit bigger than just DHCPv6.

In general, RFC 5942 advocates for the explicit split between address management and prefix assignment:

Remove irrelevant references to smbus(4).

I have no strong objection to allow a prefix route with no gateway, but I think the case pointed out in Bug 194485 can be solved by just adding an address with the delegated prefix on the interface (EUI-64 always works as the interface id). Is there any specific reason for DHCP-PD (or another use case) to have an interface route?

Remove device_printf()s just for debugging.

Updated the patch based on feedback from bz@:

Looks good to me.

Looks good to me.

Could you please fix the following nits? Sorry for sending comments so many times separately.

Update patch:

In D21589#481177, @asomers wrote:

@hrs do you realize that the submitter is not a committer? Can you commit this change for him?

Your change looks to me trying to add IPv6 support by a copy-and-paste of the logic used in IPv4. I do not think it is a good idea in general or even for rwhod. At the time when rwhod utility was written there was an IPv4-specific API only, but nowadays we have a lot of address family independent APIs. For multicast membership management, an API defined in RFC 3678 is the standard way to support IPv4 and IPv6 in a AF-agnostic manner. Therefore, multicast support of rwhod needs a major rewrite by using this new API to support both IPv4 and non-IPv4 protocols at least. While we welcome converting an IPv4-only program to support IPv6 in an AF-independent API such as getaddrinfo(3), we do not want to add another IPv6-only code path to every single IPv4-only utility unless it is the only way to do so.

• We do not have MPLS as described in RFC 4023 or NVGRE in RFC 7637 as a kernel feature.
• RFC 8086 (GRE-in-UDP) is supported.
• I am not sure why WCCP I-Ds should be listed here. They use GRE but it is usually implemented by a userland daemon, not by kernel.

Looks good to me.