Addressing IPv6 Hosts

Throughout this section there have been clues as to how hosts, and specifically interfaces, obtain their IPv6 addresses. The three methods by which an IPv6 host can obtain an IP address include stateless autoconfiguration, statefulautoconfiguration, or manually.
Stateless autoconfiguration is the easiest IPv6 address allocation method available. When used, stateless autoconfiguration uses the network prefix information contained in router advertisements as the first 64 bits of its addresses, and then appends its MAC address in EUI-64 format as the interface portion. This method is especially useful in environment where a DHCP server is neither configured nor present. On local networks without a router, a host using stateless autoconfiguration will use the link local network prefix and append to this its EUI-64 format MAC address.

For a higher degree on control over which addresses IPv6 interfaces use, statefulautoconfiguration can use another addressing method. When an IPv6 node sends out its router solicitation message at startup, the router can be configured to include whether a DHCP server should be used in its reply. If a DHCP server should be used, the node will used attempt to find a DHCP server through the use of multicasts. This is again an improvement over IPv4, where clients attempting to lease an IP address from a DHCP server use broadcast messages.

Finally, IPv6 addresses can also be configured manually. While generally not suggested for individual hosts, certain network nodes (such as routers) will require explicit configuration. Given the length and complexity of IPv6 addresses, it is generally best to use either stateful or stateless autoconfiguration for hosts to reduce potential errors and keep things simple.

Note: You may be curious about how DNS works in an IPv6 environment. Not surprisingly, the method is very similar to DNS in IPv4. However, when a host is attempting to obtain the IPv6 address associated with a fully qualified domain name (FQDN) or hostname, it sends a DNS query looking for the AAAA record associated with the host, rather than the standard A record used to resolve IPv4 addresses.

IPv6 Discovery Processes

On an IPv6 network, a number of important functions happen using discovery processes. These include the discovery of neighboring devices and routers, as well as the maximum transmission unit (MTU) that is supported between a source and destination host. Some of these concepts are similar to ones found on an IPv4 network, while others represent new ways of dealing with traditional IPv4 configuration issues.

Neighbor discovery is the process by which an IPv6 node discovers the link-layer address of systems that it needs to communicate with on the local subnet, and is the method by which a node keeps track of local routers. This neighbor discovery process uses a new version of ICMP – ICMPv6. Ultimately, multicasts and anycasts are used for neighbor discovery functions on an IPv6 network. For example, recall the ARP function on an IPv4 network; a host would send out a broadcast requesting that the host with the specified IP send back its MAC address. In IPv6, ICMP multicasts are used to send out a request looking for the link-layer address associated with a known IPv6 address. This helps to reduce some of the traditional issues associated with broadcast traffic negatively impacting network performance.

Router discovery is a feature of IPv6 that allows an IPv6 node to discover the routers connected to its local link network. Although a similar feature exists in IPv4, it is rarely used with most administrators relying upon manually configured gateway addresses instead. Two main types of router discovery messages are used on IPv6 networks – router solicitations, and router advertisements. A router advertisement is a multicast message periodically sent by an IPv6 router that allows a host to gather valuable information about the network. For example, a router advertisement could contain information about the address configuration method that should be used, the IP prefixes in use on the network (or any changes to them), which router should be considered the default router, and more. Router advertisements will be looked at in more detail in the section on addressing hosts.

In contrast, a node sends out a router solicitation method when it does not have a configured IP address at start up. The purpose of this multicast is to gather information about how the node should be configured, but without the need to wait for the next router advertisement. For example, the result of a router solicitation message could be a reply from a local router specifying that the host should auto-configure its IPv6 address, or perhaps that it should use DHCP instead.

