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