All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
HostDZire IPv6 Allocation Violation: Service Terminated After Configuration Error
I would like to share a recent experience with HostDZire involving an India VPS that was suspended due to unauthorized IPv6 address usage.
I am posting this to document what happened, including my own configuration mistake, the provider's response, and the final outcome.
This is not intended to encourage harassment or personal attacks against the provider or its staff. I believe other VPS users may find the experience useful, particularly those running Docker containers, custom IPv6 configurations, or Hurricane Electric tunnels.
1. Background
Provider: HostDZire
Service: IN CloudVPS #5 (FAT32 Special)
Incident date: October 9–10, 2026
Suspension reason: Unauthorized use of unassigned IPv6 addresses – Network abuse / IP allocation violation
Final outcome: Service terminated, with the provider confirming that a refund had been sent.
The VPS was used for container-based networking experiments, including Docker networking and Hurricane Electric IPv6 Tunnel Broker connectivity.
During a local container deployment, an incorrect network configuration resulted in multiple IPv6 addresses being associated with the VPS network interface, even though those addresses had not been assigned by the provider.
At the time, I had assumed that addresses outside my assigned allocation would simply fail to work at the upstream network level.
That assumption was incorrect, and I acknowledge that I should have verified the assigned IPv6 allocation and network configuration more carefully.
2. Initial Suspension
On October 9, I received a suspension notification stating:
Unauthorized use of unassigned IPv6 addresses – Network abuse / IP allocation violation.
I opened a support ticket requesting clarification about the specific IPv6 addresses involved, the assigned IPv6 allocation, and whether the service could be restored after correcting the configuration.
The provider subsequently supplied a list containing one authorized IPv6 address and 21 unauthorized IPv6 addresses associated with the same MAC address.
For privacy, I am not publishing the full IP or MAC address list.
The important point is that the provider identified unauthorized IPv6 address usage, and I do not dispute that those addresses had not been assigned to my VPS.
However, I disagree with the provider's conclusion that this was necessarily intentional abuse.
3. Provider's Response
On October 10, the provider responded:
Since we know this wasn't a mistake and was intentional, we can't let you use our service anymore.
They offered to cancel the VPS and refund the unused portion of the service.
After reviewing my configuration, I acknowledged the mistake and explained that the unintended configuration originated from my Docker networking setup.
I also proposed several ways to prevent the issue from recurring:
- Remove all unauthorized IPv6 addresses.
- Disable native IPv6 on the VPS entirely.
- Allow the provider to disable IPv6 at the network or switch level if necessary.
- Continue using only the assigned IPv4 address, with any required external IPv6 connectivity handled through my own Hurricane Electric tunnel.
I was willing to accept a permanent native IPv6 restriction if that was necessary to restore the service.
However, the provider rejected reinstatement.
Their response was:
No, we can't allow you to use our service anymore.
Later, they reiterated:
The decision is final. We can't keep a customer who intentionally uses an unauthorized IP.
At that point, it became clear that the provider was not willing to continue the service, even with the proposed restrictions.
4. The Disagreement
I fully understand that using IP addresses outside an assigned allocation can create network security and operational problems.
Providers have legitimate reasons to enforce IP allocation policies, including preventing address conflicts, spoofing, and potential abuse.
I am not suggesting that users should be allowed to configure arbitrary addresses on shared infrastructure.
My disagreement concerns how the incident was handled after the configuration issue was acknowledged.
From my perspective, this was a configuration error rather than an attempt to obtain unauthorized IP resources.
I had not intended to use the provider's unassigned IPv6 addresses, and once the issue was identified, I offered to remove the configuration and disable native IPv6 completely.
The provider, however, maintained that the behavior was intentional.
I also believe network-level filtering of unauthorized source addresses can provide an additional safeguard against accidental misconfiguration. That said, I recognize that the availability and implementation of such protections depend on the provider's infrastructure, and their absence would not excuse an incorrect customer configuration.
The ticket did not establish whether the unauthorized addresses caused an IP conflict, disrupted other customers, or generated additional abusive traffic. The provider's stated reason was unauthorized IPv6 usage.
5. Cancellation and Refund
After several exchanges, the provider confirmed that its decision was final.
I accepted the offer to cancel the affected VPS and refund the unused service period.
I also requested cancellation and a refund for another active service, given that the provider had made it clear it no longer wanted to continue the customer relationship.
The provider declined to refund that separate service.
They stated:
Refunding other services is not possible.
They also stated that, under their rules, even the affected India VPS would not normally qualify for a refund, but they were making an exception.
Eventually, I agreed to proceed with cancellation of the affected VPS.
When asked whether I needed a backup, I declined. Due to previous server issues and reinstalls, I had already stopped keeping critical data or services on that instance.
At 11:21 on October 10, the provider replied:
Order cancelled. Refund sent.
This was the final response in the support ticket. At the time of writing, I can confirm the provider's refund notification, but not independently confirm the payment settlement.
6. Timeline
All times below are as displayed in the support ticket.
| Date / Time | Event |
|---|---|
| Oct 9, 22:13 | I requested clarification regarding the suspension and asked how to restore the service. |
| Oct 10, 06:03 | The provider asked which IPv6 addresses had been configured. |
| Oct 10, 07:27 | I provided the assigned IPv6 information and Hurricane Electric routed prefixes. |
| Oct 10, 08:05 | The provider supplied the unauthorized IPv6 list, concluded the behavior was intentional, and offered cancellation with a refund. |
| Oct 10, 08:10 | I acknowledged the configuration mistake and proposed disabling native IPv6. |
| Oct 10, 08:18 | The provider refused to continue the service. |
| Oct 10, 08:31 | I provided a more detailed explanation and requested reconsideration. |
| Oct 10, 08:34 | The provider confirmed its final decision. |
| Oct 10, 08:47 | I accepted a refund while expressing disagreement with how the incident was handled. |
| Oct 10, 08:51 | I requested a refund for another active service. |
| Oct 10, 09:43 | The provider rejected that additional refund and reiterated its position. |
| Oct 10, 10:46 | I confirmed that no backup was needed and authorized cancellation. |
| Oct 10, 11:21 | The provider confirmed cancellation and stated that the refund had been sent. |
7. My Takeaway
There are two separate aspects of this incident.
First, my configuration was wrong.
I configured IPv6 addresses that were not assigned to my VPS. That should not have happened, regardless of whether the provider's network accepted or filtered them.
I accept responsibility for the configuration mistake.
Second, I was disappointed with the support and escalation process.
The provider treated the incident as intentional abuse and made a final decision to discontinue service.
Despite acknowledging the mistake and offering to disable native IPv6 entirely, I was not given an opportunity to correct the configuration and continue using the VPS.
I understand that providers need to protect their networks and enforce their policies. I also recognize that a provider may choose not to continue serving a customer after an allocation violation.
However, I would have preferred a process that distinguished a correctable configuration mistake from proven malicious activity, particularly when the customer was willing to cooperate.
To the provider's credit, they offered a refund for the unused period and confirmed cancellation instead of retaining the entire remaining service payment.
That is worth acknowledging.
8. Questions for the LET Community
I would be interested in hearing other members' perspectives:
- Is permanent service termination a common response to a first-time unauthorized IPv6 configuration, even when the customer acknowledges the issue and offers to disable IPv6?
- How do other VPS providers handle unauthorized IPv6 addresses at the hypervisor, virtual switch, or upstream router level?
- Would you consider cancellation and a prorated refund a reasonable resolution in this situation?
I am not asking anyone to take sides. I simply wanted to document the experience and hear how other users and providers would approach a similar incident.
Thanks for reading.
- Who was wrong45 votes
- I was wrong53.33%
- HostDZire was wrong46.67%
Comments
Here we go
Guys, you got another post to have fun 
.....
I'm willing to present the facts objectively. You're free to make malicious assumptions about my intentions. Let the other users judge for themselves.
Watching, watching
Sure, i am not saying anything here, feel free to post whole ticket screenshots..
i don't see any issue with them terminating the contract under the circumstances. there's no way for them to be certain it was accidental vs. malicious and it isn't even relevant really.
very surprised they refunded and suggest you also be surprised and appreciative and just take it as an absolutely free lesson.
i'm also surprised they didn't terminate other services as once they decided bad actor why would they keep you in their network? that seems like bizarre reasoning, but it's still to your net positive so perhaps don't question it.
anyway yes you should expect termination (but not refunds, wow!) for any friction you cause, intent irrelevant.
It's been so many days without a HostDZire thread here that I was starting to get worried. Thankfully, someone finally made one. What a relief! I can finally sleep peacefully tonight.
At this point, it's practically a tradition: kick out 4–5 clients, get rewarded with a thread or two on LET/Nodeseek. The cycle of life continues.
Exactly! In a case like this, pretty much no provider would issue a refund. But since we're HostDZire, we went ahead and refunded anyway. Because let's be honest, if we hadn't, we'd already have a 10-page thread explaining how we're scammers. 😂
Not that issuing a refund guarantees we won't get one anyway.
I really want to comment, but I can't.
~Vikas
I understand your point, and I don't dispute that a provider has the right to protect its network or terminate a service in accordance with its terms.
However, I think you're overlooking an important distinction.
Not being able to prove that something was accidental is not the same as having proof that it was intentional.
HostDZire didn't simply say they were uncomfortable continuing the service due to the risks involved. They repeatedly stated that I had acted intentionally and even told me to "don't play innocent," despite my acknowledging the misconfiguration and offering to disable native IPv6 entirely.
That's the part I take issue with.
I also disagree that any operational friction, regardless of intent, should automatically result in termination. Configuration mistakes happen in system administration. The severity of the issue, actual impact, whether it was repeated, and willingness to correct it should all be relevant considerations.
I'm not arguing that the provider was obligated to reinstate my VPS. I'm questioning whether permanent termination and repeated accusations of malicious intent were a proportionate and professional response to a first-time configuration mistake.
As for the refund, I've already acknowledged and appreciated that they offered it. But providing a refund doesn't automatically make every aspect of the handling reasonable.
Ultimately, I'm sharing the facts so other users can form their own opinions. I respect your perspective, even though I disagree with your conclusion.
@Flanker? more like... Clanker
sorry
Should we connect AI to auto-reply in this thread
i didn't overlook it, i addressed it specifically: it doesn't matter.
This is a trash host. They're experts at killing the messenger instead of fixing the problem.
DO NOT change the subject. This isn't a place where you alone get to decide what's right and wrong (For example, your Telegram group).
@HostDZire Can we take over the VMs that were terminated for abuse?
Seems, you disagree with their decision and in the claim of "allowing users to form their decision" hope to some how change it. As others have said you are lucky to
A)Have a refund
B)Been allowed to keep other services, many other providers would have cut you off and had done with it
I know when it's time to make a graceful exit. 😂
I didn't reply to you, mate. Did I tag you, or would you prefer that I not reply to this thread? I would be happy to do so.
BTW, I voted to: HostDZire was wrong
Because, as we all know, the provider is always wrong
Refund: No issues at all. It actually exceeded my expectations, and I appreciate it.
Attitude: This is where I have a problem. I found the repeated assumptions of malicious intent unnecessarily subjective and unfair. Of course, I understand that you may see things differently from the provider's perspective.
Technical side: Well... I'd rather not comment on that.
Thank you again for the refund. My disagreement was never about the money, but about the way you handled the situation and treated me as a customer. That's something I simply cannot agree with.
I don't understand why LET providers don't lock down their infrastructure. Run at a big enough scale, and misconfiguration, either accidental or deliberate will unavoidably happen. Why allow it to cause any issues for your other customers or the infrastructure when it does? E.g. in this case traffic to VMs should be filtered both on the ingress and egress paths. And it also reminds me of the recent SKRIME thread about the VPS suspended for high CPU usage. Just implement automatic throttling the enforces a sensible FUP. Skills issue?
I must agree on this. Things are going to improve in the future. It's being done, which is why we found him.
I see no reason to believe what HostDzire did was anything unexpected.
Just the way a customer has freedom to choose a provider, so does a provider to choose where to stop the service to a specific customer for a specific reason.
However, one thing I am not getting is, even though the monkey stole the cookie by setting up incorrect ipv6, why didn't HostDzire systems not stop it at the time of configuration. As a provider if we are required to allot a specific ipv6 range to a customer, then to be safe, we are also supposed to deny a incorrect configuration (intentional or otherwise) before it gets setup. 👍🏽
I think you can do better than this!
Exactly, that's my point.
Technically, their network apparently didn't prevent the incorrect IPv6 configuration in the first place. Yet when the issue was discovered, their response was immediate and absolute: permanent termination, with no opportunity to correct it.
I fully acknowledge that the misconfiguration was my responsibility, and I don't dispute their right to protect their network.
But the contrast between the apparent lack of preventive safeguards and the extremely harsh, one-size-fits-all response afterward is what I find difficult to understand.
And frankly, the repeated accusations of malicious intent made the whole experience even more disappointing.
It's not the termination itself that bothers me most. It's the attitude and the way the situation was handled.
🍿
The service was abused through improper configuration. One could say he tested the waters; others would say it was a typo; others would say he was just fooling around; others would say he wanted to use IPv6 spoofing of some sort. No matter the causality, the effect is the same: abuse of network. In this case the provider is right to remove the problematic service.
Surely, the provider should create a tighter security in templates and in virtualization; however this is a completely different discussion which has no relevance for a case where an unmanaged service is improperly configured by the customer for whatever reasons.
I just realized it was FAT32 Special, ouch
Was your other service a Leaseweb VPS?