200 customer requirements for IPv6
Following up on the discussion during RIPE-51, I have not heard much discussion on "200 customer requirement for IPv6" rule. So I would like to hear your views on this. During RIPE-51 the proposal to remove the rule caught serious objections. I can sympathise with those but I do have an issue that I'd like feedback on. I am investigating how NATO should acquire IPv6 address space. NATO will use multiple transmission providers, NATO owned transmission and national networks. Also transmission contracts will have to be opened for bidding every few years. That makes requesting IP space from an ISP a non starter. So we explore the LIR route. Note that NATO has a service provider under its umbrella that provides service towards the other NATO organisations. They operate independently and are like an ISP (and more) for that matter. They are just not selling outside NATO. At this time it is reasonably hard to specify the 200 /48 that will be given out for the "IPv6 Initial Allocation Request". Having reached about 130 or so on my list (not finished yet) I can't help wondering why RIPE-NCC should care about a list of sites that they only a vague clue of what they are and have no means of verification if the list is correct. Having said that, I get the feeling that the 200 rule only ads admin overhead and has limited actual power. Now NATO could include a summarised version in the Initial Allocation and do something like: Subnet: /48 1 year 5 regional sites (/48 per site = 5x /48) Subnet: /48 1 year 20 subordinate sites to the 5 regional sites (/48 per site = 5x 20x /48 = 100 /48) Subnet: /48 2 year 40 deployed elements (/48 per site = 40x /48) Subnet: /48 2 year 70 Crisis Response Operation locations (/48 per location = 70 x /48) Total: 215x /48 Note that the numbers are fiction but they are not very unrealistic as we also need to include standby elements that are ready to go (power up, aim dish and run) systems. Although close to the truth, RIPE-NCC would have no way of verifying this and providing a detailed list would bury RIPE-NCC in details that they don't care about and also cannot verify. I can't help feeling this rule is written for ISPs but will be counter productive for NATO and organisations with a very large privately operated enterprice network. I also can't help the feeling that its a paper tiger. So isn't there another way to achieve the same result as this rule was intended for? Any views? Marc -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm@nc3a.nato.int (PGP capable)
Marc van Selm wrote: <SNIPS throughout the doc>
I am investigating how NATO should acquire IPv6 address space. NATO will use multiple transmission providers, NATO owned transmission and national networks. Also transmission contracts will have to be opened for bidding every few years. That makes requesting IP space from an ISP a non starter. So we explore the LIR route. Note that NATO has a service provider under its umbrella that provides service towards the other NATO organisations.
This is already good enough. Because the "ISP" is providing connectivity to the other NATO organisations. Done.
At this time it is reasonably hard to specify the 200 /48 that will be given out for the "IPv6 Initial Allocation Request".
The 200 is a *PLAN*. Also, if you have 200 employees and every one is going to connect to your network, then they need 200 /48's. As they are endsites connecting using a VPN tool and these endsites might just have more than 1 device in their network which need to access your site over the VPN.
Having reached about 130 or so on my list (not finished yet) I can't help wondering why RIPE-NCC should care about a list of sites that they only a vague clue of what they are and have no means of verification if the list is correct.
They don't care. Having said that, I get the
feeling that the 200 rule only ads admin overhead and has limited actual power. Now NATO could include a summarised version in the Initial Allocation and do something like:
Subnet: /48 1 year 5 regional sites (/48 per site = 5x /48) Subnet: /48 1 year 20 subordinate sites to the 5 regional sites (/48 per site = 5x 20x /48 = 100 /48) Subnet: /48 2 year 40 deployed elements (/48 per site = 40x /48) Subnet: /48 2 year 70 Crisis Response Operation locations (/48 per location = 70 x /48) Total: 215x /48
That is PERFECT.
I can't help feeling this rule is written for ISPs but will be counter productive for NATO and organisations with a very large privately operated enterprice network.
The 200 rule is there to make sure that there will be no entity that is going to request a /32, while they will never even use even a single /48 of hosts. So: Become LIR, pay the fees, fill in the forms and request that /32. Greets, Jeroen
At 16:15 17/11/2005, Marc van Selm wrote: [NATO scenario]
I can't help feeling this rule is written for ISPs but will be counter productive for NATO and organisations with a very large privately operated enterprice network. I also can't help the feeling that its a paper tiger. So isn't there another way to achieve the same result as this rule was intended for?
Any views?
It should go. We manage a transit network connecting Middle-eastern and North African national research networks (NRENs). The aim is that this grouping go independent of us at some point and manage everything themselves. I was able to get v4 PI space for this from RIPE, but the 200 rule appears to rule out these guys using v6. Oh well. -- Tim
Tim Streater wrote:
It should go. We manage a transit network connecting Middle-eastern and North African national research networks (NRENs). The aim is that this grouping go independent of us at some point and manage everything themselves.
So in say 10 years you are not managing it anymore? Most NREN's already have plenty of address space, so why not use that address space?
I was able to get v4 PI space for this from RIPE, but the 200 rule appears to rule out these guys using v6. Oh well.
Do you need a /32 full of address space or do you want PI? If you only need a single /48, then requesting a /32 is quite silly don't you think? And also quite a waste. Do note, that this is nothing against you, but if you get a /32 because you want PI, then a lot of other small organisations (read: individuals) may want one. Constructive part, same style as to the NATO one: - You have 50 PoPs. - You have say 150 employees (both can be a plan, you might fail but hell.. it still is a plan) That is already 200. Become LIR and get it. Greets, Jeroen
At 17:00 17/11/2005, Jeroen Massar wrote:
*** PGP Signature Status: good *** Signer: Jeroen Massar <jeroen@unfix.org> (Invalid) *** Signed: 17/11/2005 17:00:26 *** Verified: 17/11/2005 17:08:46 *** BEGIN PGP VERIFIED MESSAGE ***
Tim Streater wrote:
It should go. We manage a transit network connecting Middle-eastern and North African national research networks (NRENs). The aim is that this grouping go independent of us at some point and manage everything themselves.
So in say 10 years you are not managing it anymore? Most NREN's already have plenty of address space, so why not use that address space?
We are an LIR and we already have a /32 for the European NREN transit network that we also manage (GEANT). You don't use customer address space to address your transit network. What happens if that customer goes bankrupt or wants the space back or takes their custom elsewhere? And it's intended to be a couple of years, not 10.
I was able to get v4 PI space for this from RIPE, but the 200 rule appears to rule out these guys using v6. Oh well.
Do you need a /32 full of address space or do you want PI? If you only need a single /48, then requesting a /32 is quite silly don't you think? And also quite a waste.
We don't need a /32 obviously. Can we get a /48? And can we get it routed?
Do note, that this is nothing against you, but if you get a /32 because you want PI, then a lot of other small organisations (read: individuals) may want one.
Constructive part, same style as to the NATO one: - You have 50 PoPs. - You have say 150 employees
(both can be a plan, you might fail but hell.. it still is a plan)
So you're saying we should lie to RIPE when necessary? Seems to me much better to adjust the policies to fit reality.
That is already 200. Become LIR and get it.
See above. -- Tim
Tim Streater wrote:
At 17:00 17/11/2005, Jeroen Massar wrote:
Tim Streater wrote:
It should go. We manage a transit network connecting Middle-eastern and North African national research networks (NRENs). The aim is that this grouping go independent of us at some point and manage everything themselves. So in say 10 years you are not managing it anymore? Most NREN's already have plenty of address space, so why not use that address space?
We are an LIR and we already have a /32 for the European NREN transit network that we also manage (GEANT). You don't use customer address space to address your transit network.
Hold on here. *You* are the LIR, have already a /32 and are already using it for management, but won't use it yourself? Or do you mean that you want multiple /32's because you have multiple projects which should actually be separate? If I understand correctly you see your own network GEANT, for which you have the /32 already, as a customer and you expect it to go away? Can you elaborate on this (again, as I recall that this came up before) maybe this time in ASCII or Visio style? That might better illustrate what exact problem you are having and what then the solutions might be. It seems to be a really strange construct, at least doesn't seem to make any sense to me. Could very well be me of course.
What happens if that customer goes bankrupt or wants the space back or takes their custom elsewhere? And it's intended to be a couple of years, not 10.
Couple, thus 2 or 3? If you only plan to use it for a 'couple' of years, then you can also use other address space from other entities. Doesn't really matter if you change after X years or directly, you already planned to change anyway, thus if they go bankrupt, belly up, zapped to another dimension, you are changing anyway.
I was able to get v4 PI space for this from RIPE, but the 200 rule appears to rule out these guys using v6. Oh well.
Do you need a /32 full of address space or do you want PI? If you only need a single /48, then requesting a /32 is quite silly don't you think? And also quite a waste.
We don't need a /32 obviously. Can we get a /48? And can we get it routed?
One can get anything routed. Use ULA to generate your own random prefix and use it. I am quite sure that it will reach quite far. You only want to use it for management (and transit?) for your own network anyway and the ones who participate in your organisations can surely be persuaded to receive the route.
Do note, that this is nothing against you, but if you get a /32 because you want PI, then a lot of other small organisations (read: individuals) may want one.
Constructive part, same style as to the NATO one: - You have 50 PoPs. - You have say 150 employees
(both can be a plan, you might fail but hell.. it still is a plan)
So you're saying we should lie to RIPE when necessary?
Why is that a lie? Unless you actually are a homeuser (which you are not) or some very small ISP who doesn't want customers (which isn't the case either). I really can't see why you can't get address space under the current policy. For that matter: did you ever try? Or even simpler, did you ask RIPE NCC? Instead of just saying "we can't, change the policy"
Seems to me much better to adjust the policies to fit reality.
Reality looks more that you want PI space, or actually a slot in the routing tables. As ULA's already provide PI space, they just don't directly give a slot in the routing tables. Sidestep note: one can also use 2002::/16. You will have to run a 6to4 relay then, but this will give you "PI IPv6 space". You can then announce a more specific to your friendly neighbors. People who filter will use 2002::/16 to reach you. Greets, Jeroen
At 18:10 17/11/2005, Jeroen Massar wrote:
*** PGP Signature Status: good *** Signer: Jeroen Massar <jeroen@unfix.org> (Invalid) *** Signed: 17/11/2005 18:10:27 *** Verified: 17/11/2005 18:10:45 *** BEGIN PGP VERIFIED MESSAGE ***
Tim Streater wrote:
At 17:00 17/11/2005, Jeroen Massar wrote:
Tim Streater wrote:
It should go. We manage a transit network connecting Middle-eastern and North African national research networks (NRENs). The aim is that this grouping go independent of us at some point and manage everything themselves. So in say 10 years you are not managing it anymore? Most NREN's already have plenty of address space, so why not use that address space?
We are an LIR and we already have a /32 for the European NREN transit network that we also manage (GEANT). You don't use customer address space to address your transit network.
Hold on here. *You* are the LIR, have already a /32 and are already using it for management, but won't use it yourself? Or do you mean that you want multiple /32's because you have multiple projects which should actually be separate? If I understand correctly you see your own network GEANT, for which you have the /32 already, as a customer and you expect it to go away?
Can you elaborate on this (again, as I recall that this came up before) maybe this time in ASCII or Visio style? That might better illustrate what exact problem you are having and what then the solutions might be. It seems to be a really strange construct, at least doesn't seem to make any sense to me. Could very well be me of course.
We have two network that we manage. GEANT, for which we have a /32 for the backbone and which we expect to continue for a long time. The customers on this are the European NRENs, they are all LIRs themselves, so we don't get space from them and they don't get space from us - this is a transit network. Note: we were set up by our customers and are owned by our customers - we have, therefore, a small number of large customers and this base is not expected to expand (unless the EU invades the rest of the world). The other network is one we are *currently* managing, EUMEDCONNECT. It is for the Middle-eastern and North African NRENs. The intention here is that we expect these NRENs to set up their own entity to manage it, and go their own way, in which case we gift them the infrastructure, which in this case has to include the address space. We can do that for v4 as I got PI space for that. Its v6 that is the problem.
We don't need a /32 obviously. Can we get a /48? And can we get it routed?
One can get anything routed. Use ULA to generate your own random prefix and use it. I am quite sure that it will reach quite far. You only want to use it for management (and transit?) for your own network anyway and the ones who participate in your organisations can surely be persuaded to receive the route.
This may well suffice. Personally I feel this paranoia about the size of the v6 routing table is misplaced. You got lots of bits, you get lots of routing entries. But that's another story.
So you're saying we should lie to RIPE when necessary?
Why is that a lie? Unless you actually are a homeuser (which you are not) or some very small ISP who doesn't want customers (which isn't the case either). I really can't see why you can't get address space under the current policy. For that matter: did you ever try? Or even simpler, did you ask RIPE NCC? Instead of just saying "we can't, change the policy"
Well, it asked for the plan to allocate space to 200 customers or some such (it's a while since I looked at it). We have no such plan and there won't be one. Telling RIPE that I got one is therefore not true. The policy should be expanded to cover the reasonable cases. -- Tim
On Thu, 17 Nov 2005, Tim Streater wrote:
The other network is one we are *currently* managing, EUMEDCONNECT. It is for the Middle-eastern and North African NRENs. The intention here is that we expect these NRENs to set up their own entity to manage it, and go their own way, in which case we gift them the infrastructure, which in this case has to include the address space. We can do that for v4 as I got PI space for that. Its v6 that is the problem.
Did you actually *try* getting a separate /32 for this? RIPE NCC is known to be very reasonable towards transit networks, and I could bet good money you could get an allocation without a hitch. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On 17 nov 2005, at 20.05, Pekka Savola wrote:
On Thu, 17 Nov 2005, Tim Streater wrote:
The other network is one we are *currently* managing, EUMEDCONNECT. It is for the Middle-eastern and North African NRENs. The intention here is that we expect these NRENs to set up their own entity to manage it, and go their own way, in which case we gift them the infrastructure, which in this case has to include the address space. We can do that for v4 as I got PI space for that. Its v6 that is the problem.
Did you actually *try* getting a separate /32 for this?
RIPE NCC is known to be very reasonable towards transit networks, and I could bet good money you could get an allocation without a hitch.
So what you say is "keep the current rule as the NCC will disobey it anyway". Why can't we just fix the broken policy.... - kurtis -
RIPE NCC is known to be very reasonable towards transit networks, and I could bet good money you could get an allocation without a hitch. So what you say is "keep the current rule as the NCC will disobey it anyway". Why can't we just fix the broken policy....
how much should policy be twisted to cover up broken/incomplete technology? the need will be continual and infinite. randy
On 18 nov 2005, at 17.13, Randy Bush wrote:
RIPE NCC is known to be very reasonable towards transit networks, and I could bet good money you could get an allocation without a hitch.
So what you say is "keep the current rule as the NCC will disobey it anyway". Why can't we just fix the broken policy....
how much should policy be twisted to cover up broken/incomplete technology? the need will be continual and infinite.
You know Randy, you don't HAVE to do v6. You can stay at v4...:-) - kurtis -
RIPE NCC is known to be very reasonable towards transit networks, and I could bet good money you could get an allocation without a hitch. So what you say is "keep the current rule as the NCC will disobey it anyway". Why can't we just fix the broken policy.... how much should policy be twisted to cover up broken/incomplete technology? the need will be continual and infinite. You know Randy, you don't HAVE to do v6. You can stay at v4...:-)
the question is not about me, but thanks for turning the discussion personal. have you stopped beating your routers? the issue is can we 'fix' policy to cover for the fact that v6 was only 1/3 designed, long addresses but no routing and no transition plan? i am suggesting that the policy fixes will be infinite and ever more twisty, as there is only so much one can do to cover that the underlying technology is not even half-assed. randy
On Fri, Nov 18, 2005 at 08:57:51AM -0800, Randy Bush wrote:
i am suggesting that the policy fixes will be infinite and ever more twisty, as there is only so much one can do to cover that the underlying technology is not even half-assed.
What's your alternative? "I cannot make my way to the groceries store in less than 10 minutes, so I don't go shopping at all, until... when?" I'm very convinced that putting a proper v6 PI policy in place does buy us enough time for to find a real solution to the perceived problem (which, again, noone has proven to be more than a worst case scenario yet). That solution will most probably not be IPv6. But evolution is inherent to the Net. We need evolution. We cannot wait for the magic 42 to appear to fulfil all our needs, cover all worst case scenarios the Netstradami paint onto the walls. We won't be able to predict the future >>10 years, and we are far less able to design solutions now for problems we cannot even forsee. Or to view it from a different angle: always playing safe was never the formula for great success. It's usually the formula for an intellectual parking brake. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
"I cannot make my way to the groceries store in less than 10 minutes, so I don't go shopping at all, until... when?"
broken analogy. currently, the ipv4 grocery store delivers quite well. randy
----- Original Message ----- From: "Tim Streater" <tim.streater@dante.org.uk>
We are an LIR and we already have a /32 for the European NREN transit network that we also manage (GEANT). You don't use customer address space to address your transit network. What happens if that customer goes bankrupt or wants the space back or takes their custom elsewhere? And it's intended to be a couple of years, not 10.
I was able to get v4 PI space for this from RIPE, but the 200 rule appears to rule out these guys using v6. Oh well.
Hi Tim, The 200 rule is for PA. You want/need PI so lets start/continue The PI discussion, not the "I am so special that I need a special PI policy just for my organisation" discussion if anybody is thinking in that direction. Joergen Hovland
I fully agree, the 200 customers requirement should go away. We are probably the last RIR doing so, funny :-( There are lots of similar examples as the NATO one. It make no sense at all Regards, Jordi
De: Marc van Selm <marc.van.selm@nc3a.nato.int> Organización: NATO C3 Agency Responder a: "address-policy-wg-admin@ripe.net" <address-policy-wg-admin@ripe.net> Fecha: Thu, 17 Nov 2005 17:15:05 +0100 Para: <address-policy-wg@ripe.net> Asunto: [address-policy-wg] 200 customer requirements for IPv6
Following up on the discussion during RIPE-51, I have not heard much discussion on "200 customer requirement for IPv6" rule. So I would like to hear your views on this.
During RIPE-51 the proposal to remove the rule caught serious objections. I can sympathise with those but I do have an issue that I'd like feedback on.
I am investigating how NATO should acquire IPv6 address space. NATO will use multiple transmission providers, NATO owned transmission and national networks. Also transmission contracts will have to be opened for bidding every few years. That makes requesting IP space from an ISP a non starter. So we explore the LIR route. Note that NATO has a service provider under its umbrella that provides service towards the other NATO organisations. They operate independently and are like an ISP (and more) for that matter. They are just not selling outside NATO.
At this time it is reasonably hard to specify the 200 /48 that will be given out for the "IPv6 Initial Allocation Request". Having reached about 130 or so on my list (not finished yet) I can't help wondering why RIPE-NCC should care about a list of sites that they only a vague clue of what they are and have no means of verification if the list is correct. Having said that, I get the feeling that the 200 rule only ads admin overhead and has limited actual power. Now NATO could include a summarised version in the Initial Allocation and do something like:
Subnet: /48 1 year 5 regional sites (/48 per site = 5x /48) Subnet: /48 1 year 20 subordinate sites to the 5 regional sites (/48 per site = 5x 20x /48 = 100 /48) Subnet: /48 2 year 40 deployed elements (/48 per site = 40x /48) Subnet: /48 2 year 70 Crisis Response Operation locations (/48 per location = 70 x /48) Total: 215x /48
Note that the numbers are fiction but they are not very unrealistic as we also need to include standby elements that are ready to go (power up, aim dish and run) systems. Although close to the truth, RIPE-NCC would have no way of verifying this and providing a detailed list would bury RIPE-NCC in details that they don't care about and also cannot verify.
I can't help feeling this rule is written for ISPs but will be counter productive for NATO and organisations with a very large privately operated enterprice network. I also can't help the feeling that its a paper tiger. So isn't there another way to achieve the same result as this rule was intended for?
Any views?
Marc -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm@nc3a.nato.int (PGP capable)
************************************ The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
On Thu, Nov 17, 2005 at 05:26:20PM +0100, JORDI PALET MARTINEZ wrote:
There are lots of similar examples as the NATO one. It make no sense at all
Not issueing PI for multihomed entities makes no sense at all, in face of the complete lack of a full replacement. I'm still waiting for the heads to come out of the sand, but I'm waiting since long and don't see _any_ light at the end of the tunnel (don't anybody dare to say "shim6" if he/she doesn't want to disqualify her/himself immediately). The folks all having their own /32 already allocated to them and trying to limit independent address space to "service providers" (or those who manage to pretend being it, which seems to be easy) are still arguing for "not for them!" paradigm - easy position with having their own dishes already done. Until we have a clear full replacement (that means a solution which does NOT ignore real requirements like shim6 does) there should be a very simple PI policy which issues a /48 or whatever to end sites at a nominal small fee, paid directly to the RIR. An initial setup fee and a yearly renewal fee, paid by credit card or something equally simple. No payment => assignment withdrawn. The initial fee covering the cost of evaluation of the request, doing the assignment and setting up the billing account and DNS reverse. The yearly fee covering the maintenance of the entries in the database and DNS rev NS RRset and the yearly recurring fee invoicing/billing. Done. Too simple, too scary, too much independence again to the endsites, eh? I think it's ridiculous to have folks become LIR (and pretend/lie being ISPish) just to get the PI space they need and having them pay the same money every *real* LIR (you remember what LIR means? Local Internet REGISTRY) which happens to open tickets with the hostmasters every now and then (or much more often). Setting aside my disbelieve in the FUD about the scalability problem of real BGP multihoming (noone yet has shown that the relative amount of multihomers does or will explode), I'm quite sure that we'd need a real locator/ID split which is NOT shim6 but something going farther than that. And we won't have it soon, if at all for IPv6. But keeping on ignoring user's needs for further years and waiting for the magically appearing 100% ideal solution is not the way forward. My 0.02EUR Regards, Daniel (having renumbered his IPv6 network already three times completely and hoping not having to do it a fourth time anytime soon, and not being able to properly multihome like I can do in IPv4 because I'm not a commercial ISP, nor can afford the thousands of EUR for LIR which usually finance MUCH more than just a one-time PI assignment and some DB slots) -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Hi, Daniel Roesen wrote:
On Thu, Nov 17, 2005 at 05:26:20PM +0100, JORDI PALET MARTINEZ wrote:
There are lots of similar examples as the NATO one. It make no sense at all
Not issueing PI for multihomed entities makes no sense at all, in face of the complete lack of a full replacement. I'm still waiting for the heads to come out of the sand, but I'm waiting since long and don't see _any_ light at the end of the tunnel (don't anybody dare to say "shim6" if he/she doesn't want to disqualify her/himself immediately). The folks all having their own /32 already allocated to them and trying to limit independent address space to "service providers" (or those who manage to pretend being it, which seems to be easy) are still arguing for "not for them!" paradigm - easy position with having their own dishes already done.
ok, *handraise* That's not entirely true - while i have "my" /32, i'm still arguing against this current no-PI situation every this and then (i stopped getting involed in _every_ IPv6-PI-related flamewa^Wthread long ago though...) But indeed, that's still the main problem, that people don't get their head out of the sand, largely due to just not seeing this problem as an issue for themselves.
Until we have a clear full replacement (that means a solution which does NOT ignore real requirements like shim6 does) there should be a very simple PI policy which issues a /48 or whatever to end sites at a nominal small fee, paid directly to the RIR. An initial setup fee and a yearly renewal fee, paid by credit card or something equally simple. No payment => assignment withdrawn. The initial fee covering the cost of evaluation of the request, doing the assignment and setting up the billing account and DNS reverse. The yearly fee covering the maintenance of the entries in the database and DNS rev NS RRset and the yearly recurring fee invoicing/billing. Done.
Too simple, too scary, too much independence again to the endsites, eh?
I think, the main argument against IPv6-PI _still_ is the routing table size, contradicting any reasonable predictions nowerdays (IMHO!). At least that was my own argument against(!) PI in first place, but times have changed since the last millenium. In particular, noone came up with an equal solution to BGP Multihoming with "PI"-space, which i hoped for back then. I can't even see any solution rising in the FAR future, so the only way to keep IPv6 from being completely useless is, go for allowing PI Space for organisations who really want that geniune kind of multihoming and are sure they don't want any workaround solution. A setup+renewal fee does not do much against the routing table size or so, but at least should stop having the IPv4-situation with swamp space(s) and unused, unowned or "joke" Prefixes floating in the databases. I wouldn't like to have anyone to get a Prefix without reasonable need just for the fun of it, like with el-chepo Domain-Names and Hostname ect.. One should know what he does. Of course the issuing organisation should point to alternative solutions and have the requesting one to check out on them if they might be sufficent for their needs (the famous "Did you consider using RfC1918?"-alike-question in the request form should do it with some pointers to good FAQs on alternatives).
I think it's ridiculous to have folks become LIR (and pretend/lie being ISPish) just to get the PI space they need and having them pay the same money every *real* LIR (you remember what LIR means? Local Internet REGISTRY) which happens to open tickets with the hostmasters every now and then (or much more often).
ACK. That's ridiculous. Additionaly, some might not NEED a /32 and don't want to pay for services they don't need (Registry servies, voting@RIPE-meetings, Training Courses... whatver)
Setting aside my disbelieve in the FUD about the scalability problem of real BGP multihoming (noone yet has shown that the relative amount of multihomers does or will explode), I'm quite sure that we'd need a real locator/ID split which is NOT shim6 but something going farther than that. And we won't have it soon, if at all for IPv6. But keeping on ignoring user's needs for further years and waiting for the magically appearing 100% ideal solution is not the way forward.
Well, if i say "there is no scalability" problem, that would be considered ignorant by most people, so i don't do that now. But i can't see any problems with BGP routing table size either, it will be significantly smaller than in the IPv4 world by design (one - or few - prefixes per AS), and even when it's growing again from PI-prefixes, probably beyond the current IPv4 table size, what's the problem? Nowerdays routers actually can handle that with >=1GB RAM and fast ASICs. ... and it will take YEARS if at all to raise above nowerdays size. Now let alone the fact that you need to carry on with the IPv4 table for decades anyways, so no relief in sight for the routers... But i'm not saying, there won't be a problem in 50years.
My 0.02EUR
I add another 0.02EUR
Regards, Daniel (having renumbered his IPv6 network already three times completely and hoping not having to do it a fourth time anytime soon, and not being able to properly multihome like I can do in IPv4 because I'm not a commercial ISP, nor can afford the thousands of EUR for LIR which usually finance MUCH more than just a one-time PI assignment and some DB slots)
...i rather invest in redundant Uplinks and routers than in becoming LIR for no apparent reason (i.e. not ASSIGNING Address space as primary purpose), hence i currently go for IPv4-PI for my non-profit organisation(s), utilizing a /40 Suballocation in the IPv6 world from "my" (commercial) LIR. Better than nothing but i'd prefer a completely independant IPv6-PI space and someone doing something against this /32-/35-filter-madness. "My" LIR is not very active in the ISP business lately, and i don't want to know how to deal with a CLOSE of the LIR with my more private, non-profit Address Space either. Am i allowed to keep the Suballocation when RIPE reclaims the LIR's /32? Can i announce the whole /32 when i can't reach some locations with the /40 Suballocation announcement? Can i have the whole /32 for free then not being a LIR? Do i ultimately have to renumber, too? How often? How do i maintain my multihoming properly? ...and so on...(NOTE: rethorical questions, i know the current procedures on the paper) <arrogancy> Idependency is one of the basic things in the internet, i don't like people who want to tell me how much independency i need. I know that best for myself. </arrogancy> -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
My apologies for replying to such an old message, but I couldn't let this one go. On 18-nov-2005, at 12:33, Sascha Lenz wrote:
In particular, noone came up with an equal solution to BGP Multihoming with "PI"-space, which i hoped for back then.
Well, you haven't been paying attention, because I've presented "provider-internal aggregation based on geography" at two different RIPE meetings a while ago. The only thing I got was perplexed stares. You really can't expect to keep doing the same thing we've been doing in IPv4 in IPv6 but now with different results (= more reasonable routing tables). Iljitsch -- I've written another book! http://www.runningipv6.net/
Hi, Iljitsch van Beijnum wrote:
My apologies for replying to such an old message, but I couldn't let this one go.
On 18-nov-2005, at 12:33, Sascha Lenz wrote:
In particular, noone came up with an equal solution to BGP Multihoming with "PI"-space, which i hoped for back then.
Well, you haven't been paying attention, because I've presented "provider-internal aggregation based on geography" at two different RIPE meetings a while ago.
Actually, i did pay attention, but why do you think i consider that as an equal solution to BGP Multihoming with "PI"-space? It's _ONE_ alternative solution one might suggest, but still no reason for disallowing anyone in the globally distributed prefix table. Why do i want this at all? Because there are globally distributed prefixes right now, there is no geographically based assigment in sight anywhere and yes your presentation was a while ago. IIRC even your presentation said that this would require geographically based assigments "right now". Right? Do you expect everyone with a prefix today to give it back and renumber? "Too late" at least for a full solution. This is just another suggestion that might be helpful for preventing some amount of global prefixes (see below), but not god's own solution to the problem.
The only thing I got was perplexed stares.
You really can't expect to keep doing the same thing we've been doing in IPv4 in IPv6 but now with different results (= more reasonable routing tables).
*think* Of course... as mentioned before by many people, IPv6 implicitly solves some of the problems with "too many routes". Again, this leads to: - "usually" only one Prefix per AS even with nowerdays IPv6 policy ==> "more reasonable routing table" per default because almost noone needs a second Prefix - no impact on the IPv4 Routing Table size which you have to carry around for decades anyways. ==> no relief for any router in sight, regardless of the the IPv6 policy - There _ARE_ multihoming solutions besides world-wide prefix announcements, there are many. You can suggest all of them to your customers when they ask for "redundancy" or so. You even could be required by policy to tell your customers about the solutions as i suggested during the current thread. BUT - if someone insists on BGP Multihoming with worldwide prefix distribution for whatever reason he/she might have, noone must be forbidden to do so! ==> Even less End-site-customers who want an AS and PI-Prefixes because some actually _ARE_ OK with alternative. Noone denies the fact that there are most likely too many prefixes and probably even too many ASes in todays IPv4 Internet Routing Table. It's also a fact that many of them are not really needed, and the desired redundancy could be achieved by other means. Some customers might even be happy if they don't need to care for BGP Speaking Routers or so in their network and are pleased if you suggest a different solution. The main problem is just people who want to tell "me" (not literally) what's best for "my" network, and disallow "me" in the pond with the big fish. ..and there are absolutely no technical reasons which would forbid "me" in this pond if i want to swim there. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
On 6-dec-2005, at 15:59, Sascha Lenz wrote:
In particular, noone came up with an equal solution to BGP Multihoming with "PI"-space, which i hoped for back then.
Well, you haven't been paying attention, because I've presented "provider-internal aggregation based on geography" at two different RIPE meetings a while ago.
Actually, i did pay attention, but why do you think i consider that as an equal solution to BGP Multihoming with "PI"-space?
I don't understand what you're trying to say... But I'm happy that someone noticed what I was trying to say back then.
It's _ONE_ alternative solution one might suggest, but still no reason for disallowing anyone in the globally distributed prefix table.
To me, it's pretty obvious that if we can have aggregatable PI space, then that's an excellent reason to NOT have non-aggregatable PI space. Note however that the aggregation is optional in my plan: everyone can implement it in their own network independent of what everyone else does. In the beginning, there certainly won't be any reason to aggregate so this type of PI is completely equivalent to regular PI.
Why do i want this at all?
Well, I don't know. I can get by with my PA /48 just fine. But apparently some people like to multihome and some of them insist that shim6 doesn't address their needs. And others want a portable prefix for other reasons.
Because there are globally distributed prefixes right now, there is no geographically based assigment in sight anywhere
So? If we really want this we can start doing this in a manner of weeks: the only requirement is that the RIRs start giving out prefixes that are aggregatable. In practice, it will take about the same amount of time as any other policy change.
Do you expect everyone with a prefix today to give it back and renumber?
Today, there is no PI in IPv6 so that's a moot question.
BUT - if someone insists on BGP Multihoming with worldwide prefix distribution for whatever reason he/she might have, noone must be forbidden to do so!
I'd rather have a working internet without PI than a non-working one with it. Nobody can guarantuee that we won't run into trouble with PI so the only way we can be sure we won't have this trouble is to not have PI. If you want PI as it exists today in IPv4, the burden is on you to show, yes, SHOW that it can scale for decades to come.
The main problem is just people who want to tell "me" (not literally) what's best for "my" network, and disallow "me" in the pond with the big fish.
Do whatever you want, as long as you don't do it in my routing table. The internet only works as long as 99% of all people carry 99% of all routes. When a sizeable number of people starts filtering a sizeable number of routes for whatever reason, either technical (won't fit in their routers) or political (don't agree with the policies) then we're in knee-deep brown stuff. -- I've written another book! http://www.runningipv6.net/
On Tue, 6 Dec 2005 16:30:25 +0100, Iljitsch van Beijnum wrote:
On 6-dec-2005, at 15:59, Sascha Lenz wrote: [...]
Well, you haven't been paying attention, because I've presented "provider-internal aggregation based on geography" at two different RIPE meetings a while ago. It's _ONE_ alternative solution one might suggest, but still no reason for disallowing anyone in the globally distributed prefix table.
Ack.
To me, it's pretty obvious that if we can have aggregatable PI space, then that's an excellent reason to NOT have non-aggregatable PI space.
You may aggregatable PI space if you can convince the router manufacturers create and implement a new RFC which adds an additional layer for prefix aggregation within the BGP protocol. Geographical aggregation however, is _for_sure_ not the solution for the new centrury. Geographical solutions happened in the last century. Nowadays carriers use DWDM technology, and yes, a link between Frankfurt and London or even New York is cheaper and easier to obtain than a link between Frankfurt and Wiesbaden. The key issue is whether competing dark fiber or leased line carriers are available at a certain location and _not_ the distance between those.
Well, I don't know. I can get by with my PA /48 just fine. But apparently some people like to multihome and some of them insist that shim6 doesn't address their needs. And others want a portable prefix for other reasons.
Yes, and as these people make a significant part out of the IPv4 internet world, as ISP's we can either support their requirement or keep IPv6 experimental. Period.
So? If we really want this we can start doing this in a manner of weeks: the only requirement is that the RIRs start giving out prefixes that are aggregatable. In practice, it will take about the same amount of time as any other policy change.
The key issues is: What today might look like an aggregate, won't be one tomorrow. Today A might be related to B and C to D, thus (AB) or (CD) might sound like good aggregates, tommorow A is related to C and B to D. Math limits the aggregation possibilities for ABCD. In this case, a bit mask could help: (A=x00y, B=x01y, C=x10y, D=x11y, thus first case mask 10, second 01) but it is obviously not possible to find an aggregation solution for any possible combination (e.g. ABC vs. D). As routing was not really considered by the designers of the IPv6 protocol (yes, this _is_ an fault, IPv6 can be considered a lousy solution under this view), we can either live with it or give it up. Living with it means providing a solution for the PI requesting organisations and waiting for an aggregation enhancement of the routing protocols or keep it experimental, which probably means: Let it die. Even if the PI question is solved these days, I won't be sure if the answer isn't already too late. The market will tell us.
I'd rather have a working internet without PI than a non-working one with it. Nobody can guarantuee that we won't run into trouble with PI so the only way we can be sure we won't have this trouble is to not have PI.
This argument is unreal, you can stop _any_ project with it, in Germany we call it "Vollkaskomentatlitaet" and our country suffers a lot from it. There is simply no way to prove that a given solution won't have a side effect. If you write: "Nobody can guarantee ..." then I will tell you: Nobody can _guarantee_ that your posting by its formating or content can't cause a significant harm to an important server, cause a worldwide crash of the internet, thus impairs water and electricity supply and at the end let the aliens conquer earth. Thus you shouldn't post to this list ... Of course this is very very unlikely to happen, but, who knows, a word sequence within your comment might trigger this by a unknown bug within a common microprocessor type. You can't gurantee that your posts don't harm, thus by your own logic you should really consider not to post anymore ... More realistic: I'd rather like a internet with IPv6 and PI and the very low probability of of trouble which can with a high probably be fixed than no real-in-use IPv6 because of arguments which request gurantees that can't be given for _any_ solution on this planet. Up to now engineers have always proven to find solutions for networking problems like the PI issue, thus there will be some solution for sure if required. However I doubt there will be ever this requirement.
Do whatever you want, as long as you don't do it in my routing table.
You are free to implement _your_ routing table as you like and to filter what you like, however: The global routing table is not _your_ routing table. Please don't block further enhancements of the Internet and please don't damage IPv6 by spreading out FUD. Thank You! Best regards Oliver Bartels P.s. @RIPE NCC: Question: Is there a practical way to replace the slow and cumbersome "consensus" principle of the RIPE by a democratic majority vote of the RIPE NCC members to stop further damage to IPv6, perhaps with a decision at the next RIPE NCC general meeting ? Of course some RIPE participants might then discuss adresss policies for ever, but for the RIPE NCC members we would then probably have practically acceptale policies for implementation in real world networks. Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
On 6-dec-2005, at 17:36, Oliver Bartels wrote:
To me, it's pretty obvious that if we can have aggregatable PI space, then that's an excellent reason to NOT have non-aggregatable PI space.
You may aggregatable PI space if you can convince the router manufacturers create and implement a new RFC which adds an additional layer for prefix aggregation within the BGP protocol.
I can't imagine what such a layer would look like...
Geographical aggregation however, is _for_sure_ not the solution for the new centrury. Geographical solutions happened in the last century.
In IP? Don't think so. If you have pointers, please enlighten me.
Nowadays carriers use DWDM technology, and yes, a link between Frankfurt and London or even New York is cheaper and easier to obtain than a link between Frankfurt and Wiesbaden.
Sure. But trying to aggregate on network topology is never going to work for two very simple reasons: 1. It changes all the time 2. You can't express a topology with loops in it in an addressing hierarchy The reason to choose geography to aggregate on is not because it is somehow magically always the best fit with topology, because it isn't. However, it has two very important things going for it: it's not subject to change, and it allows for optimization on distance, which in turn has the potential to be be good for cost and performance. Please don't assume you understand my proposal just because it contains the term "geography". If you want to know what it entails have a look at http://www.muada.com/drafts/draft-van-beijnum-multi6- isp-int-aggr-01.txt
The key issue is whether competing dark fiber or leased line carriers are available at a certain location and _not_ the distance between those.
Distance is actually very important. It's very hard to do decent high speed file transfer on out of the box OSes and applications with high delay. Also, it often makes sense to backhaul traffic over SOME distance, but that doesn't mean it also makes sense to backhaul it over even larger distances. I.e., even if a link to New York is cheap, you don't want to go over Palo Alto.
As routing was not really considered by the designers of the IPv6 protocol (yes, this _is_ an fault, IPv6 can be considered a lousy solution under this view), we can either live with it or give it up. Living with it means providing a solution for the PI requesting organisations and waiting for an aggregation enhancement of the routing protocols or keep it experimental, which probably means: Let it die.
Your conclusions don't follow from your assumptions. Yes, IPv6 doesn't do anything for routing except allow very large aggregates. However, the choice isn't between allowing unlimited growth and hoping we can fix it later and not using IPv6, the choice is between: - Not allowing PI - Coming up with aggregatable PI of some kind - Give up and make the exact same mess of IPv6 as we did with IPv4 Today, IPv4 routing works but it has come close to the edge of the cliff twice (early 1990s just before CIDR routing tables were too large and late 1990s flapping cost too much CPU) and it's still pushing towards that edge, which we can't see clearly but know is out there somewhere. And that happened in 25 years. We'll very likely have to live with IPv6 for much longer than that, so we HAVE to be careful from the outset. Shim6 is coming, aggregation with PI is unexplored, IPv6 is still in the extremely early stages, so this is NOT the time to do stupid things. If we're still in the same boat in 5 years when we're down to 18 months of IPv4 addresses, sure, we can revisit this issue. But we still have some time. Let's use it.
Even if the PI question is solved these days, I won't be sure if the answer isn't already too late. The market will tell us.
What kind of logic makes this too late?
I'd rather have a working internet without PI than a non-working one with it. Nobody can guarantuee that we won't run into trouble with PI so the only way we can be sure we won't have this trouble is to not have PI.
This argument is unreal, you can stop _any_ project with it, in Germany we call it "Vollkaskomentatlitaet" and our country suffers a lot from it.
Well, then apply some of that mentality to PI in IPv6 and free it up elsewhere. :-)
There is simply no way to prove that a given solution won't have a side effect.
So because you can't prove that you're right I should just believe you without proof?
If you write: "Nobody can guarantee ..." then I will tell you:
Nobody can _guarantee_ that your posting by its formating or content can't cause a significant harm to an important server, cause a worldwide crash of the internet, thus impairs water and electricity supply and at the end let the aliens conquer earth.
No, but there's no reasonable scenario that makes this happen either. The scenario that de facto unlimited PI in IPv6 will make routing tables so large that it becomes problematic in some way or another is entirely reasonable, on the other hand.
More realistic:
I'd rather like a internet with IPv6 and PI and the very low probability of of trouble which can with a high probably be fixed than no real- in-use IPv6 because of arguments which request gurantees that can't be given for _any_ solution on this planet.
Yes, I've heard it all before. Why don't we work on something that we can all get behind? The beauty of my geographical aggregation thing is that you still get PI even if it turns out that it doesn't work. So you get what you want regardless of who's right. Pretty good deal, don't you think?
Up to now engineers have always proven to find solutions for networking problems like the PI issue, thus there will be some solution for sure if required.
Sure, we can always implement some kind of aggregation later. This of course requires renumbering of all PI space. And isn't the idea behind PI space that you never have to renumber out of it...?
P.s. @RIPE NCC: Question: Is there a practical way to replace the slow and cumbersome "consensus" principle of the RIPE by a democratic majority vote of the RIPE NCC members to stop further damage to IPv6, perhaps with a decision at the next RIPE NCC general meeting ?
Please replace "RIPE NCC members" with "people who have to pay for bigger routers world wide" (not just the RIPE region) and I'm all for it. Iljitsch -- I've written another book! http://www.runningipv6.net/
On Tue, 6 Dec 2005 18:08:40 +0100, Iljitsch van Beijnum wrote:
On 6-dec-2005, at 17:36, Oliver Bartels wrote:
You may aggregatable PI space if you can convince the router manufacturers create and implement a new RFC which adds an additional layer for prefix aggregation within the BGP protocol.
I can't imagine what such a layer would look like...
Clustering all PI-prefixes originating at the same AS to form a single "super-prefix" makes policy processing a lot easier, because it need to be done just once for the whole block. This is obvious for single homed PI and even saves processing time on multihomed PI. Whether the address space occupied by this prefix is homogenous or not is a "don't care" nowadays, as a large forwarding table isn't a problem at all. With as few as 256MByte of DDRAM plus a 64K TCAM chip it is possible to handle max. 8 Million Forwarding entries at full 128 bit resolution with appx. 10 GBit/s typical and 1.5 GBit/s "bad weather" (small packets only) line rate. I personally just received a patent on such router hardware concept.
In IP? Don't think so. If you have pointers, please enlighten me.
In POTS and X.25 networks. The latter died ...
Nowadays carriers use DWDM technology, and yes, a link between Frankfurt and London or even New York is cheaper and easier to obtain than a link between Frankfurt and Wiesbaden.
Sure. But trying to aggregate on network topology is never going to work for two very simple reasons:
1. It changes all the time
The same is true for geographical aggregation. Geographical aggregation would require free transit, otherwise it is not compatible with the ISP's business models. There is no free transit and thus it doesn't work. Business relations changes all the time and in a global markets world these business relations don't stop on country boundaries. Such boundaries are artifical, the EU tries to avoid them. Thus the only aggregation you would gain is: Americas / Europe-Asia / Asia-Pacific. Not even Africa and with huge problems in Asia. Everything below this continental boundaries can be treated local and, with your own words : It changes all the time ( Why: See below, dimensions. ) Thus with a geographical approach your aggregation gain is near zero (might be a factor of 2..3 in the table, which is near zero in this context). Sorry, but geographical aggregation won't work in these days any more.
2. You can't express a topology with loops in it in an addressing hierarchy
Avoiding loops is the job of the routing protocol, not the topology.
Distance is actually very important. It's very hard to do decent high speed file transfer on out of the box OSes and applications with high delay. Also, it often makes sense to backhaul traffic over SOME distance, but that doesn't mean it also makes sense to backhaul it over even larger distances. I.e., even if a link to New York is cheap, you don't want to go over Palo Alto.
If I would be located in Seattle, Palo Alto might be an alternative way point as well as Chicago or even Dallas. What you are trying is: Map a two-and-a-half-dimensional world on a one-dimensional address range. This won't work by Math. Dimensions can only be replaced by dimensions. Asked a database programmer how difficult it is to implement a geographical 10km around some place search on a database and ask them about the algorithms in use. What they try is interleaving the West-East (X) and North-South (Y) coordinates bitwise in the search key and handle overruns by exceptions, like: X_MSB Y_MSB X_2SB Y_2SB X_3SB Y_3SB ... However this requires a _significant_ exception handling effort, nothing someone would like to implement in a fast forwarding engine for packet routing. Beleave me: The cost for 256MBytes of DDRAM is in the lower two digits Euro range, nothing to be discussed with high end routers. A large forwarding table is much cheaper than a geographical packet resolution.
However, the choice isn't between allowing unlimited growth and hoping we can fix it later and not using IPv6, the choice is between:
- Not allowing PI - Coming up with aggregatable PI of some kind - Give up and make the exact same mess of IPv6 as we did with IPv4
Today, IPv4 routing works but it has come close to the edge of the cliff twice (early 1990s just before CIDR routing tables were too large and late 1990s flapping cost too much CPU) and it's still pushing towards that edge, which we can't see clearly but know is out there somewhere.
It works. Period. And it will continue to work, because of the economic pressure. Engineers have found a solution, thus: Don't worry.
So because you can't prove that you're right I should just believe you without proof?
Yes, because the theory of computer sience gives you the prrof that there are theorems in this world which can't be proven. Computer Software belongs to this sort of items, someone can just test it, make assumptions, but can't prove it will be correct for any but the most simple algorithms. And this is proven. Try to build an algorithm which checks that any other algorithm will correctly terminate. Try to apply this algorithm to itself, think about the consequences and then you might understand: Real technology is always believe at some point and not proof. There is no way to get a _proof_ that your post (or my) doesn't trigger a nasty CPU or router operating system bug which causes the internet meltdown. There is just believe and trust that reasonable router manufacturers will deliver reasonable products.
No, but there's no reasonable scenario that makes this happen either.
Of course there is. Think of the nasty multiplication bug with the Intel 486 CPU. This happened just with a few numbers. Intel replaced a huge amount of these chips free of charge. Think of a race condition in a chip, which processes your post and creates a checksum. Under very rare circumstances the race condition applies for your checksum (see multiply bug), cascades to a bus collision and melts down the router. However the forwarding hardware already received the ok to output the dangerous packet to the next router in the chain without further intervention of the hardware which just died.
The scenario that de facto unlimited PI in IPv6 will make routing tables so large that it becomes problematic in some way or another is entirely reasonable, on the other hand.
The current experience let us make a reasonable and responsible assumption that a IPv6 routing table would take not much more growth than the current IPv4 table, whereas current technology permits tables of 10 to 100 times that size.
Yes, I've heard it all before. Why don't we work on something that we can all get behind? The beauty of my geographical aggregation thing is that you still get PI even if it turns out that it doesn't work. So you get what you want regardless of who's right. Pretty good deal, don't you think?
Again: 2 dimensions -> 1 dimension doesn't work.
Please replace "RIPE NCC members" with "people who have to pay for bigger routers world wide" (not just the RIPE region) and I'm all for it.
People who pay for big routers pay for big pipes, too. They pay significantly more for big pipes than for big routers. If you give them the choice to save 10% on the pipe for using the cheaper offer instead of the one-dimensional-geographical ordering-correct offer, and increase the router price by 30% percent for increased routing flexibility and larger tables, they still will vote for the cheaper pipe. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
On 6-dec-2005, at 20:10, Oliver Bartels wrote:
I can't imagine what such a layer would look like...
Clustering all PI-prefixes originating at the same AS to form a single "super-prefix" makes policy processing a lot easier, because it need to be done just once for the whole block.
I'm not sure I understand the "superprefix" but obviously a lot of work that now happens per-prefix in BGP should happen per-AS. But that's mostly moot in IPv6 as we should never reach the numbers of prefixes per AS that we see in IPv4.
With as few as 256MByte of DDRAM plus a 64K TCAM chip it is possible to handle max. 8 Million Forwarding entries at full 128 bit resolution
I guess that means you throw everything in the TCAM first to get from 8M to about 125 entries and then look those up in a tree or hash table? Obviously it's possible to build architectures that allow fast forwarding with big tables. However, this doesn't come free: it takes more iron to do this, and also more power. TCAMs suck down the juice like a depressed alcoholic. This is bad for your design (both the box itself and the datacenter), your wallet and the environment.
I personally just received a patent on such router hardware concept.
So big routing tables are good business for you, then?
Sure. But trying to aggregate on network topology is never going to work for two very simple reasons:
1. It changes all the time
The same is true for geographical aggregation.
I guess I you live in California or another place that is plagued by frequent earthquakes...
Geographical aggregation would require free transit, otherwise it is not compatible with the ISP's business models.
The point is to keep the aggregation inside the ISP network. Tier-1 ISPs would still have a full routing table, but rather than have a copy in each router, it's distributed over the network. So there is no free transit requirement.
country boundaries.
Such boundaries are artifical, the EU tries to avoid them.
The idea behind aggregation is that you can move up or down. If country borders get in the way, drill down a bit and start looking at provinces or cities. In our design there are potentially 64k distinct areas (mostly cities) so if you want, you can have a route for each of those in your routing table and never run into country borders.
2. You can't express a topology with loops in it in an addressing hierarchy
Avoiding loops is the job of the routing protocol, not the topology.
??? Are we talking about spanning tree now? Loops in the topology are good. You can't remove them. Routing is also dynamic, BTW.
Distance is actually very important. It's very hard to do decent high speed file transfer on out of the box OSes and applications with high delay. Also, it often makes sense to backhaul traffic over SOME distance, but that doesn't mean it also makes sense to backhaul it over even larger distances. I.e., even if a link to New York is cheap, you don't want to go over Palo Alto.
If I would be located in Seattle, Palo Alto might be an alternative way point as well as Chicago or even Dallas.
Of course. But we're in Europe. If you're in Seattle you'll see a lot of your traffic to other people in Seattle flow through Palo Alto. That's normal, because it's not economical to peer with everyone everywhere. It's not so cool when intra-Seattle traffic starts to flow through Miami.
What you are trying is:
Map a two-and-a-half-dimensional world on a one-dimensional address range. This won't work by Math. Dimensions can only be replaced by dimensions.
Ah, but we're not mathematicians but engineers. In software, you have one dimensional memory. Still, you can have multidimensional arrays.
Asked a database programmer how difficult it is to implement a geographical 10km around some place search on a database and ask them about the algorithms in use.
Easy: select everything that's in a 20x20 km grid around the center point and then do the real distance calculation on everything in that grid. Obviously you'll select stuff that's at x+8 y+8 = ~12km from the center but that's only true for a relatively small part of the intermediate results.
What they try is interleaving the West-East (X) and North-South (Y) coordinates bitwise in the search key and handle overruns by exceptions,
That sounds like Tony Hain's geographical addressing. The variant Michel Py and myself came up with is based on administrative borders such as countries so you already have on dimension: the alphabet. (Ok, not entirely how it works, but still.)
However this requires a _significant_ exception handling effort, nothing someone would like to implement in a fast forwarding engine for packet routing.
Geography is long gone by the time we're forwarding packets.
Today, IPv4 routing works but it has come close to the edge of the cliff twice (early 1990s just before CIDR routing tables were too large and late 1990s flapping cost too much CPU) and it's still pushing towards that edge, which we can't see clearly but know is out there somewhere.
It works. Period.
Hm, if you only descern "works" / "doesn't work" it's hard to say anything about the routing system... Some quantitative and qualitative analysis can be helpful.
And it will continue to work, because of the economic pressure. Engineers have found a solution, thus: Don't worry.
Guess what. I'm an engineer. I'm working on this stuff. And I'm saying: when de facto unlimited PI is allowed, it may not mean the end of the internet, but it's certainly reason to worry. Of course things will continue to work. However, they'll be less reliable and more expensive.
So because you can't prove that you're right I should just believe you without proof?
Yes, because the theory of computer sience gives you the prrof that there are theorems in this world which can't be proven.
There are also many theorems that turn out to be false. Proof is a pretty good method to avoid those. If we can't have proof we'll need to have less reliable methods to avoid them. Just accept anything is not the solution.
The scenario that de facto unlimited PI in IPv6 will make routing tables so large that it becomes problematic in some way or another is entirely reasonable, on the other hand.
The current experience let us make a reasonable and responsible assumption that a IPv6 routing table would take not much more growth than the current IPv4 table, whereas current technology permits tables of 10 to 100 times that size.
Today, people sometimes deaggregate a /16. That's bad: 255 unnecessary routes. What if they do the same thing with a /32 in IPv6? 65535 unnecessary routes. That will probably kill most existing IPv6 routers today. 10 times is 1.75M routes, 100 = 17.5. The former is probably doable for IPv4 on some extremely high end boxes but I'm not sure how those would handle real issues such as flapping, lots of full feeds etc. I don't believe the latter exists or will exist in the forseeable future, at least not in a way that anyone can afford to actually use. Even those 1.75M boxes will be very expensive and only affordable by the largest networks. Don't forget you and I all pay for their hardware, directly or indirectly. Iljitsch -- I've written another book! http://www.runningipv6.net/
On Tue, 6 Dec 2005 21:42:57 +0100, Iljitsch van Beijnum wrote:
I'm not sure I understand the "superprefix" but obviously a lot of work that now happens per-prefix in BGP should happen per-AS.
Yes. As typically all prefixes of an ISP are impacted by an upstream pipe break, it would make sense to bundle them together by the means of a protocol item and perform updates on the bundle/super-prefix only for as much operations as possible and use incremental superprefix member operations. This could be made hierachical, but on a protocol layer, not by a fixed adressing policy. It would save computing time on updates which is an issue.
I guess that means you throw everything in the TCAM first to get from 8M to about 125 entries and then look those up in a tree or hash table?
A bit different, otherwise it won't be an invention. DDRAM's have a special characteristic that helps a lot.
Obviously it's possible to build architectures that allow fast forwarding with big tables.
Yes.
However, this doesn't come free: it takes more iron to do this, and also more power. TCAMs suck down the juice like a depressed alcoholic. This is bad for your design (both the box itself and the datacenter), your wallet and the environment.
No. FUD only. A small single height eurocard is sufficient which draws less power than an average PC.
The point is to keep the aggregation inside the ISP network. Tier-1 ISPs would still have a full routing table, but rather than have a copy in each router, it's distributed over the network. So there is no free transit requirement. [...] The idea behind aggregation is that you can move up or down. If country borders get in the way, drill down a bit and start looking at provinces or cities. In our design there are potentially 64k distinct areas (mostly cities) so if you want, you can have a route for each of those in your routing table and never run into country borders.
Even we as a small ISP don't care about _city_ boundaries, they are absolutely irrelevant. In some cases there is no routing at all, it is just switched. Again: Country/City etc. boundaries are irrelevant, we have a directive in the EU which permits telco operation from any company in any member country in any other member country without license. It is just "hello, we do it now" registration. If an ISP specialises in the Elsass, it is likely that half of the net is in France and half in Germany. On the other hand for historical/business relation reasons our net is partially Bavaria and Baden-Wuerttemberg. The next ISP will support Bavaria and Saxonia, or Bavaria and Hessen (very likely due to existing infrastructure, I know several), than again Hessen and Baden-Wuertemberg, or Saarland, Luxembourg (nearby) and Hessen (DeCIX pipe, just taking additional customers there). Don't forget Bavaria and Austria, Bavaria and Switzerland or Austria and Switzerland. There is simply no mathematical consistent way to aggregate this by administrative boundaries. I am a friend of clear wording: Your RFC-suggestion paper is not functional in practice. Sorry for your paper, but math, physical laws and law's of economy don't care about personal oppinions expressed in papers.
??? Are we talking about spanning tree now? Loops in the topology are good. You can't remove them. Routing is also dynamic, BTW.
Again: Loop removal is the job of routing protocols, thus BGP contains a path attribute. As long as there is a usable and unrestricted (transit) connection, it works, as the Internet proves every day. We don't need to discuss problems which do not exist. Problems will arise if you arbitrarily split the routing table as you sugest in your RFC proposal. Thus simply don't do it and the problem is solved.
Ah, but we're not mathematicians but engineers. In software, you have one dimensional memory. Still, you can have multidimensional arrays.
Engineers should consider mathematical laws, otherwise they produce low quality. You may store multidimensional arrays, but this doesn't help you here in this task, which is exactly what your "algo" would require:
Easy: select everything that's in a 20x20 km grid around the center point and then do the real distance calculation on everything in that grid.
Aha: We take the already available solution and then do some additional calculation to present it ... No, if you sort the data inside a grid, you have to consider the eight neighbor grids, too, thus _nine_ checks. The grid size is fixed (we are talking about a database), which is very similar to the geographical address-policy problem: It is fixed, too. The grid works fine only for distances below the grid distance and not much below that, it requires nine grid cell checks for a single query etc.
Obviously you'll select stuff that's at x+8 y+8 = ~12km from the center but that's only true for a relatively small part of the intermediate results.
Obviously you have to consider neigbour grids, which is exactly the same problem as with the adressing policy: You have to consider neighbour countries, cities etc. with totally different prefixes in your model. My definately last argument to explain it, thereafter I will consider it as "trotzdem" and won't give further arguments: There is no reason to put Kehl and Strassbourg (Eurobridge) in different routing tables because they are in different countries. It is just a cable over the Rhine.
The variant Michel Py and myself came up with is based on administrative borders such as countries so you already have on dimension: the alphabet. (Ok, not entirely how it works, but still.)
Administrative border are _artificial_, the laws of math and economy don't care about them. Sorry, but for a working geographical adressing you would have to take a different scheme and even if RIPE would issue some address space based on interleaved coordinates you will find that even a geographical range search is a non-trivial task a router won't do on the fly. It takes much more computing power than a large table.
Guess what. I'm an engineer. I'm working on this stuff. And I'm saying: when de facto unlimited PI is allowed, it may not mean the end of the internet, but it's certainly reason to worry.
It definately doesn't mean the end of the internet, other RIR's issue PI, too. You might worry that an asteroid will hit us tomorrow, but this is not the issue of the address policy wg.
10 times is 1.75M routes, 100 = 17.5. The former is probably doable for IPv4 on some extremely high end boxes but I'm not sure how those would handle real issues such as flapping, lots of full feeds etc.
Today they can do. 1,75M is expected (except vendors with a customer-should-buy-new-box-because-we-limit-resources-by-company-policy attitude), 17.5M is really high end, but sounds not impossible.
Even those 1.75M boxes will be very expensive and only affordable by the largest networks. Don't forget you and I all pay for their hardware, directly or indirectly.
We pay much more for pipes than for hardware. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
The same is true for geographical aggregation. Geographical aggregation would require free transit, otherwise it is not compatible with the ISP's business models.
Geographical aggregation does not REQUIRE free transit. It is up to the ISPs to decide how to leverage geographical aggregation, how to recover transit costs and how to construct and change their business models. We should not assume that any of these things are static and unchangeable.
There is no free transit and thus it doesn't work. Business relations changes all the time and in a global markets world these business relations don't stop on country boundaries.
Such boundaries are artifical, the EU tries to avoid them.
Nevertheless, the Rhine river still exists. The Alps still exist. Is it easier to get fiber across the Rhine or through the Alps? This kind of geography affects the roads, railways and fiber paths throughout Europe. It affects the economy of European cities which determines the location and size of these cities. The city level of geographical aggregation clearly works. The real question is whether or not there is a level of aggregation possible between city and continent. I think that this question will only be solved by looking a the cities and the communication between them. In some regions there will be natural clusters of cities that form a natural aggregation grouping, for instance the U.S. East Coast. But in other areas there may be no clusters. In any case, national boundaries will almost never be related to these clusters except maybe someplace like China where culture, language and economy are closely tied to the national borders. But that is an exceptional case and perhaps it is no longer valid. Hong Kong, China has close ties with Singapore, another country. And cities like Khabarovsk, Russia probably have more economic ties with China than with Moscow. It's really a question for geographers to answer, not network engineers. So where are the geographers on this policy mailing list?
What they try is interleaving the West-East (X) and North-South (Y) coordinates bitwise in the search key and handle overruns by exceptions, like:
Geographical aggregation does NOT require geographical coordinates to be encoded in address bits. In fact, once the RIRs have decided how many addresses to reserve for each city greater than 100,000 population, and how to cluster cities in to larger groupings, there is no need for anyone to think about the geographical issues again. --Michael Dillon
On Wed, 7 Dec 2005 11:44:36 +0000, Michael.Dillon@btradianz.com said:
The same is true for geographical aggregation. Geographical aggregation would require free transit, otherwise it is not compatible with the ISP's business models.
Geographical aggregation does not REQUIRE free transit.
[Does Fedex deliver goods to everybody in a region if only one customer in the region pays for their service?] An alternative way to keep things local would be through enforced confederations or similar construct, where partitipants would have to share a common external routing-policy and transit costs. I suspect that quite a few small providers would object to be forced to cooperate with all their competitors. In some places it may even be considered anti-competitive by law. There may however be places where such cooperation is appropriate, in which case RIR-policies should accomodate such a construct. ISP's who want such cooperation should probably establish an independent organisation that would act as the LIR for their region. There's nothing (exept possibly the 200 customer limit) in the current RIR-policy that prevents such a construct. //per -- Per Heldal heldal@eml.cc
[Does Fedex deliver goods to everybody in a region if only one customer in the region pays for their service?]
Yes. That is part of their business model. The sender pays Fedex to deliver the parcel and they offer their service in regions that are receiver-dense as well as regions that are sender-dense or balanced.
An alternative way to keep things local would be through enforced confederations or similar construct,
Indeed, pointing a gun in somebody's face is always an option. However, in the realm of politics which we are discussing, this is an option that should not be under consideration. RIR policy is only concerned with address allocation, not with network provider contracts or with peering policy or facilities construction or anything else. The only thing that RIRs can enforce is address allocation policy and practice.
There may however be places where such cooperation is appropriate, in which case RIR-policies should accomodate such a construct. ISP's who want such cooperation should probably establish an independent organisation that would act as the LIR for their region. There's nothing (exept possibly the 200 customer limit) in the current RIR-policy that prevents such a construct.
As has been repeatedly pointed out by others, the 200 customer limit is a REAL block to deployment of IPv6 by many companies. Until IPv6 allocation policies are made reasonable without silly artificial constraints with no reasoning behind them, then it is a little early to discuss regional cooperative LIRs. One data point that we already have is exchange points. How many exchange points in Europe have been successful in receiving a /20 allocation from RIPE? How many in other regions? I suspect that the answer is zero because RIR policies discourage the allocation of IP addresses to such confederations. --Michael Dillon
Hi, On Wed, Dec 07, 2005 at 02:29:10PM +0000, Michael.Dillon@btradianz.com wrote:
One data point that we already have is exchange points. How many exchange points in Europe have been successful in receiving a /20 allocation from RIPE? How many in other regions? I suspect that the answer is zero because RIR policies discourage the allocation of IP addresses to such confederations.
Help me with this: how many customers (each getting a /48) does a typical exchange point have, and how do you reach a /20 from there? If you're going to split it into separate /32s or so, per connected ISP - where's the benefit for the ISP in getting address space from an IXP? (It might be cost effective, but that's not very much related to the IXP being an exchange point, more to being a "mega-LIR" with some cost benefits to its members). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Michael.Dillon@btradianz.com wrote: <SNIP>
Non-attributed person wrote:
There may however be places where such cooperation is appropriate, in which case RIR-policies should accomodate such a construct. ISP's who want such cooperation should probably establish an independent organisation that would act as the LIR for their region. There's nothing (exept possibly the 200 customer limit) in the current RIR-policy that prevents such a construct.
As has been repeatedly pointed out by others, the 200 customer limit is a REAL block to deployment of IPv6 by many companies.
Which companies? According to the stats* Leo gave only 6 requests where ever denied based on this. Can these companies please come forward and explain what they exactly want? * = http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-ap-ipv6number...
Until IPv6 allocation policies are made reasonable without silly artificial constraints with no reasoning behind them, then it is a little early to discuss regional cooperative LIRs.
"Regional cooperative LIRs" can already be made now, with current policy.
One data point that we already have is exchange points. How many exchange points in Europe have been successful in receiving a /20 allocation from RIPE?
Why would an exchange point need a /20? (IPv4 or IPv6?). Most IX's, not any I know of, don't have a need for so much address space and certainly, to stay neutral will not be able to provide address space to customers. If IX's did do that they would be a LIR-ISP again and there goes the I from PI.
How many in other regions? I suspect that the answer is zero because RIR policies discourage the allocation of IP addresses to such confederations.
Dig a bit and find live data: http://www.ripe.net/rs/ipv6/stats/ Also check: http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html Greets, Jeroen BTW: GRH doesn't cover IX assignments (yet), does it need to maybe?
On Wednesday 07 December 2005 15:52, Jeroen Massar wrote:
Michael.Dillon@btradianz.com wrote:
<SNIP>
Non-attributed person wrote:
There may however be places where such cooperation is appropriate, in which case RIR-policies should accomodate such a construct. ISP's who want such cooperation should probably establish an independent organisation that would act as the LIR for their region. There's nothing (exept possibly the 200 customer limit) in the current RIR-policy that prevents such a construct.
As has been repeatedly pointed out by others, the 200 customer limit is a REAL block to deployment of IPv6 by many companies.
Which companies? According to the stats* Leo gave only 6 requests where ever denied based on this. Can these companies please come forward and explain what they exactly want?
NATO is one org that could impacted. We plan to work around it but it depends on the definition of an "organization" and "customers". If one considers NATO as an organization (and not a alliance of organizations and nations), then NATO will not have any customers. But NATO has a large privately operated network that uses many ISPs and telcos for transmission services. Contracts have to be rebid on a regular basis. So requesting IP space from an ISP is a configuration stability issue that we don't like. Only for that reason allone, NATO "needs" to "own" a block of IP space not "owned" by a ISP. Now NATO can work around the 200-rule because NATO has its own service provider and we decided to consider NATO as an alliance of organizations. That is actually how NATO works so it is not bending the truth at all. So there are 200+ customers. But it is a bit artificial. I don't expect RIPE will reject a request but it illustrates the hoops that a large org with a large network that is part of their strategic assets will have to go through. OK one can just get space from an ISP but that effectively gives ISP lock-in as one does not want to reconfigure the core assets just for a contract rebid. Again, I think we have a solid work around but looking at the controversy that this discussion has caused, a non ISP-centric policy would be useful. Best regards, Marc -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm@nc3a.nato.int (PGP capable) This mail is not stating NATO policy but must be considered as informal exchange of views.
Marc van Selm wrote:
Which companies? According to the stats* Leo gave only 6 requests where ever denied based on this. Can these companies please come forward and explain what they exactly want? [..] Now NATO can work around the 200-rule because NATO has its own service
On Wednesday 07 December 2005 15:52, Jeroen Massar wrote: [..] provider and we decided to consider NATO as an alliance of organizations. That is actually how NATO works so it is not bending the truth at all. So there are 200+ customers.
Larger companies and organizations have an IT department, which most of the times even is an officially registered separate branch of such an organization. Branches of larger organization are also separately registered organizations, especially when crossing country borders this becomes very obvious for tax reasons and country law. The IT department or even special Networking department is effectively the "ISP" for the organization. That they only service customers of their mother company is not the question here: they service 200 customers. Another point with the 200 rule is that any employee making a vpn connection towards the network can already be consider to be a different endsite.
But it is a bit artificial. I don't expect RIPE will reject a request but it illustrates the hoops that a large org with a large network that is part of their strategic assets will have to go through.
Which hoop? Any construct of the above will have no problem in getting address space from any of the RIR's. If they do try and get rejected they should explain their situation here, if possible, and explain what they are missing so that the policy can be amended or a special policy be created for these cases.
Again, I think we have a solid work around but looking at the controversy that this discussion has caused, a non ISP-centric policy would be useful.
The only complains I have seen so far, from people who don't fit the magic 200 rule, is from sites that are real end-sites, sites that don't have any/much infrastructure except towards the IX or interconnect point with their upstream(s) and appear to not provide any/much connectivity to other organizations. For those sites a /32 would also be way too much address space, they would suffice with either a /40 or /48 already. For these sites there should come a separate policy so that they can request this address space, preferably allocated from a single global prefix for filtering reasons. Note very well that RIR's provide "Address Space", not "Routability", the latter is what you and your upstreams agree on. As a side note, any large organization using multiple access providers to connect to the Internet will budge into a hard problem, though this is mostly a routing issue: One has a /32, say 2001:db8::/32, which is the allocation for your organization. 2001:db8:1000::/48 is Amsterdam, 2001:db8:f000::/48 is Singapore. An employee from Singapore accesses a website in London. Traffic thus flows Singapore -> .sg ISP -> $inet -> London, the return traffic though flows London -> .nl ISP -> Amsterdam... oops. Indeed even though one gets a /32 allocated one will have to announce the /48's separately, or use some weird VPN tricks, when one doesn't have their own internal transit network. The problem here is again the filtering of >/32 which is taking place, though getting less in most places it still can cause a problem. Another more policy-wise issue with the above is that the idea and advantage of "Provider Aggregated" and thus less routes in the routing tables is mostly gone as most sites, the ones who effectively don't have their own transit networks, will have to announce the more specifics anyway. When the routing tables become $too_large there will have to be something to solve this issue and IMHO the PA idea will be great then, but will require that end-sites do some a double-NAT trick ala shim6 to/from the /48 which they got from their provider, that is the one with a global network.... Greets, Jeroen BTW: Everybody can of course use their IPv4 space to create IPv6 space: 2002:<aa.bb>:<cc.dd>::/48 or even bigger if you use your /24. Traffic engineering and everything works for that, one will have to rely on having working 6to4 relays though. But that is the same as having to rely on a working transit provider at the other end.
On Wednesday 04 January 2006 11:59, Jeroen Massar wrote: [...]
The IT department or even special Networking department is effectively the "ISP" for the organization. That they only service customers of their mother company is not the question here: they service 200 customers. [...]
But it is a bit artificial. I don't expect RIPE will reject a request but it illustrates the hoops that a large org with a large network that is part of their strategic assets will have to go through.
Which hoop? Any construct of the above will have no problem in getting address space from any of the RIR's. If they do try and get rejected they should explain their situation here, if possible, and explain what they are missing so that the policy can be amended or a special policy be created for these cases.
Yes you are right and that's how I'd like to treat it for NATO. The definition of an organization and customer is sufficiently flexible. So if flexibility of definitions is acceptable (non of us wants to be a lawyer I presume) than we should (should?) close the thread and move on. Best regards, Marc -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm@nc3a.nato.int (PGP capable) This mail is not stating NATO policy but must be considered as informal exchange of views.
Marc van Selm wrote:
On Wednesday 04 January 2006 11:59, Jeroen Massar wrote:
[...]
The IT department or even special Networking department is effectively the "ISP" for the organization. That they only service customers of their mother company is not the question here: they service 200 customers. [...] [..] Yes you are right and that's how I'd like to treat it for NATO. The definition of an organization and customer is sufficiently flexible. So if flexibility of definitions is acceptable (non of us wants to be a lawyer I presume) than we should (should?) close the thread and move on.
Thus indeed for you (NATO) the thread is closed. The flexibility of the policy was put in place to allow various setups to be meant for this policy. But there are apparently other organizations who do not fulfill the current policies requirements but do need address space. These folks *DO* need to come forward and raise their voices and specify how they don't fit in the current policy and how much address space they need. Greets, Jeroen
At 12:24 04/01/2006, Jeroen Massar wrote:
*** PGP Signature Status: good *** Signer: Jeroen Massar <jeroen@unfix.org> (Invalid) *** Signed: 04/01/2006 12:24:07 *** Verified: 05/01/2006 14:12:53 *** BEGIN PGP VERIFIED MESSAGE ***
Marc van Selm wrote:
On Wednesday 04 January 2006 11:59, Jeroen Massar wrote:
[...]
The IT department or even special Networking department is effectively the "ISP" for the organization. That they only service customers of their mother company is not the question here: they service 200 customers. [...] [..] Yes you are right and that's how I'd like to treat it for NATO. The definition of an organization and customer is sufficiently flexible. So if flexibility of definitions is acceptable (non of us wants to be a lawyer I presume) than we should (should?) close the thread and move on.
Thus indeed for you (NATO) the thread is closed.
The flexibility of the policy was put in place to allow various setups to be meant for this policy. But there are apparently other organizations who do not fulfill the current policies requirements but do need address space. These folks *DO* need to come forward and raise their voices and specify how they don't fit in the current policy and how much address space they need.
I thought I already did this. -- Tim
On Wed, 4 Jan 2006 11:12:19 +0100, "Marc van Selm" <marc.van.selm@nc3a.nato.int> said: [snip]
Again, I think we have a solid work around but looking at the controversy that this discussion has caused, a non ISP-centric policy would be useful.
The policy might seem ISP-centric, but that's just a coincidence. It reflects the opinion of many in the ops-community that it doesn't make sense to migrate to IPv6 until it is able to provide more than just an extended address-space. At least not as long as there is no *real* shortage of v4-addresses. Unfortunately, very few seem willing to admit that in public. The current policy will work in a future that has mechanisms to separate identifiers from locators. Maybe some people should revise their short-term expectations wrt IPv6. //per -- Per Heldal http://heldal.eml.cc/
At 13:38 16/01/2006, Per Heldal wrote:
On Wed, 4 Jan 2006 11:12:19 +0100, "Marc van Selm" <marc.van.selm@nc3a.nato.int> said: [snip]
Again, I think we have a solid work around but looking at the controversy that this discussion has caused, a non ISP-centric policy would be useful.
The policy might seem ISP-centric, but that's just a coincidence. It reflects the opinion of many in the ops-community that it doesn't make sense to migrate to IPv6 until it is able to provide more than just an extended address-space. At least not as long as there is no *real* shortage of v4-addresses. Unfortunately, very few seem willing to admit that in public. The current policy will work in a future that has mechanisms to separate identifiers from locators. Maybe some people should revise their short-term expectations wrt IPv6.
Notwithstanding this, there is some pressure in the research community for v6 to be available. And this translates downwards, at least for me, into a requirement to get some PI v6 space for a transit network. IPv6 is supposed to be an available and operational service, in which case the policy should cover all reasonable requirements. If it is not the case (i.e., not an operational or available service), but is still considered to be under development, not yet needed to be deployed, might need to be changed to introduce geographical addressing, or whatever else, then presumably this needs to be made evident and debated in a different forum. -- Tim
On Mon, 16 Jan 2006, Tim Streater wrote: [...]
Notwithstanding this, there is some pressure in the research community for v6 to be available. And this translates downwards, at least for me, into a requirement to get some PI v6 space for a transit network.
IPv6 is supposed to be an available and operational service, in which case the policy should cover all reasonable requirements. If it is not the case (i.e., not an operational or available service), but is still considered to be under development, not yet needed to be deployed, might need to be changed to introduce geographical addressing, or whatever else, then presumably this needs to be made evident and debated in a different forum.
I'm not sure how constructive this particular thread is. Transit networks are a simple case to deal in the policy. You could, for example, specify that if an ISP provides transit to other organizations which qualify (or have already qualified) for an allocation of their own, the transit network could also get an allocation. This has de-facto way the policy has been implemented already. It's the other parts of the policy that are trickier to address in an acceptable manner. Either we should focus the discussion on them (oh no, not again! :) or create a very specific policy amendment proposal that addresses the specific transit-only ISP case only. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Mon, 16 Jan 2006 14:26:50 +0000, "Tim Streater"
Notwithstanding this, there is some pressure in the research community for v6 to be available. And this translates downwards, at least for me, into a requirement to get some PI v6 space for a transit network.
Your organisation shouldn't have a problem getting adsress-space It is in everyone's best interest to get as many people as possible from the research community involved.
IPv6 is supposed to be an available and operational service,
really?
in which case the policy should cover all reasonable requirements. If it is not the case (i.e., not an operational or available service), but is still considered to be under development, not yet needed to be deployed, might need to be changed to introduce geographical addressing, or whatever else, then presumably this needs to be made evident and debated in a different forum.
I don't disagree, but: * The current policy will work just fine combined with a production-quality shim6 implementation, complete with full support for traffic-engineering and load-balancing from all vendors. I believe that still is a few years down the road. * Current policies and current v6 technology does not meet requirements from important groups like content providers wrt multi-homing and provider-independence. V6 could make a great p2p network if v6 can help eliminate NAT though ;) To me this mean there's a conflict here. Not only do people disagree wrt how things should be done, but also about what they want to achieve. //per -- Per Heldal http://heldal.eml.cc/
On Mon, Jan 16, 2006 at 05:46:22PM +0100, Per Heldal wrote:
* The current policy will work just fine combined with a production-quality shim6 implementation, complete with full support for traffic-engineering and load-balancing from all vendors.
Sorry, but please inform yourself about the technical details of shim6 first. There is no provision for traffic engineering in shim6 as we know, use and need it today. As a completely host-centric thing this ain't doable anyway, as a host has no faint clue about how the network is interconnected with others. And the idea of retrofitting such stuff into shim6 outright scares me (and many others). Let the network do it's job.
I believe that still is a few years down the road.
No, it's not even on shim6' radar. shim6 is not the droid we're looking for. And we don't even need Obi-Wan to make us believe that. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Wed, 18 Jan 2006 15:20:25 +0100, "Daniel Roesen" <dr@cluenet.de> said:
Sorry, but please inform yourself about the technical details of shim6 first. There is no provision for traffic engineering in shim6 as we know, use and need it today. As a completely host-centric thing this ain't doable anyway, as a host has no faint clue about how the network is interconnected with others. And the idea of retrofitting such stuff into shim6 outright scares me (and many others). Let the network do it's job.
I've read all proposals wrt shim6, mobile-v6 and other intiatives, and I'm not saying any of these is a solution on its own. At the same time there are hooks available for those with the right engineering-spirit to do something about it. If this flies, be sure there will be somone making something to syncronise locator-pair selection-mechanisms among large numbers of hosts in a network. Did session-handling end with TCP? Ever heard about products utilising TCP-functionality? Load-balancers? Firewalls? Any reason to belive that incremental improvements and development doesn't apply to other technologies. However, I did say that this will take years. The current V6 policy needs somthing like this, it's useless without. The polic has to be changed if you want to use V6 just as V4 is used today. Then the principle is simple; anybody that qualify for an assignment in v4 that is globally routable within RIR's prefix-filter-recommendations have to qualify for similar with v6.
No, it's not even on shim6' radar.
Not true. Potential "hooks" for traffic engineering are discussed in current proposals. [tech stuff really belong in the appropriate ietf-groups]
shim6 is not the droid we're looking for. And we don't even need Obi-Wan to make us believe that.
Agree, if you expect v6 to be immediately ready for general use. //per -- Per Heldal http://heldal.eml.cc/
At 01:20 AM 19/01/2006, Daniel Roesen wrote:
On Mon, Jan 16, 2006 at 05:46:22PM +0100, Per Heldal wrote:
* The current policy will work just fine combined with a production-quality shim6 implementation, complete with full support for traffic-engineering and load-balancing from all vendors.
Sorry, but please inform yourself about the technical details of shim6 first. There is no provision for traffic engineering in shim6 as we know, use and need it today.
You are referring to various forms of routing table abuse of course.
As a completely host-centric thing this ain't doable anyway, as a host has no faint clue about how the network is interconnected with others.
And yet once you draw further away from the host you run into the issues that we all know and love with NATS and other forms of packet header rewriting at a distance. So as a completely network-centric thing the problem you run into very quickly is how to distinguish assistance from attack. The network has no clue about intentions and all you achieve is a lowered attack threshold. Very useful indeed.
And the idea of retrofitting such stuff into shim6 outright scares me (and many others). Let the network do it's job.
Depends on your architectural vision - if the network's job is simple lossy connectionless packet forwarding along paths identified by working scaleable routing protocols, then precisely how does TE and other forms of architecture and routing abuse fit into this "job"? :-)
I believe that still is a few years down the road.
No, it's not even on shim6' radar.
Sorry, but please inform yourself about the details of shim6's agenda first. It is on the radar, and if you wish to contribute then put fingers to the keyboard and send in a draft as to _how_ it could be done.
shim6 is not the droid we're looking for. And we don't even need Obi-Wan to make us believe that.
Usual response: propose an approach, gather interest, call a BOF, formulate a plan, adopt a charter and get to work. Geoff
On 7-dec-2005, at 13:12, Per Heldal wrote:
Geographical aggregation does not REQUIRE free transit.
[Does Fedex deliver goods to everybody in a region if only one customer in the region pays for their service?]
That's not the right analogy. The right analogy is: does a Fedex truck driver in New York have a street map for Berlin? Answer: no. The NY Fedex driver knows that packages for Berlin should go to Europe. More specific routing information becomes available as the package gets closer to its destination. So Fedex does aggregate on geography, but only _internally_. Fedex as a whole still has all the detailed information for the entire world. (Well, the parts they serve at least.) Iljitsch -- I've written another book! http://www.runningipv6.net/
On Wed, Dec 07, 2005 at 09:47:24PM +0100, Iljitsch van Beijnum wrote:
On 7-dec-2005, at 13:12, Per Heldal wrote:
Geographical aggregation does not REQUIRE free transit.
[Does Fedex deliver goods to everybody in a region if only one customer in the region pays for their service?]
That's not the right analogy. The right analogy is: does a Fedex truck driver in New York have a street map for Berlin? Answer: no. The NY Fedex driver knows that packages for Berlin should go to Europe. More specific routing information becomes available as the package gets closer to its destination.
So Fedex does aggregate on geography, but only _internally_. Fedex as a whole still has all the detailed information for the entire world. (Well, the parts they serve at least.)
Interior Gateway Protocols... kind of like OSPFv3 for v6? --bill
Iljitsch
-- I've written another book! http://www.runningipv6.net/
On Wed, 7 Dec 2005 11:44:36 +0000, Michael.Dillon@btradianz.com wrote:
Geographical aggregation does not REQUIRE free transit. It is up to the ISPs to decide how to leverage geographical aggregation, how to recover transit costs and how to construct and change their business models.
A Management Consultant would say: "Our solution, your problem"
Nevertheless, the Rhine river still exists.
http://www.spiegel.de/politik/deutschland/0,1518,388814,00.html ( In English: Kehl and Strassbourg want to work jointly together to form a single Eurodistrict / city with e.g. a single phone network. ) The Rhine is no border at all for bits and bytes, use a STM-1 directional radio link.
The Alps still exist.
... and offer great opportunities for radio links, too. Again: A STM-1 between Frankfurt and London will be typically less expensive than between Frankfurt and Wiesbaden.
In fact, once the RIRs have decided how many addresses to reserve for each city greater than 100,000 population, and how to cluster cities in to larger groupings, there is no need for anyone to think about the geographical issues again.
And then every ISP puts in a prefix for his part of the geopolitical address range of every city in which it shows presence, thus giving us an enormous growth in the number of routing table prefixes. Great idea, obviously suitable for the "big prize" of the association of memory chip makers ... Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
Again: A STM-1 between Frankfurt and London will be typically less expensive than between Frankfurt and Wiesbaden.
This is not about cost. Does an STM-1 between Wiesbaden and London cost less than one between Wiesbaden and Frankfurt? Or does it pass through Frankfurt because it is a neighbouring city? If we did use a geotopological allocation scheme for another 1/8th of the IPv6 address space, this is an example of an area where there is a logical clustering of cities into a larger geographical aggregate. Wiesbaden, Mainz, Darmstadt and Frankfurt are all over 100,000 population. It is logical to reserve a single aggregate for them that covers all 4 city aggregates. That way, providers can choose to accept all city-level aggregate routes or to only see the single regional aggregate. Chances are that North American providers will only use the one regional aggregate while man Europeans will distinguish all 4 cities.
And then every ISP puts in a prefix for his part of the geopolitical address range of every city in which it shows presence, thus giving us an enormous growth in the number of routing table prefixes.
That's not how IP routing works. Anyone can announce any route that they want, but network providers filter incoming route announcements based on some sort of logical view of the network topology. In other words, they refuse to see details that they believe are unimportant to them. Geotopological addressing provides a nice framework for ISP filtering because they can ignore longer prefixes within a city aggregate if it makes sense for them to treat the entire city as a single destination. Geotop addressing doesn't mandate how filtering is done, it is just an enabler. --Michael Dillon
On Wed, 7 Dec 2005 14:40:47 +0000, Michael.Dillon@btradianz.com wrote:
This is not about cost. Does an STM-1 between Wiesbaden and London cost less than one between Wiesbaden and Frankfurt?
Between the right end points: Yes. Thanks to DWDM. The cost of leased lines is mostly dominated by - competition / available number of carriers - spare capacity - (central) locations of the end points It is no longer dominated by line length. This holds even true for regulated pricings like DTAG SFV/CVF in Germany, the new price list contains huge discounts for connections between backbone cities, smaller discounts between other cities and backbone cities versus full price for arbitrary connections, even thru there is still a distance component. However the influence of the distance component on pricing becomes very small on long distance leased lines.
Or does it pass through Frankfurt because it is a neighbouring city?
No. Frankfurt contains a lot of telco infrastructure with huge competition. You might even get a leased line between Frankfurt and New York with a pricing comparable to a local line. There is simply enough spare capacity, with DWDM you may put e.g. 400 GBit/s on a _single_ fiber pair. The whole DECIX has a peak throughput around 50 GBit/s. As long as there is a dark fiber, bandwidth is no longer an real issue.
If we did use a geotopological allocation scheme for another 1/8th of the IPv6 address space, this is an example of an area where there is a logical clustering of cities into a larger geographical aggregate. Wiesbaden, Mainz, Darmstadt and Frankfurt are all over 100,000 population. It is logical to reserve a single aggregate for them that covers all 4 city aggregates. That way, providers can choose to accept all city-level aggregate routes or to only see the single regional aggregate. Chances are that North American providers will only use the one regional aggregate while man Europeans will distinguish all 4 cities.
The key point is: The property "traffic belongs to ISP X" is _much_ more important than the property "traffic belongs to region Y". E.g. one might have a peering with ISP X, which means settlement free traffic exchange, compared to transit. Thus there is always the need for the full table if one would like to implement complex routing policies to consider quality and economical facts. As there is just one sorting criteria possible for an linear ordered address space, one must be the dominant, and this is by decision of the huge majority of the participants in the game: "ISP X". A regional ordering as dominant criteria would blow up the table dramatically, because of the need of the "from ISP" information for every region. What you can do: Make a proprosal to sort the minor adressing inside an ISP's allocation to regions. So one could use this additional information. But to be honest: I don't believe you will get acceptance on such a proposal, the infrastructure and distribution of customers to regions is too different between ISP's.
That's not how IP routing works. Anyone can announce any route that they want,
Of course you might filter out all routes and get no connectivity at all. Or you would need a default route which moves the job to the next Tier level, but doesn't solve the problem.
but network providers filter incoming route announcements based on some sort of logical view of the network topology.
As there is no guranteed transit or peering between different ISP's in a region, however as a peering or transit agreeement between ISP's typically covers the whole _company_, the primary sorting criteria for functional routing decisions and thus the MSB's in the Prefix address is the ISP company id. and not the region id. Again: Sorry, that I have no better news, it is the way it is. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
The cost of leased lines is mostly dominated by - competition / available number of carriers - spare capacity - (central) locations of the end points
It is no longer dominated by line length.
Of course, you are talking about esoteric costs measured in Euros that are only of interests to a few providers. To the vast majority of Internet users it is clear that a path between Wiesbaden and Frankfurt is much cheaper that a path from Wiesbaden to London to Frankfurt. That's because the vast majority of Internet users measure the cost of a path in milliseconds of delay.
Or does it pass through Frankfurt because it is a neighbouring city?
No.
Well actually, your first response could be interpreted to mean that it often does pass through Frankfurt but that someone determined to find the best price can find a path directly to London for a lower price. In any case, if everyone in the Frankfurt-Mainz-Darmstadt-Wiesbaden area decided to start using geotop addressing for their IPv6 routing that does not prevent Wiesbaden from favouring a direct path to London over a path through Frankfurt. And since Wiesbaden is over 100,000 population, it will have its own city reservation which will likely be accepted in route announcements in London even if it is filtered in route announcements in New York. And none of this has anything to do with what routes an ISP carries internally in their network. If a New York ISP sells a direct link to a Wiesbaden ISP, I would expect them to carry a Wiesbaden prefix in their IBGP even though most New York ISPs filter at the regional Fr-Ma-Da-Wi boundary. As for free transit, if this New York ISP accepts traffic for Wiesbaden in their San Francisco PoP then they can easily identify it and pass through a charge to the Wiesbaden ISP. But if the Wiesbaden ISP does not agree to pay such charges then the New York provider can also easily block such traffic at their San Francisco PoP. An address allocation scheme does not mandate operational or business activities.
The key point is: The property "traffic belongs to ISP X" is _much_ more important than the property "traffic belongs to region Y".
End users, especially in the USA, disagree with you. They think that the traffic belongs to the end user and that the ISP is paid to carry it to its destination, period.
E.g. one might have a peering with ISP X, which means settlement free traffic exchange, compared to transit. Thus there is always the need for the full table if one would like to implement complex routing policies to consider quality and economical facts.
A smart ISP would consider that settlements and similar things would be better handled in OSS servers rather than in routers. And then the routing table size is no longer such an issue.
A regional ordering as dominant criteria would blow up the table dramatically, because of the need of the "from ISP" information for every region.
Nothing will blow up the table dramatically because routes do not get into the table unless they get past ISP filters. An ISP with PoPs in 30 cities is free to announce all their city level allocations to all their peers, and the peers are free to ignore any prefixes that are longer than the city-level prefixes as issued by the RIR route registry. --Michael Dillon
On Wed, 7 Dec 2005 16:11:50 +0000, Michael.Dillon@btradianz.com wrote:
Of course, you are talking about esoteric costs measured in Euros that are only of interests to a few providers.
Aha. Then probably you own an interesting device called legal_bank_note_production_engine, because typically providers as real companies tend to charge their cost to their customers in one or the other way. Please let me know where I can obtain such a device, but please be aware I can accept legal offers only.
To the vast majority of Internet users it is clear that a path between Wiesbaden and Frankfurt is much cheaper that a path from Wiesbaden to London to Frankfurt.
"Trotzdem". For me the discussion dosn't make any further sense at this point. Ask the carrier of your choice about pricing. Btw.: Latency UK/Germany is typically around 30ms. DSL Latency home to BBRAR/LAC ist typically 60ms. People take the DSL ... So much about your theory.
End users, especially in the USA, disagree with you. They think that the traffic belongs to the end user and that the ISP is paid to carry it to its destination, period.
It is paid in "esoteric costs measured in Euros", not in latency time units. Probably US dollars, swiss franc or yen are acceptable, too. And yes, cost is a primary issue for most customers. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
On 7-dec-2005, at 13:12, Oliver Bartels wrote:
( In English: Kehl and Strassbourg want to work jointly together to form a single Eurodistrict / city with e.g. a single phone network. )
The point isn't that geographical addressing fits perfectly with the way network topologies are laid down. The point is that there is a decent saving, of say, a factor 10 or better. In practical terms: if Kehl and Strassbourg (Straßburg?) are on different sides of a national border but they're part of the same topological entity in the network, you simply have the Kehl routes in Strassbourg and the Strassbourg routes in Kehl. So rather than have one set of routes you have two. Obviously that means twice as many routes as you'd have when the geographical addressing was aligned with topology, but it's still a factor 32768 better than what you'd have with flat PI so who cares. And, for 90% of the routers throughout the world, both aggregate to "western europe" anyway. -- I've written another book! http://www.runningipv6.net/
Michael.Dillon@btradianz.com said:
Nevertheless, the Rhine river still exists. The Alps still exist. Is it easier to get fiber across the Rhine or through the Alps?
It's not that hard any more.
This kind of geography affects the roads, railways and fiber paths throughout Europe. It affects the economy of European cities which determines the location and size of these cities. The city level of geographical aggregation clearly works.
Not so. To a first approximation, there is *no* level of aggregation in the UK that works below UK-wide. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |
To a first approximation, there is *no* level of aggregation in the UK that works below UK-wide.
If that were really true, and I suspect that it is only true for the very largest providers, then there is an easy solution. Providers who see no benefit in using geotop addressing should continue to use classical IPv6 addressing. Geotop addressing is not a prescription for rearchitecting the Internet, just an enabler for ISPs who want to give small and medium size organizations real multihomed diverse connectivity to the Internet. These organizations will consume hundreds of thousands of AS numbers and global routing slots unless their routes can be collapsed into city aggregates. --Michael Dillon
On 7-dec-2005, at 15:58, Michael.Dillon@btradianz.com wrote:
To a first approximation, there is *no* level of aggregation in the UK that works below UK-wide.
If that were really true, and I suspect that it is only true for the very largest providers, then there is an easy solution. Providers who see no benefit in using geotop addressing should continue to use classical IPv6 addressing.
Rather than debate wheter someone in Aberdeen is really going to multihome to ISPs in Norwich and Belfast, let me observe that aggregating at the European national level is just fine. The largest countries in Europe each have about 1% of the world's population. So if they also have 1% of the routing table we can have 100 times as many routes as we could without geographical aggregation. That should give us plenty of breathing room. It's harder for the US because there are no easy demarcations there. -- I've written another book! http://www.runningipv6.net/
Hi Oliver, You wrote: [...]
P.s. @RIPE NCC: Question: Is there a practical way to replace the slow and cumbersome "consensus" principle of the RIPE by a democratic majority vote of the RIPE NCC members to stop further damage to IPv6, perhaps with a decision at the next RIPE NCC general meeting ?
Of course some RIPE participants might then discuss adresss policies for ever, but for the RIPE NCC members we would then probably have practically acceptale policies for implementation in real world networks.
I suppose that changes to the Policy Development Process (PDP) have to go through the PDP. If you want to submit a proposal to that effect then you need to complete a proposal template and pass it to the relevant WG chair. You can find the template at: http://www.ripe.net/ripe/policies/proposals/template/ There are also links to the main documents on that page. Regards, -- leo vegoda RIPE NCC Registration Services Manager
The internet only works as long as 99% of all people carry 99% of all routes. When a sizeable number of people starts filtering a sizeable number of routes for whatever reason, either technical (won't fit in their routers) or political (don't agree with the policies) then we're in knee-deep brown stuff.
And this is something that RIPE and ARIN cannot directly change. RIR policy can only encourage or discourage ISPs from carrying 99% of all routes. I think that the current policy for IPv6 is one which discourages people from using IPv6. Adding a second type of IPv6 address that is allocated geographically to allow greater topological aggregation (i.e. based on which city the network is in) will encourage use of IPv6 by making it easier for people to get IPv6 addresses. --Michael Dillon
Michael and all, Good point here Michael... Michael.Dillon@btradianz.com wrote:
The internet only works as long as 99% of all people carry 99% of all routes. When a sizeable number of people starts filtering a sizeable number of routes for whatever reason, either technical (won't fit in their routers) or political (don't agree with the policies) then we're in knee-deep brown stuff.
And this is something that RIPE and ARIN cannot directly change. RIR policy can only encourage or discourage ISPs from carrying 99% of all routes. I think that the current policy for IPv6 is one which discourages people from using IPv6. Adding a second type of IPv6 address that is allocated geographically to allow greater topological aggregation (i.e. based on which city the network is in) will encourage use of IPv6 by making it easier for people to get IPv6 addresses.
--Michael Dillon
Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Obediance of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827
"Too late" at least for a full solution. This is just another suggestion that might be helpful for preventing some amount of global prefixes (see below), but not god's own solution to the problem.
The world does not need full solutions. In regard to IP addressing policy, it is sufficient for the RIRs to start doing things more wisely. If the RIRs would open up another 1/8th of the IPv6 address space for geotop allocations then they would no longer be blocking this solution. It is not up to the RIRs to tell ISPs how to operate their networks, i.e. the RIRs cannot say that ISPs must accept announcements of PI /26s allocated by the RIRs. The ISPs are in control of what they do. But, in the area of geo-topological aggregation of announcements, ISPs are currently prevented from acting because the RIRs won't give out geotop allocations. --Michael Dillon
On 12/7/05, Michael.Dillon@btradianz.com <Michael.Dillon@btradianz.com> wrote:
In regard to IP addressing policy, it is sufficient for the RIRs to start doing things more wisely. If the RIRs would open up another 1/8th of the IPv6 address space for geotop allocations then they would no longer be blocking this solution.
IIUC, the RIRs don't have another 1/8 of the space to "open up". they don't even have the whole of the first 1/8. IANA holds the global pool. The NRO *could* be helpful in lobbying for this, if their communities asked it of them. -- Cheers, McTim $ whois -h whois.afrinic.net mctim
On 7-dec-2005, at 12:13, McTim wrote:
In regard to IP addressing policy, it is sufficient for the RIRs to start doing things more wisely. If the RIRs would open up another 1/8th of the IPv6 address space for geotop allocations then they would no longer be blocking this solution.
IIUC, the RIRs don't have another 1/8 of the space to "open up". they don't even have the whole of the first 1/8. IANA holds the global pool. The NRO *could* be helpful in lobbying for this, if their communities asked it of them.
When Michel Py and I worked on this, our design goal was to support 1 billion multihomers, or 1 multihomed geographically aggregatable PI (GAPI) prefix per 10 inhabitants of the world in the year 2050. We decided to assume upto 65536 regions with upto 65536 multihomers in them. That's over 4 billion and takes just a /16, with a factor 4 margin for error and assignment inefficiencies. It would be possible to increase to a slightly shorter prefix but that's not really needed in the forseeable future: we're currently at one in 25000 multihomers or lower in the US and Europe, so there is room for a factor 2500 growth before the /16 is depleted. Also, there is no reasonable way to do geographical aggregation within a metropolitan area, and at more than 1 in 10 we're quickly going to run into routing table problems within the world's largest cities (2.5 million multihomers in Mexico City...). -- I've written another book! http://www.runningipv6.net/
Well, you haven't been paying attention, because I've presented "provider-internal aggregation based on geography" at two different RIPE meetings a while ago.
The only thing I got was perplexed stares.
If your presentation was as cursory as the slides I saw on the web, I'm not surprised that you got perplexed stares. I think that people need to be led through the concept step by step in more detail. Also, you need to deal with existing prejudices. Most people have preconcieved notions about geographical addressing which boils down to geo = bad. They either think it is some flaky idea about encoding physical coordinates in addressing, or some idea about giving nation states control over addressing or something that was rejected by the IETF in the past and therefore cannot be retrofitted in the IPv6 protocol. It is a big job to get past these prejudices and get people to actually think about things. The root of the idea is for the RIRs to cooperate in allocating IP addresses so that they can be aggregated more widely. In other words, so that it is not necessary for every allocation to become an announcement in the global routing table. Of course, this means that RIRs and ISPs have to cooperate in allocating IPv6 addresses using a rough kind of geographical plan. I suggest that this plan be anchored to the major cities where most interconnecting is done. This is also roughly aligned with the topology of the network if you can manage to visualize an entire city (Paris, London, Hannover, Krivoy Rog) as a single node in a network. It's that level of abstraction that leads to making sense of this kind of aggregation. As you pointed out in the slides, it is not necessary for interconnect to happen in a specific geographical location in order to gain some benefit from this. Of course, one would hope that eventually every ISP will migrate to interconnecting in each city where they carry traffic, but that is not a precondition. I have taken to calling this kind of thing "geotop" addressing because it comes from noticing that there is a "rough" alignment between geography and topology. I think we should leverage that rough alignment to dampen routing table growth, and therefore buy time in the same way that we bought time with CIDR and dampening of growth in IP address allocation. --Michael Dillon
On Wed, 7 Dec 2005 10:32:20 +0000, Michael.Dillon@btradianz.com said: [snip]
Of course, this means that RIRs and ISPs have to cooperate in allocating IPv6 addresses using a rough kind of geographical plan. I suggest that this plan be anchored to the major cities where most interconnecting is done. This is also roughly aligned with the topology of the network if you can manage to visualize an entire city (Paris, London, Hannover, Krivoy Rog) as a single node in a network. It's that level of abstraction that leads to making sense of this kind of aggregation.
... and free transit into each geographical region would be mandatory ??? Aggregation across multiple administrative domains isn't just a minor technical change. It would eliminate the transit-provider business model. Disruptive technologies are facts of life and nobody has a god-given right to existence, but don't expect long-haul carriers to give up their business without a fight. //per -- Per Heldal heldal@eml.cc
... and free transit into each geographical region would be mandatory ???
Aggregation across multiple administrative domains isn't just a minor technical change. It would eliminate the transit-provider business model. Disruptive technologies are facts of life and nobody has a god-given right to existence, but don't expect long-haul carriers to give up their business without a fight.
Transit provider business models are not the same everywhere. Nobody will be forced to give anyone free transit. Yes, it is true that geotop aggregation leads to more use of cold-potato routing, but that is a problem for the providers to deal with. If they want to use geotop aggregation and if it results in a shift of traffic patterns and if that requires negotiating new business models or transit contracts then there are no technical barriers to doing this. RIRs can only make addressing policy, not mandate business models. As long as geotop addressing is implemented in addition to the classical IPv6 addressing model, nobody will be forced to do anything that they don't want to. However, new entrants into the market will be able to do things that are impossible today. This will lead to change. The fact that a new addressing policy does not create miracles, only possibilities, is not sufficient reason to oppose such a policy. In fact, it is likely that existing providers will dip their toes in the water and make some limited use of geotop addressing to enable them to offer new metro-multihoming services to small organizations that only need multihoming within a single city. This is fairly straightfoward to do. In addition to geotop addressing, it only requires two providers to negotiate a local peering agreement and that is probably already in place for classic IPv4 peering. In any case, none of these problems are insurmountable and none of them dilute the case for geotop addressing as AN ADDITIONAL OPTIONAL TYPE OF IPV6 ADDRESSING. --Michael Dillon
Marc, you have just observed the biggest brokeness of the entire IPv6 policy. There are many (thousands in fact) having the same problem as you do. To make IPv6 a (commercial) success there MUST be PI address space to allow for corporations (non-ISPs) to natively multihome and to switch ISPs without renumbering the entire network. Neither problem has been solved yet in the current IPv6 policy or proposals. In its current state the IPv6 policy is a total non-starter. There is NO WAY for large corporate and government entities to put them at the mercy of any single random ISP again. They've learned it the hard way with IPv4 already and go exclusively with PI address space now. NATO is a prime example for this. I'm doing a lot of consulting for large enterprises regarding IP addressing, multihoming and ISP independence. Based on that experience I can say with ABSOLUTE CERTAINTY that with the current policy IPv6 does not NOT get adopted AT ALL in any large corp. To all the nay-sayers and ignorants in the die-hard IPv6 camp I can only recommend that they put yourself into the shoes of a large coporation with 10,000 employees for a day. And then ypu think about how to connect this shop to the Internet in a competitive way. You'll come to the conclusion that with IPv6 you simply can't. -- Andre Marc van Selm wrote:
Following up on the discussion during RIPE-51, I have not heard much discussion on "200 customer requirement for IPv6" rule. So I would like to hear your views on this.
During RIPE-51 the proposal to remove the rule caught serious objections. I can sympathise with those but I do have an issue that I'd like feedback on.
I am investigating how NATO should acquire IPv6 address space. NATO will use multiple transmission providers, NATO owned transmission and national networks. Also transmission contracts will have to be opened for bidding every few years. That makes requesting IP space from an ISP a non starter. So we explore the LIR route. Note that NATO has a service provider under its umbrella that provides service towards the other NATO organisations. They operate independently and are like an ISP (and more) for that matter. They are just not selling outside NATO.
At this time it is reasonably hard to specify the 200 /48 that will be given out for the "IPv6 Initial Allocation Request". Having reached about 130 or so on my list (not finished yet) I can't help wondering why RIPE-NCC should care about a list of sites that they only a vague clue of what they are and have no means of verification if the list is correct. Having said that, I get the feeling that the 200 rule only ads admin overhead and has limited actual power. Now NATO could include a summarised version in the Initial Allocation and do something like:
Subnet: /48 1 year 5 regional sites (/48 per site = 5x /48) Subnet: /48 1 year 20 subordinate sites to the 5 regional sites (/48 per site = 5x 20x /48 = 100 /48) Subnet: /48 2 year 40 deployed elements (/48 per site = 40x /48) Subnet: /48 2 year 70 Crisis Response Operation locations (/48 per location = 70 x /48) Total: 215x /48
Note that the numbers are fiction but they are not very unrealistic as we also need to include standby elements that are ready to go (power up, aim dish and run) systems. Although close to the truth, RIPE-NCC would have no way of verifying this and providing a detailed list would bury RIPE-NCC in details that they don't care about and also cannot verify.
I can't help feeling this rule is written for ISPs but will be counter productive for NATO and organisations with a very large privately operated enterprice network. I also can't help the feeling that its a paper tiger. So isn't there another way to achieve the same result as this rule was intended for?
Any views?
Marc -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm@nc3a.nato.int (PGP capable)
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Andre Oppermann
There is NO WAY for large corporate and government entities to put them at the mercy of any single random ISP again. They've learned it the hard way with IPv4 already and go exclusively with PI address space now.
NATO is a prime example for this. I'm doing a lot of consulting for large enterprises regarding IP addressing, multihoming and ISP independence. Based on that experience I can say with ABSOLUTE CERTAINTY that with the current policy IPv6 does not NOT get adopted AT ALL in any large corp.
I am not going to say you are incorrect because you aren't, but speaking as a LIR and internet service provider you need to have a look at the possibilities: We have customers of so high importance, "NATO style", that we need multihomed lines to them; multihomed in the way that they have multiple lines but only to us, but if one goes down then the others are still up using HSRP, BGP etc. So should these customers perhaps get PI instead because they sooner or later will as you say "learn" that we cannot provide a good service? I have also configured redundant lines for other companies to other ISPs than the one I work for where these lines only go to a single ISP. I have not received any indication of that they wanted PI instead and multiple ISPs, nor did I suggest that they should get PI so we could sell them a line too because I did not see the reason for it. Nobody here is thinking about bankruptcy anyway. I don't really have any valid arguments for or against PI. I am just telling some facts of what some non-PI holders do today. Joergen Hovland
On Friday 18 November 2005 09:42, Jørgen Hovland wrote: [...]
We have customers of so high importance, "NATO style", that we need multihomed lines to them; multihomed in the way that they have multiple lines but only to us, but if one goes down then the others are still up using HSRP, BGP etc. So should these customers perhaps get PI instead because they sooner or later will as you say "learn" that we cannot provide a good service?
Joergen, yes that are connectivity resilience issues with a strong relation to the ISP. You probably do not need PI for that. What I'm talking about is 2 or 3 providers that provide worldwide service between a large number of locations. Contracts are rebid with regular intervals (is required). Individual circuits are can be provided by local providers or national networks and NATO owned circuits. In other words, a true multi provider environment. We are not speaking about internet service but transmission services for enterprice VPNs. [...]
Joergen Hovland
-- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm@nc3a.nato.int (PGP capable)
Andre Oppermann wrote:
There is NO WAY for large corporate and government entities to put them at the mercy of any single random ISP again. They've learned it the hard way with IPv4 already and go exclusively with PI address space now.
Have you ever taken a look at the list of companies that already have an IPv6 allocation??? FYI: Check http://www.sixxs.net/tools/grh/dfp/all/ There seem to be quite a large number of 'corporations' which don't typically fit the ISP bill according to many people. Again: Fill in the forms and go to RIPE/ARIN/LACNIC/AFRINIC/APNIC. If you are really too small, that is you have at most 10 sites, then you simply are too small. I still have not heared anybody getting rejected by RIPE, except for some home users wanting /32's over DSL and other silly stories. Greets, Jeroen
Jeroen Massar wrote:
Andre Oppermann wrote:
There is NO WAY for large corporate and government entities to put them at the mercy of any single random ISP again. They've learned it the hard way with IPv4 already and go exclusively with PI address space now.
Have you ever taken a look at the list of companies that already have an IPv6 allocation???
FYI: Check http://www.sixxs.net/tools/grh/dfp/all/
There seem to be quite a large number of 'corporations' which don't typically fit the ISP bill according to many people.
Sorry, I've gone through the list and looked for familiar non-ISP names in the RIPE region and especially Germany/Switzerland. I haven't found any smoking gun with the exception of CH-KSZ-20050103 which clearly is not even remotely an ISP. For the APNIC region I don't see any obvious non-ISP entities but then I'm not familiar with that region. In the ARIN region I can find some non-ISP entities but in no way a majority. Most of the time they are a corp and an ISP (Microsoft & MSN for example). To summarize: From a coursory examination of the IPv6 allocation table more than 95% appear to be bona fide ISP allocations without having bent the rules. My feeling is the number is even closer to 99% than 95%.
Again: Fill in the forms and go to RIPE/ARIN/LACNIC/AFRINIC/APNIC.
That the problem, I can't. I can't fill out a PI request for them and send it under my LIR name to RIPE. My friendly mega-corp customer would have to be become a LIR themselfes. While that is not that much of a problem they don't fulfill the 200 external customer requirement. They don't have any external customers. On top of it they are not the least bit interested in becoming a LIR with all the associated procedures and everything. They don't go to LIR training courses. It just makes the life miserable for them and the poor RIPE hostmaster who have to deal with their address requests. While I'm glad to consult with mega-corp it's not the way it should be. The IPv4 PI way was better dealing with this type of situation.
If you are really too small, that is you have at most 10 sites, then you simply are too small.
This just rules out getting a /32. It should not rule out getting the ability to properly multihome or to be ISP independent.
I still have not heared anybody getting rejected by RIPE, except for some home users wanting /32's over DSL and other silly stories.
I'd chances are high that you don't hear from them is because they are not ISPs and thus don't have any connections to (our) ISP community. -- Andre
On Fri, Nov 18, 2005 at 10:52:05AM +0100, Jeroen Massar wrote:
If you are really too small, that is you have at most 10 sites, then you simply are too small.
Who are you to decide who is too small to be allowed independence? Who are you to decide that size is the determining factor for that? /me goes looking wether human rights are dependent on body size. [and before anyone starts argueing that technical and economical independence from their ISP(s) are not a human right: you know what an analogy is?] Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Fri, Nov 18, 2005 at 07:25:49AM -0800, Randy Bush wrote:
If you are really too small, that is you have at most 10 sites, then you simply are too small. Who are you to decide who is too small to be allowed independence?
someone with routers which have to carry all those prefixes
You mean the very small tier 1 club? All others can default and don't _have_ to carry all those prefixes. Or do you mean the ISP community at large which tries to fulfil customer requirements and make money with that? The customer requirement is full technical and economical independence from their suppliers. And the ISPs (minus the Tier 1s) can default to their upstreams, they don't need to carry full tables - unless their customers do ask for that. It's all about fulfilling customer requirements. What's _your_ solution to this problem _now_ in IPv6? Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Who are you to decide who is too small to be allowed independence? someone with routers which have to carry all those prefixes You mean the very small tier 1 club? All others can default and don't _have_ to carry all those prefixes.
no, that's not what i mean and you know it. the number of t1s is a very tiny percentage of those carrying full routing. you may wish it otherwise. i may wish it otherwise. but until there is solid technology to support better routing, that's life. get used to it.
What's _your_ solution to this problem _now_ in IPv6?
stop deployment, which is negligible anyway, and fix the technology. and fixing is not applying endless half-assed hacks that don't actually do the job. we're gonna live with this stuff for a very long time. it should be very far more solid design than it is. if we're patching now, what will be the kludge level 20 years from now? randy
On Fri, Nov 18, 2005 at 09:03:20AM -0800, Randy Bush wrote:
Who are you to decide who is too small to be allowed independence? someone with routers which have to carry all those prefixes You mean the very small tier 1 club? All others can default and don't _have_ to carry all those prefixes.
no, that's not what i mean and you know it. the number of t1s is a very tiny percentage of those carrying full routing. you may wish it otherwise. i may wish it otherwise. but until there is solid technology to support better routing, that's life. get used to it.
You conveniently ignore the fact that all those others don't HAVE to carry all those prefixes. Which I even stated in the quoted paragraph.
What's _your_ solution to this problem _now_ in IPv6?
stop deployment, which is negligible anyway, and fix the technology.
You're welcome to find 42. Others tried hard, unsuccessfully.
and fixing is not applying endless half-assed hacks that don't actually do the job.
Which job? For how long?
we're gonna live with this stuff for a very long time. it should be very far more solid design than it is. if we're patching now, what will be the kludge level 20 years from now?
No idea. What will be problems in 20 years from now? You claim you can find the technology which won't impose problems on us for the next 20 years to come? Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Randy Bush wrote:
Who are you to decide who is too small to be allowed independence? someone with routers which have to carry all those prefixes You mean the very small tier 1 club? All others can default and don't _have_ to carry all those prefixes.
no, that's not what i mean and you know it. the number of t1s is a very tiny percentage of those carrying full routing. you may wish it otherwise. i may wish it otherwise. but until there is solid technology to support better routing, that's life. get used to it.
What's _your_ solution to this problem _now_ in IPv6?
stop deployment, which is negligible anyway, and fix the technology. and fixing is not applying endless half-assed hacks that don't actually do the job.
we're gonna live with this stuff for a very long time. it should be very far more solid design than it is. if we're patching now, what will be the kludge level 20 years from now?
Here comes Andre's guide to fix IPv6(tm): 1. Make /32 the only routable entity so we can use perfect match in the DFZ instead of longest-prefix match. Perfect match scales better and is way more economically to implement in hard- and soft- ware. (MPLS is perfect match too.) Beyond /32 use longest-prefix up to /64. 32 bit in the DFZ give us 4 billion routable entities. See "Scalability issues in the Internet routing system" thread on NANOG, starting 18. October 2005. 2. Drop the Flow Label and Next Header fields from the IPv6 header. They are architectually broken and do not belong to this layer. Just encapsulate the packet in another layer like MPLS. Next Header is broken because it's just source routing again. Dead for a long time. Nobody in their right mind will allow header popping through their firewall/network. 3. Reinsert packet fragmentation into the IPv6 header. Path MTU discovery just ain't cutting it. 4. Drop 64 bits from the IPv6 address. The lower 64 bit are just pointless as host indentifier. Very poor overhead ratio. 6. Do away with those stupid ':' separators in IPv6 addresses. No, I'm not joking. It ain't to late yet to fix it. Details and variations can be discussed. ;-) -- Andre Oppermann oppermann@networx.ch - AS8271 andre@freebsd.org - TPC/IP Kernel Developer
At 09:52 18/11/2005, Jeroen Massar wrote:
If you are really too small, that is you have at most 10 sites, then you simply are too small.
Actually two sites at present. But I wouldn't call a network that will provide v6 transit for the NRENs of a dozen or so Mediterranean countries "small", in the sense of significance. As I said, I haven't looked at this issue for a while, but I do recall that the policy was: 1) Getting space required the 200 customer plan 2) No PI space for v6 If this is the stated policy, doesn't seem much point in making an enquiry. If I were able to get the space, (1), and (2) notwithstanding, what would be the point of the policy? The present policy models a small portion of reality, and appears to leave major portions unprovided for, as others e-mails have attested. -- Tim
On Thursday 17 November 2005 17:15, Marc van Selm wrote:
Following up on the discussion during RIPE-51, I have not heard much discussion on "200 customer requirement for IPv6" rule. So I would like to hear your views on this.
Nice to see this discussion reviving. From what I hear I can draw the following conclusions for NATO (and large enterprices with a private WAN): 1) RIPE-NCC would be happy with a summarised version of our plan and does not care about the details of 200+ /48 assignments. As soon as Leo Vegoda is back from his leave, I'll know for sure if RIPE-NCC will accept it. But I get the feeling they will. 2) The 200-rule, although strongly defended during RIPE-51, remains controversial. I guess another qualifier must be introduced to satisfy both camps. 3) PI IPv6 space seems to be the solution to the large enterprice problem. If the RIR would allocate it directly to the end-customer, orgs like NATO do not have to become a LIR. They just have a block that they "own" and can contract out to an ISP of their choice to route (and rebid the contract every few years or so as the procurement rules require) or route (part of it) via private circuits. I'd say replace the 200-rule with something like the intention to use at least X /48 subnets distributed over Y or more geographical locations while using private WAN infrastructure or more than one ISP. I think that X and Y should be not so large. (To the side, we could accept a smaller block, like a /34, also for now but we all know that growth in the next 10 years is imminent so RIPE-NCC would reserve the whole /32 and probably more anyway.) Anyway, I think something like this would do the same as the 200-rule was intended for while is it not such a straight jacket. Although I think the action to write something about that was on somebody else... What do you all think about this approach? Especially the Nee sayers during RIPE-51 that have been a bit quiet until now. Marc -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm@nc3a.nato.int (PGP capable)
participants (23)
-
Andre Oppermann -
Andre Oppermann -
bmanning＠vacation.karoshi.com -
Clive D.W. Feather -
Daniel Roesen -
Geoff Huston -
Gert Doering -
Iljitsch van Beijnum -
Jeff Williams -
Jeroen Massar -
JORDI PALET MARTINEZ -
Jørgen Hovland -
Kurt Erik Lindqvist -
leo vegoda -
Marc van Selm -
McTim -
Michael.Dillon＠btradianz.com -
Oliver Bartels -
Pekka Savola -
Per Heldal -
Randy Bush -
Sascha Lenz -
Tim Streater