T
tomm3h
Guest
Hi Parallels,
The topic of IPv6 seems to be quite sparse, when I think the lack of support for it within Plesk is becoming quite concerning.
Some small background:
- I work for a hosting company that operates hundreds of Plesk-based servers, from versions 7.5.4 to 9.2 across FreeBSD, CentOS & Windows.
- We have an IPv6 address allocation from RIPE and have done for many months.
- We have multiple IPv6 provider links and are ready to begin rolling-out addressing across our internal network
IPv4 is running out quickly: fact.
RIR assignments will end in ~12 months (or less, depending on the rate of IPv4 land grabs) and LIR assignments probably 12 or so months afterwards. At that point, there will be a panic. ISPs in some countries may have to consider supplying only IPv6 to their customers.
RIPE themselves cannot stress the idea of 'gradual implementation' enough. The cost-to-benefit ratio of smoothly transitioning from an IPv4-only to dual-stack IPv4 & IPv6 network over a long period, far outweighs a sharp transition at the point when catastrophe hits. Prevention is better than cure, etc.
At present, how does Parallels presume to support their impending customer's requirements for IPv6? There is no support that I can see mentioned in Plesk 9.5, OR the 10.0 "marketing preview". Regardless of the level of demand, you have been within this business for many, many years and should by now have the ability to foresee coming trends. When the IPv4 exhaustion finally grips your customers with panic, what solution will you have to offer them?
At this time it is presumed that such ignorance will lead to one of the following situations for us:
1) Investing in supplemental (and highly expensive) IPv6-to-IPv4 solutions, so that any IPv6-only customers are able to access systems limited to IPv4 (that's Plesk.)
2) Begin working on our own implementation. We have the expertise, but the time and money required to even consider this would be astronomical.
In either case: such ignorance is going to cost us dearly.
The short story here is that we have customers to appease. They will be demanding IPv6 shortly, whilst many are already interested in seeing our services support this as soon as possible because they share the same view as myself.
Our networking hardware has support, the operating systems have had support for years, name & e-mail servers (separate to Plesk) have support already. IPv6 transit is already readily available. We're implementing slowly but surely, yet our plans for the roll-out have a huge black hole where Plesk currently resides.
So to Parallels:
1) after we've invested so much into Plesk over the last decade, what are you doing (if anything) about the inevitable, world-wide move to IPv6? Has there been any consideration at all?
2) What, if anything, is holding back the development -- if it exists?
3) Are you simply ignoring IPv6, expecting your customers to foot the bill for your short-sighted behaviour?
4) Finally, is there any form of IPv6 beta program that we can enrol in?
I look forward to hearing these replies.
Tom
The topic of IPv6 seems to be quite sparse, when I think the lack of support for it within Plesk is becoming quite concerning.
Some small background:
- I work for a hosting company that operates hundreds of Plesk-based servers, from versions 7.5.4 to 9.2 across FreeBSD, CentOS & Windows.
- We have an IPv6 address allocation from RIPE and have done for many months.
- We have multiple IPv6 provider links and are ready to begin rolling-out addressing across our internal network
IPv4 is running out quickly: fact.
RIR assignments will end in ~12 months (or less, depending on the rate of IPv4 land grabs) and LIR assignments probably 12 or so months afterwards. At that point, there will be a panic. ISPs in some countries may have to consider supplying only IPv6 to their customers.
RIPE themselves cannot stress the idea of 'gradual implementation' enough. The cost-to-benefit ratio of smoothly transitioning from an IPv4-only to dual-stack IPv4 & IPv6 network over a long period, far outweighs a sharp transition at the point when catastrophe hits. Prevention is better than cure, etc.
At present, how does Parallels presume to support their impending customer's requirements for IPv6? There is no support that I can see mentioned in Plesk 9.5, OR the 10.0 "marketing preview". Regardless of the level of demand, you have been within this business for many, many years and should by now have the ability to foresee coming trends. When the IPv4 exhaustion finally grips your customers with panic, what solution will you have to offer them?
At this time it is presumed that such ignorance will lead to one of the following situations for us:
1) Investing in supplemental (and highly expensive) IPv6-to-IPv4 solutions, so that any IPv6-only customers are able to access systems limited to IPv4 (that's Plesk.)
2) Begin working on our own implementation. We have the expertise, but the time and money required to even consider this would be astronomical.
In either case: such ignorance is going to cost us dearly.
The short story here is that we have customers to appease. They will be demanding IPv6 shortly, whilst many are already interested in seeing our services support this as soon as possible because they share the same view as myself.
Our networking hardware has support, the operating systems have had support for years, name & e-mail servers (separate to Plesk) have support already. IPv6 transit is already readily available. We're implementing slowly but surely, yet our plans for the roll-out have a huge black hole where Plesk currently resides.
So to Parallels:
1) after we've invested so much into Plesk over the last decade, what are you doing (if anything) about the inevitable, world-wide move to IPv6? Has there been any consideration at all?
2) What, if anything, is holding back the development -- if it exists?
3) Are you simply ignoring IPv6, expecting your customers to foot the bill for your short-sighted behaviour?
4) Finally, is there any form of IPv6 beta program that we can enrol in?
I look forward to hearing these replies.
Tom