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