12

I'm a software developer and just got a free book about IPv6 at the Techdays, which I'm reading for fun. They gave it away because it's a bit of an old book (W2008), so maybe things are different for other/newer OSes, but I don't understand the necessity for Neighbor Discovery to get the MAC address.

According to the book, every node automatically gets a Link-local IP-address, which is constructed from the MAC-address by inserting FF-FE between the 3rd and 4th bytes and flipping the U/L bit, so that the Link-local IP for a node with a MAC address of 00-AA-00-3F-2A-1C becomes FE80::2AA:FF:FE:3F:2A1C.

To determine the link layer MAC address, a Neighbor Solicitation message is send to the link-local IP address, which replies with a message containing its MAC address... But the sender already knows that, because the MAC is encoded in the link-local IP address. So it sounds like mailing a postcard to somebody asking for their address.

Canadian Luke
  • 885
  • 14
  • 41
Edwin
  • 223
  • 2
  • 4

2 Answers2

20

Every node automatically generates a link-local address, but:

  • That address might not be generated with the EUI-64 format specified in RFC 2464. IPv6 addresses may also be cryptographically generated addresses (RFC 3972), temporary privacy addresses (RFC 4941), or in modern operating systems, stable privacy addresses (RFC 7217).

  • An address that looks like it has an EUI-64 interface ID might not actually correspond to the indicated MAC address due to explicit configuration by an administrator.

Because you can't just "convert the address back" to a MAC address, you must send a Neighbor Solicitation to determine the MAC address.

There are other reasons why Neighbor Solicitations are necessary, as well. Some of these are:

  • Duplicate address detection (RFC 4862). It's possible that some other host may have (rightly or wrongly) claimed an address that a host wants to use.
  • Neighbor unreachability detection. A lack of response to a Neighbor Solicitation is one indicator that the neighbor is unreachable.

Books are all well and good, but very out of date books may not be so useful. Even IPv6 has had significant revisions in the last ten years. The best source of truth is the relevant RFCs, both the original ones and any that are marked as having updated or obsoleted them. RFCs are specified in sufficient detail to allow conforming implementations to be written. You can learn all the details of neighbor discovery by reading RFC 4861.

Community
  • 1
Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • Thanks for the corrections; if not using an EUI-64 format there is indeed a need to discover the MAC otherwise. But actually, I don't understand the privacy concerns with the EUI-64 format for link-local addresses, because the link-local address is scoped to the link and on that link, the MAC address will have to be (and can be) known anyway (by Neighbor Solicitation) for Ethernet communication, so for evil intentions, the MAC address can be saved along the stable privacy address on the local link, isn't is? – Edwin Oct 22 '16 at 19:45
  • @Edwin, SLAAC was originally used for all IPv6 addressing, not just the Link-Local addresses, so a host could be tracked. SLAAC is only one method to assign Link-Local addresses. They could also be manually assigned, and that would not give you the MAC address in the Link-Local address. I know some people that want to manually assign all addresses, including Link Local. It seems a lot of work for little to no gain, but it makes them happy, and all IIDs of all the addresses on an interface are the same, in an order which they prefer. – Ron Maupin Oct 22 '16 at 20:23
  • @Edwin And, each host will indeed maintain a Destination Cache (see RFC 4861), which is analogous to the IPv4 ARP table that hosts maintain. – Michael Hampton Oct 22 '16 at 20:48
  • CGA could have been simpler and more secure if addresses had been twice the size. Half the spec is workarounds for only having 64 bits in the interface identifier where they would ideally have wanted around 162 bits. It's a thing to remember whenever the idea that 128 bits is too much comes up. – kasperd Oct 22 '16 at 20:53
  • What do you consider to be non-standard about that Microsoft document? To me it looks like it just summarizes the RFCs you have linked to. – kasperd Oct 24 '16 at 07:21
9

So, you either misunderstand or were misinformed on a few things.

Using SLAAC a host can construct its own IPv6 addressing using its MAC address, but many people thought that this was dangerous, giving away too much information, and allowing a particular host to be tracked. Based on that, privacy extensions and random addressing were developed, and they are used by OSes to provide privacy/security. That means a host can create its own addressing, not based on its MAC address.

When a host needs to discover the MAC address of a neighbor in IPv4, it uses ARP. ARP broadcasts a request, but IPv6 doesn't have broadcast. Instead, every host must join a Solicited Node multicast group. This group is based on the last 24 bits of its IPv6 address. Since IPv6 interfaces can have any number of IPv6 addresses, a host may join multiple Solicited Node multicast groups. An IPv6 host looking for the MAC address of another host will send a multicast request to the Solicited Node multicast group of the target IPv6 address.

This provides an advantage over IPv4 ARP. Since ARP uses a broadcast for requests, it interrupts every host on the layer-2 broadcast domain. Because the Solicited Node multicast group uses the last 24 bits of the target IPv6 address, the ND multicast request will probably only interrupt the target host, or possibly one or two other hosts on the layer-2 broadcast domain.

Ron Maupin
  • 3,158
  • 1
  • 11
  • 16