A sender creates a packet with an anycast address as the destination address and forwards the packet to its nearest router. The router routes the packet to the nearest anycast interface—the closest device or interface that shares that address. In a WAN scope, the nearest interface is found according to the measure of the metric of the routing protocol. In a LAN scope, the nearest interface is found according to the first neighbor that is learned about.
Anycast addresses are allocated from the unicast address space and have the same format as unicast addresses, so they are indistinguishable from unicast addresses. To devices that are not configured for anycast, these addresses appear as unicast addresses. When a unicast address is assigned to more than one interface—thus turning it into an anycast address—the nodes to which the address is assigned must be explicitly configured to use and know that the address is an anycast address.
The idea of anycast in IP was proposed in 1993; however, there is little experience with widespread anycast usage to date. Only a few anycast addresses are currently assigned, including the router-subnet anycast and the Mobile IPv6 home agent anycast.
A source can use anycast addresses to control the paths across which traffic flows. An example of anycast use in a Border Gateway Protocol (BGP) multihomed network is when a customer has multiple ISPs and multiple connections to each one. The customer can configure a different anycast address for each ISP, and configure the same anycast address for each router of a given ISP. The source device can choose which ISP to send the packet to; however, the routers along the path determine the closest router by which that ISP can be reached using the IPv6 anycast address.
Another use for an anycast address is when multiple routers are attached to a LAN. These routers can have the same IPv6 anycast address so that distant devices only need to identify the anycast address; intermediate devices choose the best path to reach the closest entry point to that LAN.
IPv6 Multicast Addresses
As described in Chapter 9, "Implementing IP Multicast," a multicast address identifies a group of interfaces; traffic sent to a multicast address travels to multiple destinations at the same time. An interface may belong to any number of multicast groups. Multicasting is extremely important to IPv6, because it is at the core of many IPv6 functions and it is a replacement for broadcast.
The format of an IPv6 multicast address is illustrated in Figure 10-10. IPv6 multicast addresses are defined by the prefix FF00::/8. The second octet of the address defines the lifetime (flag) and the scope of the multicast address, as follows:
The flag parameter is equal to 0 for a permanent, or well-known, multicast address. The flag is equal to 1 for a temporary multicast address.
The scope parameter is equal to 1 for the interface scope (loopback transmission), 2 for the link scope (similar to unicast link-local scope), 3 for the subnet-local scope where subnets may span multiple links, 4 for the admin-local scope (administratively configured), 5 for the site-local scope, 8 for the organizational scope (multiple sites), and E for the global scope.
IPv6 Multicast Address Structure
For example, a multicast address starting with FF02::/16 is a permanent multicast address with a link-local scope. There is no TTL field in IPv6 multicast packets because the scoping is defined inside the address.
The multicast group ID consists of the lower 112 bits of the multicast address.
The multicast addresses FF00:: to FF0F:: have the flag set to 0 and are reserved. Within that range, the following are some example assigned addresses (there are many more assignments made; assignments are tracked by IANA):
FF02::1—"All nodes" on a link (link-local scope)
FF02::2—"All routers" on a link
FF02::9—"All routing information protocol (RIP) routers" on a link
FF02::1:FFXX:XXXX—Solicited-node multicast on a link, where the XX:XXXX is the rightmost 24 bits of the corresponding unicast or anycast address of the node. Neighbor solicitation messages are sent on a local link when a node wants to determine the link-layer address of another node on the same local link, similar to the Address Resolution Protocol (ARP) in IPv4; this process is illustrated in the example following these bullets.
FF05::101—"All Network Time Protocol (NTP) servers" in the site (site-local scope). (The site-local multicast scope has an administratively assigned radius and has no direct correlation to the now deprecated site-local unicast prefix of FEC0::/10.)
Solicited-node multicast addresses are used in IPv6 for address resolution of an IPv6 address to a MAC address on a LAN segment. In very rare cases, the rightmost 24 bits of the unicast address of the target will not be unique on a link, but this will not cause a problem, as illustrated by an example using the devices in Figure 10-11:
Node A has IPv6 address 2001:DB8:200:300:400:500:1234:5678.
Node B has IPv6 address 2001:DB8:200:300:400:500:AAAA:BBBB, and would therefore have solicited-node multicast address FF02:0:0:0:0:1:FFAA:BBBB, which can also be written as FF02::1:FFAA:BBBB.
Node C has IPv6 address 2001:DB8:200:300:400:501:AAAA:BBBB, and would therefore have solicited-node multicast address FF02::1:FFAA:BBBB. Note that this is the same as node B's solicited-node multicast address.
Network for IPv6 Solicited Node Multicast Address Example
When Node A desires to exchange packets with Node B, Node A sends a neighbor discovery (solicitation) packet to the solicited-node multicast address of B, FF02::1:FFAA:BBBB. The packet contains, in addition to other data, the full IPv6 address that Node A is looking for, 2001:DB8:200:300:400:500:AAAA:BBBB; this is called the target address.
Both node B and node C are listening to the same solicited-node multicast address, so they both receive and process the packet. Node B sees that the target address inside the packet is its own and responds with a neighbor advertisement that includes its MAC address. Meanwhile, Node C sees that the target address inside the packet is not its own and does not respond.
In this manner, nodes can have the same solicited-node multicast address on-link, but not cause neighbor discovery or solicitation process to malfunction.
Stateless Autoconfiguration
| Key Point | Stateless Autoconfiguration A router on a local link can send (either periodically or upon a host's request) network information, such as the 64-bit prefix of the local link network and the default route, to all the nodes on the local link. Hosts can autoconfigure themselves by appending their IPv6 interface identifier (in EUI-64 format) to the local link 64-bit prefix. |
This process is illustrated in Figures 10-12, 10-13, and 10-14, and results in a full 128-bit address that is usable and guaranteed to be globally unique.
A PC Solicits a Router for Network Information
A Router Advertises Network Information
A PC Configures Itself Based on the Router Advertisement
In Figure 10-12, a PC sends a router solicitation, with a source address of :: and a destination address of FF02::2, the all routers multicast address, to request a prefix for stateless autoconfiguration. In Figure 10-13, the router replies with a router advertisement, with a source address of the router's link-local address and a destination address of FF02::1, the all nodes multicast address. In Figure 10-14, the PC configures itself. A process called duplicate address detection (DAD) detects and avoids duplicate addresses.
Stateless autoconfiguration allows devices to "plug-and-play," to connect themselves to the network without any configuration and without any servers (such as DHCP servers). This key IPv6 feature enables deployment of new devices on the IPv6 Internet, such as cellular phones, wireless devices, home appliances, and home networks.
DHCP Version 6 (DHCPv6), an updated version of DHCP for IPv4, can also be used to provide IPv6 addresses to devices. Stateless DHCPv6 is a concept (introduced in February 2004) that strikes a middle ground between stateless autoconfiguration and the thick-client approach of the stateful DHCPv6. Stateless DHCPv6 is also called DHCP-lite. For more details of stateless DHCPv6, refer to RFC 3736, Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6.
IPv6 Mobility
Mobility is a very important feature in networks today. The Mobile IPv6 protocol, defined in RFC 3775, Mobility Support in IPv6, allows IPv6 nodes to remain reachable while they are moving about the IPv6 Internet, as illustrated in Figure 10-15.
IPv6 Mobility Allows Nodes to Roam and Still Be Connected
| Key Point | IPv6 Mobility Ensures Mobile Nodes Remain Connected Each IPv6 mobile node is always identified by its home address, regardless of where it is. When it is away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. |
In IPv6, mobility is built in, which means that any IPv6 node can use it as needed. In IPv4, however, mobility is a new function that must be added as nodes require it.
IPv6's routing headers make Mobile IPv6 much more efficient for end nodes than Mobile IPv4; a new "mobility" extension header has been created. Mobility takes advantage of IPv6's flexibility. For example, the binding of the home address of a mobile node with a care-of address for that mobile node uses the destination options header, support of which is mandatory for every IPv6 device.
IPv6 mobility is different from IPv4 mobility in several ways, including the following:
The IPv6 address space enables Mobile IPv6 deployment in any environment.
Because of the vast IPv6 address space, foreign agents (routers on the networks other than the node's home network) are no longer required.
The network infrastructure does not need to be upgraded to allow Mobile IPv6 nodes. The care-of address can be a global IPv6 routable address for all mobile nodes.
The Mobile IPv6 model takes advantage of some of the benefits of the IPv6 protocol itself. Examples include option headers, neighbor discovery, and autoconfiguration.
In many cases, triangle routing is eliminated, because Mobile IPv6 route optimization allows mobile nodes to communicate directly with other nodes. Support for route optimization is a fundamental part of the protocol, rather than a nonstandard set of extensions. Support is also integrated into Mobile IPv6 for allowing route optimization to coexist efficiently with routers that perform ingress filtering. Mobile IPv6 route optimization can operate securely even without prearranged security associations. It is expected that route optimization can be deployed on a global scale between all mobile nodes and correspondent nodes.
Mobile nodes work transparently even with other nodes that do not support mobility (as is done in IPv4 mobility).
The dynamic home agent address discovery mechanism in Mobile IPv6 returns a single reply to the mobile node. The directed broadcast approach used in IPv4 returns separate replies from each home agent.
Most packets sent to a mobile node while it is away from home in Mobile IPv6 are sent using an IPv6 routing header rather than IP encapsulation, reducing the amount of overhead compared to Mobile IPv4.
IPv6 Configuration and Using OSPF and Other Routing Protocols for IPv6
This section describes the routing protocols available for IPv6, and focuses on the concepts and tasks needed to implement OSPF for IPv6. Enabling IPv6 and configuring IPv6 addresses are also covered in this section.
IPv6 Routing Protocols
IPv6 uses the same "longest-prefix match" routing that IPv4 classless interdomain routing (CIDR) uses. Updates to the existing IPv4 routing protocols were necessary for handling the longer IPv6 addresses and different header structures. Currently, the following updated routing protocols are available:
Static routes
RIP new generation (RIPng) (defined in RFC 2080, RIPng for IPv6)
OSPF Version 3 (OSPFv3) (defined in RFC 2740, OSPF for IPv6)
Intermediate System-Intermediate System (IS-IS) for IPv6
Enhanced Interior Gateway Routing Protocol (EIGRP) for IPv6
Multiprotocol Border Gateway Protocol Version 4 (MP-BGP4) (defined in RFC 2545, Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing, and RFC 2858, Multiprotocol Extensions for BGP-4)
These protocols are described in the following sections.
| Key Point | Enabling IPv6 Routing The Cisco IOS ipv6 unicast-routing global configuration command for IPv6 enables IPv6 routing, and is required before any IPv6 routing protocol is configured. |
Static Routing
Static routing in IPv6 is used and configured in the same way as in IPv4. There is an IPv6 specific requirement per RFC 2461, Neighbor Discovery for IP Version 6 (IPv6), that a router must be able to determine the link-local address of each of its neighboring routers to ensure that the target address of a redirect message identifies the neighbor router by its link-local address. For static routing this requirement means that the next-hop router's address should be specified using the link-local address of the router, not a global unicast address.
IPv6 static routes can be configured with the ipv6 route ipv6-prefix/prefix-length interface-type interface-number [administrative-distance] global configuration command, similar to IPv4 static routes.
RIPng
Similar to IPv4's RIP, RIPng is a distance vector routing protocol with a metric limit of 15 hops that uses split-horizon and poison reverse to prevent routing loops. IPv6 features include the following: