New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop LXC/LXD creating useless IPv6 Networking setup inside containers by default #3333

Closed
tkedwards opened this Issue May 21, 2017 · 5 comments

Comments

5 participants
@tkedwards

tkedwards commented May 21, 2017

Required information

  • Distribution: Ubuntu
  • Distribution version: 16.04
  • The output of "lxc info" or if that fails:
config: {}
api_extensions:
- storage_zfs_remove_snapshots
- container_host_shutdown_timeout
- container_syscall_filtering
- auth_pki
- container_last_used_at
- etag
- patch
- usb_devices
- https_allowed_credentials
- image_compression_algorithm
- directory_manipulation
- container_cpu_time
- storage_zfs_use_refquota
- storage_lvm_mount_options
- network
- profile_usedby
- container_push
- container_exec_recording
- certificate_update
- container_exec_signal_handling
- gpu_devices
- container_image_properties
- migration_progress
- id_map
- network_firewall_filtering
- network_routes
- storage
- file_delete
- file_append
- network_dhcp_expiry
- storage_lvm_vg_rename
- storage_lvm_thinpool_rename
- network_vlan
- image_create_aliases
- container_stateless_copy
- container_only_migration
- storage_zfs_clone_copy
- unix_device_rename
- storage_lvm_use_thinpool
- storage_rsync_bwlimit
- network_vxlan_interface
api_status: stable
api_version: "1.0"
auth: trusted
public: false
environment:
  addresses: []
  architectures:
  - x86_64
  - i686
  certificate: |
    -----BEGIN CERTIFICATE-----
    MIIFcTCCA1mgAwIBAgIRAKrvdFAi5uDuycC8KnphJ/QwDQYJKoZIhvcNAQELBQAw
    RDEcMBoGA1UEChMTbGludXhjb250YWluZXJzLm9yZzEkMCIGA1UEAwwbcm9vdEB0
    aW1zZXJ2ZXIudGltc3N0dWZmLmV1MB4XDTE3MDQxNDA2MTY1M1oXDTI3MDQxMjA2
    MTY1M1owRDEcMBoGA1UEChMTbGludXhjb250YWluZXJzLm9yZzEkMCIGA1UEAwwb
    cm9vdEB0aW1zZXJ2ZXIudGltc3N0dWZmLmV1MIICIjANBgkqhkiG9w0BAQEFAAOC
    Ag8AMIICCgKCAgEAw5dwGlKwUQNFQlORZYK/SApR+xEEiu0rxM62GysFztuF41ps
    g2ig7MyTZ9yTRFm4WngkVVkamXswkO/l7nQ9VNYfIE/HFR76hbo/QcLbx6SM25U7
    DigzlsPj7UpN2BwTHdNj8y55JnXfqNnbN5Qvb2hP3IJg2e6TfgpmLNxoeoOid9Ju
    0wLGT6OaVvIjQv2AV51hDjORjoVB2yELgGu81DjPnVloKmmaDqIfDYAxj51EjIeR
    J+ELZ53zwYaDuMAdDFFykyJ0EJCjOzfBMrWfsVUmhUiwgUSZ/3u9fFq9N6l0mVws
    pBd/jCNROOOQB0GEZU6j7H/mab3ZHmyrSC9KmJAiFhtYwWLGcBZmWQWmEV39rC+E
    w598TKSRzsz4vhzrBwwGVxHA6IixKQU86Nncou90NIhIB6J1QD7bLiAwk4gxOgJV
    V4ouPM7zmiDn3EWe/vGuMc1ugciWTtotJaQ54o0+DLqWW3ZIdRYTTov/vMuYrI3C
    WMNGbT51idjV8M4UoHo2eMGSIsay9m9p+aYORfdEHSg+8+2i9+D4fjb0sMeSlEpi
    YXpljdyAxh9w/hIDbIoKbhvo8jqxGbUsG3mHvE2TWXfmTkWOBrbcWA5uePNscHOV
    HW7htUpniEWo+7JQcsiPgpRepf7IHI7c2Kvc1lBOxpPpBdRq/duFpwuW5CECAwEA
    AaNeMFwwDgYDVR0PAQH/BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAwGA1Ud
    EwEB/wQCMAAwJwYDVR0RBCAwHoIWdGltc2VydmVyLnRpbXNzdHVmZi5ldYcEwKgA
    BDANBgkqhkiG9w0BAQsFAAOCAgEAcP0pir9ZIdgG9SWk6aoWSrl/8d9TZhxzO4Hm
    i0SshsV6NeZJbrRwkmNjyaBQKTFMgPBGAaUGuKdfCg71ixol84u+yUxjeJfF8ISc
    MkP9ObEAGQXVwBHz7S6DqsGXvLDNWfjI+NSquIMV1i0CE7pD0Nyp8WO+AO7QdUJW
    jqD19yOZ1Jho7dOuCTItWFFXLbP+M+zWhDislw4v8U/MjpMiRSoYpkCycLpaHiEv
    6hcSHNcZaUPh+0wDJFt6sbX1xV6pTjw9jta50CpVKrYncn9qt1jLEqgOI4GI5HUr
    0fRB0ADXmcGnLxyk5zVg7Mf3ZUxPiJv4Xf+T9BuCKM6SrBa91piijIUYKpkNQ8zL
    tNk7ciFKMqq6/R80I2wuLueVHOARCsIfEtnz4VMbuWYd93wayosK2zGwuP3UP+RS
    NTfCCKNtf9tkawZB9rUFMu1Wdj/EccOSqteVMqwXaaGEGjJ6STcEhoUuDKemljBX
    Bsdx8C8U71vUTrilGpdzsTlwn+EPXK3g7YgfQZqQRzF80k5iCvOK9H3fuR49xsy9
    VOkX+w51+hSyBe4sZsiUKg4zgi5OfBLJUjt2e9L16d1TOO3bd5tjr4U7TijBqXyL
    jBI8pe+9mcYAz1fJ91O/AWjewI7xPPQdUDJREOjxg+jqYLCYLla/79n6kHiLiV90
    NhqIjLU=
    -----END CERTIFICATE-----
  certificate_fingerprint: 3b48c7a09949167bcbd30f23ccd1511f19fcde2f15e64efc4e636f158f831282
  driver: lxc
  driver_version: 2.0.8
  kernel: Linux
  kernel_architecture: x86_64
  kernel_version: 4.4.0-78-generic
  server: lxd
  server_pid: 26238
  server_version: "2.13"
  storage: btrfs
  storage_version: "4.4"

