/etc/hosts contains IPv6 entries even when IPv6 is not enabled

[swmuck]

Description

/etc/hosts contains IPv6 entries when IPv6 is not enabled in daemon.json

The container interfaces do not have IPv6 addresses assigned:

# 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
5886: eth0@if5887: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.3/16 scope global eth0
       valid_lft forever preferred_lft forever

Steps to reproduce the issue:

1. if enabled, disable IPv6 in daemon.json. By default, the Docker daemon configures the container network for IPv4 only.
2. $ docker run debian:jessie cat /etc/hosts

Describe the results you received:

127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.3      1749a2a20d9e

Describe the results you expected:

127.0.0.1       localhost
172.17.0.3      1749a2a20d9e

Output of docker version:

$ docker version
Client:
 Version:      17.06.2-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   cec0b72
 Built:        Tue Sep  5 19:57:21 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.06.2-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   cec0b72
 Built:        Tue Sep  5 19:59:19 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info:

$ docker info
Containers: 74
 Running: 21
 Paused: 0
 Stopped: 53
Images: 106
Server Version: 17.06.2-ce
Storage Driver: overlay
 Backing Filesystem: extfs
 Supports d_type: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
runc version: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.69-rancher
Operating System: RancherOS v1.1.2
OSType: linux
Architecture: x86_64
CPUs: 56
Total Memory: 251.8GiB
Name: REDACTED
ID: I6BI:SM5F:GFI3:DWLQ:6ARS:PL46:CINJ:CBEG:KKKL:RM52:NVO4:IKLH
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 REDACTED
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):

Running in RancherOS v1.1.2

[Ali3900]

you are very great you help me a lot in Ipv6 entities . Bundle of Thanks

[boaz0]

Hi @swmuck

from https://docs.docker.com/engine/userguide/networking/default_network/ipv6/

You can enable IPv4/IPv6 [...] by running [...] the --ipv6 flag. Docker will set up the bridge docker0 with the IPv6 link-local address fe80::1 [...] By default, containers that are created will only get a link-local IPv6 address.

It seems like this is not a bug but an expected behavior.
I am closing this issue but feel free to continue the conversation.

Thanks a lot.

[swmuck]

Hi @ripcurld0

When IPv6 is not enabled

• I would expect the containers interfaces to have only IPv4 addresses. That one works.
• I would expect that /etc/hosts only contains IPv4 addresses.
• I would not expect localhost to resolve to any IPv6 address.

I have a different interpretation of the paragraph from the documenation you quoted:

By default, the Docker daemon configures the container network for IPv4 only. You can enable IPv4/IPv6 dualstack support by running the Docker daemon with the --ipv6 flag. Docker will set up the bridge docker0 with the IPv6 link-local address fe80::1.

Only if IPv6 is enabled docker will set up the bridge docker0 with the IPv6 link-local address fe80::1.

All the other paragraphs on https://docs.docker.com/engine/userguide/networking/default_network/ipv6/ would also only apply when IPv6 is enabled.

Stefan

[boaz0]

@fcrisciani @mavenugo can you look at this ticket and determine whether it's a bug?

Thanks a lot.

[surjsingh]

I came across the same issue today. IPV6 is disabled on the host machine but still, I see the IPV6 entries in the /etc/hosts file inside the docker container. My tests were breaking due to below issue:
"Errno::EAFNOSUPPORT:
Address family not supported by protocol - socket(2) for "::1" port 9515"

Had to enable IPV6 on host to unblock myself for now.
Any better way to handle this while IPV6 still being disabled on the host?

[krobertson]

Bump. IMHO, this behavior makes no sense.

[fcrisciani]

@singhsurjeet at the moment a workaround is to give precedence to IPv4 https://community.rackspace.com/products/f/public-cloud-forum/5110/how-to-prefer-ipv4-over-ipv6-in-ubuntu-and-centos

[kenyon]

The real problem here is that IPv6 should not be disabled and should be enabled by default. Interfaces should have their default IPv6 addresses assigned, even if you're not doing anything else with IPv6. lo should have ::1/128 and Ethernet interfaces should have their link local addresses, just like normal hosts. Then everything would just work, just like normal hosts, and your configuration wouldn't be on this trajectory of divergence from standard Linux distributions.

[arikunbotify]

I'm facing this issue. I can't just leave ipv6 addresses in localhost because one of my frameworks gets confused when localhost resolved to ipv6. Any ideas on how to handle it?

[kenyon]

Fix the framework so it handles IPv6.

[rvvincelli]

This is a known pain when developers forget about v6 ie a lot of mainstream Python stuff tries to bind on just localhost, but editing the hostsfile or following the workaround is fine.

[rthille]

