Re: kern/42386: amd64 dom0/domU IPv6 neighbor solicitations don't work.

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

The following reply was made to PR port-xen/42386; it has been noted by GNATS.

From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: tech-net%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost, 
netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/42386: amd64 dom0/domU IPv6 neighbor solicitations don't work.
Date: Sun, 29 Nov 2009 17:04:05 +0100

 On Sun, Nov 29, 2009 at 12:55:00AM +0000, liman%cafax.se@localhost wrote:
 >      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.
 
 I think this is an issue because the packets are bridged.
 From what I've seen the incoming neighbor solicitation on dom0
 is dropped and accounts in "multicast packets which we don't join"
 in netstat -pinet6 output (and also "packets not forwardable").
 It's being dropped in this code part of ip6_input():
         if (IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst)) {
                 struct  in6_multi *in6m = 0;
 
                 in6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_mcast);
                 /*
                  * See if we belong to the destination multicast group on the
                  * arrival interface.
                  */
                 IN6_LOOKUP_MULTI(ip6->ip6_dst, m->m_pkthdr.rcvif, in6m);
                 if (in6m)
                         ours = 1;
                 else if (!ip6_mrouter) {
                         uint64_t *ip6s = IP6_STAT_GETREF();
                         ip6s[IP6_STAT_NOTMEMBER]++;
                         ip6s[IP6_STAT_CANTFORWARD]++;
                         IP6_STAT_PUTREF();
                         in6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_discard);
                         goto bad;
                 }
                 deliverifp = m->m_pkthdr.rcvif;
                 goto hbhcheck;
         }
 
 on my system RAs from domU to dom0 are sent to ff02::1:ff00:1, ether
 multicast 33:33:ff:00:00:01 while RAs from dom0 to domU are sent
 to ff02::1:ff00:2, ether mutlticast 33:33:ff:00:00:02
 
 I don't know why the domU responds to ff02::1:ff00:2 while the dom0
 doesn't reply to ff02::1:ff00:1
 
 dom0 replies to a ping6 ff02::1:ff00:1%wm0 from dom0,  but not the domU.
 domU replies to a ping6 ff02::1:ff00:2%xvif1.0 from dom0, but not the dom0.
 Nothing replies to ping6 ff02::1:ff00:2%wm0
 
 from the domU, no replies from ping6 ff02::1:ff00:1%xennet0,
 domU replies to ff02::1:ff00:2%xennet0
 
 I don't know what the correct behavior is supposed to be, nor how to
 fix the problem (exept keeping a ping6 in the background on dom0 to
 make sure the domUs have the right entries in their routing
 table).
 
 -- 
 Manuel Bouyer <bouyer%antioche.eu.org@localhost>
      NetBSD: 26 ans d'experience feront toujours la difference
 --