Re: IPv6 addresses for Exchange Points
Subj: Re: IPv6 addresses for Exchange Points
I think there are still quite a few aspects which require forming a consensus, finding a definition or a solution. First of all, talking directly to the set of IXs effectively bypasses the LIR to NCC channel. so, tjis should be defined in the proposal. I can imageing that the IX should either become an Enterprise Registry or work with one of the existing LIRs. =Date: Mon, 7 May 2001 17:51:56 +0200 =From: Gert Doering <gert@space.net> =To: Mirjam Kuehne <mir@ripe.net> =CC: lir-wg@ripe.net =Subject: Re: IPv6 addresses for Exchange Points = =Hi, = =On Mon, May 07, 2001 at 05:35:11PM +0200, Mirjam Kuehne wrote: => An Internet Exchange Point was defined as follows: => => 3 or more ASes and 3 or more separate entities attached to a LAN (the => same infrastructure) for the purpose of peering and more are welcome => to join. = =I suggest to change the wording to "a common layer 2 infrastructure" =- an exchange point might be some distributed thing peering over an =ATM/FR cloud or a SRP/DTP ring, which isn't really a "LAN". Policy =should not be tied to special implementation techniques. From a technical point of view, I fully support your suggestion. From an administrative point of view, I'd re-iterate that nobody is going to be able to define an IX, much like we agreed eventually that we would never succeed in defining an ISP. =Besides this, I like the proposal. = =As discussed with a few people after the WG, it *does* pose the risk of =handing out "lots and lots" of /48s and /64s to people claiming to be =an exchange point. (It's not that hard to get three ASes together =over "some" medium). Talking to folks at one IX (close by :-) and listening to suggestions as to why this approach is useful, I am having problems with the assumption that any such IX would remain confined to a *single* subnet. Also, in keeping with the IAB/IESG recommendation I would propose to simply ask the applicant whether they really intend to run *one* layer-2 subnet (and then assign a /64). (Examples: multicast test-beds, VLANs, host not allowed on DMZs,...) Otherwise assign a /48 - without asking questions about "relations" between IXs.
On the other hand: if we reserve a /35 for that, we have 2^13 /48's to hand out to "would-be IXes". So the danger of address wastage is not too big.
The danger of routing deaggregation *is*...
What is going to happen here is the creation of a TWD/PI environment. And I do not claim that this is bad i itself, btw. Just face the fact up front.
So I'd suggest another thing: add to this a big warning that this space is not "PI" (whatever that means) and that it is very likely that it will never be routeable world-wide. This should stop people wanting to use such space for something different than an exchange point from applying for it.
Why do we expect the v6-world to be different from the v4-world, in the sense that it is the ISPs and the folks dealing with the routing layer who decide about acceptiong routes, and *not* the address registries?
Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Wilfried. PS: btw, who is going to do revDNS for those prefixes? _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hi Wilfried, a few comments: On Wed, May 09, 2001 at 02:23:30PM +0200, Wilfried Woeber, UniVie/ACOnet wrote: [..]
=On Mon, May 07, 2001 at 05:35:11PM +0200, Mirjam Kuehne wrote: => An Internet Exchange Point was defined as follows: => => 3 or more ASes and 3 or more separate entities attached to a LAN (the => same infrastructure) for the purpose of peering and more are welcome => to join. = =I suggest to change the wording to "a common layer 2 infrastructure" =- an exchange point might be some distributed thing peering over an =ATM/FR cloud or a SRP/DTP ring, which isn't really a "LAN". Policy =should not be tied to special implementation techniques.
From a technical point of view, I fully support your suggestion.
From an administrative point of view, I'd re-iterate that nobody is going to be able to define an IX, much like we agreed eventually that we would never succeed in defining an ISP.
Yes, we'll never be able to define with 100% perfection "this is an IX and that is not". With Randys definition, we have something that should suffice to include all forms of IXes, and maybe some other things that are not IXes in the strict sense. This is why I added the remark about "ok, we will waste addresses on 'them' - but there's so much address space, so what". *I* don't think we have a problem here, but yes, we need community consensus here. [..]
Talking to folks at one IX (close by :-) and listening to suggestions as to why this approach is useful, I am having problems with the assumption that any such IX would remain confined to a *single* subnet.
This was not part of the proposal :-) - it was "if they have only one subnet, give 'em a /64, of not, give 'em a /48". There is a point about interconnection between those subnets - yes, that should not be necessary (if they are at L2 interconnected, one /64 will suffice, if at L3 or not at all, handing out multiple /64s is just not worth the effort - IMHO). [..]
What is going to happen here is the creation of a TWD/PI environment. And I do not claim that this is bad i itself, btw. Just face the fact up front.
Yes. This is why...
So I'd suggest another thing: add to this a big warning that this space is not "PI" (whatever that means) and that it is very likely that it will never be routeable world-wide. This should stop people wanting to use such space for something different than an exchange point from applying for it.
Why do we expect the v6-world to be different from the v4-world, in the sense that it is the ISPs and the folks dealing with the routing layer who decide about acceptiong routes, and *not* the address registries?
There is no difference, but we can avoid making one mistake, that has been mentioned in the "PI" discussion: if a RIR hands out a chunk of addresses, it is kind of "sanctioned" (because what good would that subnet be if not routeable?). Nobody has ever said "because this is official PI, it will work", but people expect it to work nonetheless. So this is why I think the warning label would do good: it might make sure that this is *really* only meant as "multi-site-local" address space and not to be routed on the whole net (which might work, or might not, but it's not meant for that).
PS: btw, who is going to do revDNS for those prefixes?
The IX themself - RIPE could delegate RR-DNS at /48 or /64 boundaries. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
participants (2)
-
Gert Doering, Netmaster -
Wilfried Woeber, UniVie/ACOnet