IPv6 is a large increase in the attack surface of a network (ie: http://netpatterns.blogspot.com/2016/01/the-rising-sophistication-of-network.html ), and for overworked admins it's still not worth deploying for many.

[skyscooby]

This is a real PIA.. if dockerd is not configured to enable IP6 support it should not be populating IPv6 addresses to the host file inside the container.. ESPECIALLY overlapping on the name 'localhost' because a lot of software uses this to determine which interfaces to bind to and it will try binding to a non existent ipv6 interface and fail.. one example is postfix on rhel/centos7 it's config inet_intefaces = localhost causes it to fail to start. Yes one can edit the config file to fix this but if your purpose for using containers is testing ansible playbooks for use on various OS distros it's self defeating to make changes to enable testing that don't need to be made in real systems.

My Centos 7 container on docker without IPv6 enabled:

[root@9abb70a87cc2 /]# cat /etc/hosts
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::0	ip6-localnet
ff00::0	ip6-mcastprefix
ff02::1	ip6-allnodes
ff02::2	ip6-allrouters
172.19.0.2	9abb70a87cc2

[root@9abb70a87cc2 /]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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
11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:ac:13:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.19.0.2/16 brd 172.19.255.255 scope global eth0
       valid_lft forever preferred_lft forever

My ubuntu hosts file:

127.0.0.1 localhost
127.0.1.1 my-hostname

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

It is possible to hack around this with sloppy entrypoint scripts that sed out the entires it shouldn't be necessary. This is especially frustrating as there doesn't seem to be support in the dockerd for enabling ipv6 only on the localhost interface (despite what the docs said you are required to provide a cidr for ip allocation on the non-local interface).

The real question here is what is the purpose of adding these ipv6 host file entries when docker has no intention of enabing IPv6 on the interfaces? This is incorrect behaviour and should be prioritised.

Simply removing the localhost attachment to ::1 (as ubuntu does) would basically resolve this as the other entries would only be used if explicitly referenced as ip6-localhost in which case there is no grey area as to ownerhip as the software has explicitly requested ip6 and not been fooled by the host file.

[kenyon]

@skyscooby, you should be testing with IPv6 enabled, not trying to work around the problems resulting from it being incorrectly disabled.

[skyscooby]

@kenyon that's a fine opinion if you are passionate about IPv6 but it is not a reason for injecting breaking behaviour into an infrastructure project that serves the masses for no good reason.. I'd suggest that you stop providing useless feedback on this thread so we can get a real fix going .

For those that are looking for a workaround to this until this gets addressed by professionals, this is working for me. Though if you already have an entrypoint you will need to merge into that or do a similar thing in your language of choice.

COPY docker-host-file-fix.sh /
ENTRYPOINT ["/docker-host-file-fix.sh"]

cat docker-host-file-fix.sh
#!/usr/bin/env bash

# Inline edits and moves don't work inside containers
sed 's/^::1.*localhost/::1\tip6-localhost/g' /etc/hosts > /etc/hosts.tmp
cat /etc/hosts.tmp > /etc/hosts
rm -f /etc/hosts.tmp

exec "$@"

[kenyon]

@skyscooby, IPv6 is enabled by default on every operating system. That's not an opinion, simply a fact. The breaking behavior is the disabling of it in docker. What we definitely do not need is more broken software because developers like you are testing in legacy-only environments.

[skyscooby]

@kenyon Why is docker shipping with ipv6 disabled by default in all distro then? I'll agree that this would largely be a mute point if is was just enabled by default (at minimum on the localhost interface) if detected in the underlying OS..

But it also doesn't change the fact that the current implementation is wrong and this is a bug that shouldn't be used to extort people into using IPv6 in environments where it is not necessary.

[krobertson]

because of developers like you

By many of @kenyon’s comments, he is simply biased and toxic.

Simple point: if a thing can be enabled and/or disabled, it should therefore work correctly and equally in both states. If not, fix it or remove the option. Very simple.

We don’t use use ipv6 internally and don’t need it internally. As such, we disable it. If we aren’t using something, no need to increase our surface for attack. Basic security principal. We do this with many things.

[azra1l]

excuse my limited understanding, i am somewhat new to docker.

i have ipv6 disabled. i am trying to use a 3rd party software in docker and apparently it stumbles over the ipv6 localhost entry made upon runtime.
software is called OPSI and it's an opensource software deployment solution. i want to use it in docker as a test environment.

if ipv6 is disabled, it makes zero sense to have ipv6 entries in /etc/hosts, correct?
and it breaks stuff (which it shouldn't, but that's whole different story).

so all things considered, ideally it would only add ipv6 entries to /etc/hosts when ipv6 is enabled, correct?

i am just wondering, maybe someone can eli5, why is this issue still a thing when what i wrote above is a simple no-brainer?

[couling]

It's a shame that this has somehow sparked some holy war over IPv6. It's really nothing to do with IPv6 or not... it's about docker adding hosts entries for non-existent addresses.

it cannot be correct for docker to create a hosts entry for

::1 localhost

But not also setup ::1 on the loopback device. It should be neither or both.

[anaander]

How is this still not addressed after all this time?