IPv6 Solicited-Node Addresses

Introduction

 

An IPv6 solicited-node address is a link-local multicast address used in IPv6.  Solicited-node IPv6 multicast addresses are used in IPv6 neighbor solicitation messages for layer 3 to layer 2 address resolution.  The use of solicited-node addresses for the function of layer 3 to layer 2 address resolution is far more efficient than something like ARP, which was used for the same purpose in IPv4.

 

The Problem

 

If you are reading an article on solicited-node IPv6 addresses, then you probably already know that the generally accepted standard for IPv6 subnets is to allocate a /64 for every subnet on your network.  The first 64 bits of your 128 bit IPv6 address would be used for the network ID where the last 64 bits would be used for your host ID.  Using /64 subnets is easy and allows us to use neat features like automatic IPv6 addressing for our hosts.

OK, so what?  That is a LOT of addresses…I mean a LOT of addresses.  Actually 2^64 possible addresses per segment. That means having a potentially insane amount of hosts attached to the same subnet/VLAN.  For the last decade or more us network engineers have been pushed to be as efficient as possible with our subnet allocations and for good reasons.  We have all been taught to keep our layer 3 subnets and VLANs as small as possible for many reasons.  One of the main reasons was to keep broadcast domains small.  If we had a broadcast domain that was too large, the sheer amount of broadcast traffic on the segment could make our network performance suffer.

One of the biggest challenges we had to worry about there was ARP, the address resolution protocol.  Recall that an ARP request is a layer 2 broadcast sent to the MAC address FF:FF:FF:FF:FF:FF.  ARP is of course used for layer 3 to layer 2 address resolution.  If host A wants to talk to host B and they are on the same ethernet segment, host A would have to broadcast an ARP request requesting host B’s layer 2 MAC address.  This ARP broadcast would in reality be received by every host on the segment.  If our broadcast domain was too large, we could start to see problems with performance. In essence, ARP didn’t scale very well and was not very efficient.

 

To broadcast or not to broadcast, that is the question

 

So where does that leave us with IPv6?  If we are to use /64 subnets with potentially billions of hosts on each segment, doesn’t that leave us with a totally unscalable solution for address resolution?  Well, only if we continued to use a broadcast based solution like ARP, and luckily we don’t!  ARP is out, and IPv6 neighbor discovery protocol (ND) is in.  The rules have changed, and there are lots of exciting new features with this protocol suite.

Actually, the entire concept of a broadcast has gone away completely in IPv6.  That’s right, there ARE NO broadcasts.  They are not defined in IPv6.  They do not exist.  We do have a pseudo-broadcast implemented by using the all hosts multicast address for certain things, but for all practical purposes broadcasts are gone in IPv6.

 

The Solution: IPv6 Solicited-Node Addresses

 

So if we don’t have ARP and we can’t broadcast at all, how do we solve the problem of address resolution in IPv6.  IPv6 uses the neighbor discovery protocol for these purposes.  Neighbor discovery is part of ICMPv6 and has a few different types of messages defined.  For layer 3 to layer 2 address resolution, we have the neighbor solicitation message and neighbor advertisement message.  The idea is very much like ARP, it just works differently and much more efficiently.  Essentially, host A sends a neighbor solicitation to host B asking for host B’s MAC address.  Host B then responds.  The magic is that host A ONLY asks host B, not everybody like in ARP.  There is no broadcasting involved.  That is where solicited-node addresses come in.

Basically, every IPv6 interface derives a solicited-node address from it’s link-local IPv6 address.  That solicited-node address is actually an IPv6 multicast address.  The host then joins this IPv6 multicast group and at that point is “listening” for messages destined to that multicast group.  When host A wants to get the MAC address of host B, host A simply sends an IPv6 neighbor solicitation message multicast to the solicited-node address of host B.  Host A knows what this address is because host A knows the standard solicited node prefix and it knows host B’s link local IPv6 address. Since this is an IPv6 multicast, only members of that multicast group will receive the request!  Brilliant!!!

 

So, what is the magic formula?  It is quite simple.  We take the last 24 bits of our IPv6 address and we prepend it with the prefix ff02:0:0:0:0:1:ff00::/104. We then have 104 bit prefix + the last 24 bits of our IPv6 address for a total of 128 bits.

 

Example

 

Let’s say we have two hosts on an ethernet segment, host A and host B.  host A has the IPv6 link-local address fe80:100:100:100::A/64 and host B has the link-local address fe80:100:100:100::B/64.  Host A wants to communicate with host B.  Let’s look at the steps

1) Host A will send a neighbor solicitation message to the solicited-node address of host B asking host B what it’s MAC address is.  Host A derives the solicited-node address by taking the prefix ff02:0:0:0:0:1:ff00::/104 and prepending it to the last 24 bits of host B’s link-local address.  The last 24 bits are 0000 0000 0000 0000 0000 1011.  This gives us ff02:0:0:0:0:1:ff00:000B.  We can shorten this to ff02::1:ff00:B.

2) Host B has already figured out it’s solicited-node address and has joined the IPv6 multicast group ff02::1:ff00:B using MLD (IPv6 replacement for IGMP).  Since Host B is a member of the multicast group ff02::1:ff00:B it “hears” the neighbor solicitation request from host A

