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!
On Wed, 17 Mar 1999, Engin Gunduz wrote:
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?
I'm not sure that adding yet-another-option is a good idea for general queries, although it would be for setting up various 'interesting' end-user parsing routines. Can I suggest instead that the database returns a '% Comment' line before the object, which most end-user parsing routines should be ignoring (except for '% No objects found'), in the form: '% IPv6 found: short is xx:xx::/xx, long is xx:xx:0:0:0:0:0/xx' which would make a) casual queries of IPv6 objects easy to read and b) educate said casual queriers about short and long versions of IPv6 numerics. Anything which the database 'officially' returns should be in its expanded form (same as IPv4 objects).
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.
Make shorthand notation on the input side a warning condition when the notification/object is returned to the user (eg: WARNING, expanded xx:xx::/xx to xx:xx:0:0:0:0/xx etc), so that the database works in fully qualified IPv6 numbers (FQIPv6N?), but understands both. Regards, -- Bruce Campbell <bruce.campbell@apnic.net> +61-7-3367-0490 Systems Administrator (#2) Just dis guy Asia Pacific Network Information Centre
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 (6)
-
Bruce Campbell -
David Kessens -
Engin Gunduz -
Guy Davies -
Poul-Henning Kamp -
Wilfried Woeber, UniVie/ACOnet