Gert Doering wrote:

Hi,

On Wed, May 29, 2002 at 09:29:33AM +0000, James Aldridge wrote:

...

For IPv6, on the other hand, a supernational registry can only get a single allocation, irrespective of its size and contributions to the NCC. I don't recall this policy change being discussed in the RIPE policy making forum (the LIR WG) being being put in place by the NCC for the then interim IPv6 policy.

I am aware that there are few supernational registries and that they are a pain for the RIPE NCC but this policyy change seems to work against the aggregation principles we need to follow if we're not going to have the routing table growth rate we've seen with IPv4.

I don't understand why "not giving out multiple IPv6 blocks" is "against the aggregation principles".

Could you elaborate on this?

The old IPv6 policy gave a single /35 to a supernational registry. This meant that each "sub-LIR" would have to put up with, say, a /40 (enough for a mere 256 /48 assignments) and once this was used it would be unlikely that the next /40 available from the LIR's allocation would form an aggregatable block with the earlier "sub-allocation". With different "sub-LIRs" having different (national) routing policies, these multiple non-aggregatable blocks would have to be announced to peers. This doesn't sound like following aggregation principles to me ;-) However, that was the old IPv6 policy...

Being a bit more relaxed in judging whether a multinational LIR really needs a "/22" (to be a bit extreme) would mimic the "IPv4 approach" (give out more space than usual) fairly well.

... yes, I'm sure this would help. The supernational LIR adds a few extra levels of hierarchy here: - RIR - Supernational LIR - "sub-LIR" - sub-LIR's ISP customers (who are either not LIRs or LIRs who don't meet current IPv6 criteria) - end-user assignments If a hierarchy such as this could be used to justify a larger-than-/32 allocation then I don't think that big supernational registries would have any particular problems. James