In D30398#713041, @melifaro wrote:

Also: will you write a commit message, or do you prefer me doing it?

In D30398#713040, @melifaro wrote:

You also need to add a bit of family wrapping logic inside fill_nhop_from_info(), so we get a proper family for the nexthop.

.

Pass correct AF to nd6_resolve()

In D30398#712308, @melifaro wrote:

In D30398#712270, @zlei.huang_gmail.com wrote:

@melifaro Sorry for late response ;)

I removed the LLE part, it should be easy to apply D31379 .

It should be the other way round :-) e.g. D31379 is a pre-requisite.
Could you try to apply it first, build on top and test?

Also: will you write a commit message, or do you prefer me doing it?

You also need to add a bit of family wrapping logic inside fill_nhop_from_info(), so we get a proper family for the nexthop.

In D30398#712308, @melifaro wrote:

In D30398#712270, @zlei.huang_gmail.com wrote:

@melifaro Sorry for late response ;)

I removed the LLE part, it should be easy to apply D31379 .

It should be the other way round :-) e.g. D31379 is a pre-requisite.
Could you try to apply it first, build on top and test?

Added feature(3) knob.

Cleaned up some comments.

In D30398#712270, @zlei.huang_gmail.com wrote:

@melifaro Sorry for late response ;)

I removed the LLE part, it should be easy to apply D31379 .

It should be the other way round :-) e.g. D31379 is a pre-requisite.
Could you try to apply it first, build on top and test?

.

@melifaro Sorry for late response ;)

Rebased on latest main branch

In D30398#708795, @melifaro wrote:

I've updated the aforementioned D31379 to reflect the committed parts.
If you could update this review to use the new functionality (e.g. nd6_resolve() returning lle with the proper encap) , that would be awesome.

I've updated the aforementioned D31379 to reflect the committed parts.
If you could update this review to use the new functionality (e.g. nd6_resolve() returning lle with the proper encap) , that would be awesome.

I've added D31379 with the lltable support for IPvX over IPvY.
Basically, the diff creates per-family "child" lle entries attached to the main lle entry. The purpose of each child entry is to have an object with a proper encap, so it can be referenced just like standard lle.

Rework sending queued LLE packets.

I have some WIP patch on making nd6_resolve() return LLEs with proper encap. Hope to publish it later this week.

In D30398#691776, @melifaro wrote:

LGTM, I guess the biggest remaining piece now is lle handling, especially sending queued LLE packets upon successful resolution.

In D30398#691776, @melifaro wrote:

LGTM, I guess the biggest remaining piece now is lle handling, especially sending queued LLE packets upon successful resolution.

In D30811#693218, @zlei.huang_gmail.com wrote:

Can you please share the discussion? Thanks!

I think I hit the issue that the useloopback was trying to resolve.

In D30811#692900, @donner wrote:

I'm surprised. There was a discussion about not redirecting /32 on interfaces to loopback. So we see the consequence.

I believe this bug is also related: #255685

I'm surprised. There was a discussion about not redirecting /32 on interfaces to loopback. So we see the consequence.

LGTM, I guess the biggest remaining piece now is lle handling, especially sending queued LLE packets upon successful resolution.

Updated as @melifaro suggested.

In D30398#683204, @zlei.huang_gmail.com wrote:

• inpcb LLE caching

If I remember correctly, there is LLE caching in route object, and inpcb caches the route.

• slow path - sending packets when there is no LLE entry

Current implementation when there is no LLE entry sending packets is blocked, I wonder if we can re-queue them.

ether_resolve_addr() will consume an mbuf and add it to the sending queue of the particular lle we're looking to resolve.
Once lle is resolved we iterate through this queue and re-send these using if_output() (end of arp_check_update_lle() for IPv4). Here we need to distingush between IPv4 or IPv6 packets somehow - either by inspecting IP version field or having a separate queues for IPv4/IPv6. Personally I'd experiment with the former approach.

This version looks pretty neat, please see some comments inline.

Reuse route.ro_dst to get the address family of outbound / forwarded packets.

In D30398#682930, @melifaro wrote:

First of all, thanks for working on this! This is the important feature we need to have in base, preferably turned on by default.
I'd love to land this.

Glad to get your response !
I'm interested with scalable network, and recently exploring the CLOS network architecture described by RFC 7938. It need large number of IPs and configuration
and BGP unnumbered seems to rescue (RFC 5549).
Thanks your effort on FreeBSD's routing component, it is not too hard to implement such feature in the dataplane :)

I spent some time thinking about the potential implementation option some time ago. Let me try to summarise my thoughts below.

First of all, thanks for working on this! This is the important feature we need to have in base, preferably turned on by default.
I'd love to land this.

Thanks @donner :)

Hi, since I do not have access to the src repository, could someone check in the diff please ?

Friendly ping @donner , there're changes since your first acceptance, do you have any objections?

Do you have a committer for this patch?

Re: avoiding ntohl(): that would be possible, but probably not within the scope of this change.

I am accepting this without the IPSTAT_INC(ips_forward) issue being fixed, as it looks to me as if that is an existing and separate problem in the code. Probably a walk through should be done to see that ips_forward and ips_cantforward are all done correctly.

In D29968#673077, @rgrimes wrote:

I would still like to see the "169.254.0.0/16" changed to IN_LINKLOCAL, purpose of macro is to locate this value one place and one place only, scattering this string in the code undoes that.

I would still like to see the "169.254.0.0/16" changed to IN_LINKLOCAL, purpose of macro is to locate this value one place and one place only, scattering this string in the code undoes that.

Update as @rgrimes suggested.

So we are currently handle all multicast packets from LL sources as locally handled streams regardless of the destination.
That might be correct, even if the local machine is processing the multicast destination itself. So it is able to receive such stream over the local link.

Then the condition belongs to line 740
if (V_ip_mrouter && !IN_LINKLOCAL{(ntohl(ip->ip_src.s_addr))) {

Added full context.

In D29968#672749, @donner wrote:

May you please add context to the diff?

May you please add context to the diff?

RFC 3927 2.7: Do not forward IPv4 packets with a Link-Local source address even if they have a multicast destination address.

In D29968#672733, @karels wrote:

Moving the code down fixes a couple of problems, but it introduces a new one: multicasts from link-locals can be forwarded if we are a multicast router. Maybe add a separate check in that section? We should still receive such multicasts.

Moving the code down fixes a couple of problems, but it introduces a new one: multicasts from link-locals can be forwarded if we are a multicast router. Maybe add a separate check in that section? We should still receive such multicasts.

LGTM

While we are here, may you reformat the code to match style(9).
swicth and case does line up:

I agree that this makes the code more readable.
The patch should be rebased though. There's a conflict in netinet/libalias/alias.c.