3 ms·

https://www.ietf.org/rfc/rfc1924.txt https://www.ietf.org/rfc/rfc1924.txt (base 85 representation of IPv6 addresses)

by joveian 11y ago

Dylan16807 11y ago
Base85 naturally encodes 32 bits at a time into 5 characters, why is this using 128 bit math? I can't tell if it's a joke, with that date. Edit: The commentary at the end suggests more of a joke, even though "It may be expected that future processors will address this defect, quite possibly before any significant IPv6 deployment has been accomplished." wasn't exactly false. I'm not sure why you linked an intentionally-bad RFC for a reasonable concept?
- greggyb 11y ago
  April Fool's RFCs are a bit of a tradition[0]. I'm a fan of the proposal for IPoAC[1]. [0] https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_Comments https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_C... [1] https://tools.ietf.org/html/rfc1149 https://tools.ietf.org/html/rfc1149
  - Dylan16807 11y ago
    Oh I understand why the RFC exists. But they should have put a bit more effort into it, and joveian should have made clear that it was a low-effort RFC, joke or not. I'll be more clear about my earlier post. I realized the RFC itself was put out as a joke, but I couldn't really tell if the 128 bit math was bad on purpose or out of laziness. Or what the RFC author actually thought about using such a compact representation.
    - joveian 11y ago
      I am curious about the background behind it and the author's opinion of the basic idea as well. I think the 128-bit math part was just intended to invent context for a jab at standards that assume recent hardware and not really intended to make sense in context. I admit it was a low effort comment on my part :/. It seems like something along those lines could be a good idea, although in practice I think 22 URL-safe base64 characters with four error correction bits would be better representation. Looking at Wikipedia's nice base64 page, one possibility would be to use '-' and '_' for the two non-alphanumeric characters and allow the longest run of zeros ('A's) to be changed to '~'. Automatic error detection seems like a really good idea whenever humans are forced to interact with 128-bit numbers, but then you can't easily generate subnet masks by hand. In general, I think avoiding interacting with them as much as possible is the most important step. At this point, it would take a while for any alternate representation to be widely supported by software even if there was wide agreement that it was a good idea. OTOH, a general "least bad" compact representation of larger numbers with error detection could potentially be useful for other things (even if it doesn't get used for IPv6), such as ECC public keys.
Gibbon1 11y ago
My Dad told me once, every good idea has already been thought of by someone else.

https://www.ietf.org/rfc/rfc1924.txt https://www.ietf.org/rfc/rfc1924.txt (base 85 representation of IPv6 addresses)

by joveian 11y ago

https://www.ietf.org/rfc/rfc1924.txt https://www.ietf.org/rfc/rfc1924.txt (base 85 representation of IPv6 addresses)

Base85 naturally encodes 32 bits at a time into 5 characters, why is this using 128 bit math? I can't tell if it's a joke, with that date. Edit: The commentary at the end suggests more of a joke, even though "It may be expected that future processors will address this defect, quite possibly before any significant IPv6 deployment has been accomplished." wasn't exactly false. I'm not sure why you linked an intentionally-bad RFC for a reasonable concept?

greggyb 11y ago
April Fool's RFCs are a bit of a tradition[0]. I'm a fan of the proposal for IPoAC[1]. [0] https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_Comments https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_C... [1] https://tools.ietf.org/html/rfc1149 https://tools.ietf.org/html/rfc1149
- Dylan16807 11y ago
  Oh I understand why the RFC exists. But they should have put a bit more effort into it, and joveian should have made clear that it was a low-effort RFC, joke or not. I'll be more clear about my earlier post. I realized the RFC itself was put out as a joke, but I couldn't really tell if the 128 bit math was bad on purpose or out of laziness. Or what the RFC author actually thought about using such a compact representation.
  - joveian 11y ago
    I am curious about the background behind it and the author's opinion of the basic idea as well. I think the 128-bit math part was just intended to invent context for a jab at standards that assume recent hardware and not really intended to make sense in context. I admit it was a low effort comment on my part :/. It seems like something along those lines could be a good idea, although in practice I think 22 URL-safe base64 characters with four error correction bits would be better representation. Looking at Wikipedia's nice base64 page, one possibility would be to use '-' and '_' for the two non-alphanumeric characters and allow the longest run of zeros ('A's) to be changed to '~'. Automatic error detection seems like a really good idea whenever humans are forced to interact with 128-bit numbers, but then you can't easily generate subnet masks by hand. In general, I think avoiding interacting with them as much as possible is the most important step. At this point, it would take a while for any alternate representation to be widely supported by software even if there was wide agreement that it was a good idea. OTOH, a general "least bad" compact representation of larger numbers with error detection could potentially be useful for other things (even if it doesn't get used for IPv6), such as ECC public keys.

Gibbon1 11y ago

My Dad told me once, every good idea has already been thought of by someone else.