5 ms·

Another potential problem with the sometimes-length-varies aspect to IPv6 addresses is that serious software bugs can be hidden. An array allocated to an insuf

Another potential problem with the sometimes-length-varies aspect to IPv6 addresses is that serious software bugs can be hidden. An array allocated to an insufficient size may work for quite a long time with the vast majority of addresses that take advantage of shortening tricks like "abcd::::", and fail only when presented with an address string that uses the maximum possible IPv6 address length. I think this article has a lot of really practical ideas that would help a lot. I suppose the only other thing I’d want to allow in an IPv6 address is a Perl-like underscore anywhere for visual separation that acts like a comment; e.g. Perl lets you say things like 1_000_000 to mean 1000000. The article suggests a single dot but I think that could still be combined with visual underscores for things like "dead_beef_._0001".

Gibbon1 11y ago
I wonder if some sort of base64 encoding wouldn't have been better. "dead:beef:0000:0000:0000:0000:0000:0001" becomes "3q2+7wAAAAAAAAAAAAAAAQ" Which sucks because of the non-alphanumeric characters and the long run of A's, but one gets the idea. Which is to a general user hex encoding might as well be Hungarian.
- vidoc 11y ago
  Anything that would make addresses case sensitive would I think be a terrible idea.
- joveian 11y ago
  https://www.ietf.org/rfc/rfc1924.txt https://www.ietf.org/rfc/rfc1924.txt (base 85 representation of IPv6 addresses)
  - 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.
vidoc 11y ago
> Another potential problem with the sometimes-length-varies aspect to IPv6 addresses is that serious software bugs can be hidden. An array allocated to an insufficient size may work for quite a long time with the vast majority of addresses that take advantage of shortening tricks like "abcd::::", and fail only when presented with an address string that uses the maximum possible IPv6 address length. If the array you are referring to is the human-readable buffer used to store ipv6 addresses, I would assume the 'bugs' you are talking about are entirely similar with ipv4.
nradov 11y ago
Formats like this are a great place to apply fuzz testing. It's easy to write automated test code that generates IPv6 addresses which at least look valid according to the BNF specification. That way you can get pretty good test coverage without having to manually figure out all the possible edge cases.
zimbatm 11y ago
The issue with the dot alone is that in some cases it's indistinguishable from a domain name. "dead.beef" is bound to exist now that ICANN is going crazy with top-level domains.
- api 11y ago
  Someone on Reddit suggested two dots.
  - zeveb 11y ago
    Which of course doesn't help save keystrokes…
    - api 11y ago
      Sure it does: : == two keystrokes using two separate fingers . == one keystroke using one finger .. == ~1.25 (ish) keystrokes, since your finger has to move to the dot once and then tap twice and only one finger is involved :: == 3 keystrokes using two fingers
      - wallacoloo 11y ago
        I respectfully disagree. In normal typing, I don't consider a capital "I" to be significantly more taxing than a lowercase "i". Relatedly, I think there's a reason that I've never heard an argument about why we should prefer square brackets over parentheses (square brackets require no shift while parentheses do). Right off the bat, I notice that when I'm quoting something using double quotes or placing something in parentheses or curly braces, I don't even have to think about pressing shift. I type them just as quickly as any other punctuation. So I don't think there's much validity to this argument based solely on keystrokes.
        krylon 11y ago
        > square brackets require no shift while parentheses do On a German keyboard, parentheses require a shift, but to get square brackets, one needs to hit AltGr (or "Option" on a Mac keyboard) which quickly gets annoying if one has to do it a lot. Except for that, I agree with you.
moreentropy 11y ago
An IPv6 address has 16 bytes and that's how to store them, period. For parsing / generating a string representation there's RFC5952 and libraries in every language that implement it.

Gibbon1 11y ago

I wonder if some sort of base64 encoding wouldn't have been better. "dead:beef:0000:0000:0000:0000:0000:0001" becomes "3q2+7wAAAAAAAAAAAAAAAQ" Which sucks because of the non-alphanumeric characters and the long run of A's, but one gets the idea. Which is to a general user hex encoding might as well be Hungarian.

vidoc 11y ago
Anything that would make addresses case sensitive would I think be a terrible idea.
joveian 11y ago
https://www.ietf.org/rfc/rfc1924.txt https://www.ietf.org/rfc/rfc1924.txt (base 85 representation of IPv6 addresses)
- 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.

vidoc 11y ago

> Another potential problem with the sometimes-length-varies aspect to IPv6 addresses is that serious software bugs can be hidden. An array allocated to an insufficient size may work for quite a long time with the vast majority of addresses that take advantage of shortening tricks like "abcd::::", and fail only when presented with an address string that uses the maximum possible IPv6 address length. If the array you are referring to is the human-readable buffer used to store ipv6 addresses, I would assume the 'bugs' you are talking about are entirely similar with ipv4.

nradov 11y ago

Formats like this are a great place to apply fuzz testing. It's easy to write automated test code that generates IPv6 addresses which at least look valid according to the BNF specification. That way you can get pretty good test coverage without having to manually figure out all the possible edge cases.

zimbatm 11y ago

The issue with the dot alone is that in some cases it's indistinguishable from a domain name. "dead.beef" is bound to exist now that ICANN is going crazy with top-level domains.

api 11y ago
Someone on Reddit suggested two dots.
- zeveb 11y ago
  Which of course doesn't help save keystrokes…
  - api 11y ago
    Sure it does: : == two keystrokes using two separate fingers . == one keystroke using one finger .. == ~1.25 (ish) keystrokes, since your finger has to move to the dot once and then tap twice and only one finger is involved :: == 3 keystrokes using two fingers
    - wallacoloo 11y ago
      I respectfully disagree. In normal typing, I don't consider a capital "I" to be significantly more taxing than a lowercase "i". Relatedly, I think there's a reason that I've never heard an argument about why we should prefer square brackets over parentheses (square brackets require no shift while parentheses do). Right off the bat, I notice that when I'm quoting something using double quotes or placing something in parentheses or curly braces, I don't even have to think about pressing shift. I type them just as quickly as any other punctuation. So I don't think there's much validity to this argument based solely on keystrokes.
      - krylon 11y ago
        > square brackets require no shift while parentheses do On a German keyboard, parentheses require a shift, but to get square brackets, one needs to hit AltGr (or "Option" on a Mac keyboard) which quickly gets annoying if one has to do it a lot. Except for that, I agree with you.

moreentropy 11y ago

An IPv6 address has 16 bytes and that's how to store them, period. For parsing / generating a string representation there's RFC5952 and libraries in every language that implement it.