Another very important discovery process on IPv6 networks is maximum transmission unit (MTU) discovery. In previous articles in the CCNA series, we looked at how a router was capable of fragmenting an IPv4 packet when the next network on the path to a destination used a smaller MTU size – for example, when forwarding data from a Token Ring segment to an Ethernet segment. While this method helped to avoid some of the issues associated with interconnecting different network types, it also slowed down the communication process, since a router was not only responsible for reframing and making forwarding decisions, but also fragmenting packets and subsequently reframing them all as well. In IPv6, routers no longer fragment any packets. Instead, the sending node uses a process referred to as MTU discovery to determine the larger possible MTU that is supported between itself and the destination host. If any fragmentation needs to take place, it must be done on the sending node – IPv6 routers stay out of this process completely, leading to greater routing efficiency.

To understand how MTU discovery works, consider the figure below. In it, we see a source host attempting to discover the biggest MTU possible between itself and the destination. In this case, the MTU between Host A and its local router is 1500 bytes, the MTU between Routers A and B is 1400, and the MTU between Router B and the destination is 1200.


To discover the MTU, Host A will sent out a packet to Host B attempting to use its 1500 byte MTU. At Router A, an ICMPv6 error message (packet too big) will be sent back saying that an MTU of 1400 should be used. Host A will then send out another packet with an MTU of 1400, which will be designated as too big by Router B, with a maximum MTU of 1280 specified. Since Host B is connected to a network with an MTU of 1280, Host A now knows that this is the MTU that it should use to communicate with Host B. Although this process may seen cumbersome, it’s worth noting that IPv6 specifies a minimum MTU size of 1280 bytes, and that 1500 is usually the default MTU configured on most internetworking equipment.

IPv6 Multicast Addresses

Must like the reserved Class D address space in IPv4, IPv6 dedicates some of its address space to multicast traffic, albeit a much larger portion. If you recall, a multicast transmission is one in which a single transmission is received by many systems, or a one-to-many technique. In IPv6, multicasts use the prefix FF00::/8. Common examples of multicast addresses used in IPv6 include the destination address FF02::1, which is used to send a multicast to all hosts on a given subnet. Similarly, the multicast address FF02::2 is used to communicate with all routers on a subnet. Later in this series you’ll learn more about how some routing protocols use multicasts to facilitate inter-router communication.

IPv6 Anycast Addresses

IPv6 also defines an entirely new type of address and transmission, known as an “anycast”. Simply put, an anycast address is a standard IPv6 global address that is assigned to a number of different interfaces on different systems. When a packet is destined for an anycast address, the “closest” device to the sender will process the packet. In this case, the concept of “closest” is defined by the routing protocols in use on the network. At this time, anycast addresses can only be used as a destination address, cannot be used as a source address, and are only assigned to routers. A common use in IPv6 is to apply the same anycast address to all routers interfaces that connect to the same subnet. The potential uses of anycast transmission methods are being explored further by the IETF, and the technique is already finding its way into new technologies like Mobile IP.

IPv6 Unicast Addresses

Like in the world of IPv4, a unicast transmission represents data meant for a single destination address only. However, IPv6 uses a few different types of unicast addresses for different purposes. These include global, site-local, link-local, and IPv4-mapped IPv6 addresses. Each is outlined below.

Global Unicast Address. Very similar in function to an IPv4 unicast address such as, these addresses include a global routing prefix, a subnet ID, and an interface ID as outlined earlier.

Site-Local Unicast Address. Very similar in function to the IPv4 private address space that includes ranges like, these addresses are meant for internal communications and are not routable on the public Internet. Site-local addresses start with the prefix FEC0::/10, and then include the appropriate subnet ID and interface ID as outlined earlier.

Link-Local Unicast Address. For certain communications that are meant to stay within a given broadcast domain, IPv6 uses link-local addresses. These addresses are used for features like stateless autoconfiguration, which will be looked at shortly. Link-local addresses start with the prefix FE80::/10, and then include an interface ID. Note that since these addresses never communicate outside of their local subnet, the subnet ID is not included.

IPv4-mapped IPv6 Address. For environments that are transitioning between IPv4 and IPv6, IPv6 provides another type of unicast address known as an IPv4-mapped IPv6 address. This addressing method is used on systems running both an IPv4 and IPv6 protocol stack. When used, a system will include its current 32-bit IPv4 address in the low-order bits of an IPv6 address, preceded by 16 bits set to FFFF, and the remaining bits set to 0. For example, a host with the IPv4 address would use the address of 0:0:0:0:0:FFFF:

