Introducing draft-denog-v6ops-addresspartnaming

Sat Nov 20 22:15:33 UTC 2010

> 
>> 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