Hi, Harti, we have used IPv6 transport several weeks now, and it seems all works good. Do you want to see the full final patch that we use?

In D17180#367402, @tuexen wrote:

So I can update the patch to cover also if_tap.c, but for the other tunnelling interfaces could you elaborate why they are also affected?

Maybe add the macro to deduplicate the code? It repeats 4 times...

#define INP_COND_UNLOCK(inp, locked)   \
    if ((locked) == UH_WLOCKED)
        INP_WUNLOCK(inp);
    else
        INP_RUNLOCK(inp);

It seems the problem, when old MTU is used after changing MTU on interface, also affects all tunneling interfaces gif, gre, ipsec etc. Also, for me it would be better to hide AF-related things like nd6_setmtu() in the rt_updatemtu() implementation.

Upload the full diff.

Deduplicate the code that deletes softc from srchash.
And add another IPSEC_WAIT() to fix possible race in ipsec_if_input().

So, local TCP communications using IPv6 link-local addresses also affected by routing caching. Note, should be used addresses that are configured on non-loopback interfaces.
Simple test:

So, I finally found the cause of strange behavior. It is due to the route caching. Reverting of this change makes it working https://svnweb.freebsd.org/base/head/sys/netinet6/udp6_usrreq.c?r1=304545&r2=304713

Hi, Harti, can you upload the full patch that contains Makefile changes? :)

In D16851#359111, @thj wrote:

What you think, if we make non-static ip6_checkfirstfrag() function, that can also be used by ipfw/pf/ipfil etc.?

I understand from conversations during BSDCam that ipfw relies on frag6 for fragment input processing.
I have no problem exposing this function for other users.

In D16851#359108, @ae wrote:

Also, I think ipfw/pf needs an additional look to correctly handle this too.

Also, I think ipfw/pf needs an additional look to correctly handle this too.

In D16808#357933, @mjoras wrote:

@ae tested the original diff (D11370) and found that the lock overhead did have a measurable decrease in their forwarding performance. I'd be curious to see if there's a win here in taking the liveness-locking back out.

I'll try to use this patch in several days and will report.

In D16654#354295, @harti wrote:

Sure the interface index is not the best thing in a config file, but this is how all the interface-related stuff in SNMP works. The primary key is the interface index. As far as I understand it was once supposed to be constant even through reboots, but this is obviously not the case anymore. I see several options to make this more useable:

• use the dns(16) address type. This allows using interface names for the scope of link local addresses.
• add functions to the config parser. One function might resolve interface names or descriptions to interfaces indexes.
• add functionality for GET/GETNEXT to the config parser. This is more tricky than it seems since this requires more control of the initialization order.

Hi, Harti, while I was on the vacation, you made the patch :)
You can take a look to what I did before the vacation https://people.freebsd.org/~ae/bsnmpd_ipv6.diff
It is incomplete, but I started to make it differently. Maybe you will find something interesting.

I have no objection.

In D15789#334391, @bz wrote:

right; I wonder if you could add about 500k routes for IPv4 and about (no idea 50k let's think ahead?) for IPv6 and then do about 25 route updates per second randomly in the address space; that would be an amazingly interesting test case (especially if you can provide the framework for that somewhere). I guess to see the initial table one could get an MRT dump from say https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/ris-raw-data or some of the others https://bgpstream.caida.org/data . I am neither saying you have to or that this should prevent this change from going in; it's just one of the things I have thought of for years related to some similar changes and others to have as a "router test bed scenario".

Committed in rS334707 and rS334709.