port-xen/42386: amd64 dom0/domU IPv6 neighbor solicitations don't work.

[liman%cafax.se@localhost]

>Number:         42386
>Category:       port-xen
>Synopsis:       xen dom0 doesn't respond to IPv6 neighbor solicitations from 
>domU
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    port-xen-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 29 00:55:00 +0000 2009
>Originator:     Lars-Johan Liman
>Release:        NetBSD 5.0.1
>Organization:
#-------------------------------------------------------------------------
# Lars-Johan Liman, M.Sc.                ! E-mail: liman%cafax.se@localhost
# Cafax AB                               ! HTTP  : //www.cafax.se/
# Computer Consultants, Sweden           ! Voice : +46 8 - 564 702 30
#-------------------------------------------------------------------------
>Environment:
System: NetBSD base.cafax.se 5.0.1 NetBSD 5.0.1 (XEN3_DOM0) #0: Thu Jul 30 
00:23:51 UTC 2009  
builds%b7.netbsd.org@localhost:/home/builds/ab/netbsd-5-0-1-RELEASE/amd64/200907292356Z-obj/home/builds/ab/netbsd-5-0-1-RELEASE/src/sys/arch/amd64/compile/XEN3_DOM0
 amd64
Architecture: x86_64
Machine: amd64
>Description:

        [Maybe this should be in the networking category. I don't
        quite know ...]

        An amd64 dom0 does not recognize IPv6 neighbor solicitations
        (NS) from a domU that is connected via an internal bridge.

        The domU _does_ recognize the IPv6 neighbor solicitations
        coming from the dom0 over the same bridge.

        The NSs from the domU _do_ arrive at the dom0:tap0 (verified
        by tcpdump), but they do not trigger a neighbor advertisement
        (NA) from the dom0.

        When pinging from the dom0 towards the domU, and looking at
        the traffic at the domU:xennet0, tcpdump sees both an incoming
        NS, and an outgoing NA, which seems correct.

        The problem doesn't seem to pertain specifically to the tap0.
        If the domU:xennet0 is briged through to dom0:wm0 (or other
        external interface) instead of dom0:tap0, and the domU sends
        ping6 from xennet0 to a physical host on the wire, everything
        works fine. If the domU sends ping6 from xennet0 to dom0:wm0,
        it still doesn't work. Hence, I believe its the something in
        the processing of the NSs that doesn't work in the dom0, but
        it's odd that it _does_ work for packets coming in on the
        physical wm0 from other hosts, so it's the combination of dom0
        and domU somehow ... ?

        I have not investigated whether it pertains to other kinds of
        IPv6 anycast packets than NSs.

        It is also not related to the physical interface being a
        wm0. I've repeated the situation on a totally different
        machine which has a bge0 for external interface.

        IPv4 works just fine all the time.

        I humbly request assistance in solving the problem.

>How-To-Repeat:

        Prerequisites: amd64 machine, NetBSD 5.0.1, Xen 3.3,
                       NetBSD/amd64-dom0, NetBSD/amd64-domU

        dom0 configured as follows:
             ip6mode: router
             wm0: = external interface (can be other type than wm0, e.g. bge0)
                    inet6 2a00:A:B:C::2/64 alias (static config)
             tap0: = internal interface towards domU
                    inet6 2a00:X:Y:Z::1/64 alias (static config)

             bridge0: connects dom0:tap0 to domU:xennet0.

        domU configured as follows:
             ip6mode: host
             xennet0: = interface towards dom0
                    inet6 2a00:X:Y:Z::2/64 alias (static config)

        Now boot the machines and don't touch the IPv6 network (i.e.,
        don't send/receive any IPv6 packets).

        Login to domU (console or over IPv4) and try to ping6 the IPv6
        address on the dom0:tap0. No success. Leave the ping6 running
        in its non-working state.

        Login to dom0 (console or IPv4) and ping6 the IPv6 address of
        the domU:xennet0. Works just fine _AND_ as soon as the first
        ping has traversed the link, the non-working ping6 in the domU
        starts working, since the dom0 has now learnt the MAC address
        of the domU through its own NS process.

>Fix:

        None known. :-(