diff options
28 files changed, 1442 insertions, 208 deletions
@@ -1,19 +0,0 @@ -Project: IPv6-enabled OPNFV Project (ipv6) -Project Creation Date: November 25, 2014 -Project Category: Integration & Testing -Lifecycle State: Incubation -Primary Contact: Bin Hu -Project Lead: Bin Hu -Gerrit Repository: ipv6 -Jira Project Name: IPv6-enabled OPNFV Project -Jira Project Prefix: IPVSIX -Mailing list tag: [ipv6] -IRC: Server:freenode.net Channel:#opnfv-ipv6 -Etherpad: http://etherpad.opnfv.org/p/ipv6 - -Committers: -Bin Hu (AT&T), <bh526r@att.com> -Peter Lee (ClearPath), <plee@clearpathnet.com> -Prakash Ramchandran (Huawei), <prakash.ramchandran@huawei.com> -Sridhar Gaddam (RedHat), <sgaddam@redhat.com> or <sridhar.gaddam@redhat.com> - diff --git a/INFO.yaml b/INFO.yaml new file mode 100644 index 0000000..385995a --- /dev/null +++ b/INFO.yaml @@ -0,0 +1,41 @@ +--- +project: 'IPv6-enabled OPNFV Project (ipv6)' +project_creation_date: 'November 25, 2014' +project_category: 'Integration & Testing' +lifecycle_state: 'Mature' +project_lead: &opnfv_ipv6_ptl + name: 'Bin Hu' + email: 'bh526r@att.com' + id: 'bh526r' + company: 'att.com' + timezone: 'UTC-08:00' +primary_contact: *opnfv_ipv6_ptl +issue_tracking: + type: 'jira' + url: 'https://jira.opnfv.org/projects/IPVSIX' + key: 'IPVSIX' +mailing_list: + type: 'mailman2' + url: 'opnfv-tech-discuss@lists.opnfv.org' + tag: '[ipv6]' +realtime_discussion: + type: irc + server: 'freenode.net' + channel: '#opnfv-ipv6' +meetings: + - type: 'zoom+irc' + agenda: 'https://wiki.opnfv.org/display/meetings/Ipv6' + url: 'https://zoom.us/j/2362828999' + server: 'freenode.net' + channel: '#opnfv-meeting' + repeats: 'biweekly' + time: '16:00 UTC' +repositories: + - 'ipv6' +committers: + - <<: *opnfv_ipv6_ptl +tsc: + # yamllint disable rule:line-length + approval: '' + # yamllint enable rule:line-length + diff --git a/docs/conf.py b/docs/conf.py new file mode 100644 index 0000000..0cfa9d7 --- /dev/null +++ b/docs/conf.py @@ -0,0 +1,9 @@ +####################################################################### +# Copyright (c) 2018 AT&T +# All rights reserved. This program and the accompanying materials +# are made available under the terms of the Apache License, Version 2.0 +# which accompanies this distribution, and is available at +# http://www.apache.org/licenses/LICENSE-2.0 +####################################################################### + +from docs_conf.conf import * diff --git a/docs/conf.yaml b/docs/conf.yaml new file mode 100644 index 0000000..38ea565 --- /dev/null +++ b/docs/conf.yaml @@ -0,0 +1,3 @@ +--- +project_cfg: opnfv +project: ipv6 diff --git a/docs/index.rst b/docs/index.rst new file mode 100644 index 0000000..9e916bb --- /dev/null +++ b/docs/index.rst @@ -0,0 +1,18 @@ +.. _ipv6: + +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Bin Hu (AT&T) and Sridhar Gaddam (RedHat) + +==== +IPv6 +==== + +.. toctree:: + :numbered: + :maxdepth: 4 + + ./release/release-notes/index.rst + ./release/installation/index.rst + ./release/configguide/index.rst + ./release/userguide/index.rst diff --git a/docs/release/configguide/featureconfig.rst b/docs/release/configguide/featureconfig.rst index 3e3d99b..b05d6b1 100644 --- a/docs/release/configguide/featureconfig.rst +++ b/docs/release/configguide/featureconfig.rst @@ -6,7 +6,7 @@ IPv6 Configuration - Setting Up a Service VM as an IPv6 vRouter =============================================================== -This section provides instructions to set up a service VM as an IPv6 vRouter using OPNFV Euphrates Release +This section provides instructions to set up a service VM as an IPv6 vRouter using OPNFV Hunter Release installers. Because Open Daylight no longer supports L2-only option, and there is only limited support of IPv6 in L3 option of Open Daylight, setup of service VM as an IPv6 vRouter is only available under pure/native OpenStack environment. The deployment model may be HA or non-HA. The infrastructure may be @@ -28,7 +28,7 @@ Setup Manual in OpenStack-Only Environment ****************************************** If you intend to set up a service VM as an IPv6 vRouter in OpenStack-only environment of -OPNFV Euphrates Release, please **NOTE** that: +OPNFV Hunter Release, please **NOTE** that: * Because the anti-spoofing rules of Security Group feature in OpenStack prevents a VM from forwarding packets, we need to disable Security Group feature in the @@ -42,7 +42,7 @@ OPNFV Euphrates Release, please **NOTE** that: Install OPNFV and Preparation ----------------------------- -**OPNFV-NATIVE-INSTALL-1**: To install OpenStack-only environment of OPNFV Euphrates Release: +**OPNFV-NATIVE-INSTALL-1**: To install OpenStack-only environment of OPNFV Hunter Release: **Apex Installer**: diff --git a/docs/release/configguide/index.rst b/docs/release/configguide/index.rst index 974d49f..5f3c43f 100644 --- a/docs/release/configguide/index.rst +++ b/docs/release/configguide/index.rst @@ -11,7 +11,7 @@ IPv6 Configuration Guide :Abstract: This document provides the users with the Configuration Guide to set up a -service VM as an IPv6 vRouter using OPNFV Euphrates Release. +service VM as an IPv6 vRouter using OPNFV Hunter Release. .. toctree:: :numbered: diff --git a/docs/release/installation/index.rst b/docs/release/installation/index.rst index cf7e46e..229c7dc 100644 --- a/docs/release/installation/index.rst +++ b/docs/release/installation/index.rst @@ -11,7 +11,7 @@ IPv6 Installation Procedure :Abstract: This document provides the users with the Installation Procedure to install -OPNFV Euphrates Release on IPv6-only Infrastructure. +OPNFV Hunter Release on IPv6-only Infrastructure. .. toctree:: :numbered: diff --git a/docs/release/installation/installation.instruction.rst b/docs/release/installation/installation.instruction.rst index 8438840..d352059 100644 --- a/docs/release/installation/installation.instruction.rst +++ b/docs/release/installation/installation.instruction.rst @@ -10,8 +10,14 @@ This section provides instructions to install OPNFV on IPv6-only Infrastructure. All underlay networks and API endpoints will be IPv6-only except: -1. "admin" network in underlay/undercloud still has to be IPv4, due to lack of - support of IPMI over IPv6 or PXE over IPv6. +1. "admin" network in underlay/undercloud still has to be IPv4. + +* It was due to lack of support of IPMI over IPv6 or PXE over IPv6. +* iPXE does support IPv6 now. Ironic has added support for booting + nodes with IPv6. +* We are starting to work on enabling IPv6-only environment for all + networks. For TripleO, this work is still ongoing. + 2. Metadata server is still IPv4 only. Except the limitations above, the use case scenario of the IPv6-only @@ -25,7 +31,8 @@ infrastructure includes: 5. Inter VM communication (East-West routing) when VMs are spread across two compute nodes. 6. VNC access into a VM using IPv6 addresses. -7. IPv6 support in OVS VxLAN (and/or GRE) tunnel endpoints with OVS 2.6+ (**NEW**) +7. IPv6 support in OVS VxLAN (and/or GRE) tunnel endpoints with OVS 2.6+. +8. IPv6 support in iPXE, and booting nodes with IPv6 (**NEW**). ------------------------------------------- Install OPNFV in OpenStack-Only Environment diff --git a/docs/release/release-notes/release-notes.rst b/docs/release/release-notes/release-notes.rst index a53baae..a4e405e 100644 --- a/docs/release/release-notes/release-notes.rst +++ b/docs/release/release-notes/release-notes.rst @@ -6,7 +6,7 @@ OPNFV IPv6 Project Release Notes ================================ -This document provides the release notes for Euphrates of IPv6 Project. +This document provides the release notes for Hunter of IPv6 Project. .. contents:: :depth: 3 @@ -16,18 +16,30 @@ This document provides the release notes for Euphrates of IPv6 Project. Version History --------------- -+--------------------+--------------------+--------------------+--------------------+ -| **Date** | **Version** | **Author** | **Comment** | -| | | | | -+--------------------+--------------------+--------------------+--------------------+ -| 2017-09-10 | 0.1.0 | Bin Hu | First draft | -+--------------------+--------------------+--------------------+--------------------+ -| 2017-09-30 | 0.5.0 | Bin Hu | Baseline draft | -+--------------------+--------------------+--------------------+--------------------+ -| 2017-10-16 | 5.0.0 | Bin Hu | Release Ready | -+--------------------+--------------------+--------------------+--------------------| -| 2017-12-13 | 5.1.0 | Bin Hu | Euhprates 5.1 Ready| -+--------------------+--------------------+--------------------+--------------------+ ++--------------------+--------------------+--------------------+----------------------+ +| **Date** | **Version** | **Author** | **Comment** | ++--------------------+--------------------+--------------------+----------------------+ +| 2019-03-14 | 0.1.0 | Bin Hu | Initial draft | ++--------------------+--------------------+--------------------+----------------------+ +| 2019-05-04 | 1.0.0 | Bin Hu | Hunter 8.0 Release | ++--------------------+--------------------+--------------------+----------------------+ +| 2019-06-28 | 1.1.0 | Bin Hu | Hunter 8.1 Release | ++--------------------+--------------------+--------------------+----------------------+ + +Release Data +------------ + ++--------------------------------------+--------------------------------------+ +| **Project** | IPv6 | ++--------------------------------------+--------------------------------------+ +| **Repo/tag** | opnfv-8.1.0 | ++--------------------------------------+--------------------------------------+ +| **Release designation** | Hunter 8.1 | ++--------------------------------------+--------------------------------------+ +| **Release date** | June 28, 2019 | ++--------------------------------------+--------------------------------------+ +| **Purpose of the delivery** | OPNFV Hunter 8.1 Release | ++--------------------------------------+--------------------------------------+ Important Notes --------------- @@ -47,13 +59,15 @@ For details, please refer to our `User Guide <../userguide/index.html>`_. Summary ------- -This is the Euphrates release of the IPv6 feature as part of OPNFV, including: +This is the Hunter release of the IPv6 feature as part of OPNFV, including: * Installation of OPNFV on IPv6-Only Infrastructure by Apex Installer * Configuration of setting up a Service VM as an IPv6 vRouter in OpenStack-Only environment -* User Guide, which analyzes the gap of IPv6 support in OpenStack Ocata - and OpenDaylight Carbon. +* User Guide, which includes: + + * gap analysis of IPv6 support in OpenStack Rocky and OpenDaylight Fluorine + * exploration of IPv6 in container networking Please refer to our: @@ -87,7 +101,7 @@ Please refer to `Testing Methodology <../installation/index.html#testing-methodo References ---------- -For more information on the OPNFV Euphrates release, please see: +For more information on the OPNFV Hunter release, please see: http://www.opnfv.org/software diff --git a/docs/release/userguide/docker-ipv6-nat.rst b/docs/release/userguide/docker-ipv6-nat.rst new file mode 100644 index 0000000..eb07eaf --- /dev/null +++ b/docs/release/userguide/docker-ipv6-nat.rst @@ -0,0 +1,131 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Prakash Ramchandran + +=============== +Docker IPv6 NAT +=============== + +-------------------------------------------------- +What is the Issue with Using IPv6 with Containers? +-------------------------------------------------- + +Initially Docker was not created with IPv6 in mind. It was added later. As a +result, there are still several unresolved issues as to how IPv6 should be used +in a containerized world. + +Currently, you can let Docker give each container an IPv6 address from your +(public) pool, but this has disadvantages (Refer to [1]_): + +* Giving each container a publicly routable address means all ports (even + unexposed / unpublished ports) are suddenly reachable by everyone, if no + additional filtering is done. +* By default, each container gets a random IPv6 address, making it impossible + do DNS properly. An alternative is to assign a specific IPv6 address to each + container, but it is still an administrative hassle. +* Published ports won't work on IPv6, unless you have the userland proxy + enabled (which, for now, is enabled by default in Docker) +* The userland proxy, however, seems to be on its way out and has various + issues, such as: + + * It can use a lot of RAM. + * Source IP addresses are rewritten, making it completely unusable for many + purposes, e.g. mail servers. + +IPv6 for Docker can (depending on your setup) be pretty much unusable and +completely inconsistent with the way how IPv4 works. Docker images are mostly +designed with IPv4 NAT in mind. NAT provides a layer of security allowing only +published ports through. Letting container link to user-defined networks +provide inter-container communication. This does not go hand in hand with the +way Docker IPv6 works, requiring image maintainers to rethink/adapt their +images with IPv6 in mind. + +---------------------- +Why not IPv6 with NAT? +---------------------- + +So why not try resolve above issues by managing ``ip6tables`` to setup IPv6 NAT +for your containers, like how it is done by the Docker daemon for IPv4. This +requires a locally reserved address like we do for private IP in IPv4. These +are called in IPv6 as local unicast Ipv6 address. Let’s first understand IPv6 +addressing scheme. + +We note that there are 3 types of IPv6 addresses, and all use last or least +significant 64 bits as Interface ID derived by splitting 48-bit MAC address +into 24 bits + 24 bits and insert an FE00 hexadecimal number in between those +two and inverting the most significant bit to create an equivalent 64-bit MAC +called EUI-64 bit. Refer to [2]_ for details. + +**1. Global Unicast Address** + +This is equivalent to IPv4’s public address with always 001 as Most +Significant bits of Global Routing Prefix. Subnets are 16 opposed to 8 bits +in IPv4. + +.. figure:: images/global-unicast.jpg + :name: docker-ipv6-nat-figure1 + :width: 100% + +**2. Link-Local Address** + +Link-local addresses are used for communication among IPv6 hosts on a link +(broadcast segment) only. These addresses are not routable. This address always +starts with FE80. These are used for generating IPv6 addresses and 48 bits +following FE80 are always set to 0. Interface ID is usual EUI-64 generated from +MAC address on the NIC. + +.. figure:: images/link-local.jpg + :name: docker-ipv6-nat-figure2 + :width: 100% + +**3. Unique-Local Address** + +This type of IPv6 address is globally unique & used only in site local +communication. The second half of this address contain Interface ID and the +first half is divided among Prefix, Local Bit, Global ID and Subnet ID. + +.. figure:: images/unique-local.jpg + :name: docker-ipv6-nat-figure3 + :width: 100% + +Prefix is always set to 1111 110. L bit, is set to 1 if the address is locally +assigned. So far, the meaning of L bit to 0 is not defined. Therefore, Unique +Local IPv6 address always starts with ‘FD’. + +IPv6 addresses of all types are assigned to interfaces, not nodes (hosts). An +IPv6 unicast address refers to a single interface. Since each interface belongs +to a single node (host), any of that node's interfaces' unicast addresses may +be used as an identifier for the node(host). For IPv6 NAT we prefer site scope +to be within site scope using unique local address, so that they remain private +within the organization. + +.. figure:: images/unicast-scope.jpg + :name: docker-ipv6-nat-figure4 + :width: 100% + + Figure 1: Scope of IPv6 Unicast Addresses + +Based on the IPv6 scope now question arises as what is needed to be mapped to +what? Is it IPv6 to IPv4 or IPv6 to IPv6 with post? Thus, we land up with are +we talking NAT64 with dual stack or just NAT66. Is it a standard that is agreed +upon in IETF RFCs? Dwelling into questions bring us back to should we +complicate life with another docker-ipv6nat? + +The conclusion is simple: it is not worth it and it is highly recommended that +you go through the blog listed below [3]_. + +---------- +Conclusion +---------- + +As IPv6 Project team in OPNFV, we recommend that IPv6 NAT is not worth the +effort and should be discouraged. As part of our conclusion, we recommend that +please do not use IPv6 NAT for containers for any NFV use cases. + +---------- +References +---------- + +.. [1] https://github.com/robbertkl/docker-ipv6nat +.. [2] https://www.tutorialspoint.com/ipv6/ipv6_special_addresses.htm +.. [3] http://ipv6friday.org/blog/2011/12/ipv6-nat/ diff --git a/docs/release/userguide/docker-ipv6-simple-cluster-topology.rst b/docs/release/userguide/docker-ipv6-simple-cluster-topology.rst new file mode 100644 index 0000000..8690e03 --- /dev/null +++ b/docs/release/userguide/docker-ipv6-simple-cluster-topology.rst @@ -0,0 +1,118 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Prakash Ramchandran + +=================================== +Docker IPv6 Simple Cluster Topology +=================================== + +Using external switches or routers allows you to enable IPv6 communication +between containers on different hosts. We have two physical hosts: Host1 & +Host2, and we will study here two scenarios: one with Switch and the other +one with router on the top of hierarchy, connecting those 2 hosts. Both hosts +host a pair of containers in a cluster. The contents are borrowed from +article [1]_ below, which can be used on any Linux distro (CentOS, Ubuntu, +OpenSUSE etc) with latest kernel. A sample testing is pointed in the blog +article [2]_ as a variation using ESXi & older Ubuntu 14.04. + +---------------------------- +Switched Network Environment +---------------------------- + +Using routable IPv6 addresses allows you to realize communication between +containers on different hosts. Let’s have a look at a simple Docker IPv6 +cluster example: + +.. figure:: images/docker-ipv6-cluster-example.png + :name: docker-ipv6-cluster-figure1 + :width: 100% + + Figure 1: An Docker IPv6 Cluster Example + +The Docker hosts are in the ``2001:db8:0::/64`` subnet. Host1 is configured to +provide addresses from the ``2001:db8:1::/64`` subnet to its containers. It has +three routes configured: + +* Route all traffic to ``2001:db8:0::/64`` via eth0 +* Route all traffic to ``2001:db8:1::/64`` via docker0 +* Route all traffic to ``2001:db8:2::/64`` via Host2 with IP ``2001:db8:0::2`` + +Host1 also acts as a router on OSI layer 3. When one of the network clients +tries to contact a target that is specified in Host1’s routing table, Host1 +will forward the traffic accordingly. It acts as a router for all networks it +knows: ``2001:db8::/64``, ``2001:db8:1::/64``, and ``2001:db8:2::/64``. + +On Host2, we have nearly the same configuration. Host2’s containers will get +IPv6 addresses from ``2001:db8:2::/64``. Host2 has three routes configured: + +* Route all traffic to ``2001:db8:0::/64`` via eth0 +* Route all traffic to ``2001:db8:2::/64`` via docker0 +* Route all traffic to ``2001:db8:1::/64`` via Host1 with IP ``2001:db8:0::1`` + +The difference to Host1 is that the network ``2001:db8:2::/64`` is directly +attached to Host2 via its docker0 interface, whereas Host2 reaches +``2001:db8:1::/64`` via Host1’s IPv6 address ``2001:db8:0::1``. + +This way every container can contact every other container. The containers +Container1-* share the same subnet and contact each other directly. The traffic +between Container1-* and Container2-* will be routed via Host1 and Host2 +because those containers do not share the same subnet. + +In a switched environment every host must know all routes to every subnet. +You always must update the hosts’ routing tables once you add or remove a host +to the cluster. + +Every configuration in the diagram that is shown below the dashed line across +hosts is handled by Dockeri, such as the docker0 bridge IP address +configuration, the route to the Docker subnet on the host, the container IP +addresses and the routes on the containers. The configuration above the line +across hosts is up to the user and can be adapted to the individual environment. + +-------------------------- +Routed Network Environment +-------------------------- + +In a routed network environment, you replace the layer 2 switch with a layer 3 +router. Now the hosts just must know their default gateway (the router) and the +route to their own containers (managed by Docker). The router holds all routing +information about the Docker subnets. When you add or remove a host to this +environment, you just must update the routing table in the router instead of on +every host. + +.. figure:: images/routed-network-environment.png + :name: docker-ipv6-cluster-figure2 + :width: 100% + + Figure 2: A Routed Network Environment + +In this scenario, containers of the same host can communicate directly with +each other. The traffic between containers on different hosts will be routed +via their hosts and the router. For example, packet from Container1-1 to +Container2-1 will be routed through Host1, Router, and Host2 until it arrives +at Container2-1. + +To keep the IPv6 addresses short in this example a ``/48`` network is assigned +to every host. The hosts use a ``/64`` subnet of this for its own services and +one for Docker. When adding a third host, you would add a route for the subnet +``2001:db8:3::/48`` in the router and configure Docker on Host3 with +``--fixed-cidr-v6=2001:db8:3:1::/64``. + +Remember the subnet for Docker containers should at least have a size of +``/80``. This way an IPv6 address can end with the container’s MAC address and +you prevent NDP neighbor cache invalidation issues in the Docker layer. So if +you have a ``/64`` for your whole environment, use ``/76`` subnets for the +hosts and ``/80`` for the containers. This way you can use 4096 hosts with 16 +``/80`` subnets each. + +Every configuration in the diagram that is visualized below the dashed line +across hosts is handled by Docker, such as the docker0 bridge IP address +configuration, the route to the Docker subnet on the host, the container IP +addresses and the routes on the containers. The configuration above the line +across hosts is up to the user and can be adapted to the individual environment. + +---------- +References +---------- + +.. [1] https://docs.docker.com/v17.09/engine/userguide/networking/default_network/ipv6/#docker-ipv6-cluster +.. [2] http://www.debug-all.com/?p=128 diff --git a/docs/release/userguide/feature.usage.rst b/docs/release/userguide/feature.usage.rst index db47ea3..026ab21 100644 --- a/docs/release/userguide/feature.usage.rst +++ b/docs/release/userguide/feature.usage.rst @@ -2,34 +2,34 @@ .. http://creativecommons.org/licenses/by/4.0 .. (c) Bin Hu (AT&T) and Sridhar Gaddam (RedHat) -======================================= -Using IPv6 Feature of Euphrates Release -======================================= +==================================== +Using IPv6 Feature of Hunter Release +==================================== This section provides the users with gap analysis regarding IPv6 feature requirements with -OpenStack Ocata Official Release and Open Daylight Carbon Official Release. The gap analysis +OpenStack Rocky Official Release and Open Daylight Fluorine Official Release. The gap analysis serves as feature specific user guides and references when as a user you may leverage the IPv6 feature in the platform and need to perform some IPv6 related operations. -For more information, please find Neutron's IPv6 document for Ocata Release [1]_. +For more information, please find Neutron's IPv6 document for Rocky Release [1]_. ************************************** -IPv6 Gap Analysis with OpenStack Ocata +IPv6 Gap Analysis with OpenStack Rocky ************************************** This section provides users with IPv6 gap analysis regarding feature requirement with -OpenStack Neutron in Ocata Official Release. The following table lists the use cases / feature +OpenStack Neutron in Rocky Official Release. The following table lists the use cases / feature requirements of VIM-agnostic IPv6 functionality, including infrastructure layer and VNF -(VM) layer, and its gap analysis with OpenStack Neutron in Ocata Official Release. +(VM) layer, and its gap analysis with OpenStack Neutron in Rocky Official Release. Please **NOTE** that in terms of IPv6 support in OpenStack Neutron, there is no difference -between **Ocata** release and **Newton** release. +between **Rocky** release and prior, e.g. **Queens**, **Pike** and **Ocata**, release. .. table:: :class: longtable +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ - |Use Case / Requirement |Supported in Ocata |Notes | + |Use Case / Requirement |Supported in Rocky |Notes | +===========================================================+===================+====================================================================+ |All topologies work in a multi-tenant environment |Yes |The IPv6 design is following the Neutron tenant networks model; | | | |dnsmasq is being used inside DHCP network namespaces, while radvd | @@ -125,9 +125,9 @@ between **Ocata** release and **Newton** release. +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |IPv6 Support in "Allowed Address Pairs" Extension |Yes | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ - |Support for IPv6 Prefix Delegation. |Yes |Partial support in Ocata | + |Support for IPv6 Prefix Delegation. |Yes |Partial support in Rocky | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ - |Distributed Virtual Routing (DVR) support for IPv6 |**No** |In Ocata DVR implementation, IPv6 works. But all the IPv6 ingress/ | + |Distributed Virtual Routing (DVR) support for IPv6 |**No** |In Rocky DVR implementation, IPv6 works. But all the IPv6 ingress/ | | | |egress traffic is routed via the centralized controller node, i.e. | | | |similar to SNAT traffic. | | | |A fully distributed IPv6 router is not yet supported in Neutron. | @@ -149,78 +149,98 @@ between **Ocata** release and **Newton** release. |(keepalived+VRRP). | | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ -******************************************* -IPv6 Gap Analysis with Open Daylight Carbon -******************************************* +********************************************* +IPv6 Gap Analysis with Open Daylight Fluorine +********************************************* This section provides users with IPv6 gap analysis regarding feature requirement with -Open Daylight Carbon Official Release. The following table lists the use cases / feature +Open Daylight Fluorine Official Release. The following table lists the use cases / feature requirements of VIM-agnostic IPv6 functionality, including infrastructure layer and VNF -(VM) layer, and its gap analysis with Open Daylight Carbon Official Release. +(VM) layer, and its gap analysis with Open Daylight Fluorine Official Release. -**Open Daylight Carbon Status** +**Open Daylight Fluorine Status** -In Open Daylight Carbon official release, the legacy ``Old Netvirt`` identified by feature +In Open Daylight Fluorine official release, the legacy ``Old Netvirt`` identified by feature ``odl-ovsdb-openstack`` is deprecated and no longer supported. The ``New Netvirt`` identified by feature ``odl-netvirt-openstack`` is used. +Two new features are supported in Open Daylight Fluorine official release: + +* Support for advertising MTU info in IPv6 RAs +* IPv6 external connectivity for FLAT/VLAN based provider networks + .. table:: :class: longtable - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |Use Case / Requirement |Supported in ODL Carbon|Notes | - +==================================================+=======================+==============================================================+ - |REST API support for IPv6 subnet creation in ODL |Yes |Yes, it is possible to create IPv6 subnets in ODL using | - | | |Neutron REST API. | - | | | | - | | |For a network which has both IPv4 and IPv6 subnets, ODL | - | | |mechanism driver will send the port information which | - | | |includes IPv4/v6 addresses to ODL Neutron northbound API. | - | | |When port information is queried, it displays IPv4 and IPv6 | - | | |addresses. | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |IPv6 Router support in ODL: |Yes | | - | | | | - |1. Communication between VMs on same network | | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |IPv6 Router support in ODL: |Yes | | - | | | | - |2. Communication between VMs on different | | | - | networks connected to the same router | | | - | (east-west) | | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |IPv6 Router support in ODL: |**Work in Progress** |Work in progress. | - | | | | - |3. External routing (north-south) | | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |IPAM: Support for IPv6 Address assignment modes. |Yes |ODL IPv6 Router supports all the IPv6 Address assignment | - | | |modes along with Neutron DHCP Agent. | - |1. SLAAC | | | - |2. DHCPv6 Stateless | | | - |3. DHCPv6 Stateful | | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |When using ODL for L2 forwarding/tunneling, it is |Yes | | - |compatible with IPv6. | | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |Full support for IPv6 matching (i.e. IPv6, ICMPv6,|Yes | | - |TCP, UDP) in security groups. Ability to control | | | - |and manage all IPv6 security group capabilities | | | - |via Neutron/Nova API (REST and CLI) as well as | | | - |via Horizon | | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |Shared Networks support |Yes | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |IPv6 external L2 VLAN directly attached to a VM. |**ToDo** | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |ODL on an IPv6 only Infrastructure. |**Work in Progress** |Deploying OpenStack with ODL on an IPv6 only infrastructure | - | | |where the API endpoints are all IPv6 addresses. | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |VxLAN Tunnels with IPv6 Endpoints |Yes | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |Use Case / Requirement |Supported in ODL Fluorine|Notes | + +==================================================+=========================+==============================================================+ + |REST API support for IPv6 subnet creation in ODL |Yes |Yes, it is possible to create IPv6 subnets in ODL using | + | | |Neutron REST API. | + | | | | + | | |For a network which has both IPv4 and IPv6 subnets, ODL | + | | |mechanism driver will send the port information which | + | | |includes IPv4/v6 addresses to ODL Neutron northbound API. | + | | |When port information is queried, it displays IPv4 and IPv6 | + | | |addresses. | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |IPv6 Router support in ODL: |Yes | | + | | | | + |1. Communication between VMs on same network | | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |IPv6 Router support in ODL: |Yes | | + | | | | + |2. Communication between VMs on different | | | + | networks connected to the same router | | | + | (east-west) | | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |IPv6 Router support in ODL: |**NO** |This feature is targeted for Flourine Release. | + | | |In ODL Fluorine Release, RFE "IPv6 Inter-DC L3 North-South | + |3. External routing (north-south) | |Connectivity Using L3VPN Provider Network Types" Spec [3]_ is | + | | |merged. But the code patch has not been merged yet. | + | | |On the other hand, "IPv6 Cluster Support" is available in | + | | |Fluorine Release [4]_. Basically, existing IPv6 features were | + | | |enhanced to work in a three node ODL Clustered Setup. | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |IPAM: Support for IPv6 Address assignment modes. |Yes |ODL IPv6 Router supports all the IPv6 Address assignment | + | | |modes along with Neutron DHCP Agent. | + |1. SLAAC | | | + |2. DHCPv6 Stateless | | | + |3. DHCPv6 Stateful | | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |When using ODL for L2 forwarding/tunneling, it is |Yes | | + |compatible with IPv6. | | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |Full support for IPv6 matching (i.e. IPv6, ICMPv6,|Yes | | + |TCP, UDP) in security groups. Ability to control | | | + |and manage all IPv6 security group capabilities | | | + |via Neutron/Nova API (REST and CLI) as well as | | | + |via Horizon | | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |Shared Networks support |Yes | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |IPv6 external L2 VLAN directly attached to a VM. |Yes |Targeted for Flourine Release | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |ODL on an IPv6 only Infrastructure. |Yes |Deploying OpenStack with ODL on an IPv6 only infrastructure | + | | |where the API endpoints are all IPv6 addresses. | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |VxLAN Tunnels with IPv6 Endpoints |Yes | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |IPv6 L3VPN Dual Stack with Single router |Yes |Refer to "Dual Stack VM support in OpenDaylight" Spec [5]_. | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |IPv6 Inter Data Center using L3VPNs |Yes |Refer to "IPv6 Inter-DC L3 North-South connectivity using | + | | |L3VPN provider network types" Spec [3]_. | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |Support for advertising MTU info in IPv6 RAs |Yes | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |IPv6 external connectivity for FLAT/VLAN based |Yes | | + |provider networks | | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ References -.. [1] Neutron IPv6 Documentation for Ocata Release: http://docs.openstack.org/ocata/networking-guide/config-ipv6.html - +.. [1] Neutron IPv6 Documentation for Rocky Release: http://docs.openstack.org/neutron/rocky/admin/config-ipv6.html .. [2] How to Use Config-Drive for Metadata with IPv6 Network: http://superuser.openstack.org/articles/deploying-ipv6-only-tenants-with-openstack/ - +.. [3] https://docs.opendaylight.org/projects/netvirt/en/stable-fluorine/specs/oxygen/ipv6-interdc-l3vpn.html +.. [4] http://git.opendaylight.org/gerrit/#/c/66707/ +.. [5] https://docs.opendaylight.org/projects/netvirt/en/stable-fluorine/specs/oxygen/l3vpn-dual-stack-vms.html diff --git a/docs/release/userguide/gap-odl-carbon.rst b/docs/release/userguide/gap-odl-carbon.rst deleted file mode 100644 index 273a8db..0000000 --- a/docs/release/userguide/gap-odl-carbon.rst +++ /dev/null @@ -1,73 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) Bin Hu (AT&T) and Sridhar Gaddam (RedHat) - -=========================================== -IPv6 Gap Analysis with Open Daylight Carbon -=========================================== - -This section provides users with IPv6 gap analysis regarding feature requirement with -Open Daylight Carbon Official Release. The following table lists the use cases / feature -requirements of VIM-agnostic IPv6 functionality, including infrastructure layer and VNF -(VM) layer, and its gap analysis with Open Daylight Carbon Official Release. - -**Open Daylight Carbon Status** - -In Open Daylight Carbon official release, the legacy ``Old Netvirt`` identified by feature -``odl-ovsdb-openstack`` is deprecated and no longer supported. The ``New Netvirt`` -identified by feature ``odl-netvirt-openstack`` is used. - -.. table:: - :class: longtable - - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |Use Case / Requirement |Supported in ODL Carbon|Notes | - +==================================================+=======================+==============================================================+ - |REST API support for IPv6 subnet creation in ODL |Yes |Yes, it is possible to create IPv6 subnets in ODL using | - | | |Neutron REST API. | - | | | | - | | |For a network which has both IPv4 and IPv6 subnets, ODL | - | | |mechanism driver will send the port information which | - | | |includes IPv4/v6 addresses to ODL Neutron northbound API. | - | | |When port information is queried, it displays IPv4 and IPv6 | - | | |addresses. | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |IPv6 Router support in ODL: |Yes | | - | | | | - |1. Communication between VMs on same network | | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |IPv6 Router support in ODL: |Yes | | - | | | | - |2. Communication between VMs on different | | | - | networks connected to the same router | | | - | (east-west) | | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |IPv6 Router support in ODL: |**Work in Progress** |Work in progress. | - | | | | - |3. External routing (north-south) | | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |IPAM: Support for IPv6 Address assignment modes. |Yes |ODL IPv6 Router supports all the IPv6 Address assignment | - | | |modes along with Neutron DHCP Agent. | - |1. SLAAC | | | - |2. DHCPv6 Stateless | | | - |3. DHCPv6 Stateful | | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |When using ODL for L2 forwarding/tunneling, it is |Yes | | - |compatible with IPv6. | | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |Full support for IPv6 matching (i.e. IPv6, ICMPv6,|Yes | | - |TCP, UDP) in security groups. Ability to control | | | - |and manage all IPv6 security group capabilities | | | - |via Neutron/Nova API (REST and CLI) as well as | | | - |via Horizon | | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |Shared Networks support |Yes | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |IPv6 external L2 VLAN directly attached to a VM. |**ToDo** | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |ODL on an IPv6 only Infrastructure. |**Work in Progress** |Deploying OpenStack with ODL on an IPv6 only infrastructure | - | | |where the API endpoints are all IPv6 addresses. | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - |VxLAN Tunnels with IPv6 Endpoints |Yes | | - +--------------------------------------------------+-----------------------+--------------------------------------------------------------+ - diff --git a/docs/release/userguide/gap-odl-fluorine.rst b/docs/release/userguide/gap-odl-fluorine.rst new file mode 100644 index 0000000..7ed4f71 --- /dev/null +++ b/docs/release/userguide/gap-odl-fluorine.rst @@ -0,0 +1,95 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Bin Hu (AT&T) and Sridhar Gaddam (RedHat) + +============================================= +IPv6 Gap Analysis with Open Daylight Fluorine +============================================= + +This section provides users with IPv6 gap analysis regarding feature requirement with +Open Daylight Fluorine Official Release. The following table lists the use cases / feature +requirements of VIM-agnostic IPv6 functionality, including infrastructure layer and VNF +(VM) layer, and its gap analysis with Open Daylight Fluorine Official Release. + +**Open Daylight Fluorine Status** + +In Open Daylight Fluorine official release, the legacy ``Old Netvirt`` identified by feature +``odl-ovsdb-openstack`` is deprecated and no longer supported. The ``New Netvirt`` +identified by feature ``odl-netvirt-openstack`` is used. + +Two new features are supported in Open Daylight Fluorine official release: + +* Support for advertising MTU info in IPv6 RAs +* IPv6 external connectivity for FLAT/VLAN based provider networks + +.. table:: + :class: longtable + + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |Use Case / Requirement |Supported in ODL Fluorine|Notes | + +==================================================+=========================+==============================================================+ + |REST API support for IPv6 subnet creation in ODL |Yes |Yes, it is possible to create IPv6 subnets in ODL using | + | | |Neutron REST API. | + | | | | + | | |For a network which has both IPv4 and IPv6 subnets, ODL | + | | |mechanism driver will send the port information which | + | | |includes IPv4/v6 addresses to ODL Neutron northbound API. | + | | |When port information is queried, it displays IPv4 and IPv6 | + | | |addresses. | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |IPv6 Router support in ODL: |Yes | | + | | | | + |1. Communication between VMs on same network | | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |IPv6 Router support in ODL: |Yes | | + | | | | + |2. Communication between VMs on different | | | + | networks connected to the same router | | | + | (east-west) | | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |IPv6 Router support in ODL: |**NO** |This feature is targeted for Flourine Release. | + | | |In ODL Fluorine Release, RFE "IPv6 Inter-DC L3 North-South | + |3. External routing (north-south) | |Connectivity Using L3VPN Provider Network Types" Spec [1]_ is | + | | |merged. But the code patch has not been merged yet. | + | | |On the other hand, "IPv6 Cluster Support" is available in | + | | |Fluorine Release [2]_. Basically, existing IPv6 features were | + | | |enhanced to work in a three node ODL Clustered Setup. | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |IPAM: Support for IPv6 Address assignment modes. |Yes |ODL IPv6 Router supports all the IPv6 Address assignment | + | | |modes along with Neutron DHCP Agent. | + |1. SLAAC | | | + |2. DHCPv6 Stateless | | | + |3. DHCPv6 Stateful | | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |When using ODL for L2 forwarding/tunneling, it is |Yes | | + |compatible with IPv6. | | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |Full support for IPv6 matching (i.e. IPv6, ICMPv6,|Yes | | + |TCP, UDP) in security groups. Ability to control | | | + |and manage all IPv6 security group capabilities | | | + |via Neutron/Nova API (REST and CLI) as well as | | | + |via Horizon | | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |Shared Networks support |Yes | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |IPv6 external L2 VLAN directly attached to a VM. |Yes |Targeted for Flourine Release | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |ODL on an IPv6 only Infrastructure. |Yes |Deploying OpenStack with ODL on an IPv6 only infrastructure | + | | |where the API endpoints are all IPv6 addresses. | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |VxLAN Tunnels with IPv6 Endpoints |Yes | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |IPv6 L3VPN Dual Stack with Single router |Yes |Refer to "Dual Stack VM support in OpenDaylight" Spec [3]_. | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |IPv6 Inter Data Center using L3VPNs |Yes |Refer to "IPv6 Inter-DC L3 North-South connectivity using | + | | |L3VPN provider network types" Spec [1]_. | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |Support for advertising MTU info in IPv6 RAs |Yes | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + |IPv6 external connectivity for FLAT/VLAN based |Yes | | + |provider networks | | | + +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ + +.. [1] https://docs.opendaylight.org/projects/netvirt/en/stable-fluorine/specs/oxygen/ipv6-interdc-l3vpn.html +.. [2] http://git.opendaylight.org/gerrit/#/c/66707/ +.. [3] https://docs.opendaylight.org/projects/netvirt/en/stable-fluorine/specs/oxygen/l3vpn-dual-stack-vms.html diff --git a/docs/release/userguide/gap-os-ocata.rst b/docs/release/userguide/gap-os-rocky.rst index fa2f5b7..550a918 100644 --- a/docs/release/userguide/gap-os-ocata.rst +++ b/docs/release/userguide/gap-os-rocky.rst @@ -3,22 +3,22 @@ .. (c) Bin Hu (AT&T) and Sridhar Gaddam (RedHat) ====================================== -IPv6 Gap Analysis with OpenStack Ocata +IPv6 Gap Analysis with OpenStack Rocky ====================================== This section provides users with IPv6 gap analysis regarding feature requirement with -OpenStack Neutron in Ocata Official Release. The following table lists the use cases / feature +OpenStack Neutron in Rocky Official Release. The following table lists the use cases / feature requirements of VIM-agnostic IPv6 functionality, including infrastructure layer and VNF -(VM) layer, and its gap analysis with OpenStack Neutron in Ocata Official Release. +(VM) layer, and its gap analysis with OpenStack Neutron in Rocky Official Release. Please **NOTE** that in terms of IPv6 support in OpenStack Neutron, there is no difference -between **Ocata** release and **Newton** release. +between **Rocky** release and prior, e.g. **Queens**, **Pike** and **Ocata**, releases. .. table:: :class: longtable +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ - |Use Case / Requirement |Supported in Ocata |Notes | + |Use Case / Requirement |Supported in Rocky |Notes | +===========================================================+===================+====================================================================+ |All topologies work in a multi-tenant environment |Yes |The IPv6 design is following the Neutron tenant networks model; | | | |dnsmasq is being used inside DHCP network namespaces, while radvd | @@ -116,9 +116,9 @@ between **Ocata** release and **Newton** release. +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |IPv6 Support in "Allowed Address Pairs" Extension |Yes | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ - |Support for IPv6 Prefix Delegation. |Yes |Partial support in Ocata | + |Support for IPv6 Prefix Delegation. |Yes |Partial support in Rocky | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ - |Distributed Virtual Routing (DVR) support for IPv6 |**No** |In Ocata DVR implementation, IPv6 works. But all the IPv6 ingress/ | + |Distributed Virtual Routing (DVR) support for IPv6 |**No** |In Rocky DVR implementation, IPv6 works. But all the IPv6 ingress/ | | | |egress traffic is routed via the centralized controller node, i.e. | | | |similar to SNAT traffic. | | | |A fully distributed IPv6 router is not yet supported in Neutron. | diff --git a/docs/release/userguide/icmpv6-and-ndp-proxying-for-docker-containers.rst b/docs/release/userguide/icmpv6-and-ndp-proxying-for-docker-containers.rst new file mode 100644 index 0000000..3c5bf97 --- /dev/null +++ b/docs/release/userguide/icmpv6-and-ndp-proxying-for-docker-containers.rst @@ -0,0 +1,98 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Prakash Ramchandran + +============== +ICMPv6 and NDP +============== + +ICMP is a control protocol that is considered to be an integral part of IP, +although it is architecturally layered upon IP, i.e., it uses IP to carry its +data end-to-end just as a transport protocol like TCP or UDP does. ICMP +provides error reporting, congestion reporting, and first-hop gateway +redirection. + +To communicate on its directly-connected network, a host must implement the +communication protocol used to interface to that network. We call this a link +layer or media-access layer protocol. + +IPv4 uses ARP for link and MAC address discovery. In contrast IPv6 uses ICMPv6 +though Neighbor Discovery Protocol (NDP). NDP defines five ICMPv6 packet types +for the purpose of router solicitation, router advertisement, neighbor +solicitation, neighbor advertisement, and network redirects. +Refer RFC 122 & 3122. + +Contrasting with ARP, NDP includes Neighbor Unreachability Detection (NUD), +thus, improving robustness of packet delivery in the presence of failing +routers or links, or mobile nodes. As long as hosts were using single network +interface, the isolation between local network and remote network was simple. +With requirements of multihoming for hosts with multiple interfaces and +multiple destination packet transfers, the complications of maintaining all +routing to remote gateways has disappeared. + +To add container network to local network and IPv6 link local networks and +virtual or logical routing on hosts, the complexity is now exponential. +In order to maintain simplicity of end hosts (physical, virtual or containers), +just maintaining sessions and remote gateways (routers), and maintaining routes +independent of session state is still desirable for scaling internet connected +end hosts. + +For more details, please refer to [1]_. + +----------------------------------------- +IPv6-only Containers & Using NDP Proxying +----------------------------------------- + +IPv6-only containers will need to fully depend on NDP proxying. + +If your Docker host is the only part of an IPv6 subnet but does not have an +IPv6 subnet assigned, you can use NDP Proxying to connect your containers to +the internet via IPv6. + +If the host with IPv6 address ``2001:db8::c001`` is part of the subnet +``2001:db8::/64``, and your IaaS provider allows you to configure the IPv6 +addresses ``2001:db8::c000 to 2001:db8::c00f``, your network configuration may +look like the following: + +.. code-block:: bash + + $ ip -6 addr show + + 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 + inet6 ::1/128 scope host + valid_lft forever preferred_lft forever + 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 + inet6 2001:db8::c001/64 scope global + valid_lft forever preferred_lft forever + inet6 fe80::601:3fff:fea1:9c01/64 scope link + valid_lft forever preferred_lft forever + +To split up the configurable address range into two subnets +``2001:db8::c000/125 and 2001:db8::c008/125``, use the following daemon.json +settings. + +.. code-block:: bash + + { + "ipv6": true, + "fixed-cidr-v6": "2001:db8::c008/125" + } + +The first subnet will be used by non-Docker processes on the host, and the +second will be used by Docker. + +.. figure:: images/ndp-proxying.png + :name: icmpv6-figure1 + :width: 100% + + Figure: Using NDP Proxying + +For more details, please refer to [2]_. + +---------- +References +---------- + +.. [1] https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol +.. [2] https://docs.docker.com/v17.09/engine/userguide/networking/default_network/ipv6/#using-ndp-proxying + diff --git a/docs/release/userguide/images/docker-ipv6-cluster-example.png b/docs/release/userguide/images/docker-ipv6-cluster-example.png Binary files differnew file mode 100644 index 0000000..7b0b190 --- /dev/null +++ b/docs/release/userguide/images/docker-ipv6-cluster-example.png diff --git a/docs/release/userguide/images/global-unicast.jpg b/docs/release/userguide/images/global-unicast.jpg Binary files differnew file mode 100644 index 0000000..2eedf73 --- /dev/null +++ b/docs/release/userguide/images/global-unicast.jpg diff --git a/docs/release/userguide/images/link-local.jpg b/docs/release/userguide/images/link-local.jpg Binary files differnew file mode 100644 index 0000000..e0f00aa --- /dev/null +++ b/docs/release/userguide/images/link-local.jpg diff --git a/docs/release/userguide/images/ndp-proxying.png b/docs/release/userguide/images/ndp-proxying.png Binary files differnew file mode 100644 index 0000000..30bb43f --- /dev/null +++ b/docs/release/userguide/images/ndp-proxying.png diff --git a/docs/release/userguide/images/routed-network-environment.png b/docs/release/userguide/images/routed-network-environment.png Binary files differnew file mode 100644 index 0000000..3a30aaf --- /dev/null +++ b/docs/release/userguide/images/routed-network-environment.png diff --git a/docs/release/userguide/images/unicast-scope.jpg b/docs/release/userguide/images/unicast-scope.jpg Binary files differnew file mode 100644 index 0000000..e518e68 --- /dev/null +++ b/docs/release/userguide/images/unicast-scope.jpg diff --git a/docs/release/userguide/images/unique-local.jpg b/docs/release/userguide/images/unique-local.jpg Binary files differnew file mode 100644 index 0000000..351f081 --- /dev/null +++ b/docs/release/userguide/images/unique-local.jpg diff --git a/docs/release/userguide/index.rst b/docs/release/userguide/index.rst index 3e2f4c1..30869aa 100644 --- a/docs/release/userguide/index.rst +++ b/docs/release/userguide/index.rst @@ -4,24 +4,45 @@ .. http://creativecommons.org/licenses/by/4.0 .. (c) Bin Hu (AT&T) and Sridhar Gaddam (RedHat) -======================================= -Using IPv6 Feature of Euphrates Release -======================================= +==================================== +Using IPv6 Feature of Hunter Release +==================================== :Abstract: -This section provides the users with gap analysis regarding IPv6 feature requirements with -OpenStack Ocata Official Release and Open Daylight Carbon Official Release. The gap analysis -serves as feature specific user guides and references when as a user you may leverage the -IPv6 feature in the platform and need to perform some IPv6 related operations. +This section provides the users with: -For more information, please find `Neutron's IPv6 document for Ocata Release -<http://docs.openstack.org/ocata/networking-guide/config-ipv6.html>`_. +* Gap Analysis regarding IPv6 feature requirements with OpenStack Rocky + Official Release +* Gap Analysis regarding IPv6 feature requirements with Open Daylight Fluorine + Official Release +* IPv6 Setup in Container Networking +* Use of Neighbor Discovery (ND) Proxy to connect IPv6-only container to + external network +* Docker IPv6 Simple Cluster Topology +* Study and recommendation regarding Docker IPv6 NAT + +The gap analysis serves as feature specific user guides and references when +as a user you may leverage the IPv6 feature in the platform and need to perform +some IPv6 related operations. + +The IPv6 Setup in Container Networking serves as feature specific user guides +and references when as a user you may want to explore IPv6 in Docker container +environment. The use of NDP Proxying is explored to connect IPv6-only +containers to external network. The Docker IPv6 simple cluster topology is +studied with two Hosts, each with 2 Docker containers. Docker IPv6 NAT topic +is also explored. + +For more information, please find `Neutron's IPv6 document for Rocky Release +<http://docs.openstack.org/neutron/rocky/admin/config-ipv6.html>`_. .. toctree:: :numbered: :maxdepth: 4 - ./gap-os-ocata.rst - ./gap-odl-carbon.rst - + ./gap-os-rocky.rst + ./gap-odl-fluorine.rst + ./ipv6-in-container-networking.rst + ./icmpv6-and-ndp-proxying-for-docker-containers.rst + ./docker-ipv6-simple-cluster-topology.rst + ./docker-ipv6-nat.rst diff --git a/docs/release/userguide/ipv6-in-container-networking.rst b/docs/release/userguide/ipv6-in-container-networking.rst new file mode 100644 index 0000000..2792882 --- /dev/null +++ b/docs/release/userguide/ipv6-in-container-networking.rst @@ -0,0 +1,728 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Prakash Ramchandran + +====================================== +Exploring IPv6 in Container Networking +====================================== + +This document is the summary of how to use IPv6 with Docker. + +The defualt Docker container uses 172.17.0.0/24 subnet with 172.17.0.1 as gateway. +So IPv6 network needs to be enabled and configured before we can use it with IPv6 +traffic. + +We will describe how to use IPv6 in Docker in the following 5 sections: + +1. Install Docker Community Edition (CE) +2. IPv6 with Docker +3. Design Simple IPv6 Topologies +4. Design Solutions +5. Challenges in Production Use + +------------------------------------- +Install Docker Community Edition (CE) +------------------------------------- + +**Step 3.1.1**: Download Docker (CE) on your system from "this link" [1]_. + +For Ubuntu 16.04 Xenial x86_64, please refer to "Docker CE for Ubuntu" [2]_. + +**Step 3.1.2**: Refer to "this link" [3]_ to install Docker CE on Xenial. + +**Step 3.1.3**: Once you installed the docker, you can verify the standalone +default bridge nework as follows: + +.. code-block:: bash + + $ docker network ls + NETWORK ID NAME DRIVER SCOPE + b9e92f9a8390 bridge bridge local + 74160ae686b9 host host local + 898fbb0a0c83 my_bridge bridge local + 57ac095fdaab none null local + +Note that: + +* the details may be different with different network drivers. +* User-defined bridge networks are the best when you need multiple containers + to communicate on the same Docker host. +* Host networks are the best when the network stack should not be isolated from + the Docker host, but you want other aspects of the container to be isolated. +* Overlay networks are the best when you need containers running on different + Docker hosts to communicate, or when multiple applications work together + using swarm services. +* Macvlan networks are the best when you are migrating from a VM setup or need + your containers to look like physical hosts on your network, each with a + unique MAC address. +* Third-party network plugins allow you to integrate Docker with specialized + network stacks. Please refer to "Docker Networking Tutorials" [4]_. + +.. code-block:: bash + + # This will have docker0 default bridge details showing + # ipv4 172.17.0.1/16 and + # ipv6 fe80::42:4dff:fe2f:baa6/64 entries + + $ ip addr show + 11: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default + link/ether 02:42:4d:2f:ba:a6 brd ff:ff:ff:ff:ff:ff + inet 172.17.0.1/16 scope global docker0 + valid_lft forever preferred_lft forever + inet6 fe80::42:4dff:fe2f:baa6/64 scope link + valid_lft forever preferred_lft forever + +Thus we see here a simple defult ipv4 networking for docker. Inspect and verify +that IPv6 address is not listed here showing its enabled but not used by +default docker0 bridge. + +You can create user defined bridge network using command like ``my_bridge`` +below with other than default, e.g. 172.18.0.0/24 here. **Note** that ``--ipv6`` +is not specified yet + +.. code-block:: bash + + $ sudo docker network create \ + --driver=bridge \ + --subnet=172.18.0.0/24 \ + --gaeway= 172.18.0.1 \ + my_bridge + + $ docker network inspect bridge + [ + { + "Name": "bridge", + "Id": "b9e92f9a839048aab887081876fc214f78e8ce566ef5777303c3ef2cd63ba712", + "Created": "2017-10-30T23:32:15.676301893-07:00", + "Scope": "local", + "Driver": "bridge", + "EnableIPv6": false, + "IPAM": { + "Driver": "default", + "Options": null, + "Config": [ + { + "Subnet": "172.17.0.0/16", + "Gateway": "172.17.0.1" + } + ] + }, + "Internal": false, + "Attachable": false, + "Ingress": false, + "ConfigFrom": { + "Network": "" + }, + "ConfigOnly": false, + "Containers": { + "ea76bd4694a8073b195dd712dd0b070e80a90e97b6e2024b03b711839f4a3546": { + "Name": "registry", + "EndpointID": "b04dc6c5d18e3bf4e4201aa8ad2f6ad54a9e2ea48174604029576e136b99c49d", + "MacAddress": "02:42:ac:11:00:02", + "IPv4Address": "172.17.0.2/16", + "IPv6Address": "" + } + }, + "Options": { + "com.docker.network.bridge.default_bridge": "true", + "com.docker.network.bridge.enable_icc": "true", + "com.docker.network.bridge.enable_ip_masquerade": "true", + "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0", + "com.docker.network.bridge.name": "docker0", + "com.docker.network.driver.mtu": "1500" + }, + "Labels": {} + } + ] + + $ sudo docker network inspect my_bridge + [ + { + "Name": "my_bridge", + "Id": "898fbb0a0c83acc0593897f5af23b1fe680d38b804b0d5a4818a4117ac36498a", + "Created": "2017-07-16T17:59:55.388151772-07:00", + "Scope": "local", + "Driver": "bridge", + "EnableIPv6": false, + "IPAM": { + "Driver": "default", + "Options": {}, + "Config": [ + { + "Subnet": "172.18.0.0/16", + "Gateway": "172.18.0.1" + } + ] + }, + "Internal": false, + "Attachable": false, + "Ingress": false, + "ConfigFrom": { + "Network": "" + }, + "ConfigOnly": false, + "Containers": {}, + "Options": {}, + "Labels": {} + } + ] + +You can note that IPv6 is not enabled here yet as seen through network inspect. +Since we have only IPv4 installed with Docker, we will move to enable IPv6 for +Docker in the next step. + +---------------- +IPv6 with Docker +---------------- + +Verifyig IPv6 with Docker involves the following steps: + +**Step 3.2.1**: Enable ipv6 support for Docker + +In the simplest term, the first step is to enable IPv6 on Docker on Linux hosts. +Please refer to "this link" [5]_: + +* Edit ``/etc/docker/daemon.json`` +* Set the ``ipv6`` key to true. + +.. code-block:: bash + + {{{ "ipv6": true }}} + +Save the file. + +**Step 3.2.1.1**: Set up IPv6 addressing for Docker in ``daemon.json`` + +If you need IPv6 support for Docker containers, you need to enable the option +on the Docker daemon ``daemon.json`` and reload its configuration, before +creating any IPv6 networks or assigning containers IPv6 addresses. + +When you create your network, you can specify the ``--ipv6`` flag to enable +IPv6. You can't selectively disable IPv6 support on the default bridge network. + +**Step 3.2.1.2**: Enable forwarding from Docker containers to the outside world + +By default, traffic from containers connected to the default bridge network is +not forwarded to the outside world. To enable forwarding, you need to change +two settings. These are not Docker commands and they affect the Docker host's +kernel. + +* Setting 1: Configure the Linux kernel to allow IP forwarding: + +.. code-block:: bash + + $ sysctl net.ipv4.conf.all.forwarding=1 + +* Setting 2: Change the policy for the iptables FORWARD policy from DROP to ACCEPT. + +.. code-block:: bash + + $ sudo iptables -P FORWARD ACCEPT + +These settings do not persist across a reboot, so you may need to add them to +a start-up script. + +**Step 3.2.1.3**: Use the default bridge network + +The default bridge network is considered a legacy detail of Docker and is not +recommended for production use. Configuring it is a manual operation, and it +has technical shortcomings. + +**Step 3.2.1.4**: Connect a container to the default bridge network + +If you do not specify a network using the ``--network`` flag, and you do +specify a network driver, your container is connected to the default bridge +network by default. Containers connected to the default bridge network can +communicate, but only by IP address, unless they are linked using the legacy +``--link`` flag. + +**Step 3.2.1.5**: Configure the default bridge network + +To configure the default bridge network, you specify options in ``daemon.json``. +Here is an example of ``daemon.json`` with several options specified. Only +specify the settings you need to customize. + +.. code-block:: bash + + { + "bip": "192.168.1.5/24", + "fixed-cidr": "192.168.1.5/25", + "fixed-cidr-v6": "2001:db8::/64", + "mtu": 1500, + "default-gateway": "10.20.1.1", + "default-gateway-v6": "2001:db8:abcd::89", + "dns": ["10.20.1.2","10.20.1.3"] + } + +Restart Docker for the changes to take effect. + +**Step 3.2.1.6**: Use IPv6 with the default bridge network + +If you configure Docker for IPv6 support (see **Step 2.1.1**), the default +bridge network is also configured for IPv6 automatically. Unlike user-defined +bridges, you cannot selectively disable IPv6 on the default bridge. + +**Step 3.2.1.7**: Reload the Docker configuration file + +.. code-block:: bash + + $ systemctl reload docker + +**Step 3.2.1.8**: You can now create networks with the ``--ipv6`` flag and assign +containers IPv6 addresses. + +**Step 3.2.1.9**: Verify your host and docker networks + +.. code-block:: bash + + $ docker ps + CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES + ea76bd4694a8 registry:2 "/entrypoint.sh /e..." x months ago Up y months 0.0.0.0:4000->5000/tcp registry + + $ docker network ls + NETWORK ID NAME DRIVER SCOPE + b9e92f9a8390 bridge bridge local + 74160ae686b9 host host local + 898fbb0a0c83 my_bridge bridge local + 57ac095fdaab none null local + +**Step 3.2.1.10**: Edit ``/etc/docker/daemon.json`` and set the ipv6 key to true. + +.. code-block:: bash + + { + "ipv6": true + } + +Save the file. + +**Step 3.2.1.11**: Reload the Docker configuration file. + +.. code-block:: bash + + $ sudo systemctl reload docker + +**Step 3.2.1.12**: You can now create networks with the ``--ipv6`` flag and +assign containers IPv6 addresses using the ``--ip6`` flag. + +.. code-block:: bash + + $ sudo docker network create --ipv6 --driver bridge alpine-net--fixed-cidr-v6 2001:db8:1/64 + + # "docker network create" requires exactly 1 argument(s). + # See "docker network create --help" + +Earlier, user was allowed to create a network, or start the daemon, without +specifying an IPv6 ``--subnet``, or ``--fixed-cidr-v6`` respectively, even when +using the default builtin IPAM driver, which does not support auto allocation +of IPv6 pools. In another word, it was an incorrect configurations, which had +no effect on IPv6 stuff. It was a no-op. + +A fix cleared that so that Docker will now correctly consult with the IPAM +driver to acquire an IPv6 subnet for the bridge network, when user did not +supply one. + +If the IPAM driver in use is not able to provide one, network creation would +fail (in this case the default bridge network). + +So what you see now is the expected behavior. You need to remove the ``--ipv6`` +flag when you start the daemon, unless you pass a ``--fixed-cidr-v6`` pool. We +should probably clarify this somewhere. + +The above was found on following Docker. + +.. code-block:: bash + + $ docker info + Containers: 27 + Running: 1 + Paused: 0 + Stopped: 26 + Images: 852 + Server Version: 17.06.1-ce-rc1 + Storage Driver: aufs + Root Dir: /var/lib/docker/aufs + Backing Filesystem: extfs + Dirs: 637 + Dirperm1 Supported: false + 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: + apparmor + seccomp + Profile: default + Kernel Version: 3.13.0-88-generic + Operating System: Ubuntu 16.04.2 LTS + OSType: linux + Architecture: x86_64 + CPUs: 4 + Total Memory: 11.67GiB + Name: aatiksh + ID: HS5N:T7SK:73MD:NZGR:RJ2G:R76T:NJBR:U5EJ:KP5N:Q3VO:6M2O:62CJ + Docker Root Dir: /var/lib/docker + Debug Mode (client): false + Debug Mode (server): false + Registry: https://index.docker.io/v1/ + Experimental: false + Insecure Registries: + 127.0.0.0/8 + Live Restore Enabled: false + +**Step 3.2.2**: Check the network drivers + +Among the 4 supported drivers, we will be using "User-Defined Bridge Network" [6]_. + +----------------------------- +Design Simple IPv6 Topologies +----------------------------- + +**Step 3.3.1**: Creating IPv6 user-defined subnet. + +Let's create a Docker with IPv6 subnet: + +.. code-block:: bash + + $ sudo docker network create \ + --ipv6 \ + --driver=bridge \ + --subnet=172.18.0.0/16 \ + --subnet=fcdd:1::/48 \ + --gaeway= 172.20.0.1 \ + my_ipv6_bridge + + # Error response from daemon: + + cannot create network 8957e7881762bbb4b66c3e2102d72b1dc791de37f2cafbaff42bdbf891b54cc3 (br-8957e7881762): conflicts with network + no matching subnet for range 2002:ac14:0000::/48 + + # try changing to ip-addess-range instead of subnet for ipv6. + # networks have overlapping IPv4 + + NETWORK ID NAME DRIVER SCOPE + b9e92f9a8390 bridge bridge local + 74160ae686b9 host host local + 898fbb0a0c83 my_bridge bridge local + 57ac095fdaab none null local + no matching subnet for gateway 172.20.01 + + # So finally making both as subnet and gateway as 172.20.0.1 works + + $ sudo docker network create \ + --ipv6 \ + --driver=bridge \ + --subnet=172.20.0.0/16 \ + --subnet=2002:ac14:0000::/48 \ + --gateway=172.20.0.1 \ + my_ipv6_bridge + 898fbb0a0c83acc0593897f5af23b1fe680d38b804b0d5a4818a4117ac36498a (br-898fbb0a0c83): + +Since lxdbridge used the ip range on the system there was a conflict. +This brings us to question how do we assign IPv6 and IPv6 address for our solutions. + +---------------- +Design Solutions +---------------- + +For best practices, please refer to "Best Practice Document" [7]_. + +Use IPv6 Calcualtor at "this link" [8]_. + +* For IPv4 172.16.0.1 = 6to4 prefix 2002:ac10:0001::/48 +* For IPv4 172.17.01/24 = 6to4 prefix 2002:ac11:0001::/48 +* For IPv4 172.18.0.1 = 6to4 prefix 2002:ac12:0001::/48 +* For IPv4 172.19.0.1 = 6to4 prefix 2002:ac13:0001::/48 +* For IPv4 172.20.0.0 = 6to4 prefix 2002:ac14:0000::/48 + +To avoid overlaping IP's, let's use the .20 in our design: + +.. code-block:: bash + + $ sudo docker network create \ + --ipv6 \ + --driver=bridge \ + --subnet=172.20.0.0/24 \ + --subnet=2002:ac14:0000::/48 + --gateway=172.20.0.1 + my_ipv6_bridge + + # created ... + + 052da268171ce47685fcdb68951d6d14e70b9099012bac410c663eb2532a0c87 + + $ docker network ls + NETWORK ID NAME DRIVER SCOPE + b9e92f9a8390 bridge bridge local + 74160ae686b9 host host local + 898fbb0a0c83 my_bridge bridge local + 052da268171c my_ipv6_bridge bridge local + 57ac095fdaab none null local + + # Note the first 16 digits is used here as network id from what we got + # whaen we created it. + + $ docker network inspect my_ipv6_bridge + [ + { + "Name": "my_ipv6_bridge", + "Id": "052da268171ce47685fcdb68951d6d14e70b9099012bac410c663eb2532a0c87", + "Created": "2018-03-16T07:20:17.714212288-07:00", + "Scope": "local", + "Driver": "bridge", + "EnableIPv6": true, + "IPAM": { + "Driver": "default", + "Options": {}, + "Config": [ + { + "Subnet": "172.20.0.0/16", + "Gateway": "172.20.0.1" + }, + { + "Subnet": "2002:ac14:0000::/48" + } + ] + }, + "Internal": false, + "Attachable": false, + "Ingress": false, + "ConfigFrom": { + "Network": "" + }, + "ConfigOnly": false, + "Containers": {}, + "Options": {}, + "Labels": {} + } + ] + +Note that: + +* IPv6 flag is ebnabled and that IPv6 range is listed besides Ipv4 gateway. +* We are mapping IPv4 and IPv6 address to simplify assignments as per "Best + Pratice Document" [7]_. + +Testing the solution and topology: + +.. code-block:: bash + + $ sudo docker run hello-world + Hello from Docker! + +This message shows that your installation appears to be working correctly. + +To generate this message, Docker took the following steps: + +1. The Docker client contacted the Docker daemon. +2. The Docker daemon pulled the "hello-world" image from the Docker Hub. +3. The Docker daemon created a new container from that image which runs the + executable that produces the output you are currently reading. +4. The Docker daemon streamed that output to the Docker client, which sent it + to your terminal. + +To try something more ambitious, you can run an Ubuntu container with: + +.. code-block:: bash + + $ docker run -it ubuntu bash + + root@62b88b030f5a:/# ls + bin dev home lib64 mnt proc run srv tmp var + boot etc lib media opt root sbin sys usr + +On terminal it appears that the docker is functioning normally. + +Let's now push to see if we can use the ``my_ipv6_bridge`` network. +Please refer to "User-Defined Bridge Network" [9]_. + +++++++++++++++++++++++++++++++++++++++++++++ +Connect a container to a user-defined bridge +++++++++++++++++++++++++++++++++++++++++++++ + +When you create a new container, you can specify one or more ``--network`` +flags. This example connects a Nginx container to the ``my-net`` network. It +also publishes port 80 in the container to port 8080 on the Docker host, so +external clients can access that port. Any other container connected to the +``my-net`` network has access to all ports on the my-nginx container, and vice +versa. + +.. code-block:: bash + + $ docker create --name my-nginx \ + --network my-net \ + --publish 8080:80 \ + nginx:latest + +To connect a running container to an existing user-defined bridge, use the +``docker network connect`` command. The following command connects an +already-running ``my-nginx`` container to an already-existing ``my_ipv6_bridge`` +network: + +.. code-block:: bash + + $ docker network connect my_ipv6_bridge my-nginx + +Now we have connected the IPv6-enabled network to ``mynginx`` conatiner. Let's +start and verify its IP Address: + +.. code-block:: bash + + $ docker ps + CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES + df1df6ed3efb alpine "ash" 4 hours ago Up 4 hours alpine1 + ea76bd4694a8 registry:2 "/entrypoint.sh /e..." 9 months ago Up 4 months 0.0.0.0:4000->5000/tcp registry + +The ``nginx:latest`` image is not runnung, so let's start and log into it. + +.. code-block:: bash + + $ docker images | grep latest + REPOSITORY TAG IMAGE ID CREATED SIZE + nginx latest 73acd1f0cfad 2 days ago 109MB + alpine latest 3fd9065eaf02 2 months ago 4.15MB + swaggerapi/swagger-ui latest e0b4f5dd40f9 4 months ago 23.6MB + ubuntu latest d355ed3537e9 8 months ago 119MB + hello-world latest 1815c82652c0 9 months ago 1.84kB + +Now we do find the ``nginx`` and let`s run it + +.. code-block:: bash + + $ docker run -i -t nginx:latest /bin/bash + root@bc13944d22e1:/# ls + bin dev home lib64 mnt proc run srv tmp var + boot etc lib media opt root sbin sys usr + root@bc13944d22e1:/# + +Open another terminal and check the networks and verify that IPv6 address is +listed on the container: + +.. code-block:: bash + + $ docker ps + CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES + bc13944d22e1 nginx:latest "/bin/bash" About a minute ago Up About a minute 80/tcp loving_hawking + df1df6ed3efb alpine "ash" 4 hours ago Up 4 hours alpine1 + ea76bd4694a8 registry:2 "/entrypoint.sh /e..." 9 months ago Up 4 months 0.0.0.0:4000->5000/tcp registry + + $ ping6 bc13944d22e1 + + # On 2nd termoinal + + $ docker network ls + NETWORK ID NAME DRIVER SCOPE + b9e92f9a8390 bridge bridge local + 74160ae686b9 host host local + 898fbb0a0c83 my_bridge bridge local + 052da268171c my_ipv6_bridge bridge local + 57ac095fdaab none null local + + $ ip addr + 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default + 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 + 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 + link/ether 8c:dc:d4:6e:d5:4b brd ff:ff:ff:ff:ff:ff + inet 10.0.0.80/24 brd 10.0.0.255 scope global dynamic eno1 + valid_lft 558367sec preferred_lft 558367sec + inet6 2601:647:4001:739c:b80a:6292:1786:b26/128 scope global dynamic + valid_lft 86398sec preferred_lft 86398sec + inet6 fe80::8edc:d4ff:fe6e:d54b/64 scope link + valid_lft forever preferred_lft forever + 11: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default + link/ether 02:42:4d:2f:ba:a6 brd ff:ff:ff:ff:ff:ff + inet 172.17.0.1/16 scope global docker0 + valid_lft forever preferred_lft forever + inet6 fe80::42:4dff:fe2f:baa6/64 scope link + valid_lft forever preferred_lft forever + 20: br-052da268171c: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default + link/ether 02:42:5e:19:55:0d brd ff:ff:ff:ff:ff:ff + inet 172.20.0.1/16 scope global br-052da268171c + valid_lft forever preferred_lft forever + inet6 2002:ac14::1/48 scope global + valid_lft forever preferred_lft forever + inet6 fe80::42:5eff:fe19:550d/64 scope link + valid_lft forever preferred_lft forever + inet6 fe80::1/64 scope link + valid_lft forever preferred_lft forever + +Note that on the 20th entry we have the ``br-052da268171c`` with IPv6 +``inet6 2002:ac14::1/48`` scope global, which belongs to root@bc13944d22e1. + +At this time we have been able to provide a simple Docker with IPv6 solution. + ++++++++++++++++++++++++++++++++++++++++++++++++++ +Disconnect a container from a user-defined bridge ++++++++++++++++++++++++++++++++++++++++++++++++++ + +If another route needs to be added to ``nginx``, you need to modify the routes: + +.. code-block:: bash + + # using ip route commands + + $ ip r + default via 10.0.0.1 dev eno1 proto static metric 100 + default via 10.0.0.1 dev wlan0 proto static metric 600 + 10.0.0.0/24 dev eno1 proto kernel scope link src 10.0.0.80 + 10.0.0.0/24 dev wlan0 proto kernel scope link src 10.0.0.38 + 10.0.0.0/24 dev eno1 proto kernel scope link src 10.0.0.80 metric 100 + 10.0.0.0/24 dev wlan0 proto kernel scope link src 10.0.0.38 metric 600 + 10.0.8.0/24 dev lxdbr0 proto kernel scope link src 10.0.8.1 + 169.254.0.0/16 dev lxdbr0 scope link metric 1000 + 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 + 172.18.0.0/16 dev br-898fbb0a0c83 proto kernel scope link src 172.18.0.1 + 172.20.0.0/16 dev br-052da268171c proto kernel scope link src 172.20.0.1 + 192.168.99.0/24 dev vboxnet1 proto kernel scope link src 192.168.99.1 + +If the routes are correctly updated you should be able to see ``nginx`` web +page on link ``http://172.20.0.0.1`` + +We now have completed the exercise. + +To disconnect a running container from a user-defined bridge, use the +``docker network disconnect`` command. The following command disconnects the +``my-nginx`` container from the ``my-net`` network. + +.. code-block:: bash + + $ docker network disconnect my_ipv6_bridge my-nginx + +The IPv6 Docker we used is for demo purpose only. For real production we need +to follow one of the IPv6 solutions we have come across. + +---------------------------- +Challenges in Production Use +---------------------------- + +"This link" [10]_ discusses the details of the use of ``nftables`` which +is nextgen ``iptables``, and tries to build production worthy Docker for IPv6 +usage. + +---------- +References +---------- + +.. [1] https://www.docker.com/community-edition#/download +.. [2] https://store.docker.com/editions/community/docker-ce-server-ubuntu +.. [3] https://docs.docker.com/install/linux/docker-ce/ubuntu/#install-docker-ce-1 +.. [4] https://docs.docker.com/network/network-tutorial-host/#other-networking-tutorials +.. [5] https://docs.docker.com/config/daemon/ipv6/ +.. [6] https://docs.docker.com/network/ +.. [7] https://networkengineering.stackexchange.com/questions/119/ipv6-address-space-layout-best-practices +.. [8] http://www.gestioip.net/cgi-bin/subnet_calculator.cgi +.. [9] https://docs.docker.com/network/bridge/#use-ipv6-with-the-default-bridge-network +.. [10] https://stephank.nl/p/2017-06-05-ipv6-on-production-docker.html diff --git a/docs/requirements.txt b/docs/requirements.txt new file mode 100644 index 0000000..29bb434 --- /dev/null +++ b/docs/requirements.txt @@ -0,0 +1,6 @@ +lfdocs-conf +sphinx_opnfv_theme + +# Uncomment the following line if your project uses Sphinx to document +# HTTP APIs +# sphinxcontrib-httpdomain @@ -0,0 +1,17 @@ +[tox] +minversion = 1.6 +envlist = + docs, + docs-linkcheck +skipsdist = true + +[testenv:docs] +deps = -rdocs/requirements.txt +commands = + sphinx-build -b html -n -d {envtmpdir}/doctrees ./docs/ {toxinidir}/docs/_build/html + echo "Generated docs available in {toxinidir}/docs/_build/html" +whitelist_externals = echo + +[testenv:docs-linkcheck] +deps = -rdocs/requirements.txt +commands = sphinx-build -b linkcheck -d {envtmpdir}/doctrees ./docs/ {toxinidir}/docs/_build/linkcheck |
