[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[6bone] Exchange Point Addresses
On Mon, Jun 17, 2002 at 08:18:41PM +0200, Pim van Pelt wrote:
> They give out a (non-aggregatable) /48, which is IMO almost 100%
> pointless (not a /64 like you mentioned).
My source for this was
"Since the address space does not need to be routable globally and an
IXP is expected to only have one subnet, a /64 (64 bits of address
space) will be assigned in most cases."
Perhaps this does not reflect their actual policy. In any case
if the addresses are not globally routeable, we might as well
use site-local ones.
It would befar better to use globally routeable addresses for
exactly the reasons you point out -- i.e. path MTU discovery.
Perhaps it is not impossible that a certain number of small
exchange point blocks be allowed to leak unaggregated into the
global routing table -- I suspect that the number of such blocks
would be bounded above by 10000 or so (say about 300 countries
in the world with on average 10 major cities, each with an
internet exchange or two). It's clearly feasable technically,
but less than elegant.
> As with your collegues at AMS-IX (NL), you will simply be left out in
> the cold. When you approach a registry with a remark like you just
> made, you will be told that you are no more special than any other
> company that wishes to have their own globally routable space (call it
> PI, call it TLA).
Which is unfortunate, since we don't really fit into their categories.
In reality, TORIX is a couple of ethernet switches that live in
shared physical space graciously donated by the managers of the
local telco hotel. It is not a company, it is a shared community
resource. And it has run into problems in the past being tied for
one reason or another to a particular member of the exchage.
So, what to do? ;)
The way that ARIN seems to have tentatively addressed the issue
is by trying to turn regional exchanges (a label which could
reasonably be applied to TORIX since most of the ISPs in
Ontario peer there) into sub-TLA registries for the region
188.8.131.52) which, I believe, is more responsibility than we would
be willing to take on.
They also have a RIPE-like policy proposal which doesn't appear
to have been looked at in about a year and a half: