Re: [address-policy-wg] Status of 2011-02 Policy Proposal Removal of multihomed requirement for IPv6)?
Geza,
I do see it differently. PI address space is easy to use, however, this allocation mechanism does not scale. Therefore was invented CIDR and PA allocation, if you do remember...
Could you eleborate on "does not scale" ? When deploying IPv6 one should set aside an IPv4 mindset. The same goes for the whole rehashing of the "does not scale" issue. You can't expect early 90's routing hardware to do the job of current BGP Internet routing. And when everyone will be running IPv6 (not tomorrow), the current limits for hardware won't apply. Let's not go into a discussion on asics / 64-core cpu's, but I'm pretty certain that hardware including tcams etc will keep up if the market demands it. Maybe you're referring to something altogether different, that's why I ask. I fully concur with Thomas on this point: for all the IPv4 PI allocations out there it should be possible to get an IPv6 allocation as well. Indeed nothing has changed with regard to the reasons for applying and being granted PI space. The current policy kind of suggests that everyone with IPv4 PI space should just quit their business and hand it over to the LIR as they are the only ones getting PI space for customer traffic. Regards, Albert
Turchanyi Geza schrieb am 07.11.2011 10:02: nothing stops th IPv4 PI owners to use IPv6 PA....
Nothing stops anybody of using PA, neither in IPv4 nor in v6. That's not the question.
But any reasons, why somebody wants/needs IPv4 PI space will usually fully apply to IPv6 also. It would seem stupid to me, to have IPv4 ("the past") as PI but IPv6 ("the future") as PA. That won't make sense. What changed between my v4 PI application and my v6 PI application? If I won't need PI on v6 any more, I probably won't need it on v4 any longer.
Siple question: do I need my machines to have provider independend IP addresses or not? If yes, then I need *ANY* address (IPv4, IPv6, IPvSomething) to be PI and not PA.
So, if somebody already has IPv4 PI space, he/she should more or less automatically receive v6 PI under the same conditions as for v4. He/she just has to reason, why some default /48 won't be enough. Thats my opinion.
regards, Thomas
Let's not go into a discussion on asics / 64-core cpu's, but I'm pretty certain that hardware including tcams etc will keep up if the market demands it.
Oh, do let me briefly touch on this tangent; I think your statement glosses over the worry which has been expressed. The problem is this: so far "hardware scaling" of core routers has been riding on the coattails of general advances in electronics, driven by other and larger forces (PCs etc.). However, there is apparently no general market demand for "much, Much bigger TCAMs". This means that such components will be costly at best, maybe more costly than any of us would like to think of, and/or that they may not arrive as quicly as when we have the assistance of other market forces which pull in the same direction. I tell you, widespread PI adoption is poison for the network. Just saying. So that I can tell you "told you so!" Regards, - Håvard, in a pessmistic mood
Havard,
The problem is this: so far "hardware scaling" of core routers has been riding on the coattails of general advances in electronics, driven by other and larger forces (PCs etc.). However, there is apparently no general market demand for "much, Much bigger TCAMs". This means that such components will be costly at best, maybe more costly
I tell you, widespread PI adoption is poison for the network. Maybe, maybe not. If I read things correctly, the suggestion is to take
I fully agree with that angle and the sentiments expressed in rfc4984. However, although of course I'm not a router vendor, if big data (tm) and scalability is a problem that can be solved on other planes we should be able to attack the routing problems as well. Maybe the current solutions don't fit the problems anymore. It would probably mean departing from the current router architectures and looking at much more parallel modular architectures all highly parallel and using where possible a lot of off-the-shelf components, e.g. where one engine does the control plane work and only does updating, policing, flow tagging/labeling and a data plane engine only forwards traffic. Of course this is hugely over simplified, we're getting very close to OT here as it is already :-) (don't forget in the high volume hardware market we've reached some kind of limit on speed as well, it'll be more about parallel processing now & next) the business side of things into account as well. It's kind of curious that this should stop at the (core) infrastructure side. The businesses and people that are actually using the Internet are equally if not more important. Since 2007 a lot of things have changed once again or maybe evolved further; people and businesses have grown even more dependant on Internet connectivity as could only have been expected. PI is a necessity for a lot of businesses, large _and_ small(er). I get a feeling the whole discussion is still only a technical one as itpasses by the actual Internet users (companies). If there is an element of the business, most of the people involved only argue on behalf of the (big) ISP side. Regards, Albert
On Nov 8, 2011, at 8:13 AM, Albert Siersema wrote:
Maybe the current solutions don't fit the problems anymore.
Maybe the IAB should have a workshop exploring this problem.
I tell you, widespread PI adoption is poison for the network. Maybe, maybe not.
No, really, it is. Given IPv6 uses the exact same routing technology as IPv4, the same problems apply. We couldn't flat route 32 bits so the IPv6 solution is to flat route 48 bits?
If there is an element of the business, most of the people involved only argue on behalf of the (big) ISP side.
I think you have it backwards. Who do you think will be able to afford the multi-tens of millions of euros necessary to purchase the routers that will have sufficient TCAM space to deal with PI-for-everyone? However, you are correct that perfectly understandable business concerns are driving this issue. The likely (inevitable?) end result will (again) be prefix length filters and accusations of money grubbing evil greedy bastard ISPs. Been there, done that, still have a few t-shirts left. I wonder who is going to play Sean Doran this time around... Regards, -drc
I tell you, widespread PI adoption is poison for the network. Maybe, maybe not.
No, really, it is.
This policy has been discussed in detail in the past 6 months and we keep circling back on the same topics. And sorry to burst your bubble, but you are wrong and the information (read as: the facts and not as gut feelings) from the other RIR's show (from those that have a similar policy in place) that the number of v6 PI prefixes is not taking the steep jump. The policy has come to the end of the last call and in the RIPE minutes on Wednesday it was specified that : "The APWG co-Chairs announced their intention to declare consensus on proposal 2011-02, "Removal of multihomed requirement for IPv6 PI". " Having said this, this policy will help us all in the so much required v6 adoption across the board and it is still possible to propose a change in the v6 PI policy if the take-up is moving out of hand. On the other hand, this discussion will probably be revisited or become unneeded if and when PI and PA are all going to be treated as equal in the future. Regards, Erik Bais
On 08/11/2011 18:39, Erik Bais wrote:
And sorry to burst your bubble, but you are wrong [...]
"Whoever passes through life with the most and then dies agreeably is the one who, in my opinion, O King, deserves to bear this name. It is necessary to see how the end of every affair turns out, for the god promises fortune to many people and then utterly ruins them." - Herodotus, The Histories. Nick
On Nov 8, 2011, at 10:39 AM, Erik Bais wrote:
I tell you, widespread PI adoption is poison for the network. Maybe, maybe not. No, really, it is. And sorry to burst your bubble, but you are wrong and the information (read as: the facts and not as gut feelings) from the other RIR's show (from those that have a similar policy in place) that the number of v6 PI prefixes is not taking the steep jump.
:-) 'An optimist is someone who jumps off a tall building and after 50 floors says, "So far, so good."' Regards, -drc
On Tue, Nov 08, 2011 at 04:32:18PM +0100, Havard Eidnes wrote:
I tell you, widespread PI adoption is poison for the network. Just saying. So that I can tell you "told you so!"
Regards,
- Havard, in a pessmistic mood
For a pessimistic outlook on what will be poison for the network, try: http://ripe63.ripe.net/presentations/205-2011-10-31-exhaustion.pdf on the alternatives to widespread, rapid IPv6 deployment. Successful transition to IPv6 is by no means a sure thing. The only advantage IPv6 has going for it right now is that it offers virtually unlimited, easily available address space. If we keep creating artificial scarcity by way of arbitrary rules and restrictions, IPv6 deployment *will not happen*. For the consequences, refer to the above. Regards, Sascha Luck
On Tue, Nov 8, 2011 at 7:39 PM, Erik Bais <ebais@a2b-internet.com> wrote:
Having said this, this policy will help us all in the so much required v6 adoption across the board and it is still possible to propose a change in the v6 PI policy if the take-up is moving out of hand. Exactly.
Btw, the net is already poisoned. It all began with the wide deployment of NAT-Routers as CPE. This internet currently is not the "network of all networks", in fact, it hasn't been the past years. We now have the ability to provide every customer[1] with a network, and we fail to give them addresses. Seriously? Whats wrong? Again: A PIv4 holder cannot get his hands on a PIv6 if he is not multihomed. This leads to a) PIv4 holders not deploying IPv6; b) PIv4 holders mixing PI and PA space, which requires renumbering if the provider changes. Guess what makes more sense in a business-plan to the financial departement? I cannot believe this discussion is still on... Drop it if you are unsure, so I can say "told you so" later on. ;) regards, Dan [1] customer, a: the one who pays my bills.
participants (7)
-
Albert Siersema -
Dan Luedtke -
David Conrad -
Erik Bais -
Havard Eidnes -
Nick Hilliard -
Sascha Luck