Chapter 6. IPv6 Multicast Networks

This chapter begins by covering the fundamentals of IPv6 and why there is such a great need for it today. It explains IPv6 multicast group addressing, along with the concept of scoping and IPv6 multicast group address assignments. You also learn how IPv6 multicast addresses are mapped to MAC addresses. We discuss the Layer 2 and Layer 3 multicast environment, how subscriptions to multicast streams are controlled, how IPv6 multicast messages are routed across the network, and the different options for configuring a rendezvous point. Included in this chapter are many configuration examples to get you started on the road to implementing IPv6 multicast.

IPv4 addresses use 32 bits for a numerical value to distinguish individual devices, whereas IPv6 uses 128 bits. This increase offers tremendous scalability. The implementation of IPv6 has another interesting characteristic in that there is no longer support for traditional network broadcasts. The two methods of communication available with IPv6 are unicast or multicast. Because multicast was considered during the creation of the protocol, some inherent capabilities improve that operation. Besides the greater amount of address space, the rendezvous point (RP) address and scoping information can be embedded in the message.

The biggest difference between IPv4 and IPv6 is the size of the IP address. An IPv6 address has 128 bits (16 bytes). These 128 bits are divided into 8 16-bit hexadecimal blocks separated by colons (:) in the format: X:X:X:X:X:X:X:X. Two examples of IPv6 addresses are as follows:

2002:8888:9999:AAAA:BBBB:CCCC:DDDD:1234

2002:8888:0:0:0:0:0:AAAA

An IPv6 address like the one above, 2002:8888:0:0:0:0:0:AAAA, can contain consecutive zeroes within the address. Two colons (::) within the address can be used to represent a group of consecutive zeroes. The two-colon marker can occur at the beginning, middle, or end of an IPv6 address, but it can only occur once within the entire address, representing the longest set of consecutive zeros. Table 6-1 shows a list of compressed format IPv6 addresses.

Just as with IPv4, an IPv6 unicast address is an identifier for a single host interface on a single networked device. It is a logical address that represents a physical location. A packet that is sent to a unicast destination address is routed and ultimately forwarded to the physical interface identified by that address. Unlike IPv4, IPv6 has different types of unicast addresses, and they serve different functions. The two most important to this text are global (often referred to as aggregatable global) addresses and link-local addresses.

A global unicast address is similar to a typical IPv4 address. Its structure enables address supernetting and subnetting and ultimately the strict aggregation of routed prefixes in the global (Internet) IPv6 table. Global addresses are assigned throughout a network and eventually are aggregated upward through organizations. Eventually, an aggregated block or blocks of address space are advertised by the organization to the Internet service providers (ISPs). These addresses are public and are assigned by IANA just like their IPv4 counterparts.

Global IPv6 addresses are defined by a global routing prefix, a subnet ID, and an interface ID. Except for addresses that start with binary 000, all global unicast addresses have a 64-bit interface ID. Thus, the global address has essentially two major sections, a 64-bit network prefix (equivalent to a major class network with the ability to subnet) and a 64-bit host identifier. This makes the assignment of addresses much easier for network administrators.

The assignable range of addresses for each 64-bit prefix is enormous, creating millions of potential networks with millions of potential hosts. This solves for the problem of address depletion in IPv4 networks. Additional subnetting can encroach on the 64-bit host ID of the address as well. This enables the address to convey not only the subnet but also any potential scoping included by the administrator. The final 48-bits in the address for many IPv6 hosts might simply be the MAC address of the host interface where the address is applied, connecting physical and logical in a single field.

The IPv6 global unicast address allocation uses the range of addresses that start with binary value 001 (2000::/3). Figure 6-1 shows the structure of an aggregatable global address.

The other type of addresses that we are concerned with are known as link-local addresses. A link-local address is an IPv6 unicast address that is typically automatically configured on any IPv6 interface. Consequently, if you configure a global address on a Cisco router interface, the router will by default, also assign a link-local IPv6 address. According to RFC 4291, link-local addresses must begin with the prefix FE80::/10 (1111 1110 1000 0000) and end with interface identifier in the modified EUI-64 format (normally automatically assigned using the physical address of the interface; Media Access Control [MAC] addresses in the case of Ethernet).

Link-local addresses are an absolute requirement for any IPv6 deployment. They are used in the IPv6 Neighbor Discovery Protocol (NDP), many infrastructure protocols, and the unique IPv6 stateless auto-configuration process. Nodes on a local link can use link-local addresses to communicate. This is very important to understand, IPv6 nodes do not need globally unique addresses to communicate.

Also of significance, is that IPv6 routers cannot forward packets that have link-local source or destination addresses to other links. The name link-local implies its scope. This scope is automatically enforced by any operating system that is conforming to IETF specifications for IPv6 address scoping (this should be universal). Link-local addresses are intended for local host-to-host communication only. Automatic assignment of these addresses can obscure implementations, especially inside the network infrastructure. Fortunately, the administrator can assign more meaning to the address by statically changing link-local addresses on Cisco routers and switches. Figure 6-2 shows link-local address format.

We felt that a quick introduction to IPv6 addressing was important to exploring IPv6 multicast. Of course, anyone who has studied IPv6 can tell you from a protocol perspective, there is a lot more going on than just updating the size of IP addresses. Many parts of protocol intercommunication have also evolved with the addressing capabilities. Of course, multicast is no different.

The basic purpose of the address has not changed. The IPv6 multicast address still identifies a group of subscribing nodes, and a node may belong to any number of groups. Because of the differences in address size and scope, IPv6 multicast group addresses have a unique format. Figure 6-3 illustrates the IPv6 group address format as defined by RFC 2373 and updated by RFC 4291.

The list that follows describes the fields shown in Figure 6-3:

11111111: All group addresses must begin with this bit pattern.

Flags: There are four one-bit fields equaling four flags that can be set, 0RPT. Flag values are:

The first (highest order bit) flag is reserved and thus always set to 0.

If the T bit is set to 0, this indicates a permanently assigned (“well-known”) multicast address, assigned by the Internet Assigned Numbers Authority (IANA).

When the T bit is set to 1, this indicates a non-permanently assigned (“transient” or “dynamically” assigned) multicast address.

The P flag is defined by RFC 3306:

If the P-bit = 0, this indicates a multicast address that is not assigned based on the network prefix.

If the P-bit = 1, this indicates a multicast address that is assigned based on the network prefix.

When P = 1, T must also be set to 1, otherwise the setting of the T bit is defined in Section 2.7 of [ADDRARCH] in RFC 3306.

The R flag is defined by RFC3956 and used in defining embedded RP addresses, an IPv6 inherent method for dynamically updating RP mappings on downstream routers without the use of a secondary distribution protocol like BSR or Auto-RP. Embedded RP is discussed in subsequent sections of this chapter.

Scope: A four-bit field used to indicate the scope (breadth of forwarding) of the group. Scope values are:

0000 – 0: reserved

0001 – 1: node-local scope

0010 – 2: link-local scope

0011 – 3: (unassigned)

0100 – 4: (unassigned)

0101 – 5: site-local scope

0110 – 6: (unassigned)

0111 – 7: (unassigned)

1000 – 8: organization-local scope

1001 – 9: (unassigned)

1010 – A: (unassigned)

1011 – B: (unassigned)

1100 – C: (unassigned)

1101 – D: (unassigned)

1110 – E: global scope

1111 – F: reserved

Group ID: Assigned by administrator and identifies the group as either permanent or transient within the given scope.

The scope value, however, does not indicate the meaning of the group address, only the scope in which the group should be found. Any non-permanently assigned group address is meaningful only in the scope that precedes it. The same address may appear in multiple physical locations in the network, but need not interfere with each other, or indicate any membership beyond the local network. For example, if a group of servers is assigned a permanent multicast address with a group ID of 111 (in hexadecimal), then:

