ipv6 gua assignment

IPv6 Global Unicast Address Assignments

STP Operations

Troubleshooting Scenarios

Troubleshooting Methodologies

GUA and LLA Static Configuration

This topic explain how to Configure static global unicast and link-local IPv6 network addresses. Start learning CCNA 200-301 for free right now!!

Note : Welcome: This topic is part of Chapter 12 of the Cisco CCNA 1 course, for a better follow up of the course you can go to the CCNA 1 section to guide you through an order.

Table of Contents

Static GUA Configuration on a Router

As you learned in the previous topic, IPv6 GUAs are the same as public IPv4 addresses. They are globally unique and routable on the IPv6 internet. An IPv6 LLA lets two IPv6-enabled devices communicate with each other on the same link (subnet). It is easy to statically configure IPv6 GUAs and LLAs on routers to help you create an IPv6 network. This topic teaches you how to do just that!

Most IPv6 configuration and verification commands in the Cisco IOS are similar to their IPv4 counterparts. In many cases, the only difference is the use of  ipv6  in place of  ip  within the commands.

For example, the Cisco IOS command to configure an IPv4 address on an interface is  ip address   ip-address subnet-mask.  In contrast, the command to configure an IPv6 GUA on an interface is  ipv6 address   ipv6-address/prefix-length.

Notice that there is no space between  ipv6-address  and  prefix-length.

The example configuration uses the topology shown in the figure and these IPv6 subnets:

• 2001:db8:acad:1:/64
• 2001:db8:acad:2:/64
• 2001:db8:acad:3:/64

Example Topology

The example shows the commands required to configure the IPv6 GUA on GigabitEthernet 0/0/0, GigabitEthernet 0/0/1, and the Serial 0/1/0 interface of R1.

IPv6 GUA Configuration on Router R1

Static gua configuration on a windows host.

Manually configuring the IPv6 address on a host is similar to configuring an IPv4 address.

As shown in the figure, the default gateway address configured for PC1 is 2001:db8:acad:1::1. This is the GUA of the R1 GigabitEthernet interface on the same network. Alternatively, the default gateway address can be configured to match the LLA of the GigabitEthernet interface. Using the LLA of the router as the default gateway address is considered best practice. Either configuration will work.

Just as with IPv4, configuring static addresses on clients does not scale to larger environments. For this reason, most network administrators in an IPv6 network will enable dynamic assignment of IPv6 addresses.

There are two ways in which a device can obtain an IPv6 GUA automatically:

• Stateless Address Autoconfiguration (SLAAC)
• Stateful DHCPv6

SLAAC and DHCPv6 are covered in the next topic.

Note : When DHCPv6 or SLAAC is used, the LLA of the router will automatically be specified as the default gateway address.

Static Configuration of a Link-Local Unicast Address

Configuring the LLA manually lets you create an address that is recognizable and easier to remember. Typically, it is only necessary to create recognizable LLAs on routers. This is beneficial because router LLAs are used as default gateway addresses and in routing advertisement messages.

LLAs can be configured manually using the  ipv6 address   ipv6-link-local-address   link-local  command. When an address begins with this hextet within the range of fe80 to febf, the  link-local  parameter must follow the address.

The figure shows an example topology with LLAs on each interface.

Example Topology with LLAs

The example shows the configuration of an LLA on router R1.

Statically configured LLAs are used to make them more easily recognizable as belonging to router R1. In this example, all the interfaces of router R1 have been configured with an LLA that begins with  fe80::1: n  and a unique right-most digit “n”. The “ 1 ” represents router R1.

Following the same syntax as router R1, if the topology included router R2, it would have its three interfaces configured with the LLAs fe80::2:1, fe80::2:2, and fe80::2:3.

Note : The exact same LLA could be configured on each link as long as it is unique on that link. This is because LLAs only have to be unique on that link. However, common practice is to create a different LLA on each interface of the router to make it easy to identify the router and the specific interface.

Assign IPv6 GUAs and LLAs to the specified interfaces on router R1.

Configure and activate IPv6 on the Gigabit Ethernet 0/0/0 interface with the following addresses:

Use g0/0/0 as the interface name LLA – fe80::1:1 GUA – 2001:db8:acad:1::1/64 Activate the interface Exit interface configuration mode

Configure and activate IPv6 on the Gigabit Ethernet 0/0/1 interface with the following addresses:

