What the RFC says is actually immaterial here. The RFC specifies what goes on at the DNS level, but that's moot if ping doesn't make a DNS query in the first place. When ping receives an all-numeric argument, it interprets it as an IP address.
IPv4 addresses are technically 32-bit numbers. They are almost always written in dot-decimal notation, so-called “dotted quads” like 127.0.0.1. But they can also be written as a single number in decimal like 2130706433 or in hexadecimal like 0x7f000001.
$ ping 2130706433 # 127*2^24 + 1 PING 2130706433 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.027 ms $ ping 0.0.25.192 connect: Invalid argument
Addresses in the range 0.0.0.0/8 are reserved for use as source addresses in broadcasts. You can't send a packet to them, which is why connect(2) returns EINVAL.
Many programs, including most ping implementations, have no option to force a DNS lookup. You would run into similar trouble if you made a local network with all-numeric subdomains, and ended up with a valid hostname that looked like a dotted quad.
If your local network has a name, ping 6592.mynetwork will work. But you're likely to run into similar trouble down the line, as sooner or later you'll want to omit the domain name. Just go with the flow and include a letter, preferably at the start.