On Sat, Nov 20, 2010 at 5:15 PM, Owen DeLong <owen@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@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004