FF01:0:0:0:0:0:0:111 is destined for all servers on the same node as the sender, and only that sender.

FF02:0:0:0:0:0:0:111 is destined for all servers on the same link as the sender, and only that sender.

FF05:0:0:0:0:0:0:111 is destined for all servers at the same site as the sender, and only that sender.

FF0E:0:0:0:0:0:0:111 is destined for all servers in the Internet.

Why is this relevant? Remember our discussion about overlapping domains in Chapter 5, especially the domain design and addressing schema for Multicaster’s Bank Corp.? If IPv4 addressing had a similar scoping mechanism, the design and schema could be simplified. In addition, scopes can be nested within each other. Figure 6-4 is a good way to visualize this relationship.

Furthermore, IANA breaks scope for group address assignments down into two types:

Variable-scope Group Addresses: These addresses are similar across all scopes but represent distinct groups. Variable scope addresses are reserved for certain types of services or applications. For example, Network Time Protocol (NTP), which has a multicast address of FF0X:0:0:0:0:0:0:101, where X masks the address scope.

Fixed-scope Group Addresses: These group addresses have a certain meaning only within the scope they are defined in. Fixed-scope addresses should not be changed. This type of address is important in the basic operation of IPv6. For this reason, a few common addresses are listed in Table 6-2.

The reserved multicast addresses are as follows:

FF00:0:0:0:0:0:0:0

FF01:0:0:0:0:0:0:0

FF02:0:0:0:0:0:0:0

FF03:0:0:0:0:0:0:0

FF04:0:0:0:0:0:0:0

FF05:0:0:0:0:0:0:0

FF06:0:0:0:0:0:0:0

FF07:0:0:0:0:0:0:0

FF08:0:0:0:0:0:0:0

FF09:0:0:0:0:0:0:0

FF0A:0:0:0:0:0:0:0

FF0B:0:0:0:0:0:0:0

FF0C:0:0:0:0:0:0:0

FF0D:0:0:0:0:0:0:0

FF0E:0:0:0:0:0:0:0

FF0F:0:0:0:0:0:0:0

Other groups with the scopes listed above can be assigned to make a unique group. For example, the All-Nodes IPv6 multicast group addresses are as follows:

FF01:0:0:0:0:0:0:1

FF02:0:0:0:0:0:0:1

The All-Nodes group starting with FF01 represents an all nodes (all IPv6 addressed interfaces on this node, or node-local) group. The All-Nodes group starting with FF02 represents a link-local nodes group (the nodes on a particular subnet).

Another reserved group, the All-Routers group, could be any of the following group addresses:

FF01:0:0:0:0:0:0:2

FF02:0:0:0:0:0:0:2

FF05:0:0:0:0:0:0:2

There is a breakdown for these groups as well. Each group address above identifies a specific set of all IPv6 routers within scope 1 (node-local), 2 (link-local), or 5 (site-local).

There are many other reserved addresses, and there is an order to the assignment of group addresses for public and private use within the various scopes as defined earlier. One example to pay special attention to is the solicited-node group address of FF02:0:0:0:0:1:FFXX:XXXX.

A solicited-node multicast address is made from the low-order 24-bits of a reserved address (unicast or Anycast) in combination with appended prefix bits to the prefix FF02:0:0:0:0:1:FF00::/104. The resulting range of solicited-node group multicast addresses is FF02:0:0:0:0:1:FF00:0000–FF02:0:0:0:0:1:FFFF:FFFF. Therefore, the solicited-node multicast group address that corresponds to the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. An IPv6 node is required (due to the solicited nature) to join and process any associated solicited-node group addresses derived from the unicast or Anycast addresses assigned to its interfaces. This is a convenient way of targeting a specific group of nodes in a specific network or subnet; it’s similar to a directed broadcast but with a different purpose.

For all other multicast address assignments, the IPv6 multicast group assignment uses the low-order 32-bits of the IPv6 address to create a MAC address. This is to avoid the MAC layer address overlap problem experienced in IPv4, which was discussed in the Chapter 2.

New IPv6 multicast addresses should be assigned so that the group identifier is always in the low-order 32 bits, as shown in Figure 6-5.

Any other restricted or public group assignments are managed by IANA.

Because IPv6 does not have a GLOP equivalent, the IANA assigned unicast prefix for the organization can be used to make the global group assignment instead. The resulting address is a unique unicast-prefix–based multicast group address block, as defined by RFC 3306. The address provides a way to dynamically assign IPv6 group numbers and also allows organizations to assign private address space, including those who do not have global ASNs, or who receive address assignments from service providers.

In these addresses, the 64 bits provided for the Unicast-Prefix field are sufficient based on the structure of the IPv6 unicast addresses (64 bits are used by the interface ID). The format presented in Figure 6-6 illustrates how any given IPv6 unicast prefix can become a multicast address, with 2³² possible groups per unicast prefix. The reserved bits must still always be set to 0, and the unicast prefix will follow. Thus, the address will always start with FF3X:. If an organization was assigned the IPv6 prefix 3F7E:FFFF:1/48, the resulting assignable group block would be F3X:0030:3F7E:FFFF:0001::/96. This gives each organization a unique, private block of group addresses with which to work. It is important to remember that the scope of the unicast-prefix–based multicast address should not exceed that of the embedded unicast prefix.

The solicited-node group address format is FF02::1:FF00:0000/104, where the low-order 24 bits are the same as the unicast or Anycast address that generated it. The derived group address represents a deterministic way to identify the local-link multicast group(s) to which an IPv6 unicast address host is listening. Thus, if all the requisite host information needed to establish unicast connectivity (the MAC address, and so on) is not available, the destination can still be reached via multicast sent to its solicited-node multicast address.

Administrators should also create an organizational address schema for IPv6 multicast group assignments. Wildcard masks serve an identical function for IPv6 addressing. Any meaningful split in the group address section of the address is appropriate.

At press time, most of the Internet still uses IPv4. In fact, few global multicast applications currently use IPv6 multicast. However, with the exponential growth of mobile computing, this is likely to change quickly in the coming years. Mobile computing and the Internet of Everything will require significantly more addressing than IPv4 can provide, and multicast resource efficiency will become a de facto requirement for many applications.

This also means that dynamic and temporary group address assignments may become more commonplace. The IETF has developed an addressing methodology to meet this objective. This methodology is defined in RFC 3307: Allocation Guidelines for IPv6 Multicast Addresses. Architects and administrators who are creating an IPv6 group address schema should thoroughly understand RFC 3307. Architects should also consider IETF RFC 3956 (updated by RFC 7371), which describes embedding the rendezvous point (RP) address in an IPv6 multicast address, when creating an IPv6 group address schema. Implementing RFC 3956 can greatly simplify multicast domain boundaries.

Does more address space mean more binary math? Fortunately not! Converting an IPv6 multicast address to a multicast MAC is much easier using IPv6, although there is far greater overlap of IPv6 addresses to MAC addresses. The addresses in the organizationally unique identifier (OUI) reserved block for IPv6 multicast MAC addresses are from 0X3333.0000.0000 to 0X3333.FFFF.FFFF.

To map the IPv6 multicast of FF02:0:0:0:0:0:E040:0707 to a MAC multicast, the low-order 32-bits of the IPv6 address are concatenated with the high-order bits of 0X3333, as shown in Figure 6-8.

As you can see, this is much easier than converting IPv4 multicast. It also makes for much cleaner multicast topologies. What IPv6 adds in address complexity, it makes up for with simplicity in the network design, or at least that is the intention.

