insufficient availability of IPv6 address space for end customers
Hi everyone, well ... I don't really know where to start, and my best guess is that this sortof must be an FAQ that has been discussed to death before, but then again, maybe my perspective really is something people aren't quite aware of, so here goes my hypothesis: Providers are psychologically incapable of managing IPv6 address space on their own, and RIPE should do something about it before their inability damages IPv6 beyond repair. Yes, I know what you are thinking ... please, bear with me and let me explain. I recently found myself in the market (in .de) for some tunnel with static addresses for my mail and jabber servers and stuff that I run at home, or some small virtual server that I could use to setup the tunnel myself, with one of the requirements being an IPv6 prefix, /56 at least. And guess what? Of all requirements, the biggest problem is the /56. Of course, there is quite a number of providers that still don't offer IPv6 at all ... well, OK, those are hopeless, I guess. But then, there is a large segment of providers which are either incapable of assigning a /56 or larger, or they offer it at prices that make IPv4 addresses seem like an abundant resource in comparison. Now, there might be real technical limitations in some cases that prevent some providers from assigning (or at least from routing) a large(ish) prefix--but my overall impression is that in most cases, this inability to assign non-minimal prefixes does not have its basis in any real technical causes, and not even in business reasons, but rather in some kind of psychological need to not waste address space, a sort of value judgement that is not to be questioned, and that is very difficult to attack with rational arguments. One provider not only told me essentially that I was crazy for wanting to waste so much address space (a notion that I heard more than once), but even went so far as to tell me that /56 assignments were for providers only as per RIPE policy and the most an end customer could get would be a /64 ... not even providing them with the URI of the RIPE allocation and assignment policy helped, they simply couldn't accept that "wasting so much address space" could be anything but morally repugnant, or at least a completely idiotic idea not worth any further consideration (who knows what they really thought, obviously ...). But even the ones that offered a /56 (or larger) prefix for a monthly or one-time fee mostly seemed like they didn't intentionally design their products with smaller prefixes to then be able to sell the "professional version" at a higher price, but rather simply seem to want to cover their increased costs for dealing with this "special requirement", not realizing that they themselves created this situation where my requirement is not met by the standard product, even though they could have done so at no additonal cost to them by simply always assigning a /56 or /48--or in other words, that they themselves created the overhead that the RIPE policy even warns against, and as a side effect presumably also create incentives for customers who aren't that knowledgable to use broken networking setups because of a lack of addresses or the difficulty of obtaining additional addresses. Yes, not all of those providers are RIPE members, but being a RIPE member with a /32 allocation does not seem to prevent you from "saving address space" by making sure you'll never allocate most of it to customers ever. I guess the problem of ensuring availability of addresses has been discussed before, and I guess possible solutions have been rejected for good reasons, I am not really familiar with the history of this at RIPE, and any pointers to FAQs or canonical ML posts or whatever else might bring insight are welcome ... but what I am wondering about specifically is whether it has been considered so far that providers might be incompetent, possibly to the point of not being able to learn unless forced to, at making sensible IPv6 assignments? Should providers be required to always assign at least a /56 unless they can show good technical reasons why that would cause harm? Well, I can see a ton of problems with that approach (How do you enforce that? Does it hurt competent providers? Does it hinder valid business models?), but my impression is that the policy so far assumes that providers make competent decisions, only providing non-binding recommendations regarding minimum allocation sizes, which obviously is completely ignored by providers that are caught up in the address saving mindset of IPv4, leading them to make bad decisions both for themselves and for the long term development of the IPv6 internet (and yes, I found one provider that admitted just that, they told me they were currently overhauling their product offerings and intended to change the standard assignment size in the future, as they had recognized /64 assignments to be a mistake that had happened because they felt they needed to save addresses). How about applying the HD ratio based on the smallest end-site allocation that exists within a provider's prefix (as in: if you assign /64, you only get a /40 unless you can show you have more than ~ 200k /64 assigned)? Maybe even punish small prefixes? If a provider assigns a /64, apply a higher HD ratio? Somehow make it expensive for providers to hoard addresses ... just making it cheap to assign sufficient address space doesn't seem to provide sufficient motivation, so maybe making it expensive to do the wrong thing is what's required? Well, any suggestions welcome (or any arguments why I am an idiot, or maybe just mistaken), also with regards to processes and mechanisms available at RIPE that might help with fixing this problem ... I'll stop here for now ;-) (Oh, and if you feel like you can offer what I am (still) looking for, feel free to drop me an email--but be warned that I don't really intend to spend much money on it, though I'd think it should be easily earned if you have the infrastructure in place, I don't need much traffic and I know to help myself as long as you keep your end of things running ... but that's not really a topic for further discussion on this list, I guess ...) Regards, Florian
Hi Florian, I understand you feel the IPv6 addressing architecture of a few ISPs you are dealing with is so poor that you cannot stand by silently. I'll assume you have made attempts to meaningfully (and without emotion) exchange ideas with them. You've now come to this list to paint them with a broad brush. So in this case, I think you should name names. What are the names of the ISPs you are dealing with who are managing their IPv6 product so poorly that you think ALL of RIPE's providers should be subject to more regulation from the NCC? By naming them, perhaps representatives here will see your plea, and perhaps members of the Address Policy WG can intercede on your behalf or have engineer-to-engineer discussions with them. Even now in late 2015, I believe IPv6 is still very greenfield. Network operators are still figuring out how to best do things; how to best architect IPv6 offerings in a way that balances their needs with their customers' needs. More regulation from the NCC is, in my opinion, many years premature. David R Huberman Principal, Global IP Addressing Microsoft Corporation
-----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Florian Zumbiehl Sent: Sunday, December 6, 2015 6:49 PM To: address-policy-wg@ripe.net Subject: [address-policy-wg] insufficient availability of IPv6 address space for end customers
Hi everyone,
well ... I don't really know where to start, and my best guess is that this sortof must be an FAQ that has been discussed to death before, but then again, maybe my perspective really is something people aren't quite aware of, so here goes my hypothesis:
Providers are psychologically incapable of managing IPv6 address space on their own, and RIPE should do something about it before their inability damages IPv6 beyond repair.
Yes, I know what you are thinking ... please, bear with me and let me explain.
I recently found myself in the market (in .de) for some tunnel with static addresses for my mail and jabber servers and stuff that I run at home, or some small virtual server that I could use to setup the tunnel myself, with one of the requirements being an IPv6 prefix, /56 at least.
And guess what? Of all requirements, the biggest problem is the /56. Of course, there is quite a number of providers that still don't offer IPv6 at all ... well, OK, those are hopeless, I guess.
But then, there is a large segment of providers which are either incapable of assigning a /56 or larger, or they offer it at prices that make IPv4 addresses seem like an abundant resource in comparison. Now, there might be real technical limitations in some cases that prevent some providers from assigning (or at least from routing) a large(ish) prefix--but my overall impression is that in most cases, this inability to assign non-minimal prefixes does not have its basis in any real technical causes, and not even in business reasons, but rather in some kind of psychological need to not waste address space, a sort of value judgement that is not to be questioned, and that is very difficult to attack with rational arguments.
One provider not only told me essentially that I was crazy for wanting to waste so much address space (a notion that I heard more than once), but even went so far as to tell me that /56 assignments were for providers only as per RIPE policy and the most an end customer could get would be a /64 ... not even providing them with the URI of the RIPE allocation and assignment policy helped, they simply couldn't accept that "wasting so much address space" could be anything but morally repugnant, or at least a completely idiotic idea not worth any further consideration (who knows what they really thought, obviously ...).
But even the ones that offered a /56 (or larger) prefix for a monthly or one- time fee mostly seemed like they didn't intentionally design their products with smaller prefixes to then be able to sell the "professional version" at a higher price, but rather simply seem to want to cover their increased costs for dealing with this "special requirement", not realizing that they themselves created this situation where my requirement is not met by the standard product, even though they could have done so at no additonal cost to them by simply always assigning a /56 or /48--or in other words, that they themselves created the overhead that the RIPE policy even warns against, and as a side effect presumably also create incentives for customers who aren't that knowledgable to use broken networking setups because of a lack of addresses or the difficulty of obtaining additional addresses.
Yes, not all of those providers are RIPE members, but being a RIPE member with a /32 allocation does not seem to prevent you from "saving address space" by making sure you'll never allocate most of it to customers ever.
I guess the problem of ensuring availability of addresses has been discussed before, and I guess possible solutions have been rejected for good reasons, I am not really familiar with the history of this at RIPE, and any pointers to FAQs or canonical ML posts or whatever else might bring insight are welcome ... but what I am wondering about specifically is whether it has been considered so far that providers might be incompetent, possibly to the point of not being able to learn unless forced to, at making sensible IPv6 assignments?
Should providers be required to always assign at least a /56 unless they can show good technical reasons why that would cause harm? Well, I can see a ton of problems with that approach (How do you enforce that? Does it hurt competent providers? Does it hinder valid business models?), but my impression is that the policy so far assumes that providers make competent decisions, only providing non-binding recommendations regarding minimum allocation sizes, which obviously is completely ignored by providers that are caught up in the address saving mindset of IPv4, leading them to make bad decisions both for themselves and for the long term development of the IPv6 internet (and yes, I found one provider that admitted just that, they told me they were currently overhauling their product offerings and intended to change the standard assignment size in the future, as they had recognized /64 assignments to be a mistake that had happened because they felt they needed to save addresses).
How about applying the HD ratio based on the smallest end-site allocation that exists within a provider's prefix (as in: if you assign /64, you only get a /40 unless you can show you have more than ~ 200k /64 assigned)? Maybe even punish small prefixes? If a provider assigns a /64, apply a higher HD ratio? Somehow make it expensive for providers to hoard addresses ... just making it cheap to assign sufficient address space doesn't seem to provide sufficient motivation, so maybe making it expensive to do the wrong thing is what's required?
Well, any suggestions welcome (or any arguments why I am an idiot, or maybe just mistaken), also with regards to processes and mechanisms available at RIPE that might help with fixing this problem ... I'll stop here for now ;-)
(Oh, and if you feel like you can offer what I am (still) looking for, feel free to drop me an email--but be warned that I don't really intend to spend much money on it, though I'd think it should be easily earned if you have the infrastructure in place, I don't need much traffic and I know to help myself as long as you keep your end of things running ... but that's not really a topic for further discussion on this list, I guess ...)
Regards, Florian
Hi,
I understand you feel the IPv6 addressing architecture of a few ISPs you are dealing with is so poor that you cannot stand by silently. I'll assume you have made attempts to meaningfully (and without emotion) exchange ideas with them. You've now come to this list to paint them with a broad brush. So in this case, I think you should name names. What are the names of the ISPs you are dealing with who are managing their IPv6 product so poorly that you think ALL of RIPE's providers should be subject to more regulation from the NCC? By naming them, perhaps representatives here will see your plea, and perhaps members of the Address Policy WG can intercede on your behalf or have engineer-to-engineer discussions with them.
Well ... for one, if it had been one or two providers, I probably wouldn't have felt the need to do anything about it, there always are some bad products on the market, and the best way to deal with them is to simply not buy them. It seems to me like this is a systemic problem, given how many providers seem to be affected by it. Now, no, I didn't try to "exchange ideas" with all of them, that would simply have been too much work, but I did with quite a few, and my impressions come from what they said plus the content of the offers (or non-offers) from the others. Also, maybe I should stress that when I wrote that many providers seem "incompetent" or "psychologically incapable", that is not meant as an insult, but as a rather neutral description of the problem: They don't understand the tradeoffs in address allocation, but instead only react on an emotional level to the idea of assigning "so many addresses!", or at least that is my interpretation of the behaviour I observed--while RIPE documents seem to assume that people try to rationally understand address allocation/assignment. However, I do not necessarily think that more regulation is the way to go (really, IMO that should be the last resort if nothing else helps), and if more regulation is the way to go, I guess it should be put together in such a way that the impact on competent providers is as close to zero as possible ... Things are further complicated by the fact that many of the providers probably aren't RIPE members themselves (I don't really know, not all RIPE members do advertise it prominently ...).
Even now in late 2015, I believe IPv6 is still very greenfield. Network operators are still figuring out how to best do things; how to best architect IPv6 offerings in a way that balances their needs with their customers' needs. More regulation from the NCC is, in my opinion, many years premature.
Well ... I am not sure whether that is funny or just sad, given that I've had native IPv6 connectivity for the last 10 years, with a /48 prefix, from a competent provider (yes, they do exist, obviously!), which now needs replacement (for reasons unrelated to the provider or their competence). Regards, Florian
free to drop me an email--but be warned that I don't really intend to spend much money on it, though I'd think it should be easily earned if you have the infrastructure in place, I don't need much traffic and I know to help Service costs money. In our case, we're a (mostly/almost exclusively) business provider, setting up business networks utilizing all sorts of
Florian, I believe the problem is twofold - the usual hen-and-egg-problem. On the one hand, many (especially larger) providers have been slow to adopt v6 in their networks. Partly due to the technical requirements (which, if you want to do it right, will cost them more man-power and real money (tm) than for a small ISP that only has a hand full of routers to take care of), but also due to business case - barely anybody actually wants or needs v6 at the moment. Which is "the other hand". With barely anybody requesting v6 - even if it is available - there is no pressure. e.g., we've had v6 since the 6bone-days, applied for and received and activated our /32 when it became available at RIPE, and to this day had 3 (!) actual requests for v6 throughout our customer base. And that even though we actively promoted v6 use through our newsletter, explained how easy it is to use, etc. Apart from those 3 users, we also have a couple more that have active v6 "by accident", because their DSL CE routers just request and receive their addresses (btw, for dynamic dialup without fixed configuration, we use a /64 ... which IMHO is sufficient for the "everyday" user who only cares about having reliant Internet access) - which is, btw, another 7 connections at the moment. None of our leased line customers could be convinced to set up their v6 connectivity, though at least one reserved his PI network once RIPE made PIv6 available. Not active, though. In essence, then, where do we stand? Sure, more and more providers in the net set up their v6. For probably 95% (or more) of the customers, v6 isn't an issue. And they couldn't care less. They want internet. If it's transported via v4 or v6 isn't their concern. They just want their Facebook, WhatsApp, etc. to work. On the provider side, the lack of actual interest in v6 makes the business-side of the decision easy - v6 won't make them a single buck more, rather it will cost them money in the short run. For ISPs smart (or stupid?) enough to invest time and money now, it is somewhat depressing - knowing you have all those shiny, new, untainted v6 addresses, and nobody wants them. And you can't even recuperate the cost for the additional service. At least not in a market where most customers just want to pay as little as they can for the service they want. Which gets me to my final point: lines (apart from Voice services and network monitoring consulting). We don't have the numbers to cover all of Telekom's OVSt's with our equipment in order to get the end customers' lines at some (perceived) low prices, we have to get the service indirectly from Telekom. Which means we will never be able to compete with the dumping price wars that large providers like Telekom or the cable companies have. Instead, we provide SERVICE to our customer. You can reach a tech person usually relatively quickly (and not some first level drone at a call center without any real technical knowledge and ability), we allow for custom setups for all our lines, and we try to keep up to date with technical development. In turn, all of this does one thing: it costs us money. Not v6 specifically (which I see as part of doing business without the danger of being pushed out of business some time down the road), but the whole package. Most of the additional cost is earned with the high-end products and services for leased lines, but we still need to make some of it from our "low-end" DSL services, which means we will be more expensive than your 1&1, Congstar or whoever the dumping-ISP of your choice may be (* just in case - no, we are even . So just as in "physical" life, where a cheap Fiat may (well, rather "will") not include all of the amenities of a Beamer or Merc, you will need to put your money where your mouth (and your requirements) are. (Side note: and no, even with our service we're by far not as expensive as the "premium" product of your current provider, but we can't compete with his "flex" product ... so if the latter is your desired rate, don't even look at our page - but don't complain that you don't receive the professional services you would like to get) -garry
Hi,
I believe the problem is twofold - the usual hen-and-egg-problem. On the one hand, many (especially larger) providers have been slow to adopt v6 in their networks. Partly due to the technical requirements (which, if you want to do it right, will cost them more man-power and real money (tm) than for a small ISP that only has a hand full of routers to take care of), but also due to business case - barely anybody actually wants or needs v6 at the moment. Which is "the other hand". With barely
I'd tend to disagree: Everyone _needs_ IPv6, people just don't realize it. I mean, just look at how much overhead the lack of IPv4 addresses generates every day (both in the form of management overhead due to having to deal with getting addresses assigned from RIPE/ISPs, but even more due to the grotesque workarounds that are deployed everywhere to make due with IPv4, like private address ranges, which tend to collide all the time if you try to connect previously separate networks, and NAT, and all the easy solutions to problems that NAT prevents from working, ...)--all of that cost would simply vanish once everyone has switched to IPv6, but people simply aren't aware, because they think that private addresses inside your network plus NAT just is how the internet works, they have no idea what costs sticking with IPv4 is causing, so they don't want it, even though they very much need it.
anybody requesting v6 - even if it is available - there is no pressure. e.g., we've had v6 since the 6bone-days, applied for and received and activated our /32 when it became available at RIPE, and to this day had 3 (!) actual requests for v6 throughout our customer base. And that even though we actively promoted v6 use through our newsletter, explained how easy it is to use, etc. Apart from those 3 users, we also have a couple more that have active v6 "by accident", because their DSL CE routers
Given that IPv6 should in the end be easier for ISPs as well: Have you considered offering IPv6 only connectivity at a lower price?
just request and receive their addresses (btw, for dynamic dialup without fixed configuration, we use a /64 ... which IMHO is sufficient for the "everyday" user who only cares about having reliant Internet access) - which is, btw, another 7 connections at the moment.
I think you are wrong here, I think you are making exactly the mistake that I am trying to point out providers tend to make. Your mistake is that you think that "it's sufficient" is a good reason. It's not. It's a really, really bad reason. It was a good reason with IPv4, but with IPv6 this approach to justifying assignment sizes is counterproductive. You are (correct me if I am wrong) not looking at the full tradeoff. What would the cost increase be for you if you assigned /56 prefixes by default? Zero, right? You have to make an initial assignment anyway, and /64 or /56 makes no difference in the effort required, and you still would have space for ~ 16 million customers, so no real risk of running out of addresses either, and even if you did, as per RIPE policy you could obtain a /29 without even providing any documentation, and once you have connected a further ~ 120 million customers, it still should be relatively easy to obtain space for another ~ 134 million customers, with no additional fees to pay (yes, I know that you cannot really fit 134 million customers into a /29 with a reasonable wide-area routing setup, but the RIPE policy does use an HD ratio < 1, obviously). What would the (negative) externalities be if you assigned a /56 by default? Also zero--the only potential externality would be that others might end up without addresses when they need them because you assigned too much, but there is no risk of running out of addresses even with /48 prefixes per customer, not even if earth's population increases ten-fold and every single person got assigned /48 prefixes from 10 different providers, even then only about a quarter of one percent of the available address space would be assigned, and think about how realistic that scenario is, and then divide the risk by another 256 if you use /56 prefixes instead. So, we do agree that there would be no cost, no negative consequences to assigning /56 prefixes by default, right? Now, let's look at the other side of the equation: You can be pretty sure one in a million customers (once they use IPv6) might want to use more than one LAN. Now, what are their options? Well, they could not use SLAAC. Great! Or they could just forget about the idea. Or they could request assignment of additional addresses. Either way, you have just created costs, be it in the form of lowered convenience or the need to request addresses, the need for you to process that request, the added complexity of managing this special case, probably the need to renumber the customer's network, the delay until the addresses have been assigned ... all of which also acts as an incentive to choose technically inferior solutions to avoid this overhead. Or imagine a CPE manufacturer that considers the idea of creating a product that would need multiple subnets to achieve some functionality ... if selling the product means convincing potential customers that they would have to negotiate address assignment with their providers, they'll probably simple scrap the idea. All of that for what? There is no upside to it, only downsides. And I mean _NO_ upside, not even minimal, marginal, potential upside, none. Why do you still think that it's a good idea to assign a /64? Do you have any actual reason _against_ assigning at least a /56 by default? I would really be interested to hear if you have--my guess is that you don't and that it's an unconcious bias in favour of saving addresses no matter what because that is the right thing to do with IPv4, and that's what I suspect is at work at all those providers that assign /64 prefixes (or even smaller) by default. People have to be taught now that saving addresses is actively _BAD_, that it's causing harm, that it is to be avoided if possible, just as assigning an IPv4 /24 to every dialup customer is to be avoided, just for entirely different reasons.
In essence, then, where do we stand? Sure, more and more providers in the net set up their v6. For probably 95% (or more) of the customers, v6 isn't an issue. And they couldn't care less. They want internet. If it's transported via v4 or v6 isn't their concern. They just want their Facebook, WhatsApp, etc. to work.
Well, yeah, that is a problem, but I don't think it's in any way an argument for a bad address assignment policy.
On the provider side, the lack of actual interest in v6 makes the business-side of the decision easy - v6 won't make them a single buck more, rather it will cost them money in the short run.
Well, yeah, the advantages are only to be had in the long run, obviously - however, how long that "long run" is away and how much you spend on maintaining a harder and harder to maintain ipv4 network very much depends on when you (and everyone else, unfortunately) make these investments.
For ISPs smart (or stupid?) enough to invest time and money now, it is somewhat depressing - knowing you have all those shiny, new, untainted v6 addresses, and nobody wants them. And you can't even recuperate the cost for the additional service. At least not in a market where most customers just want to pay as little as they can for the service they want. Which gets me to my final point:
Well, I am looking for a provider that will also provide IPv6 precisely because I want to support those who have made the effort instead of paying one that hasn't and then getting a free v6 tunnel, but that has turned out to be far more difficult than expected.
Service costs money. In our case, we're a (mostly/almost exclusively)
Which I totally understand, but ... I don't need any service? I don't need anything that should be special. I don't need anything that should cause any costs beyond the cost for a standard product that should be possible to run at a large scale, and I don't need any help with setting up my side of things.
business provider, setting up business networks utilizing all sorts of lines (apart from Voice services and network monitoring consulting). We don't have the numbers to cover all of Telekom's OVSt's with our equipment in order to get the end customers' lines at some (perceived) low prices, we have to get the service indirectly from Telekom. Which means we will never be able to compete with the dumping price wars that large providers like Telekom or the cable companies have. Instead, we
Which is part of why I am looking for a tunnel or virtual server to set up the tunnel myself (and no, I don't care about DTAG peering, in case you are wondering, that's DTAG's problem).
provide SERVICE to our customer. You can reach a tech person usually relatively quickly (and not some first level drone at a call center without any real technical knowledge and ability), we allow for custom setups for all our lines, and we try to keep up to date with technical development. In turn, all of this does one thing: it costs us money. Not v6 specifically (which I see as part of doing business without the danger of being pushed out of business some time down the road), but the whole package. Most of the additional cost is earned with the high-end products and services for leased lines, but we still need to make some of it from our "low-end" DSL services, which means we will be more expensive than your 1&1, Congstar or whoever the dumping-ISP of your choice may be (* just in case - no, we are even . So just as in "physical" life, where a cheap Fiat may (well, rather "will") not include all of the amenities of a Beamer or Merc, you will need to put your money where your mouth (and your requirements) are.
I can see all of that, but I really don't need service nor do I need a custom setup. Yes, I need that you fix things when they break on your side (and if you have installed call center drones who can't handle a competent caller, thus preventing you from fixing your problems, that's a cost factor for you, not for me, as it's wasting your resources, not mine (if I call, it's probably because you are at fault, and you won't be able to avoid fixing your problem other than by getting rid of me as a customer), and more than likely will make you lose me as a customer), and I also don't mind paying extra for additional effort - but assigning a /56 by default shouldn't be any additional effort.
(Side note: and no, even with our service we're by far not as expensive as the "premium" product of your current provider, but we can't compete with his "flex" product ... so if the latter is your desired rate, don't even look at our page - but don't complain that you don't receive the professional services you would like to get)
Well, you might have overlooked that no traffic price is specified in that table ;-) But no, I don't have any of the products currently listed on their website (it's access over T-DSL, which I had running with multiple PPPoE sessions until DTAG recently decided that that's a feature that they should switch off without warning, and haven't been able to re-activate (see call center drones above, and that despite the not quite dumping price of that line), which is also why I am looking to replace it now). Regards, Florian
To answer your question: No, I do not see a need for stronger regulations in this area. Richard Sent by mobile; excuse my brevity.
participants (4)
-
David Huberman
-
Florian Zumbiehl
-
Garry Glendown
-
Richard Hartmann