neutron

Bug #1480979
Comment #18

Comment 18 for bug 1480979

Revision history for this message

Alan Jenkins (aj504) wrote on 2016-02-02:

#18

Hi Andreas. Testing sounds good :), that's partly what I was trolling for. To be honest all I'd checked is that IPv6 wasn't working with DHCPv6-assigned addresses. Talking with the libvirt guy sounds even better.

My assumption with promisc. mode on a macvlan was that it let you recieve all packets regardless of MAC address. So you could add them to a linux bridge interface without any limitations.

However I get the same result as you when I tried it (just plugging together with `ip link`, veth interfaces, and namespaces; no libvirt). I can get bridging to work with one of the weird "passthrough mode" macvlan interfaces, but I don't expect you'll be using them. The normal "bridge mode" macvlans didn't co-operate with bridging, as you describe.

It's as if there's no difference between the effects of promisc. and allmulti. mode. I've come to think this is justified (see end). You're absolutely correct. VM's can only receive on one MAC address (for unicast). It's not what I would mean to call "packet sniffing". If you have to allow MAC changes in order to support multicast, it's not ideal, but significantly less dangerous than I was thinking. Apologies if I've been dumping my own confusions on you.

## Disagreements in wording

When you say "sending faked packets", I would call that "MAC spoofing", because it matches what we mean by IP address spoofing. That's what I picked up on to start with. You don't need to say that macvlan allows MAC spoofing in those exact words; it might be counter-productive because it's such a narrow concern. AFAICS macvlan allows fun with ARP spoofing too :), it's just how Ethernet works by default. My point is you should *not* describe macvlan as preventing MAC spoofing.

"No arbitrary IPv6 addresses" confuses me. I assumed assigning routable IPv6 addresses doesn't work, so IPv6 is dead. I'm just guessing, but maybe you're telling me SLAAC addresses will have the same interface identifier (last 64 bits) as link-local addresses and that means they will work too.

## promisc. notes

After much consideration :) I think the behaviour of promisc. mode is "correct". I thought it would make sense if you could create two macvlans, and enslave them to two separate bridges. I was wrong, because the notional bridge inside macvlan doesn't implement MAC learning. It would have to inefficiently flood unknown unicast traffic into *both* bridges in order to reach the destination. So I won't worry that someone will implement it in future :).

It was confusing that a promisc mode macvlan seems to enable promisc mode on the lowerdev, even if the macvlan is not passthrough mode. It looks like it only needed "allmulticast".

"bridge mode" macvlan code in the kernel also doesn't support extra secondary MAC addresses AFAICS. I can't work out the reason for _that_, and you can create "stacked" macvlans which are equivalent. But if you're a VM attached to a macvtap... that's not a concern.

Hi Andreas.  Testing sounds good :), that's partly what I was trolling for.  To be honest all I'd checked is that IPv6 wasn't working with DHCPv6-assigned addresses.  Talking with the libvirt guy sounds even better.

My assumption with promisc. mode on a macvlan was that it let you recieve all packets regardless of MAC address.  So you could add them to a linux bridge interface without any limitations.

However I get the same result as you when I tried it (just plugging together with `ip link`, veth interfaces, and namespaces; no libvirt).  I can get bridging to work with one of the weird "passthrough mode" macvlan interfaces, but I don't expect you'll be using them.  The normal "bridge mode" macvlans didn't co-operate with bridging, as you describe.

It's as if there's no difference between the effects of promisc. and allmulti. mode.  I've come to think this is justified (see end).  You're absolutely correct.  VM's can only receive on one MAC address (for unicast).  It's not what I would mean to call "packet sniffing".  If you have to allow MAC changes in order to support multicast, it's not ideal, but significantly less dangerous than I was thinking.  Apologies if I've been dumping my own confusions on you.

## Disagreements in wording

When you say "sending faked packets", I would call that "MAC spoofing", because it matches what we mean by IP address spoofing.  That's what I picked up on to start with.  You don't need to say that macvlan allows MAC spoofing in those exact words; it might be counter-productive because it's such a narrow concern.  AFAICS macvlan allows fun with ARP spoofing too :), it's just how Ethernet works by default.  My point is you should *not* describe macvlan as preventing MAC spoofing.

"No arbitrary IPv6 addresses" confuses me.  I assumed assigning routable IPv6 addresses doesn't work, so IPv6 is dead.  I'm just guessing, but maybe you're telling me SLAAC addresses will have the same interface identifier (last 64 bits) as link-local addresses and that means they will work too.

## promisc. notes

After much consideration :) I think the behaviour of promisc. mode is "correct".  I thought it would make sense if you could create two macvlans, and enslave them to two separate bridges.  I was wrong, because the notional bridge inside macvlan doesn't implement MAC learning.  It would have to inefficiently flood unknown unicast traffic into *both* bridges in order to reach the destination. So I won't worry that someone will implement it in future :).

It was confusing that a promisc mode macvlan seems to enable promisc mode on the lowerdev, even if the macvlan is not passthrough mode.  It looks like it only needed "allmulticast".

"bridge mode" macvlan code in the kernel also doesn't support extra secondary MAC addresses AFAICS.  I can't work out the reason for _that_, and you can create "stacked" macvlans which are equivalent.  But if you're a VM attached to a macvtap... that's not a concern.