Bug#989162: bridge-utils: ifupdown scripts should not unconditionally disable IPv6 on physical interface

2022-10-06 Thread Arturo Borrero Gonzalez
On Thu, 29 Sep 2022 14:33:29 +0200 Arturo Borrero Gonzalez 
 wrote:


Imagine this setup:

eno1  -- physical base device
eno1. -- vlan sub-interface
eno1. -- vlan sub-interface
br01  -- bridge device

I add eno1. and eno1. to br01 as ports.


I discovered that if use a more modern approach to naming the vlan 
devices this problem won't show up.


If instead of 'eno1.' you create 'vlan' then the algorithm to 
disable IPv6 wont detect the base interface and therefore will leave it 
alone.


This definitely feels fragile and inconsistent, and additional 
indication that the patch proposed by Anton may be the right course of 
action.


regards.



Bug#989162: bridge-utils: ifupdown scripts should not unconditionally disable IPv6 on physical interface

2022-09-29 Thread Arturo Borrero Gonzalez

On Sun, 06 Feb 2022 08:58:38 +0100 Anton Khirnov  wrote:

Quoting Santiago Garcia Mantinan (2022-02-05 22:56:09)
> Well, having IPv6 addresses attached to those ports can also be undesirable,

Could you please explain why do you think so? It would be good to have
the reason documented somewhere, as this behavior was quite surprising
to me.

> I really think that those addresses should be allowed with an explicit
> config not by default.

I suppose adding an option won't be too hard. I'll send a new patch.



There is something I'm not quite understanding.

Imagine this setup:

eno1  -- physical base device
eno1. -- vlan sub-interface
eno1. -- vlan sub-interface
br01  -- bridge device

I add eno1. and eno1. to br01 as ports.

Why would the bridge care about the IPv6 setup that I have on eno1? 
Perhaps is too invasive (and counterintuitive anyways).


The base/parent device shouldn't be affected by the setup used on the 
sub-devices. The configuration for the base interface should be left 
untouched.


I think the patch by Anton Khirnov may be the right approach.

This problem is affecting 2 different virtual machine setups in my 
organization (openstack and ganeti).


regards.
--
Arturo Borrero Gonzalez
Senior Site Reliability Engineer
Wikimedia Cloud Services
Wikimedia Foundation



Bug#989162: bridge-utils: ifupdown scripts should not unconditionally disable IPv6 on physical interface

2022-02-06 Thread Anton Khirnov
Quoting Santiago Garcia Mantinan (2022-02-05 22:56:09)
> Well, having IPv6 addresses attached to those ports can also be undesirable,

Could you please explain why do you think so? It would be good to have
the reason documented somewhere, as this behavior was quite surprising
to me.

> I really think that those addresses should be allowed with an explicit
> config not by default.

I suppose adding an option won't be too hard. I'll send a new patch.

-- 
Anton Khirnov



Bug#989162: bridge-utils: ifupdown scripts should not unconditionally disable IPv6 on physical interface

2022-02-05 Thread Santiago Garcia Mantinan
> This is NOT about addresses on bridge ports (and I agree those are not
> needed or desirable), but the case where the bridge port is a VLAN

Ok.

> interface. Then the current code prevents you from using not just the
> VLAN interface (e.g. eth0.3), but also the underlying physical interface
> (i.e. eth0). I see no reason why you should not use both of these
> simultaneously.

Well, having IPv6 addresses attached to those ports can also be undesirable,
I really think that those addresses should be allowed with an explicit
config not by default.

> The patch I sent does not change anything about disabling ipv6 on the
> bridge port interface, only for the underlying physical interface for a
> VLAN bridge port.

I know, but I don't think that is the behaviour change we need.

I think we should find a way to say we should not disable them, or a way to
enable them if we want, but not by default.

Regards.
-- 
Manty/BestiaTester -> http://manty.net



Bug#989162: bridge-utils: ifupdown scripts should not unconditionally disable IPv6 on physical interface

2022-02-03 Thread Anton Khirnov
Hi,
Quoting Santiago Garcia Mantinan (2022-02-03 23:09:43)
> On Xan 20 2022, Anton Khirnov wrote:
> > Attaching a patch. I still couldn't think of a reason this code should
> > ever disable IPv6 on the physical interface, so it's removed
> > unconditionally. If anyone can think of such a reason, then I guess an
> > option could be added?
> 
> Well, the thing here is that since de beginning of the bridge code it was
> recommended not to add ip addresses to the bridge ports, this was a long
> time ago, and maybe it has changed, if so, I'd like to know when.
> 
> But anyway... why would you want to have
> an IP v4 or v6 on the bridge ports? why not having it on the bridge itself?

