RIPE Whois Server version 3.2.0
Dear Colleagues, [ Apologies for multiple messages. ] The RIPE NCC is pleased to announce the release of version 3.2.0 of the RIPE Whois server. This software is compliant with both RPSL (RFC-2622) and RPS-Security (RFC-2725). This release adds several user-visible improvements: - dbupdate has been rewritten almost from scratch - the server now limits the number of concurrent connections per IP - transaction support is added on MySQL side - query parsing is revised Detailed release notes can be found at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-3.2.0 You can download this release by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.2.0.tar.gz If you have any questions, please don't hesitate to contact <ripe-dbm@ripe.net>. Best regards, Engin Gunduz RIPE NCC Database Group
Hi Engin, as there have been some IPv6 problems again today (connections over IPv6 were greeted with "permission denied"): what's the current state of IPv6 integration into the RIPE Whois server? Is it still done via Proxy, or is it properly integrated now? regards, Gert Doering On Wed, Aug 06, 2003 at 09:50:09AM +0200, DB-News wrote:
Dear Colleagues,
[ Apologies for multiple messages. ]
The RIPE NCC is pleased to announce the release of version 3.2.0 of the RIPE Whois server. This software is compliant with both RPSL (RFC-2622) and RPS-Security (RFC-2725).
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56318 (55442) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert, Gert Doering wrote:
as there have been some IPv6 problems again today (connections over IPv6 were greeted with "permission denied"): what's the current state of IPv6 integration into the RIPE Whois server? Is it still done via Proxy, or is it properly integrated now?
Thanks for reporting the problem. We noticed it ourselves, and are looking into it. Looks like a mismatch of the configuration of our secondary server during an upgrade caused the problem. We're looking into fixing that now. As for the state of IPv6 integration... We are still using the proxy. We continue to get about 10000 WHOIS queries per day on IPv6, with the majority coming from a small number of addresses (about 0.5% of our queries). I haven't done any further analysis since the last RIPE meeting (RIPE 45): http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-db-whoisdb-up... I'd like to emphasize that the reason we chose to use a proxy is *not* because it was easier or faster to implement, or because we wanted to understand the technology better. I talked a bit about the reasons in the presentation I gave at RIPE 44 when we introduced the proxy: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-ipv6-... The main point is that we currently use client IP address to limit the amount of personal data that a user can query. This does not make sense in the IPv6 universe. While using client IP to identify users is imperfect in an IPv4 world, it is even less meaningful in the IPv6 world. We simply don't know how to protect the privacy of our users in the IPv6 world! The main motivation for the proxy was to study access behaviour and how, if at all, we can effectively protect user's privacy. From the user point of view, the proxy should be identical to a "native" server. When we fix our config, it transparent again! One possibility that may address the client-identification issue is to move to a protocol that supports client authentication. The CRISP protocol, currently in discussion in the IETF, promises to offer such a feature. It is intended to be something that serves the same function as WHOIS, while fixing many of the limitations. http://www.ietf.org/html.charters/crisp-charter.html As I mentioned in the past, I am very eager to hear suggestions on how to deal with the privacy issue in IPv6! Any real-world experience from IPv6 operators or developers would be appreciated. We do have several months of logs now, so we can do some data mining to check theories. -- Shane Kerr RIPE NCC
Hi Shane, | As I mentioned in the past, I am very eager to hear suggestions on how | to deal with the privacy issue in IPv6! Any real-world experience | from IPv6 operators or developers would be appreciated. We do have | several months of logs now, so we can do some data mining to check | theories. There's one idea worth mentioning, allthough I'm quite certain it will not suffice in itself. If you'd like to limit the amount of queries an individual/company can do, you may want to use the database itself for some sort of constraint. Let us say that a user from 2001:7b8:3:32:202:b3ff:fe2a:1e2d wants to look something up. You can check its most specific inet6num which would be NL-BIT1-PN1-POP3 and account queries per timeinterval per inet6num and limit that. If there is no object in the database, you would then fallback to the /35 or /32 and limit the queries per ISP. If any ISP engineer feels like this is punishment for them, you can advise them to make assignments visible in the database (ie, create inet6nums for their customer assignments like they should). You can then limit the amount of queries originating from within inet6num ranges. It may not be easily implemented though, but that's not up to me to decide :-) -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment -----------------------------------------------
Hi, On Fri, Aug 08, 2003 at 03:46:01PM +0200, Pim van Pelt wrote:
Let us say that a user from 2001:7b8:3:32:202:b3ff:fe2a:1e2d wants to look something up. You can check its most specific inet6num which would be NL-BIT1-PN1-POP3 and account queries per timeinterval per inet6num and limit that.
Cool idea. One would need to mirror the other registries for that to work for "foreign" IPv6 addresses, but overall, cool idea :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56318 (55442) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Pim van Pelt wrote:
If you'd like to limit the amount of queries an individual/company can do, you may want to use the database itself for some sort of constraint.
Let us say that a user from 2001:7b8:3:32:202:b3ff:fe2a:1e2d wants to look something up. You can check its most specific inet6num which would be NL-BIT1-PN1-POP3 and account queries per timeinterval per inet6num and limit that.
That seems a bit complicated. Why not just limit per /64 or /48? Aside, how important is this for privacy anyway, given the fact that the whole database is also available via FTP? -- Hroi
Hi, On Wed, Aug 13, 2003 at 11:28:52PM +0200, Hroi Sigurdsson wrote:
Aside, how important is this for privacy anyway, given the fact that the whole database is also available via FTP?
It isn't. The person objects are not available by FTP. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
participants (5)
-
DB-News
-
Gert Doering
-
Hroi Sigurdsson
-
Pim van Pelt
-
Shane Kerr