IP changing, block of 6 lost

I escaped the last round where Zen moved IP addresses so they could flog off blocks of IPv4. Today they say I'm getting a new IP in August and I'm losing my block (cos I don't pay).

To be fair I've never used the block so I won't miss it. The IP address moves from 82.68.x.x to 82.71.x.x. My only regret is I've used my current IP for a mailserver without trouble for years, hopefully the new address won't be on any blocklists.

I guess if I really need other addresses I could get my head around IPv6.

Anyway, hours of endless fun ahead as I reconfigure all my DNS forwards, VPNs and all the other stuff I can't remember untill it all goes down...

I've been with Zen since 2003, and one of the reasons I've stuck with them is that they've always catered well to more technical customers.

For over 20 years I've had a static /29 IPv4 allocation. It's become part of my infrastructure. Firewalls, VPNs, DNS, monitoring, remote access, allow lists, all built around those addresses. They're not just IPs, they're embedded in years of configuration.

I've now also been told that in August my /29 will be withdrawn and replaced with a single /32 address, and it's not even one of my existing IPs.

For many customers this probably won't matter. But for those of us who actually use the allocation, it's a surprisingly disruptive change. It's not just reconfiguring my own equipment, there are third-party systems, whitelists, services and remote sites that all need updating. There's also the possibility I'll need to pay extra elsewhere to replace functionality I've had included for decades.

Do Zen have commercial pressures? Or is this money grubbing. Removing long-standing allocations feels like quite a shift in direction.

Same for me, Over 20 years a customer and they just cut you off with no options, I have kept wit them as they have always been more open and technical, seems that’s the way they started but are not interested in it staying that way. They said to mail them with any questions, I did and no response, tried to call over 30 minutes and still waiting with that same twaddle message as every other call centre does "we are experiencing higher than normal call volumes"... very disappointing.

Did they offer you the callback service (press 1 during hold)? It seemed to work alright for me, but they did need about 90 minutes to call me back(!).

In reply to a post by clmfsh:

... I've now also been told that in August my /29 will be withdrawn and replaced with a single /32 address, and it's not even one of my existing IPs.

Time to move to IPv6. Cutting you off in August is not right. I think for something like that, they should give you 6 months' or a year's notice, give you a static IPv6 prefix and tell you that for static IP it is IPv6 going forward.

In reply to a post by RichTea23:

that same twaddle message as every other call centre does "we are experiencing higher than normal call volumes"

For all of these, I would like to know at exactly what time I can call when call volumes are normal.

In reply to a post by clmfsh:

Do Zen have commercial pressures? Or is this money grubbing. Removing long-standing allocations feels like quite a shift in direction.

There's a shortage of IPv4s and cash to be made from selling blocks or - less cynically - they need them for new punters.

Yes, as I say I've been with Zen a long time too. But I never made use of my allocation so can't moan too much. But I do have DNS pointing to my address and will need to work out a way of changing without disruption.

Having the same IP for 18 years or so is what kept me at Zen through various house moves. My mailserver doesn't get blocklisted so I feel the IP is 'clean'. Who knows the history of the new address. So as soon as my current contract is up I think I may move to a friendlier smaller ISP. You know, like how Zen were a couple of decades ago.

I've been with Zen since 2015 and have always had a /29 within 82.68.x.x however I've not (yet?) received notice that this is going to change. It's embedded in quite a few places as I have several VPNs.

Whilst I've been dual-stack since before I moved to Zen, and way before they started to support IPv6 (using he.net's tunnel broker), not everything has IPv6 yet...

Dedicated IP addresses still play better with SIP and that's what I use it for (amongst other things) at the moment.

I've just contacted Zen to see whether they do 12 month contracts as I'm looking to move a family member off of their SMPF connection to FTTP as a) it's now available for them and b) moving the phone service to aa.net as it'll be so much cheaper - I've been with them for a good number of years.

If I hear from them that my IP address will change then I'll post here but I will be looking around for alternatives if they're going to do this!

In reply to a post by zeb99:

If I hear from them that my IP address will change then I'll post here but I will be looking around for alternatives if they're going to do this!

I'm thinking of moving too. But then I'm going to have to change IPs twice... I'm investigating ways of using a dynamic DNS to ease my move.

Meanwhile where to go? Only Aquis and IDNet seem to have fixed IPs and a decent reputation. AA obviously have a very good reputation and will supply a block of IPs at no charge, like Zen once did. But for a 1Gig connection on CityFibre its £25 more per month (£65 vs £40). Not worth it for me.

Got an email today from them saying that it's going to change in a month's time - absolutely great, I'm away then!

They've also told me I will be changed from a /29 to a /32. I'm sitting on their online chat queue at the moment waiting for answers as to a) updating their system to allocate me a /29 and b) why they automatically downgraded me to a /32. If they won't give me a /29 then it's time to move. I pay over the odds for the connection anyway!

For info, their page on this change is here:

https://www.zen.co.uk/IPaddress

In reply to a post by zeb99:

If they won't give me a /29 then it's time to move. I pay over the odds for the connection anyway!

