NETWORKING

  • 09/15/2014
    8:00 AM
  • Rating: 
    0 votes
    +
    Vote up!
    -
    Vote down!

Understanding IPv6: What Is Solicited-Node Multicast?

Denise Fishburne lays down the basics of solicited-node multicast, which provides the functionality for Neighbor Discovery in IPv6 addressing.

IPv6 solicited-node multicast somtimes seems to confuse those new to IPv6 in the beginning. I think this is because it seems so foreign and new. In this post, we will explore exactly what IPv6's solicited-node multicast is and the rules of creating such an address as told to us by RFC 4291.

However, before we start on what's new and different, let's look at what solicited-node multicast has in common with IPv4 and IPv6 constructs that we already know.

In this blog post, we looked at IPv6 link-local scope multicast addresses. One of the examples was FF02::A. This address is for all devices on a wire that want to "talk" EIGRP with one another.

Focusing specifically on FF02::A and how routers join it, we can see and say three things:

  • Local: FF02::A is local to the wire.
  • Join: Each device "joins" FF02::A by just "deciding to listen" to the IPv6 link-local scope multicast address FF02::A. Then, by extension, it listens to the corresponding MAC address for that multicast IPv6 address (33:33:00:00:00:0A).
  • Common interest: As we can see, these varying groups have something in common that they would all like to hear about. For FF02::A, the common interest -- the "connection" among the devices joining that group -- is that they all want to listen to or participate in EIGRP.

Guess what? Solicited-node multicast has all those things, too.

  • Solicited-node multicast is also local to the wire.
  • Each device joins a solicited-node multicast group address by just "deciding to listen" to the IPv6 solicited-node multicast address and then to the corresponding MAC address for that multicast IPv6 group.
  • Devices that join a specific solicited-node multicast address share a common interest

Let's do these introductions properly. As RFC 4291 section 2.7.1 states:

Solicited-node multicast address are computed as a function of a node's unicast and anycast addresses. A solicited-node multicast address is formed by taking the low-order 24 bits of an address (unicast or anycast) and appending those bits to the prefix FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the range

FF02:0:0:0:0:1:FF00:0000
to
FF02:0:0:0:0:1:FFFF:FFFF

For example, the solicited-node multicast address corresponding to the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 addresses that differ only in the high-order bits (e.g., due to multiple high-order prefixes associated with different aggregations) will map to the same solicited-node address, thereby reducing the number of multicast addresses a node must join.

A node is required to compute and join (on the appropriate interface) the associated solicited-node multicast addresses for all unicast and anycast addresses that have been configured for the node's interfaces (manually or automatically).

So, what did we just read? Let's break this down. Here's RouterA with one IPv6 address.

As we can see, RouterA has one IPv6 unicast address defined, link-local FE80::1. According to what we read above from RFC, 4291 RouterA is "required to compute and join" on interface gig1/0/1 "the associated solicited-node multicast address."

So we must compute first and then join.

Compute
"A solicited-node multicast address is formed by taking the low-order 24 bits of an address (unicast or anycast) and appending those bits to the prefix FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address."

The compute is two steps -- simple enough.

  • Low-order 24 bits for the IPv6 link-local unicast address FE80::1 is ::1. That was easy.
  • Append ::1 to FF02:0:0:0:0:1:FF00::/104, and we get FF02:0:0:0:0:1:FF00:1 or FF02::1:FF00:1.

Join
RouterA is now supposed to "join" this IPv6 solicited-node multicast group (FF02::1:FF00:1) on the corresponding interface gig1/0/1. As we can see below, RouterA does join the associated IPv6 solicited-node multicast group (FF02::1:FF00:1) for IPv6 unicast address FE80::1.

As we can see, RouterA now has 2 IPv6 unicast addresses:

  • IPv6 link-local address FE80::1
  • IPv6 global address 2001:DB8::AB:1

Remember that, according to what we read above from RFC 4291, RouterA is "required to compute and join" on interface gig1/0/1 "the associated solicited-node multicast addresses for all unicast and anycast addresses that have been configured."

Since RouterA has already computed and joined the associated IPv6 solicited-node multicast group (FF02::1:FF00:1) for IPv6 unicast address FE80::1, we just have to compute and join for the newly added IPv6 global unicast address, 2001:DB8::AB:1.

So we must compute first and then join.

Compute

  • Low-order 24 bits for the IPv6 link-local unicast address 2001:DB8::AB:1 is ::AB:1.
  • Append ::AB:1 to FF02:0:0:0:0:1:FF00::/104, and we get FF02:0:0:0:0:1:FFAB:1 or FF02::1:FFAB:1.

Join
RouterA is now supposed to join this IPv6 solicited-node multicast group (FF02::1:FFAB:1) on the corresponding interface gig1/0/1. As we can see below, RouterA has now joined both IPv6 solicited-node multicast addresses.

Why?
Of course, an obvious question here is why we need a device to compute and join the IPv6 solicited-node multicast address for each and every IPv6 unicast and anycast on an interface? Simply put, it is the basis for Neighbor Discovery (RFC 4861).

In my next post, we will revisit RouterA and RouterB and see an example of how a solicited-node multicast address is used.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.