Re: Policy Statement on Address Space Allocations
The same ISP has said publicly that they will route /19 prefixes in our address space: 193/8 and 194/8. The discussion is still going over future /8s. But read the last paragraph of the policy statement!
Sure, there is no filtering in 193/8 and 194/8, and as a result we have VERY poor aggregation. Consider this random cut-and-paste from 194/8. * 194.19.36.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.37.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.40.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.54.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.55.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.60.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.192.0 144.228.101.1 1 90 0 1239 701 3300 3301 5427 i * 194.20.0.0/15 144.228.101.1 1 90 0 1239 701 3302 ? * 194.20.8.0/21 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.16.0 144.228.101.1 1 90 0 1239 701 3300 ? * 194.20.19.0 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.20.0/22 144.228.101.1 1 90 0 1239 701 3397 ? *>i194.20.32.0/22 144.228.121.118 10 100 0 3345 i * 194.20.36.0/22 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.40.0/23 144.228.101.1 1 90 0 1239 701 3302 3313 ? * 194.20.42.0 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.44.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.49.0 144.228.101.1 1 90 0 1239 701 3302 3313 ? * 194.20.50.0/23 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.52.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.56.0/23 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.60.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.64.0/19 144.228.101.1 1 90 0 1239 701 3302 1267 i * 194.20.96.0/21 144.228.101.1 1 90 0 1239 701 3269 5394 i * 194.20.104.0/22 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.108.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.112.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.120.0/21 144.228.101.1 1 90 0 1239 701 3302 3313 ? * 194.20.136.0 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.137.0 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.138.0 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.139.0 144.228.101.1 1 90 0 1239 701 3300 5392 i Putting in a filter on 195.0.0.0/8 that will permit ONLY /18s and shorter prefixes is the only means I can see at this time that will make this kind of b.s. impossible. Indeed, if I put inbound filters on these announcements (and many other similar examples in 194/8) today, I would bet that within two days, everything that can be aggregated above, in Europe and by AlterNet, would be aggregated. If you have some technical means by which you can guarantee that no future allocations will result in rafts of unaggregated addresses like the random chunk cut and pasted above, then I would like to know about it.
I wonder where that rumour comes from. It is certainly not the RIPE NCC allocation policy. this is a good time to set the record straight on this and related things. This is *not* an attack on Tony who, I am sure, was quoting some rumour in good faith.
Yah, yah, Daniel, it's a giant conspiracy against you and Tim Bass.
1) The initial allocation for a newly established local registry (ISP) *always* is a /19. There will be no discussion about this. This is fixed, cast in stone, immutable, ... you get the idea.
Ah, so Mr "we need to find compromises" of the last message when referring to me not being willing to abandon the goal of an absolute maximum of 1024 prefixes only (and hopefully far fewer) in every /8 remaining in the old-style class C space is not so flexible as he wants me to be? Not that I care; I'm not prone to compromise myself, frankly. I just find the change in your tone from one message to the next awfully amusing.
Note that we make /19 allocations even though one particular ISP is telling the world that /18 is the minimum you ought to have these days.
Yup. And when you make the /19 allocations, you should tell them that in 195/8, if they are announcing a /19, a /20, a /21, a /22, a /23 or a /24, that will not work if they want to talk to SprintLink via a non-customer path. If not, well, I have this neat archive of plenty of warnings I've posted on several lists, and I work with a team of good people in program management, marketing, media relations and legal who went through this in a rather more controversial atmosphere when the filters on 206/8+ went in place, cutting off people who previously had gotten accidental connectivity using long prefixes. Filters on ranges of addresses that have not yet been allocated from is much simpler to defend on all fronts.
Our experience suggests that /18 is too much to assign to any newly established local registry. It is too wasteful. On the other hand we cannot live without policy #1. So we decided to stick to /19s.
Well, you're the registry. I can only tell you the consequences, and that I won't lift a finger to make exceptions when people start whining, "but RIPE didn't TELL me it wouldn't work!".
It should be noted that we have started allocating hierarchically from 193/8 when the InterNIC was still using 192/8. So we feel that we have quite a good track record concerning routing aggregation and address space conservation too. We consider our policy a good compromise between aggregation and conservation and our community backs this policy.
I don't disagree that historically RIPE's allocation policy has been *excellent*. However, there are two problems: firstly, it is insufficient in and of itself to prevent things like the stuff above, and secondly there is a disconnect between allocations and announcements. So, let's kill two birds at once: first, an enforcement mechanism to push people into announcing only one prefix per allocation, and second, increase the size of the initial allocation, which will tend to push people away from RIPE as the registry of first choice. I'm sorry if that hurts your income, RIPE. Sean.
Please excuse me for butting in on a argument the political background of which I know very little, but this was directed at local-ir so: <snip>
If you have some technical means by which you can guarantee that no future allocations will result in rafts of unaggregated addresses like the random chunk cut and pasted above, then I would like to know about it.
<snip>
I don't disagree that historically RIPE's allocation policy has been *excellent*. However, there are two problems: firstly, it is insufficient in and of itself to prevent things like the stuff above, and secondly there is a disconnect between allocations and announcements.
So, let's kill two birds at once: first, an enforcement mechanism to push people into announcing only one prefix per allocation, and second, increase the size of the initial allocation, which will tend to push people away from RIPE as the registry of first choice.
Problem 1: Smaller local-ir's with their own AS's cannot get windows larger than /19 from RIPE. If they need more than a /19 and request them non-simultaneously the /19s are not likely to be adjacent and hence aggregatable. If Sprint or anyone else refuse to accept /19 announcements, there is no way such local-IR's can get their IP numbers routed. For instance our announcement contains a /19 which is adjacent only to allocations nothing to do with us. Problem 2: Historically the breaking up of RIPE windows/allocations between different AS's has lead to a multitude of tiny announcements. Problem 3: Some ISPs have been lazy in the aggregation of routes on their router. How about: Each window that RIPE dish out (currently never smaller than /19) must have an AS number associated with it in the RIPE database before any allocations from that window are 'legal'. All announcements of address within that window must be made a single aggregated announcement covering the entire window (or more if there happens to be an adjacent allocation) which originate in the associated address. This fixes the PA addresses issue (with the slight complication that providers could theoretically need one window per AS, but this would help aggregation anyway). New PI addresses I couldn't really care less if Sprint etc. don't carry them, but essentially as long as they fall in an entire /19 with associated AS object they culd fall under the same scheme. The only legitimate reason for new PI addresses as far as I am concerned is to issue to small-ish organizations who are not local-ir's and are not multihomed, and will want /19 or thereabouts. Solves problem 1 IMHO. A time limit could be proposed where the above could be enforced for the rest of 193.* & 194.*, with RIPE cooperating to help existing providers renumber. Solves problem 3. Which just leaves (2) (historical - like most of 192.*). Well at least this problem won't grow. Alex Bligh Xara Networks
aggregatable. If Sprint or anyone else refuse to accept /19 announcements, there is no way such local-IR's can get their IP numbers routed. For
So Sprint should abandon their ridiculous policy. We only announce a /22 and are proud of it! I obviously missed something. Can someone please inform me as to the purpose of not accepting /19 announcements? Iljitsch van Beijnum bART Internet Services
Sean Doran says:
Yah, yah, Daniel, it's a giant conspiracy against you and Tim Bass.
Since my name was mentioned by Sean without provocation, please allow me to respond briefly: ------------------ the kind and compassionate reply ------------------ It interesting that as technologists and engineers, the current climate in internetworking works with undertones of "don't ask questions, because to do so is a form of heresy" against the Internet. I have spent (a few, not enough) days in the archives of Computer Networks, the IEEE journals, and other peer reviewed papers on hierarchical routing; and I have seen *zero* technical justification for "turning a blind-eye" to other less problematic hierarchical routing architectures ( the CIRD, BGP4 paradigm is problematic.... that is why this discussion is taking place as we know) In fact, I have not found one reviewed paper in a journal that compares and contrasts, stochastically, the pros and cons of different hierarchical routing models. Instead of emotional overtones and name calling, isn't it prudent to examine all hierarchical routing paradigms, generate stochastic models, and determine the optimal way to perform hierarchical routing (and try to avoid problematic practical issues as well, which BTW are important ). Hierarchical routing *does not* necessarily translate to "the BGP4, CIDR development path forever"; but for some reason that I cannot explain (and that Sean quips to be "the conspiracy theory" by us engineering skeptics and CIDR heretics) the "world" refuses to take any other hierarchical routing architectures seriously (and many are plausible and feasible if implemented, someone just kindly faxed me another one, BTW). CIDR aggregation is a flawed paradigm for long term growth of the global infrastructure (and most of the engineers seem to roughly agree, IMO); yet we, as technologists, are driven by the forces of commerce to "expand the Internet as fast as possible, keep the growth curve high, grow, grow, grow" mantra; and accept that "we'll just have to be satisfied with band-aid, "change the wings in flight" engineering. .... ladies and gentlemen, we have exactly what we want..... high uncontrollable growth, backwards compatibility problems, forward scaling problems, and the same old protocol development track and engineers and technologist in disharmony. If you study the technical development of the current track, there is a "missing link" that begs to be explored. It would be kind of "those in the CIRD camp" not to label us engineering skeptics who seek to understand "why" as 'heretics and conspiracy theorists'. Personally, I am just interested in answering the question "why?" without throwing stones or casting blame. Thank you and kind regards, Tim postscript: When this thead started, I was determined to stay on the sidelines, and avoid such a wide audience; but since I was mentioned directly in a reply, it seems appropriate to post a short clarifiation, thank your for understanding. +------------------------------------------------------------------------+ | Tim Bass | | | Principal Network Systems Engineer | "Every decoding is another | | The Silk Road Group, Ltd. | encoding.." | | | | | http://www.silkroad.com/ | David Lodge | | | | +------------------------------------------------------------------------+
Since my name was mentioned by Sean without provocation, please allow me to respond briefly:
And I don't know you - so don't take this one personally either :-)
Instead of emotional overtones and name calling, isn't it prudent to examine all hierarchical routing paradigms, generate stochastic models, and determine the optimal way to perform hierarchical routing (and try to avoid problematic practical issues as well, which BTW are important ).
Hierarchical routing *does not* necessarily translate to "the BGP4, CIDR development path forever"; but for some reason that I cannot explain (and that Sean quips to be "the conspiracy theory" by us engineering skeptics and CIDR heretics) the "world" refuses to take any other hierarchical routing architectures seriously (and many are plausible and feasible if implemented, someone just kindly faxed me another one, BTW).
CIDR aggregation is a flawed paradigm for long term growth of the global infrastructure (and most of the engineers seem to roughly agree, IMO); yet we, as technologists, are driven by the forces of commerce to "expand the Internet as fast as possible, keep the growth curve high, grow, grow, grow" mantra; and accept that "we'll just have to be satisfied with band-aid, "change the wings in flight" engineering.
Hierarchical routeing is a flawed paradigm as well. CIDR is even more flawed, but it works at the moment. CIDR really only works if the block allocated are actually routed geographically. As a provider our primary Internet links outside of the UK are all the the USA. We, however, *have* to come to RIPE for "European" address space. When RIPE starts offering *free* routeing to the world using the top level CIDR blocks, then I will agree that CIDR works. I cannot accept that we have to >beg< RIPE like a good little provider for address space that should be allocated to us from the USA anyway. I will be interested to see how the RIPE actually works (and not just listening to Daniel dictate policy by e-mail) when I go to my first RIPE meeting next week. So far it seems like a bureaucracy that is entirely self perpetuating and self interested without consider what the people who pay for its very existance want. sigh. Just like an unelected government in fact. Back to the "technical" discussion: I think the hierarchical routeing is one step *worse* than the above. The address *defines* the route the packets take ? What about the real, live multi-interconnect, multi-homed Internet we use ? Maybe I have misunderstood the way IPv6 addressing works...
When this thead started, I was determined to stay on the sidelines, and avoid such a wide audience; but since I was mentioned directly in a reply, it seems appropriate to post a short clarifiation, thank your for understanding.
Hard to do, staying in the background when discussing quite emotive "religious" issues. Regards, -- Peter Galbavy peter@demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/
Peter Galbavy <peter@demon.net> writes: Hierarchical routeing is a flawed paradigm as well. CIDR is even more flawed, but it works at the moment.
Thanks for amitting at least that much ;-). Would you care to share your thoughts on less flawed paradigms that will work with current or near-future kit ({hard,firm,soft}ware for the non-british)?
CIDR really only works if the block allocated are actually routed geographically.
Yes, CIDR works if addresses are allocated *somewhat* topologically.
As a provider our primary Internet links outside of the UK are all the the USA. We, however, *have* to come to RIPE for "European" address space.
The continental component in address space allocation is pure policy and has little to do with CIDR. The policy only seems unreasonable when considering only the issue you raise. Personally I believe that even this issue is irrelevant for providers of the size of Demon. It makes no difference where you get a /16 from. The real issues here are ones of control and attribution of cost.
I cannot accept that we have to >beg< RIPE like a good little provider for address space that should be allocated to us from the USA anyway.
I know that you object against allocation and assignments policies we apply to you as to any other local registry (provider) we serve. Yet the particular policies you object to, are the ones set by IANA and applicable globally. You mistakenly assume that these policies would not be applied if you were dealing with the InterNIC.
I will be interested to see how the RIPE actually works (and not just listening to Daniel dictate policy by e-mail) when I go to my first RIPE meeting next week. So far it seems like a bureaucracy that is entirely self perpetuating and self interested without consider what the people who pay for its very existance want. sigh. Just like an unelected government in fact.
Thank you for the public ad hominem. :-(. I consider this bad style. I suggest you examine my personal track record more closely before repeating such attacks. RIPE is not a bureaucrazy. It is about as lightweight as an organisation can get. The RIPE NCC is also not a bureaucrazy. I can assure you that *everyone* here would rather do *any* of the other activities that we are supposed to do but registration services. Yet this job has to be done and done fairly. We also consider *very carefully* what the people that pay for our very existance want. We have well documented and working meachanisms for that. We have a contributors committee where each local registry in good standing (yourselves incluided) is represented which decides on our activites and charges. We have RIPE to direct our activities technically. All these processes are open and well documented. I am quite happy that you plan to get involved in these processes. What we do *not* do is consider *individual* interests of some over the ones of others. If we would do that we would eliminate our "raison d'etre". If you do not like the RIPE NCC model, consider the alternatives. You seem to be keen to have the US government set the policies. Or maybe you want governmental regulation closer to home?
I think the hierarchical routeing is one step *worse* than the above. The address *defines* the route the packets take ? What about the real, live multi-interconnect, multi-homed Internet we use ?
You have hit the nail on the head. There are conflicting goals here and engineering needs to be done.
Maybe I have misunderstood the way IPv6 addressing works...
No you have not. IPv6 routing basically is IPv4 routing with biger addresses. Read the archives for proposals like PIP enabling really interesting routing architectures and why they didn't make it. Daniel
Peter Galbavy <peter@demon.net> writes: Hierarchical routeing is a flawed paradigm as well. CIDR is even more flawed, but it works at the moment.
Thanks for amitting at least that much ;-). Would you care to share your thoughts on less flawed paradigms that will work with current or near-future kit ({hard,firm,soft}ware for the non-british)?
I wish I knew. In this I am the worst type of couch potato. I can identify the problem but I am very unlikely to provide the solution. Not in this case at least. I suspect it is because I have not spent enough time involed with the politics of the 'net as maybe I should have. This is much more of a political problem than a technical one. Just to spend a few minutes thinking about it, what do the phone companies do ? They are the nearest thing with a large installed base that the Internet even begins to map onto. There are however some fundemental differences - primarily the fragmentation of Europe (which is not the case in the US). We have a 2Mb line from London to Amsterdam which costs us very much the same as a T1 from London to Washington. As I understand it, this "milk them for all they are worth" pricing of the telcos applies to cross-border land lines in Europe also. All this impacts very severely on the commercial decisions taken as to the routeing of traffic. I would much rather buy more lines to the US and let the traffics flow back to Europe then to just buy lines to Europe. Luckily, commercial concerns are not the only contraints within which we have to work.
CIDR really only works if the block allocated are actually routed geographically.
Yes, CIDR works if addresses are allocated *somewhat* topologically.
And in the case of (I am guessing) > 70% of RIPE NCC allocated addresses are not. This is no ones "fault", just the way the policy is. Therefore I say the policy is WRONG.
As a provider our primary Internet links outside of the UK are all the the USA. We, however, *have* to come to RIPE for "European" address space.
The continental component in address space allocation is pure policy and has little to do with CIDR. The policy only seems unreasonable when considering only the issue you raise.
But it is the *primary* issue. What else is there that influences how addresses are allocated in a CIDR or hierarchical way ? Timezones ? We have e-mail for admin - it is timezone orthoganal. The existance of the RIPE NCC should just be remote, local staff for the InterNIC. If the RIPE NCC applies a "local model" then it is not conforming to the policies of IANA and the IAB that you keep referring to.
Personally I believe that even this issue is irrelevant for providers of the size of Demon. It makes no difference where you get a /16 from.
Except you will not, even with correct justifications, give us one for our dial up services. To wash some dirty laundry here, we as a provider have been trying to get new address space for our dial up customers from RIPE NCC for almost 6 months now. We allocate *each* dialup customer *1* IP address from a block and dynamically route them based on where they log in to the service (including RSN Amsterdam). The RIPE NCC has >effectively< refused us space because they believe that we should change the product we sell and use dynamic IP for dialups. We are the largest dialup ISP in Europe. We are not the largest provider in Europe because we follow the rest of the ISPs like sheep, buying Ciscos and installing off the shelf terminal servers. We provide a product which our customers understand gives them *more* for their money. We do something different, and the customers like it. Tough fact of business life that. Eventually, Daniel has very kindly allocated a /19 of space... which is vastly too small for our growth. We started using this space about 8 days ago and have used > 15% of it. Ouch. We are doubling in size between every 5 and 8 months. Within the guildlines for address allocation we can easily demonstrate filling a /16 in this sort of timescale. The RIPE NCC believes it can dicate the business model we use, which has been established for > 3.5 years. This is unlikely to happen. I will not discuss in a public forum the odd schemes that Daniel suggested for "verifying" our use of the address space. But they were odd. It is not the NCC's job to doubt us when we say we have filled the address space. Does the NCC go and visit ACME Ltd to see that it really has all the PCs and server before allocating some more address space ? Didn't think so.
The real issues here are ones of control and attribution of cost.
Yes. You collect the RIPE NCC contributions and remain in control. Simple. I am considering my personal view on making this not the case.
I cannot accept that we have to >beg< RIPE like a good little provider for address space that should be allocated to us from the USA anyway.
I know that you object against allocation and assignments policies we apply to you as to any other local registry (provider) we serve. Yet the particular policies you object to, are the ones set by IANA and applicable globally. You mistakenly assume that these policies would not be applied if you were dealing with the InterNIC.
Please read the policies again. You policy uses words like "strongly discouraged" for static IP allocation, not "disallowed". You have attempted to strongly discourage us, we have not been so discouraged, and now give up and give us the address space we are *entitled* to.
I will be interested to see how the RIPE actually works (and not just listening to Daniel dictate policy by e-mail) when I go to my first RIPE meeting next week. So far it seems like a bureaucracy that is entirely self perpetuating and self interested without consider what the people who pay for its very existance want. sigh. Just like an unelected government in fact.
Thank you for the public ad hominem. :-(. I consider this bad style. I suggest you examine my personal track record more closely before repeating such attacks.
But this is all I have seen you do, therefore, how can I but believe that this is the case. Every private mail that has been sent to us as a company involves you acting as God and us as the grovelling peasants praying for a benidication of address space. I have all these mails in my various folders, as do you.
RIPE is not a bureaucrazy. It is about as lightweight as an organisation can get.
I did not say it was a heavy bureaucrazy (sic), but a bureaucracy is nevertheless harmful if it prevents those members it purport to represent from doing.
The RIPE NCC is also not a bureaucrazy. I can assure you that *everyone* here would rather do *any* of the other activities that we are supposed to do but registration services. Yet this job has to be done and done fairly. We also consider *very carefully* what the people that pay for our very existance want. We have well documented and working meachanisms for that. We have a contributors committee where each local registry in good standing (yourselves incluided) is represented which decides on our activites and charges. We have RIPE to direct our activities technically. All these processes are open and well documented. I am quite happy that you plan to get involved in these processes.
I wish I had the time, but it appears that we will have to make the time to get more involed. sigh.
What we do *not* do is consider *individual* interests of some over the ones of others. If we would do that we would eliminate our "raison d'etre".
Why not. We are not a communist society are we ? Each individual member of RIPE have their own unique requirements in a commercial and academically challenging world. We have a USP (Unique Selling Point) of giving our paying customers there own IP address (OK - it is not unique, but close enough). We have built propretary technology that allows our users to use *any* of our dial in points and get the same service, with the same IP number etc etc, and as one of our primary USPs we cannot allow the RIPE NCC to try to change that.
If you do not like the RIPE NCC model, consider the alternatives. You seem to be keen to have the US government set the policies. Or maybe you want governmental regulation closer to home?
The RIPE NCC model probably would work if it took into account that fact that its members are (on the whole) commercial organisations that sell differing products and services and have different requirements of the NCC. This does not appear to be the case. Regards, -- Peter Galbavy peter@demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/
Peter Galbavy <peter@demon.net> writes:
Thanks for amitting at least that much ;-). Would you care to share your thoughts on less flawed paradigms that will work with current or near-future kit ({hard,firm,soft}ware for the non-british)?
I wish I knew. In this I am the worst type of couch potato. ....
So stop critising "paradigms" without proposing better ones or at least research the rationales and history behind them.
Yes, CIDR works if addresses are allocated *somewhat* topologically.
And in the case of (I am guessing) > 70% of RIPE NCC allocated addresses are not.
First you missed the emphasis on *somewhat*. Second you are guessing wrong.
From both of the above it seems that you only know of and are only concerned with your own particular situation.
This is no ones "fault", just the way the policy is. Therefore I say the policy is WRONG.
What is the better policy?
The continental component in address space allocation is pure policy and has little to do with CIDR. The policy only seems unreasonable when considering only the issue you raise.
But it is the *primary* issue. What else is there that influences how addresses are allocated in a CIDR or hierarchical way ?
More local topology than continental one is *very* important.
We have e-mail for admin - it is timezone orthoganal. The existance of the RIPE NCC should just be remote, local staff for the InterNIC.
Fine with me. Do RIEP and theother contributors agree? We can re-organise starting next week.
If the RIPE NCC applies a "local model" then it is not conforming to the policies of IANA and the IAB that you keep referring to.
The RIPE NCC applies local policies within the boundaries of the global policies.
Personally I believe that even this issue is irrelevant for providers of the size of Demon. It makes no difference where you get a /16 from.
Except you will not, even with correct justifications, give us one for our dial up services.
To wash some dirty laundry here ...
I could help you washing in detail but I do not think this is appropriate in all these fora. For the record I will summarise: Demon is statically assigning IP addresses to dialup customers on a large scale. This results in adresses being used per customer and not per dial-in port. Obviously then number of customers is less limited than that of dial in ports. There is concern about the wastefulness of this practise on a large scale and the non-linear effects it could have on address space usage. Hence it is *global*, read IANA, policy to strongly discourage this practise and not to allocate more addresses than three months worth of usage. This is not just an NCC policy! Indeed we have allocated you a /19 to start with in addition to the address space you have been allocated for other purposes than dial up IP. Of course you will receive further allocations within the range of the above policy whenever you need them. Of course we will do our best to make the further allocations aggregateable with previous ones. Assignments of address space by local IRs to customers have to be registered in the RIPE (whois) database. You have raised that your commercial interest of keeping your customer list confidential should outweigh this registration requirement in the case of individuals because of the special characterisitcs of the (consumer) market you operate in. We have recognised that the tradeoff between the benefit of registration and the commercial interests of individual dialup providers is indeed special and consequently have worked with you(!), IANA and the other regional registries to establish a global policy for this special case. This policy has to take into account the need for verification of assignments since the registration requirement has been dropped and the database is not available for verification. We have worked with you in this matter, you have agreed to the result. I think it is *very* inappropriate to publicly abuse those who have worked with you and to throw polemics at compromises some of which you have even suggested and all of which you have agreed to. I will leave the polemics for what they are.
I wish I had the time, but it appears that we will have to make the time to get more involed. sigh.
Yes, it is more appropriate than polemicising publicly.
What we do *not* do is consider *individual* interests of some over the ones of others. If we would do that we would eliminate our "raison d'etre".
Why not. We are not a communist society are we ? Each individual member of RIPE have their own unique requirements in a commercial and academically challenging world. We have a USP (Unique Selling Point) of giving our paying customers there own IP address (OK - it is not unique, but close enough). We have built propretary technology that allows our users to use *any* of our dial in points and get the same service, with the same IP number etc etc, and as one of our primary USPs we cannot allow the RIPE NCC to try to change that. ... The RIPE NCC model probably would work if it took into account that fact that its members are (on the whole) commercial organisations that sell differing products and services and have different requirements of the NCC. This does not appear to be the case.
You have received sufficient address space for your present needs and you have been assured that -unless there are policy changes- you will receive enough for your future needs. The same policy is applied to everyone. --- Polemic mode on ---- I have the slight suspicion that for you the only good model is one that does exactly what *you* want, everyone else be damned. --- Polemic mode off ---- Daniel
I wish I knew. In this I am the worst type of couch potato. ....
So stop critising "paradigms" without proposing better ones or at least research the rationales and history behind them.
OK OK. I am trying to make some form of contribution :) Give me a little time.
And in the case of (I am guessing) > 70% of RIPE NCC allocated addresses are not.
First you missed the emphasis on *somewhat*. Second you are guessing wrong.
OK. But for informational purposes is there a figure available ?
From both of the above it seems that you only know of and are only concerned with your own particular situation.
I would have to say, from reading my own e-mails that maybe I have given that impression. Let me reqind a bit and summarse it differently below... This should *not* have been the case.
This is no ones "fault", just the way the policy is. Therefore I say the policy is WRONG.
What is the better policy?
Maybe that is what this thread can begine... a discussion of a different/ better policy ? Who knows ?
More local topology than continental one is *very* important.
Yes. How can we help to make this happen ? Are there tools, that if we make sure our RIPE records are up to date that will help you in your allocations ? ISPs are not given the opportunity to apply for topological *and* portable address space (eg we are multihomed to the US - Sprint allocations are not "good enough") from the InterNIC - we are sent to the RIPE NCC because our physical location happens to be within a geographical domain managed by the RIPE NCC.
We have e-mail for admin - it is timezone orthoganal. The existance of the RIPE NCC should just be remote, local staff for the InterNIC.
Fine with me. Do RIEP and theother contributors agree? We can re-organise starting next week.
I am not sure I meant you to agree with me on this one... :-)
If the RIPE NCC applies a "local model" then it is not conforming to the policies of IANA and the IAB that you keep referring to.
The RIPE NCC applies local policies within the boundaries of the global policies.
The problem is that various people posting to this list change which set of policies they refer to whenever the "other" set suits better for their arguments. One set of goals please. Please.
I could help you washing in detail but I do not think this is appropriate in all these fora. For the record I will summarise:
Demon is statically assigning IP addresses to dialup customers on a large scale. This results in adresses being used per customer and not per dial-in port. Obviously then number of customers is less limited than that of dial in ports. There is concern about the wastefulness of this practise on a large scale and the non-linear effects it could have on address space usage. Hence it is *global*, read IANA, policy to strongly discourage this practise and not to allocate more addresses than three months worth of usage. This is not just an NCC policy!
In the way we assign numbers, it is very linear. Just not all the hosts are reachable all the time. We return ICMP Host Unreacable from our core routers when a dial up customer is not logged in. I will try to explain some of the reasons we do it this way below. But reasons do not change or infulence the current RIPE/IANA policies - which is the thing I am trying to highlight for "discussion". I am *NOT* trying (I know that it may look that way) to say that the RIPE NCC is full of people who don't care and are not doing "the right thing". This is patently untrue... Daniel et al are doing a very good job within their interpretation of (in my belief) an incorrect, incomplete frame work.
Indeed we have allocated you a /19 to start with in addition to the address space you have been allocated for other purposes than dial up IP. Of course you will receive further allocations within the range of the above policy whenever you need them. Of course we will do our best to make the further allocations aggregateable with previous ones.
The primary issue with this one is not that of not getting the address space, but of getting additional address space in a timely fashion. By the time I write this we would have taken on another 150 - 200 customers since Friday. That is almost one /24. This (at a guess for growth) gives us about 2 months for a /19. It takes too long (in the real world - with holidays, sickness etc) to apply for a new allocation only days or a week before this (or the next) block runs out. If we can apply for a /19 at least 30 days before we need it then this may solve the problem, but I do not think this would work within the current applications processing methods. Or would it ? I don't actually know at this point, since we have been very concerned at how long it took to get the last block.
Assignments of address space by local IRs to customers have to be registered in the RIPE (whois) database. You have raised that your commercial interest of keeping your customer list confidential should outweigh this registration requirement in the case of individuals because of the special characterisitcs of the (consumer) market you operate in. We have recognised that the tradeoff between the benefit of registration and the commercial interests of individual dialup providers is indeed special and consequently have worked with you(!), IANA and the other regional registries to establish a global policy for this special case. This policy has to take into account the need for verification of assignments since the registration requirement has been dropped and the database is not available for verification.
It is not (even) a commercial confidence interest, since I believe that the RIPE NCC could be trusted with this information, but one of *LAW*. The EEC (as it was then) quite correctly required the UK parliment to pass a law called the Data Protection Act in 1984. In my opinion this act is far *too* weak, but even in its current form does not allow us to pass these detais on, with a small number of exceptions.
We have worked with you in this matter, you have agreed to the result. I think it is *very* inappropriate to publicly abuse those who have worked with you and to throw polemics at compromises some of which you have even suggested and all of which you have agreed to. I will leave the polemics for what they are.
OK. OK. I will publicly apologise for any offense I may have given to the *people* involved. You have worked very hard trying to be fair. I just do not think that the underlying policies from which this fairness is drawn is correct for all situations. I will not apologies for critising policies that I believe to be flawed or the organisations that blindly implement them. I *do* believe that people run these organisations and that the policies should allow these people to behave like human beings and make judgements based on experience rather than a fixed, immutable set of criteria.
I wish I had the time, but it appears that we will have to make the time to get more involed. sigh.
Yes, it is more appropriate than polemicising publicly.
I am here now in Amsterdam at the RIPE meeting, I am happy to try to make a contribution.
The RIPE NCC model probably would work if it took into account that fact that its members are (on the whole) commercial organisations that sell differing products and services and have different requirements of the NCC. This does not appear to be the case.
You have received sufficient address space for your present needs and you have been assured that -unless there are policy changes- you will receive enough for your future needs. The same policy is applied to everyone.
--- Polemic mode on ----
I have the slight suspicion that for you the only good model is one that does exactly what *you* want, everyone else be damned.
--- Polemic mode off ----
Nope. I am always open to critisism and people pointing out me errors. I do not think that the only policy that would work is the one that would fit my situation, but owing to a lack of involment in the "politics" of the Internet in the past 24 months or so (how long I have been in the serice provider game officially) those policies have happened without me seeing them, and so the bits that could make it all work for me/us have been either missed or overlooked. For a bit of background on why Demon use static IP allocation, and how, for those who are interested as opposed to just being opposed... When the service started (and I was just a customers) there was *NO* other reasonably priced IP service for individuals / small companies in the UK. Anyone want to disagree ? Right... Demon were set up to provide and Internet *service* not *access*. Please note my terminology on this one; Internet Service: Being a real host, providing full SMTP capabilities (ie mail transport, not mail access), fixed/unique FQDN, in effect being a full Internet site when connected. Internet Access: Getting access to WWW/POP3 etc, "using" the Internet to get information through search engines, e-mail stored in a mailbox etc etc. Being a Web surfer tupe consumer. It is difficult to enumerate the difference to well, but I think most people who have thought about it could. Some people also think of it exactly the other way around. We now have very close to 60000 dialup customers, each with their own FQDN and IP address. So far this "just" overflows a class B, once we include all all the other bits of equipment and the slightly sparse address space in the "secure" /24 subnets. Thre are a number benefits of static IP, just as there are disadvantages. We use a proprietary dynamic routeing protcol, which has been worked on very heavily over the years to provide (effectivley) invisible routeing changes when customer log in to the lines. The disadantages are the point of this discussion. I know a number of customers who use the IP addresses of the dialups for security and filtering (do that with a dynamic IP address). Another one (not so often used, but damned useful) is the ability to continue TCP sessions between disconnets (many a large FTP saved my this). There are others, but this e-mail is long enough already. This is a religious argument that I do not believe has any *real* impact on address space allocation except for a cosmetic one. So what if we gave almost every PC/Mac/UNIXen box in the world an IP address. Even in IPv4 space there are plenty for the coming years. IPv6 may be adopted for real in a few years, and by then it all changes anyhow. *ANOTHER* important one, but much more unlikely, is that we may one day (and pigs will grow wings and fly) offer all our customers a *permanent* connection to the 'net - what then ? The telecoms technology allows for it - it is just down to tariffing. Just a thought. Again - I have not inteded any of this as an attack on the dedication of the RIPE NCC staff, I just get carried away (I think I am human after all), Anyway, enough of this, I need to do some "work" here - I left my colleagues at RIPE while I cam to our offices to try to catch up with e-mail... Regards, -- Peter Galbavy peter@demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/
On Mon, 29 Jan 1996, Peter Galbavy wrote:
ISPs are not given the opportunity to apply for topological *and* portable address space (eg we are multihomed to the US - Sprint allocations are not "good enough") from the InterNIC - we are sent to the RIPE NCC because our physical location happens to be within a geographical domain managed by the RIPE NCC.
You are the biggest ISP in Europe aren't you? How big? Couldn't you spend a few quid on incorporating Demon Internet Services Inc. in the USA? Wouldn't you then be eligible for IP addresses from the US Internic?
Demon is statically assigning IP addresses to dialup customers on a large scale. This results in adresses being used per customer and not per dial-in port. Obviously then number of customers is less limited than that of dial in ports. There is concern about the wastefulness of this practise on a large scale and the non-linear effects it could have on address space usage. Hence it is *global*, read IANA, policy to strongly discourage this practise and not to allocate more addresses than three months worth of usage. This is not just an NCC policy!
In the way we assign numbers, it is very linear. Just not all the hosts are reachable all the time. We return ICMP Host Unreacable from our core routers when a dial up customer is not logged in. I will try to explain
In a classless IPV4 world in which the old Class A address area is in production use, would we have enough available IP addresses for providers to do this on a large scale assuming that they would have near 100% utilization in the blocks that were being allocated statically? Didn't the experiment with 39/8 show that it was safe to allocate classlessly out of the old Class A addresses? Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael@memra.com
You are the biggest ISP in Europe aren't you? How big? Couldn't you spend a few quid on incorporating Demon Internet Services Inc. in the USA? Wouldn't you then be eligible for IP addresses from the US Internic?
This has been consdidered I understand... but we want to play the game and make the rules better, not cheat :-)
In a classless IPV4 world in which the old Class A address area is in production use, would we have enough available IP addresses for providers to do this on a large scale assuming that they would have near 100% utilization in the blocks that were being allocated statically?
Didn't the experiment with 39/8 show that it was safe to allocate classlessly out of the old Class A addresses?
I think so and yes :-) Regards, -- Peter Galbavy peter@demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/
I cannot accept that we have to >beg< RIPE like a good little provider for address space that should be allocated to us from the USA anyway. I will be interested to see how the RIPE actually works (and not just listening to Daniel dictate policy by e-mail) when I go to my first RIPE meeting next week. So far it seems like a bureaucracy that is entirely self perpetuating and self interested without consider what the people who pay for its very existance want. sigh. Just like an unelected government in fact.
As you imply, Peter, you haven't been to a RIPE meeting yet. At RIPE 23 next week, you'll get to meet the "bureaucracy" - they're not of the 'faceless' variety ;-) - and lots of the members of RIPE. You'll also see how RIPE and its groups work, always by consensus within the membership, with expert guidance from all over Europe and the wider Internet, and with concern for the maintenance and growth of IP networking everywhere. Despite the weather forecast, I'm sure you'll warm to RIPE, its members and even its "bureaucracy", and perhaps revise your opinion in the light of an enjoyable experience. Looking forward to meeting you in Amsterdam. Mike Norris
Despite the weather forecast, I'm sure you'll warm to RIPE, its members and even its "bureaucracy", and perhaps revise your opinion in the light of an enjoyable experience.
Looking forward to meeting you in Amsterdam.
Me too. See you all there... -- Peter Galbavy peter@demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/
Sure, there is no filtering in 193/8 and 194/8, and as a result we have VERY poor aggregation.
Get used to it. This is the Internet. People will not always do what _you_ want.
Consider this random cut-and-paste from 194/8.
* 194.19.36.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.37.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.40.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.54.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.55.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.60.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i
Putting in a filter on 195.0.0.0/8 that will permit ONLY /18s and shorter prefixes is the only means I can see at this time that will make this kind of b.s. impossible.
Yes. And of course you don't care about a small side-effect: it will drive small ISP's out of business. The only way to avoid that is to do business with large ISP's such as Sprint. There are many legitimate reasons why people may announce very long prefixes. I don't see a problem with that, as long as people aren't announcing more routes than they have to. So in stead of picking on people smaller than you, go after the types that accounce 50+ routes per AS. That's the _real_ problem! Iljitsch van Beijnum bART Internet Services
Sean, If you insist on prefix-length filtering I have proposed a soloution for future address space allocated via the RIPE NCC several times: - set your inbound prefix length filter to /19. - The RIPE NCC will *guarantee* that we will not make more than 1024 non-aggregateable allocations from each /8. - The RIPE NCC will continue to work with the providers to maximise aggregation. Our goal is a maximum of 1024 routes per /8 visible at major exchange points. Incidentally this is the same goal that you seem to have. - Should we fall to short of the goal in your opinion, you can start to filter on the list of allocations which is available from our whois database (whois -h whois.ripe.net -m 19x/8). Note that we guarantee that these will be no more than 1024. Now given the current performance of everyone I personally believe that we deserve a little relief from the 1024 goal but I am willing to discuss on the basis above. Can we please enter into a discussion why this is a bad idea and/or why it is not acceptable to you personally or your employer. Daniel Detailed comments follow (can be skipped by people intersted in the real issues).
Sean Doran <smd@sprint.net> writes:
The same ISP has said publicly that they will route /19 prefixes in our address space: 193/8 and 194/8. The discussion is still going over future /8s. But read the last paragraph of the policy statement!
Sure, there is no filtering in 193/8 and 194/8, and as a result we have VERY poor aggregation.
Consider this random cut-and-paste from 194/8. ...
You conveniently ignored the stats in my message. I repeat them here sorted by "hosts addressed/route". You will note that 193/8 and 194/8 have anything but "VERY poor" aggregation. They are both within a factor 2 of your goal of 1024 routes. Routing Table router: amsterdam.ripe.net time: Mon Jan 22 11:06:13 1996 Destinations: 32934 Routes: 32934 /8 block hosts routes hosts addres- / sed route 207.0.0.0 1019136 37 27544 203.0.0.0 5831424 780 7476 200.0.0.0 4660736 697 6686 206.0.0.0 10967808 1649 6651 193.0.0.0 9264640 2019 4588 194.0.0.0 7665920 1849 4145 205.0.0.0 6019584 1793 3357 202.0.0.0 4258496 1460 2916 204.0.0.0 10499072 3660 2868 199.0.0.0 8838144 3338 2647 196.0.0.0 731648 329 2223 198.0.0.0 7488000 3705 2021 192.0.0.0 4981504 6551 760 201.0.0.0 256 1 256 197.0.0.0 256 1 256 195.0.0.0 256 1 256 C Space 82226880 27870 2950
Putting in a filter on 195.0.0.0/8 that will permit ONLY /18s and shorter prefixes is the only means I can see at this time that will make this kind of b.s. impossible.
You should be careful calling things b.s. before checking why they are done.
Indeed, if I put inbound filters on these announcements (and many other similar examples in 194/8) today, I would bet that within two days, everything that can be aggregated above, in Europe and by AlterNet, would be aggregated.
Here we disagree about how to achieve goals. I tend to favour compromise/consensus achieved by discussion to unilateral action.
If you have some technical means by which you can guarantee that no future allocations will result in rafts of unaggregated addresses like the random chunk cut and pasted above, then I would like to know about it.
I have told you before that as regional registry I have absolutely no control about routing policies of any provider whatsoever. I can only try to have influence and, again, I think we are doing quite well compared to others.
I wonder where that rumour comes from. It is certainly not the RIPE NCC allocation policy. this is a good time to set the record straight on this and related things. This is *not* an attack on Tony who, I am sure, was quoting some rumour in good faith.
Yah, yah, Daniel, it's a giant conspiracy against you and Tim Bass.
I guess we have a language communications problem here. What is wrong with someone authoritative about something to say what it is.
1) The initial allocation for a newly established local registry (ISP) *always* is a /19. There will be no discussion about this. This is fixed, cast in stone, immutable, ... you get the idea.
Ah, so Mr "we need to find compromises" of the last message when referring to me not being willing to abandon the goal of an absolute maximum of 1024 prefixes only (and hopefully far fewer) in every /8 remaining in the old-style class C space is not so flexible as he wants me to be?
You should have read further: (NB: The value of /19 might change at some point, but the fact that every newly established registry gets *the same size* initial allocation will not.) I am getting the impression that you are not really listening. What I was saying is that "everyone gets the *same* *initial* allocation" was something I am not willing to compromise on. If you had to sift through all the bullsit (marketing predictions, solicitor's letters, hurt egos, diplomatic notes(!) ...) which any other policy generates or (beware) to pay someone to handle those, I am sure you would agree.
Not that I care; I'm not prone to compromise myself, frankly.
Good that you say so, I didn't notice ;-).
Yup. And when you make the /19 allocations, you should tell them that in 195/8, if they are announcing a /19, a /20, a /21, a /22, a /23 or a /24, that will not work if they want to talk to SprintLink via a non-customer path.
If you care to read ripe-127 and the policy statement which caused this whole discussion you will notice that this is being done in no uncertain but less Sprint centric terms. This does not prevent me from arguing with you about better soloutions.
If not, well, I have this neat archive of plenty of warnings I've posted on several lists, and I work with a team of good people in program management, marketing, media relations and legal who went through this in a rather more controversial atmosphere when the filters on 206/8+ went in place, cutting off people who previously had gotten accidental connectivity using long prefixes.
Fine and I have this neat archive of warnings I put out too including the documents cited above. Now can we try to make things work rather than point fingers!
Well, you're the registry. I can only tell you the consequences, and that I won't lift a finger to make exceptions when people start whining, "but RIPE didn't TELL me it wouldn't work!".
They would be dead wrong.
I don't disagree that historically RIPE's allocation policy has been *excellent*. However, there are two problems: firstly, it is insufficient in and of itself to prevent things like the stuff above, and secondly there is a disconnect between allocations and announcements.
About which I have no *control* but some influence. See the proposal above.
So, let's kill two birds at once: first, an enforcement mechanism to push people into announcing only one prefix per allocation, and second, increase the size of the initial allocation, which will tend to push people away from RIPE as the registry of first choice.
I'm sorry if that hurts your income, RIPE.
We have no problem with that. Any way to reduce the work we have to spend on registration services is welcome. ;-). However what you are asking is for us to make and enforce policies that favour a certain type of provider more than technically necessary. This we will not do. If one of these providers chooses to cut itself and its customers off from some parts of the Internet that is fine. Daniel
Daniel,
If you insist on prefix-length filtering I have proposed a soloution for future address space allocated via the RIPE NCC several times:
- set your inbound prefix length filter to /19.
- The RIPE NCC will *guarantee* that we will not make more than 1024 non-aggregateable allocations from each /8.
Would the RIPE NCC provide such non-aggregatable allocations irrespective of how many hosts would be covered by such an allocation ? Yakov.
Yakov Rekhter <yakov@cisco.com> writes:
- The RIPE NCC will *guarantee* that we will not make more than 1024 non-aggregateable allocations from each /8.
Would the RIPE NCC provide such non-aggregatable allocations irrespective of how many hosts would be covered by such an allocation ?
Sorry, lack of clarity because of failing neurons. What I meant to say was "1024 CIDRable allocations". Or simply "allocations". The point is that we will guarantee that our allocation policy will create no more than 1024 allocations per /8 and therefore not necessitate by itself more routes than that. Currently our allocation sizes are /19 - /16. If you think about it a little you will see that it is easy to achieve. And just in case: Yes the minimum allocation is /19 irrespective of the number of hosts covered. Note: allocation != assignment. Daniel
Daniel,
Would the RIPE NCC provide such non-aggregatable allocations irrespective of how many hosts would be covered by such an allocation ?
Sorry, lack of clarity because of failing neurons. What I meant to say was "1024 CIDRable allocations". Or simply "allocations".
The point is that we will guarantee that our allocation policy will create no more than 1024 allocations per /8 and therefore not necessitate by itself more routes than that. Currently our allocation sizes are /19 - /16. If you think about it a little you will see that it is easy to achieve.
And just in case: Yes the minimum allocation is /19 irrespective of the number of hosts covered. Note: allocation != assignment.
OK, so just to make it clear, if a customer would come to the RIPE NCC and the customer has just 1 host you would still allocated him /19 block. Correct ? Yakov.
Daniel Karrenberg <Daniel.Karrenberg@ripe.net> wrote:
If you insist on prefix-length filtering I have proposed a soloution for future address space allocated via the RIPE NCC several times:
- set your inbound prefix length filter to /19.
- The RIPE NCC will *guarantee* that we will not make more than 1024 non-aggregateable allocations from each /8.
- The RIPE NCC will continue to work with the providers to maximise aggregation. Our goal is a maximum of 1024 routes per /8 visible at major exchange points. Incidentally this is the same goal that you seem to have.
You are not distinguishing (initial) allocation from announcement. Your guarantee is worthless in the sense that it only gurantees that the announcements (as opposed to allocations) can be aggregated if each window allocation is tied to a single AS, and thus, for instance that none of the allocation is for PI space, or for allocation to customers who aren't local-IRs but have their own AS etc. etc. You also have the problem that currently it is impossible for local-IRs to allocate blocks of IP numbers that wouldn't be filtered out to multihomed customers (with their own AS - thus almost inevitably requiring a separate announcement) where that customer under the RIPE rules isn't 'justified' in getting a /19 (too small, for instance). Conservation vs. aggregation again. What is your recommendation on this? Alex Bligh Xara Networks PS: Here's Sprint's sister company's current announcement of routes *originating* in its AS as I see them - I do hope Sprint takes the honest path if it does refuse to carry short announcements and not route all bar 4 of these nets, as well as a similar long list from AS1239 :-) I'm not convinced Sprint has the moral highground here.... Network Next Hop Metric LocPrf Weight Path *> 160.214.0.0 194.68.130.50 0 4000 ? *> 163.164.0.0 194.68.130.50 0 4000 ? *> 194.41.63.0 194.68.130.50 0 4000 ? *> 194.106.0.0/19 194.68.130.50 0 4000 ? *> 194.106.32.0 194.68.130.50 0 4000 ? *> 194.106.33.0 194.68.130.50 0 4000 ? *> 194.106.34.0 194.68.130.50 0 4000 ? *> 194.126.64.0/19 194.68.130.50 0 4000 ? *> 194.133.0.0/19 194.68.130.50 0 4000 i *> 194.133.4.0/23 194.68.130.50 0 4000 ? *> 194.133.6.0 194.68.130.50 0 4000 ? *> 194.133.7.0 194.68.130.50 0 4000 ? *> 194.133.8.0 194.68.130.50 0 4000 ? *> 194.133.15.0 194.68.130.50 0 4000 ? *> 194.133.24.0 194.68.130.50 0 4000 ? *> 194.133.28.0 194.68.130.50 0 4000 ? *> 194.140.128.0/19 194.68.130.50 0 4000 ? *> 194.140.224.0/21 194.68.130.50 0 4000 ? *> 194.149.192.0/18 194.68.130.50 0 4000 ? *> 194.158.0.0/20 194.68.130.50 0 4000 ? *> 194.176.96.0/19 194.68.130.50 0 4000 ? *> 194.204.96.0/23 194.68.130.50 0 4000 ? *> 196.27.0.0 194.68.130.50 0 4000 ? *> 196.27.1.0 194.68.130.50 0 4000 ? *> 198.169.26.0 194.68.130.50 0 4000 ? *> 204.59.0.0/16 194.68.130.50 0 4000 i *> 204.83.37.0 194.68.130.50 0 4000 ? *> 204.83.237.0 194.68.130.50 0 4000 ? *> 204.83.254.0 194.68.130.50 0 4000 ? *> 206.49.64.0/18 194.68.130.50 0 4000 i *> 206.49.65.0 194.68.130.50 0 4000 ?
"Alex.Bligh" <amb@Xara.NET> writes:
You are not distinguishing (initial) allocation from announcement.
Correct. This is because it is *only* the allocation that a regional registry has *control* over. After that we can only have *influence*.
Your guarantee is worthless in the sense that it only gurantees that the announcements (as opposed to allocations) can be aggregated if each window allocation is tied to a single AS,
I wouldn't call that worthless exactly, because the method has shown some successes.
and thus, for instance that none of the allocation is for PI space
I do not care about PI space. Those wanting it have had ample warning.
or for allocation to customers who aren't local-IRs but have their own AS etc. etc.
There you are! Cases of genuine need for a seperate announcement (multihomed) are not covered by the guarantee. But my expectation is that their number can be offset by bigger aggregates. Note that the number of routes *currently* announced under 193/8 and 194/8, which have some room for improvement, is quite low already. Actually they are both within the theoretical limit of a /18 filter which is 2047 routes.
You also have the problem that currently it is impossible for local-IRs to allocate blocks of IP numbers that wouldn't be filtered out to multihomed customers (with their own AS - thus almost inevitably requiring a separate announcement) where that customer under the RIPE rules isn't 'justified' in getting a /19 (too small, for instance). Conservation vs. aggregation again. What is your recommendation on this?
I fully agree that this is a problem. I believe that the only real solution to this is to reduce *unneeded* announcements as much as possible. This needs a routing registry and tools. This is why pure prefix length filtering is the wrong soloution. It just favours the big providers. The argument I am having with Sean is just part of this whole area: He says: "Change your allocation policy to match my routing policy." IANA says: "Registries shall not make allocations/assignments based on (individual) ISP's routing policies." (With which I fully agree) I say: "Change your routing policy very slightly such that it remains compatible with my allocation policy." This bartering does not solve the general problem and does not claim to. It is just part of the effort to keep things working. Daniel
Daniel Karrenberg <Daniel.Karrenberg@ripe.net> wrote:
"Alex.Bligh" <amb@Xara.NET> writes:
You are not distinguishing (initial) allocation from announcement.
Correct. This is because it is *only* the allocation that a regional registry has *control* over. After that we can only have *influence*.
Your guarantee is worthless in the sense that it only gurantees that the announcements (as opposed to allocations) can be aggregated if each window allocation is tied to a single AS,
I wouldn't call that worthless exactly, because the method has shown some successes.
and thus, for instance that none of the allocation is for PI space
I do not care about PI space. Those wanting it have had ample warning.
Neither do I.
or for allocation to customers who aren't local-IRs but have their own AS etc. etc.
There you are! Cases of genuine need for a seperate announcement (multihomed) are not covered by the guarantee. But my expectation is that their number can be offset by bigger aggregates. Note that the number of routes *currently* announced under 193/8 and 194/8, which have some room for improvement, is quite low already. Actually they are both within the theoretical limit of a /18 filter which is 2047 routes.
You also have the problem that currently it is impossible for local-IRs to allocate blocks of IP numbers that wouldn't be filtered out to multihomed customers (with their own AS - thus almost inevitably requiring a separate announcement) where that customer under the RIPE rules isn't 'justified' in getting a /19 (too small, for instance). Conservation vs. aggregation again. What is your recommendation on this?
I fully agree that this is a problem. I believe that the only real solution to this is to reduce *unneeded* announcements as much as possible. This needs a routing registry and tools.
OK, point taken. But AFAIK RIPE *still* works against this goal by giving only one window. Case in point: Our current window is /19, and all our announcements are maximally aggregated. Jo Customer comes along to me and says 'I want to go multihomed with you as a second provider, currently I have 8 class C's but they are all spread about the place'. Me 'You need to renumber then esp. as your class C's are within your current providers aggregate announcments (even though they are old, and thus technically PI' (there, that's me doing my bit for aggregation). Them: 'OK, give us a /21 to renumber into, you are a local-IR and we aren't'. Currently I have 2 choices as far as I can make out, give them a bit of my /19, break up my nice aggregate and ensure loads of extra announcements (and that probably none of them get routed by anyone applying prefix based filtering), or give them a new /19 all of their own (you've said it, that's the minimum size allocation) which actually solves their problem and mine, but this isn't an option currently available because currently it's one window per local-IR. So they have to go and become a local IR.
This is why pure prefix length filtering is the wrong soloution. It just favours the big providers.
Yup, I'd agree with us. And I hope Sprint have had a long chat with their lawyers over there as some of the more litigious smaller US providers are busy thumbing through the anti-trust laws, apparently.
...
This bartering does not solve the general problem and does not claim to. It is just part of the effort to keep things working.
Yup. Alex Bligh Xara Networks.
to me and says 'I want to go multihomed with you as a second provider, currently I have 8 class C's but they are all spread about the place'. Me 'You need to renumber then esp. as your class C's are within your current providers aggregate announcments (even though they are old, and thus technically PI' (there, that's me doing my bit for aggregation). Them: 'OK, give us a /21 to renumber into, you are a local-IR and we aren't'. Currently I have 2 choices as far as I can make out, give them a bit of my /19, break up my nice aggregate and ensure loads of extra announcements (and that probably none of them get routed by anyone applying prefix based filtering), or give them a new /19 all of their own (you've said it, that's the minimum size allocation) which actually solves their problem and mine, but this isn't an option currently available because currently it's one window per local-IR. So they have to go and become a local IR.
No they don't. You can ask the RIPE NCC for special PI space to assign to this customer. It seems they have a "chemical waste dump" to satisfy this kind of requests from.
Iljitsch van Beijnum <iljitsch@unix1.bart.nl> wrote:
No they don't. You can ask the RIPE NCC for special PI space to assign to this customer. It seems they have a "chemical waste dump" to satisfy this kind of requests from.
Ah. That will be the "chemical waste dump" that Daniel K said he didn't care about whether it got routed or not (no offence Daniel - neither do I), and is all but unaggregatable so presumably Sprintlink et al. won't want to waste their CPUs routing it as well. What hope for a customer with those IP numbers? Alex Bligh Xara Networks
No they don't. You can ask the RIPE NCC for special PI space to assign to this customer. It seems they have a "chemical waste dump" to satisfy this kind of requests from.
Ah. That will be the "chemical waste dump" that Daniel K said he didn't care about whether it got routed or not (no offence Daniel - neither do I), and is all but unaggregatable so presumably Sprintlink et al. won't want to waste their CPUs routing it as well.
Well that's their policy, so it's their problem. As an ISP selling "global Internet connectivity" I may choose to take that policy into consideration, but I'm sure most people don't give a damn. (This is starting to get more and more like FidoNet...)
What hope for a customer with those IP numbers?
The anti-trust laws. ;-) Iljitsch
On Mon, 29 Jan 1996, Alex.Bligh wrote:
Ah. That will be the "chemical waste dump" that Daniel K said he didn't care about whether it got routed or not (no offence Daniel - neither do I), and is all but unaggregatable so presumably Sprintlink et al. won't want to waste their CPUs routing it as well. What hope for a customer with those IP numbers?
They all pay somebody (NSP X) for the following service. NSP X announces an aggregate route, ???/8 or whatever, which Sprint and others *WILL* listen to. Then, NSP X reroutes traffic to all those different customers within it's own network. If NSP X needs to route through another NSP for some reason, then NSP X uses an IP tunnel to encapsulate the swampy address. Of course, this may cost more than the swamp customers want to pay, or the swamp customers may not be able to agree enough to create a globally routable aggregate. In that case, they don't get routed. Hopefully they can be convinced to renumber and release the swamp addresses, thus filling in the swamp and allowing somebody to build a nice parking lot, mall and attached apartment buildings. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael@memra.com
On Mon, 29 Jan 1996, Alex.Bligh wrote:
Ah. That will be the "chemical waste dump" that Daniel K said he didn't care about whether it got routed or not (no offence Daniel - neither do I), and is all but unaggregatable so presumably Sprintlink et al. won't want to waste their CPUs routing it as well. What hope for a customer with those IP numbers?
They all pay somebody (NSP X) for the following service.
NSP X announces an aggregate route, ???/8 or whatever, which Sprint and others *WILL* listen to. Then, NSP X reroutes traffic to all those different customers within it's own network. If NSP X needs to route through another NSP for some reason, then NSP X uses an IP tunnel to encapsulate the swampy address.
This is not beautiful but would work but...
Of course, this may cost more than the swamp customers want to pay, or the swamp customers may not be able to agree enough to create a globally routable aggregate. In that case, they don't get routed. Hopefully they can be convinced to renumber and release the swamp addresses, thus filling in the swamp and allowing somebody to build a nice parking lot, mall and attached apartment buildings.
I obviously didn't quote enough at the top of the message. The point was tht the potential swamp user wants PI addresses so he can get a more resilient connection and go multihomed, which was the very reason why they were thinking about the swamp at all (rather than renumbering into my easilly routable PA space). Your solution is fine for obstinate people who don't want to renumber, but the guys I'm concerned with have a good reason for a short announcement (i.e. they want more resilience). Now I suppose 2 NSPs could announce ???/8 and aggregate those, and reroute them, however they would have to be the same 2 NSPs. Also we're back to the geographic issue on this one, in that its quite likely that the tunnel of which you talk would go back from mainland Europe, Stateside, and back to me in the UK, i.e. instead of one transatlantic hop you get 3. I'd love to hear any solution where they can renumber *within existing rules* (remember they aren't a local-IR and can't justify a /19), use AS based announcement (they have a very good reason for doing this), and get routed. Alex Bligh Xara Networks
In message <199601291642.QAA09648@diamond.xara.net>, "Alex.Bligh" writes:
Iljitsch van Beijnum <iljitsch@unix1.bart.nl> wrote:
No they don't. You can ask the RIPE NCC for special PI space to assign to this customer. It seems they have a "chemical waste dump" to satisfy this kind of requests from.
Ah. That will be the "chemical waste dump" that Daniel K said he didn't care about whether it got routed or not (no offence Daniel - neither do I), and is all but unaggregatable so presumably Sprintlink et al. won't want to waste their CPUs routing it as well. What hope for a customer with those IP numbers?
Alex Bligh Xara Networks
Alex, Here's my suggestion. If you put that multi-homed customer in a larger aggregate (have them pick one of the providers and allocate from their address space) all of the providers must then announce the more specific. Some providers will block the longer prefix. The longer prefix will be preferred and traffic will avoid going through those providers that block it. This might cause longer or suboptimal routing for the longer prefix. Providers everywhere will have either the shorter prefix or both, so full connectivity would exist. If the multi-homing is sufficiently localized within the topology (for example, multiple providers in the same region or country) there might be a chance to draw an aggregation boundary around the whole thing and block the longer prefix outside of that locality and avoid the possibility of suboptimal routing due to long prefix filtering. Curtis
......... Alex.Bligh is rumored to have said: ] > No they don't. You can ask the RIPE NCC for special PI space to assign to ] > this customer. It seems they have a "chemical waste dump" to satisfy ] > this kind of requests from. ] Ah. That will be the "chemical waste dump" that Daniel K said ] he didn't care about whether it got routed or not (no offence ] Daniel - neither do I), and is all but unaggregatable so presumably ] Sprintlink et al. won't want to waste their CPUs routing it as well. ] What hope for a customer with those IP numbers? Learn how to renumber. It really is possible, you know. -alan
participants (11)
-
Alan Hannan -
Alex.Bligh -
Curtis Villamizar -
Daniel Karrenberg -
Iljitsch van Beijnum -
Michael Dillon -
Mike Norris -
Peter Galbavy -
Sean Doran -
Tim Bass -
Yakov Rekhter