In my attempts to drill IPv6 into my skull in time for my next CCIE lab attempt, I started playing around with some of the multicasting aspects of it on my GNS3 lab.  When I typed in “ipv6 multicast-routing”, imagine my surprise when I saw a tunnel interface pop up.  I tried to get rid of it, only to be told by IOS, “%Tunnel0 used by PIM for Registering, configuration no allowed.”

Now, thanks to Greg Ferro, I know that tunnels are an evil, evil thing used to duct tape the Internet together.  So I started researching why the router suddenly started spewing tunnels all over my finely constructed lab.  It took tons and tons of digging before I was finally able to come up with the answer, buried in a PDF.  I’m reprinting the explanation here so as to hopefully get it indexed by Google to aid whomever else may need to find it in a hurry.

The PIM-SM Draft suggests that source registering be accomplished using a virtual tunnel interface. This use of virtual tunnel interfaces permits consistent PIM state handling for the registration process. During the registration process, the tunnel interface appears like any other interface in the Outgoing Interface List for the multicast data source (S,G) state with all the rules valid for the state management. In Cisco IOS Software implementations, an automatic tunnel is created as soon as an RP is known; one virtual tunnel for each active RP in the network. While the PIM-SM Draft suggests that the tunnel should be deleted after each process of registering, Cisco IOS Software keeps each tunnel as long as the RP is known. The additional implementation-specific advantage of these tunnel interfaces is simplification of the register data encapsulation—it does not have to be handled specifically in the PIM part of the code. Instead, generic IP code can be used to perform the encapsulation such that the PIM Register packet is just forwarded into the tunnel for encapsulation. Use of generic tunnelling code in Cisco IOS Software enables the possible handling of PIM Register packets in fast (not process-switched) path if available.
These virtual tunnels are always unidirectional (transmit only) and automatic—the tunnel interface status immediately goes to up when it is created. However, the line protocol stays in down status until the there is a valid RPF interface to the RP (for example, unicast connectivity through unicast BGP in the default configuration is not enough, as BGP is not used for RPF check) and also a unicast route exists in the unicast RIB to the RP. Sources can successfully register only when the tunnel interface is fully up.
It is important to note that while all PIM Register messages from the registering routers (first-hop routers) are sent to the RP via these virtual tunnels, all PIM Register-Stop messages are sent directly from the RP to the registering router and do not use virtual tunnels.
The handling of dynamic changes of RP information is not fully resolved in the first IPv6 Multicast implementation—it is a generic Cisco IOS Software issue, which can not handle properly deleting of interfaces (the register tunnels in this case) and reusing of the same interface number by a newly created tunnel. This can cause problems when BSR and embedded RP are used to distribute RP information (when the RP information dynamically changes).

(Copied from THIS PDF)

So, it appears that these tunnels are here to stay.  They are used for PIM registrations and appear to be unidirectional and pointed toward whatever RP is setup.  So, if you find yourself configuring IPv6 multicast and you suddenly become inundated with a swarm of tunnels, just relax.  You don’t need to break out the duct tape just yet.