search

containernetworking / cni

Container Network Interface - networking for Linux containers
https://cni.dev
Apache License 2.0
5.57k stars 1.08k forks source link

Podman container got global IPv6 address unexpectedly even when macvlan network is created for pure IPv4 network #923

Open mashuai191 opened 2 years ago

mashuai191 commented 2 years ago

Description of problem: macvlan network is created for pure IPv4 network, but Podman container got global IPv6 address unexpectedly

Version-Release number of selected component (if applicable):

[root@eagappflx248 ~]# cat /etc/redhat-release Red Hat Enterprise Linux release 8.6 (Ootpa)

[root@eagappflx248 ~]# podman version Client: Podman Engine Version: 4.1.1 API Version: 4.1.1 Go Version: go1.17.7 Built: Mon Jul 11 14:56:53 2022 OS/Arch: linux/amd64

How reproducible:

Steps to Reproduce:

  1. Create macvlan network with pure ipv4 network podman network create -d macvlan --subnet=10.85.40.0/21 --gateway=10.85.40.1 -o parent=nic0 nic0

  2. podman run -itd --name c1 --ip=10.85.41.247 --network nic0 flex.io/uss-engine:17.0

  3. check container ip, and find there are a global ipv6 address and a local-link ipv6 address there. [root@eagappflx223 ~]# podman exec -ti c1 bash engine : ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.85.42.1 netmask 255.255.248.0 broadcast 10.85.47.255 inet6 2001:db8:1:0:1023:21ff:fef5:974d prefixlen 64 scopeid 0x0 inet6 fe80::1023:21ff:fef5:974d prefixlen 64 scopeid 0x20 ether 12:23:21:f5:97:4d txqueuelen 0 (Ethernet) RX packets 363 bytes 23318 (22.7 KiB) RX errors 0 dropped 41 overruns 0 frame 0 TX packets 12 bytes 980 (980.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Actual results: there are ipv6 addresses auto-configured for container which is in pure ipv4 address.

Expected results: there should be no ipv6 addresses auto-configured for container which is in pure ipv4 address.

Additional info: our lab environment has DHCP server configured, and our DNS server can resolve a hostname to both ipv4 and ipv6 address. for example [root@eagappflx128 hostadmin]# nslookup eagappflx128p1

Server: 172.16.8.12

Address: 172.16.8.12#53

Name: eagappflx128p1.engba.veritas.com

Address: 10.85.41.137

Name: eagappflx128p1.engba.veritas.com

Address: 2620:128:f021:9014::1b

mccv1r0 commented 2 years ago

This isn't an bug, it's a feature.

Global IPv6 addresses were there because:

  1. You told the container to use SLAAC
  2. Something on your network advertised an IPv6 prefix (RA), probably the switch your macvlan interface connects to.

Your container set (e.g. Linux defaults to): net.ipv6.conf.all.accept_ra=1 and net.ipv6.conf.eth0.accept_ra=1 (assuming CNI_IFNAME is set to eth0.) This tells the stack you want what you actually see. SLAAC kicks in when an RA is received advertising on-link prefixe(s).

I'm missing something re dns. Address: 2620:128:f021:9014::1b != inet6 2001:db8:1:0:1023:21ff:fef5:974d

mashuai191 commented 2 years ago

hi @mccv1r0 , two problems i see here.

  1. if the macvlan network is created as pure ipv4 network, any containers created inside the network should not get ipv6 address because the network only support ipv4.
  2. with my testing, i did try to set net.ipv6.conf.all.accept_ra=0 or net.ipv6.conf.eth0.accept_ra=0 when staring the container but it had no effect. Looks the auto-configured ipv6 address was got at earlier phase then those two parameters took effect.
mccv1r0 commented 2 years ago

if the macvlan network is created as pure ipv4 network

If the macvlan network is pure IPv4, nothing would be sending RA's to cause SLAAC to do its thing. It reads like you want the macvlan interface in this container to just use IPv4.

Looks the auto-configured ipv6 address was got at earlier phase then those two parameters took effect.

Makes sense, but you can verify it with tcpdump inside the container. You should see

  1. Route Advertisements triggering SLAAC
  2. Once the sysctl's "kick in", the address should age out (absent a Linux bug). Note the valid lifetime on one of my containers where I want SLAAC to do what you see to happen:
    inet6 2601:19c:4600:39a:8030:4bff:feb0:aef1/64 scope global dynamic mngtmpaddr 
       valid_lft 7113sec preferred_lft 1713sec

If RA's are no longer used due to sysctl(s) we discussed, the addresses should age out.

mashuai191 commented 2 years ago

I understand it should behave as below, and the reported case is same as below conditon 1.

  1. if a macvlan network is created for ipv4 subnet then any container created in that network should only support ipv4 address.
  2. if a macvlan network is created for ipv6 subnet then any container created in that network should only support ipv6 address.
  3. if a macvlan network is created for dual subnet then any container created in that network should support both ipv4 and ipv6 addresses.

with the two parameters set, I tried to remove the auto-configured ipv6, then no new ipv6 got automatically, so this proved that those two parameters has effect but not for previously auto-conf ipv6 address. Looks either it should be kick in earlier or a clean-up action needed to remove existing auto-conf ipv6 addresses.