- lir-wg - mailman.ripe.net

Proponents take IPv6 off its pedestal
by Hank Nussbacher 23 May '01

23 May '01

http://www.nwfusion.com/archive/2001/120951_05-21-2001.html -Hank

1 0

Re: Criteria for initial PA Allocation
by Wilfried Woeber, UniVie/ACOnet 23 May '01

23 May '01

Just some observations... => So, what is my conclusion? I estimate that while IPv4 address exhaustion => is going to be a problem (which IPv6 will solve), the routing topology => will cause major problems *sooner* than IPv4 runs out, and we should => do something against this. By this, I mean: => => - strongly encourage people to renumber from historic PI space to => PA space from their ISPs network block (and return the PI space => to the RIRs, to be aggregated) = :-) the finest way would be turning it "mandatory"... =i know this problem very well, as i've already done too much work =recovering some 192.x.x.x still given by ARIN... :-) This ship has left the harbour many moons ago... You can no longer honestly advocate that path to any site (without the support of _all_ ISP on the routing layer - which I expect to be nil) when the rules for obtaining address space in general, and PI in particular, have been tightened and can be expected to become even more restrictive in the future. =I still didnt finish this on my clients because some of them see it as a ="RESOURCE", and some are trying to X*Y valid addrissing by only returning =X address space... :-( they got it ;-) => - stop handing out PI space = =:-) well... could RIPE just talk to registered ISPs...? =I think this is very, very hard thing... Only a short while ago the community agreed that it is not reasonably possible to define what an ISP is. => - discourage people from becoming LIR if that's only to get "portable" => address space, with no intention of handing PA space out to customers. = =no customers = no ISP ? Be careful. You run into the same problem here, trying to define what a "customer" is. Just another aspect here, we tend to _again_ mix the concepts and responsibities of RIRs, LIRs and ISPs for the Internet (mind the capital "I" here). The ISPs collaboratively operating the Internet are responsible for the routing aspects. However, this should not prevent anyone for becoming an LIR and/or from obtaining globally unique IPv4 addresses - as long as they can document a need for them. This need does not necessarily involve connectivity to the Internet. Building an internet should be enough. => Yes, this might sound a bit harsh, but I'm *really* worried about => routeability and reachability of anything in the next couple of years. = =Yep... i see more than 104.000... Well, for the moment I consider that point moot. For quite a while the information has been made available (T.B., pfs reports) where the Internet could be improved (routing-wise) by e.g. aggregating and/or removing excessive announcements. In reality nobody really seesm to care (more than uttering their disgust :-), otherwise we would see real activity to get the broken ASes fixed (or filtered or disconnected), and an improvement. => Now go and flame me... :-) = =That's not the intention of it. = => 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 => = =./Carlos = "Networking is fun!" =------------------- =<cfriacas(a)fccn.pt>, CMF8-RIPE, Wide Area Network WorkGroup http://www.fccn.pt =F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 Wilfried. _________________________________:_____________________________________ 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

RE: Criteria for initial PA Allocation
by Hogeloon, Bert van 22 May '01

22 May '01

Hi, On Tuesday, May 22, 2001 15:58, Gert Doering, Netmaster [SMTP:netmaster@space.net] wrote: > Hi, > > (originally I did not really want to participate in this discussion, > as much of it has already been said in the last LIR-WG meeting). > > One thing got me thinking,though: > > On Tue, May 22, 2001 at 02:16:32PM +0100, Carlos Friacas wrote: > > /22 is a much more reasonable value by my view... > > Be careful what you are asking for. > > If we assume that minimum allocation size will go down to a /22, and > further assume that one fourth of the full IPv4 address range will > subsequently be handed out *and announced* as /22's, this means we > will see ( 1/4 * 2^22 ) = 1048576 /22's announced in the global BGP > table. That's over a million BGP routing table entries. I agree this is a concern, but it's always better then having the same amount of /20's in the table. I agree that we have to guard that potential 'real' LIR's do not start off with a /22, but that is also already achieved by reserving contiguous address space for a certain amount of time. The point is, would the NCC also decrease this reservation mechanism? > > This will have a significant effect on BGP routing stability and > also on the costs of global routing - you need a Gig of RAM in all > the BGP routers (on distributed architectures, more than that). The > CPU power required to handle a flap of a major line in a timely fashion > (to keep BGP convergence times low) will be horrendous. > > Also, it can be assumed that in this case, the global topology will > become complex enough so that most of the time many of the smaller > ASes won't be reachable anyway due to problems "on the way". > > I think this is something I do NOT want to see. > > > So, what is my conclusion? I estimate that while IPv4 address exhaustion > is going to be a problem (which IPv6 will solve), the routing topology > will cause major problems *sooner* than IPv4 runs out, and we should > do something against this. By this, I mean: IPv6 solves the exhaustion problem, but does it solve the multihoming problem? You would still have a lot of small companies wanting 'routable' address space. Getting PA address space makes you dependable on the routing table of at least one provider and thus doesn't guarantee you redundancy. > > - strongly encourage people to renumber from historic PI space to > PA space from their ISPs network block (and return the PI space > to the RIRs, to be aggregated) > > - stop handing out PI space > > - discourage "end users" from using multihoming with globally visible > address space (there are other ways, like "get multiple uplinks > to different POPs of the same ISP, and have them sign a SLA that > will get you 99.9% reachability or money back"). That is not really the same. For many companies, an outage of a few days can mean that they are out of business. Having your money back is then your least concern. The fact is that disasters do happen to every ISP once in a while and a lot of company's want to protect themselves from that. I don't think you really can discourage that. > > - discourage people from becoming LIR if that's only to get "portable" > address space, with no intention of handing PA space out to customers. That's nice, but you'll have to be able to offer them a good alternative. There are a few good alternatives (like NAT), but not all of these are workable for everybody. > > Yes, this might sound a bit harsh, but I'm *really* worried about > routeability and reachability of anything in the next couple of years. I agree it can create huge problems and we have to be careful, but the fact is multihoming is a huge dilemma for a lot of small company's (small of course in the sense of size of IP address space). Regards, Bert van Hogeloon > > Now go and flame me... :-) > > 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 >

3 2

RE: Criteria for initial PA Allocation
by BLOCKI,JACEK (HP-Poland,ex1) 22 May '01

22 May '01

