[Bug 262292] Seemingly not possible for IPv6 to function over tap devices on if_bridge

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262292

            Bug ID: 262292
           Summary: Seemingly not possible for IPv6 to function over tap
                    devices on if_bridge
           Product: Base System
           Version: 13.0-STABLE
          Hardware: amd64
                OS: Any
            Status: New
          Keywords: bhyve, ipv6
          Severity: Affects Only Me
          Priority: ---
         Component: bhyve
          Assignee: virtualization@FreeBSD.org
          Reporter: paul.g.webster@googlemail.com

Good day all,

I run a set of VM's on an if_bridge:

bridge103: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 58:9c:fc:10:ff:f5
        inet 192.168.103.1 netmask 0xffffff00 broadcast 192.168.103.255
        inet6 fe80::5a9c:fcff:fe10:fff5%bridge103 prefixlen 64 scopeid 0x4
        inet6 2a01:4f8:190:1183::103:1 prefixlen 64
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: tap1033 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 9 priority 128 path cost 2000000
        member: tap1032 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 8 priority 128 path cost 2000000
        member: tap1031 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 11 priority 128 path cost 2000000
        member: tap1030 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 10 priority 128 path cost 2000000
        groups: bridge
        nd6 options=63<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_RADR>


IPv4 functionality is working as expected, and ipv6 on the host works
perfectly.

However no guest may ping6 its closest host inet6 address (tap1033->bridge103)
and get a response.

tcpdump reveals that bridge103 received the request, but does not appear to do
anything about it:

root@de1:/usr/venv/bhyve/init # tcpdump -vvi bridge103 icmp6
tcpdump: listening on bridge103, link-type EN10MB (Ethernet), capture size
262144 bytes
20:11:53.073960 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32)
2a01:4f8:190:1183::103:2 > ff02::1:ff03:1: [icmp6 sum ok] ICMP6, neighbor
solicitation, length 32, who has 2a01:4f8:190:1183::103:1
          source link-address option (1), length 8 (1): 00:d3:4d:be:3f:ab
            0x0000:  00d3 4dbe 3fab
20:11:54.120586 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32)
2a01:4f8:190:1183::103:2 > ff02::1:ff03:1: [icmp6 sum ok] ICMP6, neighbor
solicitation, length 32, who has 2a01:4f8:190:1183::103:1
          source link-address option (1), length 8 (1): 00:d3:4d:be:3f:ab
            0x0000:  00d3 4dbe 3fab


The same is true for all other VM's that are connected via virtio/tap to an
if_bridge, bearing in mind the ICMP request is seen perhaps the problem is with
if_bridge.

Unfortunatly I am now somewhat out of my depth with bhyve/if_bridge_tap, I have
tried everything I can possible think of and am hoping someone here knows what
is causing such an issue.

Notable the inet6 that is directly assigned to each bridge is reachable from
the outside, that would be these:

em0:        inet6 2a01:4f8:190:1183::1:1 prefixlen 64
lo0:        inet6 ::1 prefixlen 128
bridge102:  inet6 2a01:4f8:190:1183::102:1 prefixlen 64
bridge103:  inet6 2a01:4f8:190:1183::103:1 prefixlen 64
bridge104:  inet6 2a01:4f8:190:1183::104:1 prefixlen 64

As the VM in the above examples was  2a01:4f8:190:1183::103:2 assigned to
bridge 103, there should be no way it failed to get a response that I can see

-- 
You are receiving this mail because:
You are the assignee for the bug.