fd00:68::1 and fd:0068::1 mean different things now. The former means fd00:0068::1 while the latter means 00fd:0068::1. I would instead have them mean the same thing: fd00:6800::1. The single-colon separator gets syntax but no semantics
I am not sure if this would actually be an advantage.
It would actually be a huge disadvantage. Following the principle of least surprise, whether you like it or not, the multiple colons rule is useful for making IPv6 address human factors better. Additionally, humans will tend to default to seeing the areas between colons as number fields. As such, they expect them to be right justified with leading zeros optional. Dropping trailing zeroes will inevitably lead to more misinterpretations and errors than keeping them. Where this becomes unfortunate is when people make the mistake of writing things like fd/8 or worse, fd::/8. Technically both of these are not correct. fd/8 is simply invalid syntax. The human eye will turn it into fd00::/8 because that's the only possible logical meaning that makes any sense. fd::/8 is worse because the human eye will turn it into fd00::/8 as that is again, the only sensible thing it could represent, while, in fact, as written it means 0::/8. For intuitive reading, things should always be written right justified. No one will misinterpret fd00::/8 or 2001:0d00::/24. Many will misinterpret fd::/8 and 2001:0d::/24.
and the :: separator means "all middle nibbles are zero" instead of "all middle two-byte components are zero."
Putting the burden of parsing that on humans (and computers). Same as modern compression algorithms are optimized to doing more work while encoding and less work during decoding, it does not really make sense to make it harder to understand an address while reading it for the dubious gain of saving up to six colons.
In reality the most you would gain from such a practice would be to save two colons. The other 4 could already be eliminated by the :: in current practice.
I mean, when you think about it, the consequence that :: means "all middle two-byte components are zero" is kinda weird.
It's a commonly accepted, well-defined convention to save humans effort while not sacrificing readability. There are weirder things in technology.
I don't think it's all that weird and it's a major savings in writing out IPv6 addresses and being able to read them (except in lists of varying sized addresses (please, when dumping routing tables and such, just keep the optional zeroes or give us a flag to choose). In practice, the :: usually ends up being placed between the network number and the host number for things with static addresses and rarely appears in EUI-64 based addresses, so, I don't see this as a problem.
Anything you call out will be interpreted as special. The more you call it out, the greater the expectation that the distinction is important. That's human nature.
Pattern recognition is a central part of our intelligence, so yes, it's human nature. This is not necessarily a bad thing.
While I agree that some of the delimitations are social, rather than technical, it's still useful to have them. If this results in some people not assigning their customers a /56 cause it looks funny, so be it.
I don't see a problem with people not assigning customers /56s so long as they go in the correct direction and give /48s and not /60s or /64s.
You've explained netmasks before to folks whose brains couldn't get past the dots in the address. We all have.
I honestly think I never explained (as in, after I understood the matter, myself) netmasks other than as a bit vector. Unless you mean "write 255.255.255.0 in there cause that's what right for you".
Then you are young and never had to deal with systems that didn't know about bit-vector syntax. I have had to explain the translation between bit-vector syntax (/n) and bit-field syntax (255.255.255.240) to many people. It's easy when n is a multiple of 8. After that, it can be quite hard for some mathematically challenged individuals unfamiliar with binary and BCD to wrap their heads around.
And referring to IP address notation as "dotted quads" just reinforces classful addressing concepts so that folks assigning themselves 10/8 subnets damn near always split on /16 and /24 boundaries.
And why shouldn't they? Unless they are a large ISP or similar, they will have enough space for pretty much everything they ever need to do. It's as good as anything and it allows people to be somewhat familiar with this stuff.
Not everyone is an expert and that is fine. Personally, I have no motivation whatsoever to _truly_ understand _everything_ that's involved in today's wireless systems. Still, it's nice that I can use them reliably without needing this level of involvement.
Removing bitmath from operations where possible is a good thing that reduces outages caused by human factors. It's just good human factors engineering. We can't do so in IPv4, there aren't enough bits to do it. We seek to do so in IPv6 with ARIN draft policy 2010-8 and proposal 121.
And even more efficiently when we don't have to repeatedly explain that the mental model implied by the notation style is, in fact, not how the technology actually works.
If the person can grasp what a bit vector is, they will understand. If they don't, they will not understand it anyway and I won't waste time trying to explain it in depth. At least as of right now, you are giving those people some middle ground which allows them to have a good working knowledge to use IPv6 reliably without needing this level of involvement.
Agreed.
No sweat. When I shoot my mouth off, I expect to be challenged on the remarks. Part of the fun lies in discovering whether the thesis is defensible.
For at least a few rounds, I am usually good for that, too. Personally, I think I answered the implicit question above, but it made me re-asses and re-think my personal & professional opinion on quite a few things and that's a Good Thing, from time to time.
Should we all sing kumbayah now?
By the by, as long as I'm criticizing IPv6 notation, let me express just how poor a choice of separator character the colon is. The colon separates the IPv4 address from a directory or port description only slightly less often than the slash. Writing the parsers to handle an IPv6 address as a drop in is a pain in the tail. Should have used a dash, underscore or plus. Those are far more rarely used in tokenization.
A dash is the character people use when there is not a standard. Look at what they had to do for UUIDs to make them recognizable (which worked out really well, especially the version encoding. I really like their solution). Though they had the advantage that substring length _really_ doesn't matter other than as a way to correctly distinguish UUIDs from anything else.
Underscore is a particularly poor choice for a variety of reasons, not the least of which is the resulting legibility of things like: 2001_db8_f3ed__202_3/48 Dash is a poor choice because it becomes potentially problematic to know whether your cisco is telling you that: 2001-0db8-5f03 is a MAC address or a /48 prefix. + would be interesting, but, I believe it also has overloaded semantics and would make addresses look like a math problem in hex anyway: 2001+db8+5f03++32/48 Is that 2001:db8:5f03::32/48 or is that 8cbd.43 (hex fraction approximated) I'd say that loses on both human readability and parser ambiguity too,. Other entertaining possible delimiters worthy of consideration might be: Letter v 2001vdb8v5f03vv32/48 Pretty hard to read. :( Letter I 2001Idb8I5f03II32/48 Also hard to read. :( Hash # 2001#db8#5f03##32/48 This makes a hash of it, but, not too hard to read and not ambiguous. Splat * 2001*db8*5f03**32/48 Not bad, but, who wants to type this into unix systems? B-tick ` 2001`db8`5f03``32/48 Even MORE fun on a unix system. F-tick ' 2001'db8'5f03''32/48 Yet more UNIX fun. Quote " 2001"db8"5f03""32/48 See above Basically, as I recall the earlier discussions of this and the IETF arriving at the decision to use colon (:), it boiled down to the simple fact that colon (:) is the worst choice except for all the others. Owen