carp: fix mbuf_tag usage in carp_macmatch6

[ae]

Summary

carp_macmatch6() had two issues that affect IPv6 processing:

1. it returns sc->sc_addr pointer that might become invalid after softc destroying.
2. carp_output() expects carp vhid to be stored in the mtag, not the pointer to softc.

Fix these issues. Allocate enough space in mtag to keep both vhid and
mac address. Copy vhid first to fix issue with carp_output(), then
copy sc_addr and return pointer to this copy. mtag will be alive
until mbuf is used.
This fixes problem when IPv6 packets originated from CARP IPv6 address
use incorrect mac address due to mbuf_tag has invalid data.

Test Plan

Before patch:

12:51:23.971006 00:00:5e:00:01:00 > 84:46:fe:e9:3a:fb, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::1 > fe80::8646:feff:fee9:3afb: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::8646:feff:fee9:3afb
	  source link-address option (1), length 8 (1): 00:00:5e:00:01:09
12:51:23.979630 84:46:fe:e9:3a:fb > 00:00:5e:00:01:09, ethertype IPv6 (0x86dd), length 86: (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::8646:feff:fee9:3afb > fe80::1: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is fe80::8646:feff:fee9:3afb, Flags [router, solicited, override]
	  destination link-address option (2), length 8 (1): 84:46:fe:e9:3a:fb

ICMPv6 NS there uses 00:00:5e:00:01:00 mac that is incorrect, since it has zeor vhid. In this example ICMPv6 NA was replied to correct mac address, but some systems use to reply mac address with zero vhid that was used as source in NS request and then such replies are ignored, because carp_forus() can not find corresponding address:

22:05:44.474698 00:00:5e:00:01:00 > ae:f2:39:45:ca:b7, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::1 > fe80::18b2:bf65:4abf:869
3: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::18b2:bf65:4abf:8693
          source link-address option (1), length 8 (1): 00:00:5e:00:01:2f
22:05:44.474937 ae:f2:39:45:ca:b7 > 00:00:5e:00:01:00, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::18b2:bf65:4abf:8693 > fe80::
1: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is fe80::18b2:bf65:4abf:8693, Flags [solicited]
          destination link-address option (2), length 8 (1): ae:f2:39:45:ca:b7

In this case system ignores received ICMPv6 NA and can not resolve IPv6<->MAC pairs.

After patch:

11:43:41.905788 00:00:5e:00:01:09 > 84:46:fe:e9:3a:fb, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::1 > fe80::8646:feff:fee9:3afb: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::8646:feff:fee9:3afb
	  source link-address option (1), length 8 (1): 00:00:5e:00:01:09
11:43:41.915472 84:46:fe:e9:3a:fb > 00:00:5e:00:01:09, ethertype IPv6 (0x86dd), length 86: (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::8646:feff:fee9:3afb > fe80::1: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is fe80::8646:feff:fee9:3afb, Flags [router, solicited, override]
	  destination link-address option (2), length 8 (1): 84:46:fe:e9:3a:fb

[zlei]

Looks good to me.

sys/netinet/ip_carp.c

1707

The new allocated mtag shall not overlap with any members of sc, so memcpy() is safe to use here, instead of bcopy().

1713

Ditto.

[kp]

It'd be really nice having a test case for this too.

sys/netinet/ip_carp.c

1700–1713

Would it be worth defining a 'struct carp_mtag' for this?
Although that's more of a separate cleanup commit thing than something that has to be done at the same time as this.