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
