[RFC 0/2] xen-backend interfaces and IFF_MULTICAST

[RFC 0/2] xen-backend interfaces and IFF_MULTICAST

[Luis R. Rodriguez]

Virtualization hypervisors do not make use of backend Ethernet interfaces
like typical Ethernet interfaces. In my current testing at least xen-netback
requires at least a struct in_device with a proper MTU setting in order for
the front end interface to function properly. Under the current design this
will kick off ipv6 autoconfiguration and DAD on these interfaces. This does
not happen for xen's TAP interface when HVM is used. KVM only uses TAP
interfaces but their backend interfaces *do not* perform ipv6 autoconfiguration
and DAD even though its TAP interfaces do have multicast enabled.

In xen's case some xen users used to run into issues with the current
architecture when bundles of xen guests were on the same network and ipv6
autoconfiguration was performed. This happens because the MAC address is
static and while this can be corrected by randomizing it an ipv6 address
is simply not needed for them. There is currently no way to disable ipv6
interfaces on specific type of interfaces but this is just begging review
of the architecture on why an interface is even needed at all, how about
ipv4 addresses, why do we need inetdev_init() on these virtualized
interfaces?

Disabling multicast on an interface should disable ipv6 autoconfiguration
and DAD but the note on include/uapi/linux/if_link.h makes it clear that
IFF_MULTICAST should be considered carefully given that not-NBMA links are
known to support multicast, this includes all IFF_POINTOPOINT and IFF_BROADCAST
as well. If we are to follow the RFCs on ipv6 autoconfiguration and DAD
however its clear that muliticast is required -- but if we have no reliable
way of determining this capability we won't know when we could perform
autoconfiguration and DAD properly.

If the patch to require IFF_MULTICAST for autoconfiguration and DAD is
valid then xen-netback can simply clear the flag, clearing it is required
as ether_setup() is used during the net_device allocation. I'm currently
reviewing the need for any proper-mtu interface on xen-netback but in the
meantime I'd like some feedback on IFF_MULTICAST and the following
patches.

Luis R. Rodriguez (2):
  ipv6: disable autoconfiguration and DAD on non-multicast links
  xen-netback: disable multicast and use a random hw MAC address

 drivers/net/xen-netback/interface.c | 14 +++++---------
 net/ipv6/addrconf.c                 | 18 ++++++++++++------
 2 files changed, 17 insertions(+), 15 deletions(-)

-- 
1.8.5.3

[RFC 1/2] ipv6: disable autoconfiguration and DAD on non-multicast links

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

RFC4862 [0] on IPv6 on Stateless Address Autoconfiguration on
Sections 4 and 5 state that autoconfiguration is performed only
on multicast-capable links. Multicast is used to ensure the
automatically assigned address is unique by sending Neighbor
Solicitation Messages and listening for these same messages
on both the all-nodes multicast address and the solicited-node
multicast address of the tentative address, this is called
Duplicate Address Detection (DAD) and documented on Section 5.4.
DAD has an optimization, Optimistic DAD [1] and it also requires
multicast. Skip autoconfiguration and all forms of DAD on
non-multicast links.

We don't *fully* disable IPV6 for non-multicast links as
there are signs non-multicast IPV6 devices are wished to
be supported, one example being the ipv6 autoconf module
parameter, but 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, regardless of
whether they are obtained through stateless autoconfiguration,
DHCPv6, or manual configuration with the following exceptions:

   -  When DupAddrDetectTransmits is set to zero, DAD
      can be skipped
   -  Anycast addresses can skip DAD

In the case that autoconfiguration is disabled the interface
still gets assigned a temporary address via ipv6_create_tempaddr()
however it will be kept as temporary, IFA_F_TEMPORARY.

[0] http://tools.ietf.org/html/rfc4862
[1] http://tools.ietf.org/html/rfc4429

Cc: Olaf Kirch <okir@suse.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: netdev@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 net/ipv6/addrconf.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index ad23569..362f64f 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2211,7 +2211,8 @@ void addrconf_prefix_rcv(struct net_device *dev, u8 *opt, int len, bool sllao)
 
 	/* Try to figure out our local address for this prefix */
 
