Thoughts on the chaos of ARP

Once upon a time, how simple people were, and they created a protocol like arp. This form of group Q & A is always either feasible or authoritarian in organizations such as utopia, if there is a question for all, the answer is often a strange one, and the ghost knows how many answers are spoofing. ARP's question is for the whole, but is the answer correct? How can the sender of the ARP request identify it? In addition to ethics, the ethics of machines that send ARP responses can be trusted, and there is no standard for others. However, ARP responses to machines itself will not be issued, and the software will not know how to send them, only those who compile software know it. Therefore, this is a matter of human ethics. People are selfish and self-oriented, so ARP is inherently insecure! ARP is essentially built into the "ARP spoofing" feature, which is exactly what ARP authors have granted.
I think the ARP proxy function is a spoofing function, but it is a kind of good deception. If ARP explicitly prohibits such spoofing, it will be much better, however, communication between machines that no longer have a network segment and no gateway is difficult, or socket communication with so_dontroute is troublesome. For this convenience, ARP proxy is pampered, at the same time, ARP spoofing is also supported. ARP proxy may also cause some confusion. For example, if one or more machines in the LAN have an ARP proxy, and the requested machine address is on the "other end" of the ARP proxy machine, then these machines will reply to the ARP request, different implementations of ARP cache update policies based on various operating system protocol stacks may have different behaviors, for example, in Linux, if a configurable time (use sysctl to configure/proc/sys/NET/IPv4/neigh/eth0/locktime) there are two or more different ARP replies in Linux, so Linux will adopt the first incoming ARP reply, and the arrival of ARP replies will not update the Linux ARP cache, however, for Windows Server 2003, the situation is different. The reason for locking an ARP reply for a period of time is that the ARP sender has reason to believe that the fastest replying host is the best host, since several of them can process this ARP request, select the first one. The ARP sending end is only responsible for sending data to the next hop to the destination ", whether or not the next hop can actually deliver data to the destination is complicated in the future...
Not only ARP, but also the most obvious IP protocol, which was designed in an ideal situation, the IP itself has many inconveniences, but the opposite voice has emerged, how can I manage IP addresses? Since the above TCP and SSL can handle connections and Security Well, why isn't the simpler the IP address, the better? In short, it is difficult to adjust the public, and practical is the first!