I have tried to follow this discussion, and stumbeled over a fundamental question when trying to reason about this: * why are exchange points so special ? It seems to me that shared medium exchange points historicaly have used a single subnet to interconnect. Generaly it simplifies configuration and eases operations to have a single logical interface on the physical interface connected to the shared medium. But in order to excange traffic with other partners at the exchange one needs to establish "pont to point" BGP peerings. So there is no longer any significant configuirational advantage in having all the boxes I want to talk to on a single subnet (I still need to figure out how to talk to the others by establishing BGP peerings.) On the operational side, at least back when I was directly involved in such, it would actualy be very convenient to have logical point to point links with all my peering partners in order to better diagnose and measure traffic flows and flaws. If this is the case, the IP addresses for the logical point to point links across the exchange would best be implementedwith IP addresses from any of the providers, or perhaps even the IPv6 equivalent of link local addresses. I would be interested to hear comments on this approach, because if this model makes senseto implement, it would probably make sense to document this as some kind of "best current practice" for IP v6 exchanges in order to make sure that the router vendors implements the proper tools to make this easy to configure. Looking forward to hear others opinions on this. -hph

Havard Eidnes writes:

o Addresses for the exchange point medium itself (usually a layer-two network of some sort)

I agree, this was the discussion i added to.

For the exchange point medium itself, if the medium is a "multiple- access broadcast network" it *is* actually a benefit to use the "natural" way to number such networks, i.e. use a single IP subnet, as in that case you can use BGP in the "standard configuration".

I agree that this has been the simple way of doing things in routers as we know them today.

Starting to muddle with secondary IP addresses and run "multiple subnet on the same layer-two medium" when you in reality don't have to, just causes extra complications, and should therefore be avoided.

I would again agree with you if I were discussing how to do this in current implementations. But my thinking was more on the lines: how would the ideal solution look if I didn't have the constraints of the current implementations. And since we are rather early in implementation of v6 based technology it may still be time to engineer more convenient solutions. Such an implementation should also give me SNMP access to relevant counters on such an interface. But again, I realise, this it not how the current implementations are, and mabe such suggestions should better be discussed in some IETF wg, or directy with vendors.

If your exchange point is implemented using a "multiple- access non-broadcast network" of some sort, the multiple point-to- point links, each with their own subnet out of a connected peer's address block makes sense.

Yes indeed.

Some have said that the IP network used to number the exchange itself does not have to be announced on the global level. However, it would appear that practices vary quite widely on this point for IPv4, and many are announced globally. You mention the possible use of link-local addresses; I wonder if that won't make it difficult to handle such things as ICMP; it'll probably be met with similar issues as folks who use RFC 1918 addresses in today's network (e.g. breaking Path MTU discovery because RFC 1918-originated datagrams are often summarily dropped on the floor).

I have just been reminded that at least some routers can be configured how to reply to ICMP requests, so this may solve that address. Link local addresses may actualy not be a good idea since I probably would have to carry my peers IP address in my internal routing tables and with multiple peerings I need to ensure uniqueness at least within my network. Maybe the soulution would be that all routers had a loopback like interface with a suitably sized subnet set aside, and that you could trough a DHCP like auto configure this end and discover the remote AS number. The only other thing needed to be added would be the routing policy...

I may have misunderstood something fundamental, but I also don't quite know what's so bad with using IP(v4) addresses out of a provider's block to number the exchange point medium.

Technicaly I don't think there are any disadvantages in doing this. Politicaly or emotionaly I think there are several reasons: * if the provider who donated the IP addresses in the first case deceides to disconnect from the exchange, one may want to renumber the exchange * I have repeatedly heard (at RIPE and ARIN meetings) that it is bad practice to advertise more specific routes out of a provider block. (this tends to come up more in multihoming discussions than in IX discussions tough) It seems to me that there is a notion that if somebody else announces a more specific route as an alternative path to parts of your address space it hurts in some way ("I dont allow others to punch holes in my blocks"). My personal opinion is the quite the oposite, it is better (as in more socialy acceptable to the global internet) to do multi homing with address space from one of the providers, as this allows other to save router resources with prefix length filters without risking loosing connectivity to the multi-homed networks.

As for the "service network", it will of course need global connectivity, and thus has to get transit service from one or more ISPs. What I don't understand is why this service network needs to be so special up and above other normal customers when it comes to IP address assignment?

Well, if it is "critical internet infrastructure" it requires maximum connectivity. Some tend to argue that that is best taken care of trough a separate entry in the routing table.

Creating these "special cases" as exceptions to the rules just opens up the floor for other folks who will stand up and say "My Cause is Extremely Worthy too, so I want some too under those conditions!!".

I could not agree more. -hph

