I'd suggest that anyone doing an IP stack for P2 focus on IPV6 first. It's much nicer to work with. It truly takes zero configuration in the rather typical scenario of plugging a device into an Ethernet switch and then accessing it from Windows 10. It's not the sort of "fallback" or "poor-man's network" thing we had with IPV4.
IPV6 design has taken lessons from IPV4 and fixed some real shortcomings. In IPV4, the autoconfigured addresses are in a subnet that's not accessible if there's typical central administration of network addresses (a.k.a. DHCP). The traffic to those addresses goes into the gateway and gets forwarded to a bit-bucket there. That's the typical case I've seen on most "centrally" administered networks. So if you plug in a device that doesn't bother listening to DHCP, or that the DHCP server refuses to assign an address to, you won't be able to use it on an IPV4 network without resorting to talking to it over a raw socket.
With IPV6, the router advertisements are just that: they let devices know where to send packets to get them routed outside of the broadcast domain, and they let the devices know what IPV6 address prefix they should use if they want an Internet-routable address for themselves. But that's all optional. A device can autoconfigure its sole IPV6 address - and rather quicker than on IPV4. And then it's accessible from all other devices that can exchange broadcast traffic with it. It's not a second-class citizen anymore.
On some corporate networks IPV6 is centrally disabled on Windows endpoints by domain policy, and then it's a bummer of course, but it's hopefully a receding trend.
Device segregation is also much nicer with IPV6, since there's no need to administer L3 subnets. Since the IPV6 header is extensible, switches can embed L2 vlan id into into the IPV6 header. This can be used by the routing/firewall infrastructure to classify traffic without the need to maintain the VLAN:SUBNET correspondence that was a fact of life in IPV4 - due to the inflexibility of the IPV4 header.