Sunday, 5 January 2014

IPv6 multicast

I mentioned a while back that I'd been looking at IPv6 multicast and enabling it on our backbone network.  We were in the process of moving to a new office building at work and setting up our office network such that we were a regular internal eBGP client on the backbone (same as any other department or college), rather than making it a directly-connected network.  This introduced the challenge of making interdomain IPv6 multicast work.

All the information needed is covered in CiscoPress's Deploying IPv6 Networks (Chapter 6 - "Providing IPv6 Multicast Services"), although it does assume that you're familiar with both IPv6 basics and IPv4 multicast in significant detail.

In practice, enabling IPv6 multicast was almost trivially simple.  Most of the complication comes from the different group address types — the different types control interdomain vs local domain-only and ASM vs SSM.

However, multicast is one area where IPv6 really shines over IPv4: the clearly-defined group address structure, inherent scope, as well as automatically providing holders of global IPv6 address space a set of group addresses (similar to that in RFC6034 for IPv4),

A summary of the main differences are (some of which are Cisco-specific, but likely to be the case on other equipment):
  • When IPv6 multicast routing is enabled on a Cisco router (with global command ipv6 multicast-routing) then all IPv6-enabled interfaces automatically start to route it — there's no need to issue an IPv6-equivalent of the interface command ip pim sparse-mode (although you can disable it on a per-interface basis with no ipv6 mld router / no ipv6 pim, which was important for us!).
  • Scope is an inherent part of IPv6 multicast group addresses (being the fourth nibble) and is clearly specified on a particular interface with (e.g.) ipv6 multicast boundary scope organization-local — there is no need to muck about with boundary access lists containing a set of arbitrary group addresses.
  • Source Specific Multicast (SSM) was designed-in from the start — there is no need to explicitly enable it, nor designate certain address ranges to use it.
  • IPv6 PIM only uses Sparse Mode (SM) and SSM — there is none of the baggage of Dense Mode or Sparse-Dense Mode.
  • PIM BSR and RP discovery protocols were built-in early on — there was no need for an alternative protocol (such as Cisco AutoRP).  The commands for configuring this are similar, but not the same, as for IPv4 but are generally simpler because of the cleaner addressing structure (in our case, we had no need to separate the RPs for local groups from global groups, as we do with IPv4).
  • There is no need for an MSDP for IPv6 — interdomain multicast is provided through either SSM or Embedded RP (where the address of the RP is contained within the group address itself).
  • Multicast Listener Discovery (MLD) takes the place of IGMP.

Address types, capabilities and Embedded RP


The type of group address chosen will determine how a group address is handled and what it is capable of:
Address typePrefixesASM?SSM?Interdomain?Embedded RP?
Global ASM with Embedded RPff7M::/12YesYesYesYes
Global SSMff3M::/12NoYesYesNo
Local ASMff3M:00KL::/32 and ff0M::/12YesYesNoNo

ASM is where the main difference lies: because there is no MSDP in IPv6, there is no way for a PIM domain to know about sources of traffic in other domains — IPv6 solves this by using Embedded RP.

As its name suggests, Embedded RP is where the address of the RP for a particular group is contained within the group address itself.  As addresses are still 128 bits long and you need space for the multicast prefix, scope and group, only a limited number of bits are available for the RP itself.

Addresses are in the form ff7M:0GHI:... — the 7 indicates an Embedded RP address; M is the scope (as per normal); G is the final nibble of the RP address and HI gives the number of bits from the remainder of the address (after the first 32) to be used as the leading part of the address of the RP.  The remaining bits (128 - 32 - KL) are available for the group addresses themselves.

For example, the University of Cambridge uses addresses in the format ff7M:a2c:2001:630:210::/76 — this gives an RP address of 2001:630:210::a (0x2c = 44 bits after the first 32, and ending with a).  The remaining (128 - 76 =) 52 bits then chopped with the first 12 matching an institution's prefix and the final 40 being available for allocation by the institution.

The provide the Embedded RP, a simple command is required on the selected router: ipv6 pim rp-address 2001:630:210::a.  Cisco have a special Anycast RP feature to provide redundancy for this but it isn't available on our Catalyst 6500 series platform.

Lots of information about all this is published on the our public website.

Fun and games


So what was the "excitement" I mentioned in an earlier post?  Well, when this was enabled, it caused some of our servers to immediately and repeatedly crash and reboot.

The issue has still not been resolved and IPv6 remains disabled on our central server network.  I won't mention which OS and the exact cause, but it is unlikely most people will run into it (although it affects us significantly, as it's one of the reason to run thing on this platform) and that the OS is closed-source so we are dependent on the manufacturer resolving it.

1 comment: