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".
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.
> 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.
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.
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.
> 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.
> 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).
FWIW, I switch parens and square brackets for exactly that reason. It'd be great if distros offered this as an option, but I know my way around xkb enough to do this much.
I get downvoted every time I mention this, but I'll live with it-- I want to recruit people to typing with caps lock (especially vim users, already used to modal typing).
On /some/ keyboard layouts that may be true, but remember, on different layouts, you get different results.
On German layout, for example, `:` is on `Shift` + `.` – and therefore just as easy to use as `.`
(Sorry for the formatting, but this damn page doesn’t have any useful formatting syntax, or escaping. If you want to enjoy the formatting properly, just use a userscript to run a markdown parser over this page).
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.
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?
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.
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.
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".