-	if (pinfo->autoconf && in6_dev->cnf.autoconf) {
+	if (pinfo->autoconf && in6_dev->cnf.autoconf &&
+	    dev->flags & IFF_MULTICAST) {
 		struct inet6_ifaddr *ifp;
 		struct in6_addr addr;
 		int create = 0, update_lft = 0;
@@ -2248,7 +2249,8 @@ ok:
 
 #ifdef CONFIG_IPV6_OPTIMISTIC_DAD
 			if (in6_dev->cnf.optimistic_dad &&
-			    !net->ipv6.devconf_all->forwarding && sllao)
+			    !net->ipv6.devconf_all->forwarding && sllao &&
+			    dev->flags & IFF_MULTICAST)
 				addr_flags = IFA_F_OPTIMISTIC;
 #endif
 
@@ -3161,6 +3163,7 @@ static void addrconf_dad_start(struct inet6_ifaddr *ifp)
 		goto out;
 
 	if (dev->flags&(IFF_NOARP|IFF_LOOPBACK) ||
+	    !(dev->flags&IFF_MULTICAST) ||
 	    idev->cnf.accept_dad < 1 ||
 	    !(ifp->flags&IFA_F_TENTATIVE) ||
 	    ifp->flags & IFA_F_NODAD) {
@@ -3288,6 +3291,7 @@ static void addrconf_dad_completed(struct inet6_ifaddr *ifp)
 	send_rs = send_mld &&
 		  ipv6_accept_ra(ifp->idev) &&
 		  ifp->idev->cnf.rtr_solicits > 0 &&
+		  (dev->flags&IFF_MULTICAST) &&
 		  (dev->flags&IFF_LOOPBACK) == 0;
 	read_unlock_bh(&ifp->idev->lock);
 
@@ -4192,8 +4196,9 @@ errout:
 		rtnl_set_sk_err(net, RTNLGRP_IPV6_IFADDR, err);
 }
 
-static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
-				__s32 *array, int bytes)
+static inline void ipv6_store_devconf(struct net_device *dev,
+				      struct ipv6_devconf *cnf,
+				      __s32 *array, int bytes)
 {
 	BUG_ON(bytes < (DEVCONF_MAX * 4));
 
@@ -4203,7 +4208,8 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
 	array[DEVCONF_MTU6] = cnf->mtu6;
 	array[DEVCONF_ACCEPT_RA] = cnf->accept_ra;
 	array[DEVCONF_ACCEPT_REDIRECTS] = cnf->accept_redirects;
-	array[DEVCONF_AUTOCONF] = cnf->autoconf;
+	if (dev->flags & IFF_MULTICAST)
+		array[DEVCONF_AUTOCONF] = cnf->autoconf;
 	array[DEVCONF_DAD_TRANSMITS] = cnf->dad_transmits;
 	array[DEVCONF_RTR_SOLICITS] = cnf->rtr_solicits;
 	array[DEVCONF_RTR_SOLICIT_INTERVAL] =
@@ -4326,7 +4332,7 @@ static int inet6_fill_ifla6_attrs(struct sk_buff *skb, struct inet6_dev *idev)
 	nla = nla_reserve(skb, IFLA_INET6_CONF, DEVCONF_MAX * sizeof(s32));
 	if (nla == NULL)
 		goto nla_put_failure;
-	ipv6_store_devconf(&idev->cnf, nla_data(nla), nla_len(nla));
+	ipv6_store_devconf(idev->dev, &idev->cnf, nla_data(nla), nla_len(nla));
 
 	/* XXX - MC not implemented */
 
-- 
1.8.5.3

[RFC 1/2] ipv6: disable autoconfiguration and DAD on non-multicast links

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

RFC4862 [0] on IPv6 on Stateless Address Autoconfiguration on
Sections 4 and 5 state that autoconfiguration is performed only
on multicast-capable links. Multicast is used to ensure the
automatically assigned address is unique by sending Neighbor
Solicitation Messages and listening for these same messages
on both the all-nodes multicast address and the solicited-node
multicast address of the tentative address, this is called
Duplicate Address Detection (DAD) and documented on Section 5.4.
DAD has an optimization, Optimistic DAD [1] and it also requires
multicast. Skip autoconfiguration and all forms of DAD on
non-multicast links.

We don't *fully* disable IPV6 for non-multicast links as
there are signs non-multicast IPV6 devices are wished to
be supported, one example being the ipv6 autoconf module
parameter, but 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, regardless of
whether they are obtained through stateless autoconfiguration,
DHCPv6, or manual configuration with the following exceptions:

   -  When DupAddrDetectTransmits is set to zero, DAD
      can be skipped
   -  Anycast addresses can skip DAD

In the case that autoconfiguration is disabled the interface
still gets assigned a temporary address via ipv6_create_tempaddr()
however it will be kept as temporary, IFA_F_TEMPORARY.

[0] http://tools.ietf.org/html/rfc4862
[1] http://tools.ietf.org/html/rfc4429

Cc: Olaf Kirch <okir@suse.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: netdev@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 net/ipv6/addrconf.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index ad23569..362f64f 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2211,7 +2211,8 @@ void addrconf_prefix_rcv(struct net_device *dev, u8 *opt, int len, bool sllao)
 
 	/* Try to figure out our local address for this prefix */
 
-	if (pinfo->autoconf && in6_dev->cnf.autoconf) {
+	if (pinfo->autoconf && in6_dev->cnf.autoconf &&
+	    dev->flags & IFF_MULTICAST) {
 		struct inet6_ifaddr *ifp;
 		struct in6_addr addr;
 		int create = 0, update_lft = 0;
@@ -2248,7 +2249,8 @@ ok:
 
 #ifdef CONFIG_IPV6_OPTIMISTIC_DAD
 			if (in6_dev->cnf.optimistic_dad &&
-			    !net->ipv6.devconf_all->forwarding && sllao)
+			    !net->ipv6.devconf_all->forwarding && sllao &&
+			    dev->flags & IFF_MULTICAST)
 				addr_flags = IFA_F_OPTIMISTIC;
 #endif
 
@@ -3161,6 +3163,7 @@ static void addrconf_dad_start(struct inet6_ifaddr *ifp)
 		goto out;
 
 	if (dev->flags&(IFF_NOARP|IFF_LOOPBACK) ||
+	    !(dev->flags&IFF_MULTICAST) ||
 	    idev->cnf.accept_dad < 1 ||
 	    !(ifp->flags&IFA_F_TENTATIVE) ||
 	    ifp->flags & IFA_F_NODAD) {
@@ -3288,6 +3291,7 @@ static void addrconf_dad_completed(struct inet6_ifaddr *ifp)
 	send_rs = send_mld &&
 		  ipv6_accept_ra(ifp->idev) &&
 		  ifp->idev->cnf.rtr_solicits > 0 &&
+		  (dev->flags&IFF_MULTICAST) &&
 		  (dev->flags&IFF_LOOPBACK) == 0;
 	read_unlock_bh(&ifp->idev->lock);
 
@@ -4192,8 +4196,9 @@ errout:
 		rtnl_set_sk_err(net, RTNLGRP_IPV6_IFADDR, err);
 }
 
-static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
-				__s32 *array, int bytes)
+static inline void ipv6_store_devconf(struct net_device *dev,
+				      struct ipv6_devconf *cnf,
+				      __s32 *array, int bytes)
 {
 	BUG_ON(bytes < (DEVCONF_MAX * 4));
 
@@ -4203,7 +4208,8 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
 	array[DEVCONF_MTU6] = cnf->mtu6;
 	array[DEVCONF_ACCEPT_RA] = cnf->accept_ra;
 	array[DEVCONF_ACCEPT_REDIRECTS] = cnf->accept_redirects;
-	array[DEVCONF_AUTOCONF] = cnf->autoconf;
+	if (dev->flags & IFF_MULTICAST)
+		array[DEVCONF_AUTOCONF] = cnf->autoconf;
 	array[DEVCONF_DAD_TRANSMITS] = cnf->dad_transmits;
 	array[DEVCONF_RTR_SOLICITS] = cnf->rtr_solicits;
 	array[DEVCONF_RTR_SOLICIT_INTERVAL] =
@@ -4326,7 +4332,7 @@ static int inet6_fill_ifla6_attrs(struct sk_buff *skb, struct inet6_dev *idev)
 	nla = nla_reserve(skb, IFLA_INET6_CONF, DEVCONF_MAX * sizeof(s32));
 	if (nla == NULL)
 		goto nla_put_failure;
-	ipv6_store_devconf(&idev->cnf, nla_data(nla), nla_len(nla));
+	ipv6_store_devconf(idev->dev, &idev->cnf, nla_data(nla), nla_len(nla));
 
 	/* XXX - MC not implemented */
 
-- 
1.8.5.3

[RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

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. 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, since using this can create an issue if a user
decides to enable multicast on the backend interfaces simply
use a random MAC address with the xen OUI prefix as is done
with the frontend through xen udev scripts.

Cc: Paul Durrant <Paul.Durrant@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: xen-devel@lists.xenproject.org
Cc: netdev@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/net/xen-netback/interface.c | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index b9de31e..479fbd1 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -42,6 +42,8 @@
 #define XENVIF_QUEUE_LENGTH 32
 #define XENVIF_NAPI_WEIGHT  64
 
+static const u8 xen_oui[3] = { 0x00, 0x16, 0x3e };
+
 int xenvif_schedulable(struct xenvif *vif)
 {
 	return netif_running(vif->dev) && netif_carrier_ok(vif->dev);
@@ -347,15 +349,9 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	for (i = 0; i < MAX_PENDING_REQS; i++)
 		vif->mmap_pages[i] = NULL;
 
-	/*
-	 * Initialise a dummy MAC address. We choose the numerically
-	 * largest non-broadcast address to prevent the address getting
-	 * stolen by an Ethernet bridge for STP purposes.
-	 * (FE:FF:FF:FF:FF:FF)
-	 */
-	memset(dev->dev_addr, 0xFF, ETH_ALEN);
-	dev->dev_addr[0] &= ~0x01;
-
+	eth_hw_addr_random(dev);
+	memcpy(dev->dev_addr, xen_oui, 3);
+	dev->flags &= ~IFF_MULTICAST;
 	netif_napi_add(dev, &vif->napi, xenvif_poll, XENVIF_NAPI_WEIGHT);
 
 	netif_carrier_off(dev);
-- 
1.8.5.3

[RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

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. 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, since using this can create an issue if a user
decides to enable multicast on the backend interfaces simply
use a random MAC address with the xen OUI prefix as is done
with the frontend through xen udev scripts.

Cc: Paul Durrant <Paul.Durrant@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: xen-devel@lists.xenproject.org
Cc: netdev@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/net/xen-netback/interface.c | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index b9de31e..479fbd1 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -42,6 +42,8 @@
 #define XENVIF_QUEUE_LENGTH 32
 #define XENVIF_NAPI_WEIGHT  64
 
+static const u8 xen_oui[3] = { 0x00, 0x16, 0x3e };
+
 int xenvif_schedulable(struct xenvif *vif)
 {
 	return netif_running(vif->dev) && netif_carrier_ok(vif->dev);
@@ -347,15 +349,9 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	for (i = 0; i < MAX_PENDING_REQS; i++)
 		vif->mmap_pages[i] = NULL;
 
-	/*
-	 * Initialise a dummy MAC address. We choose the numerically
-	 * largest non-broadcast address to prevent the address getting
-	 * stolen by an Ethernet bridge for STP purposes.
-	 * (FE:FF:FF:FF:FF:FF)
-	 */
-	memset(dev->dev_addr, 0xFF, ETH_ALEN);
-	dev->dev_addr[0] &= ~0x01;
-
+	eth_hw_addr_random(dev);
+	memcpy(dev->dev_addr, xen_oui, 3);
+	dev->flags &= ~IFF_MULTICAST;
 	netif_napi_add(dev, &vif->napi, xenvif_poll, XENVIF_NAPI_WEIGHT);
 
 	netif_carrier_off(dev);
-- 
1.8.5.3

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Ian Campbell]

On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> 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? Surely these
should be controlled logically independently even if there is some
notional linkage. Can SAA not be disabled directly?

>  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.

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.

So Nack for that reason.

>  since using this can create an issue if a user
> decides to enable multicast on the backend interfaces

Please explain what this issue is.

Also how can a user enable multicast on the b/e? 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)

Ian.

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Ian Campbell]

On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> 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? Surely these
should be controlled logically independently even if there is some
notional linkage. Can SAA not be disabled directly?

>  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.

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.

So Nack for that reason.

>  since using this can create an issue if a user
> decides to enable multicast on the backend interfaces

Please explain what this issue is.

Also how can a user enable multicast on the b/e? 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)

Ian.

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Luis R. Rodriguez]

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 <Ian.Campbell@citrix.com> wrote:
> On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>
>> 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

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Luis R. Rodriguez]

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 <Ian.Campbell@citrix.com> wrote:
> On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>
>> 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

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Ian Campbell]

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 <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
> >> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >>
> >> 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.

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Ian Campbell]

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 <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
> >> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >>
> >> 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.

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Wei Liu]

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 <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
> >> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >>
> >> 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.

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Wei Liu]

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 <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
> >> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >>
> >> 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.

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Bill Fink]

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 <Ian.Campbell@citrix.com> wrote:
> > > On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
> > >> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > >>
> > >> 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

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Bill Fink]

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 <Ian.Campbell@citrix.com> wrote:
> > > On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
> > >> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > >>
> > >> 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

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Luis R. Rodriguez]