IPv6 Subnetting and Address Allocation

If you’ve been working with IPv4 for some time now, you may already be familiar with subnet masks and how they work to segment the IPv4 address space into subnets. In the IPv6 world, subnetting works somewhat differently, relying on a dedicated field within an IPv6 address. While the next section will look at the breakdown of the IPv6 address space in more detail, for now it’s enough to say that an IPv6 unicast address includes a 16-bit field known as the Subnet ID or Site-Level Aggregator. Because this field is 16 bits in length, it gives companies the option of configuring up to 65535 individual subnets. The structure of an IPv6 global address is outlined below.

Tip: Remember that in IPv6, the Subnet ID (also know as the Site Level Aggregator field) is used to define individual subnets.

As part of developing the IPv6 address space, a number of the “problems” associated with IPv4 were taken into account. For example, IPv6 provides a much more organized hierarchical addressing scheme, addressing some of the limitations and problems associated with routing in the IPv4 world. The figure below outlines the major elements of a global IPv6 unicast address. To gain a better understanding of IPv6, it is worth knowing a little more about how these addresses are allocated in the real world.


First and foremost, the first three bits of the global IPv6 address space are set to use the prefix 2000::/3 (remember, this is not the decimal number 2000, but a series of four hexadecimal digits). Like the CIDR notation you are already familiar with, the /3 represents a mask that defines a portion of the address space. In this case, all IPv6 addresses that start with the binary values 001 (2000::/3) through 111 (E000::/3) are global addresses (with the exception of FF00::/8, which are addresses reserved for multicasts). Ultimately, these global addresses need to have a 64-bit interface identifier, as displayed in the previous figure. The 64-bit interface identifier is usually created by taking an interface’s MAC address (which is 48 bits in length) and wedging another 16-bit hexadecimal string (FFFE) between the OUI (first 24 bits) and unique serial number (last 24 bits) of the MAC address. This format is known as extended universal identifier (EUI) 64 format, or EUI-64 for short. When all is said and done, the last 64 bits of an IPv6 global address represent an interface.

So what are the other parts of the address space used for? Well, so far we know that the last 64 bits of an IPv6 address represent a unique interface, while the 16 bits that precede that represent the Subnet ID. As such, the first 48 bits define what is known as the Global Routing Prefix, and since the global address space starts at 2000::/3, that leaves 45 bits to break up the Global Routing Prefix itself.

Without getting into too much detail here, the IPv6 address space is allocated by the Internet Assigned Numbers Authority (IANA). The IANA assigns addresses to the various registries, such as the American Registry for Internet Numbers (ARIN) in the Americas. A registry is given a /16 portion of the address space, such as the 2001:0400::/16 address space allocated to ARIN. From this allocated space, a registry such as ARIN would begin granting address space to ISPs with a /32 prefix. Then, individual ISPs would allocate this address space to organizations using a /48 prefix.

Once a company has been granted their address in the /48 space, they can begin to allocate this address space internally, segmenting the space into smaller subnets or networks by using the 16-bit Subnet ID field. From there, hosts are addressed using the remaining 64 bits of the address space as outlined earlier.

As if it we not enough that IPv6 introduces a whole new addressing scheme, this version of IP also introduces a new concept in terms of how hosts are individually addressed. For example, in the world of IPv4, a host usually had a single IP address assigned to it. In the world of IPv6, however, a host is assigned multiple types of addresses on a per-interface basis. These addresses include different types of unicast, multicast, and anycast addresses. One that you may find conspicuously absent is the famous broadcast – in fact, you might be happy to know that IPv6 doesn’t support broadcasts at all.

IPv6 Address Formats

As mentioned in my last article, an IPv6 address is 128 bits in length, represented in hexadecimal. Much like a MAC address, an IPv6 address is broken down into 2-byte (16-bit) sections separated by a colon; the major difference being that an IPv6 address includes 8 of these sections rather than 3 with a MAC address. In fact, the standard configuration of an IPv6 address actually uses a system’s MAC address as part of the interface ID of a host, as I’ll explain shortly. The address below shows an example of a full 128-bit IPv6 address:


The first thing to recognize about an IPv6 address is that it can actually be compressed quite easily. For example, in the address above, each 2-byte section that contains only 0s can be reduced to a single 0. By the same token, any 2-byte section that begins with a 0 can also have that leading 0(s) dropped. In other words, in compressed form the address just considered would be represented as:


Although this is a little better, there is still an even easier way to represent an IPv6 address. Because the IPv6 address space is so large, there’s a good change that you’re likely to find many 0s in any given address. So, in cases where more than more than one successive field contains 0s only, you can represent it with double colons (::) in the address. For example, the compressed address 2031:0:130D:0:0:08D0:875D:130A could be represented as:


When an IPv6 system comes across this double colon (::) within an address, it knows that it should include as many 0s as necessary to get the address back to 128 bits. However, it’s very important to note than the double colons can only be included once within a given address – if it were included more than once, a system couldn’t possible know where all the 0s were to be placed in the expanded address.

Tip: Remember that double colons (::) can be used as placeholders for contiguous 0 fields in an IPv6 address, but only once within any given address.

In some cases, using the pair of colons makes an address very small indeed. For example, the loopback address in IPv6 is 0000:0000:0000:0000:0000:0000:0000:0001. By using the double colon arrangement just learned, this address can also be identified as:


Overall, IPv6 addressing is probably neither easier nor harder than what you’ve come to know and love with IPv4 – it’s simply different. As with anything new, it will just take a little time to understand and appreciate this new addressing format.

While this article gives you an introduction to IPv6, we’re just getting started. In my next CCDA article I’ll walk you through how subnetting occurs in this address space, and we’ll explore different IP address allocation and transmission methods. Stay tuned!

IPv6 Addressing and Subnetting

It’s easy to be a little intimidated when you come across an IPv6 address for the first time in its fully expanded form. First of all, at 128 bits in length, an IPv6 address is a full four times longer (in bits) than its IPv4 equivalent. Because of their length, IPv6 addresses are represented in hexadecimal rather than the common dotted decimal notation you are familiar with from IPv4. However, before you start worrying about endlessly typing (and calculating) hexadecimal characters on each and every host on your network, it’s worth noting that IPv6 includes a variety of methods to make address deployment easier for administrators, features that I’ll cover in the IPv6 operation section below.

Beyond handling addresses differently, IPv6 also changes the method by which a network is subnetted. If anything, this method is actually simpler than with IPv4, because an IPv6 address includes a section to define a subnet number directly within the address itself. Once you understand where that field is, determining the subnet to which a host belongs is as easy as just reading and matching the number listed.

In this section I’ll walk you through some of the basic of IPv6 addressing and subnetting, including how IPv6 addresses are formatted and represented, how subnets are determined, how the address space itself is allocated, and the different types of addresses and transmission methods that exist.

Introduction to IPv6

Before getting into the technical details of this new version of IP, a simple question must be answered – why does the world need a new version of IP at all? There are many answers to this question, but the most basic reason involves the rapid depletion of the IPv4 address space. If you’ll recall from earlier in this chapter, IPv4 uses 32-bit addressing, and this limits the total number of IP addresses available for issue. When the Internet Protocol was first defined, nobody envisioned the phenomenal growth that defines the Internet we know today. As such, what was originally considered an almost endless supply of address space is now challenged as increasingly greater numbers of devices are connected to the Internet. Consider examples like cellular phones, PDAs, and other embedded systems, and it’s easy to see how the need for more IP address space is upon us.

