[ipv6-wg] Publication of default assignment sizes for end-user network ?

>>>        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


Hi Marco

Sorry for the late response. I missed the original posting on this list,
then saw your follow up on the IETF list.

The RIPE NCC also has the same problem with the RIPE DB. Currently we
implement some rate limiting on individual IP addresses. As you have
explained here, this does not scale for IPv6.

The Database Group at the RIPE NCC has already done a lot of thinking
internally on this and other issues on moving the RIPE Database into an
IPv6 world. We would welcome ideas and thoughts from the community about
use cases, issues and problems you can foresee with the RIPE DB in an
IPv6 world, even if people don't have the solutions. Of course suggested
solutions are also welcome.

Let me throw some pointers at you from our thinking. Firstly don't let
your thoughts be constrained by the current RIPE DB. This was designed
in an IPv4 world with IPv6 bolted on later. Think out of the box. Don't
worry too much about the data model, interfaces, APIs, tools we have
now. Focus on what the RIPE DB needs to do for you in an IPv6 world.

For example you discuss the problem of not knowing what the block size
is that any IPv6 address belongs to. This is because the current
thinking is to not store all assignments in the RIPE DB. Suppose we
re-assess what data needs to be stored, who needs access to it and for
what purpose. Suppose we design a new data model and provide new APIs
and new tools built on those APIs. Then one possibility may be
for each LIR to upload a daily dump of assignment changes and leave it
up to the RIPE NCC to process the data. We can do batch processing over
night and sync the RIPE DB with LIR's databases.

This will not have the serious impact you referred to on your day to day
operations. We don't need to store the same information we do now for an
IP address. We can store different information about addresses used for
different purposes. Maybe not all the stored information needs to be
accessible by all people who query the RIPE DB. So we can build in data
protection safeguards. With new query interfaces, we can provide access
to this data more easily and in many different formats.

So perhaps you can widen your thinking now about possible solutions to
new problems in an IPv6 world.

Regards
Denis Walker
Business Analyst
RIPE NCC Database Group