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/ipv6-wg@ripe.net/
[ipv6-wg] Publication of default assignment sizes for end-user network ?
- Previous message (by thread): [ipv6-wg] Publication of default assignment sizes for end-user network ?
- Next message (by thread): [ipv6-wg] Happy Birthday Internet !! The first Internet connection
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Marco Hogewoning
marcoh at marcoh.net
Wed Oct 28 14:44:43 CET 2009
>> Now this does not forbid you to register individual >> assignments into the public database, but doing so poses >> various problems. Not only the sheer number of assignments >> can be a problem, but also keeping that registration >> up-to-date will have serious impact on your day to day >> operations and especially with residential users there might >> be privacy issues as well. > > If we would have a distributed database protocol to extend the > RIPE database into the LIRs, then this would not be an issue. > I'm thinking of something like DNS. > > For instance, if I need to look up data on three > /48s in fdb8:e914::/32 I would first send a lookup request to > RIPE. The RIPE db would tell me that all data for > fdb8:e914::/32 is in a server at fdb8:e914::dbdb. I would > cache that information, and send my first lookup request to > the distributed server. After getting my reply, I would prepare > to send the second request for fdb8:e914:c20f::/48, notice that > the /32 is already in my cache, and use the cached server > instead. > > This is roughly the way DNS lookups work with the result that > the detailed data does not have to be kept in one central > location. I would like to see the RIPE db move in the same > direction. > > At the same time, I would like to see the spec opened up a bit > so that the distributed server operators would be free to add > additional attributes to existing objects, and additional objects > so that there is the possibility of using the same distributed > lookup mechanism for geographic or language identifications as > well. This may as well be another solution, but it still needs some way of signalling where the actual boundary between customers is as I see no way to delegate it down to the customer level unless there is some way to incoorperate it into the CPE. And that's I think my main argument opposing to this path, it takes a lot of time to and develop that model ad get it implemented across all the LIR's. The big benefit of solving it at the RIR level is that it's only a handfull of systems that need to be changed and the basic way to retrieve that information is already there in the form of the whois protocol. I'm not syaing I don't like your solution, I'm just afraid that deployment will be just to late. Grtx, Marco
- Previous message (by thread): [ipv6-wg] Publication of default assignment sizes for end-user network ?
- Next message (by thread): [ipv6-wg] Happy Birthday Internet !! The first Internet connection
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]