Use g0/0/1 as the interface name LLA – fe80::2:1 GUA – 2001:db8:acad:2::1/64 Activate the interface Exit interface configuration mode

Configure and activate IPv6 on the serial 0/1/0 interface with the following addresses:

Use s0/1/0 as the interface name GUA – 2001:db8:acad:3::1/64 LLA – fe80::1:3 Activate the interface Exit interface configuration mode

You successfully configured IPv6 GUAs on the interfaces of router R1.

Glossary : If you have doubts about any special term, you can consult this computer network dictionary .

Ready to go! Keep visiting our networking course blog, give Like to our fanpage ; and you will find more tools and concepts that will make you a networking professional.

Privacy Overview

Automatic GUA IPv6 address for Wireguard client

Just a little guide, way to automatically assign GUA IPv6 addresses to road warrior Wireguard clients.

What you need: OpenWRT router ISP that gives you more than a single /64 GUA IPv6 subnet.

What you get: Remote Wireguard clients will get an automatic assignment of GUA IPv6 address. No need to adjust Wireguard or OpenWRT configuration if ISP changes your IPv6 prefix. Privacy IPv6 address for some clients.

Some technical details and caveats: GUA IPv6 will get assigned using using SLAAC, so you’ll need a separate /64 network and a separate interface for every Wireguard client in order for multicast to work. Basically a P2P link for every Wireguard device. Adjust ip6hint: unique for every Wireguard client and according to the size of IPv6 prefix you get from your ISP. IPv4 has to be static, DHCP doesn’t work over L3 tunnels like Wireguard, not a big deal since we are behind NAT in 99% of cases anyway. Some Android clients assign random privacy IPv6, other won’t and will use LL address device identification part. Android doesn’t seem to get DNS from RDNSS, so need so specify it like DNS=fe80::1. Systemd-networkd on Linux gets it just fine. No idea if it works for Windows, macOS, iOS etc. clients, don’t care a bit. Feel free to test yourself.

OpenWRT configuration: /etc/config/network

/etc/config/firewall

/etc/config/dhcp

Client Wireguard configuration for Android

Client Wireguard configuration for Linux systemd-networkd /etc/systemd/network/myserver.netdev

/etc/systemd/network/myserver.network

Follow up, recent version of systemd-network require both IPv6LL adress and MULTICAST flag to be set on Wireguard interface in order to receive IPv6 route advertisements.

This section describes the following items:

• How to enable dual-stack (IPv4 and IPv6 enabled) instances.
• How those instances receive an IPv6 address.
• How those instances communicate across a router to other subnets or the internet.
• How those instances interact with other OpenStack services.

Enabling a dual-stack network in OpenStack Networking simply requires creating a subnet with the ip_version field set to 6 , then the IPv6 attributes ( ipv6_ra_mode and ipv6_address_mode ) set. The ipv6_ra_mode and ipv6_address_mode will be described in detail in the next section. Finally, the subnets cidr needs to be provided.

This section does not include the following items:

• Single stack IPv6 project networking
• OpenStack control communication between servers and services over an IPv6 network.
• Connection to the OpenStack APIs via an IPv6 transport network
• IPv6 multicast
• IPv6 support in conjunction with any out of tree routers, switches, services or agents whether in physical or virtual form factors.

Neutron subnets and the IPv6 API attributes ¶

As of Juno, the OpenStack Networking service (neutron) provides two new attributes to the subnet object, which allows users of the API to configure IPv6 subnets.

There are two IPv6 attributes:

• ipv6_ra_mode
• ipv6_address_mode

These attributes can be set to the following values:

• dhcpv6-stateful
• dhcpv6-stateless

The attributes can also be left unset.

IPv6 addressing ¶

The ipv6_address_mode attribute is used to control how addressing is handled by OpenStack. There are a number of different ways that guest instances can obtain an IPv6 address, and this attribute exposes these choices to users of the Networking API.

Router advertisements ¶

The ipv6_ra_mode attribute is used to control router advertisements for a subnet.

The IPv6 Protocol uses Internet Control Message Protocol packets (ICMPv6) as a way to distribute information about networking. ICMPv6 packets with the type flag set to 134 are called “Router Advertisement” packets, which contain information about the router and the route that can be used by guest instances to send network traffic.

The ipv6_ra_mode is used to specify if the Networking service should generate Router Advertisement packets for a subnet.

ipv6_ra_mode and ipv6_address_mode combinations ¶

Project network considerations ¶, dataplane ¶.

