nanog mailing list archives

Re: Introducing draft-denog-v6ops-addresspartnaming


From: Richard Hartmann <richih.mailinglist () gmail com>
Date: Mon, 22 Nov 2010 12:40:39 +0100

On Sun, Nov 21, 2010 at 16:54, William Herrin <bill () herrin us> wrote:
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.

Which is against every expectation of anyone who ever learned Arabic
numbers in a left-to-right system. As Owen pointed out, filling with
zeros on the right-hand side would be, to put it lightly, a disaster.
Maybe I should have worded that more strongly in my last reply.


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?

Reductio ad absurdum.


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.

No. See my, and Owen's, emails.


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.

It's the least bad amongst a highly limited choice of even worse
chars. There is a reason why the colon is used so often.


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.

Personally, I have no interest whatsoever in limiting my efficiency
and increasing the chance that I or others make mistakes because
people who don't understand the matter at hand might misinterpret
something.


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.

If you ever looked at the state of a lot of data in the RIR's whois
databases, you know that's literally impossible. And a _lot_ of effort
for little to no gain. And what if a LIR changes their numbering
scheme, at some point? Attach parsing instructions to inetnum?


Richard


Current thread: