This is not true. Under the current allocation procedures it is not possible for properly neutral IXPs, even if they are a local-ir, to get an IPv6 allocation, so we have no alternative to these types of addresses. The fact we've been trying to get such an allocation and have been waiting six months (and LINX even longer) for same is the reason for this whole discussion thread in the first place.
This means the policy for IPv6 allocation is efectively more stringent than for IPv4.
Agreed.
I am at a loss to understand why this is the case - surely the point of allocation guidelines is to (a) protect utilisation of remaining address space, and (b) minimise the number of entries in router tables.
For (a), we have a whole lot more address space available in v6 than v4,
The current allocation scheme hands out /35 prefixes (RIPE-196) ... |-3|--13-|--13-|-6-|--13-|--16--|------64 bits-----| +--+-----+-----+---+-----+------+------------------+ |FP|-TLA-|-sub-|Res|-NLA-|--SLA-|---Interface ID---| |--|-ID--|-TLA-|---|--ID-|--ID--|------------------| +--+-----+-----+---+-----+------+------------------+ There are 2^29 (~500 million) of these /35s available which is 2^13 (~8000) times larger than existing AS number space. We don't have to worry about running out of /35s but do need to worry about them filling up the routing tables.
and for (b), the total number of IXPs is at least two orders of magnitude less than for ISPs, i.e. marginal.
A 1% increase in number of /35 prefixes (routes) is not a problem. Treating IXPs specially and giving them /35s would be most convenient for IXPs.
So why do we need more restrictive policies ?
To stop all the multihomed customers getting /35s and filling the routing tables. AIUI supporting multiple IPv6 prefixes on hosts has not been completely solved and I suspect that it will always be easier and more prestigious for multihomed customers to have a /35 rather than a handful of /48s. If we treat IXPs as a special case we have to be careful not to let multihomed customers qualify. Defining "IXP" in such as way as to include what we commonly understand by the term and not include multihomed customers is hard to do :-( Chris.