ipv6 dhcpv6 assignment

• Artificial Intelligence
• Generative AI
• Cloud Computing
• CPUs and Processors
• Data Center
• Edge Computing
• Enterprise Storage
• Virtualization
• Internet of Things
• Network Management Software
• Network Security
• Enterprise Buyer’s Guides
• United States
• Newsletters
• Foundry Careers
• Terms of Service
• Privacy Policy
• Cookie Policy
• Copyright Notice
• Member Preferences
• About AdChoices
• E-commerce Links
• Your California Privacy Rights

Our Network

• Computerworld

IPv6: How to configure static and DHCP IP addressing and deal with DNS

Ipv6 offers several ways that aren’t possible in ipv4 to assign ip addresses, and dns set-up has differences as well..

As IP technology has matured, the range of devices that the internet protocol supports goes well beyond computers to include cell phones, entertainment systems, and Internet of Things (IoT) devices, which created the need for more IP addresses and the development of IPv6 to provide them.

With more and more device types requiring network connectivity, the demand for addresses in an IPv4-based network is at a premium. It can provide somewhere south of 4,294,967,296 unique addresses. IPv6 , on the other hand, can yield roughly 3.4×10 38 , which should be ample for a very long time.

IPv6 also includes performance enhancements like refined multicasting, stateless address autoconfiguration (SLAAC), simplified headers to streamline router processing, and the option to allow larger packets. Security also gets a potential boost in IPv6 with IPSec, which was initially built for IPv6 and then retrofitted for IPv4.

Dealing with IPv6 includes familiarizing yourself with two important IP concepts: DHCP and DNS. Here are tips on both.

Key IPv6 addressing concepts

IPv6 addressing within a network has a few major differences from IPv4. With IPv4 certain address ranges are reserved for private networks (such as 10.0.0.0/8 or 192.168.0.0/16) and link-local addressing without dynamic host configuration protocol (DHCP) (169.254.0.0/16).

DHCP automatically assigns IP addresses and distributes other information to hosts on a network so they can communicate with other endpoints. At the same time, by assigning active IP addresses only to active devices, DHCP can reuse them to help conserve IPv4 addresses. IPv6 has similar concepts but refines each idea a little further.

Link-local addresses in IPv6 exist on each interface, regardless of whether the interface has an address assigned from DHCP or is configured using another method. Link-local IPv6 addresses have a prefix of fe80::/10 and a 64-bit suffix which can be computed and managed by the host itself without requiring additional networking components. IPv6 hosts can verify the uniqueness of their link-local addresses through a neighbor discovery process, which reaches out to the local network in order to verify that the address is not already in use.

Once a link-local address has been established, the IPv6 host attempts to determine if an IPv6-capable router is available through the use of a router solicitation message. If an IPv6 router is available it will respond with a router advertisement, which includes network configuration information such as a network prefix that is used for automatic address configuration using SLAAC or whether the host should obtain additional configuration information from a DHCPv6 server.

Configuring a Static IPv6 address in Windows

Typical to Windows, there are three ways to configure a static IPv6 address for a network adapter, all of which work in Windows 10 and in both Windows Server 2016 and 2019. The first way uses the classic Control Panel method as follows.

From the Control Panel, navigate to Network and Internet, Network and Sharing Center, and then choose the Change adapter settings link in the left panel. (You can shortcut all the clicking by searching for “View Network Connections” from the Start Menu or the Search bar).

Once you locate the network adapter you wish to configure, you can view the properties and locate the Internet Protocol Version 6 (TCP/IPv6) node and configure the properties for the IPv6 protocol. As with IPv4 you can set the adapter to obtain the IPv6 address automatically or configure your own IPv6 address, subnet, default gateway, and DNS server information. If you need to set multiple IPv6 addresses this can be accomplished by clicking the Advanced button.

The second method of setting a static IP address involves the more modern Settings application. In Settings go to Network & Internet and click the Properties button for the interface you wish to configure. Click the Edit button under IP settings, change the configuration type to Manual, enable IPv6, and populate your settings.

The third way is to use the Windows PowerShell command-line interface. In order to set a static IPv6 address using the New-NetIPAddress cmdlet you will need either the name or the numeric index of the adapter you wish to configure. Both of these values are available using the Get-NetAdapter cmdlet. From an administrative PowerShell prompt enter one of the following commands (on a single line) replacing the details as necessary for your environment:

Managing IPv6 Addressing for a Windows Network

Static IP addresses are generally OK to use when the device is hosting a critical network service that requires retaining a consistent network address, but for general use you’ll want to have a way to automate address configuration.

In an IPv4 network DHCP is the obvious answer for IP configuration and can also provide critical networking details such as the default gateway or DNS-server addresses through DHCP options. IPv6 offers three potential scenarios for managing addressing and network configuration.

SLAAC is a straightforward option assuming your router supports the appropriate router-advertisement messages. DHCP is certainly still in play to handle stateful addressing in the form of DHCPv6. You can also potentially have a hybrid scenario where your router handles addressing, and DHCPv6 simply provides the relevant network-configuration details.

In Windows Server 2016 and 2019, configuring DHCPv6 is extremely straightforward. If your router is configured to handle router advertisements and addressing through SLAAC you can simply manage the IPv6 server options to configure DNS servers or other options. If you prefer to roll with stateful addressing you can add one or more DHCPv6 scopes and configure a prefix, any exclusions, and lease durations. DHCPv6 scopes will maintain a list of leases and their expirations just as an IPv4 scope would, and they also provide an easy path for creating IPv6 reservations from existing leases.

Setting up DNS Name Resolution for IPv6

DNS is incredibly important in an IPv6 network, even moreso than in an IPv4 network because trying to configure connectivity and access resources using only IPv6 addresses is borderline insane. The biggest difference to note in regard to using DNS with IPv6 is that the IPv4 A records, which convert a fully qualified domain name (FQDN) to an IPv4 address, are replaced by AAAA (quad-A) records. All other record types such as CNAME, MX, NS, SOA, and the various DNSSEC-related record types simply reference the FQDN of the AAAA record. Reverse lookup zones, which are used to find a hostname from an IP address, are different in IPv6 simply because they are built on the IP address structure, but the process of creating and using these zones are functionally identical.

The DNS server role in Windows Server supports both IPv4 and IPv6 through a similar set of tools and processes. As with A records, AAAA records can either be created manually for critical systems or the dynamic update process can be leveraged to manage DNS records for the entire enterprise.

AAAA records can be manually created using the DNS console through the same process as A records: Right click the required DNS zone, select the New Host (A or AAAA) option, and populate the Host name and IP address. Dynamic updates are enabled through the DNS console, but most of the work is done by DHCP; the update process is configured within the DHCP console and updates are performed by the DHCP client service on individual hosts. Dynamic updates can also be manually initiated from the command line using the ipconfig command with the /registerdns switch.

Related content

Regulators sound out users on cloud services competition concerns, backgrounding and foregrounding processes in the linux terminal, fcc proposes $6m fine for ai-generated robocall spoofing biden’s voice, ibm brings ai assistant to mainframe, promises linux version, newsletter promo module test.

Tim Ferrill is an IT professional and writer living in Southern California. He has covered Windows, Windows Phone, and Windows Server for several publications, including CITEworld and InfoWorld.

More from this author

Tips for building a home lab to prep for network certifications, certifications that can land you a job as a network-automation engineer, free training from 8 top vendors to advance your it career, surviving a mastodon stampede, most popular authors.

Show me more

Open ran and hashicorp are making us rethink openness.

Complexity snarls multicloud network management

2024 network outage report and internet health check

Has the hype around ‘Internet of Things’ paid off? | Ep. 145

Episode 1: Understanding Cisco’s Converged SDN Transport

Episode 2: Pluggable Optics and the Internet for the Future

Has the hype around ‘Internet of Things’ paid off?

Are unused IPv4 addresses a secret gold mine?

Preparing for a 6G wireless world: Exciting changes coming to the wireless industry

• school Campus Bookshelves
• menu_book Bookshelves
• perm_media Learning Objects
• login Login
• how_to_reg Request Instructor Account
• hub Instructor Commons

Margin Size

• Download Page (PDF)
• Download Full Book (PDF)
• Periodic Table
• Physics Constants
• Scientific Calculator
• Reference & Cite
• Tools expand_more
• Readability

selected template will load here

This action is not available.

8.8: IPv6 Host Address Assignment

• Last updated
• Save as PDF
• Page ID 11173

• Peter Lars Dordal
• Loyola University of Chicago

\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

\( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

\( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

\( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

\( \newcommand{\Span}{\mathrm{span}}\)

\( \newcommand{\id}{\mathrm{id}}\)

\( \newcommand{\kernel}{\mathrm{null}\,}\)

\( \newcommand{\range}{\mathrm{range}\,}\)

\( \newcommand{\RealPart}{\mathrm{Re}}\)

\( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

\( \newcommand{\Argument}{\mathrm{Arg}}\)

\( \newcommand{\norm}[1]{\| #1 \|}\)

\( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

\( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

\( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

\( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

\( \newcommand{\vectorC}[1]{\textbf{#1}} \)

\( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

\( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

\( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

IPv6 provides two competing ways for hosts to obtain their full IP addresses. One is DHCPv6 , based on IPv4’s DHCP ( 7.10 Dynamic Host Configuration Protocol (DHCP) ), in which the entire address is handed out by a DHCPv6 server. The other is StateLess Address AutoConfiguration , or SLAAC, in which the interface-identifier part of the address is generated locally, and the network prefix is obtained via prefix discovery. The original idea behind SLAAC was to support complete plug-and-play network setup: hosts on an isolated LAN could talk to one another out of the box, and if a router was introduced connecting the LAN to the Internet, then hosts would be able to determine unique, routable addresses from information available from the router.

In the early days of IPv6 development, in fact, DHCPv6 may have been intended only for address assignments to routers and servers, with SLAAC meant for “ordinary” hosts. In that era, it was still common for IPv4 addresses to be assigned “statically”, via per-host configuration files. RFC 4862 [ https://tools.ietf.org/html/rfc4862.html] states that SLAAC is to be used when “a site is not particularly concerned with the exact addresses hosts use, so long as they are unique and properly routable.”

SLAAC and DHCPv6 evolved to some degree in parallel. While SLAAC solves the autoconfiguration problem quite neatly, at this point DHCPv6 solves it just as effectively, and provides for greater administrative control. For this reason, SLAAC may end up less widely deployed. On the other hand, SLAAC gives hosts greater control over their IPv6 addresses, and so may end up offering hosts a greater degree of privacy by allowing endpoint management of the use of private and temporary addresses (below).

When a host first begins the Neighbor Discovery process, it receives a Router Advertisement packet. In this packet are two special bits: the M (managed) bit and the O (other configuration) bit. The M bit is set to indicate that DHCPv6 is available on the network for address assignment. The O bit is set to indicate that DHCPv6 is able to provide additional configuration information ( eg the name of the DNS server) to hosts that are using SLAAC to obtain their addresses. In addition, each individual prefix in the RA packet has an A bit, which when set indicates that the associated prefix may be used with SLAAC.

8.7.1 Duplicate Address Detection

Whenever an IPv6 host obtains a unicast address – a link-local address, an address created via SLAAC, an address received via DHCPv6 or a manually configured address – it goes through a duplicate-address detection (DAD) process. The host sends one or more Neighbor Solicitation messages (that is, like an ARP query), as in 8.6 Neighbor Discovery , asking if any other host has this address. If anyone answers, then the address is a duplicate. As with IPv4 ACD ( 7.9.1 ARP Finer Points ), but not as with the original IPv4 self-ARP, the source-IP-address field of this NS message is set to a special “unspecified” value; this allows other hosts to recognize it as a DAD query.

Because this NS process may take some time, and because addresses are in fact almost always unique, RFC 4429 [ https://tools.ietf.org/html/rfc4429.html] defines an optimistic DAD mechanism. This allows limited use of an address before the DAD process completes; in the meantime, the address is marked as “optimistic”.

Outside the optimistic-DAD interval, a host is not allowed to use an IPv6 address if the DAD process has failed. RFC 4862 [ https://tools.ietf.org/html/rfc4862.html] in fact goes further: if a host with an established address receives a DAD query for that address, indicating that some other host wants to use that address, then the original host should discontinue use of the address.

If the DAD process fails for an address based on an EUI-64 identifier, then some other node has the same Ethernet address and you have bigger problems than just finding a working IPv6 address. If the DAD process fails for an address constructed with the RFC 7217 [ https://tools.ietf.org/html/rfc7217.html] mechanism, 8.2.1 Interface identifiers , the host is able to generate a new interface identifier and try again. A counter for the number of DAD attempts is included in the hash that calculates the interface identifier; incrementing this counter results in an entirely new identifier.

While DAD works quite well on Ethernet-like networks with true LAN-layer multicast, it may be inefficient on, say, MANETs ( 3.7.8 MANETs ), as distant hosts may receive the DAD Neighbor Solicitation message only after some delay, or even not at all. Work continues on the development of improvements to DAD for such networks.

8.7.2 Stateless Autoconfiguration (SLAAC)

To obtain an address via SLAAC, defined in RFC 4862 [ https://tools.ietf.org/html/rfc4862.html] , the first step for a host is to generate its link-local address (above, 8.2.2 Link-local addresses ), appending the standard 64-bit link-local prefix fe80::/64 to its interface identifier ( 8.2.1 Interface identifiers ). The latter is likely derived from the host’s LAN address using either EUI-64 or the RFC 7217 [ https://tools.ietf.org/html/rfc7217.html] mechanism; the important point is that it is available without network involvement.

The host must then ensure that its newly configured link-local address is in fact unique; it uses DAD (above) to verify this. Assuming no duplicate is found, then at this point the host can talk to any other hosts on the same LAN, eg to figure out where the printers are.

The next step is to see if there is a router available. The host may send a Router Solicitation (RS) message to the all-routers multicast address. A router – if present – should answer with a Router Advertisement (RA) message that also contains a Prefix Information option; that is, a list of IPv6 network-address prefixes ( 8.6.2 Prefix Discovery ).

As mentioned earlier, the RA message will mark with a flag those prefixes eligible for use with SLAAC; if no prefixes are so marked, then SLAAC should not be used. All prefixes will also be marked with a lifetime, indicating how long the host may continue to use the prefix. Once the prefix expires, the host must obtain a new one via a new RA message.

The host chooses an appropriate prefix, stores the prefix-lifetime information, and appends the prefix to the front of its interface identifier to create what should now be a routable address. The address so formed must now be verified through the DAD mechanism above.

In the era of EUI-64 interface identifiers, it would in principle have been possible for the receiver of a packet to extract the sender’s LAN address from the interface-identifier portion of the sender’s SLAAC-generated IPv6 address. This in turn would allow bypassing the Neighbor Solicitation process to look up the sender’s LAN address. This was never actually permitted, however, even before the privacy options below, as there is no way to be certain that a received address was in fact generated via SLAAC. With RFC 7217 [ https://tools.ietf.org/html/rfc7217.html] -based interface identifiers, LAN-address extraction is no longer even potentially an option.

A host using SLAAC may receive multiple network prefixes, and thus generate for itself multiple addresses. RFC 6724 [ https://tools.ietf.org/html/rfc6724.html] defines a process for a host to determine, when it wishes to connect to destination address D, which of its own multiple addresses to use. For example, if D is a unique-local address, not globally visible, then the host will likely want to choose a source address that is also unique-local. RFC 6724 [ https://tools.ietf.org/html/rfc6724.html] also includes mechanisms to allow a host with a permanent public address (possibly corresponding to a DNS entry, but just as possibly formed directly from an interface identifier) to prefer alternative “temporary” or “privacy” addresses for outbound connections. Finally, RFC 6724 [ https://tools.ietf.org/html/rfc6724.html] also defines the sorting order for multiple addresses representing the same destination; see 8.11 Using IPv6 and IPv4 Together .

At the end of the SLAAC process, the host knows its IPv6 address (or set of addresses) and its default router. In IPv4, these would have been learned through DHCP along with the identity of the host’s DNS server; one concern with SLAAC is that it originally did not provide a way for a host to find its DNS server. One strategy is to fall back on DHCPv6 for this. However, RFC 6106 [ https://tools.ietf.org/html/rfc6106.html] now defines a process by which IPv6 routers can include DNS-server information in the RA packets they send to hosts as part of the SLAAC process; this completes the final step of autoconfiguration.

How to get DNS names for SLAAC-configured IPv6 hosts into the DNS servers is an entirely separate issue. One approach is simply not to give DNS names to such hosts. In the NAT-router model for IPv4 autoconfiguration, hosts on the inward side of the NAT router similarly do not have DNS names (although they are also not reachable directly, while SLAAC IPv6 hosts would be reachable). If DNS names are needed for hosts, then a site might choose DHCPv6 for address assignment instead of SLAAC. It is also possible to figure out the addresses SLAAC would use (by identifying the host-identifier bits) and then creating DNS entries for these hosts. Finally, hosts can also use Dynamic DNS ( RFC 2136 [ https://tools.ietf.org/html/rfc2136.html] ) to update their own DNS records.

8.7.2.1 SLAAC privacy

A portable host that always uses SLAAC as it moves from network to network and always bases its SLAAC addresses on the EUI-64 interface identifier (or on any other static interface identifier) will be easy to track: its interface identifier will never change. This is one reason why the obfuscation mechanism of RFC 7217 [ https://tools.ietf.org/html/rfc7217.html] interface identifiers ( 8.2.1 Interface identifiers ) includes the network prefix in the hash: connecting to a new network will then result in a new interface identifier.

Well before RFC 7217 [ https://tools.ietf.org/html/rfc7217.html] , however, RFC 4941 [ https://tools.ietf.org/html/rfc4941.html] introduced a set of privacy extensions to SLAAC: optional mechanisms for the generation of alternative interface identifiers, based as with RFC 7217 on pseudorandom generation using the original LAN-address-based interface identifier as a “seed” value.

RFC 4941 goes further, however, in that it supports regular changes to the interface identifier, to increase the difficulty of tracking a host over time even if it does not change its network prefix. One first selects a 128-bit secure-hash function F(), eg MD5 ( 22.6 Secure Hashes ). New temporary interface IDs (IIDs) can then be calculated as follows

\[(IID_{new},seed_{new}) = F(seed_{old}, IID_{old})\]

where the left-hand pair represents the two 64-bit halves of the 128-bit return value of F() and the arguments to F() are concatenated together. (The seventh bit of IID new must also be set to 0; cf 8.2.1 Interface identifiers where this bit is set to 1.) This process is privacy-safe even if the initial IID is based on EUI-64.

The probability of two hosts accidentally choosing the same interface identifier in this manner is vanishingly small; the Neighbor Solicitation mechanism with DAD must, however, still be used to verify that the address is in fact unique within the host’s LAN.

The privacy addresses above are to be used only for connections initiated by the client; to the extent that the host accepts incoming connections and so needs a “fixed” IPv6 address, the address based on the original EUI-64/RFC-7217 interface identifier should still be available. As a result, the RFC 7217 mechanism is still important for privacy even if the RFC 4941 mechanism is fully operational.

RFC 4941 stated that privacy addresses were to be disabled by default, largely because of concerns about frequently changing IP addresses. These concerns have abated with experience and so privacy addresses are often now automatically enabled. Typical address lifetimes range from a few hours to 24 hours. Once an address has “expired” it generally remains available but deprecated for a few temporary-address cycles longer.

DHCPv6 also provides an option for temporary address assignments, again to improve privacy, but one of the potential advantages of SLAAC is that this process is entirely under the control of the end system.

Regularly ( eg every few hours, or less) changing the host portion of an IPv6 address should make external tracking of a host more difficult, at least if tracking via web-browser cookies is also somehow prevented. However, for a residential “site” with only a handful of hosts, a considerable degree of tracking may be obtained simply by observing the common 64-bit prefix.

For a general discussion of privacy issues related to IPv6 addressing, see RFC 7721 [ https://tools.ietf.org/html/rfc7721.html] .

8.7.3 DHCPv6

The job of a DHCPv6 server is to tell an inquiring host its network prefix(es) and also supply a 64-bit host-identifier, very similar to an IPv4 DHCPv4 server. Hosts begin the process by sending a DHCPv6 request to the All_DHCP_Relay_Agents_and_Servers multicast IPv6 address ff02::1:2 (versus the broadcast address for IPv4). As with DHCPv4, the job of a relay agent is to tag a DHCPv6 request with the correct current subnet, and then to forward it to the actual DCHPv6 server. This allows the DHCPv6 server to be on a different subnet from the requester. Note that the use of multicast does nothing to diminish the need for relay agents. In fact, the All_DHCP_Relay_Agents_and_Servers multicast address scope is limited to the current LAN; relay agents then forward to the actual DHCPv6 server using the site -scoped address All_DHCP_Servers.

Hosts using SLAAC to obtain their address can still use a special Information-Request form of DHCPv6 to obtain their DNS server and any other “static” DHCPv6 information.

Clients may ask for temporary addresses. These are identified as such in the “Identity Association” field of the DHCPv6 request. They are handled much like “permanent” address requests, except that the client may ask for a new temporary address only a short time later. When the client does so, a different temporary address will be returned; a repeated request for a permanent address, on the other hand, would usually return the same address as before.

When the DHCPv6 server returns a temporary address, it may of course keep a log of this address. The absence of such a log is one reason SLAAC may provide a greater degree of privacy. SLAAC also places control of the cryptographic mechanisms for temporary-address creation in the hands of the end user.

A DHCPv6 response contains a list (perhaps of length 1) of IPv6 addresses. Each separate address has an expiration date. The client must send a new request before the expiration of any address it is actually using.

In DHCPv4, the host portion of addresses typically comes from “address pools” representing small ranges of integers such as 64-254; these values are generally allocated consecutively. A DHCPv6 server, on the other hand, should take advantage of the enormous range (2 64 ) of possible host portions by allocating values more sparsely, through the use of pseudorandomness. This is to make it very difficult for an outsider who knows one of a site’s host addresses to guess the addresses of other hosts, cf 8.2.1 Interface identifiers .

The Internet Draft draft-ietf-dhc-stable-privacy-addresses [tools.ietf.org/id/draft-ietf...resses-00.txt] proposes the following mechanism by which a DHCPv6 server may generate the interface-identifier bits for the addresses it hands out; F() is a secure-hash function and its arguments are concatenated together:

\[F(prefix, client_DUID, IAID, DAD_counter, secret_key)\]

The prefix, DAD_counter and secret_key arguments are as in 8.7.2.1 SLAAC privacy . The client_DUID is the string by which the client identifies itself to the DHCPv6 server; it may be based on the Ethernet address though other options are possible. The IAID, or Identity Association identifier, is a client-provided name for this request; different names are used when requesting temporary versus permanent addresses.

Some older DHCPv6 servers may still allocate interface identifiers in serial order; such obsolete servers might make the SLAAC approach more attractive.

PacketMania

Technology | Knowledge | Sharing

IPv6 Dynamic Address Allocation Mechanism Illustrated

IPv6 supports multiple addresses, making address assignments more flexible and convenient. Unlike IPv4, which relied solely on the DHCP protocol for address assignment, IPv6 incorporates a native Stateless Address AutoConfiguration SLAAC) protocol. SLAAC can either work alone to provide IPv6 addresses to hosts, or it can work with DHCPv6 to generate new assignment schemes. Here is a comprehensive analysis of the dynamic address allocation mechanism for IPv6.

Who the hell knew how much address space we needed? — Vint Cerf (American Internet pioneer and one of "the fathers of the Internet")

IPv6 Address Overview

Address formats.

The interface identifier can be generated in several ways:

• Static manual setting
• Converted from the interface's MAC address using the modified EUI-64 format
• Obtained from a DHCPv6 server
• Automatically established randomly or cryptographically

IETF recommends a canonical textual representation format for ease of writing. It includes leading zeros suppression and compression of consecutive all-zero fields. With the network prefix length at the end, the above address can be shortened to 2001:db8:130f :: 7000: 0 :140b/ 64 .

Address Types

RFC 4291 defines three types of addresses:

• Unicast: A network address corresponds to a single network node, point-to-point connection.
• Anycast: The target address corresponds to a group of receiving nodes, but only the "nearest" one receives.
• Multicast: The target address corresponds to a group of nodes that can receive replicated messages.

Note that there are no broadcast addresses in IPv6, their function being superseded by multicast addresses. Anycast addresses are syntactically indistinguishable from unicast addresses and have very limited applications. A typical application for anycast is to set up a DNS root server to allow hosts to look up domain names in close proximity. For unicast and multicast addresses, they can be identified by different network prefixes:

• All Nodes Addresses on the local link — ff02::1
• All Routers Addresses on the local link — ff02::2
• Solicited-Node Address on local link — ff02::1:ffxx:xxxx

Dynamic Allocation Schemes

Ndp protocol.

IPv6 dynamic address assignment depends on Neighbor Discovery Protocol (NDP). NDP acts at the data link layer and is responsible for discovering other nodes and corresponding IPv6 addresses on the link and determining available routes and maintaining information reachability to other active nodes. It provides the IPv6 network with the equivalent of the Address Resolution Protocol (ARP) and ICMP router discovery and redirection protocols in IPv4 networks. However, NDP adds many improvements and new features. NDP defines five ICMPv6 message types:

• Router Solicitation (RS)
• Router Advertisement (RA)
• Neighbor Solicitation (NS)
• Neighbor Advertisement (NA)

The first two message types here, RS and RA, are the keys to implementing dynamic IPv6 address assignment. The host sends an RS message to the multicast address ff02::2 of all routers in the local network segment to request routing information. When the router receives the RS from the network node, it sends an immediate RA in response. The message format of the RA is as follows

It defines two special bits, M and O, with the following meaning:

• M — "Managed address configuration" flag, set to 1 when the address is obtained from DHCPv6.
• O — "Other configuration" flag, set to 1 to indicate that other configuration information is available via DHCPv6

The RA message ends with the Options section, which originally had three possible options: Source Link-Layer Address, MTU, and Prefix Information. Later, RFC 8106 (which replaced RFC 6106) added the Recursive DNS Server (RDNSS) and DNS Search List (DNSSL) options. The Prefix Information option directly provide hosts with on-link prefixes and prefixes for Address Autoconfiguration, and it has the following format

Here the Prefix Length and the Prefix jointly determine the network prefix of the IPv6 address. In addition, the Prefix Information option also defines two special bits, L and A:

• L — on-link flag. When set, indicates that this prefix can be used for on-link determination.
• A — autonomous address-configuration flag. When set, indicates that this prefix can be used for SLAAC.

Similar to the IPv4 subnet mask feature, the purpose of the "on-link" determination is to allow the host to determine which networks an interface can access. By default, the host only considers the network where the link-local address is located as "on-link". If the "on-link" status of a destination address cannot be determined, the host forwards the IPv6 datagram to the default gateway (or default router) by default. When the host receives an RA message, if the "on-link" flag for a prefix information option is set to 1 and the Valid Lifetime is also a non-zero value, the host creates a new prefix network entry for it in the prefix list. All unexpired prefix network entries are "on-link".

Message Sequence

After understanding the NDP protocol and the information conveyed by the RA messages, let's see how they guide the network nodes to achieve dynamic address assignment.

Routers in the network periodically send RA messages to the multicast addresses (ff02::1) of all nodes in the local subnet. However, to avoid latency, the host sends one or more RS messages to all routers in the local subnet as soon as it has finished booting. The protocol requires the routers to respond to the RA messages within 0.5 seconds. Then, based on the values of the M/O/A bits in the received RA messages, the host decides how to dynamically configure the unique local and global unicast addresses of the interface and how to obtain other configuration information. With certain combinations of bit fetch values, the host needs to run DHCPv6 client software to connect to the server to obtain address assignment and/or other configuration information. The entire process is shown in the following message sequence diagram.

Note: Unlike the IPv4 DHCP protocol, DHCPv6 clients use UDP port 546 and servers use UDP port 547.

Next explain in detail three dynamic allocation schemes determined by the combination of the M/O/A-bit values:

SLAAC + Stateless DHCPv6

Stateful dhcpv6.

SLAAC is the simplest automatic IPv6 address assignment scheme and does not require any server. It works by sending an RS message request after the host starts up and the router sends back RA messages to all nodes in the local network segment. If the RA message contains the following configuration

• M-bit and O-bit all clear in the message header
• L-bit and A-bit all set in Prefix Information option

Then the host receives this RA message and performs the following operations to implement SLAAC:

• Combine the network prefix with the local interface identifier to generate a unique local address or global unicast address.
• Install the default gateway (or default route) to point to the router address (source address of the RA message).
• Set this interface as the "on-link" corresponding to the network prefix, which is also the next-hop interface of the default gateway above.
• If the RDNSS and/or DNSSL options are included, install the name servers and domain name suffixes.

This way, the host gets one or more IPv6 unique local addresses or global unicast addresses, plus the default gateway and domain name service information to complete various Internet connections.

The following is an example of the SLAAC configuration on a Cisco Catalyst 9300 Multilayer Access Switch:

The Layer 3 interface of the Cisco Multilayer Switch provides routing functionality. As you can see, when IPv6 is activated on the Layer 3 interface in VLAN 10, its default address auto-assignment scheme is SLAAC. the control bits of RA messages from this interface are all set according to the SLAAC scheme, and the network prefixes for each IPv6 address it configures are automatically added to the RA prefix information options list. Of course, the network administrator can also exclude certain network prefixes with a separate interface configuration command. The last two lines of the example configuration command specify RDNSS and DNSSL, which are also added to the RA message options.

If a host connects to a port in VLAN 10, it immediately gets a global unicast address with the network prefix of 2001:ABCD:1000::/64, and its default gateway address is set to 2001:ABCD:1000::1. Open a browser and enter a URL, and it will send a message to the specified domain name server 2001:4860:4860::8888 (Google's public name server address) to obtain the IPv6 address of the destination URL to establish a connection.

SLAAC automatic address assignment is fast and easy, providing a plug-and-play IPv6 deployment solution for small and medium-sized network deployments. However, if a network node needs access to additional configuration information, such as NTP/SNTP server, TFTP server, and SIP server addresses, or if its functionality relies on certain Vendor-specific Information Options, it must choose SLAAC + stateless DHCPv6 scheme.

This scenario still uses SLAAC automatic address assignment, but the router instructs the host to connect to a DHCPv6 server for additional configuration information. At this point, the RA message sent back by the router has

• M-bit clear and O-bit set in the message header

After receiving this RA message, the host performs the following actions:

• Install a default gateway (or default route) pointing to the router address (source address of the RA message).
• Start the DHCPv6 client and connect to the DHCPv6 server to request additional configuration information .
• Save the additional configuration information replied by the DHCPv6 server .

As you can see, SLAAC + stateless DHCPv6 is not different from SLAAC in terms of address assignment. DHCPv6 only provides additional configuration information and does not assign IPv6 addresses. So the DHCPv6 server does not track the address assignment status of network nodes, which is what "stateless" means.

The corresponding configuration commands on the Catalyst 9300 switch are as follows.

The difference with the SLAAC example is that the VLAN 10 interface configuration command ipv6 nd other-config-flag explicitly specifies to set the O-bit of the RA message. Its next command, ipv6 dhcp server vlan-10-clients , activates the DHCPv6 server response feature of the interface, corresponding to the server's pool name of vlan-10-clients . The DHCPv6 server is configured above the interface configuration, starting at ipv6 dhcp pool vlan-10-clients , and contains the DNS server address, DNS domain name, and SNTP server address.

If you are using a separate DHCPv6 server located on a network segment, you can remove the ipv6 dhcp server command and enable the ipv6 dhcp relay destination command on the next line of the example to specify the address to forward DHCPv6 requests to the external server.

Many large enterprises use DHCP to manage the IPv4 addresses of their devices, so deploying DHCPv6 to centrally assign and manage IPv6 addresses is a natural preference. This is where Stateful DHCPv6 comes into play. This scenario also requires RA messages sent by the router but does not rely solely on network prefixes for automatic address assignment. The control bits of the RA messages are configured to

• M-bit set in the message header, O-bit does not matter
• L-bit and A-bit can be set or clear as desired in Prefix Information option

Upon receiving this RA message, the host performs the following actions:

• Generate a unique local address or a global unicast address if there is a Prefix Information option with the A-bit set.
• If there is a Prefix Information option with the L-bit set, set this interface to "on-link" with the corresponding network prefix.
• If the RDNSS and/or DNSSL options are included, install the name servers and domain suffixes.
• Start the DHCPv6 client and connect to the server to request addresses and other configuration information .
• Set the address assigned by the DHCPv6 server to this interface .
• Save additional configuration information from the DHCPv6 server response .

An example of the Stateful DHCPv6 configuration command on a Catalyst 9300 switch is as follows.

Compared to SLAAC + Stateless DHCPv6 , the interface configuration here removes the ipv6 nd other-config-flag and replaces it with the ipv6 nd managed-config-flag command. This corresponds to setting the M-bit of the RA message header. The DHCPv6 server configuration adds two address prefix commands to set the network prefix. Also, the ipv6 nd prefix 2001:ABCD:1:1::/64 no-advertise configured for the interface specifies that the router does not include the 2001:ABCD:1:1::/64 prefix information option into the RA. So, this example host interface will not generate SLAAC addresses, but only two addresses from DHPCv6: a unique local address with the network prefix FD09:9:5:90::/64, and a global unicast address with the network prefix 2001:9:5:90::/64. The interface identifier for each of these two addresses is also specified by DHPCv6.

How to distinguish the source of dynamically assigned addresses for host interfaces? The method is simple. One thing to remember is that DHPCv6 does not send the network prefix length to the requestor, so the network prefix length of the addresses received from DHPCv6 is 128, while the network prefix length of the addresses generated by SLAAC will not be 128. See the following example of the wired0 interface on a Linux host:

We can immediately determine that the interface is using Stateful DHCPv6 address assignment, but also generates the SLAAC address with the same network prefix 2001:20::/64 received.

• 2001:20::53c7:1364:a4d8:fd91/128 — DHCPv6 address, random interface identifer
• 2001:20::a2ec:f9ff:fe6c:d930/64 — SLAAC addeess, interface identifer is MAC in EUI-64 format
• fe80::a2ec:f9ff:fe6c:d930/64 — Link-local address, interface identifer is MAC in EUI-64 format

Note: DHPCv6 server also does not provide any IPv6 default gateway information. The host needs to be informed of the dynamic default gateway from the RA message.

Summary and Comparison

The following table shows the control bit combinations of RA messages concerning different address allocation and other configuration acquisition methods.

Summarize three dynamic allocation schemes:

Note: Since IPv6 network interfaces can have multiple addresses (a link-local address, plus one or more unique local addresses and/or global unicast addresses), it becomes important how the source address is selected when establishing an external connection. RFC 6724 gives detailed IPv6 source address selection rules. In the development of embedded systems, the control plane and the data plane connected to the same remote device are often implemented by different functional components. For example, the control plane directly calls a Linux userspace socket to establish the connection, and the IPv6 source address used for the connection is selected by the TCP/IP stack, while the data plane directly implements data encapsulation processing and transmission in kernel space. In this case, the IPv6 source address selected by the control plane has to be synchronized to the data plane in time, otherwise, the user data might not be delivered to the same destination.

Troubleshooting Guide

The common IPv6 dynamic address assignment debugging and troubleshooting commands on Cisco routers and switches are listed in the following table.

The following console NDP protocol debug log shows that the router received an RS message from host FE80::5850:6D61:1FB:EF3A and responded with an RA message to the multicast address FF02::1 of all nodes in this network:

And the next log shows an example of Stateless DHCPv6 observed after entering the debug ipv6 dhcp debug command. Host FE80::5850:6D61:1FB:EF3A sends an INFORMATION-REQUEST message to the DHCPv6 server, which selects the source address FE80::C801:B9FF:FEF0:8 and sends a response message.

The following debug log of Stateful DHCPv6 shows the complete process of two message exchanges (SOLICIT/ADVERTISE, REQUEST/REPLY) on lines 1, 15, 16, and 26.

For complex cases where it is difficult to identify whether the problem is with the host, router, or DHCPv6 server, we recommend using the free open-source network packet analysis software Wireshark to capture packets of the entire process for analysis. While analyzing packets with Wireshark, you can apply the keyword filtering function.

We can either run Wireshark directly on the host side, or we can use the Switched Port Analyzer (SPAN) provided with the switch. Running on the network side, SPAN can collectively redirect packets from a given port to the monitor port running Wireshark for capturing. Cisco Catalyst 9300 Series switches also directly integrate with Wireshark software to intercept and analyze filtered packets online, making it very easy to use.

Sample packet capture files for three allocation scheme are available here for download and study: slaac.pcap ， stateless-dhcpv6.pcap ， stateful-dhcpv6.pcap

IPv6 Product Certification Test

Accurate and effective testing of IPv6 products is key to ensuring high interoperability, security, and reliability of IPv6 infrastructure deployments. The IPv6 Ready logo is an IPv6 testing and certification program created by the IPv6 Forum . Its goals are to define IPv6 conformance and interoperability test specifications, provide a self-testing toolset, establish Global IPv6 Test Centers and provide product validation services, and finally, issue IPv6 Ready logo.

In May 2020, IPv6 Ready Logo Program published new version 5.0 test specifications ：

• IPv6 Core Protocols Test Specification (Conformance)
• IPv6 Core Protocols Interoperability Test Specification (Interoperability)

Along with these two new test specifications, the project team also affirmed two permanent changes:

• Testing must be done in an IPv6-only environment, without any IPv4 being used for the device to function.
• The device under test must have IPv6 on and enabled on all IP interfaces by default.

Not surprisingly, the new version 5.0 core protocols test specification has a section dedicated to defining SLAAC test cases to validate this core IPv6 protocol.

IPv6 Core Protocol RFC List

In the list below, the RFCs shown in bold are directly covered by the IPv6 Ready Version 5.0 Core Protocol Test Specification:

• RFC 4191 Default Router Preferences and More-Specific Routes
• RFC 4193 Unique Local IPv6 Unicast Addresses
• RFC 4291 IP Version 6 Addressing Architecture
• RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
• RFC 4861 Neighbor Discovery for IP version 6 (IPv6)
• RFC 4862 IPv6 Stateless Address Autoconfiguration
• RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
• RFC 5095 Deprecation of Type 0 Routing Headers in IPv6
• RFC 6724 Default Address Selection for Internet Protocol Version 6 (IPv6)
• RFC 6980 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
• RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)
• RFC 8064 Recommendation on Stable IPv6 Interface Identifiers
• RFC 8106 IPv6 Router Advertisement Options for DNS Configuration
• RFC 8200 Internet Protocol, Version 6 (IPv6) Specification
• RFC 8201 Path MTU Discovery for IP version 6
• RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
• Gitalk Comments
• Utterances Comments
• Disqus Comments

There are three methods to configure a host with a global unicast address, default gateway, DNS server, and a domain name:

• Method 1 : Configure the host manually. This approach does not scale and is prone to human error;
• Method 2 : Using SLAAC and a Stateless DHCPv6 server. We have looked at this approach in our previous lesson ;
• Method 3 : Using a Stateful DHCPv6 server.

Stateful DHCPv6 is similar in functionalities to DHCP protocol in IPv4, but there are some major differences in the way the whole process works. In this lesson, we are going to examine it step by step.

Stateful vs Stateless DHCPv6

A stateless DHCPv6 server does not provide IPv6 addresses at all. It only provides " other information " such as a DNS server list and a domain name. It works in conjunction with another feature called SLAAC that tells hosts how to generate global unicast addresses. In this context stateless means that  no server keeps track  of what addresses have been assigned by which hosts and what addresses are still available for an assignment.

A stateful DHCPv6 server  provides IPv6 addresses and " other information " to hosts. It also keeps track of the state of each assignment. It tracks the address pool availability and resolves duplicated address conflicts. It also logs every assignment and keeps track of the expiration times. However, there is a big difference between DHCPv6 and DHCPv4. In IPv4 DHCP server typically provides default gateway addresses to hosts. In IPv6, only routers sending Router Advertisement messages can provide a default gateway address dynamically.

Stateful DHCPv6 Messages

Unlike IPv4, in IPv6 routers actively participate in the process of dynamic hosts addressing. In both Stateless and Stateful implementations, a router on the link advertises its presence with Router Advertisements messages. These RA messages play a very important role for a few reasons:

• Hosts set their Default Gateway based on the RA messages -  If there is only one router attached to the link, the source address of its RA messages is configured by hosts as a default gateway address. If there are multiple routers attached to the link, there is a value in the RA message called pref (router preference)  that can be set to Low, Medium, or High. Hosts set their default gateway to the source address of the RA messages with the highest preference.
• A-flag - if it is set to 1, this informs hosts that they can auto-generate GUA address using SLAAC. If it is set to 0 means that auto-configuration is not allowed for this segment.
• O-flag - if it is set to 1, this informs hosts that they can obtain a DNS server list and a domain name from a Stateless DHCPv6 server, but not addressing information. Typically it works in conjunction with SLAAC for auto-addressing and both the A-flag and the O-flag are set to 1.
• M-flag - if it is set to 1, this informs hosts that they can obtain a global address as well as DNS and a domain name from a Stateful DHCPv6 server. Typically this means that auto-addressing using SLAAC is not allowed on this segment and both the  A-flag and the O-flag are set to 0.

Figure 1 illustrates the steps PC1 takes to configure a global unicast address, a default gateway, and a DNS using a Stateful DHCPv6:

• Step 1 - PC1 sends out a Router Solicitation message destined to the all-routers multicast address FF02::2.
• Step 2 - Upon receiving the RS from PC1, Router 1 generates a Router Advertisement message with the M-flag set to 1 and the A-flag set to 0. This informs PC1 that SLAAC is not allowed on this segment and it must use a Stateful DHCPv6 for addressing and other configuration. Note that RA messages are sent to the all-nodes multicast group FF02::1 and are received by all neighbors on a local segment.
• Step 3 - Upon receiving the Route Advertisement, PC1 sets the source IPv6 address of Router 1 (FE80::1) as its default gateway. Because the A-flag is set to 0, PC1 does not perform Stateless Address Auto-configuration (SLAAC).
• Step 4 - Because the M-flag in the RA message is set to 1, PC1 sends out a DHCPv6 SOLICIT message to the all-dhcpv6-servers multicast group FF02::1:2, searching for DHCP server.
• Step 5 - Upon hearing the solicit message, the server responds with a DHCPv6 ADVERTISE message. It is destined directly as unicast to the link-local address of PC1.
• Step 6 - PC1 then knows that a DHCPv6 service is available and sends out a REQUEST packet asking for addressing information.
• Step 7 - Upon receiving the REQUEST, the server responds with a DHCPv6 REPLY that contains the global unicast address and all other information that is available for assignment.
• Step 8 - In the end, PC1 performs Duplicate Address Detection (DAD) on the received GUA address to ensure that it is unique.

Note that the DHCPv6 service works in conjunction with the Neighbor Discovery protocol. Although the global address including all other information is provided by the server, the default gateway is provided by Router 1 .

Implementing Stateful DHCPv6 with a Cisco router

For this example, we are going to use a basic topology shown in figure 2. As a Stateful DHCPv6 server, we will use a regular Cisco router named Router2.

There are three mains configuration steps to enable Stateful DHCPv6 service:

• Set the A-flag in the RA messages to 0 - From a technical standpoint, this is not a mandatory step. But if the A-flag is left to the default value of 1, hosts will obtain a global unicast address from DHCPv6 and will also generate one using SLAAC. Therefore, hosts will have at least two global addresses configured. Typically, companies have security policies in place and want to track the IP addresses on the network. In this case, hosts should not be able to generate addresses on their own. Thus, it is a best practice to disable the SLAAC process by setting the A-flag to 0.
• Set the M-flag in the RA messages to 1  - To inform hosts in the local network that there is a DHCPv6 server that provides both addressing and other information, routers must advertise this feature using the M-flag in the RA messages.
• Set up a Stateful DHCPv6 server - A device in the network must act as a DHCP server. It could be a Cisco router or other appliance.

Setting the A-flag to 0 and the M-flag to 1

Let's configure Router 1 from scratch. Note that IPv6 unicast routing must be enabled otherwise the router won't begin sending RA messages.

At this point, all flags in the Router Advertisement messages are set to their default values. By default on Cisco routers, the M-flag is set to 0, the O-flag is set to 0 and the A-flag is set to 1. To enable Stateful DHCPv6 , we must set the M-flag to 1 using the following command under the interface configuration mode.

And disable SLAAC by setting the A-flag to 0 using the following command:

If we now look at a Wireshark capture of the RA messages being sent by Router1, we can verify that the M-flag is set to 1 and the A-flag is set to 0.

Configuring a Cisco router as a Stateful DHCPv6 server

Now it is time to configure Router2 as a DHCPv6 server. The configuration is pretty basic and straightforward. We must create a new DHCP pool using the command ipv6 dhcp pool [ pool-name ] . This will lead us into the pool configuration mode, where we specify all parameters such as prefix, DNS servers, and a domain name. 

After the pool has been created, we must enable it on the interface attached to the link.

Note that we stop Router2 from sending out any Route Advertisement messages with the command  ipv6 nd ra suppress all  because it just plays the role of a server and should not be acting as a router in our example.

Verification Steps

Let's look at some verification steps that we can take to make sure everything worked as expected.

Verifying Router 1 as a Default Router

As you have seen in the Step-by-step explanation, the process starts with the Router Solicitation and Router Advertisement messages exchanged by Router1 and PC1. The most useful command we can use is the show ipv6 interface  that displays all IPv6 and ICMPv6 settings of a particular interface.

Note that the last line says " Hosts use DHCP to obtain addresses ". This means that the M-flag is set to 1 and Router1 informs hosts on the segment to use Stateful DHCPv6. You should not see a line that says " Hosts use stateless autoconfig for addresses " meaning that SLAAC is disabled (A-flag is set to 0)

Verifying Router 2 as a Stateful DHCPv6 server

There are several commands that display information about the status of the DHCPv6 service provided by the router. The show ipv6 dhcp pool command outputs the allocation prefix, along with the other information and the number of active clients. In our example, there is only one active client as expected.

Another useful one is the show ipv6 dhcp bindings command that displays the following important values:

• Client - This is the link-local address of a client that obtained an IPv6 address from the server. In our example, you can see that this is the LLA of PC1.
• DUID - This is the DHCP Unique Identifier used to uniquely identify a client. In our example,  the value is the identifier of PC1, shown in the ipconfig /all output below.
• Address - This is the global unicast address that the DHCPv6 server provided to this client. You will see later on in the ipconfig /all output that this is the IPv6 address PC1 has had configured.

Verifying that PC1 has obtained GUA address

Using the ipconfig /all command on PC1, we can verify that PC1 successfully obtained a global IPv6 address and other information from the DHCP server. You can check based on the DHCP Unique Identifier (DUID) that this is the exact address Router 2 has provided.

• Skip to content
• Skip to search
• Skip to footer

IPv6 Configuration Guide, Cisco IOS Release 15.0S

Bias-free language.

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

• Implementing IPv6 Addressing and Basic Connectivity
• Implementing Bidirectional Forwarding Detection for IPv6
• Implementing Multiprotocol BGP for IPv6

Implementing DHCP for IPv6

• Implementing EIGRP for IPv6
• Configuring First Hop Redundancy Protocols in IPv6
• Implementing IS-IS for IPv6
• Implementing IPv6 for Network Management
• Implementing Mobile IPv6
• Implementing IPv6 Multicast
• Implementing IPv6 over MPLS
• Implementing IPv6 VPN over MPLS
• Netflow v9 for IPv6
• Implementing OSPFv3
• Implementing QoS for IPv6
• Implementing RIP for IPv6
• Implementing Selective Packet Discard in IPv6
• Implementing Static Routes for IPv6
• Implementing Traffic Filters and Firewalls for IPv6 Security
• Implementing Tunneling for IPv6

Chapter: Implementing DHCP for IPv6

Finding feature information, restrictions for implementing dhcp for ipv6, configuring nodes without prefix delegation, client and server identification, rapid commit, client function, server function, dhcp relay agent, dhcpv6 relay source configuration, dhcpv6 relay sso and issu, dhcpv6 server and relay--mpls vpn support, configuring the dhcpv6 configuration pool, configuring a binding database agent for the server function, configuring the dhcpv6 client function, configuring the dhcpv6 relay agent, configuring route addition for relay and server, restrictions for configuring a dhcpv6 relay source, configuring a dhcpv6 relay source on an interface, configuring a dhcpv6 relay source globally, configuring dhcpv6 bulk-lease query parameters, prerequisites for configuring dhcpv6 address assignment, enabling the dhcpv6 server function on an interface, enabling the dhcpv6 client function on an interface, configuring the stateless dhcpv6 server, configuring the stateless dhcpv6 client, enabling processing of packets with source routing header options, configuring the information refresh server option, importing the information refresh server option, configuring nis- and nisp-related server options, importing nis- and nis+-related server options, importing sip server options, configuring the sntp server option, importing the sntp server option, importing stateless dhcpv6 server options, defining a general prefix with the dhcpv6 prefix delegation client function, configuring a vrf-aware relay, configuring a vrf-aware server, deleting automatic client bindings from the dhcpv6 binding table, troubleshooting dhcpv6, example: configuring the dhcpv6 server function, example: configuring the dhcpv6 client function, example: configuring a database agent for the server function, example: configuring dhcp for ipv6 address assignment, example: configuring the stateless dhcpv6 function, additional references, feature information for implementing dhcp for ipv6.

This module describes how to configure Dynamic Host Configuration Protocol (DHCP) for IPv6.

Information About Implementing DHCP for IPv6

How to implement dhcp for ipv6, configuration examples for implementing dhcpv6.

Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the Feature Information Table at the end of this document.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn . An account on Cisco.com is not required.

• Cisco IOS Release 12.0S provides IPv6 support on Gigabit Switch Routers (GSRs) and Cisco 10720 Internet routers only.
• The DHCPv6 Remote-ID for Ethernet Interfaces feature works only for Ethernet interfaces in Cisco IOS Release 12.2(33)SRC.
• The DHCPv6 implementation in Cisco IOS Release 12.3(4)T, Cisco IOS Release 12.0(32)S, and Cisco IOS 12.2(33)SRC supports only stateless address assignment.

DHCPv6 Prefix Delegation

The IPv6 Access Services--DHCPv6 Prefix Delegation feature can be used to manage link, subnet, and site addressing changes. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) can be used in environments to deliver stateful and stateless information. The definitions are given below:

• Stateful--Address assignment is centrally managed and clients must obtain configuration information that is not available through protocols such as address autoconfiguration and neighbor discovery.
• Stateless--Stateless configuration parameters do not require a server to maintain any dynamic state for individual clients, such as Domain Name System (DNS) server addresses and domain search list options.

Extensions to DHCPv6 also enable prefix delegation, through which an ISP can automate the process of assigning prefixes to a customer for use within the customer's network. Prefix delegation occurs between a provider edge (PE) device and customer premises equipment (CPE) using the DHCPv6 prefix delegation option. Once the ISP has delegated prefixes to a customer, the customer may further subnet and assign prefixes to the links in the customer's network.

DHCPv6 Client Server and Relay Functions

Stateless DHCPv6 allows DHCPv6 to be used for configuring a node with parameters that do not require a server to maintain any dynamic state for the node. The use of stateless DHCP is controlled by router advertisement (RA) messages multicasted by routers. The DHCPv6 client will invoke stateless DHCPv6 when it receives an appropriate RA. The DHCPv6 server will respond to a stateless DHCPv6 request with the appropriate configuration parameters, such as the DNS servers and domain search list options.

Each DHCPv6 client and server is identified by a DHCP unique identifier (DUID). The DUID is carried in client identifier and server identifier options. The DUID is unique across all DHCP clients and servers, and it is stable for any specific client or server. DHCPv6 uses DUIDs based on link-layer addresses for both the client and server identifier. The device uses the MAC address from the lowest-numbered interface to form the DUID. The network interface is assumed to be permanently attached to the device.

When a DHCPv6 client requests two prefixes with the same DUID but with different IAIDs on two different interfaces, these prefixes are considered to be for two different clients, and the interface information is maintained for both.

The DHCPv6 client can obtain configuration parameters from a server either through a rapid two-message exchange (solicit, reply) or through a normal four-message exchange (solicit, advertise, request, reply). By default, the four-message exchange is used. When the rapid-commit option is enabled by both client and server, the two-message exchange is used.

The DHCPv6 client, server, and relay functions are mutually exclusive on an interface. When one of these functions is already enabled and a user tries to configure a different function on the same interface, one of the following messages is displayed: "Interface is in DHCP client mode," "Interface is in DHCP server mode," or "Interface is in DHCP relay mode."

The following sections describe these functions:

The DHCPv6 client function can be enabled on individual IPv6-enabled interfaces.

The DHCPv6 client can request and accept those configuration parameters that do not require a server to maintain any dynamic state for individual clients, such as DNS server addresses and domain search list options. The DHCPv6 client will configure the local Cisco IOS stack with the received information.

The DHCPv6 client can also request the delegation of prefixes. The prefixes acquired from a delegating router will be stored in a local IPv6 general prefix pool. The prefixes in the general prefix pool can then be referred to from other applications; for example, the general prefix pools can be used to number router downstream interfaces.

Server Selection

A DHCPv6 client builds a list of potential servers by sending a solicit message and collecting advertise message replies from servers. These messages are ranked based on preference value, and servers may add a preference option to their advertise messages explicitly stating their preference value. If the client needs to acquire prefixes from servers, only servers that have advertised prefixes are considered.

IAPD and IAID

An Identity Association for Prefix Delegation (IAPD) is a collection of prefixes assigned to a requesting router. A requesting router may have more than one IAPD; for example, one for each of its interfaces.

Each IAPD is identified by an identity association identification (IAID). The IAID is chosen by the requesting router and is unique among the IAPD IAIDs on the requesting router. IAIDs are made consistent across reboots by using information from the associated network interface, which is assumed to be permanently attached to the device.

The DHCPv6 server function can be enabled on individual IPv6-enabled interfaces.

The DHCPv6 server can provide those configuration parameters that do not require the server to maintain any dynamic state for individual clients, such as DNS server addresses and domain search list options. The DHCPv6 server may be configured to perform prefix delegation.

All the configuration parameters for clients are independently configured into DHCPv6 configuration pools, which are stored in NVRAM. A configuration pool can be associated with a particular DHCPv6 server on an interface when it is started. Prefixes to be delegated to clients may be specified either as a list of preassigned prefixes for a particular client or as IPv6 local prefix pools that are also stored in NVRAM. The list of manually configured prefixes or IPv6 local prefix pools can be referenced and used by DHCPv6 configuration pools.

The DHCPv6 server maintains an automatic binding table in memory to track the assignment of some configuration parameters, such as prefixes between the server and its clients. The automatic bindings can be stored permanently in the database agent, which can be, for example, a remote TFTP server or local NVRAM file system.

Configuration Information Pool

A DHCPv6 configuration information pool is a named entity that includes information about available configuration parameters and policies that control assignment of the parameters to clients from the pool. A pool is configured independently of the DHCPv6 service and is associated with the DHCPv6 service through the command-line interface (CLI).

Each configuration pool can contain the following configuration parameters and operational information:

• A prefix pool name and associated preferred and valid lifetimes
• A list of available prefixes for a particular client and associated preferred and valid lifetimes
• A list of IPv6 addresses of DNS servers
• A domain search list, which is a string containing domain names for DNS resolution

DHCP for IPv6 Address Assignment

DHCPv6 enables DHCP servers to pass configuration parameters, such as IPv6 network addresses, to IPv6 clients. The DHCPv6 Individual Address Assignment feature manages nonduplicate address assignment in the correct prefix based on the network where the host is connected. Assigned addresses can be from one or multiple prefix pools. Additional options, such as the default domain and DNS name-server address, can be passed back to the client. Address pools can be assigned for use on a specific interface or on multiple interfaces, or the server can automatically find the appropriate pool.

Prefix Assignment

A prefix-delegating router (DHCPv6 server) selects prefixes to be assigned to a requesting router (DHCPv6 client) upon receiving a request from the client. The server can select prefixes for a requesting client using static assignment and dynamic assignment mechanisms. Administrators can manually configure a list of prefixes and associated preferred and valid lifetimes for an IAPD of a specific client that is identified by its DUID.

When the delegating router receives a request from a client, it checks if there is a static binding configured for the IAPD in the client's message. If a static binding is present, the prefixes in the binding are returned to the client. If no such a binding is found, the server attempts to assign prefixes for the client from other sources.

The Cisco IOS DHCPv6 server can assign prefixes dynamically from an IPv6 local prefix pool. When the server receives a prefix request from a client, it attempts to obtain unassigned prefixes from the pool. After the client releases the previously assigned prefixes, the server returns them to the pool for reassignment.

An IPv6 prefix delegating router can also select prefixes for a requesting router based on an external authority such as a RADIUS server using the Framed-IPv6-Prefix attribute. For more information on this feature, see the Implementing ADSL and Deploying Dial Access for IPv6 module.

Automatic Binding

Each DHCPv6 configuration pool has an associated binding table. The binding table contains the records about all the prefixes in the configuration pool that have been explicitly delegated to clients. Each entry in the binding table contains the following information:

• Client DUID
• Client IPv6 address
• A list of IAPDs associated with the client
• A list of prefixes delegated to each IAPD
• Preferred and valid lifetimes for each prefix
• The configuration pool to which this binding table belongs
• The network interface on which the server that is using the pool is running

A binding table entry is automatically created whenever a prefix is delegated to a client from the configuration pool, and it is updated when the client renews, rebinds, or confirms the prefix delegation. A binding table entry is deleted when the client releases all the prefixes in the binding voluntarily, all prefixes' valid lifetimes have expired, or administrators run the clear ipv6 dhcp binding command.

Binding Database

Each permanent storage to which the binding database is saved is called the database agent. A database agent can be a remote host such as an FTP server or a local file system such as NVRAM.

The automatic bindings are maintained in RAM and can be saved to some permanent storage so that the information about configuration such as prefixes assigned to clients is not lost after a system reload or power down. The bindings are stored as text records for easy maintenance. Each record contains the following information:

• DHCPv6 pool name from which the configuration was assigned to the client
• Interface identifier from which the client requests were received
• The client IPv6 address
• The client DUID
• IAID of the IAPD
• Prefix delegated to the client
• The prefix length
• The prefix preferred lifetime in seconds
• The prefix valid lifetime in seconds
• The prefix expiration time stamp
• Optional local prefix pool name from which the prefix was assigned

At the beginning of the file, before the text records, a time stamp records the time when the database is written and a version number, which helps differentiate between newer and older databases. At the end of the file, after the text records, the text string "*end*" is stored to detect file truncation.

The permanent storage to which the binding database is saved is called the database agent. Database agents include FTP and TFTP servers, RCP, flash file system, and NVRAM.

DHCPv6 Server Stateless Autoconfiguration

Hierarchical DHCPv6 for stateless configuration parameters allows a stateless or stateful DHCPv6 client to export configuration parameters (DHCPv6 options) to a local DHCPv6 server pool. The local DHCPv6 server can then provide the imported configuration parameters to other DHCPv6 clients.

The figure below shows a typical broadband deployment.

The CPE interface toward the PE can be a stateless or stateful DHCPv6 client. In either case, the ISP-side DHCPv6 server may provide configuration parameters such as DNS server addresses, domain names, and Simple Network Time Protocol (SNTP) servers to the DHCP client on the CPE. These information can be specific to an ISP and may change.

In addition to being a DHCPv6 client (for example, toward the ISP), the CPE may act as a DHCPv6 server to the home network. For example, Neighbor Discovery followed by stateless or stateful DHCPv6 can occur on the link between CPE and the home devices (for example, the home router or PC). In some cases, the information to be provided to the home network is the same information obtained from the ISP-side DHCPv6 server. Because this information can be dynamically changed, it cannot be hard-configured in the CPE's configuration. Therefore, the DHCPv6 component on the CPE allows automatic importing of configuration parameters from the DHCPv6 client to the DHCPv6 server pool.

DHCPv6 provides support of the options for IPv6 on the server described in the following sections:

Information Refresh Server Option

The DHCPv6 information refresh option can specify an upper boundary for the length of time a client should wait before refreshing information retrieved from DHCPv6. This option is used with stateless DHCPv6, because there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration.

NIS- and NIS+-Related Server Options

Users can configure the network information service (NIS) or NIS plus (NIS+) address or domain name of a DHCPv6 server using NIS- and NIS+-related options, and then import that information to the DHCPv6 client.

SIP Server Options

Session initiation protocol (SIP) server options contain either a list of domain names or IPv6 addresses that can be mapped to one or more SIP outbound proxy servers. One option carries a list of domain names, and the other option carries a list of 128-bit IPv6 addresses.

SIP is an application-layer control protocol that can establish, modify and terminate multimedia sessions or calls. A SIP system has several logical components: user agents, proxy servers, redirect servers, and registrars. User agents may contain SIP clients; proxy servers always contain SIP clients.

SNTP Server Option

The SNTP server option provides a list of one or more IPv6 addresses of SNTP servers available to the client for synchronization. The clients use these SNTP servers to synchronize their system time to that of the standard time servers. The server may list the SNTP servers in decreasing order of preference, but clients must treat the list of SNTP servers as an ordered list.

A DHCP relay agent, which may reside on the client's link, is used to relay messages between the client and server. DHCP relay agent operation is transparent to the client. A client locates a DHCP server using a reserved, link-scoped multicast address. Therefore, it is a requirement for direct communication between the client and the server that the client and the server be attached to the same link. However, in some situations in which ease of management, economy, or scalability is a concern, it is desirable to allow a DHCP client to send a message to a DHCP server that is not connected to the same link.

DHCPv6 Relay Agent Notification for Prefix Delegation

DHCPv6 relay agent notification for prefix delegation allows the router working as a DHCPv6 relay agent to find prefix delegation options by reviewing the contents of a DHCPv6 RELAY-REPLY packet that is being relayed by the relay agent to the client. When a prefix delegation option is found by the relay agent, the relay agent extracts the information about the prefix being delegated and inserts an IPv6 static route matching the prefix delegation information onto the relay agent. Future packets destined to that prefix via relay will be forwarded based on the information contained in the prefix delegation. The IPv6 static route is then left in the routing table until the prefix delegation lease time expires or the relay agent receives a release packet from the client releasing the prefix delegation.

No user configuration is required for this feature. Static route management is done automatically by the relay agent.

The IPv6 routes are added when the relay agent relays a RELAY-REPLY packet, and the IPv6 routes are deleted when the prefix delegation lease time expires or the relay agent receives a release message. An IPv6 static route in the routing table of the relay agent can be updated when the prefix delegation lease time is extended.

This feature leaves a static IPv6 route on the routing table of the relay agent. This registered IPv6 address allows unicast reverse packet forwarding (uRPF) to work by allowing the router doing the reverse lookup to confirm that the IPv6 address on the relay agent is not malformed or spoofed. The static route left in the routing table of the relay agent can be redistributed to other routing protocols to advertise the subnets to other nodes. The static routes will be removed when an DHCP_DECLINE message is sent by the client.

DHCPv6 Bulk-Lease Query

DHCPv6 supports bulk-lease query that allows a client to request information about DHCPv6 bindings. This functionality adds new query types and allows the bulk transfer of DHCPv6 binding data through TCP.

Bulk-lease query is enabled by default if the DHCPv6 relay agent is enabled. Bulk-lease query is triggered at the relay agent startup to retrieve binding information lost because of a reload. If a DHCPv6 relay destination is configured on an interface, bulk-lease query is performed by the IPv6 address of the interface on which DHCPv6 relay is enabled. Bulk-lease query is a separate process from the relay agent process.

DHCPv6 Relay Chaining

DHCPv6 messages can be relayed through multiple relay agents. This configuration is called relay chaining . Such a configuration can be supported only when each relay agent adds certain information to DHCPv6 messages before relaying them. The additional information helps in relaying the DHCPv6 reply back to the DHCPv6 client through the same path.

The delegated IPv6 prefix must be routable in order to be useful. The actual DHCPv6 Prefix Delegation (PD) client may not be permitted to inject routes into the delegating network. In service-provider (SP) networks, for example, an edge router typically acts as a DHCPv6 relay agent, and this edge router often has the responsibility to maintain routes within the SP network for clients' PD bindings. In the event that DHCPv6 requests and responses are relayed through a chain of DHCPv6 relays, there may be a need to introduce appropriate routes (particularly with DHCPv6 PD) in the Forwarding Information Base (FIB) so that routing is handled transparently.

The DHCPv6 server sends its replies to the source address of relayed messages. Normally, a DHCPv6 relay uses the address of the server-facing interface used to send messages as the source. However, in some networks, it may be desirable to configure a more stable address (such as a loopback interface) and have the relay use that interface as the source address of relayed messages. The DHCPv6 Relay Source Configuration feature provides this capability.

The figure below shows a simple network with a single client, relay, and server. The relay and server communicate over 2001:DB8:1::/64, and the relay has a client-facing interface on 2001:DB8:2::/64. The relay also has a loopback interface configured with address 2001:DB8:3:1/64.

When the relay receives a request from the client, the relay includes an address from the client-facing interface (Ethernet 1/0) in the link-address field of a relay-forward message. This address is used by the server to select an address pool. The relay then sends the relay-forward message toward the server. By default, the address of the server-facing (Ethernet 0/0) interface is used as the IPv6 source, and the server will send any reply to that address.

If the relay source interface is explicitly configured, the relay will use that interface's primary IPv6 address as the IPv6 source for messages it forwards. For example, configuring Loopback 0 as the source would cause the relay to use 2001:DB8:3:1/64 as the IPv6 source address for messages relayed toward the server.

In specific Cisco networking devices that support dual RPs, stateful switchover (SSO) takes advantage of RP redundancy to increase network availability. The feature establishes one of the RPs as the active processor while the other RP is designated as the standby processor, and then synchronizing critical state information between them. Following an initial synchronization between the two processors, SSO dynamically maintains RP state information between them.

The Cisco IOS In Service Software Upgrade (ISSU) process allows Cisco IOS software to be updated or otherwise modified while packet forwarding continues. In most networks, planned software upgrades are a significant cause of downtime. ISSU allows Cisco IOS software to be modified while packet forwarding continues, which increases network availability and reduces downtime caused by planned software upgrades.

SSO and ISSU use redundant hardware, with the active and standby RP each running an instance of the DHCP relay agent. Both instances exchange run-time state data.

For further information about SSO and ISSU, see the "Stateful Switchover" and "Cisco IOS In Service Software Upgrade Process" modules in the Cisco IOS High Availability Configuration Guide.

DHCPv6 Relay Options: Remote-ID for Ethernet Interfaces

This feature adds the remote identification (remote-ID) option to relayed (RELAY-FORWARD) DHCPv6 packets.

The remote-ID option provides information to the DHCPv6 server, including port information, the system's DUID, and the VLAN ID. Collectively, this information can be used to uniquely identify both the relay and the port on the relay through which the client's packet arrived. The DHCPv6 server uses this information to select parameters specific to a particular user, host, or subscriber modem. This feature works only for Ethernet interfaces at this time.

This feature introduces no user configuration. Because the addition of the remote-ID option to the RELAY-FORWARD packet occurs automatically, no user configuration is necessary.

The DHCPv6 server does not need to echo the remote-ID option in the RELAY-REPLY packet. Internet Assigned Numbers Authority (IANA) has assigned the DHCPv6 option code 37 for the relay agent remote-ID option.

If the remote-ID option is included in the RELAY-REPLY packet, the option is stripped out of the packet before the packet is relayed to the client.

DHCPv6 Relay Options: Reload Persistent Interface-ID

This feature makes the interface-ID option, which is used by relay agents to decide which interface should be used when forwarding a RELAY-REPLY packet, persistent. A persistent interface-ID option will not change if the router acting as a relay agent goes offline (such as during a reload or a power outage). When the router acting as a relay agent returns online, it is possible that changes to the internal interface index of the relay agent may have occurred in certain scenarios (such as cases where the relay agent reboots and has a change in the number of interfaces in the interface index, or the relay agents boots up and has more virtual interfaces than it did before the reboot). This feature prevents this scenario from causing any problems.

This feature changes the DHCPv6 interface-ID option to be expressed as simply the short form of the interface name. This syntax helps avoid potential problems that could arise due to physical or logical interfaces changing on the relay agent after a reload.

To facilitate managed central services in a Multiprotocol Label Switching (MPLS)-based network, DHCPv6 must be made MPLS-aware so a single resource can be used to serve multiple virtual private networks (VPNs) instead of dedicating a resource to a single VPN.

The DHCPv6 server implementation of MPLS VPN support allows a per-pool configuration so DHCPv6 pools can be associated with a VPN routing and forwarding (VRF) instance. The DHCPv6 server differentiates clients from various VRFs and assigns an IPv6 prefix accordingly from the respective VRF pools. Meanwhile, the DHCPv6 bindings store clients' VRF information.

The DHCPv6 relay implementation allows the configuration of the destination VRF instance to which the relay messages will be forwarded. The relay adds the client's VPN information while forwarding the client's DHCPv6 requests toward the server, and the relay then processes the client's VPN information in reply packets from server.

The relay adds IPv6 static routes for delegated prefixes in corresponding clients' VRF, and the relay's high availability (HA) functionality synchronizes the VRF information while synchronizing static routes created by the relay process.

The DHCPv6 relay and server VRF-aware features are disabled by default for backward compatibility.

Configuring the DHCPv6 Server Function

Configuring a dhcpv6 relay source, configuring dhcp for ipv6 address assignment, configuring the stateless dhcpv6 function, configuring the dhcpv6 server options, configuring a vrf-aware relay and server for mpls vpn support, verifying dhcpv6 configuration and operation.

The tasks in the following sections explain how to configure DHCPv6 server function:

Perform this task to create and configure the DHCPv6 configuration pool and associate the pool with a server on an interface.

1.     enable

2.     configure terminal

3.     ipv6 dhcp pool poolname

4.     domain-name domain

5.     dns-server ipv6-address

6.     prefix-delegation ipv6-prefix / prefix-length client-duid [ iaid iaid ] [ lifetime ]

7.     prefix-delegation pool poolname [ lifetime valid-lifetime preferred-lifetime ]

8.     exit

9.     interface type number

10.     ipv6 dhcp server poolname [ rapid-commit ] [ preference value ] [ allow-hint ]

11.     end

3.     ipv6 dhcp database agent [ write-delay seconds ] [ timeout seconds ]

4.     end

General prefixes can be defined dynamically from a prefix received by a DHCPv6 prefix delegation client. The delegated prefix is stored in a general prefix.

3.     interface type number

4.     ipv6 dhcp client pd { prefix-name | hint ipv6-prefix } [ rapid-commit ]

5.     end

4.     ipv6 dhcp relay destination ipv6-address [ interface-type interface-number ]

To enable route addition by DHCPv6 relay and server for the delegated prefix, use the ipv6 dhcp iapd-route-add command in global configuration mode.

To add routes for individually assigned IPv6 addresses on a relay or server, use the ipv6 dhcp iana-route-add command in global configuration mode

Perform the following tasks to configure a DHCPv6 relay source:

• If the configured interface is shut down, or if all of its IPv6 addresses are removed, the relay will revert to its standard behavior.
• The command line interface (CLI) will report an error if the user attempts to specify an interface that has no IPv6 addresses configured.
• The interface configuration takes precedence over the global configuration if both have been configured.

Perform this task to configure an interface to use as the source when relaying messages.

4.     ipv6 dhcp relay source-interface interface-type interface-number

3.     ipv6 dhcp-relay source-interface interface-type interface-number

The DHCPv6 Bulk-Lease Query feature is enabled automatically when the DHCPv6 relay agent is enabled.

3.     ipv6 dhcp-relay bulk-lease { data-timeout seconds | retry number } [ disable ]

Perform the following tasks to configure DHCPv6 address assignment:

By default, no DHCPv6 features are configured on the router.

When configuring DHCPv6 address assignment, remember that the specified interface must be one of these Layer 3 interfaces:

• Switch Virtual Interface (SVI): a VLAN interface created by using the interface vlan vlan-id command.
• EtherChannel port channel in Layer 3 mode: a port-channel logical interface created by using the interface port-channel port-channel-number command.

Perform this task to enable the DHCPv6 server function on an interface. Note that to delete a DHCPv6 pool, you must use the no ipv6 dhcp pool poolname global configuration command. Use the no form of the DHCP pool configuration mode commands to change the DHCPv6 pool characteristics. To disable the DHCPv6 server function on an interface, use the no ipv6 dhcp server interface configuration command.

4.     address prefix ipv6-prefix [ lifetime { valid-lifetime preferred-lifetime | infinite }]

5.     link-address ipv6-prefix

6.     vendor-specific vendor-id

7.     suboption number { address ipv6-address | ascii ascii-string | hex hex-string }

9.     exit

10.     interface type number

11.     ipv6 dhcp server [ poolname | automatic ] [ rapid-commit ] [ preference value ] [ allow-hint ]

12.     end

13.     Do one of the following:

• show ipv6 dhcp pool
• show ipv6 dhcp interface

14.     copy running-config startup-config

Perform this task to enable the DHCPv6 client function on an interface. To disable the DHCPv6 client function, use the no ipv6 address dhcp interface configuration command. To remove the DHCPv6 client request, use the no ipv6 address dhcp client request vendor interface configuration command.

4.     ipv6 address dhcp [ rapid-commit ]

5.     ipv6 address dhcp client request vendor

6.     end

7.     show ipv6 dhcp interface

The server maintains no state related to clients; for example, no prefix pools and records of allocation are maintained. Therefore, this function is "stateless" DHCPv6.

4.     dns-server ipv6-address

5.     domain-name domain

6.     exit

7.     interface type number

8.     ipv6 dhcp server poolname [ rapid-commit ] [ preference value ] [ allow-hint ]

9.     ipv6 nd other-config-flag

10.     end

4.     ipv6 address autoconfig [ default ]

3.     ipv6 source-route

4.     information refresh { days [ hours minutes ] | infinity }

4.     import information refresh

4.     nis address ipv6-address

5.     nis domain-name domain-name

6.     nisp address ipv6-address

7.     nisp domain-name domain-name

8.     end

4.     import nis address

5.     import nis domain-name

6.     import nisp address

7.     import nisp domain-name

4.     import sip address

5.     import sip domain-name

4.     sntp address ipv6-address

4.     import sntp address ipv6-address

4.     import dns-server

5.     import domain-name

Perform this task to configure the DHCPv6 client function on an interface and enable prefix delegation on an interface. The delegated prefix is stored in a general prefix.

Note that you do not have to configure this feature on specified interfaces; if you want the feature to be enabled globally on the router only, perform steps 1, 2, and 3.

3.     ipv6 dhcp-relay option vpn

4.     interface type number

5.     ipv6 dhcp relay option vpn

6.     ipv6 dhcp relay destination ipv6-address [ interface-type interface-number | vrf vrf-name | global ]

7.     end

4.     ipv6 dhcp server vrf enable

2.     clear ipv6 dhcp binding [ ipv6-address ] [ vrf vrf-name ]

2.     debug ipv6 dhcp [ detail ]

3.     debug ipv6 dhcp database

4.     debug ipv6 dhcp relay

2.     show ipv6 dhcp

3.     show ipv6 dhcp binding [ ipv6-address ]

4.     show ipv6 dhcp database [ agent-URL ]

5.     show ipv6 dhcp interface [ type number ]

6.     show ipv6 dhcp pool [ poolname ]

7.     show running-config

Sample Output from the show ipv6 dhcp Command

The following example from the show ipv6 dhcp command shows the DUID of the device:

Sample Output from the show ipv6 dhcp binding Command

In the following example, the show ipv6 dhcp binding command shows information about two clients, including their DUIDs, IAPDs, prefixes, and preferred and valid lifetimes:

Sample Output from the show ipv6 dhcp database Command

In the following example, the show ipv6 dhcp database command provides information on the binding database agents TFTP, NVRAM, and flash:

Sample Output from the show ipv6 dhcp interface Command

The following is sample output from the show ipv6 dhcp interface command. In the first example, the command is used on a router that has an interface acting as a DHCPv6 server. In the second example, the command is used on a router that has an interface acting as a DHCPv6 client:

Sample Output from the show ipv6 dhcp pool Command

In the following example, the show ipv6 dhcp pool command provides information on the configuration pool named svr-p1, including the static bindings, prefix information, the DNS server, and the domain names found in the svr-p1 pool:

DHCPv6 clients are connected to the server on Ethernet interface 0/0. The server is configured to use parameters from the DHCP pool called dhcp-pool. This pool provides clients with the IPv6 address of a DNS server and the domain name to be used. It also specifies that prefixes can be delegated from the prefix pool called client-prefix-pool1. The prefixes delegated will have valid and preferred lifetimes of 1800 and 600 seconds. The prefix pool named client-prefix-pool1 has a prefix of length /40 from which it will delegate (sub)prefixes of length /48.

This DHCPv6 client has three interfaces: Ethernet interface 0/0 is the upstream link to a service provider, which has a DHCPv6 server function enabled. The Fast Ethernet interfaces 0/0 and 0/1 are links to local networks.

The upstream interface, Ethernet interface 0/0, has the DHCPv6 client function enabled. Prefixes delegated by the provider are stored in the general prefix called prefix-from-provider.

The local networks, Fast Ethernet interfaces 0/0 and 0/1, both assign interface addresses based on the general prefix called prefix-from-provider. The bits on the left part of the addresses come from the general prefix, and the bits on the right part of the addresses are specified statically.

The DHCPv6 server is configured to store table bindings to the file named dhcp-binding on the server at address 10.0.0.1 using the TFTP protocol. The bindings are saved every 120 seconds.

The following example shows how to specify DHCP for IPv6 binding database agent parameters and store binding entries in bootflash:

The following example shows how to configure a pool called engineering with an IPv6 address prefix:

The following example shows how to configure A pool called testgroup with three link addresses and an IPv6 address prefix:

The following example shows how to configure a pool called 350 with vendor-specific options:

This example uses the DHCPv6 function to configure clients with information about the name lookup system. The server is configured with a DHCP pool, which contains name lookup information to be passed to clients. It does not need to contain a prefix pool. This DHCP pool is attached to the access link to customers (Ethernet0/0) using the ipv6 dhcp server command. The access link also has the ipv6 nd other-config-flag command enabled. RA messages sent from this interface will inform clients that they should use DHCPv6 for "other" (for example, nonaddress) configuration information.

The client has no obvious DHCPv6 configuration. However, the ipv6 address autoconfig command on the uplink to the service provider (Ethernet 0/0) causes two events to happen:

• Addresses are autoconfigured on the interface, based on prefixes in RA messages received from the server.
• If received RA messages have the "other configuration" flag set, the interface will attempt to acquire other (for example, nonaddress) configuration from any DHCPv6 servers.

Related Documents

Standards and rfcs, technical assistance.

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

Was this Document Helpful?

Contact Cisco

• (Requires a Cisco Service Contract )

IPv6 - DHCPv6

DHCPv6, or Dynamic Host Configuration Protocol for IPv6 , is a protocol used for assigning IP addresses and other configuration information to devices on a network. It operates similarly to DHCP for IPv4 , but with specific adaptations for the IPv6 architecture. Here are some key points about DHCPv6:

Address Configuration

• Stateful Configuration : DHCPv6 can assign IPv6 addresses dynamically in a stateful manner, meaning it keeps track of the addresses it assigns to devices.
• Stateless Configuration : DHCPv6 can also provide other configuration information (like DNS servers) without assigning an IPv6 address, in what's called stateless address autoconfiguration (SLAAC) .
• DHCPv6 uses ICMPv6 for discovery and solicitation messages, differentiating it from DHCP for IPv4 which uses UDP . This allows devices on an IPv6 network to find DHCPv6 servers and request configuration information.

DHCPv6 Messages

• It involves several types of messages for communication between clients and servers, such as Solicit, Advertise, Request, Confirm, Renew, Rebind, Reply, Release, and Decline.
• Devices are identified using DUIDs (DHCP Unique Identifiers) rather than MAC address es. This is a shift from IPv4’s DHCP reliance on MAC addresses for client identification. DUIDs provide a more flexible and consistent client identifier mechanism.

Prefix Delegation

• DHCPv6 supports Prefix Delegation, which allows routers to obtain IPv6 prefixes from a DHCPv6 server. This is especially useful for configuring networks behind the routers, allowing for automatic subnetting and address assignment without manual configuration.
• Like DHCP for IPv4, DHCPv6 can be susceptible to various security threats, such as unauthorized DHCP servers providing false information. However, DHCPv6 includes support for authentication using keys agreed upon by both the server and client, enhancing security.

Compatibility

• DHCPv6 is necessary because IPv6 addresses are not backward compatible with IPv4 addresses, requiring a separate protocol to handle IPv6 configurations.

Implementation

• The implementation of DHCPv6 is crucial for IPv6 deployment, as it simplifies the management of large-scale networks and supports a broad range of network configuration options.

DHCPv6 plays a critical role in the deployment of IPv6 by providing a robust and flexible mechanism for address assignment and network configuration, supporting both stateful and stateless operations.

https://networklessons.com/ipv6/cisco-dhcpv6-server-configuration/

Links to this page:

• DHCP - DHCPv6 and the default gateway
• DHCP relay agent
• DHCPv6 - determining the IPv6 prefix assigned to an interface
• DHCPv6 lease times on a Cisco IOS device
• DHCPv6 relay agent
• IPv6 - Network and Interface Identifiers
• IPv6 - SLAAC
• IPv6 - ipv6 nd prefix command
• IPv6 global unicast address
• IPv6 stateless DHCP active clients equals zero

• Documentation Home
• Palo Alto Networks
• Live Community
• Knowledge Base

Dynamic IPv6 Addressing on the Management Interface

Next-generation firewall docs.

• Cloud Management of NGFWs
• PAN-OS 10.0 (EoL)
• PAN-OS 10.1
• PAN-OS 10.2
• PAN-OS 11.0
• PAN-OS 11.1 & Later
• Cloud Management and AIOps for NGFW
• PAN-OS 11.1
• PAN-OS 11.2
• PAN-OS 8.1 (EoL)
• PAN-OS 9.0 (EoL)
• A stateful DHCPv6 client, which receives its IPv6 address, prefix length, and other configuration from a DHCPv6 server.
• An IPv6 stateless address autoconfiguration (SLAAC) client, which autogenerates its IPv6 address. A stateless IPv6 address avoids a DHCPv6 server having to store dynamic state information about clients; such avoidance is helpful in environments with a large number of endpoints.
• An Autonomous (A) flag set to 1 tells the firewall to autogenerate a Global Unicast Address (GUA) using SLAAC. The firewall uses the prefix from the prefix options in the RA message, along with the EUI-64 Interface ID of the MGT interface, to create a GUA for the MGT interface. The Interface ID is created from the MAC address of the management interface. (If the flag is set to 0, autoconfiguration isn't allowed on the segment.)
• An Other Configuration (O) flag set to 1 tells the firewall that it can get a DNS server list and a domain name from a stateless DHCPv6 server (but not addressing information). Usually the O flag works with SLAAC autoconfiguration and both the A flag and O flag are set to 1. Currently, there is a known issue with the O flag (stateless DHCPv6), which isn't supported in this release.
• A Managed (M) flag set to 1 tells the firewall to get its IPv6 network parameters (such as its global address, DNS, and a domain name) from a stateful DHCPv6 server. The firewall contacts a DHCPv6 server to request a GUA and the other information. Typically this means that SLAAC autoaddressing isn't allowed on the segment and both the A flag and O flag are set to 0. Currently, there is a known issue that the firewall sends a DHCPv6 Solicit message even when the M flag isn't set.
• Step 1—The firewall sends an RS to the well-known multicast address for all routers (FF02::2).
• Step 2—In response, Router 1 generates an RA with the M-flag set to 1 and the A-flag set to 0, indicating to the firewall that SLAAC isn't allowed on the segment and it must use stateful DHCPv6 for addressing and other configuration.
• Step 3—Upon receipt of the RA, the firewall sets the source IPv6 address of Router 1 as its default gateway. Because the A-flag is set to 0, the firewall does not perform SLAAC.
• Step 4—Based on the M-flag set to 1 in the RA, the firewall sends a DHCPv6 Solicit message to the well-known multicast address for all DHCPv6 agents (FF01::1:2), searching for a DHCPv6 server.
• Step 5—Upon receipt of the Solicit message, the server unicasts a DHCPv6 Advertise message to the link-local address of the firewall.
• Step 6—The firewall knows DHCPv6 service is available and sends a Request for addressing information.
• Step 7—Upon receipt of the Request, the server sends a DHCPv6 Reply containing the GUA and all other information available to assign. (The DNS information is taken from the DHCPv4 server, not the DHCPv6 server.)
• The firewall performs Duplicate Address Detection (DAD) on the GUA it receives to confirm the GUA is unique. If DAD determines that the IPv6 address is a duplicate (whether a SLAAC, DHCPv6, or even a link-local address), the IPv6 address is not seen in the interface.

Recommended For You

© 2024 Palo Alto Networks, Inc. All rights reserved.

Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

ON THIS PAGE

• Using DHCPv6 IA_NA with DHCPv6 Prefix Delegation Overview

DHCPv6 Options in a DHCPv6 Multiple Address Environment

Methods for obtaining addresses for both dhcpv6 prefix delegation and dhcpv6 ia_na, multiple dhcpv6 ia_na and ia_pd requests per client interface, example: configuring a dual stack that uses dhcpv6 ia_na and dhcpv6 prefix delegation over pppoe, wan and lan addressing using dhcpv6 ia_na and dhcpv6 prefix delegation.

You can use DHCPv6 IA_NA to assign a global IPv6 address to the CPE WAN link and DHCPv6 prefix delegation to provide prefixes for use on the subscriber LAN. DHCPv6 IA_NA and DHCPv6 prefix delegation are done in a single DHCPv6 session. If the CPE sends both the IA_NA and IA_PD options in the same DHCPv6 Solicit message, the BNG returns both a single IPv6/128 address and an IPv6 prefix.

When at least one address is successfully allocated, the router creates a subscriber entry and binds the entry to the assigned address. If both addresses are successfully allocated, the router creates a single subscriber entry and binds both addresses to that entry.

Lease Times and Session Timeouts for DHCPv6 IA_NA and DHCPv6 Prefix Delegation

Behavior when cpe sends separate renew requests for ia_na and ia_pd address types.

When you use DHCPv6 IA_NA together with DHCPv6 prefix delegation, note the following about session timeouts and lease times:

A session timeout from AAA has the highest precedence and overrides local pool lease times.

For DHCPv6 local server, the minimum lease time associated with an address pool takes precedence over pools with longer lease times. For example, if a CPE obtains an IA_NA address from a pool with a lease time of 3600, and a prefix from a pool with a lease time of 7200, the lease time returned in the Reply message from the BNG is 3600.

If AAA does not return a session timeout and the address pool does not have a configured lease time, the default setting of 86,400 (one day) is used.

In some networks, the DHCPv6 client CPE device does both of the following:

Initiates negotiation for both the IA_NA and IA_PD address types in a single solicit message.

Sends separate lease renew requests for the IA_NA and the IA_PD and the renew requests are received back-to-back.

Starting in Junos OS Release 17.2R3, 17.4R2, 18.1R3, 18.2R2, and 18.3R1, the jdhcpd process extends the lease for both address types in this situation.

When the reply is received for the first renew request, if a renew request is pending for the second address type, the client stays in the renewing state, the lease is extended for the first IA, and the client entry is updated.

When the reply is received for the second renew request, the lease is extended for the second IA and the client entry is updated again.

In earlier releases, the behavior is different for this situation:

The client transitions to the bound state instead of staying in the renewing state. The lease is extended for the first IA and the client entry is updated.

When the reply is received for the second renew request, the lease is not renewed for the second address type and the reply is forwarded to the client. Consequently, when that lease ages out, the binding for that address type is cleared, the access route is removed, and subsequent traffic is dropped for that address or address prefix.

For dual-stacked clients over the same session (PPP over L2TP LNS, DHCP, or IPoE), enhanced subscriber management does not support configurations where both of the following are true:

The CPE sends separate DHCPv6 solicit messages for the IA_NA and the IA_PD.

The solicit messages specify a type 2 or type 3 DUID (link-layer address).

As a workaround, you must configure the CPE to send a single solicit message for both IA_NA and IA_PD when the other configuration elements are present.

• IPv6 WAN Link Addressing with DHCPv6 IA_NA
• Design 1: IPv6 Addressing with DHCPv6 IA_NA and DHCPv6 Prefix Delegation

In a DHCPv6 environment, DHCPv6 clients can use a single DHCPv6 Solicit message to request multiple addresses (for example, IA_NA address, IA_PD address, or both), as well as the DNS server address (DHCPv6 attribute 23). When a client requests multiple addresses, DHCPv6 uses the following guidelines to determine how options are returned to the client.

DNS server address—Whenever a client requests an IA_PD address (either alone or with an IA_NA address) and also requests a DNS server address, DHCPv6 returns a DNS address only when one is specified in the IA_PD pool. If the IA_PD pool does not include a DNS address, DHCPv6 ignores any DNS address configured in the IA_NA pool.

If the client requests an IA_NA address (but not an IA_PD address) and also a DNS server address, DHCPv6 returns a DNS address if one is configured in the IA_NA pool.

Lease time—DHCPv6 returns the shortest value of the lease times configured in the IA_NA pool, the IA_PD pool, and authd . DHCPv6 uses this value to set the lifetimes and the Renew and Rebind timers.

By default, DHCPv6 local server returns the DNS server address as a global DHCPv6 option. You can override the current default behavior if you want DHCPv6 to return the DNS server address at the suboption level.

• Overriding How the DNS Server Address Is Returned in a DHCPv6 Multiple Address Environment

You can set up the BNG to select global IPv6 addresses to be delegated to the requesting router in one the following ways:

An external source such as a AAA RADIUS server or a DHCP server using the DHCPv6 relay agent.

Dynamic assignment from a local pool of prefixes or global IPv6 addresses that is configured on the BNG

Address assignment for prefix delegation and IA_NA are independent. For example, you can use AAA RADIUS for DHCPv6 IA_NA, and use a local pool for prefix delegation.

Address Pools for DHCPv6 Prefix Delegation and DHCPv6 IA_NA

Using a aaa radius server to obtain ipv6 addresses and prefixes, junos os predefined variable for multiple dhcpv6 address assignment.

You need two separate address pools for prefix delegation and IA_NA. The pool used for IA_NA contains /128 addresses, and the pool for prefix delegation contains /56 or /48 addresses.

You can specify the name of a delegated pool to use for prefix delegation, which means that you do not need to use AAA to obtain the pool name. In this configuration, if you have also specified a pool match order, the specified delegated pool takes precedence.

You can configure pool attributes so that the IA_NA pool and the prefix delegation pool can specify different SIP servers for DNS addresses. DHCPv6 options that the BNG returns to the CPE are based on the pool from which the addresses were allocated. These options that are returned are based on the DHCPv6 Option Request option (ORO), which can be configured globally or within the IA_NA and IA_PD request.

When the BNG needs to obtain a global IPv6 address for the CPE WAN link and a DHCPv6 prefix, it uses the values in one of the following RADIUS attributes:

Framed-IPv6-Prefix —The attribute contains a global IPv6 address and a prefix. A prefix length of 128 is associated with the global IPv6 address. Prefix lengths less than 128 are associated with prefixes.

Framed-IPv6-Pool —The attribute contains the name of an address-assignment pool configured on the BNG, from which the BNG can select a global IPv6 address or an IPv6 prefix to send to the CPE.

Both attributes are sent from the RADIUS server to the BNG in RADIUS Access-Accept messages.

To configure dynamic DHCPv6 address assignment for both DHCPv6 IA_NA and DHCPv6 prefix delegation, use the $junos-subscriber-ipv6-multi-address predefined variable In your dynamic profile. You use this variable in place of the $junos-subscriber-ipv6-address variable, which supports a single IPv6 address or prefix. The $junos-subscriber-ipv6-multi-address variable is applied as a demultiplexing source address, and is expanded to include both the host and prefix addresses.

You include the $junos-subscriber-ipv6-multi-address variable at the [edit dynamic-profile profile-name interfaces interface-name unit logical-unit-number family inet6 demux-source] hierarchy level.

• Configuring an Address-Assignment Pool for Use by DHCPv6 Prefix Delegation
• Configuring an Address-Assignment Pool for Use by DHCPv6 IA_NA

DHCPv6 relay agent supports multiple IA_NA and IA_PD requests within a single DHCPv6 Solicit message. The requests can be any combination of IA_NA and IA_PD addresses, up to a maximum of eight requests. As part of the multiple IA request support, each address lease is assigned its own lease time expiration, independent of the other leases. The use of independent lease timers ensures that when one lease is torn down, the other active leases are maintained. You can use the show dhcpv6 relay binding and show dhcpv6 relay binding detail commands to display the status of the individual lease times.

The DHCPv6 support for multiple IA requests enables you to use prefix delegation to designate blocks of addresses, as described in RFC 3633, IPv6 Prefix Options for DHCPv6 . For example, you might want to delegate multiple address blocks to a customer premises equipment (CPE) router as a means to simplify flow classification and service monetization in your IPv6 environment.

Requirements

Configuration, verification.

This example uses the following hardware and software components:

MX Series 5G Universal Routing Platform

Junos OS Release 11.4 or later

This design uses DHCPv6 IA_NA and DHCPv6 prefix delegation in your subscriber access network as follows:

The access network is PPPoE.

DHCPv6 IA_NA is used to assign a global IPv6 address on the WAN link. The address comes from a local pool that is specified using AAA RADIUS.

DHCPv6 prefix delegation is used for subscriber LAN addressing. It used a delegated prefix from a local pool that is specified using AAA RADIUS.

DHCPv4 is used for subscriber LAN addressing.

DHCPv6 subscriber sessions are layered over an underlying PPPoE subscriber session.

Table 1 describes the configuration components used in this example.

CLI Quick Configuration

Configuring a dhcpv6 local server for dhcpv6 over pppoe, configuring a dynamic profile for the pppoe logical interface, configuring a loopback interface, configuring a vlan demux interface over an ethernet underlying interface, configuring an interface for communication with radius server, specifying the bng ip address, configuring radius server access, configuring radius server access profile, configuring local address-assignment pools.

The following is the complete configuration for this example:

Step-by-Step Procedure

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

To layer DHCPv6 above the PPPoE IPv6 family (inet6), associate DHCPv6 with the PPPoE interfaces by adding the PPPoE interfaces to the DHCPv6 local server configuration. Because this example uses a dynamic PPPoE interface, we are using the pp0.0 (PPPoE) logical interface as a wildcard to indicate that a DHCPv6 binding can be made on top of a PPPoE interface.

To configure a DHCPv6 local server:

Access the DHCPv6 local server configuration.

Create a group for dynamic PPPoE interfaces and assign a name.

The group feature groups a set of interfaces and then applies a common DHCP configuration to the named interface group.

Add an interface for dynamic PPPoE logical interfaces.

From configuration mode, confirm your configuration by entering the show command.

If you are done configuring the device, enter commit from configuration mode.

Create a dynamic profile for the PPPoE logical interface. This dynamic profile supports both IPv4 and IPv6 sessions on the same logical interface.

To configure the dynamic profile:

Create and name the dynamic profile.

Add a routing instance to the profile.

Configure a PPPoE logical interface (pp0) that is used to create logical PPPoE interfaces for the IPv4 and IPv6 subscribers.

Specify $junos-interface-unit as the predefined variable to represent the logical unit number for the pp0 interface. The variable is dynamically replaced with the actual unit number supplied by the network when the subscriber logs in.

Specify $junos-underlying-interface as the predefined variable to represent the name of the underlying Ethernet interface on which the router creates the dynamic PPPoE logical interface. The variable is dynamically replaced with the actual name of the underlying interface supplied by the network when the subscriber logs in.

Configure the router to act as a PPPoE server when a PPPoE logical interface is dynamically created.

Configure the IPv4 family for the pp0 interface. Specify the unnumbered address to dynamically create loopback interfaces. Because the example uses routing instances, assign the predefined variable $junos-loopback-interface .

Configure the IPv6 family for the pp0 interface. Specify the unnumbered address to dynamically create loopback interfaces. Because the example uses routing instances without router advertisement, assign the predefined variable $junos-loopback-interface .

Configure one or more PPP authentication protocols for the pp0 interface.

Enable keepalives and set an interval for keepalives. We recommend an interval of 30 seconds.

To configure a loopback interface:

Create the loopback interface and specify a unit number.

Configure the interface for IPv4.

Configure the interface for IPv6.

To configure a VLAN demux interface over an Ethernet underlying interface:

Configure the underlying Ethernet interface.

Create the VLAN demux interface, and specify a unit number.

Configure the VLAN tags.

Specify the underlying Ethernet interface.

Specify the dynamic profile.

Prevent multiple PPPoE sessions from being created for the same PPPoE subscriber on the same VLAN interface.

(Optional) Specify that you want the demux interface to use Proxy ARP.

To configure the interface:

Create the interface, specify a unit number, and configure the address.

Configure the interface for IPv4 and specify the address.

Specify that Gigabit Ethernet options are not automatically negotiated.

We strongly recommend that you configure the BNG IP address, thereby avoiding unpredictable behavior if the interface address on a loopback interface changes.

To configure the IP address of the BNG:

Access the routing-options configuration.

Specify the IP address or the BNG.

To configure RADIUS servers:

Create a RADIUS server configuration, and specify the address of the server.

Configure the required secret (password) for the server. Secrets enclosed in quotation marks can contain spaces.

Configure the source address that the BNG uses when it sends RADIUS requests to the RADIUS server.

(Optional) Configure the number of times that the router attempts to contact a RADIUS accounting server. You can configure the router to retry from 1 through 16 times. The default setting is 3 retry attempts.

(Optional) Configure the length of time that the local router or switch waits to receive a response from a RADIUS server. By default, the router or switch waits 3 seconds. You can configure the timeout to be from 1 through 90 seconds.

To configure a RADIUS server access profile:

Create a RADIUS server access profile.

Specify the order in which authentication methods are used.

Specify the address of the RADIUS server used for authentication and the server used for accounting.

Configure RADIUS accounting values for the access profile.

Configure three address-assignment pools for DHCPv4, DHCPv6 IA_NA, and DHCPv6 prefix delegation.

To configure the address-assignment pools:

Configure the address-assignment pool for DHCPv4.

Configure the address-assignment pool for DHCPv6 IA_NA.

Configure the address-assignment pool for DHCPv6 prefix delegation.

(Optional) Enable duplicate prefix protection.

Confirm that the configuration is working properly.

Verifying Active Subscriber Sessions

Verifying both ipv4 and ipv6 address in correct routing instance, verifying dynamic subscriber sessions, verifying dhcpv6 address pools used for dhcpv6 prefix delegation, verifying dhcpv6 address bindings, verifying ppp options negotiated with the remote peer.

Verify active subscriber sessions.

From operational mode, enter the show subscribers summary command.

The fields under Subscribers by State show the number of active subscribers.

The fields under Subscribers by Client Type show the number of active DHCP and PPPoE subscriber sessions.

Verify that the subscriber has both an IPv4 and IPv6 address and is placed in the correct routing instance.

From operational mode, enter the show subscribers command.

The Interface field shows that two subscriber sessions are running on the same interface. The IP Address field shows that one session is assigned an IPv4 address, and the second session is assigned an IPv6 address by DHCPv6 IA_NA.

The LS:RI field shows that the subscriber is placed in the correct routing instance and that traffic can be sent and received.

Verify dynamic PPPoE and DHCPv6 subscriber sessions. In this example configuration the DHCPv6 subscriber session should be layered over the underlying PPPoE subscriber session.

From operational mode, enter the show subscribers detail command.

When a subscriber has logged in and started both an IPv4 and an IPv6 session, the output shows the active underlying PPPoE session and the active DHCPv6 session.

The Session ID field for the PPPoE session is 2. The Underlying Session ID for the DHCP session is 2, which shows that the PPPoE session is the underlying session.

Verify the delegated address pool used for DHCPv6 prefix delegation and the length of the IPv6 prefix that was delegated to the CPE.

From operational mode, enter the show subscribers extensive command.

The IPv6 Delegated Address Pool field shows the name of the pool that DHCPv6 used to assign the IPv6 address for this subscriber session.

Display the address bindings in the client table on the DHCPv6 local server.

From operational mode, enter the show dhcpv6 server binding detail command.

The Client IPv6 Address field shows the /128 address that was assigned to the CPE WAN link using DHCPv6 IA_NA.

The Client Pool Name field shows the name of the address pool that was used to assign the Client IPv6 Address .

Verify PPP options negotiated with the remote peer.

From operational mode, enter the show ppp interface interface extensive command.

The output shows the PPP options that were negotiated with the remote peer.

Under IPCP, the Negotiated options field shows the IPv4 local and remote addresses that were negotiated by IPCP.

Under IPV6CP, the Negotiated options field shows the IPv6 local and remote interface identifier that were negotiated by IPv6CP.

Related Documentation

• Subscriber LAN Addressing with DHCPv6 Prefix Delegation
• Designs for IPv6 Addressing in a Subscriber Access Network