Both the Linux bridge and the Open vSwitch dataplane modules support forwarding IPv6 packets amongst the guests and router ports. Similar to IPv4, there is no special configuration or setup required to enable the dataplane to properly forward packets from the source to the destination using IPv6. Note that these dataplanes will forward Link-local Address (LLA) packets between hosts on the same network just fine without any participation or setup by OpenStack components after the ports are all connected and MAC addresses learned.

Addresses for subnets ¶

There are three methods currently implemented for a subnet to get its cidr in OpenStack:

• Direct assignment during subnet creation via command line or Horizon
• Referencing a subnet pool during subnet creation
• Using a Prefix Delegation (PD) client to request a prefix for a subnet from a PD server

In the future, additional techniques could be used to allocate subnets to projects, for example, use of an external IPAM module.

Address modes for ports ¶

An external DHCPv6 server in theory could override the full address OpenStack assigns based on the EUI-64 address, but that would not be wise as it would not be consistent through the system.

IPv6 supports three different addressing schemes for address configuration and for providing optional network information.

OpenStack can be setup such that OpenStack Networking directly provides RA, DHCP relay and DHCPv6 address and optional information for their networks or this can be delegated to external routers and services based on the drivers that are in use. There are two neutron subnet attributes - ipv6_ra_mode and ipv6_address_mode – that determine how IPv6 addressing and network information is provided to project instances:

• ipv6_ra_mode : Determines who sends RA.
• ipv6_address_mode : Determines how instances obtain IPv6 address, default gateway, or optional information.

For the above two attributes to be effective, enable_dhcp of the subnet object must be set to True.

Using SLAAC for addressing ¶

When using SLAAC, the currently supported combinations for ipv6_ra_mode and ipv6_address_mode are as follows.

Setting ipv6_ra_mode to slaac will result in OpenStack Networking routers being configured to send RA packets, when they are created. This results in the following values set for the address configuration flags in the RA messages:

• Auto Configuration Flag = 1
• Managed Configuration Flag = 0
• Other Configuration Flag = 0

New or existing neutron networks that contain a SLAAC enabled IPv6 subnet will result in all neutron ports attached to the network receiving IPv6 addresses. This is because when RA broadcast messages are sent out on a neutron network, they are received by all IPv6 capable ports on the network, and each port will then configure an IPv6 address based on the information contained in the RA packet. In some cases, an IPv6 SLAAC address will be added to a port, in addition to other IPv4 and IPv6 addresses that the port already has been assigned.

For DHCPv6, the currently supported combinations are as follows:

Setting DHCPv6-stateless for ipv6_ra_mode configures the neutron router with radvd agent to send RAs. The list below captures the values set for the address configuration flags in the RA packet in this scenario. Similarly, setting DHCPv6-stateless for ipv6_address_mode configures neutron DHCP implementation to provide the additional network information.

• Other Configuration Flag = 1

Setting DHCPv6-stateful for ipv6_ra_mode configures the neutron router with radvd agent to send RAs. The list below captures the values set for the address configuration flags in the RA packet in this scenario. Similarly, setting DHCPv6-stateful for ipv6_address_mode configures neutron DHCP implementation to provide addresses and additional network information through DHCPv6.

• Auto Configuration Flag = 0
• Managed Configuration Flag = 1

Router support ¶

The behavior of the neutron router for IPv6 is different than for IPv4 in a few ways.

Internal router ports, that act as default gateway ports for a network, will share a common port for all IPv6 subnets associated with the network. This implies that there will be an IPv6 internal router interface with multiple IPv6 addresses from each of the IPv6 subnets associated with the network and a separate IPv4 internal router interface for the IPv4 subnet. On the other hand, external router ports are allowed to have a dual-stack configuration with both an IPv4 and an IPv6 address assigned to them.

Neutron project networks that are assigned Global Unicast Address (GUA) prefixes and addresses don’t require NAT on the neutron router external gateway port to access the outside world. As a consequence of the lack of NAT the external router port doesn’t require a GUA to send and receive to the external networks. This implies a GUA IPv6 subnet prefix is not necessarily needed for the neutron external network. By default, a IPv6 LLA associated with the external gateway port can be used for routing purposes. To handle this scenario, the implementation of router-gateway-set API in neutron has been modified so that an IPv6 subnet is not required for the external network that is associated with the neutron router. The LLA address of the upstream router can be learned in two ways.

• In the absence of an upstream RA support, ipv6_gateway flag can be set with the external router gateway LLA in the neutron L3 agent configuration file. This also requires that no subnet is associated with that port.
• The upstream router can send an RA and the neutron router will automatically learn the next-hop LLA, provided again that no subnet is assigned and the ipv6_gateway flag is not set.

Effectively the ipv6_gateway flag takes precedence over an RA that is received from the upstream router. If it is desired to use a GUA next hop that is accomplished by allocating a subnet to the external router port and assigning the upstream routers GUA address as the gateway for the subnet.

It should be possible for projects to communicate with each other on an isolated network (a network without a router port) using LLA with little to no participation on the part of OpenStack. The authors of this section have not proven that to be true for all scenarios.

When using the neutron L3 agent in a configuration where it is auto-configuring an IPv6 address via SLAAC, and the agent is learning its default IPv6 route from the ICMPv6 Router Advertisement, it may be necessary to set the net.ipv6.conf.<physical_interface>.accept_ra sysctl to the value 2 in order for routing to function correctly. For a more detailed description, please see the bug .

Neutron’s Distributed Router feature and IPv6 ¶

IPv6 does work when the Distributed Virtual Router functionality is enabled, but all ingress/egress traffic is via the centralized router (hence, not distributed). More work is required to fully enable this functionality.

Advanced services ¶

VPNaaS supports IPv6, but support in Kilo and prior releases will have some bugs that may limit how it can be used. More thorough and complete testing and bug fixing is being done as part of the Liberty release. IPv6-based VPN-as-a-Service is configured similar to the IPv4 configuration. Either or both the peer_address and the peer_cidr can specified as an IPv6 address. The choice of addressing modes and router modes described above should not impact support.

FWaaS allows creation of IPv6 based rules.

NAT & Floating IPs ¶

At the current time OpenStack Networking does not provide any facility to support any flavor of NAT with IPv6. Unlike IPv4 there is no current embedded support for floating IPs with IPv6. It is assumed that the IPv6 addressing amongst the projects is using GUAs with no overlap across the projects.

Security considerations ¶

Initially this is probably just stating the security group rules relative to IPv6 that are applied. Need some help for these

Configuring interfaces of the guest ¶

OpenStack currently doesn’t support the privacy extensions defined by RFC 4941. The interface identifier and DUID used must be directly derived from the MAC as described in RFC 2373. The compute hosts must not be setup to utilize the privacy extensions when generating their interface identifier.

There is no provisions for an IPv6-based metadata service similar to what is provided for IPv4. In the case of dual stacked guests though it is always possible to use the IPv4 metadata service instead.

Unlike IPv4 the MTU of a given network can be conveyed in the RA messages sent by the router as well as in the DHCP messages.

OpenStack control & management network considerations ¶

As of the Kilo release, considerable effort has gone in to ensuring the project network can handle dual stack IPv6 and IPv4 transport across the variety of configurations described above. OpenStack control network can be run in a dual stack configuration and OpenStack API endpoints can be accessed via an IPv6 network. At this time, Open vSwitch (OVS) tunnel types - STT, VXLAN, GRE, support both IPv4 and IPv6 endpoints.

Prefix delegation ¶

From the Liberty release onwards, OpenStack Networking supports IPv6 prefix delegation. This section describes the configuration and workflow steps necessary to use IPv6 prefix delegation to provide automatic allocation of subnet CIDRs. This allows you as the OpenStack administrator to rely on an external (to the OpenStack Networking service) DHCPv6 server to manage your project network prefixes.

Prefix delegation became available in the Liberty release, it is not available in the Kilo release. HA and DVR routers are not currently supported by this feature.

Configuring OpenStack Networking for prefix delegation ¶

To enable prefix delegation, edit the /etc/neutron/neutron.conf file.

If you are not using the default dibbler-based driver for prefix delegation, then you also need to set the driver in /etc/neutron/neutron.conf :

Drivers other than the default one may require extra configuration, please refer to Extra configuration

This tells OpenStack Networking to use the prefix delegation mechanism for subnet allocation when the user does not provide a CIDR or subnet pool id when creating a subnet.

Requirements ¶

To use this feature, you need a prefix delegation capable DHCPv6 server that is reachable from your OpenStack Networking node(s). This could be software running on the OpenStack Networking node(s) or elsewhere, or a physical router. For the purposes of this guide we are using the open-source DHCPv6 server, Dibbler. Dibbler is available in many Linux package managers, or from source at tomaszmrugalski/dibbler .

