IPv6

Matter field issues often sound very vague at first: the device supports Matter but cannot be added; it has already been added but the app still cannot find it; some devices in the same home connect instantly while others keep dropping. Once you break it apart, the bottleneck is often not in the same layer at all. Some devices never get past the BLE (Bluetooth Low Energy) onboarding entry. Some have already obtained Wi-Fi or Thread join material but still have not entered the target IP network. Some already have IPv6 addresses but have not been brought into the target Fabric. Others are already in the Fabric but fail later at runtime discovery, session establishment, or specific Cluster access.

Many Thread field issues sound simple at first: the device cannot join the network, or it has joined but the app still cannot find it. Once you break it apart, the bottleneck is often somewhere else. Some devices never even found the target PAN (Personal Area Network). Some completed commissioning but never truly attached to the Thread network. Some already have an on-network address but still have no usable prefix. Others can communicate inside the mesh, but still cannot reach a home LAN (Local Area Network) or a cloud service.

IPv6 is not only about knowing your own address. A host also needs to know who the default router is, where local neighbors are, whether an address conflicts with someone else, and which prefixes can be treated as directly reachable on the local link. If you still split those jobs the way IPv4 often did, boundaries keep getting loose.

NDP handles that problem. It is not as simple as “turn ARP into IPv6 length addresses”. It brings neighbor resolution, router discovery, prefix advertisement, and address conflict detection into one ICMPv6 control-message framework for the IPv6 local link.

If you think of IPv6 as “changing IPv4 addresses from 32 bits to 128 bits”, this article would not need to exist. What actually makes IPv6 a different network model is not just that the address got longer. It also rewrites several default assumptions that had been bothering IPv4 networks for a long time: address scarcity, widespread NAT, separate ARP, messy fragmentation boundaries, and host configuration that depends heavily on centralized assignment.

When the same data has to go to many receivers, there are usually only two extremes: send a separate copy to each one, or broadcast it to the whole network. The first is simple, but once the number of receivers grows, the sender and the network get buried under duplicate traffic. The second looks convenient, but it also disturbs devices that should never have received that data in the first place. Live video, market data distribution, service discovery, routing neighbor announcements, and many local-link control messages all need something different from either extreme.