This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] rpsltool & odd prefixes in the RIPE db
- Previous message (by thread): [db-wg] rpsltool & odd prefixes in the RIPE db
- Next message (by thread): [db-wg] Scheduled Maintenance on RIPE Database Update Server - 10 May, at 14:00 UTC
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Shane Kerr
shane at time-travellers.org
Mon May 7 11:06:32 CEST 2012
Erik, On Friday, 2012-05-04 14:18:01 +0200, Erik Romijn <eromijn at solidlinks.nl> wrote: > > That doesn't seem right - the correct prefix would be 2a02:4c8::/64. > I've asked the RIPE NCC about this, and they explained that > internally, the database silently discards the host bits. So for the > database, this is 2a02:4c8::/64. This is also visible in whois > queries: searching for 2a02:4c8::1/64 yields no results, you have to > search for 2a02:4c8::/64. I agree that the current situation is non-optimal. :) Note that the lookup does tell you what it is doing on query: %WARNING:905: fixed lookup key % % The key "2A02:4C8::1/64" has been changed to "2a02:4c8::/64" for lookup. Regarding the update path, I think we should reject entries with non-zero bits after the CIDR portion of the network address. I'm not sure what to do about the existing entries. I'd recommend a cleanup, actually, since they imply confusion on the maintainer's part. -- Shane
- Previous message (by thread): [db-wg] rpsltool & odd prefixes in the RIPE db
- Next message (by thread): [db-wg] Scheduled Maintenance on RIPE Database Update Server - 10 May, at 14:00 UTC
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]