Re: IPv6 addresses for Exchange Points

Hi Gert! =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 :-) Correct :-) =- 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 I was referring to was the paragraph in Mirjam's summary to the EIX list: "There was consensus to assign a /64 to an isolated Exchange Point. It was further suggested to assign the agreed standard assignment size to a site (currently a /48) to a group of inter-connected Exchange Points." =[..] => 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 'course - but then their (IPv6) prefix must be routed, or they have to obtain/use addresses from (one of) their members (which sounds like the thing they want to avoid in the first place?) or buy connectivity or service form somewhere. Can be done, of course! - RIPE could delegate RR-DNS at /48 or /64 boundaries. Yes, they probably could. But do they want to? And potentially doing it for free? =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.

Hiya all, I disagree with this: "There was consensus to assign a /64 to an isolated Exchange Point. It was further suggested to assign the agreed standard assignment size to a site (currently a /48) to a group of inter-connected Exchange Points." This makes no sense to me. They are only going to come back and say they need another network (test equipment, multicast, etc...), and then we have to start carrying two/three/four... prefixes. Even after 80 bits of the 128 bit address range have been wasted, I repeat that IPv6 addresses are NOT IN SHORT SUPPLY and that Agregation and Prefix conservation (with registration and documentation) should be our sole concern except in completely crazy cases. Or does someone think there may really be around 1,000,000,000,000,000 entities pretending to be internet exchanges ? ---- Seperate response: David R Huberman wrote: ->Exchange points need the ability to petition RIRs directly for address ->space not for routability, but to ensure uniqueness. I think exchange point infrastructure - web servers,monitoring,test traffic boxes, etc. need to be multihomed as well as globally unique. Cheers Dave Pratt

=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?).
=> PS: btw, who is going to do revDNS for those prefixes? = =The IX themself
'course - but then their (IPv6) prefix must be routed, or they have to obtain/use addresses from (one of) their members (which sounds like the thing they want to avoid in the first place?) or buy connectivity or service form somewhere. Can be done, of course!
Please correct me if I'm wrong, but since when do exchange points route their address space across the public internet? Exchange Points petitioning ARIN under the micro-allocation policy are required to agree *not* to route their IP address space across the public internet. Exchange points need the ability to petition RIRs directly for address space not for routability, but to ensure uniqueness. /david

Hi, On Thu, May 10, 2001 at 03:02:45PM +0200, Wilfried Woeber, UniVie/ACOnet wrote:
=> PS: btw, who is going to do revDNS for those prefixes? = =The IX themself
'course - but then their (IPv6) prefix must be routed, or they have to obtain/use addresses from (one of) their members (which sounds like the thing they want to avoid in the first place?) or buy connectivity or service form somewhere. Can be done, of course!
Indeed, good point. But they need connectivity for things like member mailing lists, www servers etc. anyway - which does not mean that those services have to (or even "should") be located at the IX itself, in the same IP prefix. 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

But they need connectivity for things like member mailing lists, www servers etc. anyway - which does not mean that those services have to (or even "should") be located at the IX itself, in the same IP prefix.
I should have read this before I responded to Dave Pratt's email - Gert said it far better than I did! For the purposes of this policy discussion, we must differentiate between address space utilized explicitly for the interconnection of exchange participants and space utilized for other purposes. /david

For the purposes of this policy discussion, we must differentiate between address space utilized explicitly for the interconnection of exchange participants and space utilized for other purposes.
we will gladly give them address space when they buy transit. randy
participants (5)
-
Dave Pratt
-
David R Huberman
-
Gert Doering, Netmaster
-
Randy Bush
-
Wilfried Woeber, UniVie/ACOnet