Hi @all, first: thanks @Carlos for your response. I've read a lot of statements and position herein, some making sense to me, some hinting a way to go on and some simply sounding like 'ground-keeping'. I'd like to try to sum up the problems (real, possible future, self-made) and add a few thoughts myself. Currently there're ~35.000 AS'es handed out with ~180.000 prefixes carried in the v4 table. The v6 table houlds about 500-600 prefixes now. According RIPE-353 about 1/4 to 1/3 of the ASN handed out aren't seen in the forwarding paths. This leads to the first (and I think most urgent problem) taking a look at the rate ASN's a assigned nowadays. In rough numbers there're about 10.000 ASN not being visible in the routing table. And like someone else already mentioned in the 'multi-homing v6' discussion, how many of the newly handed out ASN are really required for multihoming ? I don't want to open a discussion about 'proper' way to multihome (again), but how many of the 'corporate' ASN handed out are really going to connect to more than one upstream provider ? (I know of LIR's operating their network with dual uplinks for the same upstream and a 'fake' secondary. Before someone starts shouting how to know: one of our aligned companies had been on of these.) During my years in ISP networking bussiness I've more than once come upon a network with fake entries and customers/potential customers multihoming to one upstream and asking for an ASN request with a second upstream being 1/50th to 1/10th of the primary bandwidth to satisfy requirements. These setups I'm almost sure don't need an ASN. And how about the non-visible ASN ? They may be hoarded, used for confed's after mergers & takeovers, a few for test networks (if reasonable argumented I agree here) or simply not returned to the pool after removal due to laziness. So first point to consider when talking 'needless' resources is: how to possibly limit the number of multihoming-ASN handed out to the ones really needed and how to move people to hand them back when no longer needed ? In case of PI space this is a bit more complicated. Adresses hasn't to be visible in the global routing tables to satisfy a need for globally unique adresses. Although in v4 world, RFC1918 & NAT are a fine thing to conserve address space, but forcing their use would be dictating others how to operate their network. This gets me to the assumption not every PI address space will get through to the routing tables. Surely PI space mostly not being aggregatable is filling up the tables with prefixes. But don't the de-aggregated PA's also do ? And what about invalid announcements (take a look to your table and search for ASN >=65512 !) ? What about the (IMHO) pollution of the table with nonsene of entries longer - let's say - /24 ? Did you ever take a look about your table in regard to prefix sizes ? There's a lot of /28 - /30 flowing around. At least for the /30 I think there're guys messing up their redist and BGP filters. Before we - the LIR admins - aren't able to agree on senseful filters and what's mess not to be announced (prefix length) and behave ourselves (de-aggregates) where's the right to discussing other peoples needs ? (just a comment: I've read someone here stating something like: do what you want, but not in my table. Hopefully there's no flaw to find in YOUR announcements ....) I've written in my previous (messy) post, but again: are we the ones entitled to decide how a customer has to run it's network and what he needs and what not ? Let me ask a simple question: how many of you do work directly in first line on your customers (in means of consulting your sales guys) ? Customers (especially corporate) nowadays are striving for redundant / multihomed connectivity and - the Level3/Cogent de-peer a few months ago showed this - how can you be 100% sure connectivity even by multiple links to one ISP won't take you offline ? There could be a serious network issue, a de-peer, the network could be blown by one of those nasty bot-nets etc. Many companies are moving ever more bussiness towards their internet access and therefore they reasonably ask for best connectivity possible (at reasonable cost). You can shake your head as furiously you like, but the primary target won't change: customer's demand. Did you always try to tell your boss that you wouldn't submit a PI or ASN request for a potential customer ? I bet you wouldn't do that often - maybe more than once, but you'd soon be looking for a job. Often a solution can be worked out together with the customer but not always. The customer will simply move on to another ISP willing to - at least try to - fulfil his wishes. PI space in v6 in demanded by customers the same way it is for v4. Either there'll be a way to satisfy this need or a solution to the multihoming dilemma with globally unique adresses SHORTLY or IPv6 can be dropped RIGHT NOW. This get's the second and third thing to consider: how do we get people to hand back no longer needed PI space and how will we handle IPv6 PI ? On side of the ISP's there're worries about size of the routing tables and the costs to replace your routers. But did you take a look at the growth rate of utilized bandwidth ? All these 'high-bandwidth' consumer links like DSL and such are driving bandwidth requirements up and up steadily. How long do you think your routers can keep with the traffic volume ? With number and bandwidth of consumer internet access increasing also the risk of floods and the basic 'trash' flowing around increases. On customers side there're worries about stablility and cost also, but maybe taken in another perspective. Corporate customers are willing (at least most of them) to pay more for a stable setup lowering (or at least pinning) their TCO. This includes not having to renumber regularly and/or being dependent on one ISP. But even if they are willing to pay more for true multihoming I'd like to hear how you sell them becoming a LIR themselves although they will never provide internet services to others but would have to care for a lot rules and administrative work in addition. PI as it's administrative nature is now is exactly what the want and need. So regardless where you put your eyes upon, it always comes back to money. So why not take (try) a simple approach. - get IPv6 (corporate-)ready by handing out PI space out of a well-known address space in chunks of /40 to /48 - limit the routing table size by agreeing on 'best practice' filters for prefix-length - limit the routing table size by bashing de-aggregators --- just kidding ... --- - limit routing table size and assigned resources by creating a motivation to hand resourced back. The last item is IMHO the crucial. RIPE-330 charging scheme states: Note: For AS Numbers and PI IPv4 allocations, only the allocations from the past 12 months dating back from the 30 September 2004 are taken into account as these resources are allocated or assigned on behalf of third parties. WHY ??? Let non-LIR's pay for their resources as well, but without requiring them to become a LIR. I'd propose something like: Add a new member category 'corporate' for those who don't provide internet services to others but are in need of resources and assign a charging scheme without any time variable. One-time: 500 EUR yearly: 250 EUR per ASN: 250 EUR (per year) per PI assignment: 150 EUR (per year) With at least 650 EUR a year people would think twice about their needs. In addition remove the ASN's for ISP's from this charging scheme and also charged fixed 250 EUR per ASN/year. This would hopefully push at least some people to hand back no longer used ASN or 'official' ASN used for confed's. regards, Marcus ---------------------------------------------------------- Tropolys Rhein-Main GmbH Network Engineering and Administration Fon: +49-(0)6131/129343 | Fax: +49-(0)6131/129321 Mombacher Str. 40, 55122 Mainz, Germany ---------------------------------------------------------- AS15837 | AS8638 | MG3031-RIPE ----------------------------------------------------------