3) Host B replies with it’s MAC address in the payload of a neighbor advertisement message destined to Host A

*NOTE* These solicited-node multicast addresses are IPv6 layer 3 multicast addresses.  What about layer 2?  If a switch gets a layer 2 multicast message it forwards it to every port in the VLAN.  That kind of defeats the purpose.  That’s why we have MLD snooping to make sure that only the proper switch ports receive the multicast message and that they don’t get flooded out everywhere.

Summary

That about does it for IPv6 solicited-node addresses.  Essentially, the solicited node address is a link-local multicast address derived from a host’s link-local IPv6 address that is used in conjunction with IPv6 neighbor discovery to offer efficient and scalable L3/L2 address resolution.

I know that I for one was wondering for a long time what the repercussions of using /64 bit subnets would be with regards to “broadcast” domains and IPv6, and I’m glad I dug into this technology.

 

 

 

 

 

 

14 Comments

  • Syed Taukir says:

    Very good explanation :)

  • Hemanth Raj says:

    Gud post buddy. I always read ur posts. Its awesome
    I have a doubt in this post

    How does Host A knows about the solicited neighbor address of Host B

  • yukio says:

    Hi, thanks for very easy-to-understand explanation!!
    Well, although it is not long after I started to study about IPv6,
    I just wonder how Host A sends the neighbor solicitation message to Host B. What is MAC field set to at the time, rather than MAC broadcast address?

    • Joe Astorino says:

      Typically with IPv6 multicast, the IPv6 multicast address gets mapped to a L2 ethernet address like this:

      You append the last 32 bits of your IPv6 address with the prefix 33:33 to come up with a 48 bit MAC address. I’m not positive that is how it works for this special case, but that is normally what happens.

      • yukio says:

        Thanks for quick reply.
        I am afraid I am not clear yet.

        Host A needs to know Host B’s MAC address when Host A sends packets to Host B. Right?
        So, Host A needs to send a neighbor solicitation message to Host B. I was asking what is the destination MAC address set to in this message?. You said this MAC address is made of “33:33 + the last 4 bytes of Host B IPv6 address”. Do I understand correct?

        If this is correct, what is the difference between the true Host B’s MAC address and “33:33 + the last 4 bytes….”?

        • Joe Astorino says:

          Yes, you understand correctly. The difference would be the 33:33 + the last 32 bits of the IPv6 is an ethernet multicast (L2 multicast) address and not a MAC address. Similarly, in IPv4 multicast the last 23 LSB of the IP multicast get mapped to an ethernet multicast address wtih a specific prefix

  • eric says:

    Thanks for your writeup.
    I’m still missing some key point.

    regarding your explanation “Host A will send a neighbor solicitation message to the solicited-node address of host B asking host B what it’s MAC address is. Host A derives the solicited-node address by taking the prefix ff02:0:0:0:0:1:ff00::/104 and prepending it to the last 24 bits of host B’s link-local address.”

    So to summarize, at present host A (1) already knows the host B’s link-local address and (2) does not know host B’s MAC address and want to know it.

    All textbooks make the comparison between IPv4’s ARP and IPv6’s Neighbor Solicitation. But ARP is Link layer protocol Neighbor Solicitation is on top of ICMP which in turn is on top of IP layer. Right?

    If right, then my question is this:
    Why does host A send Neighbor Solicitation message using host B’s multicast address when it already knows host B’s unique link-local address?

    In other words,when sending Neighbor Solicitation, at L2 use this address per your explanation”…MAC address is made of “33:33 + the last 4 bytes of Host B IPv6 address” (no change) but at L3 use host B’s link-local address and not its multicast address. What’s wrong with this?

    I’ll googled so much to understand this but I’m still confused. Thanks for your help.

    eric

    • Joe Astorino says:

      @Eric — Good question. Check out RFC 4861 http://tools.ietf.org/html/rfc4861

      Specifically, check out section 4.3 on the neighbor solicitation format. It states

      “Neighbor Solicitations are multicast when the node needs to resolve an address and unicast when the node seeks to verify the reachability of a neighbor.”

      I would have to really dig into it further, but it seems that the unicast NS message is used for a different purpose in IPv6 than the multicast message. The multicast was specifically designed to do address resolution, whereas the unicast version is used for a separate feature known as reachability verification

  • rmcewin says:

    Firstly, thanks Joe. This is the concise description I was looking for. One thing that had me puzzled that was not included in the article was how would a NS message work when we had two hosts with different IPv6 addresses that shared the last 24 bits. Obviously, the solicited Node address would be the same and both hosts would receive the multicast NS. All was revealed when I checked a wireshark capture and saw that the specific IPv6 address that is targeted in the solicited Node multicast is included in the NS message. The untargeted host that received the multicast will not respond with a NA.

  • Leonidas Romualdo says:

    Epic explanation !

    Thanks Very much!

  • shah says:

    Joe really appreciate for such a nice and easy to understand article. Thanks for the efforts you made for this..

Leave a Reply to eric Cancel reply