Hello, Existing procedures promote allocation of /20 block to those who need multi homed networks. An example new LIR registration form included in Ripe212 reads: 4. What are the main reasons for becoming an LIR, rather than requesting address space from the upstream provider? We want to use BGP and connect to 2 upstream providers. Everyone knows existing internet has two problems: *limited IPv4 address space which has to be assigned in a fair manner *growing number of BGP routing entries Unfortunately those two are interconnected, if we decide to reduce initial allocation size and promote becoming a LIR, number of ASes will grow. One should keep in mind this number is also limited, on cisco routers AS number is two byte unsigned integer thus we can have max 65536 ASes. Conclusion: BGP "address space" (ASes) is even easier to exhaust than IPv4 address space. Of course one can always request IOS modification, but it will also require change in BGP specification. Taking into account scale of change and resulting growth of routing tables it won't be easy. As I understand existing RIPE rules are oriented towards traffic organization. LIRs provide internet connectivity and assign IP addresses to end customers. In an ideal world, where providers guarantee QoS there will be no need for end user multi homing. However world is not perfect, therefore a need for multi homing arises. In my opinion, based on situation in Poland, the only way to ensure proper routing is own CIDR block -> go LIR. Other solutions such as "more specific routes" don't work in practice, especially when you want to provide service (e.g. run portal) over internet. From technical point of view BGP deployment is a valid reason to assign a CIDR block. If we want to tame rapid growth of LIRs we should ask for justification of BGP implementation and refuse LIR registration if the only reason is convenience (we want own address space and are aware of PI problems). Of course it won't be easy and will result in numerous problems. Therefore we should only impose administrative limitations on becoming a LIR if we have to, e.g. we are afraid to run out of CIDRs before IPv6 is widely implemented. I understand such a policy hinders "new kids on the block", but CIDR blocks are no different from any other scarce resource, difficulty to get one increases as number of free ones decreases. Regards, Jacek Blocki -----Original Message----- From: Alfredo Sola [mailto:alfredo@intelideas.com] Sent: Monday, May 21, 2001 7:36 PM To: RIPE NCC Staff Cc: lir-wg(a)ripe.net Subject: Re: Criteria for initial PA Allocation > The RIPE NCC has experienced several cases where organisations have > insisted on becoming members in order to receive a portable /20 > address block despite the fact they clearly state that their need is > for less, in some cases only for c:a 300 addresses. We also observe > organisations who become LIRs with the pure objective of obtaining > portable address space but who are unaware of the responsibilities and > workload membership comprises. We are painfully aware of this. Furthermore, many mid to large organisations could do it with less than a /24 as they are doing address translation and need only a handful of IPs for the translated users and a handful of public servers. However, I don't think it is feasible to allocate such small ranges. The only alternative to me seems to lower the initial allocation of Enterprise LIRs to a /22 or even a /24 (if a range is available that won't be filtered out by the usual prefix length policies), except if the LIR asks for something larger on the first request. By doing that, you would also be able to say to PI requesters to get a LIR, which they don't actually need to get their IPs as of now. Responsibilities - I honestly don't have a suggestion for that, other than pointing out that when one needs only one range and maybe a second one after many months or even years, this can probably be done without much hassle. It would be more of a problem if we were talking about ISPs, which need new allocations every day. -- Alfredo Sola Director técnico () ascii ribbon campaign /\ Support plain text e-mail

2 1

Re-shifting priorities in the Registration Services
by RIPE NCC Staff 21 May '01

21 May '01

Dear all, This is to inform you that we are re-shifting our priorities in the Registration Services at the RIPE NCC. As this may affect the members' planning, the details are outlined below. The Registration Services will for the coming future be focusing its efforts on IP and ASN requests. As reported over the last years, a large part of the RS's workload is represented by the high amounts of questions we receive. However, it has been expressed in the membership that although the education is a vital part of the RIPE NCC's role, it shouldn't impede or delay the evaluation of IP and ASN requests. In order to give required priority to IP and ASN requests, we will therefore be giving lower priority to general questions and queries, which will be removed from the general wait queue. While we are waiting for software to automate this process, we are already starting this approach on a manual basis. We therefore ask for your patience with your questions and queries, keeping in mind that IP and ASN requests will be answered in a quicker fashion. We would also like to ask you to make sure that your requests are properly filled out, paying close attention to all templates as this ensures that correct priority is given and faster processing of the request. Please see the URLs below for further information and explanations. Another change underway is related to the way priorities are given to new and on-going requests. In order to reduce the initial waiting time, we will be giving priority to new requests as opposed to on-goings. This will allow hostmasters to quickly reply to and approve correct requests, while requests that require many corrections and reiterations are given a lower priority. This change is in concordance with recent feedback from the community and is part of an attempt to respond to the membership needs in a more precise and timely fashion. Kind regards, Nurani Nimpuno +------------------------------------+ | Nurani Nimpuno | | Registration Services Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | +------------------------------------+ Quick tips for IP and AS Requests: http://www.ripe.net/ripencc/tips/tips.html Registration Services FAQ: http://www.ripe.net/ripencc/faq/registration/index.html European IP Address Space Request Form http://www.ripe.net/ripe/docs/iprequestform.html Supporting Notes for the European IP Address Space Request Form http://www.ripe.net/ripe/docs/iprequestsupport.html

2 1

Re: IPv6 addresses for EP
by Dave Pratt 18 May '01

18 May '01

Hiya, I've removed lir-wg(a)gblx.net from the distribution !!! Please see below. On Thu, 10 May 2001, 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. -> ->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 Looking at a couple of professionally run exchanges in Europe, I disagree. Exchange support infrastructure needs to be multihomed, and as Randy so succinctly pointed out, this cannot be achieved through a transit provider (or with their addresses). I would see an exchange being in control of a block (at least /48, although a normal LIR assignment would make more sense to me to ensure routability). This block would be globally routable and provide connectivity to support infrastructure. A more specific prefix of this could then be used for the exchange LAN itself. If the exchange requires two completely independent prefixes then I would also support that option. IPv6 addresses are not in short supply - a /60 compromise only complicates things and is against the "/48 policy". We could expand this discussion to cover multihoming in general - why would anyone switch to IPv6 from IPv4 if it means they can no longer multihome like they did in IPv4. Cheers Dave

9 13

80/8, 81/8 Allocated to the RIPE NCC
by RIPE NCC Staff 18 May '01

18 May '01

Dear all, This is to inform you that the RIPE NCC has recently been allocated the CIDR blocks 80/8 and 81/8 by IANA. The RIPE NCC is currently starting to make allocations primarily from 80/8. The minimum allocation size made by the RIPE NCC in these address blocks is a /20. ** If you use prefix based filtering in your routers, please note this change ** This has been announced previously but may not have reached all affected parties. We sincerely apologise for this. For a complete list of all /8 address blocks, please refer to: http://www.iana.org/assignments/ipv4-address-space Kind regards, Nurani Nimpuno +------------------------------------+ | Nurani Nimpuno | | Registration Services Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | +------------------------------------+

1 0

80/8, 81/8 Allocated to the RIPE NCC
by RIPE NCC Staff 18 May '01

18 May '01

Dear all, This is to inform you that the RIPE NCC has recently been allocated the CIDR blocks 80/8 and 81/8 by IANA. The RIPE NCC is currently starting to make allocations primarily from 80/8. The minimum allocation size made by the RIPE NCC in these address blocks is a /20. ** If you use prefix based filtering in your routers, please note this change ** This has been announced previously but may not have reached all affected parties. We sincerely apologise for this. For a complete list of all /8 address blocks, please refer to: http://www.iana.org/assignments/ipv4-address-space Kind regards, Nurani Nimpuno

1 0

RE: New Document available: RIPE-219
by Low, Adam 18 May '01

18 May '01

Is it me or are the ASCII versions of this document unavailable, the FTP site doesnt seem to have them ? Thanks, Adam > -----Original Message----- > From: RIPE NCC Document Announcement Service [mailto:ncc@ripe.net] > Sent: 04 May 2001 16:58 > To: ripe-list(a)ripe.net > Cc: local-ir(a)ripe.net; lir-wg(a)ripe.net > Subject: New Document available: RIPE-219 > > > 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 >

1 0

Fw: [aso-announce] ASO input forum at Saturday June 2nd 0900
by Hans Petter Holen 16 May '01

16 May '01

----- Original Message ----- From: "Hans Petter Holen" <hph(a)online.no> To: <aso-announce(a)aso.icann.org> Sent: Wednesday, May 16, 2001 10:47 PM Subject: [aso-announce] ASO input forum at Saturday June 2nd 0900 | Dear Adrressing Community, | | The ASO plans to hold an ASO input forum | at the upcoming ICANN meeting in Stockholm. | | http://www.icann.org/stockholm/ | | The meeting is Scheduled to take place at | Saturday June 2nd 0900 | | Please submit proposals for presentations to be | given to hph(a)online.no before May 26th | | Best Regards, | | Hans Petter Holen | Address Council Chair | www.aso.icann.org | | * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-announce * | * To unsubscribe: send "unsubscribe" to aso-announce-request(a)aso.icann.org * | |

1 0