why we need IPv6 solicited multicast address ??

[mohammed hashim]

hi,

my question:

why we have to let a unicast address join multicast address and then calculate DMAC address. Why the DMAC is not calculated directly from the unicast address?

for example, in normal situation when we have IPv6 unicast address like 2001:DB8::AB:1, then the solicited-node address will be FF02::1:FFAB:1

and finally the L2 MAC address map will look like 33-33-FF-AB-00-01

so why the process is not simply map MAC address 33-33-FF-AB-00-01 to the unicast address directly?

____________________________________

there is another thing I would like to discuss which is why the IPv6 node need to send Neighbor Solicitation if there result is obsouly known like:

if I want to ping IPv6 address 2001:DB8::AB:1 , then I am 100% expects the L2 MAC address of remote node to be 33-33-FF-AB-00-01

appreciate if someone clarifies this for me.

[Jon Marshall]

Because that is a multicast mac address not a unicast one.

So if you mapped directly how would you send an NS for another hosts real mac address ?

You can't send the NS as a unicast because you don't have the real mac address so you can only send it as a multicast and as such you need to use a multicast IP address ie. the solicited node address.

And for your other question you don't know that is the mac address because it isn't, the device with that IP address will have a mac address assigned to the interface which is why you use a NS to obtain that address.

Jon

[Peter Paluch · Accepted solution]

Mohammed, Jon,

Please allow me to join.

I believe that Mohammed's question is more to the process of "double translation" of the unicast IPv6 address being the target of the NS, through the conversion to the solicited-node multicast, to the multicast MAC address. He asks whether the intermediary conversion to the solicited-node multicast is necessary if we know immediately that in the final result, the lowmost three bytes of the unicast IPv6 address are being copied to the MAC address with the prefix of 33:33:FF.

To explain this, we need to go to the basics of Neighbor Discovery mechanism in IPv6. The purpose of Neighbor Discovery is to find out what exact Layer2 address is used by a host on the same link if we already know its unicast IPv6 address. Obviously, we cannot ask the host directly because that assumes we actually know its Layer2 address - which in turn means we do not need to ask at all. The only option we are left with is to just "shout across the link" and hope that out of the possibly many stations that hear us, the one we're looking for will answer. Now the question is - how "loudly" shall we shout? Shall we send our inquiry to all hosts on the link (broadcast)? Or just choose a subset of them that has a higher chance of containing the host that is being searched (some kind of multicast)?

IPv6 authors decided not to use broadcasts for this purposes (or any other in IPv6) as they are inefficient - while they truly make sure that every host on the link will have a look at a broadcasted packet, many of the hosts will find out that the message in that packet is not really interesting for them. Instead, they have decided that Neighbor Solicitation messages encapsulated in IPv6 packets will be sent only to a subset of all hosts - those hosts whose own IPv6 unicast address partially resembles the address being searched by matching in the lowmost 3 bytes of the address. Obviously, if a host's IPv6 address differs in the lowmost 3 bytes from the searched address then the entire addresses won't match, either.

Following this reasoning, a Neighbor Solicitation message - which is an IPv6 packet requiring a source and a destination address - has to be sent to a destination IPv6 address that represents all hosts having the 3 least significant bytes of their unicast IPv6 address identical to the unicast address being looked up. Obviously, these hosts form a group, and so the destination address of the Neighbor Solicitation message must be set to a multicast IPv6 address. IPv6 creators have mandated that this multicast IPv6 address will be in the format of FF02::1:FF<xx>:<yyzz>, with the <xxyyzz> being the 3 lowmost octets of the searched unicast address. This IPv6 address - the solicited-node multicast address - cannot be omitted in this process because the Neighbor Solicitation is an IPv6 packet and the destination address in an IPv6 packet is a mandatory field that must be properly populated. Additionally, each host with a particular IPv6 address has to listen on the corresponding solicited-node multicast address in case some other host is looking for him.

So in fact, the solicited-node multicast IPv6 address is extremely important in the whole Neighbor Discovery procedure because it defines both the multicast group address on which a host is required to listen for Neighbor Solicitations, and the destination IPv6 address of Neighbor Solicitation messages looking for that host.

Keep in mind that the solicited-node multicast is not the address we are trying to find; rather, it is a tool to address the Neighbor Solicitation message to a limited subset of all hosts on the link that still contains the searched host.

Assuming that your computer has constructed such a Neighbor Solicitation message and put proper source and destination IPv6 addresses into its header, this message now needs to be sent out through the network interface. Depending on the type of the network interface, the Neighbor Solicitation message may end up being encapsulated in an Ethernet frame, or a PPP frame, or perhaps an ATM cell. Note that each of these link layer technologies uses different frame format and a different Layer2 addressing: Ethernet uses MAC addresses, while PPP does not use any addressing at all, and ATM - on the cell level - uses two short numbers called VPI and VCI. In other words, each link layer technology uses different style of addressing, and thus each one converts a multicast IPv6 address into its own addressing in a different way. Specifically for Ethernet, every multicast IPv6 packet will be carried in a frame whose destination MAC begins with 33:33 and the remaining 4 bytes are copied from the 4 lowmost bytes of the multicast destination IPv6 address. However, this goes just for Ethernet. A different link layer technology might use a different style of addressing and so will choose its own way of deriving multicast L2 addresses from multicast L3 addresses.

Following this, the MAC address of 33:33:... is not an absolute. Depending on the link layer technology used, there might in fact not be a MAC address at all. The only absolute is the solicited-node multicast IPv6 address, and the MAC - or any other L2 address - is only then derived from it.

Keep in mind that even this derived MAC address is not the MAC address of the host you are looking for - it is again a group address applying to a subset of all hosts on a link, one of which might be the host you are searching for. However, that host has to respond back to you to tell you its true MAC address.

So the process is, in short:

1. From a known unicast IPv6 address of the host you want to talk to, generate the solicited-node multicast IPv6 address and put it into the destination address field of the IPv6 packet carrying the Neighbor Solicitation message
2. Encapsulate the IPv6 packet containing the Neighbor Solicitation message into the frame used by the egress network interface, deriving that frame's destination address (if there is any) from the packet's destination IPv6 address using the appropriate mapping mechanism defined for the link layer technology in use

I apologize for this post being so long - I just felt it was necessary to shed some light on the overall logic and motivation of the whole process.

Best regards,
Peter

[Jon Marshall]

Peter

For my own clarification -

Following this reasoning, a Neighbor Solicitation message - which is an IPv6 packet requiring a source and a destination address - has to be sent to a destination IPv6 address that represents all hosts having the 3 least significant bytes of their unicast IPv6 address identical to the unicast address being looked up. Obviously, these hosts form a group ....

In other words because you are only using 3 bytes from the host portion of the IPv6 unicast address then it does not identify a specific host within the vlan ie. using this method you could in fact have multiple hosts on the same vlan using the same low order 3 bytes.

Is that what you are saying ?

As usual, I thought I understood this until I read one of your posts :)

Jon

[Peter Paluch]

Hi Jon,

In other words because you are only using 3 bytes from the host portion of the IPv6 unicast address then it does not identify a specific host within the vlan ie. using this method you could in fact have multiple hosts on the same vlan using the same low order 3 bytes.

Yes, that is absolutely correct. In a network using a /64 prefix, you can have up to 2⁴⁰ hosts whose IPv6 addresses match in the lowmost three bytes. They all listen on the same solicited-node multicast IPv6 address, and they would all receive and process the Neighbor Solicitation message sent to this address. Of course, this message contains the full IPv6 address of the solicited host inside its ICMP body, so even though it can be processed by multiple hosts, only the host whose address fully matches the solicited address will respond.

Even though 2⁴⁰ possible hosts sharing the same solicited-node multicast is a lot, it is still better than bothering all 2⁶⁴ possible hosts which would be the case if we were using broadcasts or all-IPv6-nodes multicast to perform Neighbor Discovery. In addition, if assigning IPv6 addresses in an ordered sequence (<prefix>::1/64, <prefix>::2/64, <prefix>::3/64, ...), you would need to assign 2²⁴ addresses before the corresponding solicited-node multicast addresses started repeating themselves. Also, if addresses are assigned entirely randomly, there is only a 2^-24 probability that you will generate an address whose solicited-node multicast will match a single existing host's solicited-node multicast address.

Best regards,
Peter

[Jon Marshall]

Peter

Thanks, that was what I thought you were saying.

Just wanted to make sure :)

Jon

[Peter Paluch]

Jon,

You are welcome! :)

Best regards,
Peter

[LvSrikanthLakshman]

I am still confused. Anyway, either use unicast IPv6 or solicited node multicast, at layer 2, the switch floods the packet to all the ports other than the one it receives. Why not directly use IPv6 broadcast address at layer 3 and ff:ff:ff:ff:ff:ff as layer 2 DA just like IPv4 to mac translation? The process doesnt look different at layer 2 level though DA is also a multicast address. More detailed explanation will be very helpful please.

[Giuseppe Larosa]

Hello LvSrikanthLakshman,

you cannot get a more detailed explanation then the one provided by Peter Paluch in this thread.

When I studied IPv6 for the first time I had difficulties to understand how it was possible to resolve an IPv6 address to a MAC address without using ARP and without using broadcast frames at OSI layer 2.

The key element to make this IPv6 address resolution to be successful is the solicited node multicast IPv6 address and its corresponding L2 multicast MAC address.

The usage of a L2 multicast MAC address allows for L2 forwarding optimization made by MLD snooping on the switches (MLD is the IPv6 equivalent of IPv4 IGMP even if MLD is a subset of IGMPv6).

So it is not true that the multicast frame will be flooded to all ports in Vlan as MLD snooping allows to send the frame only to those hosts that have joined the same multicast MAC address only to those hosts having the same values in the last 3 bytes of their IPv6 address.

For MLD snooping to work each host needs to send an MLD join periodically for each solicited multicast address it is interested.

This explains the greater efficiency of IPv6 Neighbor Discovery when compared to ARP used in IPv4.

Hope to help

Giuseppe

[LvSrikanthLakshman]

thanks so much, i think i am getting it :)

[LvSrikanthLakshman]

Thank you so much, I think I got the point!

IPv6's NDP, mechanism similar to ARP, uses solicited multicast IPv6 address (which is derived from unicast IPv6 address in such a way that the first 104 bits form ff02::1:ff/104 for hosts or ff02::2:ff/104 for routers so on with last 24 bits obtained from unicast last 3 bytes). Here, a subset of hosts can be formed where the hosts in the subset will all have same last 3 bytes info and will accept the incoming frame, decapsulate and investigate the inside content. The multicast mac address becomes 3333:ffxx:yy:zz where xx:yy:zz are the last 3 bytes from the solicited multicast IPv6 address. As this multicast address will be same for all the hosts in the group (IPv6 address' last 3 bytes same), the frames get delivered to all these hosts. Once the frame is accepted by a host, it rip opens and check the layer3 unicast address encapsulated in ICMPv6 structure which will contain actual host's IPv6 unicast address, which means only the actual host to whom the packet is destined will accept it for further processing.