This is NOT about addresses on bridge ports (and I agree those are not
needed or desirable), but the case where the bridge port is a VLAN
interface. Then the current code prevents you from using not just the
VLAN interface (e.g. eth0.3), but also the underlying physical interface
(i.e. eth0). I see no reason why you should not use both of these
simultaneously.

The patch I sent does not change anything about disabling ipv6 on the
bridge port interface, only for the underlying physical interface for a
VLAN bridge port.

-- 
Anton Khirnov



Bug#989162: bridge-utils: ifupdown scripts should not unconditionally disable IPv6 on physical interface

2022-02-03 Thread Santiago Garcia Mantinan
On Xan 20 2022, Anton Khirnov wrote:
> Attaching a patch. I still couldn't think of a reason this code should
> ever disable IPv6 on the physical interface, so it's removed
> unconditionally. If anyone can think of such a reason, then I guess an
> option could be added?

Well, the thing here is that since de beginning of the bridge code it was
recommended not to add ip addresses to the bridge ports, this was a long
time ago, and maybe it has changed, if so, I'd like to know when.

But anyway... why would you want to have
an IP v4 or v6 on the bridge ports? why not having it on the bridge itself?

Regards.
-- 
Manty/BestiaTester -> http://manty.net



Bug#989162: bridge-utils: ifupdown scripts should not unconditionally disable IPv6 on physical interface

2022-01-20 Thread Anton Khirnov
Attaching a patch. I still couldn't think of a reason this code should
ever disable IPv6 on the physical interface, so it's removed
unconditionally. If anyone can think of such a reason, then I guess an
option could be added?

-- 
Anton Khirnov
From f8691b90f83c2058d82ac9b173b351ce3aa5b714 Mon Sep 17 00:00:00 2001
From: Anton Khirnov 
Date: Thu, 20 Jan 2022 09:18:31 +0100
Subject: [PATCH] Do not disable IPv6 on the physical interface for a VLAN
 port.

When one of the bridge ports is a VLAN interface, the ifupdown script
will currently disable IPv6 on the physical interface for that VLAN.
This is undesirable, since the user may want to use the physical
interface independently.
---
 debian/bridge-utils.sh | 4 
 1 file changed, 4 deletions(-)

diff --git a/debian/bridge-utils.sh b/debian/bridge-utils.sh
index a3bfe5f..915c5d0 100644
--- a/debian/bridge-utils.sh
+++ b/debian/bridge-utils.sh
@@ -64,10 +64,6 @@ then
   # port is a vlan and the device exists?
   if [ "$port" != "$dev" ] && [ -e "/sys/class/net/$dev" ]
   then
-if [ -f /proc/sys/net/ipv6/conf/$dev/disable_ipv6 ]
-then
-  echo 1 > /proc/sys/net/ipv6/conf/$dev/disable_ipv6
-fi
 ip link set "$dev" up
 ip link add link "$dev" name "$port" type vlan id "${port#*.}"
   fi
-- 
2.30.2



Bug#989162: bridge-utils: ifupdown scripts should not unconditionally disable IPv6 on physical interface

2021-05-27 Thread Anton Khirnov
Package: bridge-utils
Version: 1.7-1
Severity: normal
Tags: ipv6

Dear Maintainer, when using the network/interfaces scripts to set up a
bridge, they will automatically and unconditionally disable ipv6 not
only on the ports added to the bridge, but also on the underlying
physical device (if the port is a VLAN device). This is not always
desirable (actually I wonder if it's ever desirable), e.g. in my setup
I'm bridging a VLAN device on my physical NIC with veth devices attached
to LXC containers, so the containers' traffic is always sent to a
specific VLAN. However I still want to use the physical interface for
the host's own traffic.

Thanks,
-- 
Anton Khirnov

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'testing'), (500, 'stable'), (400, 'unstable'), (300, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-11-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages bridge-utils depends on:
ii  libc6  2.31-11

bridge-utils recommends no packages.

Versions of packages bridge-utils suggests:
ii  ifupdown  0.8.36

-- no debconf information

-- debsums errors found:
debsums: changed file /lib/bridge-utils/bridge-utils.sh (from bridge-utils 
package)
debsums: changed file /lib/bridge-utils/ifupdown.sh (from bridge-utils package)
^^ the local changes are just commenting out the lines disabling ipv6