Much like we saw with IPv4, user-defined networks can leverage IPv6 addressing. That is, all of the network-related parameters relate to both IPv4 and IPv6. In this chapter, we'll walk through defining a user-defined IPv6 network and demonstrate some of the related configuration options.
In this recipe, we'll be using a single Docker host. It is assumed that Docker is installed and is its default configuration. It is not required that the Docker service be enabled with the --ipv6 service-level parameter in order to use IPv6 addressing on user-defined networks.
When working with user-defined networks, we can define configuration for both IPv4 and IPv6. In addition, when we run containers we can specify both their IPv4 and IPv6 addresses. To demonstrate this, let's first define a user-defined network that has both IPv4 and IPv6 addressing:
user@docker1:~$ docker network create -d bridge --subnet 2003:ab11:0:0:c000::/66 --subnet 192.168.127.0/24 --ipv6 ipv6_bridge
The syntax of this command should be familiar to you from Chapter 3, User-Defined Networks, where we discussed user-defined networks. However, there are a couple of things to point out.
First, you'll notice that we've defined the --subnet parameter twice. In doing so, we defined both an IPv4 subnet as well as an IPv6 subnet. The --gateway and --aux-address fields can be used in a similar fashion when defining IPv4 and IPv6 addresses. Second, we defined an option to enable IPv6 on this network. If you do not define this option to enable IPv6 the gateway interface of the host will not be defined.
Once defined, let's start a container on the network to see what our configuration looks like:
user@docker1:~$ docker run -d --name=web1 --net=ipv6_bridge --ip 192.168.127.10 --ip6 2003:ab11::c000:0:0:10 jonlangemak/web_server_1
This syntax should also look familiar to you. Note that we specified that this container should be a member of the user-defined network ipv6_bridge. In doing so, we can also define both an IPv4 and IPv6 address for the container using the --ip and --ip6 parameters.
If we inspect the network, we should see the container attached as well as all of the relevant information related to both the network definition as well as the containers network interfaces:
user@docker1:~$ docker network inspect ipv6_bridge
[
{
"Name": "ipv6_bridge",
"Id": "0c6e760998ea6c5b99ba39f3c7ce63b113dab2276645e5fb7a2207f06273401a",
"Scope": "local",
"Driver": "bridge",
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "192.168.127.0/24"
},
{
"Subnet": "2003:ab11:0:0:c000::/66"
}
]
},
"Containers": {
"38e7ac1a0d0ce849a782c5045caf770c3310aca42e069e02a55d0c4a601e6b5a": {
"Name": "web1",
"EndpointID": "a80ac4b00d34d462ed98084a238980b3a75093591630b5832f105d400fabb4bb",
"MacAddress": "02:42:c0:a8:7f:0a",
"IPv4Address": "192.168.127.10/24",
"IPv6Address": "2003:ab11::c000:0:0:10/66"
}
},
"Options": {
"com.docker.network.enable_ipv6": "true"
}
}
]
user@docker1:~$By checking the host's network configuration, we should see that a new bridge has been created that matches up with these networks:
user@docker1:~$ ip addr show
…<Additional output removed for brevity>…
9: br-0b2efacf6f85: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:09:bc:9f:77 brd ff:ff:ff:ff:ff:ff
inet 192.168.127.1/24 scope global br-0b2efacf6f85
valid_lft forever preferred_lft forever
inet6 2003:ab11::c000:0:0:1/66 scope global
valid_lft forever preferred_lft forever
inet6 fe80::42:9ff:febc:9f77/64 scope link
valid_lft forever preferred_lft forever
inet6 fe80::1/64 scope link
valid_lft forever preferred_lft forever
…<Additional output removed for brevity>…
user@docker1:~$ If we check the container itself, we'll note that these interfaces are what the containers on this network will use for both their IPv4 and IPv6 default gateway:
user@docker1:~$ docker exec web1 ip route default via 192.168.127.1 dev eth0 192.168.127.0/24 dev eth0 proto kernel scope link src 192.168.127.10 user@docker1:~$ docker exec web1 ip -6 route 2003:ab11:0:0:c000::/66 dev eth0 proto kernel metric 256 fe80::/64 dev eth0 proto kernel metric 256 default via 2003:ab11::c000:0:0:1 dev eth0 metric 1024 user@docker1:~$
Just like the default network modes, user-defined networks do not support host firewall integration to support outbound masquerade or inbound port publishing. IPv6 connectivity on and off of the host is the same as the docker0 bridge in regard to having to route the IPv6 traffic natively.
You'll also note that if you start a second container on the host that embedded DNS works for both IPv4 and IPv6 addressing:
user@docker1:~$ docker run -d --name=web2 --net=ipv6_bridge jonlangemak/web_server_1 user@docker1:~$ user@docker1:~$ docker exec -it web2 ping web1 -c 2 PING web1 (192.168.127.10): 48 data bytes 56 bytes from 192.168.127.10: icmp_seq=0 ttl=64 time=0.113 ms 56 bytes from 192.168.127.10: icmp_seq=1 ttl=64 time=0.111 ms --- web1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.111/0.112/0.113/0.000 ms user@docker1:~$ user@docker1:~$ docker exec -it web2 ping6 web1 -c 2 PING web1 (2003:ab11::c000:0:0:10): 48 data bytes 56 bytes from web1.ipv6_bridge: icmp_seq=0 ttl=64 time=0.113 ms 56 bytes from web1.ipv6_bridge: icmp_seq=1 ttl=64 time=0.127 ms --- web1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.113/0.120/0.127/0.000 ms user@docker1:~$