Note: Talking about IPv6 begs a simple question – whatever happened to IPv5? The answer to that is that IPv5 is actually defined, although for a different purpose. IPv5 defines an experiment protocol that was originally developed to provide quality of service (QoS) features on IPv4 networks. You don’t need to know anything about IPv5 for the CCDA exam, but hopefully this helps to clear up what might have been a nagging thought. To that end, it’s also an interesting little piece of tech trivia!

A number of techniques have been developed and implemented to help slow down the need to deploy a new version of IP, and of these, network address translation (NAT) is clearly the most popular. Earlier in this chapter we also looked at the three ranges of IP addresses set aside for private addressing. While this technique has reduced the need for public IP addresses, it is still not a proper solution, and does little to address the foreseeable growth of the Internet in the longer term. Quite simply, a larger IP address space is required, and IPv6 addresses this issue with a 128-bit address space. At this time, a 128-bit address space would be capable of providing more than a thousand IPv6 addresses for each man, woman, and child on the planet.

Managing Changes to DHCP with NETSH

How many times have you been approached by the Network Engineering Group with the news that the internal IP scheme needs to be changed or that VLAN’s are going to be implemented on all switching equipment? The first will require some configuration, but the second can mean large amounts of work to create and configure the new scopes and scope options needed to complement the additional subnets.

The DHCP MMC snap-in can definitely facilitate this procedure; however, the NETSH utility offers a method to script modifications to DHCP scopes automatically. For those of you who are still building your VBScript, WMI, and ADSI scripting skills, don’t fret. This is good old-fashioned command line work and doesn’t require knowledge of objects, methods, components, etc.

The NETSH utility has many different functional parameters within the DHCP context alone. As there are far too many options to cover at one time, this guide will focus on the following common administrative tasks in making changes to DHCP scopes that can be accomplished with NETSH:

  1. Dumping scopes and configurations from and existing DHCP server into a text file.
  2. Creating a new scope.
  3. Defining the range of the scope.
  4. Adding options to the scope.
  5. Assigning reservations for IP addresses.
  6. Listing authorized DHCP servers and authorizing DHCP servers.

Dumping Existing Scopes and Configurations

Getting your configuration in a text file is a great method to obtain as much or as little dhcp information as needed in a single document without navigating around the MMC. The following example run from the command line will dump all information for the scope from the DHCP server into a text file call test.txt. Note – You may also specify the DHCP server by name. For example: \\DHCP-SVR01.

C:\>netsh -c dhcp server scope dump > c:\test.txt

The first few lines of output will resemble the following:

# Changed the current scope context to scope.Dhcp Server add scope "ScopeA" "First Scope"
Dhcp Server Scope set state 1

# ============================================================
#  Start Add Ipranges to the Scope, Server
# ============================================================

