Chapter 31. Implementing IPv6 Addressing on Hosts
This chapter covers the following exam topics:
1.0 Network Fundamentals
1.12 Configure, verify, and troubleshoot IPv6 addressing
1.13 Configure and verify IPv6 Stateless Address Auto Configuration
1.14 Compare and contrast IPv6 address types
1.14.f Autoconfiguration
IPv6 hosts act like IPv4 hosts in many ways, using similar ideas, similar protocols, and even similar or identical commands for the same purpose. At the same time, IPv6 sometimes takes a much different approach than does IPv4, using a much different solution with a new protocol or command. For example:
Similar to IPv4, IPv6 hosts use a unicast address, prefix length (mask), default router, and DNS server.
Similar to IPv4, IPv6 uses a protocol to dynamically learn the MAC address of other hosts in the same LAN-based subnet.
Unlike IPv4, IPv6 hosts use the Neighbor Discovery Protocol (NDP) for many functions, including the functions done by IPv4’s ARP.
Similar to IPv4, IPv6 hosts can use DHCP to learn their four primary IPv6 settings.
Unlike IPv4, IPv6 supports a dynamic address assignment process other than DHCP, called Stateless Address Auto Configuration (SLAAC).
This chapter focuses on the four primary IPv6 settings on hosts: the address, prefix length, default router address, and DNS server address. However, to understand how hosts dynamically learn those addresses, this chapter begins its first major section devoted to NDP, which plays a key role in several IPv6 processes. The middle section of the chapter then focuses on how hosts dynamically learn their IPv6 settings, with both DHCP and SLAAC. The final major section of this chapter looks at the tools to verify a host’s IPv6 settings, many of which use the same commands used for IPv4.
“Do I Know This Already?” Quiz
Take the quiz (either here, or use the PTP software) if you want to use the score to help you decide how much time to spend on this chapter. The answers are at the bottom of the page following the quiz, and the explanations are in DVD Appendix C and in the PTP software.
1. PC1, PC2, and Router R1 all connect to the same VLAN and IPv6 subnet. PC1 wants to send its first IPv6 packet to PC2. What protocol or message will PC1 use to discover the MAC address to which PC1 should send the Ethernet frame that encapsulates this IPv6 packet?
a. ARP
b. NDP NS
c. NDP RS
d. SLAAC
2. PC1 and Router R1 connect to the same VLAN and IPv6 subnet. The user of PC1 pings the IPv6 address of a host that sits at a remote site, so that the packets flow through R1, PC1’s default router. PC1 does not statically configure its default router setting. Which of the following answers lists a protocol or message that PC1 could have used when trying to learn what IPv6 address to use as its default router?
a. EUI-64
b. NDP NS
c. DAD
d. NDP RS
3. Which of the following pieces of information does a router supply in an NDP Router Advertisement (RA) message? (Choose two answers.)
a. Router IPv6 address
b. Host name of the router
c. IPv6 prefix(es) on the link
d. IPv6 address of DHCP server
4. Host PC1 dynamically learns its IPv6 settings using Stateless Address Auto Configuration (SLAAC). Which one of PC1’s settings is most likely to be learned from the stateless DHCPv6 server?
a. Host address
b. Prefix length
c. Default router address
d. DNS server address(es)
5. Host PC1 dynamically learns its IPv6 settings using Stateless Address Auto Configuration (SLAAC). Think about the host’s unicast address as two parts: the prefix and the interface ID. Which of the answers list a way that SLAAC learns or builds the value of the interface ID portion of the host’s address? (Choose two answers.)
a. Learned from a DHCPv6 server
b. Built by the host using EUI-64 rules
c. Learned from a router using NDP RS/RA messages
d. Built by the host using a random value
6. Three routers connect to the same VLAN and IPv6 subnet. All three routers have sent NDP RA messages, in reply to various IPv6 hosts’ NDP RS messages, asking to learn about the available IPv6 routers in the subnet. A network engineer issues the show ipv6 neighbors command on R1. Which of the answers best describes the kind of NDP information held in this output?
a. IPv6 neighbors (both routers and hosts) plus their MAC addresses, without noting which are routers
b. IPv6 neighbors (both routers and hosts) plus their MAC addresses, and also noting which are routers
c. IPv6 routers, with no information about nonrouters, with no MAC address info
d. IPv6 routers, with no information about nonrouters, with MAC address info
Answers to the “Do I Know This Already?” quiz:
Foundation Topics
The Neighbor Discovery Protocol
IPv6 hosts need to know several important IPv6 settings that mirror the settings needed on IPv4 hosts: an address, the associated prefix length (mask equivalent), the default router address, and the DNS server address(es). Figure 31-1 shows those four concepts for PC1 on the left.
Note that of the four settings, three are unicast IPv6 addresses. The PC’s own IPv6 address is typically a global unicast or unique local unicast, as are the PC’s references to the DNS servers. However, because the default router must be locally reachable, the default router setting typically refers to the router’s link-local address.
Neighbor Discovery Protocol (NDP) defines several different functions related to IPv6 addressing, as follows:
SLAAC: When using Stateless Address Auto Configuration (SLAAC), the host uses NDP messages to learn the first part of its address, plus the prefix length.
Router Discovery: Hosts learn the IPv6 addresses of the available IPv6 routers in the same subnet using NDP messages.
Duplicate Address Detection: No matter how a host sets or learns its IPv6 address, the host waits to use the address until the host knows that no other host uses the same address. How does a host detect this problem? Using NDP messages, of course, through a process called Duplicate Address Detection (DAD).
Neighbor MAC Discovery: After a host has passed the DAD process and uses its IPv6 address, a LAN-based host will need to learn the MAC address of other hosts in the same subnet. NDP replaces IPv4’s ARP, providing messages that replace the ARP Request and Reply messages.
The rest of this section steps through each of these four functions to varying degrees. Note that this section defers most of the discussion of the SLAAC process until later in the chapter, focusing more on the core NDP functions in this section.
Discovering Routers with NDP RS and RA
For IPv6, ICMPv6 replaces the ICMP protocol. As with ICMP for IPv4, ICMPv6 includes a Request and Echo Reply message for use by the ping command. ICMPv6 also includes all the NDP messages, like the two messages in this list. These two messages enable hosts to learn addressing and subnet information from any routers in the subnet.
Router Solicitation (RS): This message is sent to the “all-IPv6-routers” local-scope multicast address of FF02::2 so that the message asks all routers, on the local link only, to identify themselves.
Router Advertisement (RA): This message, sent by the router, lists many facts, including the link-local IPv6 address of the router. When unsolicited, it is sent to the all-IPv6-hosts local-scope multicast address of FF02::1. When sent in response to an RS message, it flows back to either the unicast address of the host that sent the RS or to the all-IPv6-hosts address FF02::1.
For example, Figure 31-2 shows how host PC1 can learn R1’s link-local address. The process is indeed simple, with PC1 first asking and R1 replying.
Note
IPv6 allows multiple prefixes and multiple default routers to be listed in the RA message; Figure 31-2 just shows one of each for simplicity’s sake.
IPv6 does not use broadcasts, but it does use multicasts. In this case, the RS message flows to the all-routers multicast address (FF02::2) so that all routers will receive the message. It has the same good effect as a broadcast with IPv4, without the negatives of a broadcast. In this case, only IPv6 routers will spend any CPU cycles processing the RS message. The RA message can flow either to the unicast IPv6 address of PC1 or to the all-nodes FF02::1 address.
Note that while Figure 31-2 shows how a host can ask to learn about any routers, routers also periodically send unsolicited RA messages, even without an incoming RS. When routers send these periodic RA messages, they basically advertise details about IPv6 on the link. In this case, the RA messages flow to the FF02::1 all-nodes IPv6 multicast address.
Discovering Addressing Info for SLAAC with NDP RS and RA
The NDP RS and RA messages give hosts a means to ask routers to supply information; they also give routers a means to supply that information to hosts. In short, RS/RA can act as a basic query/response protocol (or solicitation/advertisement, if you prefer the words from the RS and RA acronyms).
What could an IPv6 router know that an IPv6 host might want to learn? Figure 31-2 shows one fact learned through the RS and RA messages—namely, the IPv6 address of the IPv6 router. Another useful fact is the prefix and prefix length used on the local link. Routers know the prefix and prefix length because of the typical ipv6 address command on each interface; that command lists the prefix length and enough information for the router to calculate the associated IPv6 prefix. A host can learn these details using the RS and RA message exchange, as shown in Figure 31-3.
As it turns out, the SLAAC process, used by hosts to dynamically learn an IPv6 address, uses the prefix/prefix length information learned from the router using RS and RA messages. The later section “Using Stateless Address Auto Configuration” discusses the entire process.
Discovering Neighbor Link Addresses with NDP NS and NA
NDP defines a second pair of matched solicitation and advertisement messages: the Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages. Basically, the NS acts like an IPv4 ARP request, asking the host with a particular unicast IPv6 address to send back a reply. The NA message acts like an IPv4 ARP Reply, listing that host’s MAC address.
The process of sending the NS and NA messages follows the same general process as RS and RA: The NS message asks for information, and the NA supplies the information. The most obvious difference is that while RS/RA focuses on information held by routers, NS/NA focuses on information that could be held by any IPv6 host.
Neighbor Solicitation (NS): This message asks a host with a particular IPv6 address (the target address) to send back an NA with its MAC address listed. The NS message is sent to the solicited-node multicast address associated with the target address, so the message is processed only by hosts whose last six hex digits match the address that is being queried.
Neighbor Advertisement (NA): This message lists the sender’s address as the target address, along with the matching MAC address. It is sent back to the unicast address of the host that sent the original NS message. In some cases, a host sends an unsolicited NA, in which case the message is sent to the all-IPv6-hosts local-scope multicast address FF02::1.
Note
With NDP, the word neighbor refers to the fact that the devices will be on the same data link; for example, the same VLAN.
Figure 31-4 shows an example of how a host (PC1) uses an NS message to learn the MAC address used by another host. The NDP NS and NA messages replace the IPv4 ARP protocol in that it lets hosts discover the link-layer address of other IPv6 hosts on the same data link. (IPv6 refers to hosts on the same data link as simply on-link.) The NS message lists a target IPv6 unicast address, with the implied question: “What is your link address?” The NA message, in this example sent back to the original host that asked the question, lists that link address. Figure 31-4 shows an example.
At Step 1 of this particular example, PC1 sends the solicitation to find PC2’s MAC address. PC1 first looks in its NDP neighbor table, the equivalent of the IPv4 ARP cache, and does not find the MAC address for IPv6 address 2001:DB8:1111:1::22. So, at Step 1, PC1 sends the NDP NS message to the matching solicited-node multicast address for 2001:DB8:1111:1::22 or FF02::1:FF00:22. Only IPv6 hosts whose address ends with 00:0022 will listen for this solicited-node multicast address. As a result, only a small subset of hosts on this link will process the received NDP NS message.
At Step 2, PC2 reacts to the received NS message. PC2 sends back an NA message in reply, listing PC2’s MAC address. PC1 records PC2’s MAC address in PC1’s NDP neighbor table.
Note
To view a host’s NDP neighbor table, use these commands: (Windows) netsh interface ipv6 show neighbors; (Linux) ip -6 neighbor show; (Mac OS) ndp -an.
Discovering Duplicate Addresses Using NDP NS and NA
The NDP NS/NA messages also require hosts to do an important check to avoid using duplicate IPv6 addresses. IPv6 uses the Duplicate Address Detection (DAD) process before using a unicast address to make sure that no other node on that link is already using the address. If another host already uses that address, the first host simply does not use the address until the problem is resolved.
The term DAD refers to the function, but the function uses NDP NS and NA messages. Basically, a host sends an NS message, but it lists the address the host wants to use as the target address. If no duplicate exists, no other host should reply with an NA. However, if another host already uses that address, that host will reply with an NA, identifying a duplicate use of the address. Figure 31-5 shows an example in which a duplicate is detected.
Figure 31-5 shows an example in which both PC1 and PC2 attempt to use the same IPv6 address. PC2 is already using the address, and PC1 uses DAD before using the address. The figure shows the following steps:
1. PC1, before using address 2001:DB8:1111:1::11, must use DAD.
2. PC1 sends an NS message, listing the address PC1 now wants to use (2001:DB8:1111:1::11) as the target.
3. PC2 receives the NS, sees what PC2 already uses as its own address, and sends back an NA.
4. PC1, on receiving the NA message for its own IPv6 address, realizes a duplicate address exists.
Hosts do the DAD check for each of their unicast addresses, link-local addresses included, both when the address is first used and each time the host’s interface comes up.
NDP Summary
This chapter explains some of the more important functions performed by NDP. NDP does more than what is listed in this chapter, and the protocol allows for addition of other functions, so NDP might continue to grow. For now, use Table 31-2 as a study reference for the four NDP features discussed here.
Dynamic Configuration of Host IPv6 Settings
By the time IPv6 was created back in the early to mid-1990s, the world had a decade or two of experience with IPv4. That experience with IPv4 had already shown the need for hosts to dynamically learn their IPv4 settings, including the host’s IPv4 address. By the time IPv6 was being created, DHCP for IPv4 had already become the preferred IPv4 solution to allow hosts to dynamically learn their IPv4 address and other settings.
DHCP worked well for IPv4, so creating a version of DHCP for IPv6 (DHCPv6) made perfect sense. However, while DHCP has many advantages, one possible disadvantage is that DHCP requires a server that keeps information about each host (client) and its address. The designers of IPv6 wanted an alternative dynamic address assignment tool, one that did not require a server. The answer? SLAAC.
This second major section of the chapter first looks at DHCPv6, followed by SLAAC.
Dynamic Configuration Using Stateful DHCP and NDP
DHCP for IPv6 (DHCPv6) gives an IPv6 host a way to learn host IPv6 configuration settings, using the same general concepts as DHCP for IPv4. The host exchanges messages with a DHCP server, and the server supplies the host with configuration information, including a lease of an IPv6 address, along with prefix length and DNS server address information.
Note
The DHCP version is not actually version 6; the name just ends in “v6” in reference to the support for IPv6.
More specifically, stateful DHCPv6 works like the more familiar DHCP for IPv4 in many other general ways, as follows:
DHCP clients on a LAN send messages that flow only on the local LAN, hoping to find a DHCP server.
If the DHCP server sits on the same LAN as the client, the client and server can exchange DHCP messages directly, without needing help from a router.
If the DHCP server sits on another link as compared to the client, the client and server rely on a router to forward the DHCP messages.
The router that forwards messages from one link to a server in a remote subnet must be configured as a DHCP Relay Agent, with knowledge of the DHCP server’s IPv6 address.
Servers have configuration that lists pools of addresses for each subnet from which the server allocates addresses.
Servers offer a lease of an IP address to a client, from the pool of addresses for the client’s subnet; the lease lasts a set time period (usually days or weeks).
The server tracks state information, specifically a client identifier (often based on the MAC address), along with the address that is currently leased to that client.
DHCPv6 has two major branches of how it can be used: stateful DHCPv6 and stateless DHCPv6. Stateful DHCPv6 works more like the DHCPv4 model, especially related to that last item in the list. A stateful DHCPv6 server tracks information about which client has a lease for what IPv6 address; the fact that the server knows information about a specific client is called state information, making the DHCP server a stateful DHCP server.
Stateless DHCP servers do not track any per-client information. The upcoming section “Using Stateless Address Auto Configuration” discusses how stateless DHCPv6 servers have an important role when a company decides to use SLAAC.
Differences Between DHCPv6 and DHCPv4
While stateful DHCPv6 has many similarities to DHCPv4, many particulars differ as well. Figure 31-6 shows one key difference: Stateful DHCPv6 does not supply default router information to the client. Instead, the client host uses the built-in NDP protocol to learn the routers’ IPv6 addresses directly from the local routers.
DHCPv6 also updates the protocol messages to use IPv6 packets instead of IPv4 packets, with new messages and fields as well. For example, Figure 31-7 shows the names of the DHCPv6 messages, which replace the DHCPv4 Discover, Offer, Request, and Acknowledgment (DORA) messages. Instead, DHCPv6 uses the Solicit, Advertise, Request, and Reply messages.
The four DHCPv6 messages work in two matched pairs with the same general flow as the similar DHCPv4 messages. The Solicit and Advertise messages complete the process of the client searching for the IPv6 address of a DHCPv6 server (the Solicit message) and the server advertising an address (and other configuration settings) for the client to possibly use (the Advertise message). The Request and Reply messages let the client ask to lease the address, with the server confirming the lease in the Reply message.
DHCPv6 Relay Agents
For enterprises that choose to use stateful DHCPv6, often the DHCP server sits at a central site, far away from many of the clients that use the DHCPv6 server. In those cases, the local router at each site must act as a DHCP relay agent.
The concepts of DHCPv6 relay work like DHCPv4 relay, as discussed in the section “Supporting DHCP for Remote Subnets with DHCP Relay,” in Chapter 20, “DHCP and IP Networking on Hosts.” The client sends a message that only flows inside the local LAN. The router then changes the source and destination IP address, forwarding the packet to the DHCP server. When the server sends a reply, it actually flows to an address on the router (the relay agent), which changes the addresses in that packet as well.
The differences for IPv6 become more obvious when you look at some of the IPv6 addresses used in DHCPv6 messages, like the Solicit message used to lead off a DHCPv6 flow. As shown in Figure 31-8, the client uses the following addresses in the solicit message:
Source of link-local: The client uses its own link-local address as the source address of the packet.
Destination address of “all-DHCP-agents” FF02::1:2: This link-local scope multicast address is used to send packets to two types of devices: DHCP servers and routers acting as DHCP relay agents.
With a link-local scope multicast destination address, the Solicit message sent by a host would flow only on the local LAN. Figure 31-8 shows some of the particulars of how R1, acting as a DHCPv6 relay agent, assists DHCPv6 clients like host A to deliver DHCPv6 packets to the DHCPv6 server.
Focus first on Step 1, in which host A, the DHCPv6 client, builds and sends its DHCPv6 Solicit message. The message flows from host A’s link-local address to the all-DHCP-agents multicast address FF02::1:2. With a link-local scope multicast destination address, the Solicit message sent by a host would flow only on the local LAN.
Step 2 shows the results of R1’s work as the DHCPv6 relay agent. R1 listens for incoming DHCPv6 messages sent to FF02::1:2, and processes the message sent by host A. R1 changes the destination IPv6 address of the packet to match the DHCPv6 server on the right. R1 also changes the source IPv6 address to be one of R1’s IPv6 addresses. With DHCPv6, by default R1 uses the address of its outgoing interface (S0/0/0) as the source IPv6 address, which is slightly different from the DHCPv4 relay agent. R1 then forwards the Solicit message to the server.
The return DHCPv6 messages from the server to the client (not shown in the figure) flow first to the relay agent router’s IPv6 address—in other words, to 2001:DB8:1111:2::1 in this case. The relay agent then converts the destination address of those messages as well and forwards the DHCPv6 messages to the client’s link-local address.
Example 31-1 shows the DHCPv6 relay agent configuration for R1 in Figure 31-8. The top of the example shows the ipv6 dhcp relay interface subcommand, with reference to the IPv6 address of the DHCPv6 server. The bottom of the figure shows the output of the show ipv6 interface command, which confirms that R1 is now listening for multicasts sent to the all-DHCP-agents multicast address FF02::1:2.
Example 31-1 Configuring Router R1 to Support Remote DHCPv6 Server
interface GigabitEthernet0/0
ipv6 dhcp relay destination 2001:DB8:1111:3::8
R1# show ipv6 interface g0/0
GigabitEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::FF:FE00:1
No Virtual link-local address(es):
Description: to SW1 port F0/1
Global unicast address(es):
2001:DB8:1111:1::1, subnet is 2001:DB8:1111:1::/64 [EUI]
Joined group address(es):
FF02::1
FF02::2
FF02::A
FF02::1:2
FF02::1:FF00:1
! Lines omitted for brevity
Using Stateless Address Auto Configuration
The stateful nature of DHCPv4, as well as its newer cousin stateful DHCPv6, causes some challenges. Someone has to configure, administer, and manage the DHCP server(s). The configuration includes ranges of IP addresses for every subnet. Then, when a host (client) leases the address, the server notes which client is using which address. All these functions work, and work well, but the reliance on a stateful DHCP server requires some thought and attention from the IT staff.
IPv6’s SLAAC provides an alternative method for dynamic IPv6 address assignment—without needing a stateful server. In other words, SLAAC does not require a server to assign or lease the IPv6 address, does not require the IT staff to preconfigure data per subnet, and does not require the server to track which device uses which IPv6 address.
The term SLAAC refers to both a specific part of how a host learns one IPv6 setting—its IPv6 address—plus the overall process of learning all four key host IPv6 settings (address, prefix length, default router, and DNS server addresses). This next topic begins by looking at the tasks done by SLAAC related to the IPv6 address. Then the text looks at the overall process that uses SLAAC to find all four host settings—a process that uses NDP as well as stateless DHCP.
Building an IPv6 Address Using SLAAC
When using SLAAC, a host does not lease its IPv6 address, or even learn its IPv6 address. Instead, the host learns part of the address—the prefix—and then makes up the rest of its own IPv6 address. Specifically, a host using SLAAC to choose its own IPv6 address uses the following steps:
1. Learn the IPv6 prefix used on the link, from any router, using NDP RS/RA messages.
2. Choose its own IPv6 address by making up the interface ID value to follow the just-learned IPv6 prefix.
3. Before using the address, first use DAD to make sure that no other host is already using the same address.
Figure 31-9 summarizes the first two steps, while noting the two most common ways a host completes the address. Hosts can use EUI-64 rules, as discussed in Chapter 30’s section “Generating a Unique Interface ID Using Modified EUI-64.” Alternatively, the host can use a process to choose a random number.
Combining SLAAC with NDP and Stateless DHCP
When using SLAAC, a host actually makes use of three different tools to find its four IPv6 settings, as noted in Figure 31-10. SLAAC itself focuses on the IPv6 address only. The host then uses NDP messages to learn both the prefix length and the IPv6 addresses of the available routers on the link. Finally, the host makes use of stateless DHCP to learn the IPv6 addresses of any DNS servers.
Stateless DHCP solves the last piece of this puzzle when also using SLAAC. The host needs to know the DNS servers’ IPv6 addresses. The solution? Use DHCPv6. However, the host, acting as the DHCPv6 client, asks the server for only the DNS server addresses, and not for a lease of an IPv6 address.
So, why does the world need to call this service stateless DHCPv6? The DHCP server with stateless DHCPv6 has far less work to do, and the network engineer has far less administrative work to do. With stateless DHCPv6, the DHCPv6 server
Needs simple configuration only, specifically a small number of addresses for the DNS servers, but nothing else
Needs no per-subnet configuration: no subnet list, no per-subnet address pools, no list of excluded addresses per subnet, and no per-subnet prefix lengths
Has no need to track state information about DHCP leases—that is, which devices lease which IPv6 address—because the server does not lease addresses to any clients
Table 31-3 summarizes the key comparison points between stateless DHCP and stateful DHCP.
Troubleshooting IPv6 Addressing
This third and final major section of the chapter examines a few commands to verify and troubleshoot IPv6 addressing configuration on hosts. Specifically, this section examines the host’s IPv6 settings and then looks at the usual commands to test whether a host can send packets: ping and traceroute.
Note that this section lists some commands on different host OSs. As usual, the goal of listing host commands is to give a general idea of the information that can be viewed on a host. However, keep in mind that this and other chapters do not attempt to show each variation of every networking command on every OS; instead, the goal is to reinforce the ideas discussed earlier in the chapter.
Verifying Host IPv6 Connectivity from Hosts
Most end-user OSs support a convenient way to look at IPv6 settings from the graphical user interface. In some cases, all four of the key IPv6 host settings can be on the same window, whereas in other cases, seeing all the settings might require navigation to multiple windows or tabs in the same window.
As an example, Figure 31-11 shows a window from Mac OS X, which lists three of the four IPv6 host settings. The one missing setting, the DNS server setting, is in another tab (as shown near the top of the image).
Take a moment to look at the details in Figure 31-11’s image. The image shows the IPv4 settings at the top, as being learned with DHCP. The lower half of the window shows the IPv6 settings as having been learned “Automatically,” which means that the host will use either stateful DHCP or SLAAC. In this case, the host used SLAAC to give itself two IPv6 addresses inside the same 2001:DB8:1111:1::/64 subnet—one using EUI-64 rules and one with a random interface ID. (Note that IPv6 host logic includes many details not discussed in this chapter, including the reasons why a host might use two addresses rather than one.)
Hosts also support a range of commands to check the same information. For IPv6 settings, many OSs use familiar commands: ipconfig on Windows OSs and ifconfig on Linux and Mac OS. Example 31-2 shows an ifconfig command from the same Mac used to create Figure 31-11 for comparison. In particular, if you look at the two highlighted fields, you can see the EUI-64 interface ID that resulted from using this host’s MAC address.
Example 31-2 Sample ifconfig Command from a Mac
WOair$ ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 10:93:e9:06:a4:b6
inet6 fe80::1293:e9ff:fe06:a4b6%en0 prefixlen 64 scopeid 0x4
inet 192.168.1.163 netmask 0xffffff00 broadcast 192.168.1.255
inet6 2001:db8:1111:1:1293:e9ff:fe06:a4b6 prefixlen 64 autoconf
inet6 2001:db8:1111:1:50c0:2cf5:a699:d7ba prefixlen 64 autoconf temporary
media: autoselect
status: active
Beyond simply checking the four key IPv6 settings on the host, testing the installation of a new host also requires testing whether the host has connectivity to the rest of the internetwork, using the usual tools: the ping and traceroute commands.
As for the commands themselves, some OSs (notably Microsoft Windows variants and Cisco routers and switches) let you use the same ping and traceroute commands used with IPv4. Some other OSs require a different command, like the ping6 and traceroute6 commands used with Mac OS and Linux. (The upcoming examples show both variations.)
As for the output of the ping and traceroute commands, most people who understand the IPv4 version of these commands need no coaching whatsoever to understand the IPv6 version. The output is mostly unchanged compared to the IPv4 equivalents, other than the obvious differences with listing IPv6 addresses. For comparison, upcoming Examples 31-3 and 31-4 show sample output, using the internetwork displayed in Figure 31-12.
Example 31-3 shows three ping commands, taken from PC1, a Linux host. (Linux happens to replace the older commands with the ping6 and traceroute6 commands.) The first two commands show IPv6 pings, the first to R1’s LAN IPv6 address, followed by PC1 pinging PC2’s IPv6 address. The final command shows an IPv4 ping for comparison.
Example 31-3 The ping6 Command from PC1, for R1 and PC2
Master@PC1:$ ping6 2001:db8:1111:1::1
PING 2001:db8:1111:1::1 (2001:db8:1111:1::1) 56 data bytes
64 bytes from 2001:db8:1111:1::1: icmp_seq=1 ttl=64 time=1.26 ms
64 bytes from 2001:db8:1111:1::1: icmp_seq=2 ttl=64 time=1.15 ms
^C
--- 2001:db8:1111:1::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001 ms
rtt min/avg/max/mdev = 1.156/1.210/1.263/0.062 ms
Master@PC1:$ ping6 2001:db8:1111:3::22
PING 2001:db8:1111:3::22 (2001:db8:1111:3::22) 56 data bytes
64 bytes from 2001:db8:1111:3::22: icmp_seq=1 ttl=64 time=2.33 ms
64 bytes from 2001:db8:1111:3::22: icmp_seq=2 ttl=64 time=2.59 ms
64 bytes from 2001:db8:1111:3::22: icmp_seq=3 ttl=64 time=2.03 ms
^C
--- 2001:db8:1111:3::22 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003 ms
rtt min/avg/max/mdev = 2.039/2.321/2.591/0.225 ms
! An IPv4 ping next, for comparison - ping of PC2 from PC1
Master@PC1:$ ping 10.1.3.22
PING 10.1.3.22 (10.1.3.22) 56 data bytes
64 bytes from 10.1.3.22: icmp_seq=1 ttl=64 time=2.45 ms
64 bytes from 10.1.3.22: icmp_seq=2 ttl=64 time=2.55 ms
64 bytes from 10.1.3.22: icmp_seq=3 ttl=64 time=2.14 ms
^C
--- 10.1.3.22 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2014 ms
rtt min/avg/max/mdev = 2.04/2.318/2.604/0.224 ms
Example 31-4 shows a traceroute6 command on PC1, finding the route to PC2. The output mirrors the style of output for most IPv4 traceroute commands, other than the obvious difference of listing IPv6 addresses. Note that the output lists R1’s G0/0 IPv6 address, then R2’s S0/0/1 IPv6 address, and then finally PC2’s address to end the output.
Example 31-4 The traceroute6 Command from PC1, for PC2
Master@PC1:$ traceroute6 2001:db8:1111:3::22
traceroute to 2001:db8:1111:3::22 (2001:db8:1111:3::22) from 2001:db8:1111:1::11,
30 hops max, 24 byte packets
1 2001:db8:1111:1::1 (2001:db8:1111:1::1) 0.794 ms 0.648 ms 0.604 ms
2 2001:db8:1111:2::2 (2001:db8:1111:2::2) 1.606 ms 1.49 ms 1.497 ms
3 2001:db8:1111:3::22 (2001:db8:1111:3::22) 2.038 ms 1.911 ms 1.899 ms
Verifying Host Connectivity from Nearby Routers
For router verification commands for IPv6, some IPv6 features use the exact same command as with IPv4, but some substitute “ipv6” for “ip.” And in some cases, particularly with functions that do not exist in IPv4 or have changed quite a bit, routers support brand-new commands. This section looks at a couple of router commands useful to verify IPv6 host connectivity, some old and some new for IPv6.
First, for the more familiar commands. Cisco routers and switches support the ping and traceroute commands with the same basic features for IPv6 as with IPv4. For the standard version of the commands, the commands accept either an IPv4 or an IPv6 address as input. For the extended versions of these commands, the first prompt question asks for the protocol. Just type ipv6, instead of using the default of ip, and answer the rest of the questions.
Of course, an example helps, particularly for the extended commands. Example 31-5 begins with an extended IPv6 ping, from R1 to PC2, using R1’s G0/0 interface as the source of the packets. The second command shows a standard IPv6 traceroute from R1 to PC2.
Example 31-5 Extended ping and Standard traceroute for IPv6 from Router R1
R1# ping
Protocol [ip]: ipv6
Target IPv6 address: 2001:db8:1111:3::22
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands? [no]: yes
Source address or interface: GigabitEthernet0/0
UDP protocol? [no]:
Verbose? [no]:
Precedence [0]:
DSCP [0]:
Include hop by hop option? [no]:
Include destination option? [no]:
Sweep range of sizes? [no]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:1111:3::22, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:1111:1::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
R1# traceroute 2001:db8:1111:3::22
Type escape sequence to abort.
Tracing the route to 2001:DB8:1111:3::22
1 2001:DB8:1111:2::2 4 msec 0 msec 0 msec
2 2001:DB8:1111:3::22 0 msec 4 msec 0 msec
Another way to verify host settings from a router is to look at the router’s neighbor table. All IPv6 hosts, routers included, keep an IPv6 neighbor table: a list of all neighboring IPv6 addresses and matching MAC addresses. Basically, this table replaces the IPv4 ARP table, and it contains the content learned with NDP NS and NA messages.
One way to verify whether a neighboring host is responsive is to find out whether it will send back an NDP NA when the router sends it an NDP NS (to discover the host’s MAC address). To do so, the router could clear its neighbor table (clear ipv6 neighbor) and then ping a host on some connected interface. The router will first need to send an NDP NS, and the host must send an NDP NA back. If the router shows that host’s MAC address in the neighbor table, the host must have just replied with an NDP NA. Example 31-6 shows a sample of an IPv6 neighbor table, from Router R2 in upcoming Figure 31-13, using the show ipv6 neighbors command.
Example 31-6 The show ipv6 neighbors Command on Router R2
R2# show ipv6 neighbors
IPv6 Address Age Link-layer Addr State Interface
FE80::11FF:FE11:1111 0 0200.1111.1111 STALE Gi0/0
FE80::22FF:FE22:2222 1 0200.2222.2222 STALE Gi0/0
2001:DB8:1111:3::22 0 0200.2222.2222 REACH Gi0/0
FE80::FF:FE00:3333 1 0200.0000.3333 DELAY Gi0/0
2001:DB8:1111:3::33 0 0200.1111.1111 REACH Gi0/0
2001:DB8:1111:3::3 0 0200.0000.3333 REACH Gi0/0
Finally, routers can also list information about the available routers on a LAN subnet, which impacts the connectivity available to hosts. As a reminder, routers send NDP RA messages to announce their willingness to act as an IPv6 router on a particular LAN subnet. Cisco routers watch for RA messages received from other routers (routers send periodic unsolicited RA messages, by the way). The show ipv6 routers command lists any other routers, but not the local router.
As an example, consider the topology shown in Figure 31-13. R1 is the only IPv6 router on the LAN on the left, so R1 does not hear any RA messages from other routers on that LAN subnet. However, R2 and R3, connected to the same subnet, hear NDP RAs from each other. Example 31-7 lists the output of the show ipv6 routers command on R1 (with no routers listed) and R2 (with one router listed) for comparison’s sake.
Example 31-7 Listing All Routers with the show ipv6 routers Command
! No routers listed by this command on R1
R1# show ipv6 routers
R1#
! The next command happens on R2 - one router (R3) listed
R2# show ipv6 routers
Router FE80::FF:FE00:3333 on GigabitEthernet0/0, last update 0 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500
HomeAgentFlag=0, Preference=Medium
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:1111:3::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
Finally, one last thought related to commands on hosts themselves: The host can, of course, list its own NDP information. Interestingly, most hosts list the neighbor table and then just flag which entries also happen to be routers (the ones that also sent an NDP RA at some point).
Example 31-8 shows an example, this time from a host using Mac OS. Of the two highlighted entries, the first, with the flags field (“Flgs”) listing an “R,” is a router that formerly sent an RA to announce itself. The second highlighted entry is for a host, so the letter “R” is not listed under the “Flgs” (flags) heading.
Example 31-8 Example NDP Neighbor Table, Mac OS X
WOAir$ ndp -an
Neighbor Linklayer Address Netif Expire St Flgs Prbs
::1 (incomplete) lo0 permanent R
2001:db8:1111:1::1 5c:d9:98:59:b3:fc en0 1s D R
2001:db8:1111:1:1293:e9ff:fe06:a4b6 10:93:e9:6:a4:b6 en0 5s R
Chapter Review
One key to doing well on the exams is to perform repetitive spaced review sessions. Review this chapter’s material using either the tools in the book, DVD, or interactive tools for the same material found on the book’s companion website. Refer to the “Your Study Plan” element for more details. Table 31-4 outlines the key review elements and where you can find them. To better track your study progress, record when you completed these activities in the second column.
Stateless Address Auto Configuration (SLAAC)
Duplicate Address Detection (DAD)
Command References
Tables 31-6, 31-7, and 31-8 list configuration and verification commands used in this chapter, respectively. As an easy review exercise, cover the left column in a table, read the right column, and try to recall the command without looking. Then repeat the exercise, covering the right column, and try to recall what the command does.
Table 31-6 Chapter 31 Configuration Command Reference
Table 31-7 Chapter 31 EXEC Command Reference
Table 31-8 Chapter 31 Host Command Reference