An IPv6 address must be configured on an interface before the interface can forward IPv6 traffic. Configuring a site-local or global IPv6 address on an interface automatically configures a link-local address and activates IPv6 for that interface. Additionally, the configured interface automatically joins the following required multicast groups for that link:

• Solicited-node multicast group FF02:0:0:0:0:1:FF00::/104 for each unicast and anycast address assigned to the interface

  Note	The solicited-node multicast address is used in the neighbor discovery process.

• All-nodes link-local multicast group FF02::1
• All-routers link-local multicast group FF02::2

IPv6 includes support for global and nonglobal addresses. This section describes the usage of IPv6 addresses of different scopes.

A scope zone, or a simply a zone, is a connected region of topology of a given scope. For example, the set of links connected by routers within a particular site, and the interfaces attached to those links, comprise a single zone of site-local scope.

A zone is a particular instance of a topological region (for example, Zone1's site or Zone2's site), whereas a scope is the size of a topological region (for example, a site or a link). The zone to which a particular nonglobal address pertains is not encoded in the address itself, but rather is determined by context, such as the interface from which it is sent or received. Therefore, addresses of a given nonglobal scope may be reused in different zones of that scope. For example, Zone1's site and Zone2's site may each contain a node with site-local address FEC0::1.

Zones of the different scopes are instantiated as follows:

• Each link, and the interfaces attached to that link, comprises a single zone of link-local scope (for both unicast and multicast).
• There is a single zone of global scope (for both unicast and multicast), comprising all the links and interfaces in the Internet.
• The boundaries of zones of scope other than interface-local, link-local, and global must be defined and configured by network administrators. A site boundary serves as such for both unicast and multicast.

Zone boundaries are relatively static features and do not change in response to short-term changes in topology. Therefore, the requirement that the topology within a zone be "connected" is intended to include links and interfaces that may be connected only occasionally. For example, a residential node or network that obtains Internet access by dialup to an employer's site may be treated as part of the employer's site-local zone even when the dialup link is disconnected. Similarly, a failure of a router, interface, or link that causes a zone to become partitioned does not split that zone into multiple zones; rather, the different partitions are still considered to belong to the same zone.

Zones have the following additional properties:

• Zone boundaries cut through nodes, not links (the global zone has no boundary, and the boundary of an interface-local zone encloses just a single interface.)
• Zones of the same scope cannot overlap; that is, they can have no links or interfaces in common.
• A zone of a given scope (less than global) falls completely within zones of larger scope; that is, a smaller scope zone cannot include more topology than any larger scope zone with which it shares any links or interfaces.
• Each interface belongs to exactly one zone of each possible scope.

The MLD access group provides receiver access control in Cisco IOS IPv6 multicast routers. This feature limits the list of groups a receiver can join, and it allows or denies sources used to join SSM channels.

The explicit tracking feature allows a router to track the behavior of the hosts within its IPv6 network. This feature also enables the fast leave mechanism to be used with MLD version 2 host reports.

IPv6 multicast by design allows any host in the network to become a receiver or a source for a multicast group. Therefore, multicast access control is needed to control multicast traffic in the network. Access control functionality consists mainly of source access control and accounting, receiver access control and accounting, and provisioning of this access control mechanism.

Multicast access control provides an interface between multicast and authentication, authorization, and accounting (AAA) for provisioning, authorizing, and accounting at the last-hop router, receiver access control functions in multicast, and group or channel disabling capability in multicast.

When you deploy a new multicast service environment, it is necessary to add user authentication and provide a user profile download on a per-interface basis. The use of AAA and IPv6 multicast supports user authentication and downloading of the user profile in a multicast environment.

The event that triggers the download of a multicast access-control profile from the RADIUS server to the access router is arrival of an MLD join on the access router. When this event occurs, a user can cause the authorization cache to time out and request download periodically or use an appropriate multicast clear command to trigger a new download in case of profile changes.

Accounting occurs via RADIUS accounting. Start and stop accounting records are sent to the RADIUS server from the access router. In order for you to track resource consumption on a per-stream basis, these accounting records provide information about the multicast source and group. The start record is sent when the last-hop router receives a new MLD report, and the stop record is sent upon MLD leave or if the group or channel is deleted for any reason.