Issue description

By default lxc/lxd will create containers with an IPv6 network setup that does nothing. The problem with this is that its presence in the container prevents NetworkManager from working properly, see https://bugzilla.gnome.org/show_bug.cgi?id=782816

There appears to be no way to disable this default IPv6 network. If there is then please consider this a documentation bug, because it's not documented.

$ lxc list local:
+-------------+---------+---------------------+----------------------------------------------+------------+-----------+
|    NAME     |  STATE  |        IPV4         |                     IPV6                     |    TYPE    | SNAPSHOTS |
+-------------+---------+---------------------+----------------------------------------------+------------+-----------+
| emby-xenial | RUNNING | 10.51.46.201 (eth0) | fd29:1cd:eba7:4138:216:3eff:fe4e:ed65 (eth0) | PERSISTENT | 0         |
+-------------+---------+---------------------+----------------------------------------------+------------+-----------+

root@emby-xenial:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
6: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:4e:ed:65 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.51.46.201/24 brd 10.51.46.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fd29:1cd:eba7:4138:216:3eff:fe4e:ed65/64 scope global mngtmpaddr dynamic 
       valid_lft 3093sec preferred_lft 3093sec
    inet6 fe80::216:3eff:fe4e:ed65/64 scope link 
       valid_lft forever preferred_lft forever

Steps to reproduce

  1. Create a container
  2. launch a shell inside the container with lxc exec
  3. run 'ip addr'
@albertodonato

This comment has been minimized.

Show comment
Hide comment
@albertodonato

albertodonato May 21, 2017

Contributor

IPv6 in containers is configured on a per-network basis.

By default, containers are connected to the "lxdbr0" network (see lxc profile show default output).

You can disable entirely IPv6 on that network via

lxc network set lxdbr0 ipv6.address none
Contributor

albertodonato commented May 21, 2017

IPv6 in containers is configured on a per-network basis.

By default, containers are connected to the "lxdbr0" network (see lxc profile show default output).

You can disable entirely IPv6 on that network via

lxc network set lxdbr0 ipv6.address none

@brauner brauner closed this May 21, 2017

@tkedwards

This comment has been minimized.

Show comment
Hide comment
@tkedwards

tkedwards commented May 22, 2017

Thanks

@cloud4g

This comment has been minimized.

Show comment
Hide comment
@cloud4g

cloud4g Sep 21, 2017

Disabling by default is backwards thinking IMO. IPv4 has run out of address space while IPv6 is plentiful. Customers will demand IPv^, IPv6 rPTR/DNS etc. It is up to providers to mitigate the difficulties or your competitors will.

cloud4g commented Sep 21, 2017

Disabling by default is backwards thinking IMO. IPv4 has run out of address space while IPv6 is plentiful. Customers will demand IPv^, IPv6 rPTR/DNS etc. It is up to providers to mitigate the difficulties or your competitors will.

@fraggletoser

This comment has been minimized.

Show comment
Hide comment
@fraggletoser

fraggletoser Oct 25, 2017

@albertodonato
lxc network set lxdbr0 ipv6.address none
yes, if you're using lxd > 2.0.10 . otherwise ?

fraggletoser commented Oct 25, 2017

@albertodonato
lxc network set lxdbr0 ipv6.address none
yes, if you're using lxd > 2.0.10 . otherwise ?

@fraggletoser

This comment has been minimized.

Show comment
Hide comment
@fraggletoser

fraggletoser Oct 25, 2017

@cloud4g

Disabling by default is backwards thinking IMO.

it's definitively not. firstly don't enable things which you never use. (->security a.s.o. - apparently you come from $$$-side, right?). secondly preemptive obedience leads to unquestioning obedience. better we gonna wait for a more sophisticated ipNG in the future, right?
thirdly if you are not sure, don't do it!

IPv4 has run out of address space while IPv6 is plentiful.

that's right. with v6 you can give each alien devices outer space an ip-address ;) , ergo ?

Customers will demand IPv^, IPv6 rPTR/DNS etc.

customers even like to be on twitter or facebook never wasting any thought about. the thing is: customers never know what they do.
ipv4 is connectionless, ipv6 connection oriented. using ipv6 in a perfect ipv6 world == orwell 1984 !

It is up to providers to mitigate the difficulties or your competitors will.

that's not an argument. it's not a customer business.

fraggletoser commented Oct 25, 2017

@cloud4g

Disabling by default is backwards thinking IMO.

it's definitively not. firstly don't enable things which you never use. (->security a.s.o. - apparently you come from $$$-side, right?). secondly preemptive obedience leads to unquestioning obedience. better we gonna wait for a more sophisticated ipNG in the future, right?
thirdly if you are not sure, don't do it!

IPv4 has run out of address space while IPv6 is plentiful.

that's right. with v6 you can give each alien devices outer space an ip-address ;) , ergo ?

Customers will demand IPv^, IPv6 rPTR/DNS etc.

customers even like to be on twitter or facebook never wasting any thought about. the thing is: customers never know what they do.
ipv4 is connectionless, ipv6 connection oriented. using ipv6 in a perfect ipv6 world == orwell 1984 !

It is up to providers to mitigate the difficulties or your competitors will.

that's not an argument. it's not a customer business.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment