• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

Can't Figure Out Layer 2

Started by wswartzendruber, July 10, 2012, 12:15:07 AM

Previous topic - Next topic


I mentioned to my boss and coworker that IPv6 doesn't have ARP.  I was met with skepticism.  Then I started reading to figure out how MAC addresses are resolved from IPv6 addresses.  Needless to say, I have no actual idea how this all really works.  It seems that the ARP stuff has migrated to specialized ICMPv6 packet types, but how does something with a Layer 3 address get to a physical device?  Aren't IPv6 addresses still mapped to MAC addresses?  At first I thought the link-local address was relied on, but it seems that even that can be arbitrary.

I'm very weak on Layer 2 stuff.



Quote from: wswartzendruber on July 10, 2012, 12:15:07 AMIt seems that the ARP stuff has migrated to specialized ICMPv6 packet types
That is indeed correct.

Ethernet has a 16 bit field identifying the higher level protocol. When using IPv4 two different 16 bit identifiers were used, one for ARP another for IPv4. With IPv6 only a single 16 bit identifier is used. That however is not the most important difference.

With IPv6 there are multicast addresses. Instead of sending an ARP request as a broadcast packet over Ethernet a ND message is sent to an IPv6 multicast address. The multicast address to use is deduced from the IPv6 address. But that just added a layer of abstraction, you still need to send the ND message on the physical network. Now however the destination address is no longer a unicast IPv6 address but a multicast IPv6 address. The multicast addresses are mapped to special MAC addresses starting with 33:33: (one of those first 16 bits in fact indicates that this is a multicast MAC address.)

With the above two steps the IPv6 address which you want to find a MAC address for is mapped to a MAC address to which the request can be send. If the switch handle the packet the same way as one send to a unicast address, it will find that it has never received a packet from that MAC address, thus it doesn't know its location on the network, and the switch will send it on all ports. It may also be that the switch knows the destination MAC is a multicast address, but doesn't know where interested receivers are, thus it sends it on every port.

Most likely the ND message will end up being send over every link on the LAN anyway, since none of the switches knows where it needs to go. However in the future we may start seeing switches which can take hints from IPv6 about who are in which multicast groups, at which point the switches will know not to broadcast the ND messages.

ND is slightly more complicated than ARP, but from an operational perspective, it works almost the same. It has the potential to be more efficient, but that's not significant yet. As the number of hosts on a segment increases the percentage of the network resources consumed by ARP packets increases, and that puts a limit on how large segments you can use.

Once operating systems stop enabling IPv4 by default and once switches have better multicast support, you can start using more hosts on each segment without the usual performance problems. Don't expect this anytime soon.

Since ND packets are send over IPv6 they can be routed over the internet. This is not supposed to happen, but sometimes it does (see the thread about www.opensuse.org). ND packets forwarded by routers can be a security problem. Sender can set the hop limit to 1 to prevent this, but then the receiver wouldn't know if it was spoofed. Alternatively the sender can set the hop limit to 255 and the receiver can drop any ND message that has a lower hop limit. If receivers drop all ND messages with a hop limit less then 255, then any forwarded ND message would be dropped.

Applying packet filters to prevent ND messages from being spoofed may be good practice. But it is not effective since such filters can be bypassed through fragmentation. So it is a good idea to drop any ND message resulting from reassembly.

So compared to ARP, ND does offer possibility for better performance, but it also opens for new sorts of security problems. And being a younger protocol it has not had the same level of scrutiny as ARP.