The proposal doesn't mention it, but part of the existing IPv6 address syntax is that, for transition mechanisms, it offers the option to embed a dotted format IPv4 address syntax in the end of an IPv6 address:
https://tools.ietf.org/html/rfc4291#section-2.2
In the suggested format, we'd lose this convenient transition feature and are left with:
20010DB8..d014403
..FFFF81903426
This is less clear than the existing method with the colons and dots.
If one decides, in this proposal, to support trailing IPv4 addresses as is currently supported, e.g., for IPv6-mapped-IPv4 addresses, some pretty ugly things happen:
20010DB8..13.1.68.3
..FFFF129.144.52.38
Is .13.1.68.3 a typo of an IPv4 address with missing whitespace or is it an IPv6 address with an IPv4 address embedded at the end?
And what about parsing "FFFF129"? Are we really going to change base from 16 to 10 between the "F" and the "1"?
Or are we going to introduce another separator, e.g., a leading "." on IPv4 addresses?
..FFFF.129.144.52.38
Or are we going to require that the ".." be the separator there?
0000:0000:0000:0000:0000:FFFF..129.144.52.38
Or are we going to use the existing format for IPv6 addresses that embed IPv4 addresses, and another format only otherwise (Hint, of course one must support the existing 20 year old format.)
a leading zero on an IPv4 address octet meant that the byte is specified in octal.
One can easily argue that the best solution is to use a different special character, e.g., ":", for IPv6 rather than the IPv4 "." because leading zeroes had a special meaning in IPv4 syntax.
All in all, it looks to me like the early IPv6 community thought about the address syntax... a lot.
Examples: 2001:DB8::13.1.68.3 ::FFFF:129.144.52.38
In the suggested format, we'd lose this convenient transition feature and are left with: 20010DB8..d014403 ..FFFF81903426
This is less clear than the existing method with the colons and dots.
If one decides, in this proposal, to support trailing IPv4 addresses as is currently supported, e.g., for IPv6-mapped-IPv4 addresses, some pretty ugly things happen: 20010DB8..13.1.68.3 ..FFFF129.144.52.38
Is .13.1.68.3 a typo of an IPv4 address with missing whitespace or is it an IPv6 address with an IPv4 address embedded at the end?
And what about parsing "FFFF129"? Are we really going to change base from 16 to 10 between the "F" and the "1"?
Or are we going to introduce another separator, e.g., a leading "." on IPv4 addresses?
..FFFF.129.144.52.38
Or are we going to require that the ".." be the separator there?
0000:0000:0000:0000:0000:FFFF..129.144.52.38
Or are we going to use the existing format for IPv6 addresses that embed IPv4 addresses, and another format only otherwise (Hint, of course one must support the existing 20 year old format.)
To add another historic complication for some implementations: https://en.wikipedia.org/wiki/Dot-decimal_notation#IPv4_addr...
a leading zero on an IPv4 address octet meant that the byte is specified in octal.
One can easily argue that the best solution is to use a different special character, e.g., ":", for IPv6 rather than the IPv4 "." because leading zeroes had a special meaning in IPv4 syntax.
All in all, it looks to me like the early IPv6 community thought about the address syntax... a lot.