Ethernet – Can the source mac address in an Ethernet header be used to identify the sender

RFC 4291, IP Version 6 Addressing Architecture, Appendix A has the full explanation.

Basically, you split the 48-bit MAC address down the middle, insert FFFE to extend it to 64 bits, and flip the U/L bit. This creates the 64-bit Interface ID which you append to the end of the 64 bits of the Global Routing Prefix and Subnet ID combination. For Link-local addresses, the created Interface ID is appended to the Link-local prefix (FE80:0:0:0::).

Some people are concerned that you can use a unique number, like a MAC address, to track a particular host. To correct this, RFC 4941, Privacy Extensions for Stateless Address Autoconfiguration in IPv6 was created. Windows and many Linux variants use random addressing by default, but this may be disabled.

There's a very good reason why the use of Microsoft's multicast NLB is not very popular in a whole lot of networks - it's a hack that breaks several basic operating practices and RFC's.

So - under normal circumstances multicast means that the destination IP of a packet is somewhere in the 224.0.0.0/4 range, with this range broken up into various well-known chunks. In turn, there is a mapping of these IP multicast group addresses to certain MAC addresses. Here is a Microsoft article describing how that mapping is achieved.

Anyhow - what we normally have is that traffic is sent to a multicast group IP that is mapped to a multicast MAC address. The switch is smart enough to snoop on the Internet Group Management Protocol (IGMP) which is how individual end hosts signify which multicast groups they want to receive. When the switch sees an IGMP join request, it programs the port such that any packets to the multicast MAC are copied down. This means that on a network with 100 hosts if only 10 signify interest in this multicast group then traffic bound to that group only shows up on those 10 ports (...vs all 100 in the case of a broadcast).

Where Microsoft broke this is that they require a mapping of a unicast IP to a multicast MAC. They also require the underlying switch to either turn off IGMP snooping (...thus causing the cluster packets to be sent to every host in the subnet, whether they need them or not) or to statically map this address to the physical ports occupied by their servers (hint: this is NOT supported in lots of hardware and breaks vswitches and virtualization pretty horribly as well).

So - in essence Microsoft wrote a really, really hacky and awful way of doing this that requires that the underlying network layer break all kinds of accepted best practices for how networks otherwise work. To their credit they also have some newer modes (IGMP based) that aren't quite as bad but, ultimately, it's now a lot more common in new installations to see folks dropping back to a unicast-based mode that uses some kind of external load balancer to achieve the same effect in a more sane manner.