MLD is built on standard Internet Control Messaging Protocol (ICMP), the same protocol that enables traceroute, ping, and echo replies. MLD leverages ICMP messages to carry information about group subscription. This is very unlike IGMP, which has its own messaging format and process. In spite of this difference, both IGMP and MLD provide networks with a way to automatically control and limit the flow of multicast traffic. This control is achieved through the use of special multicast queriers. Queriers and hosts do not perform the same functions. Let us quickly review the role of each:

A querier is usually a network device, such as a gateway multicast router, that sends query messages to discover which network devices are members of a given multicast group. Queries can be specific to a group (“Are there any listeners for group G on the segment?”), or they can be general (as in, “Are there any listeners for any groups on this segment?”).

A host is simply a receiver, which can also be routers or other network devices. Hosts send group report messages to inform the querier of group subscriptions.

Outside of the Multicast Address field, the most important field in the header is the Type field. The type in the message header indicates what type of message is being issued:

Multicast Listener Query: As previously mentioned, there are two types of queries, both designed to locate multicast hosts on a segment. General queries are sent to the link-local, all-nodes multicast address of FF02::1. The MLD Multicast Address field is set to groups unspecified (::), which should solicit a group report (called a listener report) response from each receiver. A group-specific query is used to identify the listeners for a given group that is listed in the MLD Multicast Address field of the message and is sent to the queried multicast address.

MLD queries use a Maximum Response Delay field. This is the maximum allowed delay (in milliseconds) in which a node has to send a report if it has a listener. In all other MLD messages, this field is not used and is therefore set to 0. The Multicast Listener Query message uses a message header Type field equal to 130 (0X82).

Multicast Listener Report: Hosts use the report message type as a response to an MLD query. The destination group address for a report is the multicast address being reported about. In report and done messages, the Multicast Address field contains the multicast group to which a member listens or the group it is leaving. The Multicast Listener Report message uses a message header Type field equal to 131 (0X83).

Multicast Listener Done: This message is sent by a node to indicate that it stopped listening to a multicast address. It is the equivalent of an IPv4 IGMP leave group message. The destination group address for a done message is the link-local, all-routers multicast address (FF02::2). It is assumed that the local multicast querier will receive this message, which is also the likely Layer 3 gateway. The Multicast Listener Done message uses a message header Type field equal to 132 (0X84).

The biggest difference between the versions is the way MLDv2 improves the Listener Report message. Rather than sending a response for each group, it concatenates a set of records, each record containing information that relates to multicast group address subscriptions. This provides MLDv2 Report messages the capability of leaving a group, thereby eliminating the need for the MLDv1 Done message.

MLDv2 is backward compatible with MLDv1 and can coexist comfortably in the same LAN as MLDv1-only hosts. Keep in mind that when a host using MLD version 1 sends a Done message, the querier router needs to send query messages to reconfirm that this host was the last MLD version 1 host joined to the group before it can stop forwarding traffic, and this process takes about two seconds. This is known as leave latency and is also present in IPv4 IGMP version 2–enabled networks.

The prerequisite for configuring IPv6 multicast routing requires IPv6 unicast routing to be properly configured and running. Here, we provide the basic MLD configuration, but unicast routing is beyond the scope of this book.

Begin by configuring the router for IPv6 unicast routing in global configuration mode, as shown in the list that follows. In this example, we use IOS-XE. Refer to the command references for other operating systems.

Step 1. Enable IPv6 unicast routing:

Click here to view code image

R1(config)#ipv6 unicast-routing

Step 2. Assign IPv6 address to the appropriate interfaces in interface configuration mode, for example:

Click here to view code image

R1(config-if)#ipv6 address 2001:192:168:7::1/64

Step 3. Configure the IGP of your choice. You are on your own for this one!

R1(config)#router ?

Step 4. Enable IPv6 multicast routing in global configuration mode. By default, this enables PIM and MLD on any interfaces configured with an IPv6 address.

Click here to view code image

R1(config)#ipv6 multicast-routing

To ease the configuration burden for IPv6, it is assumed that MLD should be enabled on all IPv6-enabled interfaces when ipv6 multicast-routing is configured. In addition, many of the same configuration options that are available for IGMPv1-3 are also available for MLD, in particular those configurations that affect MLD on the segment. Examples include joining groups, limiting group addresses that are accepted in a response by ACL, and other query timers/parameters.

The configuration in Example 6-1 shows some of the MLD commands as they would be applied in an IOS-XE router’s running configuration file.

Example 6-1 MLD Interface Commands

Click here to view code image

---

!
interface GigabitEthernet0/0
 ipv6 enable
 ipv6 mld join-group FF37::1 [include | exclude]
 ipv6 mld static-group FF37::1 [include | exclude]
 ipv6 mld access-group <access-list-name>
 ipv6 mld query-timeout <seconds>
 ipv6 mld query-interval <seconds>
 ipv6 mld query-max-response-time <seconds>
!

---

1. The host (Receiver-1) sends a multicast join message to the group address FF37::7 in this example. Below is a packet capture of the message. There are a few items to note: The destination address for a MLDv2 report messages is FF02::16, and this corresponds to the MAC address of 33:33:00:00:00:16. The IPv6 address of Receiver-1 that sources the messages is a link-local address because it starts with FE80:

Click here to view code image

