10.3 Basic IPv6 functionality protocols
IPv6 uses a number of protocols to support it. Because IPv6 is fundamentally similar to IPv4, some of these protocols will be familiar to you-for example, ICMP, CDP, and DHCP. However, some aspects of IPv6 operation, and indeed some of its greatest strengths, require functional support from protocols not included in the IPv4 protocol suite. Key among them is Neighbor Discovery Protocol (discussed in section 10.2), which provides many functions critical in IPv6 networks. Other protocols, such as DHCP, DNS, and ICMP, will be quite familiar.
10.3.1 Router Advertisement and Router Solicitation
A Cisco IPv6 router begins sending RA messages for each of its configured interface prefixes when the ipv6 unicast-routing command is configured. You can change the default RA interval (200 seconds) using the command ipv6 nd ra-interval. Router advertisements on a given interface include all of the 64-bit IPv6 prefixes configured on that interface. This allows for stateless address autoconfiguration using EUI-64 to work properly. RAs also include the link MTU, hop limits, and whether a router is a candidate default router. IPv6 routers send periodic RA messages to inform hosts about the IPv6 prefixes used on the link and to inform hosts that the router is available to be used as a default gateway. By default, a Cisco router running IPv6 on an interface advertises itself as a candidate default router. If you do not want a router to advertise itself as a default candidate, use the command ipv6 nd ra-lifetime 0. By sending RAs with a lifetime of 0, a router still informs connected hosts of its presence, but tells connected hosts not to use it to reach hosts off the subnet.
At startup, IPv6 hosts can send Router Solicitation (RS) messages to the all-routers multicast address. Hosts do this to learn the addresses of routers on a given link, as well as their various parameters, without waiting for a periodic RA message. If a host has no configured IPv6 address, it sends an RS using the unspecified address as the source. If it has a configured address, it sources the RS from the configured address.
10.3.2 Duplicate Address Detection
IPv6 DAD is a function of neighbor solicitation. When a host performs address autoconfiguration, it does not assume that the address is unique, even though it should be because the seed 48-bit MAC address used in the EUI-64 process should itself be globally unique.
To verify that an autoconfigured address is unique, the host sends an NS message to its own autoconfigured address's corresponding solicited-node multicast address. This message is sourced from the unspecified address, ::. In the Target Address field in the NS is the address that the host seeks to verify as unique. If an NA from another host results, the sending host knows that the address is not unique. IPv6 hosts use this process to verify the uniqueness of both statically configured and autoconfigured addresses.
For example, if a host has autoconfigured an interface for the address 2001:128:1F:633:207:85FF: FE80:71B8, then it sends an NS to the corresponding solicited-node address, FF02::1:FE80:71B8/104. If no other host answers, the node knows that it is okay to use the autoconfigured address.
The method described here is the most efficient way for a router to perform DAD, because the same solicited-node address matches all autoconfigured addresses on the router.
10.3.3 Neighbor Unreachability Detection
IPv6 neighbors can track each other, mainly for the purpose of ensuring that Layer 3 to Layer 2 address mapping remains current, using information determined by various means. Reachability is defined not just as the presence of an advertisement from a router or a neighbor, but further requires confirmed, two-way reachability. However, that does not necessarily mean that a neighbor has to ask another node for its presence and receive a direct reply as a result. The two ways a node confirms reachability are as follows:
A host sends a probe to the desired host's solicited-node multicast address and receives an RA or an NA in response.
A host, in communicating with the desired host, receives a clue from a higher-layer protocol that two-way communication is functioning. One such clue is a TCP ACK.
Note that clues from higher-layer protocols work only for connection-oriented protocols. UDP, for example, does not acknowledge frames and, therefore, cannot be used as a verification of neighbor reachability. In the event that a host wants to confirm another's reachability under conditions where no traffic or only connectionless traffic is passing between these hosts, the originating host must send a probe to the desired neighbor's solicited-node multicast address.
Like ICMP for IPv4, ICMPv6 provides messaging support for IPv6. As you learned in the previous section, ICMPv6 provides all the underlying services for neighbor discovery, but it also provides many functions in error reporting and echo requests.
ICMPv6 is standardized in RFC 2463, which broadly classifies ICMPv6 messages into two groups: error reporting messages and informational messages. To conserve bandwidth, RFC 2463 mandates configurable rate limiting of ICMPv6 error messages. The RFC suggests that ICMPv6 may limit its message rate by means of timers or based on bandwidth. No matter which methods are used, each implementation must support configurable settings for these limits. To that end, Cisco IOS Software implements ICMP rate limiting by setting the minimum interval between error messages and allows credit to build using a token bucket.
To limit ICMPv6 error messages, use the ipv6 icmp error-interval command, in global configuration mode. The default interval is 100 ms, and the default token-bucket size is 10 tokens. With this configuration, a new token (up to a total of 10) is added to the bucket every 100 ms. Beginning when the token bucket is full, a maximum of 10 ICMPv6 error messages can be sent in rapid succession. Once the token bucket empties, the router cannot send any additional ICMPv6 error messages until at least one token is added to the bucket.
10.3.5 Unicast Reverse Path Forwarding
In IPv6, unicast RPF helps protect a router from DoS attacks from spoofed IPv6 host addresses. When you configure IPv6 unicast RPF by issuing the ipv6 verify unicast reverse-path command on an interface, the router performs a recursive lookup in the IPv6 routing table to verify that the packet came in on the correct interface. If this check passes, the packet in question is allowed through; if not, the router drops it.
Cisco IOS Software gives you the option of defining a sort of trust boundary. This way, a router can verify only selected source IPv6 addresses in the unicast RPF check. To do this, configure an access list on the router and call it with the ipv6 verify unicast reverse-path command.
DNS for IPv6 is quite similar to DNS for IPv4; it provides resolution of domain names to IPv6 addresses. One key difference is the name used for DNS records for IPv6 addresses. In IPv4, these are known as A records; in IPv6, RFC 1886 cleverly terms them AAAA records, because IPv6 addresses are four times longer (in bits) than IPv4 addresses. RFC 1886 and RFC 2874 are both IPv6 DNS extensions. RFC 2874 calls IPv6 address records A6 records. Today, RFC 1886 is most commonly used; however, RFC 2874 expects to eventually obsolete RFC 1886.
IPv6 DNS extensions also provide the inverse lookup function of PTR records, which maps IPv6 addresses to host names.
One alternative to static IPv6 addressing, namely stateless autoconfiguration, was covered earlier. Another alternative also exists: stateful autoconfiguration. This is where DHCPv6 comes in. DHCPv6 is specified in RFC 3315.
Two conditions can cause a host to use DHCPv6:
The host is explicitly configured to use DHCPv6 based on an implementation-specific setting.
An IPv6 router advertises in its RA messages that it wants hosts to use DHCPv6 for addressing. Routers do this by setting the M flag (Managed Address Configuration) in RAs.
To use stateful autoconfiguration, a host sends a DHCP request to one of two well-known IPv6 multicast addresses on UDP port 547:
FF02::1:2, all DHCP relay agents and servers
FF05::1:3, all DHCP servers
The DHCP server then provides the necessary configuration information in reply to the host on UDP port 546. This information can include the same types of information used in an IPv4 network, but additionally it can provide information for multiple subnets, depending on how the DHCP server is configured.
To configure a Cisco router as a DHCPv6 server, you first configure a DHCP pool, just as in IPv4 DHCP. Then, you must specifically enable the DHCPv6 service using the ipv6 dhcp server pool-name interface command.