Robert Kiessling wrote:
Michal Krsek writes:
Some IXPs are not only infrastructure for interconnection and they sometimes offer some public services. I cannot determine all of them, but in example: NTP, traffic statistics, root DNS servers and some other (hope people from LINX or NETNOD should find some others).
I think this was addressed in the discussion,
Apologies, but I am afraid I missed this (local-ir ?) discussion. Could someone please recap the arguments here, because I do not understand why this is necessary. Our requirements for reachability and neutrality of our "value-added" services are just as strong as for the IXP mesh itself.
If an IXP insists on putting those services on the same net, they can of course do so if they get routable IPv6 space for it, through standard procedures. Use of those addresses for IXPs is in no way forced.
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. 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, and for (b), the total number of IXPs is at least two orders of magnitude less than for ISPs, i.e. marginal. So why do we need more restrictive policies ?
with the solution to get normal IPv6 space from the usual sources for thoses services. For example the K root nameserver does not sit on the LINX exchange network itself, but in a very different netblock, and this model could be applied to IPv6, too.
Indeed, if the argument as above is that the mesh parts of IXPs need to have seperate alllocations (and if this is the policy, then don't stop me getting *both* in my own right), this increases (b) the number of routing table entries. Our ideal requirement is to have a single (say /48) allocation in which we would operate a number of (say /64) IXPs, only one prefix total. Keith http://www.xchangepoint.net/contact/keith/