0

IPv6 – Solicited Node Multicast Address

This is one of the other optimizations done by IPv6. In the case of IPv4, the layer 3 and layer 2 addresses are essentially uncoupled, where as in the case of IPv6, layer 3 address gives us some hint about layer 2 address.

In the case of ARP resolution, an ARP request is broadcast – one of the side effects of it is that all the nodes on the local link are supposed to trap the packet and inspect it to check if it is the intended recipient.

However, with IPv6, the packet is not broadcast, but multicast. That is, there is a standard way to frame an IPv6 destination address given the IPv6 target address for link layer resolution – i.e. node A knows about node B’s IPv6 address, but not its link layer address. In this case, the packet would be sent to ff02::1:ff <24-bit suffix of target IPv6 address>. All the nodes which have the same 24-bit suffix of the target IPv6 address (essentially mostly only one node) will listen to the aforementioned multicast address and then process it.

From a layer 2 perspective, there is no bandwidth savings – because the packet would still be broadcast on VLAN, however from a layer 3 perspective – i.e. node’s perspective – not all nodes inspect the packet – the packet would get dropped early on all the nodes except the intended listener. Needless to say, even routers need to listen on that.

In essence, there is no broadcast packet in this case, so even routers are saved from examining the packet by trapping them to ARP daemon. Since the packets cannot be sent, anyways, on other links, routers need not do anything here.

One quick point to be taken home is that – nodes are not supposed to assume that the MAC is embedded in the last 64 bits of IPv6 address with EUI 64 format. If they assume that, there is no need to fire a ND request at all in the first place. Data links other than Ethernet can also be used and one can never be sure.

0

On IP (v4/v6) and Fragmentation

Well, does the source node sending an IP packet worry about fragmenting the data being sent, just because some nth hop’s data link does not support such large packets? The source node does not even know about the path the packet is going to take – that’s the essence of connectionless network layer anyways. What if the path the packet changes subsequently?

The original notion of fragmentation with IPv4 made sense to me. If an arbitrary router find its data link to parochial, it will fragment it and send it across. The destination node will re-assemble the packet and deliver it to the gods.

However, IPv6 made source based fragmentation mandatory. The only fact that comes to the source node’s rescue – in dealing the MTU of the path – is the minimum MTU that needs to be supported which is 1280 bytes. If the source node does not wish to participate in this exercise of MTU discovery, it can choose to send the minimum MTU packets safely. Otherwise, it has to run along hops to discover the MTU.

The only reason I can think of for removing this is to relieve routers of online (i.e. data path speed) fragmentation of packets which may need complex hardware to achieve the same.

I did not like this approach.