All lines with the hash mark (#) are ignored as input similar to the REM statement used in batch files. The two lines beginning with Dhcp Server are actual commands that can be edited to change information and then the file can be used as an input script which we will cover later in this work.

Creating a new scope

To create a new scope we will use one of the lines in the above example to create a scope for the network ID For this example, the first non-commented line is copied to notepad and then the file is saved as C:\dhcp.txt.

Next, from the command line we run C:\>netsh exec c:\dhcp.txt. This creates and activates the new scope as shown below. Note – The scope does not have any Property Options set at this time, hence the blue information icon.

Defining the range of the scope

In order for the clients to lease IP’s, we must obviously assign a range from which leases will be distributed. This is done as follows in our script:

Dhcp Server Scope add iprange
Dhcp Server Scope add excluderange

Note – that an exclusion range is included in the example to prevent a range of IP addresses from being assigned to the clients.

As we are executing these commands in steps from our script, we will save the lines above to C:\range.txt. Going back to the command line, we now run C:\>netsh exec c:\range.txt which adds the ranges to the scope as shown below in the MMC:

Adding options to the scope

Now that the scope is created, we need to add some options for the clients to better define their DHCP leases. Note – Normally, these lines would be included in the script (dhcp.txt) underneath the line that defines the range of the scope and actually run in the previous step. Since it is activated upon creation, clients that might lease IP addresses from this scope would need the defined options at the time of lease. This has been broken into steps in this article for subject demonstration. To create a scope that was deactivated initially, the following line would need to be added after the first line in the script:

Dhcp Server Scope set state 0

This example will add the standard options: router (gateway), DNS servers, and lease expiration to the scope. All possible options can be scripted, but are beyond the scope of this example. It is possible to get the syntax for all options for scripts by creating a dump file at the server level instead of the scope level. The syntax for the three options we will use is as follows in the script file:

Dhcp Server Scope set optionvalue 3 IPADDRESS ""
Dhcp Server Scope set optionvalue 6 IPADDRESS "" ""
Dhcp Server Scope set optionvalue 51 DWORD "691200"

The first line sets the router for the scope. This is the gateway the clients will use to leave the defined network. The second line assigns DNS servers to the client leases and can include as many as needed. The third line in this example assigns the expiration for the lease. In this case 8 days expressed in seconds (691200 seconds/60 = 11520 minutes/60 = 192 hours/24 = 8 days). Again, the changes can be verified in the MMC.

Note – The lease expiration is not viewable in this screen as it is a property of the scope and not an option. This may be viewed by right-clicking on the scope and selecting Properties.

Assigning reservations to the scope

To assign the same IP to a client whenever the lease is renewed, we can define reservations via the netsh script.  As we are using multiple steps to create the scope in this example, we will use the following syntax and save the file as C:\reserve.txt.

Dhcp Server Scope add reservedip 00043c40fb6a SVR01
Dhcp Server Scope add reservedip 0600ba34f50c SVR02
Dhcp Server Scope add reservedip 02003b5d80ca SVR03

In this example, we are working on server in scope The number at the end of the line is the MAC (Media Access Control) address of the NIC card. This ensures that whenever this NIC requests a lease renewal, it will always get the same IP. The name on the end is simply for labeling the reservation in DHCP, it has no effect on the client. We now execute the script file with the following syntax from the command line: C:\>netsh exec c:\reserve.txt. Again, we can verify the results in the MMC.

Note – I have run into intermittent issues with reservation client types where the reservation will sometimes be assigned a lease type of BOOTP instead of DHCP. This can be forced by adding another entry to the end of each line of the script specifying any of the following options [BOOTP | DHCP | BOTH] as needed.

Listing and authorizing DHCP servers in Active Directory

It is possible to verify and list all the authorized DHCP servers in Active Directory from the command line using the following syntax: C:\netsh dhcp show server. This allows you to view all authorized servers to ensure that an over-eager administrator hasn’t added an unnecessary server to the network.

You may also authorize a DHCP server in AD remotely with the following command:

C:\ netsh dhcp add server

This one can be extremely handy if you want to hand off the job of creating the DHCP scopes and/or server to a junior admin. As Enterprise rights are needed to authorize the server, the work could be verified before going into production and then authorized remotely from the command line. Note – Remember that it can take a DHCP server 15 minutes to authorize so if it doesn’t show up immediately, give it a little while to process.

Bringing it all together

This has been broken into steps for better demonstration; however, all of the steps can be combined into a single script after you are comfortable with the syntax. The completed script would look like the following:

Dhcp Server add scope "ScopeA" "First Scope"
Dhcp Server Scope add iprange
Dhcp Server Scope add excluderange
Dhcp Server Scope set optionvalue 3 IPADDRESS ""
Dhcp Server Scope set optionvalue 6 IPADDRESS "" ""
Dhcp Server Scope set optionvalue 51 DWORD "691200"
Dhcp Server Scope add reservedip 00043c40fb6a SVR01
Dhcp Server Scope add reservedip 0600ba34f50c SVR02
Dhcp Server Scope add reservedip 02003b5d80ca SVR03
Dhcp Server Scope set state 1

This would all be saved to a single file and run using the C:\>netsh exec filename.txt command from the command line.

Netsh is a very powerful command line tool with MANY other options and uses. The syntax can be tricky but after a little practice, you’ll find that it simplifies several mundane administrative tasks.