Introducing draft-denog-v6ops-addresspartnaming

Sun Nov 21 22:15:12 UTC 2010

On Nov 21, 2010, at 7:54 AM, William Herrin wrote:

> On Sat, Nov 20, 2010 at 5:15 PM, Owen DeLong <owen at delong.com> wrote:
>>>> 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. [...]
>> 
>> 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.
> 
> So... You just dissed my screed about IPv6 notation and then offered
> two fantastic arguments why I'm right... Because in my version fd::/8
> actually is the same as fd00::/8, which, as you rightly point out, is
> exactly what a normal human being would naturally expect.
> 
That's not a reason you're correct, it's a recognition of one of the
warts in the current system and a statement that on the rare
occasion when people are writing IPv6 addresses, they need
to do so with care. So long as one writes the IPv6 address
correctly, it is not hard to read.

There is no problem with the understanding of fd00::/8 for
both humans and machines.

In fact, fd::/8 would be interpreted, I estimate, by approximately
80% of people as fd00::/8 and by the other 20% who are used
to working with numbers and computers as 00fd::/8 until they
realized that the person responsible for that scrawl must have
meant fd00::/8. Thus, it is an ambiguous representation open
to convenient misinterpretation.

The problem with your idea comes when we move on to
fd::/16. In the current system, this is a valid syntax for
00fd::/16. In your system, would this mean 00fd::/16 or
would it mean fd00::/16? Both are equally valid as I
see it. Certainly there is the likelihood for much confusion
even if you have rules that cover it.

> Imea nrea lly, what ifwe wrot eEng lish thew aywe writ eIPv 6add ress
> es? Looks pretty stupid without a floating separator, doesn't it?
> 
If this were prose, sure. It isn't. It's an addressing scheme. I mean,
really, we don't question 99999-1520 or 408-555-1212 which
are much more like what we're talking about.

In fact, it would look pretty weird to most people if we started writing
951-21-42-33 (or I bet they wouldn't expect that was a zip code in
any case). Similarly, if we start placing the separators in arbitrary
places in phone numbers, people get confused.

> We've gone too far down the wrong path to change it now; colons are
> going to separate every second byte in the v6 address. But from a
> human factors perspective, floating colons would have been better.

I still disagree. While I noted the one pathology with the current
system, that same pathology is present with floating colons
and there are others which I also pointed out (difficulty in
reproducing the "correct" placement of the floating colons in
automated output, for example.

>> From a computer parser perspective, a character other than a colon
> would have been better because colons are already claimed for many for
> other syntax elements that include an IP address, like the
> address/port separator in a URL.
> 
The syntax for handling this was already present in IPv4 and is easily
adapted to the problem in IPv6. Simply wrap the IPv6 address in
square brackets (e.g. [2001:db8:feed::cafe]:80 is the ipv6
address 2001:db8:feed::cafe on port 80).

> Making the jump in logic, it would help mitigate the errant design if
> the two-byte groupings separated by the colons were intentionally and
> formally not named. That fits a training scenario which reinforces the
> idea that the colons are there for convenience but that there is
> nothing special about those two byte groupings.
> 
Really, there's no advantage whatsoever to this. All it does is make
talking about address structure more complicated. Having a universal
name will reduce the occurrence of local arbitrary naming which I
believe is a useful practice.

> 
>> 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.
> 
> Cisco's expression of a MAC address is wrong anyway. Correct notation
> for a MAC address is separating each byte with a colon. This has
> always been a PIA for me any time I need to copy a MAC address in to
> or out of a Cisco config.
> 
Doesn't matter... It's widespread and Cisco isn't the only one to use it.
As such, doing this to IPv6 addresses is a recipe for pain.

> 
>> 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.
> 
> Could have stuck with dot and forgone "::192.168.1.1". Or replaced the
> v4 dot with a dash in that scenario. Could have gone with comma and
> quoted the address in CSV files like you do for any text value that
> isn't trivial, instead of bracketing it in much more commonly used
> URLs.
> 
We did forego ::192.168.1.1. However, we still have ::ffff:192.168.1.1
and for good reason. This is a useful construct for allowing humans
to see in log files that an IPv6-aware application on a dual-stack
machine accepted an IPv4 connection on an IPv6 socket.

> 
>>> For example:
>>> 
>>> 260:abcde:123456:98::1
>>> 
>>> 260 - IANA to ARIN, a /12
>>> abcde - ARIN to ISP, a /32
>>> 123456 - ISP to customer, a /56
>>> 98 - customer subnet
>>> ::1 - LAN address
>> 
>> How do you propose to get the router to regurgitate this?
> 
> I don't. The colons float. If the address was learned dynamically, the
> router can regurgitate it any way it wants.
> 
Yeah, because it's always good for human factors when the output
showing an address bears little or no resemblance to the way the
user expects it to be written. NOT!

> The question leads me to recall a fancy version of traceroute I once
> used. In addition to looking up the PTR record for each hop, it also
> looked up the org and AS number currently associated. If users found
> it valuable to have the router present variable colon placement, it's
> a doable albeit complex computing task.
> 
Which, IMO, is a good reason the current system is superior. Fewer
surprises==better human factors engineering.

Owen