diff options
Diffstat (limited to 'docs/release/userguide')
14 files changed, 442 insertions, 57 deletions
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 052e16d..026ab21 100644 --- a/docs/release/userguide/feature.usage.rst +++ b/docs/release/userguide/feature.usage.rst @@ -3,33 +3,33 @@ .. (c) Bin Hu (AT&T) and Sridhar Gaddam (RedHat) ==================================== -Using IPv6 Feature of Fraser Release +Using IPv6 Feature of Hunter Release ==================================== This section provides the users with gap analysis regarding IPv6 feature requirements with -OpenStack Pike Official Release and Open Daylight Nitrogen 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 Pike Release [1]_. +For more information, please find Neutron's IPv6 document for Rocky Release [1]_. -************************************* -IPv6 Gap Analysis with OpenStack Pike -************************************* +************************************** +IPv6 Gap Analysis with OpenStack Rocky +************************************** This section provides users with IPv6 gap analysis regarding feature requirement with -OpenStack Neutron in Pike 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 Pike 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 **Pike** release and **Ocata** release. +between **Rocky** release and prior, e.g. **Queens**, **Pike** and **Ocata**, release. .. table:: :class: longtable +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ - |Use Case / Requirement |Supported in Pike |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 **Pike** release and **Ocata** release. +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |IPv6 Support in "Allowed Address Pairs" Extension |Yes | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ - |Support for IPv6 Prefix Delegation. |Yes |Partial support in Pike | + |Support for IPv6 Prefix Delegation. |Yes |Partial support in Rocky | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ - |Distributed Virtual Routing (DVR) support for IPv6 |**No** |In Pike 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. | @@ -150,25 +150,30 @@ between **Pike** release and **Ocata** release. +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ ********************************************* -IPv6 Gap Analysis with Open Daylight Nitrogen +IPv6 Gap Analysis with Open Daylight Fluorine ********************************************* This section provides users with IPv6 gap analysis regarding feature requirement with -Open Daylight Nitrogen 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 Nitrogen Official Release. +(VM) layer, and its gap analysis with Open Daylight Fluorine Official Release. -**Open Daylight Nitrogen Status** +**Open Daylight Fluorine Status** -In Open Daylight Nitrogen 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 Nitrogen|Notes | + |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. | @@ -190,11 +195,11 @@ identified by feature ``odl-netvirt-openstack`` is used. | (east-west) | | | +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ |IPv6 Router support in ODL: |**NO** |This feature is targeted for Flourine Release. | - | | |In ODL Nitrogen Release, RFE "IPv6 Inter-DC L3 North-South | + | | |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 | - | | |Nitrogen Release [4]_. Basically, existing IPv6 features were | + | | |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 | @@ -214,21 +219,28 @@ identified by feature ``odl-netvirt-openstack`` is used. +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ |Shared Networks support |Yes | | +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ - |IPv6 external L2 VLAN directly attached to a VM. |**ToDo** | | + |IPv6 external L2 VLAN directly attached to a VM. |Yes |Targeted for Flourine Release | +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ - |ODL on an IPv6 only Infrastructure. |**Work in Progress** |Deploying OpenStack with ODL on an IPv6 only infrastructure | + |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 Pike Release: http://docs.openstack.org/neutron/pike/admin/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] http://docs.opendaylight.org/en/latest/submodules/netvirt/docs/specs/ipv6-interdc-l3vpn.html - +.. [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-nitrogen.rst b/docs/release/userguide/gap-odl-fluorine.rst index 5ca1de2..7ed4f71 100644 --- a/docs/release/userguide/gap-odl-nitrogen.rst +++ b/docs/release/userguide/gap-odl-fluorine.rst @@ -3,25 +3,30 @@ .. (c) Bin Hu (AT&T) and Sridhar Gaddam (RedHat) ============================================= -IPv6 Gap Analysis with Open Daylight Nitrogen +IPv6 Gap Analysis with Open Daylight Fluorine ============================================= This section provides users with IPv6 gap analysis regarding feature requirement with -Open Daylight Nitrogen 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 Nitrogen Official Release. +(VM) layer, and its gap analysis with Open Daylight Fluorine Official Release. -**Open Daylight Nitrogen Status** +**Open Daylight Fluorine Status** -In Open Daylight Nitrogen 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 Nitrogen|Notes | + |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. | @@ -43,11 +48,11 @@ identified by feature ``odl-netvirt-openstack`` is used. | (east-west) | | | +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ |IPv6 Router support in ODL: |**NO** |This feature is targeted for Flourine Release. | - | | |In ODL Nitrogen Release, RFE "IPv6 Inter-DC L3 North-South | + | | |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 | - | | |Nitrogen Release [2]_. Basically, existing IPv6 features were | + | | |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 | @@ -67,13 +72,24 @@ identified by feature ``odl-netvirt-openstack`` is used. +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ |Shared Networks support |Yes | | +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ - |IPv6 external L2 VLAN directly attached to a VM. |**ToDo** | | + |IPv6 external L2 VLAN directly attached to a VM. |Yes |Targeted for Flourine Release | +--------------------------------------------------+-------------------------+--------------------------------------------------------------+ - |ODL on an IPv6 only Infrastructure. |**Work in Progress** |Deploying OpenStack with ODL on an IPv6 only infrastructure | + |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] http://docs.opendaylight.org/en/latest/submodules/netvirt/docs/specs/ipv6-interdc-l3vpn.html +.. [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-pike.rst b/docs/release/userguide/gap-os-rocky.rst index 7acefb0..550a918 100644 --- a/docs/release/userguide/gap-os-pike.rst +++ b/docs/release/userguide/gap-os-rocky.rst @@ -2,23 +2,23 @@ .. http://creativecommons.org/licenses/by/4.0 .. (c) Bin Hu (AT&T) and Sridhar Gaddam (RedHat) -===================================== -IPv6 Gap Analysis with OpenStack Pike -===================================== +====================================== +IPv6 Gap Analysis with OpenStack Rocky +====================================== This section provides users with IPv6 gap analysis regarding feature requirement with -OpenStack Neutron in Pike 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 Pike 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 **Pike** release and **Ocata** release. +between **Rocky** release and prior, e.g. **Queens**, **Pike** and **Ocata**, releases. .. table:: :class: longtable +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ - |Use Case / Requirement |Supported in Pike |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 **Pike** release and **Ocata** release. +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |IPv6 Support in "Allowed Address Pairs" Extension |Yes | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ - |Support for IPv6 Prefix Delegation. |Yes |Partial support in Pike | + |Support for IPv6 Prefix Delegation. |Yes |Partial support in Rocky | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ - |Distributed Virtual Routing (DVR) support for IPv6 |**No** |In Pike 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 e8e7a44..30869aa 100644 --- a/docs/release/userguide/index.rst +++ b/docs/release/userguide/index.rst @@ -5,18 +5,22 @@ .. (c) Bin Hu (AT&T) and Sridhar Gaddam (RedHat) ==================================== -Using IPv6 Feature of Fraser Release +Using IPv6 Feature of Hunter Release ==================================== :Abstract: This section provides the users with: -* Gap Analysis regarding IPv6 feature requirements with OpenStack Pike +* Gap Analysis regarding IPv6 feature requirements with OpenStack Rocky + Official Release +* Gap Analysis regarding IPv6 feature requirements with Open Daylight Fluorine Official Release -* Gap Analysis regarding IPv6 feature requirements with Open Daylight Nitrogen - 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 @@ -24,15 +28,21 @@ 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. +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 Pike Release -<http://docs.openstack.org/neutron/pike/admin/config-ipv6.html>`_. +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-pike.rst - ./gap-odl-nitrogen.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 |
