[6bone] Exchange Point Addresses

Pim van Pelt pim@ipng.nl
Mon, 17 Jun 2002 21:31:05 +0200


On Mon, Jun 17, 2002 at 08:20:56PM +0000, Robert Kiessling wrote:
| Pim van Pelt <pim@ipng.nl> writes:
| 
| > On Mon, Jun 17, 2002 at 12:45:59PM -0400, ww@GROOVY.NET wrote:
| > | At the Toronto Internet Exchange (TORIX) we've been talking about
| > | making it possible to peer natively over IPv6. The problem is
| > | getting addresses for the exchange -- RIPE seems to have a clear
| > | policy (they'll hand out a /64), but ARIN doesn't appear to. It
| > | would not be appropriate to use addresses from one of the providers
| > | at the exchange since TORIX has been, since its inception, 
| > | provider neutral and we'd like to keep it that way.
| > They give out a (non-aggregatable) /48, which is IMO almost 100%
| > pointless (not a /64 like you mentioned).
| 
| It fulfils exactly what it's made for: to provide neutral,
| provider-independent IPv6 addresses for the exchange mesh. There was
| and is a need for this, so it's far from "100% useless".
Hi Robert,
 
Sitelocal will do fine for these things. If you can't route it, I don't
see the point in having it allocated from the 2000::/3 aggregate. I
would find fec0::/10 addresses in the peering mesh useful. 

We have seen (in practice) that not having globally routable peering
meshes, potentially breaks Path MTU discovery. This can happen when all
the hops to the endpoint are larger than the one used on the shared
medium, making the last box before the shared medium hop generate a
message to the originating host that the MTU should be set to its value.

Some router implementations drop any packets from sources which they do 
not have a route to in their FIB.

| > | Any suggestions or pointers to how to go about acquiring some
| > | numbers for the exchange would be appreciated.
| > 
| > As with your collegues at AMS-IX (NL), you will simply be left out in 
| > the cold.
| 
| No, you're not. You can receive address space for the exchange
| mesh. There is no need for these addresses to be routable.
See above.

 
| Addresses for other services like web page, NTP etc. is a different
| story altogether.
It's the story I was actually referring to in my original comment.
 
| > 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).
| 
| Indeed.
| 
| You are implying that the secondary services offered by exchange
| points are so important that they justify a different allocation
| policy. This in turn implies that you want to introduce PI to IPv6,
| which so far does not exist (TLA, sTLA are *not* PI, they clearly are
| PA).
Please don't put words in my mouth. I am not implying that I would like
to have PI space in IPv6, on the contrary.
 
| There is a clear consencus that this is not desirable.
I consent to not having PI, I do not consent to having the 2001:7f8::/32
superblock with /48 allocations for peering meshes.
 
| > At current, at least in the region I am active in (RIPE), IXPs cannot
| > obtain address space without becoming dependant on a member. By the
| > way, neither can the RIR itself.
| 
| They can obtain address space like everone else. They just cannot get
| "PI" space, that is globally routable addresses not bound to an
| upstream. Of course they are free to fulil the requirements for an
| allocation, which is essentially to become a LIR and expect 200
| customer assignments.
This would be lying to the RIR, and that type of behavior is being
actively promoted these days, for example at RIPE42, where RIPE joined
the other two RIRs with the new allocation policies.

For an IXP, which will not offer downstream customers connectivity via
their AS, it would not be feasable to request an IPv6 allocation from
the RIR in saying that they would have a business case for 200 customer
allocations (which would be their members).

Most independant IXPs I know of (although I admit that I do not know of
many :-), are member associations, which will not be able to make a case
at their RIR to meet the 200 potential end-sites criterium. So either
they lie, or they break their independence by becoming a customer with
one (or several) of their members.

As much as I do not think that an IXP is a more special pig than other
pigs, I also do not think that they should be bending the rules and
forcing themselves into awkward positions to obtain address space.

Oh, did I mention that the RIRs themselves face exactly the same problem ? 

groet,
Pim

-- 
---------- - -    - - -+- - -    - - ----------
Pim van Pelt                 Email: pim@ipng.nl
http://www.ipng.nl/             IPv6 Deployment
-----------------------------------------------