May 2001 - lir-wg - mailman.ripe.net

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 Arjan 10 May '01

10 May '01

To: lists-lir-wg-out(a)lists.ripe.net To: David R Huberman <huberman(a)gblx.net> To: <200105101738.VAA93346(a)phil.wplus.net> Euhm, can we fix this ? Whatever is happening ? I think 7 copies is enough... Thanks :) On Thu, 10 May 2001 at 10:25 -0700, David R Huberman wrote: > To: lists-lir-wg-out(a)lists.ripe.net > To: postmaster1(a)wplus.net > > > To: lists-lir-wg-out(a)lists.ripe.net > To: postmaster1(a)wplus.net > > > To: lists-lir-wg-out(a)lists.ripe.net > To: postmaster1(a)wplus.net > > > To: lists-lir-wg-out(a)lists.ripe.net > To: postmaster1(a)wplus.net > > > 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 > > -- GE d- s++:++ a- C+++$ U+ P+ L- E---- W- N++ o++++ w O- M-- PS+++ PE++ Y+ PGP++ t+@ 5 X+ R* tv+ b- G e h r- y++

1 0

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

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

10 May '01

>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(a)space.net> =To: Mirjam Kuehne <mir(a)ripe.net> =CC: lir-wg(a)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(a)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(a)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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

RIPE-181 to RPSL Migration; Phase 2.
by DB-News 10 May '01

10 May '01

Dear Colleagues, (Apologies for multiple messages). On and from 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 will also be 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 RP S L 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 RP S L format On Monday, 14th May, 2001, we cannot guarantee that an update message sent to <auto-dbm(a)ripe.net> will use a specific update path (RPSL or RIPE-181). Thus, we advise that updates in RIPE-181 format should be sent to <auto-181(a)ripe.net> and that updates in RPSL format should be sent to <auto-rpsl(a)ripe.net>. 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, A. M. R. Magee - -------------- Database Group RIPE NCC

1 0

RE: IPv6 addresses for Exchange Points
by paul.mylotte＠bt.com 09 May '01

09 May '01

At the RIPE 39 joint meeting it was clarified that we should cater for the support of both types of IPv6 exchanges, viz: * allocate addresses for IPv6 exchange infrastructure only (no onwards allocation in the manner of a backbone ISP). * allocate a sub TLA to the IPv6 exchange which will then act in the manner of an ISP and allocate downstream. In order to progress this, I would like to propose: * IPv6 exchanges that need addresses for the purpose of internal addressing can apply for the addresses already set aside for this purpose and held by IANA, as per RFC2928 and RFC2450. In this case a /48 allocation will be sufficient. (How IPv6 exchanges should apply for these addresses is out of scope - either direct to IANA, or IANA allocates down to RIRs first). * IPv6 exchanges that plan to onward allocate addresses in the manner of an ISP should apply via the existing mechanism. The existing mechanism is currently being reviewed and this review should take account of any changes necessary to include IPv6 exchanges explicitly desiring addresses for onward allocation as being acceptable candidates for address space. Regards, Paul P. S. Mylotte BTexact Technologies Adastral Park 01473 606333 / + 44 1473 606333 paul.mylotte(a)bt.com BTexact Technologies is a trademarkof British Telecommunications plc Registered office 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be priveleged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the number or address above) immediately. > -----Original Message----- > From: Mirjam Kuehne [SMTP:mir@ripe.net] > Sent: 07 May 2001 16:35 > To: eix-wg(a)ripe.net > Cc: ipv6-wg(a)ripe.net; lir-wg(a)ripe.net > Subject: IPv6 addresses for Exchange Points > > > [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 > >

1 0

IPv6 Bootstrap Phase
by Mirjam Kuehne 07 May '01

07 May '01

Dear colleagues, As discussed at RIPE 39 in Bologna last week, we have almost reached the end of the bootstrap phase for IPv6 allocations as originally defined in the "Provisional IPv6 Assignment and Allocation Policy Document": 4.2.2.1. Duration of Bootstrap Phase " The eligibility criteria in this section will only apply until 100 requesting organisations have received allocations of sub-TLA address space, provided that no more than 60 of these organisations are located in one Regional IR's region. After this threshold has been reached, the bootstrap phase will be considered to be over and Regional IRs will only make allocations to organisations that meet the general criteria in section 4.2.1. " The Regional Internet Registries (RIRs) have jointly made almost 80 IPv6 allocations to date. At the RIPE meeting it was suggested to continue allocating under the bootstrap criteria until 100 allocations have been made and to further extend the bootstrap phase. No specific end for the bootstrap phase has been suggested. The RIRs will inform the community as soon as 100 IPv6 allocations have been made. Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Re: New Document available: RIPE-219
by Dmitry Morozovsky 04 May '01

04 May '01

To: <200105041458.QAA23820(a)office.ripe.net> Cc: RIPE NCC Document Announcement Service <ncc(a)ripe.net> On Fri, 4 May 2001, RIPE NCC Document Announcement Service wrote: RNDAS> Document number 219 is the European IP Address Space Request RNDAS> Form. This new document obseletes RIPE-141. I suppose differences between ripe-141 and ripe-219 are interesting for the LIR community. They follow (besides formatting issues and obvious references); on the other hand, most of changes between ripe-142 and ripe-220 are in formatting and changing all dates to 4-digit year notaion. --- ripe-141.txt +++ ripe-219.txt @@ -25,13 +24,13 @@ This document contains the set of templates to be used when submitting an IP assignment request. This set of templates must be used by - Internet Service Providers when submitting a request to the RIPE NCC. + Local Internet Registries when submitting a request to the RIPE NCC. It may also be used by ISPs to collect information from those managing the networks that will use the address space. Instructions for filling out the templates are found in the accompanying document "Supporting - Notes for the European IP Address Space Request Form ( ripe-142). + Notes for the European IP Address Space Request Form ( ripe-219). - Internet Service Providers: Submit the form via e-mail to + Requesters: Submit the form via e-mail to "<hostmaster(a)ripe.net>." (If the ISP is not a Local Internet Registry , the form should be submitted to the upstream provider.) @@ -138,13 +137,14 @@ inetnum: netname: descr: - descr: country: admin-c: tech-c: status: +mnt-by: +mnt-lower: (optional) +mnt-routes: (optional) notify: (optional) - mnt-by: (optional) changed: source: RIPE @@ -152,8 +152,6 @@ person: address: - address: - address: e-mail: phone: fax-no: (optional) @@ -163,6 +161,13 @@ changed: source: RIPE - #[TEMPLATES END]# IV. Optional Information Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck(a)rinet.ru *** ------------------------------------------------------------------------

1 0

New Document available: RIPE-219
by RIPE NCC Document Announcement Service 04 May '01

04 May '01

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE Document Store. Short content description ------------------------- RIPE Document number 219 is the European IP Address Space Request Form. This new document obseletes RIPE-141. Accessing the RIPE Document Store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-219.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-219.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-219 is not available from the WWW at this moment, but will be soon, at the following URL: http://www.ripe.net/ripe/docs/ripe-219.html

4 3

New Document available: RIPE-220
by RIPE NCC Document Announcement Service 04 May '01

04 May '01

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE Document Store. Short content description ------------------------- Supporting Notes for the European IP Address Space Request Form. This document obseletes RIPE-142. Accessing the RIPE Document Store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-220.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-220.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-220 is not available from the WWW at this moment, but will be soon, at the following URL: http://www.ripe.net/ripe/docs/ripe-220.html

2 1