New RIPE DB sw version
Joao Luis Silva Damas joao at ripe.net
Fri Jun 4 11:12:45 CEST 1999
Dear all, the RIPE NCC is happy to announce version 2.3 of the RIPE Database software. This new version introduces complete support for the IPv6 address objects. Only the RIPE NCC can introduce objects with value ALLOCATED in the status field of IPv4 address objects. This reflects the current registration policy. Some other minor features and a number of bug fixes have been introduced. For more details, please see the release notes included below and on the software package. This new version is available immediately from ftp.ripe.net and will be used on whois.ripe.net starting next Monday (7th June). Regards, Joao Damas DB Group RIPE NCC -------------- next part -------------- RELEASE NOTES for RIPE Database 2.3 This a new release with substantial new features added. There are also some bug fixes and some operational enhancements. SUPPORTED SYSTEMS This release has been tested with perl 5.004_04 on bsdi3.1 and Solaris 2.6 systems. Please let us know if you have problems running it on other systems. NEW FEATURES Changes on inet6num object: - mnt-lower attribute has been added to the inet6num object, so that users will be able to use hierarchical authorisation with inet6num objects. - status attribute has been added to the inet6num object. It is a generated attribute. Possible values are TLA, SUBTLA, NLA and SLA (Top Level Aggregator, Sub-TLA, Next Level Aggregator and Site Local Aggregator). o inet6num objects with a prefix length between 4 and 15, inclusive, are assigned TLA in their status attribute. o For TLA 0x0001 (first two bytes are 2001 in hexadecimal notation): o prefixes between 16 and 35, inclusive, are assigned SUBTLA value in status attribute. o prefixes between 36 and 48, inclusive, are assigned NLA value in status attribute. o prefixes between 49 and 64, inclusive, are assigned SLA value in status attribute. o For TLAs other than 0x0001: o prefixes between 16 and 24, inclusive, are not allowed, since they are reserved bits. o prefixes between 25 and 48, inclusive, are assigned NLA value in status attribute. o prefixes between 49 and 64, inclusive, are assigned SLA value in status attribute. o inet6num objects with a prefix length grater than 64 are not allowed. - Only aggregatable global unicast address blocks can be registered in the database (the most significant three bits are 001). A check has been added for updates of inetnum objects. Only certain maintainers are allowed to add inetnum objects with status ALLOCATED now, others should use ASSIGNED. The list of authorised maintainers is set in the configuration file with the following syntax ALLOCMNT <mntnername> [<mntnername> ...] Instead of putting many mntners in this line, the setting can span many lines. INCLUDE facility. A possibility of splitting the configuration file into separate files has been added. The syntax is INCLUDE <filename> Inclusion may be nested (up to the number of free file descriptors). If the <filename> does not contain a "/" sign, it is considered to refer to a file from the same directory as the main configuration file. newdb changes. The newdb program has been modified, a few minor bugs have been fixed. Now, if a database file exists, newdb -a prints a warning message and skips that file (before, it would stop with an error). New syntax checks. The regular expression passed in the auth attribute like follows auth: MAIL-FROM <regexp> is now subject to new syntax checks. Missing regexp is signaled with an error, a whitespace in the regexp triggers a warning. All e-mail addresses in various attributes of the database (upd-to, e-mail, guardian, mnt-nfy, notify) are checked. If they match the AUTOBOX address then the object is rejected to prevent mail loops. MAINTENANCE RELATED CHANGES New log file was introduced which logs values given to whois client on the command line. No timestamp and no query source information is logged. When running in test mode server sends additional RFC822 header line containing the original recipient address a message would be sent to in normal mode of operation. BUG FIXES After a hierarchical authorisation failure an erratical notification was sent to maintainer of the object stating that creation was succesfull while in fact it wasn't. At the same time a proper acknowledge message was sent informing about an authorisation failure. This was corrected and false notification is not sent anymore.
[ lir-wg Archives ]