Re: Modifications to the inet6num in the RIPE Database
Guy, Engin, thanks a lot for the explanation! Guy said:
Finally, you can only have one of these constructs per address. This is common sense really since, if you have 3ffe::aaaa::bbbb, you cannot tell how many zeroes are replaced with the first pair of colons and how many by the second. There is no convention (AFAIK) for which block would be written out in full. Personally, since I am lazy, I choose to write out the fewer number of zeroes (remembering that I only need one zero per block of 4 hex digits).
So, some examples of IPv6 addresses are...
3ffe:1100:0:c00::/52 = Note the :0: because there is a :: later in the address
Engin added:
The algorithm we use translates "5:0:0:78:0:0:0:0" into "5:0:0:78::" but not "5::78:0:0:0:0". Of course, both are legal, but we choose to double-colonize the last group of zeros, and all prefixes are normalized according to this and then put into the registry.
which already gives us two compatible but different ways to deal with that, and
But I don't know what 6bone registry does.
interesting, indeed. Taking this one step further, and looking back at what we did with IPv4, where it would be feasible to say 131.130/16, implying 131.130.0.0/16, I wonder if it wouldn't again be worthwhile to restrict the use of these shorthand notations in the Address Registry? Is there a danger for braking something by _not_ allowing the "::" construct in the registry at all, or - in particular - not _in the middle_ of a prefix? Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------
In message <009D5362.46E0DF3C.25@cc.univie.ac.at>, "Wilfried Woeber, UniVie/ACO net" writes:
Taking this one step further, and looking back at what we did with IPv4, where it would be feasible to say 131.130/16, implying 131.130.0.0/16, I wonder if it wouldn't again be worthwhile to restrict the use of these shorthand notations in the Address Registry?
There is certainly something to be said for making it easy for programs to parse the registry. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far!
On Tue, Mar 16, 1999 at 06:48:15PM +0100, Poul-Henning Kamp wrote:
In message <009D5362.46E0DF3C.25@cc.univie.ac.at>, "Wilfried Woeber, UniVie/ACO net" writes:
Taking this one step further, and looking back at what we did with IPv4, where it would be feasible to say 131.130/16, implying 131.130.0.0/16, I wonder if it wouldn't again be worthwhile to restrict the use of these shorthand notations in the Address Registry?
There is certainly something to be said for making it easy for programs to parse the registry.
The current registry abbreviates. While this means a little more work for machines, people seem to have more trouble parsing long lines and are more difficult to fix in this regard than a simple parser in a program. I don't think that adding zeroes makes it easier to read and editing an existing object doesn't get very easy either: inet6num: 3FFE:1100:0:C00::/56 becomes: inet6num: 3FFE:1100:0000:0C00:0000:0000:0000:0000/56 David K. ---
Hi, Personally, I would like to see 2030:0:5::/48 instead of 2030:0:5:0:0:0:0:0/48 as the result of the query in the whois database, since shorthand notation is, IMHO, more "readable" by human eye. However, maybe we can introduce yet another option to the whois server and client to show the query result on inet6num objects without shorthand notation? Well, restricting the usage of shorthand notation could ease the implementation of the whois server. But, IMHO, in the user side, it is better to allow it. Best regards, Engin Gunduz RIPE NCC Poul-Henning Kamp wrote:
In message <009D5362.46E0DF3C.25@cc.univie.ac.at>, "Wilfried Woeber, UniVie/ACO net" writes:
Taking this one step further, and looking back at what we did with IPv4, where it would be feasible to say 131.130/16, implying 131.130.0.0/16, I wonder if it wouldn't again be worthwhile to restrict the use of these shorthand notations in the Address Registry?
There is certainly something to be said for making it easy for programs to parse the registry.
-- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far!
Uhm, I think people got my comment wrong: I don't particular care if we use :: shorthand or not, I just want it to be sufficient systematic that programs can parse it reliably. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far!
interesting, indeed.
Taking this one step further, and looking back at what we did with IPv4, where it would be feasible to say 131.130/16, implying 131.130.0.0/16, I wonder if it wouldn't again be worthwhile to restrict the use of these shorthand notations in the Address Registry?
Is there a danger for braking something by _not_ allowing the "::" construct in the registry at all, or - in particular - not _in the middle_ of a prefix?
I have to admit that in recording address allocations in UUNET UK's networks, I write the addresses out in full. I tabular format, it makes for much easier identification of errors and anomalies. In the RPSL format, it's a little more difficult to point to benefits for humans but, as PHK pointed out, it's easier for machines to parse. However, given that at least a few dozen hardware and software vendors have come up with a reliable way to parse the abbreviated form, it can't be that difficult. Regards, Guy
participants (5)
-
David Kessens -
Engin Gunduz -
Guy Davies -
Poul-Henning Kamp -
Wilfried Woeber, UniVie/ACOnet