|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: ULA and RIR cost-recovery
In a message written on Wed, Nov 24, 2004 at 11:40:50AM -0800, Tony Hain wrote: > The current problem is that the RIR membership has self-selected to a state > where they set policies that ensure the end customer has no alternative > except to be locked into their provider's address space. Everyone > acknowledges that the demand for PI space is real while simultaneously > refusing to seriously deal with it (and the re-architecting of fundamental > assumptions about the Internet effort of multi6, while serious, is not a > short term solution). I don't think this statement is true on its face. Regardless, if it is true the end users have no one to blame but themselves. The policy process (at least for the past several years) has been an open, public process. You don't have to be a member to show up and make policy. The big ISP's do not dominate the discussions. You need look no further than than those elected for proof. The ARIN Advisory Council is elected by the membership. The members are at http://www.arin.net/about_us/ab_org_ac.html. If you look close you'll see that of the 15 members only 3 work for "large ISP's". If you look closely at recent events, you'll see a number of proposals all for small ISP's or for end users. The members passed 2003-15, a relaxation of the rules in Africa to help small ISP's in Africa. The members passed the "six months" rule, to insure growing ISP's would always have plenty of addresses on hand. The members passed a policy to allow end users to always get a /24 from their upstream if they are multi-homed. The members moved the minimum allocation size from a /20 to a /22 for multi-homed sites. Did we experience some growing pains in the past? Sure. There were technological and political issues in the past that caused some people some pain. However, the process that came out of all of that is fair and open. Almost all the IP Allocation issues in the past 2-3 years have been issues that the small guy faces, and have generally been passed to help them grow. So, I don't know where your statement comes from. When end sites can get a /22 directly from ARIN so they can multi-home, I wonder how we are locking end-sites into their providers address space. Since you can get a /22 with a 50% justification you only have to show a need for 512 IP's to be provider independent. I would love to know how that is an unreasonable barrier. Note, there is also talk of ARIN extending this boundary to a /24. This will be tackled in upcoming meetings. The membership decided we would go to a /22, collect data, and evaluate the impact of moving to a /24. While we only have 6 months of data so far, the current trend does not indicate a "land rush", which makes it much more likely the boundary will go to a /24 within the next 12-18 months. So, it seems like in IPv4 land we're making it quite easy for end-sites to get PI space. It also seems like, even with end sites getting PI space, and everyone announcing cutouts of provider blocks we don't have a global routing table that's too large. We're at ~140,000 routes now, and that's with the mess of the swamp and other poor past decisions floating around. To bring us full circle back to IPv6, if we don't do stupid things like create a swamp (which in my mind includes ULA), the table should not be any bigger (by number of routes) than with IPv4, and in fact should be smaller. Many companies today have several IPv4 prefixes in the swamp, non-aggregateable, and all of the proposed IPv6 schemes would prevent that from ever happening. I firmly expect the IPv6 table would be around half the size of the IPv4 table were similar allocation rules to be applied. That's something we can manage, and it gives all the end sites a shot at PI space as well. If we cut the table size in half, even with addresses that are 4x the size, we only double memory requirements. Given where routers are going with memory that doesn't seem like a big issue in the timeframe that we are talking about. There was a time when people were running AGS+'s that needed to filter routes to get them to stay up. There was a time when people ran 7513's with 128M of RAM and they were falling over due to too many routes. There are important lessons to learn from those experiences. Operators and vendors took away a lot of knowledge from those incidents, and started to produce boxes that didn't have those limits. While we need to learn from those mistakes and not repeat them they do not lead to such draconian moves such as "NO PI SPACE!", such as those in the IPv6 working group want to push. So, in summary, you state end sites have no alternative but to use their upstreams addresses. Nothing could be further from the truth with IPv4, with the RIR's currently bending over backwards to make it easier for small sites to be provider independent. At the same time you want to push an IPv6 proposal that specifically excludes all PI space. Hipocracy at its best. The IPv6 working group needs to adopt a simple path for moving forward. #1 Set aside a block for "local" use a-la RFC1918. This set aside should make no recommendations about how the space is subdivided for used for these local purposes. #2 Drop the ULA nonsense. As currently crafted its destined to fail. #3 Drop the absolutely stupid notion that there should be no PI space. There will be PI space, either by people using ULA for that purposes, or by the RIR's changing this stupidity after they get ahold of it. #4 Drop the absolutely stupid notion that "one size fits all". A /32 for everyone makes no sense. VLSM was a good idea. #5 Stay out of the allocation details. The RIR's have been allocating addresses for years. The RIR's have people, from small to large ISP's and everything inbetween solving real world allocation problems every day. The history tells us is the policy will change over time. History also tells us being too liberal early on can never be "fixed". The RIR's will change policy as time goes on to fit the changing IPv6 world. Let them deal with the policy on a going forward basis. -- Leo Bicknell - [email protected] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [email protected], www.tmbg.org Attachment:
pgp00119.pgp
|