From wikipedia: “When fewer than four numbers are specified in the address in dotted notation, the last value is treated as an integer of as many bytes as are required to fill out the address to four octets. (https://en.wikipedia.org/wiki/Internet_Protocol_version_4)

The address is not the real issue. An IPv4 header contains 32 bits for the source address and 32 bits for the destination address. That's what needed to be extended. IPv4 implementations expect the destination address to be 32 bits after the source address.

Any fix you can think of to extend the address fields in the header will fall into the situation of having an additional protocol. Because changing the v4 header and calling it a v4 header would probably get your packet dropped as bad. Or have it being sent to somewhere else. Or some other undefined behavior.

So your best option is to have it identify as a new version. Yes, v4 implementations will reject your packet, but that's what you want in this case.

Seriously. IPv4=8.8.8.8 means "this goes to the DNS server". The DNS server helps you find all the other IP addresses you need, which is why this one is special. One DNAT rule, one SNAT rule, and you're done.

IMO IP should have had this feature from day one.

So if it gets an ethernet frame destined for your address starting with 4 or 6, it will think it's actually an IP payload, and discard it because it doesn't validate as a IP packet or otherwise misdirect it.

Edit to add: In MPLS networks, 'P routers' (core routers) by design don't know if the payload is Ethernet or IP; but may want to peak into the payload to do hashed traffic balancing or validating packets before forwarding. Hashing the packet as an IP packet when it's an ethernet packet is problematic because you want all packets on a given TCP connection to have the same hash value -- but since you misidentified the type of packet, the bytes used as input to the hash aren't static for a given connection so different packets in the connection may take different paths and may arrive out of order.

All IPv4 address are 32 bit addresses. That's why each number of an IPv4 address that people are familiar with are called octets. They represent 8 bits of the 32 bit address. So if you have 127.0.0.1, then the first octet is 127, the second is 0 and so on.

Any representation of this 32 bit number (including the most familiar A.B.C.D format) is a kind of short-hand for representing that 32 bit number.

I tried finding a link to a particular site that was phenomenal for learning the entire TCP/IP stack but I haven't seen that site since at least 1998.

But basically, if you want to spend time learning about IPv4 right before IPv6 becomes the dominant standard, then look into how hosts use the combination of IP address and subnet mask to determine if something is on the local network, how hosts use ARP to translate a 32 bit IP address into a MAC address and all the other low level protocols.

This is the bit that wasn't in djb's original article AFAIR. My take was that 1.2.3.4 and 1.2.3.4.0.0.0.1 would be the same machine -- or at least allocated to the same entity.

The "special" case is supporting network addresses to be written as 10.2932832 ("convenient" for class A's), 172.16.61031 (ditto for B's), or just one big address like 39282329, when we're used to 4 octets separated by dots.

Not every bit of host software supports these cases anymore, as basically their sole remaining use case is as a curiosity or to circumvent bad security controls.

Edit: An aside, these addresses are different in both text or binary representation, but the article doesn't provide many details, so I can't entirely follow.