Introducing draft-denog-v6ops-addresspartnaming

Sun Nov 21 15:54:34 UTC 2010

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.

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?

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

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.

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

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

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

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.

Regards,
Bill Herrin

-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004