- lir-wg - mailman.ripe.net

[pekkas@netcore.fi: RIR ISP to end-user address allocation policy?]
by John Wells 16 May '01

16 May '01

Here's a message from the IPv6 WG listserv. This should start some discussion.. John -- John WELLS INRIA Rhône-Alpes équipe Planète - ENSIMAG 3A/Télécomm et Réseaux Virginia Tech MS/Computer Engineering - Networking and Visualization Lab Clé public: finger wells(a)mansoun.inrialpes.fr <interne>

6 8

RE: IPv6 addresses for EP or why are exhanges so special ?
by Hallgren, Michael 16 May '01

16 May '01

> > > > 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? > > My take on this is that "they are not". > > But before plunging on, I would find it useful to distinguish > between the two portions that have been discussed so far: > > o Addresses for the exchange point medium itself (usually a > layer-two network of some sort) > > o Addresses for a "service network", probably used by the > organization which runs the exchange point and which can > provide additional common services of interest to the > connected networks. > > I'll also mention that my experience on the matter is based on > IPv4, so if there are additional quirks that are specific to IPv6 > that I don't know about, you'll have to excuse me. > > 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". > 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. 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. > I'm of the same opinion. > 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 fear that as well. Of course, however, it's a question of being smallest MTU on path - but for avoiding such potential problems... > 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. > > > 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? > Depending on how transit / co-location is provided, yes. Hrm,... maybe I'm wrong, maybe I'm right... but couldn't suitable PI disjunct to IX infra space (and/or close segment) be a choice as well? Thoughts? Kind regards Michael > > 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!!". > > > Best regards, > > - Håvard >

1 0

IPv6 addresses for Exchange Points
by Mirjam Kuehne 15 May '01

15 May '01

[Apologies for multiple postings. I suggest to keep the discussion on <lir-wg(a)ripe.net> as it is related to address allocation policies]. Dear colleagues, At RIPE 39 last week in Bologna the issue of IPv6 address assignments to Internet Exchange Points was discussed (see also my mail from 24 April 2001 to these lists). 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. 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. The RIPE NCC proposes to proceed with assignments for Exchange Points under the above policy. Kind Regards, Mirjam Kuehne RIPE NCC

3 2

RIPE-181 to RPSL Migration; Completed switch-over to phase 2
by DB-News 14 May '01

14 May '01

Dear Colleagues, (Apologies for multiple messages). This is to announce that we have completed the phase 1 of migration. Starting from today, Monday, 14th May, 2001, <auto-dbm(a)ripe.net> shall only accept updates in RPSL format; updates in RIPE-181 format will no longer be accepted. Updates in RIPE-181 format can be sent to <auto-181(a)ripe.net>, where they will be automatically converted to RPSL format. <auto-rpsl(a)ripe.net> will continue to accept updates in RPSL format. The update path for the TEST database has also been changed. In summary, from 14th May, 2001: =============================== RIPE Database: ------------- <auto-dbm(a)ripe.net> - updates in RPSL format only <auto-rpsl(a)ripe.net> - updates in RPSL format only <auto-181(a)ripe.net> - updates in RIPE-181 format, automatically converted to RPSL format TEST Database: ------------- <test-dbm(a)ripe.net> - updates in RPSL format only <test-rpsl(a)ripe.net> - updates in RPSL format only <test-181(a)ripe.net> - updates in RIPE-181 format, automatically converted to RPSL format Please note that from Monday, 15th October, 2001, updates in RIPE-181 format will no longer be accepted by the RIPE Database. Further information is available from http://www.ripe.net/rpsl/. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz ____________________________ RIPE Database Administration.

1 0

Re: IPv6 addresses for EP or why are exhanges so special ?
by Cathy Wittbrodt 11 May '01

11 May '01

HPH, The other reason why there is an allocation policy for exchange points (at least in the ARIN region) is because the folks who are building exchange points may not have enough of them to justify the minimum allocation. It seemed reasonable that they would need provider independent space, however, so they can get it with the provisions written in the policy. If you think about a neutral exchange point provider who's business is to connect up providers to peer, etc, that exchange point provider may want or need to supply the IP addresses for that exchange point. They're providing a service and may want to provide the address space as well. I can't speak for the exchange providers, but setting up p2p vlans or whatever for folks connected to the same ethernet switch may be time consuming and also can waste quite a bit of address space (if you're using /30s for p2p links and not /31s, per the new yet unimplemented draft). I hope this helps! ---CJ From: "Hans Petter Holen" <hph(a)online.no> Subject: IPv6 addresses for EP or why are exhanges so special ? 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

1 0

RE: IPv6 addresses for Exchange Points
by Hallgren, Michael 11 May '01

11 May '01

> -----Message d'origine----- > De : Randy Bush [mailto:randy@psg.com] > Envoyé : jeudi 10 mai 2001 22:54 > À : David R Huberman > Cc : Gert Doering, Netmaster; Wilfried Woeber, UniVie/ACOnet; > lir-wg(a)ripe.net > Objet : Re: IPv6 addresses for Exchange Points > > > > 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. > idem :) mh > randy > -- Michael Hallgren, Inet Eng., Teleglobe, MH2198-RIPE

1 0

Re: IPv6 addresses for Exchange Points
by Hank Nussbacher 11 May '01

11 May '01

At 10:25 10/05/01 -0700, David R Huberman wrote: > > 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. What about a route reflector run at an exchange point with a LG to check things out? Wouldn't a globally routable IP address be called for in regards to the LG? -Hank >/david

2 1

Re: IPv6 addresses for Exchange Points
by David R Huberman 11 May '01

11 May '01

> ->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. I don't understand. An exchange point, as I think about well-known implementations, is simply a means by which to organize participants in a common place. It's an island to which multiple participants connect with the explicit goal of interconnecting to one another. Exchange point address space should only be used to establish those interconnections with the routers - not for any ancillary services the exchange point might provide that require internet connectivity. Such services should *not* be part of any exchange point address policy considered by LIR-WG, imo. /david

2 1

Re: IPv6 addresses for Exchange Points
by Wilfried Woeber, UniVie/ACOnet 10 May '01

10 May '01

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(a)Space.Net =Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 =80807 Muenchen Fax : +49-89-32356-299 Wilfried.

5 5

Re: IPv6 addresses for Exchange Points
by David R Huberman 10 May '01

10 May '01

To: lists-lir-wg-out(a)lists.ripe.net To: <20010510154913.C3919(a)Space.Net> > 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

2 1