3 ms·

UTF-8 took over entirely for backwards compatibility reasons

by HWR_14 4y ago

kevin_thibedeau 4y ago
UTF-16 is a PITA if you're working outside the BMP. At that point you're dealing with variable size codepoints anyway and may as well use a more compact encoding.
p1mrx 4y ago
Text files are variable length; IP addresses are fixed length.
tialaramex 4y ago
There can be no "backwards compatibility" for an IPv4 successor because of the pigeonhole principle. UTF-8 is popular on modern computers with an 8-bit byte, conveniently leaving a whole bit free on the common ASCII text encoding and of course text is handled in sequences, so the multi-byte arrangement isn't inherently incompatible. However IPv4 doesn't have either a convenient spare bit which can be re-purposed, nor an interpretation where you just get to string more addresses together and that's fine. Your IPv4 packets contain exactly one 32-bit IPv4 source and one 32-bit IPv4 destination.
- HWR_14 4y ago
  IPv4 packets and processing code have exactly one 32-bit IPv4 source/destination and would not work. That's not how I interpreted the request. I took the point as "IPv6 as a standard should have been designed to take an IPv4 address and convert it reliably to a specified IPv6 address, which we would set up to route to the same location." That is, old software that requested an IPv4 address could have it translated by the OS into an IPv6 packet before transmission deterministically, people with memorized IPv4 address could use them in the future, etc.
  - cesarb 4y ago
    > That's not how I interpreted the request. I took the point as "IPv6 as a standard should have been designed to take an IPv4 address and convert it reliably to a specified IPv6 address, which we would set up to route to the same location." That is, old software that requested an IPv4 address could have it translated by the OS into an IPv6 packet before transmission deterministically It appears you are asking for the "IPv4-mapped IPv6 addresses", which are of the form ::ffff:x:y, where xy is the 32-bit IPv4 address (there's even a special text format for these addresses, you can use ::ffff:a.b.c.d instead of having to convert the IPv4 address to hexadecimal). The only difference from what you are asking is that these addresses are routed through the IPv4 network; they allow applications written with only IPv6 in mind to still work with IPv4 networks. Or you might be thinking of something like SIIT (Stateless IP/ICMP Translation), which uses addresses of the form ::ffff:0:x:y (which can also use the same kind of special text format as above).

UTF-8 took over entirely for backwards compatibility reasons

by HWR_14 4y ago

UTF-8 took over entirely for backwards compatibility reasons

UTF-16 is a PITA if you're working outside the BMP. At that point you're dealing with variable size codepoints anyway and may as well use a more compact encoding.

p1mrx 4y ago

Text files are variable length; IP addresses are fixed length.

tialaramex 4y ago

There can be no "backwards compatibility" for an IPv4 successor because of the pigeonhole principle. UTF-8 is popular on modern computers with an 8-bit byte, conveniently leaving a whole bit free on the common ASCII text encoding and of course text is handled in sequences, so the multi-byte arrangement isn't inherently incompatible. However IPv4 doesn't have either a convenient spare bit which can be re-purposed, nor an interpretation where you just get to string more addresses together and that's fine. Your IPv4 packets contain exactly one 32-bit IPv4 source and one 32-bit IPv4 destination.

HWR_14 4y ago
IPv4 packets and processing code have exactly one 32-bit IPv4 source/destination and would not work. That's not how I interpreted the request. I took the point as "IPv6 as a standard should have been designed to take an IPv4 address and convert it reliably to a specified IPv6 address, which we would set up to route to the same location." That is, old software that requested an IPv4 address could have it translated by the OS into an IPv6 packet before transmission deterministically, people with memorized IPv4 address could use them in the future, etc.
- cesarb 4y ago
  > That's not how I interpreted the request. I took the point as "IPv6 as a standard should have been designed to take an IPv4 address and convert it reliably to a specified IPv6 address, which we would set up to route to the same location." That is, old software that requested an IPv4 address could have it translated by the OS into an IPv6 packet before transmission deterministically It appears you are asking for the "IPv4-mapped IPv6 addresses", which are of the form ::ffff:x:y, where xy is the 32-bit IPv4 address (there's even a special text format for these addresses, you can use ::ffff:a.b.c.d instead of having to convert the IPv4 address to hexadecimal). The only difference from what you are asking is that these addresses are routed through the IPv4 network; they allow applications written with only IPv6 in mind to still work with IPv4 networks. Or you might be thinking of something like SIIT (Stateless IP/ICMP Translation), which uses addresses of the form ::ffff:0:x:y (which can also use the same kind of special text format as above).