Registration of IPv6 DHCPv6-PD pools
Hi, the current IPv6 Address Allocation and Assignment Policy (RIPE-481) states: http://www.ripe.net/ripe/docs/ripe-481.html#registration_assignment ======================================================================= 5.5. Registration When an organisation holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate. (Information registered by an RIR/NIR may be replaced by a distributed database for registering address management information in future). Information is registered at the granularity of End Site assignments. [...] ======================================================================= Let's assume a residential eyeball network with $BIGNUM customers provides a dynamic /56 via DHCPv6-PD to each customer by default, from a large pool of /56s. I'm not sure what the implications of above policy is, especially in regards to the last sentence, "Information is registered at the granularity of End Site assignments.". Given that the End Site identity changes dynamically in a relatively high frequency, and considering $BIGNUM in the 6 to 7 figure range, it certainly won't be sensible pumping a $BIGNUM count of /56 inet6nums into the RIPE DB, all with "descr: dynamic end site network". Unfortunately it seems that this is actually required ny the policy though, wether in the RIPE DB or a DB operated by the LIR in question, accessible to the NCC. Providing dynamic networks to end sites instead of only single addresses is something new to the community. I'm looking for clarification on how we're going to handle those kind of deployments in regard of assignment registration. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Hi Daniel, On 09/10/2009 11:30, "Daniel Roesen" <dr@cluenet.de> wrote:
it must register assignment information in a database, accessible by RIRs as appropriate.
[...]
I'm not sure what the implications of above policy is, especially in regards to the last sentence, "Information is registered at the granularity of End Site assignments.". Given that the End Site identity changes dynamically in a relatively high frequency, and considering $BIGNUM in the 6 to 7 figure range, it certainly won't be sensible pumping a $BIGNUM count of /56 inet6nums into the RIPE DB, all with "descr: dynamic end site network". Unfortunately it seems that this is actually required ny the policy though, wether in the RIPE DB or a DB operated by the LIR in question, accessible to the NCC.
My interpretation the text of the policy different from yours. It does not say that assignments must be registered in the RIPE database, just that the database has to be accessible by RIRs. This is presumably to allow the RIPE NCC to assess you for your next allocation when your allocation is 'full'. I also think that if there is a highly dynamic movement of prefixes between subscribers in the pool then it would make most sense to register the pool rather than the end user, just like you do for IPv4. I suspect that most ISPs treat pool of dynamic IPv4 addresses as the site and the subscribers as users connected to that site. Does this need to change for IPv6? This is just my interpretation, though. Regards, Leo Vegoda
On Fri, Oct 09, 2009 at 12:00:52PM -0700, Leo Vegoda wrote:
My interpretation the text of the policy different from yours. It does not say that assignments must be registered in the RIPE database, just that the database has to be accessible by RIRs.
That's my interpretation as well, see "the "or a DB operated by the LIR":
Unfortunately it seems that this is actually required ny the policy though, wether in the RIPE DB or a DB operated by the LIR in question, accessible to the NCC.
I guess this is a reference to a local RIPE-like DB as employed by several LIRs. No matter in which database, it makes (in my view) absolutely no sense to have each /56 in there as individual entries.
I also think that if there is a highly dynamic movement of prefixes between subscribers in the pool then it would make most sense to register the pool rather than the end user, just like you do for IPv4.
Agreed, but the policy doesn't really (in my interpretation, I'm seeking for clarification on that) allow this option as it clearly says that the granularity of registration is supposed to be at End Site level - that's quite normative.
I suspect that most ISPs treat pool of dynamic IPv4 addresses as the site and the subscribers as users connected to that site. Does this need to change for IPv6?
Using this analogy ("pool of /56s" = "end site") would mean that the pool can be only 256 /56s big (=/48) without approval by NCC, see policy "5.4.2. Assignment of multiple /48s to a single End Site". In fact, this would mean we would need to get approval for all our end user IP pools. On the other side, a business ISP wouldn't ever need to approach NCC for assigning their allocation full of /48s for end users, as long as any single site does not exceed /48. This makes no sense to me. Even simple IPv4 DHCP pools for single WAN IPs aren't clearly regulated by policy. Ask hostmaster A and he/she will say "that's your infrastructure, as you need those IPs to connect your customer to you, just use INFRA-AW, no approvals required". Ask the next hostmaster and he/she will tell you differently, that this is abuse of INFRA-AW and needs approval. Ideally we're going to find a consensus interpretation on how to deal with dynamic pools (of any size), be it for single IPs or prefix delegations via DHCP-PD. I would see some merit in codifying this in the addressing policy so it becomes much less ambiguous. For IPv4 this is probably not really necessary anymore, we won't have to deal with this ambiguities and indifferent interpretations by NCC for much longer. But "prefix pools" is something we as a community have no experience how to deal with regarding policy and policy application. It's something "new" we will see with IPv6 deployment. I see value in giving NCC guidance on how to deal with that. Looking forward to further input. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Ideally we're going to find a consensus interpretation on how to deal with dynamic pools (of any size), be it for single IPs or prefix delegations via DHCP-PD.
I think it depends very much on how big an assignment you would want to make out of these, in my personal opinion, I think that anything larger than /64 (which is the minimum you need to get anything done) should be documented. Why do I think this? In the IPv4 world, we take a /24 pool and divide it up into /32s which we need to connect the customer to us ("infrastructure") and no per-customer documentation is needed. The minute an IPv4 customer asks for some addresses to be routed to them, enough to create another "network", we give them at minimum a /29 and document this. In the IPv6 world, I think I would be following the same approach, only on a bigger scale. The minute a customer wants more than just to have their home IPv6 devices work in a basic fashion (i.e they want another /64 or a /56) then I would expect there to be some documentation for it, I'm not trying to be restrictive about what they do with their home networks, just trying to draw a line in the sand somewhere, below which I don't care about usage and above which I do. Now, as for the question of what this documentation should be or where it lives, I can't see much use in populating the RIR DB with all of this small assignment stuff, perhaps best draw another line and make this the RIR reporting threshold. Dave.
participants (3)
-
Daniel Roesen -
David Freedman -
Leo Vegoda