Dear Marc, thank you for pointing out to this problem, and please receive apologies for the delays that happened recently. Here is what is causing them: RIPE Working Groups mailing lists are moderated lists, so that only subscribers can post to them (to prevent "spam"). Still, lists are open for subscription to everyone. Bounced messages go to the human moderator, and are being looked into and manually approved, at least twice a day, during working days. If the message is sent after working hours, or on the weekend, its approval will be delayed, and that will indeed confuse the archiving. To improve the situation, it would be helpful if mailing list members would post from the same address that they are subscribed from. However, due to the parallel discussions that happen on several mailing lists, or relevant postings done only once from non-subscribers, or messages that get bounced because they have a word "subscribe" in the body, it is inevitable that this kind of behaviour of the mailing list archiving will sometimes occur. We are looking at this problem at RIPE NCC, and will improve our archiving software. We apologise again for any inconvenience. Vesna Manojlovic RIPE NCC staff Marc Roger <marc@belnet.be> writes: * Dear NCC, * * I have just received the following messages addressed to the lir-wg * mailing-list, that were apparently sent more than four days ago: * * Andre Opperman Fri, 11 May 2001 20:52:19 +0200 <3AFC34E3.5A816 * A2C@telehouse.ch> * Havard Eidnes <he@runit.no> Fri, 11 May 2001 19:04:45 +0200 <20010511190445 * J.he@runit.no> * * In both messages I see that it was processed by qmail at the RIPE mail * server today at 09:44 and that they do not appear in the lir-wg archives * at their original posting date, which indicates that the problem is not * local: see * http://www.ripe.net/ripe/mail-archives/lir-wg/current/mail3.html * * This is not the first occurence of this phenomenon, eg on May 9th at 11:31 * I have received the following announcement: * * Return-Path: <owner-sst@belnet.be> * Received: from vivaldi.belnet.be (vivaldi.belnet.be [193.190.198.2]) * by dagesh.fw.belnet.be (8.10.2/8.10.2) with ESMTP id f499VvM23656 * for <sst@office.belnet.be>; Wed, 9 May 2001 11:31:57 +0200 (MEST) * Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) * by vivaldi.belnet.be (8.10.2/8.10.2) with SMTP id f499Vuw11762 * for <ir@belnet.be>; Wed, 9 May 2001 11:31:56 +0200 (MEST) * Received: (qmail 1707 invoked by alias); 9 May 2001 09:23:44 -0000 * Delivered-To: lists-local-ir-reg@lists.ripe.net * Received: (qmail 1558 invoked by alias); 9 May 2001 09:23:36 -0000 * Delivered-To: lists-local-ir-out@lists.ripe.net * Received: (qmail 1475 invoked by uid 66); 9 May 2001 09:23:31 -0000 * Message-Id: <200105041452.QAA11314@office.ripe.net> * To: ripe-list@ripe.net * Cc: local-ir@ripe.net, lir-wg@ripe.net * From: RIPE NCC Document Announcement Service <ncc@ripe.net> * Subject: New Document available: RIPE-220 * X-Phone: +31 20 535 4444 * X-Fax: +31 20 535 4445 * Date: Fri, 04 May 2001 16:52:47 +0200 * Sender: owner-local-ir@ripe.net * Precedence: bulk * * (which is also archived under "09 May 2001" on the ML archives) * * It is not possible to follow a discussion if messages are randomly delayed * by several days like this. Can I kindly ask the RIPE NCC to fix this * problem ? * * -- * Marc.Roger@belnet.be, BELNET, the National Research Network * * * * * *

On Wed, May 16, 2001 at 08:19:09PM -0400, Randy Bush wrote:

bgp is not needed at all, as the exchange point has no asn, and the prefix is internal to the attached providers.

Several European IXPs run their own BGP, and have their own ASN, with one or more of their members providing transit to the IXP's PA space. -- Paul Martin <pm@zetnet.net>

On Thu, May 17, 2001 at 07:49:47AM -0700, Randy Bush wrote:

...

...

bgp is not needed at all, as the exchange point has no asn, and the prefix is internal to the attached providers. Several European IXPs run their own BGP, and have their own ASN, with one or more of their members providing transit to the IXP's PA space.

this is true for most exchanges. but the exchange mesh itself, which is the subject of our discussion, is not in that asn. it is the side service net which is in the transit asn.

I know of at least one IXP which uses a portion of its PA space for the exchange itself (on a multiple-access broadcast network, ie. switched ethernet) -- it was advised to do so by RIPE. Strangely enough, it is some of the side services that are on non-global-transit address space. -- Paul Martin <pm@zetnet.net>

Hans Petter, before you continue to create confusion in this thread please do me and us a favor and read the relevant RFC's on BGP4. Especially read the sections about EBGP, IBGP and multi-hop EBGP and all their implications. If you have done so, either all the questions and points you raise here are answered or I'm willing to assist you in any matter. RFC1771, RFC1772, RFC1773, RFC1774 plus relevant Cisco Press Literature. Thank you -- Andre Oppermann TIX Project Manager Hans Petter Holen wrote:

I have tried to follow this discussion, and stumbeled over a fundamental question when trying to reason about this: * why are exchange points so special ?

It seems to me that shared medium exchange points historicaly have used a single subnet to interconnect. Generaly it simplifies configuration and eases operations to have a single logical interface on the physical interface connected to the shared medium.

But in order to excange traffic with other partners at the exchange one needs to establish "pont to point" BGP peerings. So there is no longer any significant configuirational advantage in having all the boxes I want to talk to on a single subnet (I still need to figure out how to talk to the others by establishing BGP peerings.)

On the operational side, at least back when I was directly involved in such, it would actualy be very convenient to have logical point to point links with all my peering partners in order to better diagnose and measure traffic flows and flaws.

If this is the case, the IP addresses for the logical point to point links across the exchange would best be implementedwith IP addresses from any of the providers, or perhaps even the IPv6 equivalent of link local addresses.

I would be interested to hear comments on this approach, because if this model makes senseto implement, it would probably make sense to document this as some kind of "best current practice" for IP v6 exchanges in order to make sure that the router vendors implements the proper tools to make this easy to configure.

Looking forward to hear others opinions on this.

-hph