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@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