On Wed, Feb 12, 2014 at 9:17 AM, Bill Fink <billfink@mindspring.com> 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

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Luis R. Rodriguez]

On Wed, Feb 12, 2014 at 9:17 AM, Bill Fink <billfink@mindspring.com> 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

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Luis R. Rodriguez]

On Wed, Feb 12, 2014 at 3:15 AM, Ian Campbell <Ian.Campbell@citrix.com> 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 <Ian.Campbell@citrix.com> wrote:
>> > On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
>> >> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>> >>
>> >> 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

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Luis R. Rodriguez]

On Wed, Feb 12, 2014 at 3:15 AM, Ian Campbell <Ian.Campbell@citrix.com> 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 <Ian.Campbell@citrix.com> wrote:
>> > On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
>> >> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>> >>
>> >> 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

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Luis R. Rodriguez]

On Wed, Feb 12, 2014 at 2:05 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> 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

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Luis R. Rodriguez]

On Wed, Feb 12, 2014 at 2:05 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> 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

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Luis R. Rodriguez]

On Wed, Feb 12, 2014 at 8:27 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> 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

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Luis R. Rodriguez]

On Wed, Feb 12, 2014 at 8:27 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> 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

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Ian Campbell]

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.

Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

[Ian Campbell]

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.

[RFC 0/2] xen-backend interfaces and IFF_MULTICAST

