lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 20 May 2019 22:23:03 +0200
From:   "M. Buecher" <>
Cc:     Michal Kubecek <>,
        Matthias May <>,
        Heiner Kallweit <>
Subject: Re: IP-Aliasing for IPv6?

On 2019-05-15 11:26, Michal Kubecek wrote:
> On Tue, May 14, 2019 at 08:49:12PM +0200, M. Buecher wrote:
>> According to the documentation [1] "IP-Aliasing" is an obsolete way to
>> manage multiple IP[v4]-addresses/masks on an interface.
>> For having multiple IP[v4]-addresses on an interface this is 
>> absolutely
>> true.
>> For me "IP-Aliasing" is still a valid, good and easy way to "group" ip
>> addresses to run multiple instances of the same service with different 
>> IPs
>> via virtual interfaces on a single physical NIC.
>> Short story:
>> I recently added IPv6 to my LAN setup and recognized that IP-Aliasing 
>> is not
>> support by the kernel.
>> Could IP-Aliasing support for IPv6 be added to the kernel?
> You should probably better explain what is the feature you are using
> with IPv4 but you are missing for IPv6. The actual IP aliasing has been
> removed in kernel 2.2, i.e. 20 years ago. Since then, there is no IP
> aliasing even for IPv4. What exactly works for IPv4 but does not for
> IPv6?

Used feature is the label option of `ip`, which works for IPv4, but not 
with IPv6.

Goal: Use virtual interfaces to run separate instances of a service on 
different IP addresses on the same machine.
For example with dnsmasq I use `-interface ens192` for the normal main 
instance, while using `-interface ens192:0` and `-interfaces ens192:1` 
for special instances only assigned to specific machines via their MAC 

What is the correct name when I use the label option of the ip command?
The "IP-Aliasing" doc was the only one I could find on that 
fit the way labels are assigned with ip.

I know how to set these labels the following three ways:
a) manual iproute2 commands
ip addr add broadcast + dev ens192
ip addr add broadcast + label ens192:0 dev ens192
ip addr add broadcast + label ens192:1 dev ens192

b) via /etc/network/interfaces
iface ens192 inet static

iface ens192:0 inet static

iface ens192:1 inet static

c) via systemd-networkd



Hope this explains it much better

>> Long story:
>> I tried to find out how to do virtual network interfaces "The Right 
>> Way
>> (tm)" nowadays.
>> So I came across MACVLAN, IPVLAN and alike on the internet, mostly in
>> conjunction with containers or VMs.
>> But MACVLAN/IPVLAN do not provide the same usability as "IP-Aliasing", 
>> e.g.
>> user needs to learn a lot about network infrastructre, sysctl 
>> settings,
>> forwarding, etc.
>> They also do not provide the same functionality, e.g. the virtual 
>> interfaces
>> cannot reach their parent interface.
>> In my tests with MACVLAN (bridge)/IPVLAN (L2) pinging between parent 
>> and
>> virtual devices with `ping -I <device> <target ip>` failed for IPv4 
>> and
>> IPV6.
> This is an interesting observation but also a completely artificial
> example. You should probably explain what is the actual goal you want 
> to
> achieve.
>> Pinging from outside MACVLAN worked fine for IPv4 but not IPv6, while 
>> failed also for pinging with IPv4 to the virtual interfaces. Pinging 
>> to
>> outside only worked from the parent device.
>> Unfortunately I could not find any source on the internet that 
>> describes how
>> to setup MACVLAN/IPVLAN and their surroundings correctly for a single
>> machine. It seems they are just used for containers and VMs.
> That's because containers and VMs are the primary use case (macvlan can
> also make sense if you want to use different MAC address for some
> reason). Otherwise, it should be sufficient to simply assign multiple
> IPv[46] addresses to your interface.
> Michal Kubecek

Powered by blists - more mailing lists