The MLD proxy feature provides a mechanism for a router to generate MLD membership reports for all (*, G)/(S, G) entries or a user-defined subset of these entries on the router's upstream interface. The MLD proxy feature enables a device to learn proxy group membership information, and forward multicast packets based upon that information.

If a router is acting as RP for mroute proxy entries, MLD membership reports for these entries can be generated on user specified proxy interface.

IPv6 multicast provides support for intradomain multicast routing using PIM-SM. PIM-SM uses unicast routing to provide reverse-path information for multicast tree building, but it is not dependent on any particular unicast routing protocol.

PIM-SM is used in a multicast network when relatively few routers are involved in each multicast and these routers do not forward multicast packets for a group, unless there is an explicit request for the traffic. PIM-SM distributes information about active sources by forwarding data packets on the shared tree. PIM-SM initially uses shared trees, which requires the use of an RP.

Requests are accomplished via PIM joins, which are sent hop by hop toward the root node of the tree. The root node of a tree in PIM-SM is the RP in the case of a shared tree or the first-hop router that is directly connected to the multicast source in the case of a shortest path tree (SPT). The RP keeps track of multicast groups and the hosts that send multicast packets are registered with the RP by that host's first-hop router.

As a PIM join travels up the tree, routers along the path set up multicast forwarding state so that the requested multicast traffic will be forwarded back down the tree. When multicast traffic is no longer needed, a router sends a PIM prune up the tree toward the root node to prune (or remove) the unnecessary traffic. As this PIM prune travels hop by hop up the tree, each router updates its forwarding state appropriately. Ultimately, the forwarding state associated with a multicast group or source is removed.

A multicast data sender sends data destined for a multicast group. The designated router (DR) of the sender takes those data packets, unicast-encapsulates them, and sends them directly to the RP. The RP receives these encapsulated data packets, de-encapsulates them, and forwards them onto the shared tree. The packets then follow the (*, G) multicast tree state in the routers on the RP tree, being replicated wherever the RP tree branches, and eventually reaching all the receivers for that multicast group. The process of encapsulating data packets to the RP is called registering, and the encapsulation packets are called PIM register packets.

• Designated Router
  
• Rendezvous Point
  
• PIMv6 Anycast RP Solution Overview
  

PIM routers in a domain must be able to map each multicast group to the correct RP address. The BSR protocol for PIM-SM provides a dynamic, adaptive mechanism to distribute group-to-RP mapping information rapidly throughout a domain. With the IPv6 BSR feature, if an RP becomes unreachable, it will be detected and the mapping tables will be modified so that the unreachable RP is no longer used, and the new tables will be rapidly distributed throughout the domain.

Every PIM-SM multicast group needs to be associated with the IP or IPv6 address of an RP. When a new multicast sender starts sending, its local DR will encapsulate these data packets in a PIM register message and send them to the RP for that multicast group. When a new multicast receiver joins, its local DR will send a PIM join message to the RP for that multicast group. When any PIM router sends a (*, G) join message, the PIM router needs to know which is the next router toward the RP so that G (Group) can send a message to that router. Also, when a PIM router is forwarding data packets using (*, G) state, the PIM router needs to know which is the correct incoming interface for packets destined for G, because it needs to reject any packets that arrive on other interfaces.

A small set of routers from a domain are configured as candidate bootstrap routers (C-BSRs) and a single BSR is selected for that domain. A set of routers within a domain are also configured as candidate RPs (C-RPs); typically, these routers are the same routers that are configured as C-BSRs. Candidate RPs periodically unicast candidate-RP-advertisement (C-RP-Adv) messages to the BSR of that domain, advertising their willingness to be an RP. A C-RP-Adv message includes the address of the advertising C-RP, and an optional list of group addresses and mask length fields, indicating the group prefixes for which the candidacy is advertised. The BSR then includes a set of these C-RPs, along with their corresponding group prefixes, in bootstrap messages (BSMs) it periodically originates. BSMs are distributed hop-by-hop throughout the domain.

Bidirectional BSR support allows bidirectional RPs to be advertised in C-RP messages and bidirectional ranges in the BSM. All routers in a system must be able to use the bidirectional range in the BSM; otherwise, the bidirectional RP feature will not function.

PIM-SSM is the routing protocol that supports the implementation of SSM and is derived from PIM-SM. However, unlike PIM-SM where data from all multicast sources are sent when there is a PIM join, the SSM feature forwards datagram traffic to receivers from only those multicast sources that the receivers have explicitly joined, thus optimizing bandwidth utilization and denying unwanted Internet broadcast traffic. Further, instead of the use of RP and shared trees, SSM uses information found on source addresses for a multicast group. This information is provided by receivers through the source addresses relayed to the last-hop routers by MLD membership reports, resulting in shortest-path trees directly to the sources.

In SSM, delivery of datagrams is based on (S, G) channels. Traffic for one (S, G) channel consists of datagrams with an IPv6 unicast source address S and the multicast group address G as the IPv6 destination address. Systems will receive this traffic by becoming members of the (S, G) channel. Signaling is not required, but receivers must subscribe or unsubscribe to (S, G) channels to receive or not receive traffic from specific sources.

MLD version 2 is required for SSM to operate. MLD allows the host to provide source information. Before SSM will run with MLD, SSM must be supported in the Cisco IPv6 router, the host where the application is running, and the application itself.

• SSM Mapping for IPv6
  
• PIM Shared Tree and Source Tree (Shortest-Path Tree)
  
• Reverse Path Forwarding
  

When an IPv6 interior gateway protocol is used to build the unicast routing table, the procedure to detect the upstream router address assumes the address of a PIM neighbor is always same as the address of the next-hop router, as long as they refer to the same router. However, it may not be the case when a router has multiple addresses on a link.

Two typical situations can lead to this situation for IPv6. The first situation can occur when the unicast routing table is not built by an IPv6 interior gateway protocol such as multicast BGP. The second situation occurs when the address of an RP shares a subnet prefix with downstream routers (note that the RP router address has to be domain-wide and therefore cannot be a link-local address).

The routable address hello option allows the PIM protocol to avoid such situations by adding a PIM hello message option that includes all the addresses on the interface on which the PIM hello message is advertised. When a PIM router finds an upstream router for some address, the result of RPF calculation is compared with the addresses in this option, in addition to the PIM neighbor's address itself. Because this option includes all the possible addresses of a PIM router on that link, it always includes the RPF calculation result if it refers to the PIM router supporting this option.

Because of size restrictions on PIM messages and the requirement that a routable address hello option fits within a single PIM hello message, a limit of 16 addresses can be configured on the interface.

Bidirectional PIM allows multicast routers to keep reduced state information, as compared with unidirectional shared trees in PIM-SM. Bidirectional shared trees convey data from sources to the RPA and distribute them from the RPA to the receivers. Unlike PIM-SM, bidirectional PIM does not switch over to the source tree, and there is no register encapsulation of data from the source to the RP.

A single designated forwarder (DF) exists for each RPA on every link within a bidirectional PIM domain (including multiaccess and point-to-point links). The only exception is the RPL on which no DF exists. The DF is the router on the link with the best route to the RPA, which is determined by comparing MRIB-provided metrics. A DF for a given RPA forwards downstream traffic onto its link and forwards upstream traffic from its link toward the rendezvous point link (RPL). The DF performs this function for all bidirectional groups that map to the RPA. The DF on a link is also responsible for processing Join messages from downstream routers on the link as well as ensuring that packets are forwarded to local receivers discovered through a local membership mechanism such as MLD.

Bidirectional PIM offers advantages when there are many moderate or low-rate sources. However, the bidirectional shared trees may have worse delay characteristics than do the source trees built in PIM-SM (depending on the topology).

Only static configuration of bidirectional RPs is supported in IPv6.

Distributed Multicast Forwarding Information Base (MFIB) is used to switch multicast IPv6 packets on distributed platforms. Distributed MFIB may also contain platform-specific information on replication across line cards. The basic MFIB routines that implement the core of the forwarding logic are common to all forwarding environments.

dMFIB implements the following functions:

• Distributes a copy of the MFIB to the line cards.
• Relays data-driven protocol events generated in the line cards to PIM.
• Provides an MFIB platform application program interface (API) to propagate MFIB changes to platform-specific code responsible for programming the hardware acceleration engine. This API also includes entry points to switch a packet in software (necessary if the packet is triggering a data-driven event) and to upload traffic statistics to the software.
• Provides hooks to allow clients residing on the RP to read traffic statistics on demand. Distributed MFIB does not periodically upload these statistics to the RP.

The combination of distributed MFIB and MRIB subsystems allows the device to have a "customized" copy of the MFIB database in each line card and to transport MFIB-related platform-specific information from the RP to the line cards.

1.    enable

2.    configure terminal

3.    interface type number

4.    ipv6 mld join-group [group-address] [include | exclude] {source-address | source-list [acl]}

5.    ipv6 mld access-group access-list-name

6.    ipv6 mld static-group group-address ] [include| exclude] {source-address | source-list [acl]}

7.    ipv6 mld query-max-response-time seconds

8.    ipv6 mld query-timeout seconds

9.    ipv6 mld query-interval seconds

10.    exit

11.    show ipv6 mld [vrf vrf-name] groups [link-local] [group-name | group-address] [interface-type interface-number] [detail | explicit]

12.    show ipv6 mld groups summary

13.    show ipv6 mld [vrf vrf-name] interface [type number]

14.    debug ipv6 mld [group-name | group-address | interface-type]

15.    debug ipv6 mld explicit [group-name | group-address

Per-interface and global MLD limits operate independently of each other. Both per-interface and global MLD limits can be configured on the same router. The number of MLD limits, globally or per interface, is not configured by default; the limits must be configured by the user. A membership report that exceeds either the per-interface or the global state limit is ignored.

• Implementing MLD Group Limits Globally
  
• Implementing MLD Group Limits per Interface
  

1.    enable

2.    configure terminal

3.    interface type number

4.    ipv6 mld explicit-tracking access-list-name

• Prerequisites
  
• Restrictions
  
• Enabling AAA Access Control for IPv6 Multicast
  
• Specifying Method Lists and Enabling Multicast Accounting
  
• Disabling the Router from Receiving Unauthenticated Multicast Traffic
  

1.    enable

2.    configure terminal

3.    ipv6 mld host-proxy [group-acl

4.    ipv6 mld host-proxy interface [group-acl]

5.    show ipv6 mld host-proxy [interface-type interface-number] group [group-address]]

• Resetting Authorization Status on an MLD Interface
  

1.    enable

2.    clear ipv6 mld [vrf vrf-name] traffic

3.    show ipv6 mld [vrf vrf-name] traffic

1.    enable

2.    clear ipv6 mld [vrf vrf-name] counters interface-type

1.    enable

2.    configure terminal

3.    ipv6 pim [vrf vrf-name] rp-address ipv6-address [group-access-list] [bidir]

4.    exit

5.    show ipv6 pim [vrf vrf-name] interface [state-on] [state-off] [type number]

6.    show ipv6 pim [vrf vrf-name] group-map [group-name | group-address] | [group-range | group-mask] [info-source {bsr | default | embedded-rp | static}]

7.    show ipv6 pim [vrf vrf-name] neighbor [detail] [interface-type interface-number | count]

8.    show ipv6 pim [vrf vrf-name] range-list[config] [rp-address | rp-name]

9.    show ipv6 pim [vrf vrf-name] tunnel [interface-type interface-number]

10.    debug ipv6 pim [group-name | group-address | interface interface-type | bsr | group | mvpn | neighbor]

1.    enable

2.    configure terminal

3.    ipv6 pim [vrf vrf-name] spt-threshold infinity [group-list access-list-name]

4.    ipv6 pim [vrf vrf-name] accept-register {list access-list | route-map map-name}

5.    interface type number

6.    ipv6 pim dr-priority value

7.    ipv6 pim hello-interval seconds

8.    ipv6 pim join-prune-interval seconds

9.    exit

10.    show ipv6 pim [vrf vrf-name] join-prune statistic [interface-type]

1.    enable

2.    configure terminal

3.    ipv6 pim [vrf vrf-name] rp-address ipv6-address [group-access-list] [bidir]

4.    exit

5.    show ipv6 pim [vrf vrf-name] df [interface-type interface-number] [rp-address]

6.    show ipv6 pim [vrf vrf-name] df winner[interface-type interface-number] [rp-address]

1.    enable

2.    clear ipv6 pim [vrf vrf-name] traffic

3.    show ipv6 pim [vrf vrf-name] traffic

1.    enable

2.    clear ipv6 pim [vrf vrf-name] topology [group-name | group-address]

3.    show ipv6 mrib [vrf vrf-name] client [filter] [name {client-name | client-name : client-id}]

4.    show ipv6 mrib [vrf vrf-name] route [link-local| summary | [sourceaddress-or-name | *] [groupname-or-address [prefix-length]]]

5.    show ipv6 pim [vrf vrf-name] topology [groupname-or-address [sourcename-or-address] | link-local | route-count [detail]]

6.    debug ipv6 mrib [vrf vrf-name] client

7.    debug ipv6 mrib [vrf vrf-name] io

8.    debug ipv6 mrib proxy

9.    debug ipv6 mrib [vrf vrf-name] route [group-name | group-address]

10.    debug ipv6 mrib [vrf vrf-name] table

1.    enable

2.    configure terminal

3.    ipv6 pim [vrf vrf-name] bsr candidate bsr ipv6-address[hash-mask-length] [priority priority-value]

4.    interface type number

5.    ipv6 pim bsr border

6.    exit

7.    show ipv6 pim [vrf vrf-name] bsr {election | rp-cache | candidate-rp}

1.    enable

2.    configure terminal

3.    ipv6 pim [vrf vrf-name] bsr candidate rp ipv6-address [group-list access-list-name] [priority priority-value] [interval seconds] [scope scope-value] [bidir]

4.    interface type number

5.    ipv6 pim bsr border

1.    enable

2.    configure terminal

3.    ipv6 pim [vrf vrf-name] bsr candidate bsr ipv6-address [hash-mask-length] [priority priority-value]

4.    ipv6 pim [vrf vrf-name] bsr candidate rp ipv6-address [group-list access-list-name] [priority priority-value] [interval seconds] [scope scope-value] [bidir]

5.    interface type number

6.    ipv6 multicast boundary scope scope-value

1.    enable

2.    configure terminal

3.    ipv6 pim [vrf vrf-name] bsr announced rp ipv6-address [group-list access-list-name] [priority priority-value] [bidir] [scope scope-value]

1.    enable

2.    configure terminal

3.    router bgp as-number

4.    neighbor peer-group-name peer-group

5.    neighbor {ip-address | ipv6-address | peer-group-name} remote-as as-number

6.    address-family ipv6 [unicast | multicast]

7.    neighbor {ip-address | peer-group-name | ipv6-address} activate

8.    neighbor {ip-address | ipv6-address} peer-group peer-group-name

• What to Do Next
  

1.    enable

2.    configure terminal

3.    router bgp as-number

4.    address-family ipv6 [unicast | multicast]

5.    network ipv6-address / prefix-length

1.    enable

2.    configure terminal

3.    router bgp as-number

4.    address-family ipv6 [vrf vrf-name] [unicast | multicast | vpnv6]

5.    redistribute bgp [process-id] [metric metric-value] [route-map map-name] [source-protocol-options]

6.    exit

Caution

Changing the administrative distance of BGP internal routes is not recommended. One problem that can occur is the accumulation of routing table inconsistencies, which can break routing.

1.    enable

2.    configure terminal

3.    router bgp as-number

4.    address-family ipv6 [unicast | multicast}

5.    distance bgp external-distance internal-distance local-distance

1.    enable

2.    configure terminal

3.    router bgp as-number

4.    address-family ipv6 [unicast | multicast}

5.    neighbor ipv6-address translate-update ipv6 multicast [unicast]

1.    enable

2.    clear bgp ipv6 {unicast | multicast} {* | autonomous-system-number | ip-address | ipv6-address | peer-group peer-group-name} [soft] [in | out]

1.    enable

2.    clear bgp ipv6 {unicast | multicast} external [soft] [in | out]

3.    clear bgp ipv6 {unicast | multicast} peer-group name

1.    enable

2.    clear bgp ipv6 {unicast | multicast} dampening [ipv6-prefix prefix-length]

1.    enable

2.    clear bgp ipv6 {unicast | multicast} flap-statistics [ipv6-prefix/prefix-length | regexp regexp | filter-list list]

1.    enable

2.    configure terminal

3.    interface type number

4.    ipv6 address {ipv6-address / prefix-length | prefix-name sub-bits / prefix-length}