How to Embed RP & VLC Multicasting with IPv6

When you put an address on a letter, you're only specifying one thing: the location of the recipient. The postal service uses that information to figure out which sorting stations, which planes, trains and boats that piece of mail should take to get to a U.S. post office. And then once there, which mail carrier's route it should be carried on to make it to its destination. The postal service is responsible for figuring all of that out based on the address you wrote. But what if the address you wrote on a letter included all of that information, all the way down to the name of the mail carrier who'll drop it off? If that information was available to you, it could save the postal service a lot of time and energy.

That's a rough metaphor for something that can sometimes happen in networking, when a rendezvous point's (RP) IP address gets embedded inside of an IPv6 multicast group address. Squeezing an RP's IP address down inside a multicast group address is an impressive trick because it means some poor network administrator doesn't have to manually configure every device on a network with all RPs of each multicast group on the network. Instead, when a host initiates its request to join a multicast group, the very address it uses to ask about the multicast group can include what router to forward the inquiry to.

If that sounds confusing or technical, read on. In this post, we're covering how to train a given network to dynamically learn who the rendezvous point for the network is without using additional protocols like boundary state routing and without statically configuring that information on every single router.

What is Multicast?

Multicast is a form of transmission that allows one source to send data to multiple recipients. Multicast transmissions are different from unicast in that there are multiple recipients, but still only a single copy is sent from the source. A multicast transmission is sent to an IP address, and the copy of data is distributed to any recipients who opt in to the transmission. Routers that lie between the source and the recipients of a multicast only produce additional copies of the data when the path to a recipient branches.

What is a Multicast Address?

When sending a multicast transmission, the data itself is sent to a single address that's actually a logical identifier for a group of hosts. A group of hosts of any size can be represented by one multicast address. Hosts looking to receive a particular multicast transmission advertise their group membership to designated routers so that they can be forwarded the relevant data. In IPv6, multicast group addresses are formatted in highly specific ways to distinguish them from a unicast address.

What is a Rendezvous Point?

In multicast, a rendezvous point is essentially the middle ground for recipients of a certain multicast address group and the data actually being sent. More technically, a rendezvous point (RP) is a router acting as a shared root for a multicast tree. A multicast network domain can support any number of routers configured as RPs, and routers designated as rendezvous points can cover different multicast group ranges.

What does Our Network Look Like?

We'll be walking through how a rendezvous point's IP address can be embedded inside a group address, but in order to do that, we'll first have to imagine the network that we're working on. Because this squeezing works with IPv6, we'll be using IPv6 IP addresses.

Our network is 2001:db8:X:: /64, and it consists of four routers: R1, R2, R3, and R4. We'll imagine R2, R3 and R4 are each connected to one another in a simple triangle layout, and R1 is connected only to R2. We have a subnet called Subnet A behind R1's gig 1/0 interface, and Subnet F behind gig 3/0 on R3. When we get to broadcasting our multicast, we'll originate it from Subnet A, and we'll have our host in Subnet F.

The first thing to do is decide which device will be serving as the rendezvous point. In our case, we're going to choose R2. We'll decide we want its loopback address of 2001:db8:2222::2 /64 to be the rendezvous point IP address.

Now, we will have to statically configure R2 and designate it as the rendezvous point. We want to statically configure as little as possible, but we do need to instruct the rendezvous point that it has a job to do. We're not doing that in today's blog post, but we'll imagine we've already instructed R2 that it's in charge of being the rendezvous point. However – importantly – we're not going to specifically tell R1, R3, or R4. We'll let them figure out who the RP is based on the multicast group address that we create.

What does an IPv6 Multicast Group Address With Embedded Rendezvous Point Data Look Like?

Keeping in mind that we're going to use 2001:db8:2222::2 /64 as our rendezvous point address, let's look at how we go about stuffing that into a multicast group address. To do that, we're going to look at the template that IPv6 multicast group addresses follow. Once we have a sense of their numbering conventions, we'll explain how our multicast address follows the template.

IPv6 multicast group addresses follow the same template or convention:

FF78:0RPL:NNNN:NNNN:NNNN:NNNN:GGGG:GGGG

We're about to explain that, but compare that template to what our IPv6 multicast group address actually will be:

FF78:240:2001:db8:2222:0:0:6789

Every IPv6 multicast group address begins with "FF". A device that pulls apart an IPv6 address and sees "FF" at the start knows it's looking at a multicast group.

The "7" is a differentiator. It designates that this is not a normal multicast group. When a device reads that "7" in the third position, it will know that the rest of the address actually contains embedded information about the rendezvous point.

The fourth digit, "8", represents the scope of the multicast content. A multicast group might be site-wide, organization-wide. It could even be global in scope. The 8 represents an organization-wide multicast group.

The next collection of bits starts with a 0, but we're interested in the "R". That "R" is a placeholder that stands for the last character of the rendezvous point's Interface ID or Host ID. It won't actually be "R" in our multicast group address.

There's an important requirement when you're stuffing an IPv6 address inside of another. In the rendezvous point's address, the Host portion needs to be mostly 0s.

Remember that the address we chose for our rendezvous point is 2001:db8:2222::2 /64, so it's true that the host portion is mostly 0s. And the last character is "2". Take a look at our IPv6 multicast group address and you can see that we took that last character (2) and dropped it into the "R" spot.

If this is making sense so far, you might be starting to wonder if this could be enough information. Careful readers might notice that we'll need more information about the rendezvous point than just the last character of its IPv6 address. Well observed: we'll also need to know what network it's on.