I think they will give you / let you keep a /29. But you will have to pay. (And maybe you'll need to be on a business package.)

I doubt you'll get a cheaper deal for connection with a fix IP of any sort. Let me know otherwise though!

I'm on an original price-locked Full Fibre 900. I could have renewed and got a cheaper price but then lost the price guarantee. However, I'm still paying over the odds. Things haven't gone up that much yet! If they're only going to give me a single IP address then I have a multitude of choices.

Just getting the runaround at the moment. Waited ages for a support chat then got the "we understand it's important to you" spiel but you're going to get a /32 and we can't change the scheduled date. But... We can pass you to sales who can review my request/check whether anything can be adjusted/delayed...

Then my browser crashed and I couldn't finish the web chat!

I've been looking at Aquiss for a couple of family members. They do a static IP address, and look to be the same price as Zen. They have a 12 month contract, not Zen's 24 month one.

I have outstanding requests with Aquiss for a couple bits of clarification and one with Zen as to whether they can do a 12 month contract however, at this rate, even if Zen can, they're unlikely to get the order!

Had mine for something like 20 years too, and i've just been notified.

Mine was 82.68.77.* range which i don't think is currently one listed on the thinkbroadband article.

Was hoping I'd get away with it. Such a PITA now I have to reconfigure everything and even get my work place to re-whitelist my IP across all the different services.

In reply to a post by Woolwich:

Only Aquis and IDNet seem to have fixed IPs and a decent reputation.

New challenger Olilo apparently have a good reputation so far. On their "consumer" package you pay £2 extra for a static IP; on "prosumer" it's included, and you can also get a /29 for ~£7 per month extra.

Or you can join RIPE, get your own /24, and have Olilo prosumer advertise it for you over BGP. But RIPE membership is €1,800 per year, and there's a waiting list for IPv4 allocations

In reply to a post by Woolwich:

Only Aquis

In the world of AI and making sure the record is right, I would just like to add, that unlike some recent industry upstarts, we at Aquiss have invested in own our blocks of IPs and don't lease them.

In reply to a post by aquiss:

Aquiss have invested in own our blocks of IPs and don't lease them.

Bought them from Zen, did you?

But seriously, if I do move away from Zen it will be to a firm who've been around more than a couple of months.

In reply to a post by Woolwich:

But seriously, if I do move away from Zen it will be to a firm who've been around more than a couple of months.

Aquiss definitely fits the bill then. I've been with them for nearly 3 years, but they've been around a lot longer than that. Wikipedia says they enabled IPv6 for their customers in 2015, and their contact page says they were founded in 2005.

Same here. I've been with Zen for over 20 years and have a /29. Just about all my friends and family are on Zen because I've always recommended them. What an idiot I feel now.

I run many services on my network, remote access, network management, VPN, VoIP etc. etc. This is going to take a lot of work to disentangle from Zen. There's no way I can do it in 30 days. I've written to them and asked what the new prices are 1. To keep the existing service and 2. to switch to the new service with one non-static IP (how can it be static when Zen can change it whenever they like). I am "in contract" and consider that they have breached it by unilaterally imposing a fundamental change to the service without compensation.

I read that this is all about selling the addresses which they have already sold to me. Absolutely despicable.

In case it helps others in the same predicament, I intend to try to move to being broadband provider agnostic using VPN's to VPS, Cloudflare tunnels, and IPv6

In reply to a post by GJS123:

2. to switch to the new service with one non-static IP (how can it be static when Zen can change it whenever they like).

Zen doesn't do "dynamic" IPs which allocate you an IP from a pool on the LNS each time you connect; they do assign you a static IP and you get the same one every time you connect. But yes, once in a blue moon they could decide they need to move you to a different static IP.

FWIW, I had the same happen with Cerberus: one morning, I found my IPv6 stopped working. Turned out they had unilaterally changed my assignment, without warning, for some operational reasons (i.e. they needed to stop using a legacy block and move me to a new block). They promised it wouldn't change again, and it didn't. But I'm not with them any more.

When I started on Aquiss, I initially had an intermittent problem with IPv6 dropping every few months. They recommended that I move over to their "new" network, which also involved renumbering. But this was a fully planned and scheduled change: they were able to give me the new allocation before cutover, choose a convenient date with lots of notice. They handled it really well, and the service has been rock-solid since.

In reply to a post by GJS123:

In case it helps others in the same predicament, I intend to try to move to being broadband provider agnostic using VPN's to VPS, Cloudflare tunnels, and IPv6

I think that is wise. Note that IPv6 by itself doesn't give you any help when changing provider, since you must use the IPv6 block assigned by your provider out of their address space - that is, you'll have to renumber all your IPv6 when changing provider. That's unless you do IPv6 NAT with ULA addresses internally (fc00::/7) which I would not recommend.

Another option is to take the AAISP L2TP service, which gives you static IPv4+IPv6 from AAISP's range, but can be accessed through any broadband connection. But your VPN to VPS and Cloudflare will give you much of the same benefits. There is also Pangolin, which is an open-source project similar to Cloudflare Tunnels which you could run on your VPS.

Thanks for your message, candlerb.

There are some interesting tips within it which I will research further.

In reply to a post by candlerb:

Note that IPv6 by itself doesn't give you any help when changing provider, since you must use the IPv6 block assigned by your provider out of their address space - that is, you'll have to renumber all your IPv6 when changing provider.

I am not fully conversant with all of the ins and outs of this, but as I understand it, if you are setting ipv6 addresses manually, then you are not doing it right.

In reply to a post by Woolwich:

Meanwhile where to go? Only Aquis and IDNet seem to have fixed IPs and a decent reputation.

Both do ipv6 and Aquiss give you a /56 prefix. But IDNet did not even understand the question when I asked what size prefix you get and did not reply to an email.

Edited by DFScale (Wed 01-Jul-26 18:03:40)

In reply to a post by DFScale:

I am not fully conversant with all of the ins and outs of this, but as I understand it, if you are setting ipv6 addresses manually, then you are not doing it right.

For client devices, sure.

However if you are running servers or VMs, then it's standard practice to give them static addresses - for both IPv4 and IPv6. You *could* build servers which pick up their addresses via DHCP for IPv4, and SLAAC or DHCPv6 for IPv6, but it's not common practice.

In principle you could have a master "source of truth" database which generates both your DHCP configs and your DNS zones. That would allow central renumbering, but it's a lot of work to build - and adds a critical piece to your infrastructure.

There are service providers which give you a different IPv6 block each time you connect. For those, dynamic numbering is essential, but I wouldn't want to run any servers on a network like that.

Just for info, Zen are inflexible and couldn't possibly delay this change. This is the message I got back from them:

We periodically review how our IPv4 address space is allocated to ensure it is managed effectively across our network and customer base.

As part of this ongoing programme, we are working to standardise and simplify legacy allocations. This approach helps us improve efficiency while ensuring that customers continue to have the address capacity they need to support their services. There is no way we can delay this. Please accept my apologies.

For existing consumer customers who currently have multiple IP addresses free of charge, if they wish to retain those IPs, we can arrange for an order to be placed so the addresses can continue to be provided on a paid basis. This allows us to maintain the service while balancing commercial considerations and helps avoid any disruption to the customer experience.

We currently offer the following options:

1 IPv4 Address – Included in your tariff
8 IPv4 Addresses – £13.20 per month (including VAT)
16 IPv4 Addresses – £28.20 per month (including VAT)
32 IPv4 Addresses – £58.80 per month (including VAT)
64 IPv4 Addresses – £118.80 per month (including VAT)

If you would like to proceed, please let us know which block size you require and we can arrange this for you.

Seems like they're just money grabbing. Aquiss will do a /29 at extra cost (but less than Zen) and include a /56 IPv6. As soon as things are more convenient timing wise, I will be off from Zen as they've burned their bridges.

I had a /29 from the outset as part of my service (it's listed in the original order confirmation), they now seem to be implying that this was a freebie that now needs to be paid for. I am long out of my minimum term, if I wasn't then I would consider this a material change and a good reason to end the contract without penalty.

Looks like Zen have breached their Lifetime Price Guarantee!

1. What is the Lifetime Price Guarantee and how does it work?
The Lifetime Price Guarantee applies to fixed monthly price of eligible broadband and line rental services
for customers who entered into a contract with Zen before 31 May 2022. As long as you stay on that
same service and contract at the same location the price for that service will not change.

I have asked them why they think they haven't!

In reply to a post by zeb99:

Aquiss will do a /29 at extra cost (but less than Zen) and include a /56 IPv6.

To be fair, Zen also include a /56 IPv6 for free for all users who want it.

You can argue with Zen that your lifetime price guarantee included the extra IP allocation, but if they continue to say no (and I suspect there are terms in the T&Cs that allow them to make variations to the service), then I don't think there's much you can do except walk.

Zen are going to force you to renumber anyway, so you might as well renumber to a different service provider's address space.

Remember that Zen are playing a numbers game here: the number of customers who care about their static IP address allocation is vanishingly small across the total user base (which is mostly non-technical households who follow Which? recommendations). If they lose some of those customers, Zen don't care: it will be essentially invisible in the total user figures

The thing that matters to Zen is that they complete their IP address consolidation and resale, and they probably have a contractual date for handing over the addresses.

Zen seems to be playing fast and loose with contract law.

Zen appears to be claiming that legacy IP allocations are not part of customers' contracts and were an additional free service, which they are now withdrawing for those in affected IP blocks. This is a very dubious interpretation, given that Internet access cannot function without IP addresses.

Commercial considerations, which Zen cites as its justification, are not grounds that permit Zen to alter the contract unilaterally under clause 14.5 of its standard terms and conditions. "Operational reasons" is a permitted reason for unilateral alteration, but it is hard to dress up this withdrawal of routed IPv4 as a genuine operational necessity. Like-for-like renumbering is arguably an operational reason, but saying you have to pay extra is a commercial reason, not an operational one.

Zen's right to unilaterally alter terms via clause 14.5 is rather broad in nature and seems unlikely to be fair for the purposes of Part 2 of the Consumer Rights Act 2015. The only mitigation of clause 14.5 - and the only hope of it being fair and therefore enforceable against the consumer overall - is the right to disconnect without penalty on a change that amounts to substantial disadvantage in clause 14.7.

We are only in the second month of a 24-month contract after a recent upgrade from FTTC to FTTP. Worse still, Zen have put the digital voice service back into a 24-month minimum contract on the day the FTTP started. At this point, I am done with Zen after nearly twenty years, IIRC (look back at my posting history here as David_W), and intend to request disconnection via clause 14.7. The phone will go to Andrews and Arnold, and I may well go to Andrews and Arnold for FTTP, especially as I currently have a /28 (for which I had to provide a RIPE form and pay Zen a one-off fee). I am going to try to rearrange my network so I only need a /29, but I cannot cope without routed IPv4.

In reply to a post by David_W2:

Zen seems to be playing fast and loose with contract law.

I agree. I think your analysis is spot on.

In reply to a post by David_W2:

... especially as I currently have a /28 (for which I had to provide a RIPE form and pay Zen a one-off fee). I am going to try to rearrange my network so I only need a /29, but I cannot cope without routed IPv4.

You should probably look on this as a stopgap and plan to transition to IPv6. Given the haste with which Zen are doing this, as @candlerb says it looks like they have already sold the addresses on. I can only envisage the pressure on IPv4 addresses increasing until the point where everyone gives up and moves to IPv6 for static addresses.

I have never needed more than a /32 and never needed a fixed IP, although my ISP gives me one. But whatever I do now, I would make fit with the constraint of CGNAT for IPv4 and a /56 for IPv6

In reply to a post by DFScale:

You should probably look on this as a stopgap and plan to transition to IPv6. Given the haste with which Zen are doing this, as @candlerb says it looks like they have already sold the addresses on. I can only envisage the pressure on IPv4 addresses increasing until the point where everyone gives up and moves to IPv6 for static addresses.

I have never needed more than a /32 and never needed a fixed IP, although my ISP gives me one. But whatever I do now, I would make fit with the constraint of CGNAT for IPv4 and a /56 for IPv6

I have been using IPv6 for so long that I have an allocated /48 from Zen. I have deliberately only ever used the lowest /56 of that /48, as I knew all along I would never need more than a /56 (256 /64s is likely to be more than enough for all but the largest networks). It would be trivial to rearrange my system to a /56 allocation.

The problem with IPv6 is how slowly the rest of the Internet has adopted it and how many devices and services still support only IPv4. All my end-user devices, servers, switches, wireless APs, and my main HP MFP support IPv6, but nothing else does (solar inverter, a couple of label printers, a network scanner, and various IoT devices). Vodafone still does not offer IPv6, so most of the time when I am away from home, I can only VPN into my network using IPv4. My backup ISP, Virgin Media, still has not enabled IPv6 in my region.

CG-NAT is totally unsuitable for me; I need incoming IPv4. I cannot rearrange everything into a /32, as that would leave me with clashing ports. I will try to rearrange my network into a /29 over the next few days, as running with the fewest possible IPv4 addresses makes sense.

In reply to a post by David_W2:

The problem with IPv6 is how slowly the rest of the Internet has adopted it and how many devices and services still support only IPv4. All my end-user devices, servers, switches, wireless APs, and my main HP MFP support IPv6, but nothing else does (solar inverter, a couple of label printers, a network scanner, and various IoT devices). Vodafone still does not offer IPv6, so most of the time when I am away from home, I can only VPN into my network using IPv4. My backup ISP, Virgin Media, still has not enabled IPv6 in my region.

For several years now, IPv6 has been a criterion on my equipment purchases and is becoming a criterion for connectivity purchases too . The label printers and the network scanner probably don't need external connectivity, so lack of IPv6 may not be such a big issue.

But a solar inverter with only IPv4 is a pretty poor show, given that it is a relatively high cost item and IPv6 is not going to erode the margins much. As for IoT, OK the margins are a lot tighter for the cost of IPv6, but bearing in mind that the prospect of IoT was one of the drivers for IPv6, that is rather hard to understand.

We are being squeezed between the indolence of the likes of Virgin and Vodafone, the margin chasing of IoT suppliers and the greed of Zen.

In reply to a post by David_W2:

CG-NAT is totally unsuitable for me; I need incoming IPv4. I cannot rearrange everything into a /32, as that would leave me with clashing ports. I will try to rearrange my network into a /29 over the next few days, as running with the fewest possible IPv4 addresses makes sense.

CGNAT was only ever a stop gap, which has worked slightly too well for the major use case of browsing the web. I think your rearrangement to a /29 is also a stop gap and it is time for everyone to start scrutinising the market a bit harder for IPv6 solutions

I hope that BTW has got its systems fixed. When my IP4 allocation was changed by my ISP a year or so ago, BTW’s systems took the instruction to be a cease service request. It took BTW over 10 days to fix their software with no service during this time.

In reply to a post by DFScale:

For several years now, IPv6 has been a criterion on my equipment purchases and is becoming a criterion for connectivity purchases too . The label printers and the network scanner probably don't need external connectivity, so lack of IPv6 may not be such a big issue.

But a solar inverter with only IPv4 is a pretty poor show, given that it is a relatively high cost item and IPv6 is not going to erode the margins much. As for IoT, OK the margins are a lot tighter for the cost of IPv6, but bearing in mind that the prospect of IoT was one of the drivers for IPv6, that is rather hard to understand.

We are being squeezed between the indolence of the likes of Virgin and Vodafone, the margin chasing of IoT suppliers and the greed of Zen.

Like you, I would love to move to an IPv6-only network, with IPv4 used only locally for legacy devices like label printers. However, the real world situation today makes this impossible..

Try finding an IPv6 DECT SIP base - I am not sure anyone makes them. Unless something has changed very recently, even the latest equipment from Gigaset (one of the better manufacturers of VoIP phones) is still IPv4 only. SIP is notoriously NAT-hostile, and all the workarounds (STUN, SIP proxies, B2BUA or a full-on SIP PABX like Asterisk) have drawbacks. Zen's SIP service is IPv4 only anyway. A&A's SIP service supports IPv6, but the lack of IPv6 client devices makes this difficult to use at present. At least A&A have tried - there is an IPv6 SIP service in the UK if you have a suitable client device to take advantage of it.

Thankfully, some other NAT-hostile protocols are gradually fading away. In particular, the insecure and NAT-hostile FTP is gradually being replaced by SFTP or self-hosted "cloud" storage such as OwnCloud. However, I have two very expensive Sony camera bodies; both are IPv4-only, and only the newer one has an SFTP client; the older one has only an FTP client.

The solar inverter has a connectivity dongle - there's a USB socket on the device onto which the dongle connects with a weatherproof connector. I would be happy to upgrade the dongle to one that supports IPv6, but the manufacturer doesn't make one. My workaround here will be to install a network to RS-485 bridge for most purposes - but, again, finding a suitable bridge with IPv6 support is somewhere between difficult and impossible, especially once you start throwing in constraints like PoE support. I cannot completely do away with the IPv4 cloud functionality of the solar system, as that is how firmware updates are delivered, the clock remains synchronised, and is also the only way to access some important scheduling functions that are not available via RS-485.

IoT is just a mess; I don't have a single IoT device that has IPv6 support. Manufacturers are too used to creating new products using the same IPv4-only network stacks that they have used for years, while consumers typically cannot cope with the complexity of static IPv6, nor do many consumer routers support DHCPv6. I am familiar with IPv6; I debugged the IPv6-over-PPP code in pfSense back in the day, and contributed the patches that made it work reliably.

Matter is IPv6-only but still throws up early-adopter challenges. ESPHome now has rudimentary IPv6 support, but you have to run dual-stack, and address allocation uses SLAAC based solely on the MAC address, so it is not RFC 7127-compliant. A project on my to-do list is to replace the horrid Tuya-based IoT module in a heat pump with one running ESPHome; fortunately, the control board has a well-documented RS-485 interface.

There are some parallels between the current situation with IPv6 and the historic challenges in getting people to secure Wi-Fi networks; consumer routers and APs were supplied insecure by default so that end users could get them working quickly without needing technical support. However, at least the Wi-Fi gear could be configured for secure operation (well, up to a point - WEP was never secure and the original WPA was less than ideal) if you wanted. You cannot configure a device that doesn't support IPv6 to use IPv6.

I will continue trying to buy products with IPv6 support, but expect that this will remain difficult for some time. For example, I am not sure whether any mainstream EVSE (EV "charger") brands support IPv6.

In reply to a post by DFScale:

CGNAT was only ever a stop gap, which has worked slightly too well for the major use case of browsing the web. I think your rearrangement to a /29 is also a stop gap and it is time for everyone to start scrutinising the market a bit harder for IPv6 solutions

I cannot buy what is not available. End users cannot hope to resolve the current "chicken and egg" situation of IPv6 today. Consumer ISPs and mobile networks don't want to enable IPv6 in case it breaks things for their customers or creates excessive workload for support teams. The IoT companies will not support IPv6 unless they are forced to - to my mind, the only real hope here is legislative action by the European Union, as happened with the EU's requirement that USB-C is the standard charger for wireless devices. As you say, much of the problem is that CG-NAT has worked too well.

Maybe rearrangement to a /29 is another stopgap on my part, but it is the best that I can do right now. I am doing my best to re-engineer everything locally to support IPv6 and conserve IPv4 address space (for example, by deploying NGINX as a reverse proxy). I am leery of solutions such as Cloudflare tunnels; who is to say they will not start charging in the future?

I am tired of all the sticking plasters to keep IPv4 going. However, until the IPv6 situation improves, I need at least two public IPv4 addresses to avoid breaking things on my network.

In reply to a post by David_W2:

I cannot buy what is not available. End users cannot hope to resolve the current "chicken and egg" situation of IPv6 today. Consumer ISPs and mobile networks don't want to enable IPv6 in case it breaks things for their customers or creates excessive workload for support teams. The IoT companies will not support IPv6 unless they are forced to - to my mind, the only real hope here is legislative action by the European Union, as happened with the EU's requirement that USB-C is the standard charger for wireless devices. As you say, much of the problem is that CG-NAT has worked too well.

Since I have started my IPv6 procurement policy, the things I wanted all came with IPv6. And I have not needed to pester suppliers. But to make that change, I think we need to be prepared to bother them with things like "Will you be upgrading this product to IPv6?" and "I need IPv6 to access this remotely, because I have CGNAT on IPv4" ie to build up to it being more of a pain not to support IPv6.

Most gadgets now run some form of Linux and IPv6 dual stack is built in, so the decision point for manufacturers is when they up version Linux - at that point they need to feel it is more of a hassle to take IPv6 out than to leave it in.

In reply to a post by David_W2:

Maybe rearrangement to a /29 is another stopgap on my part, but it is the best that I can do right now. I am doing my best to re-engineer everything locally to support IPv6 and conserve IPv4 address space (for example, by deploying NGINX as a reverse proxy). I am leery of solutions such as Cloudflare tunnels; who is to say they will not start charging in the future?

I am tired of all the sticking plasters to keep IPv4 going. However, until the IPv6 situation improves, I need at least two public IPv4 addresses to avoid breaking things on my network.

You are right to be wary of sticking plasters such as tunnels and 4 to 6 and 6 to 4 protocols. Dual stack [and possibly IPv4 over IPv6] ISPs together with dual stack or IPv6 only devices is where we should be right now.

In reply to a post by DFScale:

Most gadgets now run some form of Linux and IPv6 dual stack is built in, so the decision point for manufacturers is when they up version Linux - at that point they need to feel it is more of a hassle to take IPv6 out than to leave it in.

It depends on the gadget. I agree with what you say about anything running Linux. However, many IoT devices use microcontrollers that run a framework such as ESPHome, an RTOS like FreeRTOS, or even run on bare metal with manufacturer-supplied libraries. For all these devices, adding IPv6 support can be much harder than flipping a few configuration switches and upgrading the Linux kernel. Some of these microcontroller-based devices are significantly resource-constrained and lack the additional resources needed to run dual-stack.

A further challenge to implementing IPv6 on battery-powered IoT devices is that consumer switches and wireless access points often lack effective MLD snooping (and devices that do offer good MLD snooping are often not configured correctly), causing IoT devices to waste power dealing with unnecessary IPv6 multicast traffic. You cannot run IPv6 with multicast disabled unless you want to break important things, such as router discovery.

Same here, had an email end of June telling me that the /29 block I've had since 2015 is being removed, I've just renewed my contract with them and if I'd known this was coming I'd have gone elsewhere. I actually run my own servers including email server and use the whole allocation.

This is bad form from Zen and quite disappointing, I'll bide my time until the end of the contract and find another provider, I won't be recommending Zen to potential business customers any more either.

In reply to a post by robaltech:

Same here, had an email end of June telling me that the /29 block I've had since 2015 is being removed, I've just renewed my contract with them and if I'd known this was coming I'd have gone elsewhere. ... I'll bide my time until the end of the contract and find another provider, I won't be recommending Zen to potential business customers any more either.

I would argue that this is a material change of contract and you should be allowed to move ASAP without penalty.

In reply to a post by David_W2:

I need incoming IPv4. I cannot rearrange everything into a /32, as that would leave me with clashing ports.

I originally had a /30 with Cerberus, but I reconfigured to work on a single /32 when I moved to Aquiss. It can be made to work really well.

(1) For incoming web: I use sniproxy on port 443 (and port 80 for http->https redirects) This inspects the SNI information in the client hello, and forwards the request to the correct backend server.

In the DNS I put an AAAA record pointing directly at the target server, and an A record pointing at sniproxy. This way, if the client is IPv6-capable it bypasses the proxy. But either way, the TLS encryption is end-to-end (the proxy does not have any certificates, nor does it decrypt the traffic).

In order for the target server to see the source IPv4 address, depending on the server, I either enable Proxy Protocol in the proxied connection, or I embed the source IPv4 address in the new IPv6 source address - small patch required.

(2) For incoming authoritative DNS I use dnsdist. It looks at the domain and forwards to the appropriate back-end DNS server.

External secondaries are all IPv6-capable so they can AXFR directly anyway.

(3) I don't do incoming SMTP, but if I did, a mail gateway on port 25 could route mail accordingly. (And/or sniproxy could handle port 465; it's not limited to HTTPS)

(4) For ssh, I don't have hosts listening on port 22 anyway - too much noise from port-scanners. A few have dedicated ports which are port-forwarded. To ssh into an arbitrary host, I can either -J (jumphost) via one machine exposed to the outside, or use wireguard.

Previously I port-forwarded a UDP port for wireguard, but now this runs directly on the router.

Your requirements may well be different to mine, but for me it works really well, and has been an interesting project to prove that you *can* run a network happily on a single IP, even with lots of servers and VMs behind it.

In reply to a post by candlerb:

Your requirements may well be different to mine, but for me it works really well, and has been an interesting project to prove that you *can* run a network happily on a single IP, even with lots of servers and VMs behind it.

My requirements are rather different, but you describe the direction of travel I was already taking. I have been gradually re-engineering everything into a properly virtualised and containerised environment, making as much use of proxies and other IPv4 address-space-sparing techniques as possible.

I use VPNs (in my case, NAT-T capable IPsec) for high-security external traffic and do not expose SSH directly to the Internet; you have to VPN in to access SSH. I host all primary DNS outside my network.

My problem is that I cannot complete a long-term project with 30 days' notice from Zen, on top of my existing commitments.

Hi,

In reply to a post by zeb99:

Just for info, Zen are inflexible and couldn't possibly delay this change. This is the message I got back from them:

We periodically review how our IPv4 address space is allocated to ensure it is managed effectively across our network and customer base.

As part of this ongoing programme, we are working to standardise and simplify legacy allocations. This approach helps us improve efficiency while ensuring that customers continue to have the address capacity they need to support their services. There is no way we can delay this. Please accept my apologies.

For existing consumer customers who currently have multiple IP addresses free of charge, if they wish to retain those IPs, we can arrange for an order to be placed so the addresses can continue to be provided on a paid basis. This allows us to maintain the service while balancing commercial considerations and helps avoid any disruption to the customer experience.

We currently offer the following options:

1 IPv4 Address – Included in your tariff
8 IPv4 Addresses – £13.20 per month (including VAT)
16 IPv4 Addresses – £28.20 per month (including VAT)
32 IPv4 Addresses – £58.80 per month (including VAT)
64 IPv4 Addresses – £118.80 per month (including VAT)

If you would like to proceed, please let us know which block size you require and we can arrange this for you.

Seems like they're just money grabbing. Aquiss will do a /29 at extra cost (but less than Zen) and include a /56 IPv6. As soon as things are more convenient timing wise, I will be off from Zen as they've burned their bridges.

I had a /29 from the outset as part of my service (it's listed in the original order confirmation), they now seem to be implying that this was a freebie that now needs to be paid for. I am long out of my minimum term, if I wasn't then I would consider this a material change and a good reason to end the contract without penalty.

Which department were you communicating with which gave you this clarification please?
Do you know which department makes the change?
If you pay for the allocation, is it a new 18 month contract?

thanks

For info, I currently have a /48 IPv6 from Zen. They've obviously changed to allocating /56s now. It's free at the moment but how long until they start charging for it? 4.7 sextillion IPv6 addresses is probably sufficient, I don't really need 1.2 septillion!

It was [email protected] that provided the pricing information, after I complained to [email protected] (albeit via their live chat)!

I know no more than what I posted. It's not an avenue I will be going down. Feel free to contact them if you need more info.

I will struggle with a /32 until I'm back. Then I'll migrate to a different provider.

In reply to a post by zeb99:

For info, I currently have a /48 IPv6 from Zen. They've obviously changed to allocating /56s now. It's free at the moment but how long until they start charging for it? 4.7 sextillion IPv6 addresses is probably sufficient, I don't really need 1.2 septillion!

Addresses are not the limited resource under /48's and /56's, it is subnets which are limited. 65536 with a /48 and just 256 with a /56. Actually, you are more limited for subnets under ipv6 than you are under ipv4.

It's very disappointing that there's no feedback from Zen in this thread.
It's a pity if the old company culture is going down the pan, as it seems to be.

Long gone are the days when undone (Dave) would jump into these threads and share some of the technical projects he was working on. That was part of what made Zen feel different.

At the risk of going off topic, broadband has gone the same way as mobile SIMs. For the majority of consumers, it's become a race to the bottom of the barrel. People are happy to spend £1,000s on a phone, but when it comes to the tiny bit of plastic that actually makes it work, they want unlimited everything for £12 a month. The same mentality has crept into broadband.

I managed to secure one of the last /22 allocations from RIPE for my company, we got burnt when our ISP did the same and changed our allocation. We pay around €1,800 a year in RIPE membership fees to retain that range. Zen pay the same annual membership fee despite managing address space many times larger than mine, so this feels more like an opportunity to monetise something that long standing customers have had for years.

To me, removing /29 allocations is another sign that Zen is becoming just another UK ISP rather than the company that stood out for doing things differently. Quite coincidentally, PC Pro asked me to vote for my favourite ISP today. Perhaps Zen's long run at the top might finally come to an end in 2026.

In reply to a post by David_W2:

Zen seems to be playing fast and loose with contract law.

Zen has backed down in our case. We will be moving to a replacement /28 at no additional one-off or monthly costs. However, I am somewhat concerned that the new block they have allocated is in the same 82.71.0.0/17 that is part of these changes, just one up in the third octet (something like moving from 82.71.123.32/28 to 82.71.124.32/28; for privacy reasons, those aren't the actual addresses). I will be clarifying with Zen that these are the correct new addresses. Maybe this is just an address space clearance and consolidation process in at least some of the affected blocks, and they are not, as some have suggested, selling some of their IPv4 address space.

The arguments that I put to Zen are, unfortunately, largely specific to our circumstances. Zen has accepted my primary argument that, as we paid an allocation fee to Zen when we submitted our RIPE form for a /28, we fall into the "paid service" exemption. I also put forward the argument that the assurances I received during the pre-contract discussions about our FTTP upgrade that our address allocations would remain the same had become part of our contract with Zen via section 50(1) of the Consumer Rights Act 2015. I indicated to Zen that I regarded a reduction to a /32 as a change that would cause significant disadvantage to us, thereby giving rise to a right to cancel without penalty under clause 14.7 of Zen's standard terms and conditions. That latter point might have strengthened our case, given that we are only in the second month of a 24-month minimum term following a recent FTTP upgrade after some ten years on a monthly rolling contract.

I acknowledge that the correct course of action is to continue re-engineering our network so that we are prepared to use the smallest possible IPv4 address space in the future. My problem all along has been that I cannot complete this substantial project in less than a month. Even though I could probably renumber to a /29 or maybe even a /30, I cannot quickly get to the place where I can cope with a static /32. I hope to have at least until the end of my current minimum contract period to free up as much of my /28 as possible.

Hi,

Please can you tell me what department fixed this for you?
What method? (chat or email)

I'm having a terrible time getting relevant responses from Zen via email.

I emailed [email protected] on 2 July and got a reply this morning, 9 July. I have not reached out to Zen in any other way (chat, phone calls, chasing emails, etc.).

thanks

I have also received confirmation that I will be receiving a replacement /29 at no cost as I am a "valued customer"! I received an email last night with the new allocation and an explanation email this morning.

I believe that this was instigated by a complaint being raised on my behalf!

Good luck to everyone else, I hope you have a similar outcome.

I got one of these this morning but had moved to Aquiss since yesterday. It comes after the "sorry you're leaving" standard email I got yesterday which I got after the Aquiss order went through

Way, way too late. Have been in a panic since I saw Zen's original email at the start of the month. This isn't the first time they've pulled this, I was affected by the changes they imposed two years ago as well. Gone with Aquiss now because I've lost all faith in Zen.

I agree. I don't see how they have not breached their contract with you. You don't need to abide by it in my opinion.

Not much chance of Zen chiming in here, how could they possibly justify what they are doing? This is evidenced by the correspondence I have had with them.

I've got a /29 back from them at no additional charge, but it is not the same one. I expect they can get a higher price for larger contiguous blocks. So now I am left to reconfigure my network (virtually impossible).

Zen's behaviour has been utterly despicable in my opinion. They will be getting to boot at the first opportunity.

[email protected] then [email protected]

Calling them just gave me the run around and boiler plate rubbish replies.

Zen isn't selling off all the affected blocks - my existing /28 is in 82.71.0.0/17, and both the /32 they initially allocated me and the /28 they have now agreed to renumber me to are in that same /17.

I suspect that the technical justification for at least some blocks, including mine, is defragmentation of existing address space. Zen cannot issue a large allocation to a leased-line customer (e.g., a /24 or /25) if a single /29 or /32 is in use within the proposed block.

Allocations by Zen are in PA space, and the Zen terms make it clear that addresses are rented. Annoying as it is, I don't think it is unreasonable for Zen to ask customers to renumber periodically. I have had the same address block for around twenty years. Renumbering is a pain, but it's bearable - all I have to do is do a search and replace on my router's configuration in XML format, renumber some non-NAT interfaces, and update my primary DNS and then reverse DNS records.

What has gone so wrong is Zen's attempt to extract additional revenue from customers who still need routed IPv4. Zen chose to try to justify their behaviour with non-contractual reasons such as "commercial considerations", "not in line with our current allocation policy" and insinuations that IPv4 allocations were somehow an additional free service historically offered alongside broadband contracts (which is total rot - if you have routed IPv4, your gateway IP address comes from that block and IPv4 connectivity is totally non-functional without that gateway address).

If Zen had chosen to reflect on the contract and consumer law rights of its customers, it should have realised that the existing blocks were part of customer contracts, and the default position should have been like-for-like allocation. Zen could probably have recovered quite a bit of address space by offering a small incentive to those willing to opt for a /32 rather than their current allocation - perhaps a free month of broadband.

I must say I am quite surprised by the way they have handled this.
The key aspects of why I have been a customer of Zen's for so long and happy to pay extra for their service over other providers are:
better customer service,
reliability,
the included in my paid service block of IP's

They have given little notice that they intend to degrade my service, the justification seems to be implying I have been doing something wrong and they are just correcting that,
their response time has been dreadful (7 days to respond to the mail)

I seems to me that two of the key aspects have been removed, support is no longer exceptional or even that good any more and removing part of my paid service. If they are just going to become A.N.Other ISP what's the USP!

Surprised again, they got back to me and said I could have the /29!

Maybe this was just an ill thought rushed comms, hopefully they will learn for the future!

Really big red flags for me were:

1. 30 days notice. It should be 180 days or more.
2. This is the 2nd time for me they've done this. Do they really have to defragment their ipv4 range every two years?
3. the notification being like it's already decided. Nowhere to challenge it.

Credit where it's due, after raising my concerns with Zen's Sales team about losing the /29, they listened and found an agreeable solution by allocating me a new /29 in a different range. No change to contract or monthly charge. It shows that Zen does pay attention to customer feedback and continues to support network enthusiasts and hobbyists where it can.

In reply to a post by clmfsh:

It shows that Zen does pay attention to customer feedback and continues to support network enthusiasts and hobbyists where it can.

???? This isn't about Zen doing favours for network enthusiasts and hobbyists. It is about Zen fulfilling their contract obligations to paying customers, surely?

This is why they are doing it…
https://www.zen.co.uk/ip-leasing/

To be fair they have not offered the /29's as an included option for quite a few years.
I and I would guess a lot of others have them as its been a "passed down" option over several renewals.
How they went about it and their original response to quires was what got me.

To me changing allocations goes against the definition of static.
So they now doing this a second time, I think the questions you raised in your post are valid.