Technology / Networking

What is a Solicited Nodes Multicast Group in IPv6?

What is a Solicited Nodes Multicast Group in IPv6? picture: A
Follow us
Published on April 1, 2021

These days, it's easy to forget the importance of discovering your neighbors. These are friends just waiting to happen: people who can gather your mail for you while you're away, keep an eye out for suspicious behavior, even hold on to a key for you in case you lock yourself out. But it's not just real-life, meatspace neighbors that are important: the neighbor-discovery process is even more important for network devices.

One of the most useful tools in networking is the Solicited Nodes Multicast Group. But understanding it takes diving into what differentiates it from other casts and how it operates. So, let's explore SNMGs.

What is Unicast?

Quick definition: Unicast is the term that describes a one-to-one communication transmission. In computer networks, a unicast is one sender transmitting a message to one receiver. Each point in a unicast transmission has its own network address.

What is Multicast?

Quick definition: Not to be confused with point-to-multipoint communication, multicast is the term that describes one-to-many or many-to-many communication transmission. In computer networks, a multicast is one or many senders transmitting a message to multiple recipients.

What is a Multicast Group?

Quick definition: A multicast group is a logical identifier for recipients of multicasts. A multicast group is used to identify groups of recipients, each of whom are interested in particular data transmissions. A multicast group is represented by an IP address.

What is a Solicited Node Multicast Group?

Quick definition: In IPv6, for every multicast address that a host has, it must join a solicited node multicast group, which represents the address that's valid only within the local-link. A solicited node multicast address is used to obtain Layer 2 addresses of other nodes via the Neighbor Discovery Protocol.

An Overview of Solicited Node Multicast Group [VIDEO]

In this video, Keith Barker covers solicited node multicast groups, what they are, how they’re created and how they can be used in a network. IPv6 and IPv4 networks act differently, and solicited node multicast groups sit at the heart of IPv6’s improved speed and efficiency.

What's the Difference Between Unicast, Multicast and Solicited Node Multicast?

The primary difference between unicast, multicast and solicited node multicast is the number of senders and number of recipients. To appreciate the Solicited Node Multicast Group, we should make sure we have a basic understanding of multicast groups in general, and to do that, we should compare it to unicast.

Imagine there's a uncast conversation between a hypothetical PC, which we'll call PC1, and a server. The PC has a specific IP address, the server has a specific IP address, and so when the server is responding or sending data to the client, the destination IPv6 address is a unicast address: it's only for PC1, that's it. It gets routed to PC1's network, and PC1 is the only device that processes it.

Now, let's compare that unicast to multicast. With multicast, instead of sending a packet to the IP address of PC1, we send the packet to the IP address of a special multicast group.

Incidentally, those are very easy to pick out. In IPv6, multicast groups all start with "FF". So, we send this packet to the multicast group whose address begins with FF.

And as the packet gets forwarded down the network and reaches the local network segment that PC1 is on, all the devices. Imagine that there are 200 devices on that segment, all of them would have the opportunity (if they wanted to) to process and look at that single packet sent by the server.

Unicast is one-to-one. Multicast is one-to-many.

Imagine a multicast group. If we have 200 PCs in that group, and 50 of them care about listening to that multicast transmission we just described, they can effectively join that multicast group. That essentially means that their computers will be looking for multicast content and de-encapsulating and processing the data as it comes in. The other 150, who couldn't care less about the multicast group, don't have to process the data.

So, what do we know so far? We know that a multicast group is a special, Layer 3 IPv6 address that's intended for potentially more than one computer. We also know that a device, like any number of PCs associated with that group, that wants to listen and process that multicast traffic would just join the respective multicast group. Then, when that traffic comes by on the network, they'd be able to de-encapsulate and take a look at it.

That's multicasting. So now, finally, we have the opportunity to answer what, exactly, Solicited Node Multicast Group is. And the answer is quite simple.

Every device on an IPv6 network, if it has a unicast address, for example a global address like 2001:db8:6783:(and so on), it (that same interface) will also will also join a special group: a Solicited Node Multicast Group. It's a multicast group that links to the actual unicast address applied to an interface.

How are Solicited Node Multicast Groups Formed?

A Solicited Node Multicast Group is created by adding the last 24 bits of the unicast address as the multicast group address. That can be confusing, so let's explore that a bit.

Let's take the IPv6 multicast address default: FF02::1:FFxx:xxxx.

At the beginning is "FF02". In IPv6, "FF" represents "multicast".

