Cc'ing kvm folks as they may have a shared interest on the shared
physical case with the bridge (non NAT).
On Tue, Feb 11, 2014 at 12:43 AM, Ian Campbell <[email protected]> wrote:
> On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez" <[email protected]>
>>
>> Although the xen-netback interfaces do not participate in the
>> link as a typical Ethernet device interfaces for them are
>> still required under the current archtitecture. IPv6 addresses
>> do not need to be created or assigned on the xen-netback interfaces
>> however, even if the frontend devices do need them, so clear the
>> multicast flag to ensure the net core does not initiate IPv6
>> Stateless Address Autoconfiguration.
>
> How does disabling SAA flow from the absence of multicast?
See patch 1 in this series [0], but I explain the issue I see with
this on the cover letter [1]. In summary the RFCs on IPv6 make it
clear you need multicast for Stateless address autoconfiguration
(SLAAC is the preferred acronym) and DAD, however the net core has not
made this a requirement, and hence the patch. The caveat which I
address on the cover letter needs to be seriously considered though.
[0] http://marc.info/?l=linux-netdev&m=139207142110535&w=2
[1] http://marc.info/?l=linux-netdev&m=139207142110536&w=2
> Surely these should be controlled logically independently even if there is some
> notional linkage.
When a node hops on a network it will query its network by sending a
router solicitation multicast request for its configuration
parameters, the router can respond with router advertisements to
disable SLAAC.
Apart from that we have no other means to disable SLAAC neatly, and as
I gather that would be counter to the IPv6 RFCs anyway, and that makes
sense.
> Can SAA not be disabled directly?
Nope. The ipv6 core assumes all device want ipv6 and this is done upon
netdev registration, and as I noted on my patch 1 description --
although ipv6 supports a module parameter to disable autoconfiguration
RFC4682 Section 5.4 makes it clear that DAD *MUST* be performed on all
unicast addresses prior to assigning them to an interface, regardless
of
whether they are obtained through SLAAC, DHCPv6, or manual configuration.
Upon NETDEV_REGISTER the ipv6 core has 2 struct ipv6_devconf sets of
configurations which could get slapped onto devices, neither of these
disable autoconfiguration, its not a knob with a design purpose to let
devices disable freely -- and technically the RFCs for IPv6 simply
imply that you should not use IPv6 if you do cannot support multicast.
Given that the noautoconf module parameter exists though I think my
patch can be considered upstream after addressing the caveat I noted
on not-NBMA links (and I now I think I know how to address that, we
can just make the MULTICAST flag more meaninful for the dev->type).
A nasty hack to disable IPv6 for testing purposes is to set the MTU to
something lower than IPV6_MIN_MTU (1280) and in fact IPv4 can also be
disabled by setting it to 67, that will disable both IPv6 and IPv4.
That's obviously just that, a nasty nasty hack, but useful for easy
testing of disabling either ipv6 completely or both.
>> Clearing the multicast
>> flag is required given that the net_device is using the
>> ether_setup() helper.
>>
>> There's also no good reason why the special MAC address of
>> FE:FF:FF:FF:FF:FF is being used other than to avoid issues
>> with STP,
>
> With your change there is a random probability on reboot that the bridge
> will end up with a randomly generated MAC address instead of a static
> MAC address (usually that of the physical NIC on the bridge), since the
> bridge tends to inherit the lowest MAC of any port.
I had not considered the bridge taking the lowest MAC address of any
port added! So that was one of the tricks with the fixed MAC address
of FE:FF:FF:FF:FF:FF, to ensure the bridge would skip using its mac
address when it was later added as a port. Another collateral issue if
this is *not* considered is that if a xen-netback interface has a MAC
address lower than the general interface one and if you shutdown that
guest, and therefore removed it from the bridge, the bridge MAC
address will also change once again back to the general interface one.
This will cause a hiccup on accessing the device, while ARP settles
things. If doing a massive shutdown / reboot of guests that have a
series of MAC addresses lower than the general interface one is a
series of MAC address changes on the bridge.
FWIW kvm seems to completely randomize the MAC address of the backend
TAP interfaces (while the front end virtio driver fully randomizes
it), but note that in the NAT use case where only the TAP interfaces
get added the above is not an issue, although I suspect if the shared
connection is used this could be a problem, it will depend on what
tools create the TAP interface and how.
I suspect we may have a shared concern here and I wonder if kvm hit
the snags described above on the shared physical cases. Curious if kvm
folks have seen these issues?
> Since IP configuration is done on the bridge this will break DHCP,
> whether it is using static or dynamic mappings from MAC to IP address,
> and the host will randomly change IP address on reboot.
Its beyond that, as I noted as well there can be issues upon shutdown.
> So Nack for that reason.
Makes sense. Will think about this a bit more.
>> since using this can create an issue if a user
>> decides to enable multicast on the backend interfaces
>
> Please explain what this issue is.
I explained this on the cover letter but should have elaborated more
here. The *known* and *reported* issue is that xen-backend interfaces
can end up SLAAC and you'd obviously end up in some situations where
the MAC address and IP address clash, despite the architecture of IPv6
to randomize time requests for neighbor solicitations, and DAD.
Ultimately a series of services can end up filling your log messages
with tons of warnings.
Another not reported issue, but I suspect critical and it can bite
both xen and kvm in the ass is described on Appendex A on RFC 4862 [2]
which considers the issues of getting duplicates of packets on the
same link with the same link layer address. I think to address that we
can also consider dev->type into all the different cases.
What drove these patches is trying to find a proper upstream approach
to Olaf's old xen ipv6-no-autoconf patch [3]. Although not stated on
the patch I have seen some old year 2006 internal reports even with
the static FE:FF:FF:FF:FF:FF MAC address, whereby the xen-netback
interfaces kicked off IPv6 SLAAC and DAD. IPv6 SLAAC should trigger
once the link goes up.
My preference, rather than trying to simply disable ipv6 is actually
seeing how xen-netback interfaces (and kvm TAP topology) can be
simplified further). As I see it there is tons of code which could
trigger being used on these xen-netback interfaces (and TAP for kvm)
which is simply not needed for the use case of just doing sending data
back and forth between host and guest: ipv6 is not needed at all, and
I tried to test removing ipv4, but ran into issues.
[2] http://tools.ietf.org/html/rfc4862#appendix-A
[3[ https://gitorious.org/opensuse/kernel-source/source/8e16582178a29b03e850468004a47e7be5ed3005:patches.xen/ipv6-no-autoconf
> Also how can a user enable multicast on the b/e?
ip set multicast on dev <devname>
ip set multicast off dev <devname>
> AFAIK only Solaris ever
> implemented the m/c bits of the Xen PV network protocol (not that I
> wouldn't welcome attempts to add it to other platforms)
Do you mean kernel configuration multicast ? Or networking ?
Luis
On Tue, 2014-02-11 at 13:53 -0800, Luis R. Rodriguez wrote:
> Cc'ing kvm folks as they may have a shared interest on the shared
> physical case with the bridge (non NAT).
>
> On Tue, Feb 11, 2014 at 12:43 AM, Ian Campbell <[email protected]> wrote:
> > On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
> >> From: "Luis R. Rodriguez" <[email protected]>
> >>
> >> Although the xen-netback interfaces do not participate in the
> >> link as a typical Ethernet device interfaces for them are
> >> still required under the current archtitecture. IPv6 addresses
> >> do not need to be created or assigned on the xen-netback interfaces
> >> however, even if the frontend devices do need them, so clear the
> >> multicast flag to ensure the net core does not initiate IPv6
> >> Stateless Address Autoconfiguration.
> >
> > How does disabling SAA flow from the absence of multicast?
>
> See patch 1 in this series [0], but I explain the issue I see with
> this on the cover letter [1].
Oop, I felt like I'd missed some context. Thanks for pointing out that
it was right under my nose.
> In summary the RFCs on IPv6 make it
> clear you need multicast for Stateless address autoconfiguration
> (SLAAC is the preferred acronym) and DAD,
That seems reasonable, but I think is the opposite to what I was trying
to get at.
Why is it not possible to disable SLAAC and/or DAD even if multicast is
present?
IOW -- enabling/disabling multicast seems to me to be an odd proxy for
disabling SLAAC or DAD and AIUI your patch fixes the opposite case,
which is to avoid SLAAC and DAD on interfaces which don't do multicast
(which makes sense since those protocols involve multicast).
> however the net core has not
> made this a requirement, and hence the patch. The caveat which I
> address on the cover letter needs to be seriously considered though.
>
> [0] http://marc.info/?l=linux-netdev&m=139207142110535&w=2
> [1] http://marc.info/?l=linux-netdev&m=139207142110536&w=2
>
> > Surely these should be controlled logically independently even if there is some
> > notional linkage.
>
> When a node hops on a network it will query its network by sending a
> router solicitation multicast request for its configuration
> parameters, the router can respond with router advertisements to
> disable SLAAC.
Surely it should be possible for an interface to be explicitly not ipv6
enabled, in which case it doesn't want to do any solicitation at all.
> Apart from that we have no other means to disable SLAAC neatly, and as
> I gather that would be counter to the IPv6 RFCs anyway, and that makes
> sense.
In your[0] post you say:
it should be noted that RFC4682 Section 5.4
makes it clear that DAD *MUST* be performed on all unicast
addresses prior to assigning them to an interface
is that what you mean by counter to the RFCs?
In my reading this "must do DAD" requirement only comes into affect if
you are trying to assign a unicast address to an interface. It should be
possible to simply not do that for an interface.
> > Can SAA not be disabled directly?
>
> Nope. The ipv6 core assumes all device want ipv6
IMHO it is entirely reasonable for an admin to desire that an interface
has nothing at all to do with IPv6. At which point all of the
requirements for multicast which flow from enabling IPv6 disappear.
> >> since using this can create an issue if a user
> >> decides to enable multicast on the backend interfaces
> >
> > Please explain what this issue is.
>
> I explained this on the cover letter but should have elaborated more
> here. The *known* and *reported* issue is that xen-backend interfaces
> can end up SLAAC and you'd obviously end up in some situations where
> the MAC address and IP address clash, despite the architecture of IPv6
> to randomize time requests for neighbor solicitations, and DAD.
> Ultimately a series of services can end up filling your log messages
> with tons of warnings.
Right, this makes sense, but it seems like the solution should be to
stop SLAAC from happening directly and not by playing tricks with
multicast that happen to have the side effect of disabling SLAAC.
> Another not reported issue, but I suspect critical and it can bite
> both xen and kvm in the ass is described on Appendex A on RFC 4862 [2]
> which considers the issues of getting duplicates of packets on the
> same link with the same link layer address. I think to address that we
> can also consider dev->type into all the different cases.
We should never actually be generating any traffic with this address
FWIW, all the generated traffic will have the guest's actual MAC. (at
least in the bridging case, perhaps with with routing or NAT things are
different, but I think in that case the traffic would appear to come
from the hosts outgoing interface, not the vif device)
> My preference, rather than trying to simply disable ipv6 is actually
> seeing how xen-netback interfaces (and kvm TAP topology) can be
> simplified further). As I see it there is tons of code which could
> trigger being used on these xen-netback interfaces (and TAP for kvm)
> which is simply not needed for the use case of just doing sending data
> back and forth between host and guest: ipv6 is not needed at all, and
> I tried to test removing ipv4, but ran into issues.
Bridging is not the only way to provide VM network connectivity. It
should also be possible to do routing and even NAT by configuring
appropriate p2p links and routing tables in the host. For that to work I
think the tap and vif devices do need some sort of IPv[46] capability,
so you can't just nuke that stuff completely. (Maybe/likely it also
requires them to have a sensible MAC address, I'm not sure).
> [2] http://tools.ietf.org/html/rfc4862#appendix-A
> [3[ https://gitorious.org/opensuse/kernel-source/source/8e16582178a29b03e850468004a47e7be5ed3005:patches.xen/ipv6-no-autoconf
>
> > Also how can a user enable multicast on the b/e?
>
> ip set multicast on dev <devname>
> ip set multicast off dev <devname>
>
> > AFAIK only Solaris ever
> > implemented the m/c bits of the Xen PV network protocol (not that I
> > wouldn't welcome attempts to add it to other platforms)
>
> Do you mean kernel configuration multicast ? Or networking ?
I meant the PV protocol extension which allows guests (netfront) to
register to receive multicast frames across the PV ring -- i.e. for
multicast to work from the guests PoV.
(maybe that was just an optimisation though and the default is to flood
everything, it was a long time ago)
Ian.
On Tue, Feb 11, 2014 at 01:53:26PM -0800, Luis R. Rodriguez wrote:
> Cc'ing kvm folks as they may have a shared interest on the shared
> physical case with the bridge (non NAT).
>
> On Tue, Feb 11, 2014 at 12:43 AM, Ian Campbell <[email protected]> wrote:
> > On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
> >> From: "Luis R. Rodriguez" <[email protected]>
> >>
> >> Although the xen-netback interfaces do not participate in the
> >> link as a typical Ethernet device interfaces for them are
> >> still required under the current archtitecture. IPv6 addresses
> >> do not need to be created or assigned on the xen-netback interfaces
> >> however, even if the frontend devices do need them, so clear the
> >> multicast flag to ensure the net core does not initiate IPv6
> >> Stateless Address Autoconfiguration.
> >
> > How does disabling SAA flow from the absence of multicast?
>
> See patch 1 in this series [0], but I explain the issue I see with
> this on the cover letter [1]. In summary the RFCs on IPv6 make it
> clear you need multicast for Stateless address autoconfiguration
> (SLAAC is the preferred acronym) and DAD, however the net core has not
> made this a requirement, and hence the patch. The caveat which I
> address on the cover letter needs to be seriously considered though.
>
> [0] http://marc.info/?l=linux-netdev&m=139207142110535&w=2
> [1] http://marc.info/?l=linux-netdev&m=139207142110536&w=2
>
> > Surely these should be controlled logically independently even if there is some
> > notional linkage.
>
> When a node hops on a network it will query its network by sending a
> router solicitation multicast request for its configuration
> parameters, the router can respond with router advertisements to
> disable SLAAC.
>
> Apart from that we have no other means to disable SLAAC neatly, and as
> I gather that would be counter to the IPv6 RFCs anyway, and that makes
> sense.
>
> > Can SAA not be disabled directly?
>
> Nope. The ipv6 core assumes all device want ipv6 and this is done upon
> netdev registration, and as I noted on my patch 1 description --
> although ipv6 supports a module parameter to disable autoconfiguration
> RFC4682 Section 5.4 makes it clear that DAD *MUST* be performed on all
FWIW: RFC4862 :-)
You had the same typo in patch 1.
Wei.
On Wed, 12 Feb 2014, Ian Campbell wrote:
> On Tue, 2014-02-11 at 13:53 -0800, Luis R. Rodriguez wrote:
> > Cc'ing kvm folks as they may have a shared interest on the shared
> > physical case with the bridge (non NAT).
> >
> > On Tue, Feb 11, 2014 at 12:43 AM, Ian Campbell <[email protected]> wrote:
> > > On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
> > >> From: "Luis R. Rodriguez" <[email protected]>
> > >>
> > >> Although the xen-netback interfaces do not participate in the
> > >> link as a typical Ethernet device interfaces for them are
> > >> still required under the current archtitecture. IPv6 addresses
> > >> do not need to be created or assigned on the xen-netback interfaces
> > >> however, even if the frontend devices do need them, so clear the
> > >> multicast flag to ensure the net core does not initiate IPv6
> > >> Stateless Address Autoconfiguration.
> > >
> > > How does disabling SAA flow from the absence of multicast?
> >
> > See patch 1 in this series [0], but I explain the issue I see with
> > this on the cover letter [1].
>
> Oop, I felt like I'd missed some context. Thanks for pointing out that
> it was right under my nose.
>
> > In summary the RFCs on IPv6 make it
> > clear you need multicast for Stateless address autoconfiguration
> > (SLAAC is the preferred acronym) and DAD,
>
> That seems reasonable, but I think is the opposite to what I was trying
> to get at.
>
> Why is it not possible to disable SLAAC and/or DAD even if multicast is
> present?
>
> IOW -- enabling/disabling multicast seems to me to be an odd proxy for
> disabling SLAAC or DAD and AIUI your patch fixes the opposite case,
> which is to avoid SLAAC and DAD on interfaces which don't do multicast
> (which makes sense since those protocols involve multicast).
Forgive me if this doesn't make sense in this context since
I'm not a kernel developer, but I was just wondering if any of
the sysctls:
/proc/sys/net/ipv6/conf/<ifc>/disable_ipv6
/proc/sys/net/ipv6/conf/<ifc>/accept_dad
/proc/sys/net/ipv6/conf/<ifc>/accept_ra
/proc/sys/net/ipv6/conf/<ifc>/autoconf
would be apropos for the requirement being discussed.
-Bill
On Wed, Feb 12, 2014 at 9:17 AM, Bill Fink <[email protected]> wrote:
> On Wed, 12 Feb 2014, Ian Campbell wrote:
>> IOW -- enabling/disabling multicast seems to me to be an odd proxy for
>> disabling SLAAC or DAD and AIUI your patch fixes the opposite case,
>> which is to avoid SLAAC and DAD on interfaces which don't do multicast
>> (which makes sense since those protocols involve multicast).
>
> Forgive me if this doesn't make sense in this context since
> I'm not a kernel developer, but I was just wondering if any of
> the sysctls:
>
> /proc/sys/net/ipv6/conf/<ifc>/disable_ipv6
> /proc/sys/net/ipv6/conf/<ifc>/accept_dad
> /proc/sys/net/ipv6/conf/<ifc>/accept_ra
> /proc/sys/net/ipv6/conf/<ifc>/autoconf
>
> would be apropos for the requirement being discussed.
These are run time configuration options, post initialization. What
we're considering is internal net_device capability fields, to even
avoid creating these in the first place.
Luis
On Wed, Feb 12, 2014 at 3:15 AM, Ian Campbell <[email protected]> wrote:
> On Tue, 2014-02-11 at 13:53 -0800, Luis R. Rodriguez wrote:
>> Cc'ing kvm folks as they may have a shared interest on the shared
>> physical case with the bridge (non NAT).
>>
>> On Tue, Feb 11, 2014 at 12:43 AM, Ian Campbell <[email protected]> wrote:
>> > On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
>> >> From: "Luis R. Rodriguez" <[email protected]>
>> >>
>> >> Although the xen-netback interfaces do not participate in the
>> >> link as a typical Ethernet device interfaces for them are
>> >> still required under the current archtitecture. IPv6 addresses
>> >> do not need to be created or assigned on the xen-netback interfaces
>> >> however, even if the frontend devices do need them, so clear the
>> >> multicast flag to ensure the net core does not initiate IPv6
>> >> Stateless Address Autoconfiguration.
>> >
>> > How does disabling SAA flow from the absence of multicast?
>>
>> See patch 1 in this series [0], but I explain the issue I see with
>> this on the cover letter [1].
>
> Oop, I felt like I'd missed some context. Thanks for pointing out that
> it was right under my nose.
>
>> In summary the RFCs on IPv6 make it
>> clear you need multicast for Stateless address autoconfiguration
>> (SLAAC is the preferred acronym) and DAD,
>
> That seems reasonable, but I think is the opposite to what I was trying
> to get at.
>
> Why is it not possible to disable SLAAC and/or DAD even if multicast is
> present?
Even if you set your IP address manually you still need to send router
solicitations using multicast, you also need to do DAD.
> IOW -- enabling/disabling multicast seems to me to be an odd proxy for
> disabling SLAAC or DAD and AIUI your patch fixes the opposite case,
> which is to avoid SLAAC and DAD on interfaces which don't do multicast
> (which makes sense since those protocols involve multicast).
Agreed :)
>> however the net core has not
>> made this a requirement, and hence the patch. The caveat which I
>> address on the cover letter needs to be seriously considered though.
>>
>> [0] http://marc.info/?l=linux-netdev&m=139207142110535&w=2
>> [1] http://marc.info/?l=linux-netdev&m=139207142110536&w=2
>>
>> > Surely these should be controlled logically independently even if there is some
>> > notional linkage.
>>
>> When a node hops on a network it will query its network by sending a
>> router solicitation multicast request for its configuration
>> parameters, the router can respond with router advertisements to
>> disable SLAAC.
>
> Surely it should be possible for an interface to be explicitly not ipv6
> enabled, in which case it doesn't want to do any solicitation at all.
There are run time configuration options, but not net_device flags.
More on this below.
>> Apart from that we have no other means to disable SLAAC neatly, and as
>> I gather that would be counter to the IPv6 RFCs anyway, and that makes
>> sense.
>
> In your[0] post you say:
> it should be noted that RFC4682 Section 5.4
> makes it clear that DAD *MUST* be performed on all unicast
> addresses prior to assigning them to an interface
>
> is that what you mean by counter to the RFCs?
Yeap.
> In my reading this "must do DAD" requirement only comes into affect if
> you are trying to assign a unicast address to an interface. It should be
> possible to simply not do that for an interface.
That is correct, why enable ipv6 then on that interfaces then? We have
the loopback for local stuff.
>> > Can SAA not be disabled directly?
>>
>> Nope. The ipv6 core assumes all device want ipv6
>
> IMHO it is entirely reasonable for an admin to desire that an interface
> has nothing at all to do with IPv6. At which point all of the
> requirements for multicast which flow from enabling IPv6 disappear.
Agreed.
>> >> since using this can create an issue if a user
>> >> decides to enable multicast on the backend interfaces
>> >
>> > Please explain what this issue is.
>>
>> I explained this on the cover letter but should have elaborated more
>> here. The *known* and *reported* issue is that xen-backend interfaces
>> can end up SLAAC and you'd obviously end up in some situations where
>> the MAC address and IP address clash, despite the architecture of IPv6
>> to randomize time requests for neighbor solicitations, and DAD.
>> Ultimately a series of services can end up filling your log messages
>> with tons of warnings.
>
> Right, this makes sense, but it seems like the solution should be to
> stop SLAAC from happening directly and not by playing tricks with
> multicast that happen to have the side effect of disabling SLAAC.
Agreed, however as I see it since yesterday the requirement for
multicast for IPv6 should likely become a requirement for dev->type
ether, there however is a module parameter to disable autoconf
completely though so I believe there may be some ether dev->type
devices out there with IPv6 without multicast, and while that seems
counter to the requirements on the RFCs it is something to consider.
At this point I consider the above a separate discussion (but one I'll
follow up with an RFCv2 patch), given that it seems we are in
agreement we should *consider* the ability to disable ipv6 all
together from a net_device. More on this below.
>> Another not reported issue, but I suspect critical and it can bite
>> both xen and kvm in the ass is described on Appendex A on RFC 4862 [2]
>> which considers the issues of getting duplicates of packets on the
>> same link with the same link layer address. I think to address that we
>> can also consider dev->type into all the different cases.
>
> We should never actually be generating any traffic with this address
> FWIW, all the generated traffic will have the guest's actual MAC. (at
> least in the bridging case, perhaps with with routing or NAT things are
> different, but I think in that case the traffic would appear to come
> from the hosts outgoing interface, not the vif device)
Which leads me to believe that creating a regular interface for a
backend interface seems overkill. I'm evaluating the minimal
requirements on the xen-backend case for an interface and believe this
can likely be shared with as a type of interface with kvm. Furthermore
the bridging could then be extended to not use its MAC address for the
root port even if STP were enabled.
>> My preference, rather than trying to simply disable ipv6 is actually
>> seeing how xen-netback interfaces (and kvm TAP topology) can be
>> simplified further). As I see it there is tons of code which could
>> trigger being used on these xen-netback interfaces (and TAP for kvm)
>> which is simply not needed for the use case of just doing sending data
>> back and forth between host and guest: ipv6 is not needed at all, and
>> I tried to test removing ipv4, but ran into issues.
>
> Bridging is not the only way to provide VM network connectivity. It
> should also be possible to do routing and even NAT by configuring
> appropriate p2p links and routing tables in the host. For that to work I
> think the tap and vif devices do need some sort of IPv[46] capability,
We have to be careful for sure, I'll try to test all cases including
kvm, but architecturally as I see it so far these things are simply
exchanging over data through their respective backend channels, I know
ipv6 interfaces are unused and I'm going to dig further to see why at
least one ipv4 interfaces is needed. I cannot fathom why either of
these interfaces would be required. I'll do a bit more digging.
The TAP interface requirements may be different, I haven't yet dug into that.
> so you can't just nuke that stuff completely. (Maybe/likely it also
> requires them to have a sensible MAC address, I'm not sure).
I'll dig.
>> [2] http://tools.ietf.org/html/rfc4862#appendix-A
>> [3[ https://gitorious.org/opensuse/kernel-source/source/8e16582178a29b03e850468004a47e7be5ed3005:patches.xen/ipv6-no-autoconf
>>
>> > Also how can a user enable multicast on the b/e?
>>
>> ip set multicast on dev <devname>
>> ip set multicast off dev <devname>
>>
>> > AFAIK only Solaris ever
>> > implemented the m/c bits of the Xen PV network protocol (not that I
>> > wouldn't welcome attempts to add it to other platforms)
>>
>> Do you mean kernel configuration multicast ? Or networking ?
>
> I meant the PV protocol extension which allows guests (netfront) to
> register to receive multicast frames across the PV ring -- i.e. for
> multicast to work from the guests PoV.
Not quite sure I understand, ipv6 works on guests so multicast works,
so its unclear what you mean by multicast frames across the PV ring.
Is there any code or or documents I can look at ?
> (maybe that was just an optimisation though and the default is to flood
> everything, it was a long time ago)
>From a networking perspective everything is being flooded as I've seen
it so far.
Luis
On Wed, Feb 12, 2014 at 2:05 PM, Luis R. Rodriguez
<[email protected]> wrote:
> We have to be careful for sure, I'll try to test all cases including
> kvm, but architecturally as I see it so far these things are simply
> exchanging over data through their respective backend channels, I know
> ipv6 interfaces are unused and I'm going to dig further to see why at
> least one ipv4 interfaces is needed. I cannot fathom why either of
> these interfaces would be required. I'll do a bit more digging.
>
> The TAP interface requirements may be different, I haven't yet dug into that.
I have a test patch that now works that restricts xen-netback from
getting any IPv4 and IPv6 addresses, and disables multicast. With this
set in place the xen-frontend still gets IPv4 and IPv6 addresses and
Multicast still works. This was tested under a shared physical
environment, I'll have to test NAT next, and also see if we can enable
this as an option for KVM for their TAP 'backend' interfaces.
Luis
On Wed, Feb 12, 2014 at 8:27 PM, Luis R. Rodriguez
<[email protected]> wrote:
> I have a test patch that now works that restricts xen-netback from
> getting any IPv4 and IPv6 addresses, and disables multicast. With this
> set in place the xen-frontend still gets IPv4 and IPv6 addresses and
> Multicast still works. This was tested under a shared physical
> environment, I'll have to test NAT next, and also see if we can enable
> this as an option for KVM for their TAP 'backend' interfaces.
Also perhaps a silly question, as I haven't yet looked carefully into
the qemu TAP usage / requirement yet, but has anyone considered just
having a dma-buf agent for us in userspace ? That'd remove any
redundant interfaces and do let qemu do DMA directly.
Luis
On Wed, 2014-02-12 at 14:05 -0800, Luis R. Rodriguez wrote:
> > I meant the PV protocol extension which allows guests (netfront) to
> > register to receive multicast frames across the PV ring -- i.e. for
> > multicast to work from the guests PoV.
>
> Not quite sure I understand, ipv6 works on guests so multicast works,
> so its unclear what you mean by multicast frames across the PV ring.
> Is there any code or or documents I can look at ?
xen/include/public/io/netif.h talks about 'feature-multicast-control'
and XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL}.
Looking at it now in the absence of those then flooding is the
default...
> > (maybe that was just an optimisation though and the default is to flood
> > everything, it was a long time ago)
>
> From a networking perspective everything is being flooded as I've seen
> it so far.
... which is why it works ;-)
Ian.