It seems that the OVH doesn't know how IPv6 address zero compression works.Zero compression can be only used once per address. So if there are addresses like
I'll recommend that they'll read RFC 5952 section 2.1 - and RFC 4291 section 2.2.
Leading Zeros in a 16-Bit Field and Text Representation of Addresses.
Zero compression allows compression one more full zero blocks to :: .
Lead zero compression allows dropping leading zeros within address block.
Example of full address:
Only addresses 16 bytes aka 128 bits, are full addresses.
Full blocks of 0's have been omitted, with :: .
Lead zero compression:
Leading zeros within each block have been omitted.
Both methods combined, most compact representation:
Examples above are all structurally correct.
That address seems to be ok above? Yet it isn't. Why? Because it seems that guys at OVH do the zero compression incorrectly.
The address is shown as above, even if it's supposed to be uncompressed:
And as compressed:
That's right, for some unknown reason they're taking one trailing zero from that 3100 block and omitting it with :: structure. That lost zero is high lighted with red color. I suspect they've got buggy code or something dealing with the address compaction. This mistake seems to be systematic in their management console portal, in different views. I got rid of all IPv6 issues so far, by adding that one missing zero to configurations manually. Same mistake applies to the host IP address as well as the default gateway address. Earlier OVH used uncompressed addresses in the management console, but they implemented the address compression incorrectly. - Lulz.
This interestingly shows the 'standard it security & reliability concepts'. Nobody gives a bleep, if it's working or if the information is correct. Unfortunately I see this happening daily, in all kind of situations. Disinformation is extremely wide spread and nobody cares about the fact, that facts are completely wrong.
Other funny remarks: I also found several sites advertising IPv6 address expansion to full 128 bit notation. Yet even that site worked incorrectly. It seems that they'll only expand the zero compression, and do not correctly expand the lead zero compression. Yet Python does all that correctly.
OVH - Thank you for providing disinformation to your customers and wasting my time for pointless troubleshooting and blog posts. You know, it took me a while to figure out WTF is wrong. And then you complain that the HD is overloaded? Well, it is. If you disinform and mislead customers, it's quite natural that most customers don't get what's wrong.
Edit: Continued three days after noticing the issue. They haven't even bothered to fix the issue yet. OVH's JSON API does give correct (uncompressed / exploded / expanded) address information. But the management console still compresses addresses incorrectly. Other people have confirmed the issue on Twitter as well as I've confirmed it using several different OVH accounts. It's just as I said and nobody bothers even to care about that. - Also added color highlighting. To examples.
Made up IPv4 example to clarify things
It also seems that the IPv6 example is hard to grasp for several people. Let's make IPv4 example if it would be more familiar for everyone. This is made up example, but shows the concept.
JSON API would show full address:
And the management console would show compressed address:
Python & IPv6
This is also reason why using Python standard library ipaddress and similar functions are very nice and get the job done correctly.
kw: OVH, IPv6, fail, addressing, zero compression, won't work, no Internet, issue, problem, fix, connectivity, can't ping gateway, no route to host, default gateway unreachable, IPv6, Internet address addressing, python, representation, human readable, spacing, colon, encoding, ASCII, 85, networking, issues.