The next two digits are "02". You know the expression, "What happens in Vegas stays in Vegas?" You wouldn't be far off by thinking of "02" as that expression. Those represent it's link-local in scope. The "02" in this part of the address instructs anyone looking at it that this multicast stays on the network that instructs any routing device not to route it across network boundaries.

Next in the multicast address is "::1:FF". This is the telltale sign that this is, specifically, a Solicited Node Multicast Group.

The last 24 bits, the final six characters, are all "x". They represent what the last 24 bits of the host ID will be.

Say we had a network whose first 64 bits were, for example, 2001:db8:6783:x. Then let's say the Host ID — the last 64 bits — was :A:B:CC12:3456. In that, "12:3456" represents the last 24 bits of that ID. They're the last six characters, but remember that with hexadecimal, every character represents 4 bits. So, with those six characters we get the last 24 bits of the unicast address. We take those 24 bits, pop them into the "xx:xxxx" part of the default multicast and now we know the SNMG that this device will join.

Why do Solicited Node Multicast Groups Matter?

Solicited Node Multicast Groups are central to the neighbor-discovery process, which is central to quickly getting access to network resources.

For example, imagine PC1 from above. Imagine that a router we'll call R1 is its default gateway. How does PC1 know that? By default, just in being powered up, PC1 has no knowledge of what the Layer 2 address of its default gateway is.

How can PC1 learn that? In the days of IPv4, we used ARP. We sent out a broadcast. an ARP request, and we'd get the reply. With that, we'd have Layer 2 info in our ARP cache and we'd move forward.

But IPv6 has no ARP. And there is no Layer 2 broadcast. But we still need to know our default gateway. What we can use instead is some other protocols, ones that involve the solicited node multicast address.

Fortunately for us, PC1 knows the rules on how a Solicited Node Multicast Group is created. And because he knows the IP address of his default gateway, he's going to anticipate that his default gateway also joined the appropriate SNMG. And that's where the request goes out.

We send a request out, addressing it to the Solicited Node Multicast Group that we think our router ought to be listening on. If all the configuration has been done, then they are in fact playing by the both rules and the router is listening. The router, when it gets that request, can respond with the Layer 2 address. And that's a very significant application for Solicited Node Multicast Groups.

How Does Solicited Node Multicast Group Enable Neighbor Discovery?

Let's take R1 and imagine that at the moment it doesn't have any IPv6 address configured whatsoever. We'll run through the commands and configuration necessary to get it one. If you have a virtualized network, head into configuration of your router. We'll start with a quick show command verifying that gig 2/0 is empty, regarding IPv6:

do show ipv6 int g 2/0

This will have no return, assuming there actually aren't any addresses configured.

We'll be going into the interface to configure two addresses. First is a link-local address, which we could leave off, as one would automatically be generated for us and secondly, a global address. That address will start with 2001.

Interface GigabitEthernet2/0
ipv6 address FE80::12:3456 link-local
ipv6 address 2001:DB8:6783:1:A:B:CC12:3456/64

After having done that, issue the same command from earlier again:

do show ipv6 int g 2/0

If things have gone right, there should be a significant difference from before. This output contains a lot of valuable information. Info like the link-local address (looking exactly like we configured it). We'll also find our global unicast address (looking just how we configured it). Those are both examples of unicast: one's global, one's link-local in nature.

From here, you can also see that it has joined a group. That group is "FF02::1:FF12:3456" Remember that "FF02::1:FF" is the telltale sign for the multicast group for the solicited node. And, sure enough, we can see that it used the last 24 bits that match the unicast addresses.

Something to note is that if the link-local address had had a different last 24 bits than the global, we would have joined two separate SNMGs.

Wrapping Up

Solicited Node Multicast Groups are a crucial part of the neighbor-discovery process. Local to their wire, each device joins theirs simply by deciding to listen to the correct address. This differs significantly from IPv4, so although it's very simple, it can be difficult to unlearn what you might have worked with for years.


By submitting this form you agree to receive marketing emails from CBT Nuggets and that you have read, understood and are able to consent to our privacy policy.

Don't miss out!Get great content
delivered to your inbox.

By submitting this form you agree to receive marketing emails from CBT Nuggets and that you have read, understood and are able to consent to our privacy policy.

Recommended Articles

Get CBT Nuggets IT training news and resources

I have read and understood the privacy policy and am able to consent to it.

© 2024 CBT Nuggets. All rights reserved.Terms | Privacy Policy | Accessibility | Sitemap | 2850 Crescent Avenue, Eugene, OR 97408 | 541-284-5522