When using the reference implementation of the OpenStack Networking prefix delegation driver, Dibbler must also be installed on your OpenStack Networking node(s) to serve as a DHCPv6 client. Version 1.0.1 or higher is required.

This guide assumes that you are running a Dibbler server on the network node where the external network bridge exists. If you already have a prefix delegation capable DHCPv6 server in place, then you can skip the following section.

Configuring the Dibbler server ¶

After installing Dibbler, edit the /etc/dibbler/server.conf file:

The options used in the configuration file above are:

• script Points to a script to be run when a prefix is delegated or released. This is only needed if you want instances on your subnets to have external network access. More on this below.
• iface The name of the network interface on which to listen for prefix delegation messages.
• pd-pool The larger prefix from which you want your delegated prefixes to come. The example given is sufficient if you do not need external network access, otherwise a unique globally routable prefix is necessary.
• pd-length The length that delegated prefixes will be. This must be 64 to work with the current OpenStack Networking reference implementation.

To provide external network access to your instances, your Dibbler server also needs to create new routes for each delegated prefix. This is done using the script file named in the config file above. Edit the /var/lib/dibbler/pd-server.sh file:

The variables used in the script file above are:

• $PREFIX1 The prefix being added/deleted by the Dibbler server.
• $1 The operation being performed.
• $REMOTE_ADDR The IP address of the requesting Dibbler client.
• $IFACE The network interface upon which the request was received.

The above is all you need in this scenario, but more information on installing, configuring, and running Dibbler is available in the Dibbler user guide, at Dibbler – a portable DHCPv6 .

To start your Dibbler server, run:

Or to run in headless mode:

When using DevStack, it is important to start your server after the stack.sh script has finished to ensure that the required network interfaces have been created.

User workflow ¶

First, create a network and IPv6 subnet:

The subnet is initially created with a temporary CIDR before one can be assigned by prefix delegation. Any number of subnets with this temporary CIDR can exist without raising an overlap error. The subnetpool_id is automatically set to prefix_delegation .

To trigger the prefix delegation process, create a router interface between this subnet and a router with an active interface on the external network:

The prefix delegation mechanism then sends a request via the external network to your prefix delegation server, which replies with the delegated prefix. The subnet is then updated with the new prefix, including issuing new IP addresses to all ports:

If the prefix delegation server is configured to delegate globally routable prefixes and setup routes, then any instance with a port on this subnet should now have external network access.

Deleting the router interface causes the subnet to be reverted to the temporary CIDR, and all ports have their IPs updated. Prefix leases are released and renewed automatically as necessary.

References ¶

The following link provides a great step by step tutorial on setting up IPv6 with OpenStack: Tenant IPV6 deployment in OpenStack Kilo release .

Extra configuration ¶

Neutron dhcpv6_pd_agent ¶.

To enable the driver for the dhcpv6_pd_agent, set pd_dhcp_driver to this in /etc/neutron/neutron.conf :

To allow the neutron-pd-agent to communicate with prefix delegation servers, you must set which network interface to use for external communication. In DevStack the default for this is br-ex :

Once you have stacked run the command below to start the neutron-pd-agent:

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License . See all OpenStack Legal Documents .

• Install Guides
• User Guides
• Configuration Guides
• Operations and Administration Guides
• Contributor Guides
• Deutsch (German)
• Français (French)
• Bahasa Indonesia (Indonesian)
• Italiano (Italian)
• 日本語 (Japanese)
• 한국어 (Korean)
• Português (Portuguese)
• Türkçe (Türkiye)
• 简体中文 (Simplified Chinese)

neutron 12.1.2.dev242

• Installation Guide
• Introduction
• Configuration
• Deployment examples
• Miscellaneous
• Archived Contents
• Neutron Configuration Options
• Command-Line Interface Reference
• Neutron Feature Classification
• Contributor Guide

Page Contents

• IPv6 addressing
• Router advertisements
• ipv6_ra_mode and ipv6_address_mode combinations
• Addresses for subnets
• Address modes for ports
• Using SLAAC for addressing
• Neutron’s Distributed Router feature and IPv6
• NAT & Floating IPs
• Configuring interfaces of the guest
• OpenStack control & management network considerations
• Configuring OpenStack Networking for prefix delegation
• Requirements
• Configuring the Dibbler server
• User workflow
• Neutron dhcpv6_pd_agent