[Luis R. Rodriguez]

Virtualization hypervisors do not make use of backend Ethernet interfaces
like typical Ethernet interfaces. In my current testing at least xen-netback
requires at least a struct in_device with a proper MTU setting in order for
the front end interface to function properly. Under the current design this
will kick off ipv6 autoconfiguration and DAD on these interfaces. This does
not happen for xen's TAP interface when HVM is used. KVM only uses TAP
interfaces but their backend interfaces *do not* perform ipv6 autoconfiguration
and DAD even though its TAP interfaces do have multicast enabled.

In xen's case some xen users used to run into issues with the current
architecture when bundles of xen guests were on the same network and ipv6
autoconfiguration was performed. This happens because the MAC address is
static and while this can be corrected by randomizing it an ipv6 address
is simply not needed for them. There is currently no way to disable ipv6
interfaces on specific type of interfaces but this is just begging review
of the architecture on why an interface is even needed at all, how about
ipv4 addresses, why do we need inetdev_init() on these virtualized
interfaces?

Disabling multicast on an interface should disable ipv6 autoconfiguration
and DAD but the note on include/uapi/linux/if_link.h makes it clear that
IFF_MULTICAST should be considered carefully given that not-NBMA links are
known to support multicast, this includes all IFF_POINTOPOINT and IFF_BROADCAST
as well. If we are to follow the RFCs on ipv6 autoconfiguration and DAD
however its clear that muliticast is required -- but if we have no reliable
way of determining this capability we won't know when we could perform
autoconfiguration and DAD properly.

If the patch to require IFF_MULTICAST for autoconfiguration and DAD is
valid then xen-netback can simply clear the flag, clearing it is required
as ether_setup() is used during the net_device allocation. I'm currently
reviewing the need for any proper-mtu interface on xen-netback but in the
meantime I'd like some feedback on IFF_MULTICAST and the following
patches.

Luis R. Rodriguez (2):
  ipv6: disable autoconfiguration and DAD on non-multicast links
  xen-netback: disable multicast and use a random hw MAC address

 drivers/net/xen-netback/interface.c | 14 +++++---------
 net/ipv6/addrconf.c                 | 18 ++++++++++++------
 2 files changed, 17 insertions(+), 15 deletions(-)

-- 
1.8.5.3