Ethernet II, Src: 80:ee:73:07:7b:61, Dst: 33:33:00:00:00:16
    Destination: 33:33:00:00:00:16
        Address: 33:33:00:00:00:16
        .... ..1. .... .... .... .... = LG bit: Locally administered address
        (this is NOT the factory default)
        .... ...1 .... .... .... .... = IG bit: Group address
        (multicast/broadcast)
    Source: 80:ee:73:07:7b:61
        Address: 80:ee:73:07:7b:61
        .... ..0. .... .... .... .... = LG bit: Globally unique address
        (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: fe80::82ee:73ff:fe7:7b61 Dst: ff02::16
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
    Payload length: 36
    Next header: IPv6 hop-by-hop option (0)
    Hop limit: 1
    Source: fe80::82ee:73ff:fe07:7b61
    [Source SA MAC: 80:ee:73:07:7b:61]
    Destination: ff02::16
Hop-by-Hop Option
        Next header: ICMPv6 (58)
        Length: 0 (8 bytes)
        IPv6 Option (Router Alert)
            Type: Router Alert (5)
            Length: 2
            Router Alert: MLD (0)
        IPv6 Option (PadN)
            Type: PadN (1)
            Length: 0
            PadN: <MISSING>
Internet Control Message Protocol v6
    Type: Multicast Listener Report Message v2 (143)
    Code: 0
    Checksum: 0xfec7 [correct]
    Reserved: 0000
    Number of Multicast Address Records: 1
    Multicast Address Record Changed to exclude: ff37::7
        Record Type: Changed to exclude (4)
        Aux Data Len: 0
        Number of Sources: 0
        Multicast Address: ff37::7

2. The router receives the report from Receiver-1. The following command verifies the entry:

Click here to view code image

ASR1K-2#show ipv6 mld groups FF37::7 detail
Interface:       GigabitEthernet0/0/0
Group:           FF37::7
Uptime:          00:05:10
Router mode:     EXCLUDE (Expires: 00:03:55)
Host mode:       INCLUDE
Last reporter:   FE80::82EE:73FF:FE07:7B61
Source list is empty

3. The (*,G) entry and (S,G) entries are added to the multicast routing table, which can be seen using the following command:

Click here to view code image

ASR1K-2#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
       C - Connected, L - Local, I - Received Source Specific Host Report,
       P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
       J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State

(*, FF05::1:3), 00:18:27/never, RP 2001:192:168::1, flags: SCLJ
  Incoming interface: GigabitEthernet0/0/1
  RPF nbr: FE80::D68C:B5FF:FE43:1E01
  Immediate Outgoing interface list:
    GigabitEthernet0/0/0, Forward, 00:18:27/never

(*, FF37::7), 00:04:04/never, RP 2001:192:168::1, flags: SCJ
  Incoming interface: GigabitEthernet0/0/1
  RPF nbr: FE80::D68C:B5FF:FE43:1E01
  Immediate Outgoing interface list:
    GigabitEthernet0/0/0, Forward, 00:04:04/never

(2001:192:168:8::10, FF37::7), 00:01:34/00:01:55, flags: SJT
  Incoming interface: GigabitEthernet0/0/1
  RPF nbr: FE80::D68C:B5FF:FE43:1E01
  Inherited Outgoing interface list:
    GigabitEthernet0/0/0, Forward, 00:04:04/never

4. The router performs an RPF check and updates the Multicast Forwarding Information Base (MFIB) table with the outgoing interface; this is where Receiver-1 is located and where the outbound interface list (OIF) is added.

The following output displays the IPv6 MFIB table for the multicast address of FF37::7. The Hardware (HW) forwarding entry indicates that traffic is flowing:

Click here to view code image

ASR1K-2#show ipv6 mfib FF37::7 verbose
Entry Flags:    C - Directly Connected, S - Signal, IA - Inherit A flag,
                ET - Data Rate Exceeds Threshold, K - Keepalive
                DDE - Data Driven Event, HW - Hardware Installed
I/O Item Flags: IC - Internal Copy, NP - Not platform switched,
                NS - Negate Signalling, SP - Signal Present,
                A - Accept, F - Forward, RA - MRIB Accept, RF - MRIB Forward,
                MA - MFIB Accept
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts:      Total/RPF failed/Other drops
I/O Item Counts:   FS Pkt Count/PS Pkt Count
Default
 (*,FF37::7) Flags: C K HW
   0x9E  OIF-IC count: 0, OIF-A count: 1
   SW Forwarding: 0/0/0/0, Other: 0/0/0
   HW Forwarding:   48/0/1390/0, Other: 0/0/0
   GigabitEthernet0/0/1 Flags: RA A MA NS
   GigabitEthernet0/0/0 Flags: RF F NS
     CEF: Adjacency with MAC: 33330000000700225561250086DD
     Pkts: 0/0
 (2001:192:168:8::10,FF37::7) Flags: K HW DDE
   0x9F  OIF-IC count: 0, OIF-A count: 1
   SW Forwarding: 0/0/0/0, Other: 0/0/0
   HW Forwarding:   61559/278/1390/3018, Other: 0/0/0
   GigabitEthernet0/0/1 Flags: RA A MA
   GigabitEthernet0/0/0 Flags: RF F NS
     CEF: Adjacency with MAC: 33330000000700225561250086DD
     Pkts: 0/0

Example 6-2 MLD Leave Group Message Received

Click here to view code image

---

Ethernet II, Src: 80:ee:73:07:7b:61, Dst: 33:33:00:00:00:16
    Destination: 33:33:00:00:00:16
    Source: 80:ee:73:07:7b:61
    Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: fe80::82ee:73ff:fe07:7b61, Dst: ff02::16
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
    Payload length: 36
    Next header: IPv6 hop-by-hop option (0)
    Hop limit: 1
    Source: fe80::82ee:73ff:fe07:7b61
    Destination: ff02::16
Hop-by-Hop Option
        Next header: ICMPv6 (58)
        Length: 0 (8 bytes)
        IPv6 Option (Router Alert)
        IPv6 Option (PadN)
Internet Control Message Protocol v6
    Type: Multicast Listener Report Message v2 (143)
    Code: 0
    Checksum: 0xffc7 [correct]
    Reserved: 0000
    Number of Multicast Address Records: 1
    Multicast Address Record Changed to include: ff37::7
        Record Type: Changed to include (3)
        Aux Data Len: 0
        Number of Sources: 0
        Multicast Address: ff37::7

---

Let us examine MLD snooping configuration and mechanics. As shown in Figure 6-11, Host A and Host B are receiving an IPv6 multicast stream from FF02::E040:707.

Example 6-3 Verifying IPv6 MLD Support

Click here to view code image

---

Switch#show sdm prefer
 The current template is "desktop IPv4 and IPv6 routing" template.
 The selected template optimizes the resources in
 the switch to support this level of features for
 8 routed interfaces and 1024 VLANs.

  number of unicast mac addresses:                  1.5K
  number of IPv4 IGMP groups + multicast routes:    1K
  number of IPv4 unicast routes:                    2.75K
    number of directly-connected IPv4 hosts:        1.5K
    number of indirect IPv4 routes:                 1.25K
  number of IPv6 multicast groups:                  1K
  number of directly-connected IPv6 addresses:      1.5K
  number of indirect IPv6 unicast routes:           1.25K
  number of IPv4 policy based routing aces:         0.25K
  number of IPv4/MAC qos aces:                      0.5K
  number of IPv4/MAC security aces:                 0.5K
  number of IPv6 policy based routing aces:         0.25K
  number of IPv6 qos aces:                          0.5K
  number of IPv6 security aces:                     0.5K

---

The switch database management (SDM) templates allow you to change the behavior of the switch. In order to support IPv6 multicast, you must select a template that supports IPv6. If your switch does not support IPv6 multicast, you will need to change the template and reboot the switch, as demonstrated in Example 6-4.

Example 6-4 SDM Template for IPv6 and IPv4 Support

Click here to view code image

---

C3560E(config)#sdm prefer dual-ipv4-and-ipv6 routing
Changes to the running SDM preferences have been stored, but cannot take effect
until the next reload.
Use 'show sdm prefer' to see what SDM preference is currently active.

---

Now that IPv6 is enabled, you can complete the remainder of the configuration. Enable IPv6 MLD using the following command:

Click here to view code image

C3560E(config)#ipv6 mld snooping

Using the show ipv6 mld snooping mrouter command, you can verify the attached router has been detected as demonstrated in Example 6-5.

Example 6-5 Show ipv6 mld snooping mrouter Command Output

Click here to view code image

---

C3560E#show ipv6 mld snooping mrouter
Vlan    ports
----    -----
  12    Gi0/13(dynamic)

---

The output in Example 6-6 shows Host A connected to Gi0/3 and Host B connected to Gi0/5, and both are accessing the FF02::E040:707 multicast stream.

Example 6-6 Show MLD Snooping Per VLAN

Click here to view code image

---

C3560E#show ipv6 mld snooping address vlan 12
Vlan      Group                    Type        Version     Port List
-----------------------------------------------------------------------
12        FF02::E040:707           mld         v2          Gi0/3, Gi0/5,
                                                           Gi0/13

---

The debug ipv6 mld provides a great deal of information. The following output shows the MLD report from Host B:

Click here to view code image

MLDSN: Processing v2 Report as a MLDv1 Report for group FF02::E040:707 on port
Gi0/5 in vlan 12

When Host B leaves the multicast group, the following debug message is displayed:

Click here to view code image

MLDSN: Processing v2 Report as MLDv1 Leave for group FF02::E040:707 on port Gi0/5
in vlan 12

The important aspect to remember is that no new multicast routing protocol is required. When we use PIM in an IPv6 network, with IPv6 rules enabled, we sometimes call it PIM6. This is not a new protocol or protocol version, but again, indicates IPv6 support in PIMv2 implementations. This allows both IPv4 and IPv6 to reside simultaneously on the same infrastructure while still supporting multicast for each.

To illustrate this point, we take a look at some of the same output we examined in earlier chapters regarding how basic Layer 3 multicast operations work. In this case, we use a new IPv6 network without IPv4-enabled, running PIM sparse-mode (PIM-SM) on Cisco IOS-XE. We keep the network very simple, with only three routers (R1–R3), as shown in Figure 6-12. R1 is the RP and is using BSR to advertise itself. R3 Loopback 0 has joined two IPv6 multicast groups, FF05::1 and FF06::1.

Now, let us examine the multicast state table on R2, where the forwarding path and the reverse path converge. For IPv4 we would use the command show ip mroute to see the IPv4 multicast state table. To collect the equivalent IPv6 output, we need only replace ip with ipv6. The command is show ipv6 mroute, as demonstrated in Example 6-7.

Example 6-7 Displaying the IPv6 Multicast State Table

Click here to view code image

---

R2#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
       C - Connected, L - Local, I - Received Source Specific Host Report,
       P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
       J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State

(2002:11:1:1::1, FF35::1), 00:36:40/00:02:47, flags: ST
  Incoming interface: Ethernet0/0
  RPF nbr: FE80::A8BB:CCFF:FE00:100
  Immediate Outgoing interface list:
    Ethernet1/0, Forward, 00:36:40/00:02:47

(2002:11:1:1::1, FF36::1), 00:46:23/00:02:47, flags: STI
  Incoming interface: Ethernet0/0
  RPF nbr: FE80::A8BB:CCFF:FE00:100
  Immediate Outgoing interface list:
    Ethernet1/0, Forward, 00:36:40/00:02:47

---

The command output is essentially identical to the IPv4 output. First we are given the table flags indicating the PIM type and other tree information. The protocol and state flags should be very familiar because they are the same as those in IPv4. Next, we are given the states of the two (S,G) entries for groups FF05::1 and FF06::1. Notice how the state information in the output includes the RPF neighbor information as well as the outgoing interface list (OIL).

What might strike some administrators as odd is the RPF neighbor information. Take a closer look at the output for the (2002:11:1:1::1, FF35::1) state entry, paying attention to the highlighted portions.

The OIL and the RPF neighbor in this case are IPv6. However, the process for determining this information is the same as the process for IPv4. The only difference is that the IPv6 routing table (RIB) and forwarding table (FIB) are used to derive the OIL and RPF check information and populate the v6 MRIB and MFIB respectively. The source, 2002:11:1:1::1 in the (S,G) for each entry, is the loopback for R1.

If we show the RPF information for the source address on R2, using the show ipv6 rpf command (again, same command, just replace ip with ipv6), we see that the unicast address 2002:11:1:1::1 is in fact located out router interface Ethernet0/0, but that the RPF neighbor address is not the configured interface address of R1 located out E0/0, as shown in Example 6-8.

Example 6-8 RPF for IPv6 Multicast

Click here to view code image

---

R2#show ipv6 rpf 2002:11:1:1::1
RPF information for 2002:11:1:1::1
  RPF interface: Ethernet0/0
  RPF neighbor: FE80::A8BB:CCFF:FE00:100
  RPF route/mask: 2002:11:1:1::1/128
  RPF type: Unicast
  RPF recursion count: 0
  Metric preference: 120
  Metric: 2

---

Instead, the RPF address is the link-local address configured for R1’s E0/0 interface. The IPv6 unicast route table (RIB) and CEF table (FIB) show us where this RPF information was derived from, by using the show ipv6 route and show ipv6 cef commands, as shown in Example 6-9.

Example 6-9 IPv6 RIB and FIB

Click here to view code image

---

R2#show ipv6 route
IPv6 Routing Table - default - 9 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, M - MIPv6, R - RIP, I1 - ISIS L1
       I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
       EX - EIGRP external, ND - Neighbor Discovery
       O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2

R   2002:11:1:1::1/128 [120/2]
     via FE80::A8BB:CCFF:FE00:100, Ethernet0/0

R2#show ipv6 cef
2002:11:1:1::1/128
  nexthop FE80::A8BB:CCFF:FE00:100 Ethernet0/0
FF00::/8
  multicast

---

As you can see, the nexthop information for the RPF check uses the link-local address of the neighboring router (R1) from the RIB and FIB as the forwarding address. That makes the link-local address of R1 the RPF neighbor, even though the global routes are learned via the configured global interface addresses (the RPF route from the show ipv6 rpf output). This is a function of IPv6 addressing rules, and it may require that you spend some time double-checking local connectivity in an IPv6 PIM domain.

You can also see that many protocols, including PIM, use the link-local addresses to form neighbor adjacencies and exchange protocol information. Look at the show ipv6 pim neighbor command on R2 in Example 6-10. Here we find the neighbor relationships are established between the link-local addresses of the routers.

Example 6-10 IPv6 PIM Neighbors Table

Click here to view code image

---

R2#show ipv6 pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, G - GenID Capable
Neighbor Address           Interface          Uptime    Expires  Mode DR pri

FE80::A8BB:CCFF:FE00:100   Ethernet0/0        00:46:37  00:01:16 B G     1
FE80::A8BB:CCFF:FE00:301   Ethernet1/0        00:36:52  00:01:33 B G  DR 1

---

We can see that R1, located out Ethernet0/0 has a link-local address of FE80::A8BB:CCFF:FE00:100, the same as that found in the RPF information. To find the link-local address of a given interface—in this case, Ethernet0/0 on R1—simply use the show ipv6 interface [type (port/slot)] command. If we issue this command, show ipv6 interface Ethernet0/0 on R1, we find consistency with the table outputs from R2, as demonstrated in Example 6-11.

Example 6-11 Finding the Link-Local Address

Click here to view code image

---

R1#show ipv6 interface e0/0
Ethernet0/0 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::A8BB:CCFF:FE00:100
  No Virtual link-local address(es):
  Global unicast address(es):
    2002:10:1:1::1, subnet is 2002:10:1:1::/64
  Joined group address(es):
    FF02::1
    FF02::2
    FF02::9
    FF02::D
    FF02::16
    FF02::1:FF00:1
    FF02::1:FF00:100
    FF06::1
  MTU is 1500 bytes
  ICMP error messages limited to one every 100 milliseconds
  ICMP redirects are enabled
  ICMP unreachables are sent
  Output features: MFIB Adjacency
  ND DAD is enabled, number of DAD attempts: 1
  ND reachable time is 30000 milliseconds (using 42613)
  ND advertised reachable time is 0 (unspecified)
  ND advertised retransmit interval is 0 (unspecified)
  ND router advertisements are sent every 200 seconds
  ND router advertisements live for 1800 seconds
  ND advertised default router preference is Medium
  Hosts use stateless autoconfig for addresses.

---

The important component to understand is that the IPv6 RIB and FIB are used for RPF loop prevention and state population in the MRIB and MFIB of the router. This is the same process as the one used for IPv4, and it is consistent with the rules of PIMv2 as laid out by IETF RFCs. Almost any command that you can issue for IPv4 multicast you can issue for IPv6 multicast. Most of the commands simply require a change in the syntax from ip to ipv6. This is true even of configuration commands in IOS.

Let us look at the basic PIM and interface configuration of R1 in Example 6-12 to illustrate this point more fully.

Example 6-12 R1 PIM and Interface Configuration

Click here to view code image

---

hostname R1
!
!
ip cef
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
!
interface Loopback0
 no ip address
 ipv6 address 2002:11:1:1::1/128
 ipv6 enable
 ipv6 router isis TEST
!
interface Loopback100
 no ip address
 ipv6 address 2002:100:1:1::1/128
 ipv6 enable
 ipv6 router isis TEST
!
interface Ethernet0/0
 no ip address
 ipv6 address 2002:10:1:1::1/64
 ipv6 enable
 ipv6 router isis TEST
!
!
router isis TEST
 net 49.0001.0000.0001.00
!
!
ipv6 pim bsr candidate bsr 2002:11:1:1::1
ipv6 pim bsr candidate rp 2002:11:1:1::1 group-list ACL priority 190
!
!
!
ipv6 access-list ACL
 permit ipv6 any FF05::/64

---

In this configuration, we enabled PIM on the relevant interfaces (Ethernet0/0, Loopback0, and Looback100) by simply enabling ipv6 multicast routing, as previously mentioned. The show running-config all command (see Example 6-13), shows us that this automatically configures PIM-SM for IPv6 using the command ipv6 pim sparse-mode, along with many other IPv6 multicast commands, as shown here for interface Ethernet0/0. (Remember that sparse-mode with or without SSM support is the only option for PIM6, and consequently the command to enable it per interface is simply ipv6 pim.)

Example 6-13 Finding Automatic PIM Configuration for IPv6

Click here to view code image

---

R1#show running-config all
!
interface Ethernet0/0
 no ip address
 ipv6 address 2002:10:1:1::1/64
 ipv6 enable
 ipv6 nd reachable-time 0
 ipv6 nd ns-interval 0
 ipv6 nd dad attempts 1
 ipv6 nd prefix framed-ipv6-prefix
 ipv6 nd nud igp
 ipv6 nd ra lifetime 1800
 ipv6 nd ra interval 200
  ipv6 redirects
  ipv6 unreachables
 ipv6 mfib forwarding input
 ipv6 mfib forwarding output
 ipv6 mfib cef input
 ipv6 mfib cef output
 ipv6 mld query-max-response-time 10
 ipv6 mld query-timeout 255
 ipv6 mld query-interval 125
 ipv6 mld router
 ipv6 pim hello-interval 30
 ipv6 pim dr-priority 1
 ipv6 pim join-prune-interval 60
 ipv6 pim
 ipv6 router isis TEST
!

---

In addition, we have enabled PIM BSR for IPv6. This was accomplished using the same command as BSR for IPv4 (ip pim bsr candidate bsr address), except we replace the ip syntax with ipv6. This makes configuring IPv6 multicast a cinch, and it enables dual stack networking (running IPv4 and IPv6 natively over the same infrastructure) with ease. IPv4 multicast configuration complexities and interface mode management confusion have been eliminated in PIM6.

Static mroutes for IPv6 multicast are configured as an extension of IPv6 static routes. An IPv6 static route can be configured for unicast routing only, static multicast route for multicast RPF selection only, or to use a static route for both unicast routing and multicast RPF selection. This is accomplished using the command ipv6 route address/mask interface-type slot/port [multicast | unicast]. If no keyword (multicast or unicast) is specified in the IPv6 static route, it is used for both unicast routing and multicast RPF selection.

The following is an example configuration for adding a static entry on R2 for RPF of source 2001:DDBB:200::10/128.

Click here to view code image

!
ipv6 route 2001:DDBB:200::10/128 Ethernet0/1 [multicast | unicast ]
!

Both IPv6 multipath-multicast and tunneling are supported on all Cisco platforms. These can come in very handy for v6 installs, for the same reasons they do for IPv4 networks. Tunneling can also be especially useful for crossing a non-PIM6 or non-IPV6-enabled boundary. This is common in some IPv6 networks, where IPv6 is deployed at the edge but tunneled over an IPv4 core network. In these situations, there are ways to propagate the multicast information from IPv6 across the IPv4 infrastructure, but many may find it easier to simply configure IPv6-enabled tunnels, where appropriate.

In addition to static entries for tunneling and multipath routing, IPv6 MP-BGP address-family information (AFI) can be used for PIM6 traffic engineering. Multicast BGP with the IPv6 multicast address family provides multicast BGP extensions for IPv6 and supports the same features and functionality as IPv4 BGP. IPv6 enhancements to multicast BGP include support for an IPv6 multicast address family, network layer reachability information (NLRI), and next-hop (the next router in the path to the destination) attributes that use IPv6 addresses. A subsequent address family identifier (SAFI) provides information about the type of network layer reachability information that is carried in the attribute. Multiprotocol BGP unicast uses SAFI 1 messages, and multiprotocol BGP multicast uses SAFI 2 messages.

The IPv6 multicast address family can carry routes used for RPF lookup by the IPv6 PIM protocol, and multicast BGP IPv6. Users must use IPv6 multicast BGP AFI when using IPv6 multicast with BGP because the IPv6 unicast BGP learned routes will not be used for IPv6 multicast RPF. A separate BGP routing table is maintained to configure incongruent policies and topologies (for example, IPv6 unicast and multicast) by using IPv6 multicast RPF lookup. Multicast RPF lookup is very similar to the IP unicast route lookup.

General any-source multicast (ASM): The group ranges specified in Generic Multicast Group Addresses Definition and Unicast-Prefix–Based Addresses will by default always be handled as sparse-mode groups. If Cisco IOS Software is not aware of an RP for a group, then a default group mode is used (sparse-mode for IPv6, for example).

Source-specific multicast (SSM): The SSM group range (SSM address range) is hard-coded and will always be handled in the SSM mode (no wildcard joins processed, no RP definition for the group range required).

Embedded RP groups: Embedded group ranges (embedded RP addresses) cannot be predefined (the RP address is not preliminarily known) in the SSM sense, but the router interprets the embedded RP group address only when the first PIM joins for that group appear or the first data appears from the directly connected source; prior to that, it is not possible to determine any RP for the group. Embedded RP is explained in the next section, but it is introduced here to complete the group mode discussion.

The group mode can be displayed using the show ipv6 pim range-list command (PIM range for an output example). By default, when multicast routing is enabled, the group modes are listed in Table 6-3.

However, the IETF developed a new, open standard method of embedding RP information within multicast packets as an easier alternative for performing dynamic group mappings. This is known as embedded RP and is defined by IETF RFC 3956. Cisco did not extend proprietary Auto-RP support to PIM6. Consequently, there is no support for Auto-RP in an IPv6 multicast network. Table 6-4 provides you a complete overview of the available methods to configure RP group mappings, with a comparison between IPv4 and IPv6 PIM.

As shown in Table 6-4, if the domain is not using embedded RP, BSR is the only other dynamic RP propagation and mapping option. Again, there is no Auto-RP support for IPv6. PIM6 devices in a domain must still be able to map each multicast group to the correct RP address regardless of IP version. With the PIM6 BSR feature, multicast routing devices will detect an unreachable RP. Any mapping tables will be modified after the failure so that the unreachable RP is no longer used. If failover is configured within the BSR domain using priority, new tables will be rapidly distributed throughout the domain when the primary RP failure has fully converged.

As shown earlier, the configuration for BSR is nearly identical to IPv4, changing only the key syntax word ip to ipv6. The domain still needs at least one of each, a candidate RP and a candidate BSR, configured in the domain. The PIM BSR messages are propagated through the network in the same way, except using the link-local IPv6 PIM connection instead of the IPv4 PIM network.

Just as with IPv4 PIM, PIM6 sparse-mode multicast groups need to associate with the IP or IPv6 address of an RP. If the domain is running dual-stack (simultaneous configuration of IPv4 and IPv6) an IPv4 RP can work as the RP for PIM6 managed groups. This is one of the big advantages of the IETF using the same PIM version (version 2) for both IPv4 and IPv6. When a new IPv6 multicast source starts sending multicast packets, its local gateway router DR encapsulates these data packets in a PIM register message and sends them to the RP for that multicast group. When a new multicast receiver joins a group, the local gateway DR sends a PIM join message to the RP for that multicast group. This functionality does not change, and the role of the RP is the same as it is for IPv4.

Don’t forget the best practice and security recommendations for PIM domains that we discussed in the previous chapter. These all still apply for PIM6 domains. It is especially important to limit the scope of the PIM6 domain. When using BSR, for example, make sure you have a well-defined BSR borders using the ipv6 pim bsr border command and well-defined domain boundaries using the ipv6 multicast boundary command.

Remember that Anycast RP offers the PIM domain robust RP services along with fast convergence when a PIM RP device fails. This is considered ideal for any IPv6 multicast services that are mission critical or of high importance to the organization where PIM6 is deployed. Let us examine the IOS-XE configuration for PIM6 Anycast RP. It is of course very similar to the non-MSDP configuration option for IPv4 and works using the same principles.

In this configuration example, we use the same three router network we used for the previous BSR configuration example. R1 still acts as an RP, but R3 will also be added to the RP set using Anycast RP global-scope address 2002:F:F:F::1/128 (Loopback 500 on each RP router). All routers (including the RP) will be configured with a static RP address command. Examine Figure 6-13 to see how this configuration is arranged.

Example 6-14 shows the router configurations used to support this Anycast RP deployment.

Example 6-14 Configuration to Support Anycast RP Deployment

Click here to view code image

---

RP: R1
hostname R1
!
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
 no ip address
 ipv6 address 2002:11:1:1::1/128
 ipv6 enable
 ipv6 router isis TEST
!
interface Loopback500
 no ip address
 ipv6 address 2002:F:F:F::1/128
 ipv6 enable
 ipv6 router isis TEST
!
interface Ethernet0/0
 no ip address
 ipv6 address 2002:10:1:1::1/64
 ipv6 enable
 ipv6 router isis TEST
!
router isis TEST
 net 49.0001.0000.0001.00
!
ipv6 pim anycast-rp 2002:F:F:F::1 2002:11:1:1::3
ipv6 pim rp-address 2002:F:F:F::1 group-list ACL
!
ipv6 access-list ACL
 permit ipv6 any FF05::/64

---

RP: R2
hostname R2
!
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
 no ip address
 ipv6 address 2002:11:1:1::2/128
 ipv6 enable
 ipv6 router isis TEST
!
interface Ethernet0/0
 no ip address
 ipv6 address 2002:10:1:1::2/64
 ipv6 enable
 ipv6 router isis TEST
!
interface Ethernet1/0
 no ip address
 ipv6 address 2002:10:1:2::1/64
 ipv6 enable
 ipv6 router isis TEST
!
router isis TEST
 net 49.0002.0000.0002.00
!
ipv6 pim rp-address 2002:F:F:F::1 group-list ACL
!
ipv6 access-list ACL
 permit ipv6 any FF05::/64

---

R3
hostname R3
!
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
 no ip address
 ipv6 address 2002:11:1:1::3/128
 ipv6 enable
 ipv6 router isis TEST
!
interface Loopback500
 no ip address
 ipv6 address 2002:F:F:F::1/128
 ipv6 enable
 ipv6 router isis TEST
!
interface Ethernet1/0
 no ip address
 ipv6 address 2002:10:1:2::2/64
 ipv6 enable
 ipv6 router isis TEST
!
router isis TEST
 net 49.0002.0000.0003.00
!
ipv6 pim anycast-rp 2002:F:F:F::1 2002:11:1:1::1
ipv6 pim rp-address 2002:F:F:F::1 group-list ACL
!
ipv6 access-list ACL
 permit ipv6 any FF05::/64
!

---

RFC3956 specifies rendezvous point (RP) address encoding and is accomplished by adding a new field for the RP address and by defining a new flag in the Flgs field. The group address should start with FF7X::/12, where the flag value of 7 means embedded RP. Figure 6-14 illustrates the format of the group.

Elements in Figure 6-14 related to PIM6 Embedded RP:

Binary Bits: 11111111 at the start of the address identifies the address as being a multicast address.

Flgs: The RFC redefines the four-bit “flag” field with the following option for using embedded RP:

R = 1 indicates this is an embedded RP multicast address and contains the address of the PIM-SM RP. When R = 1, P must be set to 1, and consequently T must also be set to 1, as specified in RFC3306 (Generic Multicast Group Addresses Definition). This address range is therefore represented as FF7X::/12 in the prefix format.

RIID: The RP address of the PIM-SM RP for this unicast-prefix–based multicast address.

Plen: The number of significant bits in the Network Prefix field.

Network Prefix: Contains the assigned unicast network prefix. The maximum length is 64 bits. Any unused prefix bits are not required to be zeroed anymore—a strict requirement from RFC 3306. RFC 3956 relaxes this requirement. The “plen” is used to construct the RP address, but the group address can contain a longer part of the unicast prefix.

Group ID: The address owner assigned 32-bit multicast group ID.

That means embedding an RP address in the multicast group is a simple operation. We need only examine the Flgs, RIID, and Network Prefix fields for address derivation or loading. Figure 6-15 illustrates this process.

When using embedded RP, there is no need to configure routers with RP information or to use a dynamic protocol to perform RP mapping and propagation. Instead, multicast-enabled devices can extract and use the RP information from the group address, as shown above. That means a large number of RPs can be deployed anywhere, either local to the PIM domain or on the Internet for inter-domain multicast routing (multicast routing that typically occurs between two or more organizations or the Internet). No additional protocol or PIM6 changes are required to support embedded RP, it is built-in. Cisco router operating systems are programmed to automatically derive the RP information, making additional configuration unnecessary.

Any routers acting as a physical RP for an embedded group must have a statically configured RP address using an address assigned to one interface on the RP router. Routers automatically search for embedded RP group addresses in MLD reports or PIM messages and data packets coming from the source. When an embedded RP address is discovered, the router performs the group-to-RP mapping using the newly learned RP address. If no physical RP exists that matches the learned address, or if the learned RP address is not in the unicast RIB, then the router will not be able to complete the multicast group state. Embedded RP does not allow administrators to escape the need for a physical RP.

Also, keep in mind that a router can learn just one RP address for a multicast group using embedded RP. That means that you cannot have redundancy with embedded RP, because you cannot embed more than one RP address in the group. You can, however, use an Anycast RP set as the physical RP component, so long as the derived embedded RP address always points to the Anycast RP address configured on each router in the RP set. Also, as of this writing, embedded RP is not compatible with bidirectional PIM.

Let us adjust our BSR RP example (shown earlier in Figure 6-12) to include an embedded RP, removing the BSR configuration and replacing it with a static RP configuration. Below are the example configurations for each router. We statically configure our RP on R1 with a new Loopback400 interface that is assigned the IP address 1234:5678:9ABC::1/128 from our example group FF76:0150:1234:5678:9ABC::1234 (illustrated by Figure 6-15). On routers R2 and R3, we can now remove any irrelevant RP information. In fact, outside of the command ipv6 multicast-routing, no other multicast configuration is required on R2 and R3. We will, however, add an MLD join on R3’s Loopback0 interface to simulate a host using the embedded RP group address from the example above, group FF76:0150:1234:5678:9ABC::1234. Figure 6-16 depicts the updated topology.

Example 6-15 shows the router configurations for embedded RP support.

Example 6-15 Configuration to Support Embedded RP

Click here to view code image

---

RP: R1
hostname R1
!
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
 no ip address
 ipv6 address 2002:11:1:1::1/128
 ipv6 enable
 ipv6 router isis TEST
!
interface Loopback400
 no ip address
 ipv6 address 1234:5678:9ABC::1
 ipv6 enable
 ipv6 router isis TEST
!
interface Ethernet0/0
 no ip address
 ipv6 address 2002:10:1:1::1/64
 ipv6 enable
 ipv6 router isis TEST
!
router isis TEST
 net 49.0001.0000.0001.00
!
!

---

RP: R2
hostname R2
!
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
 no ip address
 ipv6 address 2002:11:1:1::2/128
 ipv6 enable
 ipv6 router isis TEST
!
interface Ethernet0/0
 no ip address
 ipv6 address 2002:10:1:1::2/64
 ipv6 enable
 ipv6 router isis TEST
!
interface Ethernet1/0
 no ip address
 ipv6 address 2002:10:1:2::1/64
 ipv6 enable
 ipv6 router isis TEST
!
router isis TEST
 net 49.0002.0000.0002.00
!

---

R3
hostname R3
!
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
 no ip address
 ipv6 address 2002:11:1:1::3/128
 ipv6 enable
 ipv6 router isis TEST
 ipv6 mld join-group FF76:0150:1234:5678:9ABC::1234
!
interface Loopback500
 no ip address
 ipv6 address 2002:F:F:F::1/128
 ipv6 enable
 ipv6 router isis TEST
!
interface Ethernet0/1
 no ip address
 ipv6 address 2002:10:1:2::2/64
 ipv6 enable
 ipv6 router isis TEST
!
router isis TEST
 net 49.0002.0000.0003.00
!

---

Look at what happens on R3 first. R3 needs to have an RP-to-group mapping for the joined group of FF76:0150:1234:5678:9ABC::1234. Issuing a show ipv6 pim group-map on R3 reveals whether this mapping has occurred, as in Example 6-16.

Example 6-16 Verifying RP-to-Group Mapping

Click here to view code image

---

R3#show ipv6 pim group-map
IP PIM Group Mapping Table
(* indicates group mappings being used)

FF76:150:1234:5678:9ABC::/112*
    SM, RP: 1234:5678:9ABC::1
    RPF: ,::
    Info source: Embedded
    Uptime: 00:12:32, Groups: 1

---

Great! The group is in fact learned by R3 through the MLD join and the router has derived the RP 1234:5678:9ABC::1 from the group. That’s good news. If the R1 RP is properly configured, we should be able to reach R3. Because no packets have been sourced to the group address yet, R1 should not yet have a group mapping for FF76:0150:1234:5678:9ABC::1234, as shown by executing the same show ipv6 pim group-map command on R1 in Example 6-17.

Example 6-17 PIM6 Group Mappings

Click here to view code image

---

R1#show ipv6 pim group-map
IP PIM Group Mapping Table
(* indicates group mappings being used)

FF05::/64*
    SM, RP: 2002:F:F:F::1
    RPF: Tu2,2002:F:F:F::1 (us)
    Info source: Static
    Uptime: 00:37:08, Groups: 0
FF70::/15*
    NO
    Info source: Default
    Uptime: 00:37:51, Groups: 0

---

If we now send an IPv6 ping packet sourced from interface Ethernet0/0 on router R1, the group mapping should be derived from the embedded RP in the packet, and R1 should forward the packet toward R3 with success, as in Example 6-18.

Example 6-18 IPv6 Multicast Group Ping

Click here to view code image

---

R1#ping ipv6 FF76:0150:1234:5678:9ABC::1234
Output Interface: ethernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF76:150:1234:5678:9ABC::1234, timeout is
  2 ­seconds:
Packet sent with a source address of 2002:10:1:1::1

Reply to request 0 received from 2002:11:1:1::3, 39 ms
Reply to request 1 received from 2002:11:1:1::3, 1 ms
Reply to request 2 received from 2002:11:1:1::3, 1 ms
Reply to request 3 received from 2002:11:1:1::3, 1 ms
Reply to request 4 received from 2002:11:1:1::3, 1 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/8/39 ms
5 multicast replies and 0 errors.

---

Now, if we reissue the show ipv6 pim group-map command, we should find that R1, the RP, has learned the group mapping and constructed the appropriate RPF neighbor, as demonstrated in Example 6-19.

Example 6-19 Source Added to PIM6 Group Mapping

Click here to view code image

---

R1#show ipv6 pim group-map
IP PIM Group Mapping Table
(* indicates group mappings being used)

FF76:150:1234:5678:9ABC::/112*
    SM, RP: 1234:5678:9ABC::1
    RPF: Et0/0, FE80::A8BB:CCFF:FE00:200
    Info source: Embedded
    Uptime: 00:00:26, Groups: 1

---

R2, the router between the source (R1) and the receiver (R3), needs to accept the incoming IPv6 multicast packet, derive the embedded RP information, create the appropriate group mappings and state entries, and, finally, forward the packet down the OIL to R3. If we issue the show ipv6 pim group-map and show ipv6 mroute commands on R2, we should see that this process is in fact complete, as demonstrated in Example 6-20.

Example 6-20 Final Group State in the MRIB

Click here to view code image

---

R2#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
       C - Connected, L - Local, I - Received Source Specific Host Report,
       P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
       J - Join SPT, Y - Joined MDT-data group,
       y - Sending to MDT-data group
       g - BGP signal originated, G - BGP Signal received,
       N - BGP Shared-Tree Prune received, n - BGP C-Mroute suppressed,
       q - BGP Src-Active originated, Q - BGP Src-Active received
       E - Extranet
Timers: Uptime/Expires
Interface state: Interface, State

(*, FF76:150:1234:5678:9ABC::1234), 00:07:22/00:03:07, RP 1234:5678:9ABC::1,
flags: S
  Incoming interface: Ethernet0/0
  RPF nbr: FE80::A8BB:CCFF:FE00:100
  Immediate Outgoing interface list:
    Ethernet1/0, Forward, 00:07:22/00:03:07

R2#show ipv6 pim group-map
IP PIM Group Mapping Table
(* indicates group mappings being used)

FF76:150:1234:5678:9ABC::/112*
    SM, RP: 1234:5678:9ABC::1
    RPF: Et0/0,FE80::A8BB:CCFF:FE00:100
    Info source: Embedded
    Uptime: 00:12:34, Groups: 1

---

As this example shows, configuring embedded RP for PIM6 is very easy. It is enabled by default. R2 and R3 have virtually no PIM configuration requirements. Simply enable IPv6 multicast-routing and you are off to the races.

Which brings us to one final consideration:

Any multicast host can embed an RP address, meaning host applications on multicast sources. That means that if the embedded RP information is incorrectly configured by that application, the infrastructure could have erroneous mappings for multicast groups. Embedded RP functionality is enabled by default on all Cisco routers when IPv6 multicast routing is enabled. That can pose an issue if the group has a large organizational scope. It also means that there is a chance that a low-end router could end up becoming the RP for many of high data rate sources. If these are concerns in the multicast domain, it may be best to use BSR and/or Anycast RP and to disable embedded RP capability altogether.

Use the following IOS-XE command to disable embedded RP functionality:

Click here to view code image

no ipv6 pim [vrf vrf-name] rp embedded

One of the interesting aspects of IPv6 is the notion of a link-local address. These are intended for local device-to-device communication only, and it must be well understood because the link-local address is used for Neighbor Discovery Protocol (NDP), device communication, and so on.

Multicast Listener Discovery (MLD) protocol is used to discover devices requesting access to multicast streams at Layer 2. There are currently two implementations of MLD, version 1 and version 2. Layer 2 switches use MLD to direct traffic to the appropriate destinations.

Previous knowledge of protocol independent multicast (PIM) for IPv4 networks makes it easy to understand how PIM6 is implemented. Just as in IPv4, an additional routing protocol is not required to implement PIM6. The PIM6 modes of operation include general any-source multicast (ASM), source-specific multicast (SSM), and embedded RP groups.