Activate IPv6 for docker container?

  • Hi!


    Does anyone know how to activate IPv6 for docker containers on OMV? I can't even find the config file for docker containers. This is all new to me. But since Nextcloud 16 requires PHP 7.1, I need to start using docker for nextcloud.


    Cheers,
    T

    • Offizieller Beitrag

    This should help. You could add it to daemon.json or the extra options box in Run.
    https://docs.docker.com/v17.09…ing/default_network/ipv6/

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Thanks. Don't know why I didn't find it first.


    Is there any way to find out the IPv6 address? I installed the Nextcloud docker image, but this seems to be missing ip or ifconfig binaries? If I do "docker exec -it nextcloud bash" and enter "ifconfig" or "ip", it says "command not found".


    EDIT: Actually, it's not really working. After I rebooted my OMV image the webinterface is throwing errors after I enabled IPv6. Also in the console I get errors for docker. As soon as I remove the IPv6-option from daemon.json everything is back to normal.


    EDIT2: Okay, it fails if I use the same prefix as OMV is already using. I don't want a new prefix as I only got a /64 delegated to the network on which OMV sits. I somehow have to use the same prefix. That's what I thought the bridge interface is for...

  • Wow, IPv6 is just stupid on docker. I don't think I'm gonna use docker after all. Who design an application in this time and totally miss out on IPv6?

    • Offizieller Beitrag

    Who design an application in this time and totally miss out on IPv6?

    Most people using docker don't need ipv6 and big companies probably just put a proxy server in front of it.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • That's stupid by design. Especially for docker IPv6 would bring so many advantages...e.g. assigning every container its own IP. No hassle with endless portmappings. Proper end-to-end-connection.
    Especially normal people will need IPv6 more and more, because they're sitting behind carrier-grade NAT at home with DSLite. So only way to access is per IPv6.

  • Docker is designed for bridged networking. The way it works is not that the docker ip is reachable from the outside. So ipv6 is completly unnecessary, as you wont put more dockers in a single docker net than ipv4 can deliver.
    What you want is delivered by some proxy and should be handled that way for many reasons. What you want would brake concepts and security on many levels. I think you missunderstand what docker is designed for.

  • I understand what docker was designed for.


    But how the handle the networking doesn't make sense. It's not ready for the now. IPv6 is essential. The way they implemented IPv6 support is totally contradictive.


    Also, the network bridge on docker isn't really a bridge, I find. It's an internal network on the host. If it was a bridge, I would expect the docker client to appear on the physical network segment as an independent host.


    It wouldn't break security, if docker was designed in a sensible way. It could still chose not to expose every port on the container. Same like it does with NATted IPv4 containers.

  • I am not intending to be disrespectfull by any means, but no, you obviously dont understand it.
    Of course it is an internal network on the host, still it is bridged.
    If I understand correctly, you want some kind of net=host with additional assigned ipv6 on the hosts network device (which one by the way, all?) which than get redirected to the docker. How can this not break security and, arguebly even more important, concept? Docker is designed for environments, ot easy software installation as it is used successfully by many here. Think about the influence on the hosts network stack. Docker is intended to have minimal to no effects on the host.
    I commonly use ipv6 in many environments these days, but I see absolutly no gain in docker. You may need to look for something else, although I dont know what does deliver what you are looking for. Docker, lxc, singularit, they all dont afaik.

  • No, I do understand it.
    Which network interface? Preferably configurable!
    It's easy not to break security: if docker just acts as a firewall and only allows specified ports, like it does for IPv4.
    Well, actually I'd prefer without docker, but then you have the problems with dependencies.
    Whatever was designed to not work with IPv6 natively today is just stupid design.

  • If you really think, this is how containers should be you can seriously go ahead and implement it. Collecting money in this area is rather easy, 5 man dev team with good payment for 2 years should be no issue to get as Initial investment.
    You dont have me convinced though. Issues I see is host/container interaction, or better put influence on the host. Issues with fdn and certificates in most currerent networks. Configurable interfaces break portability, also the dependency on the running firewall, selinux and such get more critical. You need to realize, that docker containers in professional environments mostly run in swarm or kubernetes, on inconsistent hw. Also you basically force dns for every container, nobody wants to type ipv6 adresses, so your dns proxy is needed anyways, which in the end means to me: more overhead, more host influence, less portability, higher network environment demands, conceptional issues with virtual docker nets (docker-compose files utulize it basically always), security risks (sounds like default exposing containers), zero gain.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!