The next two characters, "PL", represent 8 more bits, and they're placeholders for the prefix length bits. We use this part of the address to communicate how much of the network we're going to communicate. Remember, our IPv6 multicast address is on a /64-bit network. We need to tell devices that 2001:db8:2222:0 is what's getting squeezed in. We represent that with "40".

Now, if you're a regular human, you probably read "40" in decimal and think that's wrong. We need to communicate 64 bits, not 40. But remember: IPv6 addresses are hexadecimal. So actually, "40" isn't four tens and zero ones, it's four sixteens and zero ones. In hexadecimal, "40" is 16 x 4 + 0 X 1. And that equals 64.

When a device unpacks our IPv6 multicast address and sees our "40", it knows that it's about to receive 64 bits of information regarding the network address of the rendezvous point. And so, it shouldn't surprise you to learn that if you told it that you were going to give it 64 bits, that's what the next 64 bits need to be.

The next four groups of bits represent the network address of the rendezvous point. In our case, 2001:db8:2222:0. The ":0" could be replaced with a double colon, but we wanted to emphasize all of the 64 bits.

We've accounted for nearly everything in our IPv6 multicast address template. We're only left with 32 bits at the end; we'll use them to represent our individual multicast group ID. But with 32 bits available, we can create millions of different multicast groups. And each of those groups would have an address that has the embedded address of their rendezvous point inside of them.

Now that you know what the template of an IPv6 multicast group looks like, look back at the address we'll be assigning:

FF78:240:2001:db8:2222:0:0:6789

Hopefully it now makes sense what each of those characters and bits are actually communicating when a device opens them up.

An Overview of How to Embed RP & VLC Multicasting with IPv6 [VIDEO]

In this video, Keith Barker covers how to embed rendezvous points inside of a multicast group address. You'll learn how to train a network to dynamically learn where their rend

How to Use VLC Media Player to Test Embedded Rendezvous Point Addressing

Once we've identified that this is the multicast group that we want to use and that we're going to use a group of 0:6783 in the last 32 bits, the only thing that remains to be done is to configure R2 — instructing it directly that, "You are the rendezvous point."

Following that, we can rest easy knowing that R1, R3, R4, and anybody else on the network who sees this IPv6 multicast group's address will automatically know who that group's rendezvous point is. The address itself is simply a logical identifier, but any device can extract the information to learn that R2 is the router serving as a rendezvous point for that multicast group.

Next, we'll demonstrate the steps necessary to actually test the multicast. We'll assume that we've already statically configured R2 and it knows that it's a rendezvous point. But no other routers on our network have been configured with that information. At this point, we encourage you to actually follow along on a virtual network of your own. You already know the routers and subnets we have on our own network, so you should be able to set up your own test environment. And here at CBT Nuggets, we think actually doing the thing is the best way to learn new network configuration processes.

In our case, we set up a Windows XP box with an IP address of 2001:db8:a:0. That's on our "A" subnet, which you'll remember is sitting just off to the left of R1 in our example network. We also set up a Windows 8 machine on the F subnet, which is just off of the gig 3/0 interface at the bottom of our network, hanging off of R3.

We're going to make the XP box a VLC multicast server. To do that, we simply launch VLC. We originally did this back when VLC's current version was 2.05, but it remains very easy to do. The steps for creating a stream are simple enough: navigate to Media, then click Stream.

We had a short .mp4 saved to our desktop in preparation for this test, and it's as easy as selecting it and pressing "Stream" in the dialogue box. When VLC asks us how we want to send the file, we select "RTP / MPEG Transport Stream".

We select that and click "Add". Following that, we need to put the address of where we want to send the stream. The address that goes into the available field is the multicast embedded group address that we just decided on: ff78:240:2001:db8:2222:0:0:6783. While we're there, we also specify port 5004. That's minor, but worth being aware of. On the client side, we'll need to not only register for that group but also pay attention, once that stream starts coming in, to port 5004.

This window will also give you the option to perform active transcoding. We don't want to do that in this case, we're just sending it as-is. Then, we click "Next" to move on to one last important thing: specifying the time to live. As we know, if we set TTL to 1, the first router that gets the multicast will drop it because the time to live would've reached its limit.

In our case, we'll specify 10 hops. We're choosing 10 because we know that's plenty to navigate the four routers that are sitting between the Subnet A devices and Subnet F devices. Last thing is to click "Stream". After that, the content is being pumped out to the network.

In case you're unfamiliar with Windows XP, you can look for an icon in your system tray that will tell you that you're broadcasting network to the network. It looks similar to the normal network icon in the system tray.

The second half of this is to go down to the Windows 8 machine on Subnet F and tell it to join this multicast group. We'll use the VLC player there as well. What we'll be doing is use a multicast listener discovery report to tell R3 it wants to listen to that group. That message becomes propagated throughout the multicast network. And if everything has gone well, then the content will flow down to the Windows 8 machine.

On the Windows 8 machine, we'll bring up VLC and go to Media -> Open Network Stream. When asked what address we're looking for, we enter the following: "rtp://@[ff78:240:2001:db8:2222:6783]:5004".

This might differ slightly from what you were expecting, so let's explain it a little bit. We're using brackets because it's an IPv6 address that uses colons. And as we close the brackets, the ":5004" indicates the port we specified earlier as the one to listen on.

If everything has worked out correctly, when we click "Play", we should see the video being streamed.

Wrapping Up

We took a look at one way of training network devices to learn who the rendezvous point for a specific multicast group is. That way was through embedding the RP's address inside of a multicast group address. It's not the only way to set up efficient multicasts for your network, but it's one way to make IPv6 do more for your networks. If you're looking for more help, this CBT Nuggets video can help you understand IPv6 rendezvous points better.