For instance, IPv6's NDP is built on actual IPv6 packets (ICMPv6), rather than some spoofed IP-lookalike thing. No layering violation, and, thanks to multicasting, no need to dump a bunch of broadcast traffic on the layer 2 network.
Only if the L2 network actually supports L2-multicast. Ethernet doesn't, except if your switches are intelligent enough. With cheap ethernet switches, multicast will be simulated by broadcast.
And actually, you can never avoid a layering violation. The only thing that NDP avoids is filling in the source/destination IP portions with placeholders. In NDP, you fill the destination with some multicast IPv6 address. But that is window dressing. You still need to know that this L3-multicast IPv6 address corresponds to a L2-multicast MAC address (or just do L2 broadcast). The NDP source you fill with an L3 IPv6 address that is directly derived from your L2 MAC address. And you still get back a MAC address for each IPv6 address and have to keep both in a table. So there are still tons of layering violations where the L2 addresses either have direct 1:1 correspondences to L3 addresses, or you have to keep L2/L3 translation tables and L3 protocols where the L3 part needs to know which L2 protocol it is running on, otherwise the table couldn't be filled.
It's pretty silly anyway. NDP is more of a layering violation than ARP, because now IPv6 has a stupid circular dependency on itself. Mapping L3 addresses to L2 is a layer below 3, it is not part of layer 3, it is part of the sub-layer that adapts between 2 and 3. DHCP should be part of that sub-layer, too.
Did you know that for every kind of network that IP can run on top of, there's a whole separate standard specifying how to adapt one to the other? RFC 894 specifies how to run IP over Ethernet networks. RFC 2225 specifies how to run IP over ATM networks.
The only thing one should really really really avoid is the TCP mistake of not just having some minimally necessary glue, but that tight coupling of TCP connections to IP addresses in the layer below.
True, but outside bottom-barrel switches, any switch that's not super old should support multicast, no?
Regarding the rest of your comment, I really don't see how all those things count as layering violations. Yes, there is tight coupling (well, more like direct correspondence) between l2 and l3 addresses. However, these multicast addresses are actual addresses furnished by IPv6; nodes answer on these addresses. Basically, the fact that there is semantic correspondence between l2 and l3 is basically an implementation detail. Whereas ARP even needs its own EtherType!
And, yes, nodes need to keep state. But why is that relevant to whether or not this is a layering violation? When two layers are separate, they need to be combined somewhere ("gluing the layers together"). The fact that the glue is stateless seems irrelevant. But again, I'm just a sysadmin.
NDP may very well be a nicer protocol than ARP, but following the logic of the article, the neighbor solicitation part of NDP would be just as unnecessary as ARP.
I disagree.
With IPv4, the layers aren't quite a stack, but, logically, there's Ethernet, and on top of Ethernet is the ARP layer, and on top of that is IPv4. With the exception of DHCP, correctly functioning IPv4 hosts will actually set their source address field and speak IPv4 properly.
With IPv6, there's Ethernet. On top of Ethernet is IPv6, except that no one knows how to communicate. So there are delightful kludges like the RFC 4291 "unspecified" address, and hosts sent a packet with an "unspecified" address to do duplicate address detection prior to actually using their assigned address. To me, this smells like much more of a layering violation than ARP. Not to mention that a network that wants to optimize ARP can optimize ARP without actually interfering with IPv4 packets, but a network that wants to optimize IPv6 neighbor detection needs to mess with IPv6 packets.